[coreboot] CBFS transition plan

Myles Watson mylesgw at gmail.com
Wed May 6 03:47:53 CEST 2009

> -----Original Message-----
> From: Kevin O'Connor [mailto:kevin at koconnor.net]
> Sent: Tuesday, May 05, 2009 6:45 PM
> To: Myles Watson
> Cc: coreboot
> Subject: Re: [coreboot] CBFS transition plan
> On Tue, May 05, 2009 at 09:13:32AM -0600, Myles Watson wrote:
> > 3. PCI ROM optimization.  There should be some optimization for ROMs.
> >     a. Possibilities:
> >         1. Traverse ROM once and set a flag in devices which have ROMs
> >         2. Traverse ROM and keep a list of ROMs
> >         3. ....
> Are you referring to the email I sent on the time SeaBIOS spent
> traversing CBFS to find option roms?

I'm referring to the cost if CBFS can be sparse.  I'm also referring to the
number of scans required for some hardware.  My Opteron boxes have many
onboard devices, so there are 20+ CBFS scans.

> I did modify SeaBIOS so that option roms scans are much faster.  (The
> cost is now negligible.)  I accomplished this by ending the file scan
> if a signature of zeros is found.

That only works if CBFS files are contiguous.

> I don't think caching the list of files in the flash will work well -
> even one brute force scan will take too much time on large flash
> chips.  Instead, I think CBFS needs to have an orderly layout of files
> which doesn't require users to do a brute force scan.
> I think there's a simple way to accomplish this - have cbfstool create
> "null" files that contain all the empty space.  Then the users of cbfs
> (eg, coreboot, seabios) wouldn't need any special code - they would
> skip them just like they skip over any other file.

I could see that working.  It was zero-fill in v3 lar.


More information about the coreboot mailing list