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