[coreboot] v2 resource allocator strangeness

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Mar 20 01:14:06 CET 2009


Almost three years ago, I stumbled over an oddness in the resource
allocator for bridges. Back then, multiple people on this list told me
that the behaviour was expected and intended. Although I didn't
understand why such behaviour would be intended, I decided not to ask
for a more detailed explanation to avoid embarrassment.

Fast forward to today. I'm still seeing the oddness and I no longer
believe that it is intended or wanted.

00:04.0 PCI bridge [0604]: ATI Technologies Inc Device [1002:7914]
(prog-if 00 [Normal decode])
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: fff00000-000fffff
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff

The pattern looks like this:
If there is no I/O, Mem or PrefMem behind a given bridge, the base for
the given resource will be set to 0xffffffff (subject to truncation for
always-zero bits), the limit will be set to 0x00000000. The upper 32
bits of memory resources are always being set to 0.

Is that behaviour suggested/mandated by the PCI standard? I have access
to printed copies of that standard, so I can look it up if I know where
to look.

It seems that many BIOS versions out there always fill in the registers
with something, even if that type of resource does not exist behind the
bridge.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the coreboot mailing list