[coreboot] Notes on CBFS

Kevin O'Connor kevin at koconnor.net
Mon Apr 13 15:43:45 CEST 2009

On Sun, Apr 12, 2009 at 08:59:02AM -0700, ron minnich wrote:
> I'm fine with le32, although it may produce confusion in the future.
> People's fingers seem to want to type [nh]to[nh]. I don't see how
> ntoh* can cause so much bad code in seabios, but i want seabios to be
> happy, so a patch is fine too. Kevin, are you certain it's that big
> problem?

SeaBIOS works with it today, so it's not a "show stopper".  However,
it's annoying to work with, and I can't see any benefit to it.  I
noticed that coreboot isn't doing proper big-endian for the CBFS u64s
- I assume this was because it's annoying having to code up a proper
u64 bswap.

> Also, w.r.t. getting rid of the offset in the file header: one nice
> thing about that design is the file header and the file data need not
> be contiguous in the flash. It is a much more flexible setup. Again,
> given the small number of entries in a CBFS (certainly < 64), is the
> savings of < 512 bytes or so worth this change?

I hadn't realized that was a goal.  In order to do that though, it
would require the file searching code linearly search the whole flash
for files (which it does today).  This will make file scans slow - as
potentially the whole flash will need to be read in order to find the
last file.  (For example, if three files are in the CBFS - "payload",
"linux-kernel", "pci1106,3344.rom" - then the code would need to
completely read "payload" and "linux-kernel" from flash in order to
find "pci1106,3344.rom".)  I think documenting that header and
contents are together would allow for a speed improvement, because
then the file find code could skip scanning file contents.


More information about the coreboot mailing list