[coreboot] Random extra option ROMs in CBFS

Myles Watson mylesgw at gmail.com
Thu Apr 30 16:34:28 CEST 2009


On Thu, Apr 30, 2009 at 8:23 AM, Patrick Georgi
<patrick.georgi at coresystems.de> wrote:
> 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.

I think this is overkill.  I think file names are intuitive and
obvious.  Just because there are problems with using system tools
doesn't mean we should create new problems.

Adding special support to the Option ROM header for extra drivers that
are not option ROMs is ugly.

Thanks,
Myles




More information about the coreboot mailing list