[U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Ian Campbell <ijc@hellion.org.uk>]

Adding u-boot list since I think this is a general issue/question.

On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote:
> On 03/09/14 16:18, tyler.baker at linaro.org wrote:
> > On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler... at linaro.org wrote:
> >> Hello,
> >>
> >> I am trying to boot the cubietruck with a minimal ramdisk. However, it
> >> seems to hang at "Starting kernel..." whenever I pass bootz a
> >> ramdisk load address.
[...]
> > Turl help me solve this in IRC. Needed to setenv initrd_high 
> > '0xffffffff' in case anyone else runs into this.

> The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but 
> thanks for helping remind people!

Actually it mentions fdt_high but not initrd_high.

But what is the reason for the default behaviour of bootz doing things
which do not conform to linux/Documentation/arm/Booting and therefore is
not going to boot?

The docs recommend that DTB and initrd go just after the 128MB boundary.
If either are loaded "too high" then the kernel will crash on boot,
often in a tricky to diagnose way (I've chased it down more than once).
It's especially annoying when one has carefully loaded everything at a
suitable address in the first place ;-)

Should the global default be changed to either 0xffffffff (no
relocation) or to start-of-ram+256MB (which should satisfy the kernels
requirements without needing logic changes to handle "just after the
128MB boundary" as a concept).

Or is it intended that each board should opt-in to a sensible default
via their default environment?

Does bootm suffer the same? I suspect it does, at least for fdt (since
initrd has a load addr in the u-boot header).

Ian.