On 03/11/14 11:38, 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, [email protected] wrote:
On Sunday, March 9, 2014 8:06:27 AM UTC-7, [email protected] 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.
That is new to me ;)

I think it was discussed in depth as to why and what, but I forgot everything about it :p (been 5 or 6 months!)

http://irclog.whitequark.org/linux-sunxi/search?q=fdt_high

Should give a reasonable overview, only 20 or so entries for 2013 + 2014.

Olliver

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.


--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to