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

Kumar Gala
2008-02-26T14:31:01Z

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.

We can cleanup the fixup once we have better support for dealing w/the
sizing of the fdt.

- k