Re: [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