[coreboot] PCI IO Address space over 0xffff
joe.korty at ccur.com
Sat May 22 18:11:50 CEST 2010
On Fri, May 21, 2010 at 09:28:55PM -0400, Peter Stuge wrote:
> Joe Korty wrote:
> > I've solved this one, kind of. It is PCI IO Space
> > overflow, we are going over 0xffff which apparently is
> > a hard limit.
> What cards did you have in this expansion chassis? Would it be
> possible for you to provide lspci -vv output on that system?
> Does the system boot if the chassis is completely empty?
That particular expansion chassis load is no longer
accessible to me at the moment (sent elsewhere).
I'm pretty sure I can reconstruct it but I first have to
scrap up the parts.
The real problem is PCI-e bridges rounding everything up
to 4Kbyte boundaries. Doing this for IO space is a real
pain, it doesn't take very many PCI-e bridges (and every PCI-e
card seems to have a bridge within it) to make us go
over the 0xffff IO Space limit.
I saw each Quad Ethernet taking 8K of IO space. Thus it
doesn't take very many of these cards to fill up IO space.
The address space allocation (from /proc/ioports, from
memory) follows this pattern:
>From the rounding it appears that this pci-e board
internally has two pci-e busses, each with two ethernets,
perhaps fronted with a pci-e mux giving the board its
connection to the outside world.
> How do the chassis connect upstream, on PCI level? How does that
> upstream-facing component divide address space? Does it reserve
> a chunk for everything that can connect downstream? How big a chunk?
The PCIe bridges seems to be rounding everything to 4k
boundaries. I haven't found any documentation on what the
PCIe standards says that limit, if any, should actually be.
More information about the coreboot