Part Number: AM5728
Tool/software: TI-RTOS
We are trying to demonstrate PCIe enumeration of a Sitara Processor AM5728 acting as a PCIe endpoint with a Linux computer acting as root complex. We are using a SOM manufacturer’s PCBA (phyCORE®-AM57x PCM-057) for this along with their carrier board (phyCORE-AM57x Carrier Board PCM-948) for this testing . Their schematic closely matches the TI reference design (both SOM and development board schematics are attached). We also are using the recommended PCIe male to male crossover PCIe cable (3” length) from Adex. The cable crosses the TX/RX lines, passes the REFCLK signals straight through
We first did a successful enumeration demo between two carrier boards with the clocks disconnected via a SMT jumper option on the ADEX PCIe jumper cable (Note each carrier board by default has their own clock generator and buffer ICs). We did this with the sample code named: PCIE_am572x_phycore_rdk_wSoCFile_armExampleProject (that was slightly modified for use with the Phytec SOM). One carrier board were running pre-built RTOS BSP configured as EP, and the other BSP-Yocto-TISDK-AM57xx-PD18.2.0 as RC. The demo software reports that link training succeeded, the correct number of lanes is seen (1) and the correct speed is detected (gen 2), and passed all tests and data xfers.
After reading the forums on TI’s E2E we knew that the spread spectrum nature of most Linux computers would not allow us to use the separate clock scheme used above. Because of this we reworked the carrier board to disable the on board clock generator and pass the clock from the boards PCIe connector onto the Sitara. We also added back the SMT jumpers we had removed before to this time pass the ref clock from one board to the next. We repeated the above demo with two carrier boards and were able show link training had once again succeeded, the correct number of lanes were seen (1) and the correct speed was detected (gen 2). Because of this demo we believe the rework is at minimum good enough to succeed at PCIe enumeration.
Using the, we repeated the above hardware configuration (2 carrier boards), this time one running Linux and acting as RC and the other running TI RTOS acting as the EP. With an >>lspci command through the pre-built RTOS BSP we were able to see the endpoint had been enumerated and had a string describing it as a non-vga unclassified TI device.
Our problem comes when we try to interface the carrier board acting as endpoint with a Linux computer (intel). Note the carrier board here is the one modified to pass the refclk signals from the PCIe connector directly through to the Sitara processor. The Linux computer (intel) does not properly enumerate it. Most of the time we see no acknowledgement what-so-ever of there being anything plugged in on the Linux computer. Other times we’ve seen the PCIe slot show up with no identification string. We’ve never had a successful test which shows the equivalent of what was seen in the paragraph above: non-vga unclassified TI device. On the EP we run a terminal that announces the link training state we are stuck in if link training doesn’t initially succeed. It updates every 100ms (again only if training failed). If training passes the debug console continues giving output – ultimately ending with if the correct number of lanes and speed were sensed. We’ve never seen indication on the EP (when interfacing with the intel computer) that the link was established. This includes when the Linux computer (intel) lists the PCIe port the EP is connected to with no identification string.
I need to complete link training and enumeration with a AM57x (TI-RTOS EP) -> PC (Linux RC), so that the AM57x will show up under >lspci. My understanding is that there are no additional drivers needed on the Linux PC side to accomplish this task, and that this is an electrical and connectivity problem (and possibly configuration on the AM57x).
