On Thu, 14 Jul 2011 17:20:53 -0400 David Long dave.long@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