[coreboot] LAR TODO

[Carl-Daniel Hailfinger]

On 19.02.2008 16:48, Patrick Georgi wrote:
> Am Dienstag, den 19.02.2008, 16:07 +0100 schrieb Stefan Reinauer:
>   
>> Drop entry and load address out of the LAR format. Instead, we define
>> a
>> "coreboot native blob format" which looks like the following and pack
>> it _into_ the lar.
>>
>> +--------------------+
>> | MAGIC              |
>> +--------------------+
>> | Entry              |
>> +--------------------+
>> | Number of Segments |
>> |    (consecutive)   |
>> +--------------------+
>> | SEGMENT 1/n        |
>> | +----------------+ |
>> | | Load Address   | |
>> | +----------------+ |
>> | | Len (needed?)  | |
>> | +----------------+ |
>> | | Compress. Type | |
>> | +----------------+ |
>> | | Data           | |
>> | |                | |
>> | +~~~~~~~~~~~~~~~~+ |
>> +--------------------+
>> |      ....          |
>> +--------------------+
>> | SEGMENT n/n        |
>> | +----------------+ |
>> | | Load Address   | |
>> | +----------------+ |
>> | | Len (needed?)  | |
>> | +----------------+ |
>> | | Compress. Type | |
>> | +----------------+ |
>> | | Data           | |
>> | |                | |
>> | +~~~~~~~~~~~~~~~~+ |
>> +--------------------+
>>     
>
> This gives essentially two layers of archive format, lar and
> executable-file.
>   

I don't like the layered ide very much.


> How about doing segments per file (like right now), and simply
> prepending their data "section" with the load address (as they already
> get special treatment anyway).
>   

What does that buy us except a header format change which essentially 
moved the loadaddr header field to the end of the header?


> The entry point could end up in a file "entry", 4 bytes large,
> containing nothing but the address to jump to.
>   

Bad idea, sorry. That increases boot time by one LAR lookup which can be 
very costly in the worst case.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/