On Thu, 2011-07-14 at 15:21 -0500, Scott Wood wrote:
You have memory below where the kernel is loaded?
Our boot script loads the kernel 2MB into physical RAM. It loads the initrd and fdt from the same NAND flash file system into RAM below that. 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).
This splits memory into three, instead of two regions in the kernel. I don't think that split ever goes away. Then there's the additional region we already have to create for the Ducati memory. That's at least five memory regions total. There are only eight regions currently allowed by default. I don't have a feel for the implications of this, but it seems unnecessary.
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. It just seems a bad idea to create more holes in the middle of physical RAM unless we really have to. 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. Seems to me it'd be uglier than the fdt_high approach. Maybe I'm missing something though. I'm certainly not a VM expert.
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. And we're now being relocated when we did not get relocated prior to FDT functionality.
-dl