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.
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).
The entry point could end up in a file "entry", 4 bytes large, containing nothing but the address to jump to.
I think, that approach would be even simpler, while still keeping the advantages of your proposal.
Regards, Patrick Georgi