On Sat, Mar 26, 2011 at 9:33 AM, Tixy <t...@yxit.co.uk> wrote: > On Fri, 2011-03-25 at 22:46 -0600, Grant Likely wrote: > [...] >> It appears that when U-Boot >> relocates the .dtb, it either moves it to a location that the kernel >> cannot read during early boot, or it corrupts it when it is moved. >> Either way, the kernel is hooped when it tries to parse the device >> tree data, it falls back to the old ATAGs support, but there aren't >> any ATAGs either so it cannot actually boot. > > I didn't appear to have any problems with dtb relocation on a > beagleboard. It does get put at the bottom of RAM just before the > kernel, are there things down there like initial stacks or command-line > args that could corrupt the dtb?
No, the dtb replaces the command line and other ATAGs, so no worries there. The initial stack is much higher in RAM, and the initial page tables start at 16k from the base of ram. The beagleboard sets CONFIG_SYS_BOOTMAPSZ to the first 16k or RAM which is an obsolete limitation and the kernel can handle the dtb located anywhere in RAM. I've got a couple of patches that eliminates the requirement to set CONFIG_SYS_BOOTMAPSZ, but in the current code that means it tries to relocate the dtb to the end of RAM which doesn't seem to work. Relocating to a lower address works fine from my testing. >> I've got it working at >> the moment by hacking u-boot to /not/ relocate the .dtb blob which >> gets me much farther, but it also looks like it also causes problems >> with the initramfs image. It currently has an oops when it cannot >> mount the initramfs. Still investigating... > > Thanks for posting to the mailing lists. I was just about to start > tackling the off-by-one ramdisk sizes when I thought I'd check the list > to see if anyone had been there before me :-) :-) The tree I posted as a reply to the Device Tree on ARM status report email shows my current trees. There were 2 initrd off-by-one bugs, one in the kernel and one in u-boot. Both are fixed in my tree. g. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
