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