[U-Boot-Users] [PATCH v2] [new uImage] ppc: Re-order ramdisk/fdt handling sequence

[Marian Balakowicz <m8@semihalf.com>]

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.