On Feb 26, 2008, at 3:11 AM, Marian Balakowicz wrote:
Kumar Gala wrote:
On Feb 22, 2008, at 11:08 AM, Marian Balakowicz wrote:
...
If we add LMB and rework bootm memory allocation, putting things (kernel, cmdline, kdb, initrd (optionally), fdt) in sequence starting from bootm_low then we may want to always relocate fdt to avoid overlapping. And, in case of new uImage FDT blob will be embedded in a new uImage shell which is a blob itself. So, in this case in-place resizing is not really a clean option, we would need to resize the embedding new uImage blob first, and this one may have significant size, so I suspect it may impact performance.
I felt the sequence (on PPC) is either: kernel, cmdline, kdb, initrd
or
kernel, fdt, initrd
The reason being is that initrd doesn't need to be constrained to BOOTMAPSZ but cmdline, kdb, and fdt would/should be.
That's right.
My point was just to have two steps:
- Move all the stuff to the final locations (whatever the sequence)
kernel
fdt - *always* relocate to within BOOTMAPSZ, increase size
dynamically.
fdt blob can be delivered using of the three different methods: (1) raw fdt blob, (2) fdt blob embedded in legacy format uImage, (3) fdt blob embedded in new uImage format. To simplify things always relocate it to a allocated spot within BOOTMAPSZ.
- initrd - within or outside of the BOOTMAPSZ boundaries
- Update fdt blob, knowing we have enough free blob space: set initrd
params, other fixups, etc.
With such approach we don't need special treatment for initrd,start/initrd,end (and other fixups). We assure that there is enough free space in fdt blob when we relocate it.
How we get the fdt blob doesn't matter as much as its size. At this point we still don't know how large it might need to be. I think the changes I made make sense in that we'd want to process the majority of the fdt before we do anything w/the initrd.
We can cleanup the fixup once we have better support for dealing w/the sizing of the fdt.
- k