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

[Scott Wood]

On Thu, 14 Jul 2011 17:20:53 -0400
David Long <dave.long at linaro.org> wrote:

> When we boot without specifying an FDT, u-boot does not relocate the
> initrd.  When we specify an FDT address in RAM, u-boot relocates both.
> We do not need that relocation (in this case at least).

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.

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

> > What do you mean by a "region" here, and why can there only be eight of
> > them?
> 
> Functionally identical and contiguous sections of RAM recorded in the
> Linux global meminfo data structure, and (mostly) operated on in code
> found in arch/arm/mm/.  There's a define that sets the size of this
> array to 8.  Again, I don't know the implications, if any, of having
> several versus a couple of these banks/regions. 

I don't think we have this kind of thing on powerpc.  We track unusable
regions with lmb, based on things like the dtb memreserve list.

> It just seems a bad idea to create more holes in the middle of physical
> RAM unless we really have to.

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.

> Plus, we have to inform the kernel about them somehow.  I
> don't have a clear idea how we would do that in a clean way.

I don't know how ARM does it, but on powerpc the kernel is told about the
initrd/initramfs address range through the device tree, and the device
tree address is in r3 on entry.  The device tree blob is also marked
reserved in the dtb memreserve list.

The initrd/initramfs doesn't appear to be marked reserved, probably since
the kernel had ways of avoiding that region since before flat device
trees and memreserve came along.

> > > Again, I don't think the problem is where u-boot relocates this data
> > > TOO, but the fact that the new default is to relocate it at all.  Is
> > > there a reason for relocating this stuff?  The initrd always used to be
> > > happy left where it was.
> > 
> > The user specified address might be in flash.
> 
> 
> But in our case it is not. 

It still needs to be supported.

-Scott