[coreboot] Random extra option ROMs in CBFS

Patrick Georgi patrick.georgi at coresystems.de
Thu Apr 30 16:23:20 CEST 2009

Am 30.04.2009 16:03, schrieb Myles Watson:
> On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauer<stepan at coresystems.de>  wrote:
>> With all the infrastructure in the CBFS format, I think encoding duplicate
>> information in the file names is not an appropriate approach. Instead the
>> existing infrastructure should be used.
> Care to elaborate?  I don't see ordering information or whether the
> ROM returns in CBFS.
Option Rom support is, for now, incomplete (eg. no subheader). The 
subheader will contain at least a compression flag and vid/did fields 
(for faster lookup, and to free the name field for more useful purposes, 
eg. keeping the vendor filename which includes a version number).
We could add an order field there, or pick an invalid vendor ID (0x0000 
and 0xffff seem to be free, and esp. the latter likely won't be used at 
all, as it looks like a read in empty I/O space) and order them by 
device ID. coreboot or the payload would iterate PCI, then run through 
the device ids (with did=0 being executed first).

CBFS has rich metadata for its objects. If we don't use it, and stuff 
everything in the filename, we could as well use ar(1) and the system's 
tools (with all the trouble that brings, eg. with slightly incompatible 
lzma implementations and the like), and spare us the trouble of 
maintaining our own tool.

We're not on unix. Not everything is a file for coreboot (neither for 
unix, but that's a different discussions).


More information about the coreboot mailing list