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

[Marian Balakowicz <m8@semihalf.com>]

Kumar Gala wrote:
> 
> 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:
>>
>> 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.
> 
> 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.

Correct me if I am wrong but my understanding is that it will not help
if the total size of the blob is too small.

It will just use/allocate free internal blob space - if the internal
free space is sufficient. And if it is it can be used at any time. If
it is not sufficient, then we need to grow the blob total size first.

m.