[U-Boot] [uboot PATCH v2] Add uboot "fdt_high" enviroment variable

[David Long]

On Thu, 2011-07-14 at 20:53 -0600, Grant Likely wrote:

>You should have everything you need to fix it.  If
> CONFIG_SYS_BOOTMAPSZ is defined, then U-Boot will not use memory
> larger that that for the dtb or atags.
> 
> Right now CONFIG_SYS_BOOTMAPSZ is not set by default, but we could
> default it to a sane value for ARM platforms.

Which makes more sense, setting this or  Scott's suggestion of reserving
highmem to prevent it's use as is done in the powerpc's
arch_lmb_reserve()?  The latter would affect all ARM.  Wouldn't BOOTMAP
need to be set in each boards config file?



On Thu, 2011-07-14 at 16:51 -0500, Scott Wood wrote:

> Well, that does sound strange.  I'd think it would be based on whether you
> define CONFIG_SYS_BOOT_RAMDISK_HIGH, and whether initrd_high is set to
> 0xffffffff.


Same kernel, same u-boot, and initrd_high not set at all.  This is the
crux of the problem. The default changes when any FDT is provided.  I
think the difference may come from bootm_linux_fdt().

Rereading your earlier mail and looking at the code, we should probably
do as you suggest and add logic to arch_lmb_reserve() to reserve highmem
like powerpc does.  I think the fdt_high patch is still a good idea
though.  It allows us to continue booting using lowest memory for the
initrd and other startup data.


> Or were you just not telling bootm about the ramdisk before, and letting
> the kernel know about the address through some other means?



We always provide a ramdisk address to bootm.  The problem occurs when
we add an FDT address. 


> So add a mechanism for the user to override if you can justify a use for
> it, but the default should be allocated from an lmb that has had unusable
> addresses excluded.


Well, I do find it troubling I'm having to go to so much trouble to
convince u-boot to continue to use this data directly from where we put
it in the first place.


> > > The user specified address might be in flash.
> > 
> > But in our case it is not. 
> 
> It still needs to be supported.


I can appreciate that, but the default behavior has changed.   It's
surprising.  For the moment it breaks things (granted that it breaks
only if you use the  fdt feature).

-dl