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

[Tom Rini]

On Mon, Mar 17, 2014 at 03:29:44PM +0000, Ian Campbell wrote:
> On Mon, 2014-03-17 at 11:20 -0400, Tom Rini wrote:
> > 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.
> 
> You are dropping fdt_high=0xffffffff here, is that deliberate?
> 
> I suppose this is offset by the addition of bootm_size which keeps
> things working? (or does it, I'm very confused now...)

Intentional and confusing.

> > > > 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.
> 
> I'm glad it's not just me!
> 
> >   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.
> 
> Right, I don't think I want to add any weirdness, unless all the cool
> kids are going to be doing it of course ;-)
> 
> > I'm going to whack at this more..
> 
> Thanks. I think for now with this series I can just set BOOTMAPSZ to
> 256MB without making this problem any better or worse and we can fixup
> things later in whatever is determined to be the right solution. Is that
> OK with you?

Yes, you can do that for now and I'll bounce ideas off you in v2 of the
TI series at least..

-- 
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/420930fc/attachment.pgp>