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

[Tom Rini <trini@ti.com>]

On Tue, Mar 11, 2014 at 10:38:05AM +0000, Ian Campbell wrote:
> 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?

Because U-Boot is more than just ARM, and ARM boards not enforcing /
getting the correct behavour via fdt_high / initrd_high or bootm_low /
bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ.

> 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 ;-)

I have as well, sadly.

> 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).

SoCs should set a sane and correct set of values, using either of the
available mechanisms.  I think Tegra gets this all correct via
CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts
as part of the generic distro work.

And keep in mind that when we set fdt/initrd_high to a non-0xffffffff
value we're setting a maximum that's still checked vs how much we have,
so setting base+512MB is probably a best default for cases where we may
run on boards with varying amounts of DDR.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140311/5d725124/attachment.pgp>