I am trying to implement full PCIe support for Windows CE BSPs, including bridges. My specific hardware is PLX 8606.
My references are:
- FSL documentation (IMX6DQRMr2 part1 and part2)
- Linux implementation for PCI bus enumeration
- PCIe implementation for x86 BSPs on Windows CE platform
- PCI.ORG documentation
From the very beginning I detected two problems in OAL support:
- Only BDF 0:0:0 is accepted, all other are rejected. I corrected that.
- When 0 bytes are read, OAL fills up the entire configuration structure with FFs thus simulating multi-function device and causing PCIBus driver to look up phantom functions. I corrected that, too.
I followed the ideas of Linux implementation for traversing PCI bus beyond the bridge, but this fails. I can only see the configuration of the 8606 bridge.
PCI controller is initialized in Root Complex mode, but its class code is "undefined" initially, setting up that configuration was my first step.
I have a few questions regarding this development.
1. Linux code sets up RC as PCI bridge (0604, rev. 0) and treats the configuration space as Header Type 1. This includes addr. 0x3C which in IMX6DQRM is described as PCIE_RC_EROMMASK.
Is this correct, or changing EROMMASK just happens to be inconsequential because EROMBAR is disabled?
2. Linux sets up BAR0 and all BLRs with specific values. I can hard-code same values in IO, MEM, PREF_MEM as well, but I could not deduce how these values are calculated.
Does they depend on the BARs of the bridge, and if not -- what would be the right method to calculate them? Writing FFs only brings back the masks and these masks allow very broad ranges.
3. Linux sets up ATU.0 for BDF 0:0:0 in "...\arch\arm\mach-mx6\pcie.c", but later some other module changes iATURLTA to BDF 1:0:0.
I could not locate that part of the code in the sources -- any help on it?
4. So far, I can only see the configuration space for the first device -- the bridge. Even if there are no more devices on bus 0, I am getting response for all BDFs 0:x:0; the whole 64KB mapped configuration space are populated with repeated blocks.
Is there way to determine from the Configuration Space Header whether a device truly exists, when for example BDF 0:1:0 is requested?
5. And at the end, when the bridge is pre-configured and the time comes to traverse it, I write to iATURLTA new BDF 1:0:0 and read the bus using the address of the already mapped configuration space at 0x01F00000.
Yet in it the VID/PID of the bridge only shows. Do I need to map another memory space from bridge's BARs to get the info for downstream devices?
Sharing the experience for Linux Kernel PCI support is valuable, even if there is no direct correspondence between that Kernel and OAL in WEC7.