On Mon, Jan 31, 2011 at 3:27 PM, Nicolas Pitre <[email protected]> wrote: > On Mon, 31 Jan 2011, Grant Likely wrote: > >> If a dtb is passed to the kernel then the kernel needs to iterate >> through compiled-in mdescs looking for one that matches and move the >> dtb data to a safe location before it gets accidentally overwritten by >> the kernel. >> >> This patch creates a new function, setup_machine_fdt() which is >> analogous to the setup_machine_atags() created in the previous patch. >> It does all the early setup needed to use a device tree machine >> description. It also creates arm_unflatten_device_tree() which copies >> the dtb into an allocated buffer and unflattens it into the live-tree >> representation. >> >> v2: Changed to save the dtb by copying into an allocated buffer. >> - Since the dtb will very likely be passed in the first 16k of ram >> where the interrupt vectors live, memblock_reserve() is >> insufficient to protect the dtb data. > > This is wrong. The vector page can be allocated anywhere. It is > currently allocated with memblock_alloc(), so if you memblock_reserve() > the dtb soon enough then it should be safe and the vector page or > whatever will be allocated somewhere else.
Ah, thanks. Did not know that. > What was the actual problem? I was seeing the first page in memory getting zeroed partway through the boot process which wiped out the dtb. I haven't yet narrowed down to the exact point that it gets overwritten. It is late enough that all the early setup dt code works, but before init_machine gets called. I'm also seeing a problem with /proc/device-tree getting corrupted on qemu which I cannot reproduce on Tegra hardware. Still investigating this one. g. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
