[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>]

On Tue, 2014-03-11 at 09:48 -0400, Tom Rini wrote:
> On Tue, Mar 11, 2014 at 10:38:05AM +0000, Ian Campbell wrote:
> > 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.

So you consider this to be a board level problem, rather than an arch
level one? (IOW we can't just fix this for all arm boards at once)

[...]
> > 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.

I took a look at BOOTMAPSZ on sunxi and it is using (16 << 20) which
seems sensible, if a bit small, so perhaps something else is going
wrong.

Tegra uses 256MB, might be worth giving that a go I guess.

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

I'm not sure I follow -- why is +512MB best?

Thanks,
Ian.