[coreboot] Flash ROM access during boot

Martin Roth gaumless at gmail.com
Mon Jan 23 05:57:19 CET 2017


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 at 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 at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list