Re: PCIe enumeration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux