[coreboot] unrv2b delay (v2)

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Oct 30 23:52:19 CET 2008

On 30.10.2008 23:33, Marc Jones wrote:
> Stefan Reinauer wrote:
>> On 30.10.2008, at 15:03, Marc Jones <marc.jones at amd.com> wrote:
>>> I think that this is in all K8 and fam10 disable_car code.
>>> The copy to memory is probably good. Running from the rom and
>>> decompressing from the rom is going to thrash. It may affect some
>>> cpu/chipset combinations more than others.
>>> Marc
>> So what's the reason for that?
> off the top of my head:
> 1. ROM access speed: lpc and or spi may be run at different speeds.
> (faster on some platforms)
> 2. domain crossed - ht -> maybe pci/pcie -> pci/pcie -> lpc ( less is
> better)
> 3. prefetch and code alignment. Being a few bytes off can cause and
> prefetching to thrash.
> It shouldn't thrash as bad if the ROM is being cached but I am not
> sure that it is or that it is setup correctly.

A system using SPI for its ROM at the usual speed without caching has a
per-byte latency of ~3 microseconds.
That translates to per-instruction latencies of roughly 6 microseconds
for simple instructions accessing data in the ROM. That's roughly 500
times slower than an instruction in I-Cache accessing data in RAM.



More information about the coreboot mailing list