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..