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

[Marian Balakowicz]

Marian Balakowicz wrote:
> Kumar Gala wrote:
>> 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.
> 
> But we don't really grow the blob, we are just allocating the space for
> the initrd properties - *if* the blob already has enough free space. If
> the blob does not have enough free space we'll hit the bottom anyway,
> whether in fdt_chosen() or ft_board_setup(), so it seem that it doesn't
> matter whether we pre-allocate space for initrd or not. Or am I missing
> something?
> 
> I was rather thinking of increasing the total blob size when relocating
> it. Currently relocation happens only when the blob is not within
> BOOTMAPSZ region, so we would need to always relocate the blob and
> figure out the size delta: (1) get it from env variable, if set (2) or
> use some default delta. What do you think?

Also, for the blob growing changes it would be nice to first merge your
LMB patches to sort out the memory allocation. I didn't have a time to
review your changes in detail but it's definitely step in the right
direction. Current bootm allocation is pretty messy, I cleaned it a bit
but didn't want to touch too many pieces at the same time. For the same
reason I would like to finish the current patch I am working on that
adds dual format framework before we add LMB and dynamic blob growing.

m.