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

[Kumar Gala]

On Feb 18, 2008, at 1:46 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> On Feb 18, 2008, at 1:15 PM, Jerry Van Baren wrote:
>>> Kumar Gala wrote:
>>>> On Feb 18, 2008, at 11:51 AM, Jerry Van Baren wrote:
>>>>> Kumar Gala wrote:
>
> [[[[snip]]]]
>
>>> The patch is creating dummy initrd entries in the reserved map and  
>>> in /chosen, only to work hard to delete and re-create the reserved  
>>> map entries and rewrite the /chosen entries.
>>>
>>> My counter-proposal is to not bother with dummy values.  Simply  
>>> pass in 0,0 which will prevent the creation of the initrd entries  
>>> by fdt_chosen().  By not creating dummy entries, you can simply  
>>> create the proper entries once you know what the the correct  
>>> values are, rather than the more complicated rsvmap search &  
>>> delete + rsvmap creation + /chosen modifications.
>> Ahh, the reason I wanted them created was to ensure we have enough  
>> size for them up front rather than figuring that out later.  By  
>> creating them and replacing them I will not being changing the size  
>> at all.
>> - k
>
> OK, I see.
>
> Currently this isn't an issue because our blob has a fixed size that  
> has free space inside it, so creating the rsvmap and /chosen entries  
> eat at the internal free space and don't change the total blob size.
>
> People are advocating dynamically increasing the blob size, which  
> simplifies things for blob generation (don't have to guess how big  
> to make the blob when running the dtc to create it), but that would  
> cause problems with my counter-proposal.

And the whole point of my patch was to enable the ability to  
dynamically grow the blob before we do anything w/the ramdisk.

- k