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:
1) 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
2) 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.
m.