[coreboot] Time for a new project
c-d.hailfinger.devel.2006 at gmx.net
Sun Apr 13 01:14:35 CEST 2008
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.
> 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).
More information about the coreboot