On L, 2009-04-18 at 23:05 -0400, Kevin O'Connor wrote:
On Sat, Apr 18, 2009 at 09:14:06PM -0400, Kevin O'Connor wrote:
The biggest SeaBIOS time consumers:
[...]
425ms - scanning for option roms
I tracked this one down - it's the cost of CBFS and reading the flash. Of the 425ms, 90ms is spent copying the via vga rom. The remaining time is spent doing CBFS searches - there are 18 pci devices on this machine and for each one SeaBIOS scans CBFS for "pciVVVV,DDDD.rom". Because none of these files were actually present, SeaBIOS ended up walking all the flash freespace each time. All those flash accesses add up.
Is there no zero-fill with cbfs? With LAR if I don't zero-fill (add a dummy entry to fill up the remaining space, the content is actually 0xFF's despite the term) it will also walk all the flash free space. Observing roughly 1 sec vs 4 sec boot times with and without zero-fill - I need to make a proper measurement, and this kind of tools that you and Peter have written were exactly what I was missing for doing that!
In coreboot-v3 there's a Kconfig option to zero-fill, but as I have to manually add the Geode VSA blob, I have that disabled and do it manually as described in http://www.coreboot.org/Artec_Group_DBE62 However I don't think zero-fill was even the default option in v3.
Maybe you can do zero-fill entry for cbfs too similarly. I believe Carl-Daniel mentioned CBFS doesn't fix that problem either and shares the gotcha with LAR at the moment still.
Regards, Mart Raudsepp
260ms - initializing ATA drives
I wonder if I can skip the ATA reset on the first boot - the device should have just gone through a hw reset anyway...
-Kevin