Adding onto what others have said:
The additional accesses you're seeing are the cbfs searches for additional ROMS and configuration data.
I don't think that it would save much time if we cached the cbfs locations and filenames, but it's possible that it might save a very small amount. I doubt that it's worth the added complexity though.
Since we generally only read the files from the ROM once, even if we knew exactly which bits we were going to need, it doesn't save any time to pre-load the pieces into memory.
Martin
On Sat, Jan 21, 2017 at 11:03 PM, Andrey Petrov andrey.petrov@intel.com wrote:
Hi,
On 01/21/2017 02:30 PM, Paul Menzel via coreboot wrote:
Dear coreboot folks,
Playing around with the trace feature of the Dediprog EM100Pro, I noticed several flash ROM accesses until the payload is loaded.
Are there ways or strategies to preload the whole flash ROM chip content into memory for faster access right after RAM is set up for example? What does that depend on? Does that make any sense at all?
preloading whole flash is a bad idea, because you have to pay upfront IO cost for whole-flash read. And then most of that is going to be wasted anyways, because you likely need only parts of the flash at that point.
On Apollolake at least, SPI hardware sequencer has some internal cache and when combined with regular CPU cache (just set MTRRs to cover memory mapped SPI flash) seems to work effectively. There was an issue we found recently where ramstage never cached mmaped BIOS area but that was addressed swiftly.
What you could do is to pre-populate cache with flash data right before it is going to be used. So you could read just a byte from each page of memory-mapped payload, and cause spi hardware to read the whole page in 'background' due to work of prefetchers. This may be useful if you are at the last stages of ramstage and doing PCI device IO and waiting/spinning. So by the time you want to load payload it is already "preloaded" in the cache.
However on apollolake grand total for IO is less than 100ms and even less for payload so I suspect benefits from such hack are going to be pretty small.
Andrey
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot