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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
