From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 11 Mar 2014 09:48:09 -0400 Subject: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck) In-Reply-To: <1394534285.18366.25.camel@kazak.uk.xensource.com> References: <8c845410-b511-4866-85ac-ab0a2ec77610@googlegroups.com> <531CBA3E.8050507@schinagl.nl> <1394534285.18366.25.camel@kazak.uk.xensource.com> Message-ID: <20140311134809.GN16805@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: