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

Kumar Gala galak at kernel.crashing.org
Wed Feb 27 15:58:42 CET 2008


On Feb 27, 2008, at 5:20 AM, Marian Balakowicz wrote:

> 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.

At this point in time you are correct.  However I'm looking forward to  
having the possibility of growing things w/regards to the fdt.

- k




More information about the U-Boot mailing list