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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
