[U-Boot] [PATCH v1 8/9] sunxi: non-FEL SPL boot support for sun7i

[Tom Rini <trini@ti.com>]

On Sun, Mar 16, 2014 at 04:45:57PM +0000, Ian Campbell wrote:
> On Sun, 2014-03-16 at 15:19 +0000, Ian Campbell wrote:
> > On Fri, 2014-03-14 at 15:03 -0400, Tom Rini wrote:
> > > On 03/14/2014 02:50 PM, Hans de Goede wrote:
> > > > Hi,
> > > > 
> > > > On 03/14/2014 03:17 PM, Tom Rini wrote:
> > > >> On Fri, Mar 14, 2014 at 10:33:50AM +0000, Ian Campbell wrote:
> > > >>
> > > >>> Based linux-sunxi#sunxi commit d854c4de2f57 "arm: Handle .gnu.hash section in
> > > >>> ldscripts" vs v2014.01.
> > > >> [snip]
> > > >>> +/* Flat Device Tree (FDT/DT) support */
> > > >>> +#define CONFIG_OF_LIBFDT
> > > >>> +#define CONFIG_SYS_BOOTMAPSZ		(16 << 20)
> > > >>
> > > >> This seems pretty small.  This is to keep things from being relocated
> > > >> into highmem right?
> > > > 
> > > > Hmm, this reminds me that we currently need to do a "env set fdt_high ffffffff"
> > > > in our boot scripts to get ftd to work at all. Would be nice to fix this for
> > > > upstream. I'm afraid I'm clueless as to why we (sunxi) need it, but we do.
> > > 
> > > You want to be setting bootm_low (even for bootz, it's about the
> > > underlying boot mechanics that bootz and bootelf and ... hook into) to
> > > the amount of lowmem the kernel will have.  We do this because we do
> > > want to make sure that the device tree isn't overwritten by the kernel
> > > BSS or similar.  Everyone with more DDR than kernel lowmem needs to be
> > > doing something along these lines.
> > 
> > So, I'm confused about what to do here ;-)
> > 
> > AFAICS none of the existing platforms in u-boot.git are setting
> > bootm_low in their default environment.

Yes.  http://patchwork.ozlabs.org/patch/329210/ gets things right for
some subset of TI platforms and I'll be picking that up soon.  Or maybe
a v2.

> > README suggests that bootm_low is the lowest address allowed for use by
> > bootm/z rather than the limit, from the docs it seems that
> > CONFIG_SYS_BOOTMAPSZ (overridden by env bootm_mapsize) is the limit
> > 
> > bootm_low defaults to CONFIG_SYS_SDRAM_BASE, which sunxi sets, and this
> > seems logical to me since kernel's lowmem mapping starts at offset 0
> > into RAM.
> > 
> > I think we probably do want to set BOOTMAPSZ to something like 256MB,
> > which seems to be the highest in tree (although the vast majority use
> > 8MB...). But I'm not sure that explains why fdt_high is needed today.
> > I'll have a play.
> 
> So setting BOOTMAPSZ to e.g. 256MB limits the fdt load address as you
> would expect.
> 
> But it seems to not make any difference for the initramfs which still
> gets loaded to the top of RAM. This is consistent with README which says
> that unless initrd_high is set the ramdisk will be loaded as high as
> possible, without reference to BOOTMAPSZ. Supposedly setting initrd_high
> to "no", "off" or "0" should cause initrd relocation to obey BOOTMAPSZ
> -- but at least in my experiments it does not seem to do so.
> 
> boot_ramdisk_high() doesn't seem to make any reference to
> bootm_{low,size,etc} like I would expect and with initrd_high==0 it
> calls lmb_alloc which allocates anywhere. This is in contrast with
> boot_relocate_fdt which uses getenv_bootm_mapsize() and
> getenv_bootm_low().
> 
> It looks to me like the initrd reloc logic is wrong -- but it's been
> that way for such a long time I think I must be mistaken.

I think after reading what you're saying, things are very unclear,
unfortunately.  What you can do, but is very odd after thinking about it
is if you set bootm_low only and not any of the size things, it works as
a constraint on the upper bounds so initrd nor fdt are put above that.
But that's really seeming like a side effect rather than an intent.  I'm
going to whack at this more..

-- 
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/20140317/4386b7e9/attachment.pgp>