[coreboot] PCI IO Address space over 0xffff

[Joe Korty]

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?

Hi Peter,
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:

	a000-a01f
	a020-a03f
	b000-b01f
	b020-b03f

>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.

Regards,
Joe