On 19.04.2009 07:02, Mart Raudsepp wrote: > 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. >
Not yet. > I believe Carl-Daniel mentioned CBFS doesn't fix that problem either and > shares the gotcha with LAR at the moment still. > Replace CBFS with zerofilled LAR and the problem will go away without having to code another feature. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
