On Monday 16 November 2009 08:40:49 am Thierry Reding wrote: > I have a setup where an FPGA is connected to a PCIe port. The FPGA itself > acts as a bridge and forwards PCI requests to some user logic that in turn > simulates multiple PCIe endpoints. The communication between the root complex > and the user logic works fine and all endpoints are visible to the BIOS and > Linux later on. > > One problem that we're facing now is that during PCIe enumeration, the BIOS > seems to correctly allocate and assign resources for all endpoints, but only > if all BARs are designated prefetchable. > > If the BARs are configured as non-prefetchable, however, the BIOS still seems > to allocate and assign resources correctly, but after the first assignment of > base addresses, it decides to overwrite these with 0, except for the very > first endpoint. Now when Linux comes up it reads those BARs and decodes them > again, then writes the original 0 back. Therefore when the BARs are marked > non-prefetchable, all endpoints except the first end up unusable in the > system. > > Does anyone have an idea what might be going on here? Is there some > restriction in PCIe that may be causing this behaviour? I've been going > through the specification looking for clues but so far haven't come up with > anything. It would be interesting to know what your host bridge apertures are and how much space your BARs require. It's possible there just isn't enough address space to configure those non-prefetchable BARs. Most PCIe devices are behind a root port or other PCI bridge. These bridges only have 32-bit non-prefetchable apertures, which means the non-prefetchable BARs of those PCIe devices all have to fit below 4GB. PCI bridges can have 64-bit prefetchable apertures, so there's a lot more address space available for devices with prefetchable BARs. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
