[coreboot] Time for a new project

[Carl-Daniel Hailfinger]

On 13.04.2008 00:48, Jordan Crouse wrote:
> On 12/04/08 17:06 +0200, Carl-Daniel Hailfinger wrote:
>   
>>>> SELF is missing a per-section compression algorithm specifier
>>>>     
>>>>         
>>> Does it need one? Either the entire SELF is compressed, or not.
>>>   
>>>       
>> Uh, no. The SELF design says that only some SELF segments may be
>> compressed, others must not be compressed.
>>
>>     
>>> Again, LAR does the work. No?
>>>   
>>>       
>> See above. I wouldn't have complained that much if you were right.
>>     
>
> I'm going to address this, since it seems to be Carl-Daniel's main
> sticking point.
>   

Thanks for changing the wiki page. The compression situation is now a
lot more well-defined. Perhaps add something like "this segment has zero
length in ROM so compression does not apply" to the segment description
for BSS and ENTRY.

> One of the minor details of a "chooser" menu is that we need
> to populate the menu with sane and descriptive names.  We could just
> use the LAR "filename", but that is not very customer friendly.  
> Thats where the NAME segment comes from.   I think thats pretty clear
> to everybody.
>
> I expect that when bayou first comes up in chooser mode, the 
> first thing it is going to do is walk the LAR and locate all the payloads
> for its menu.  While its doing that, its going to also read the names
> for each of the payloads.  Forcing the entire SELF to decompress 
> for this simple act costs memory and is needlessly slow.  Compressing
> just the segment is silly (we're talking at most 15 to 20 bytes here),
> and it forces any payloads that want to examine the SELF files in the
> LAR to carry a de-compression alogrithm.  I also extended the same
> behavior to the .notes section, because I deemed that the payload may
> wish to store configuration information there, which would be silly
> to copy to memory if we didn't need to.
>   

OK.

> The data and code segments will be compressed with the LAR compression
> mechanism, if it happens to be specified (I will go back and correct
> the wiki page to make that clearer).  Yes, that does mean lzma headers
> per segment.  I'm okay with that, I think its worth the cost.
>   

Thanks. Can you add another format constraint? Each SELF segment should
be aligned to an 8 byte boundary. That will resolve the unaligned access
problem (and eliminate another one of my worries).


Regards,
Carl-Daniel