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@linaro.org wrote:
On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@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.