This lane was used on an M2 E connector on the the devkit (so I use the default pinmux and gpio and device tree nodes). In my use case I would like to connect it to a Epix Pixci H2FL (this is a commonly used frame grabber, from its data sheet it does not require power on the pcie port side, I supply the grabber by a 12V from an other PSU). When I debug it from my custom linux the following messages appeared in the log.
[ 8.522707] tegra194-pcie 14100000.pcie: Using GICv2m MSI allocator
[ 8.530726] tegra194-pcie 14100000.pcie: host bridge /pcie@14100000 ranges:
[ 8.537905] tegra194-pcie 14100000.pcie: IO 0x0036100000…0x00361fffff → 0x0036100000
[ 8.554361] tegra194-pcie 14100000.pcie: MEM 0x2428000000…0x242fffffff → 0x0040000000
[ 8.563046] tegra194-pcie 14100000.pcie: MEM 0x2140000000…0x2427ffffff → 0x2140000000
[ 9.680713] tegra194-pcie 14100000.pcie: Phy link never came up
For the sake of hardware debug I try to measure the clk on the pcie clk lane p and n in this case the frame grabber its never showed 100 MHz. On the other hand I get a wifi card too for testing mini PCIe hardware side (intel centrino advanced-N 6205). This wifi module came up automatically in the slot and I could program it and try to join to wifi network (lspcie showed up and i can start config wlan0). In this case I could measure the 100 MHz on the PCIe CLK N lane.
I don’t really get it where my project fail. In case of wifi modul its appears as a working hardware and Linux OS. In case of the frame grabber its nothing (with the same setup). Also we test this frame grabber with an AGX Orin devkit with PCIe to mini PCIe adapter and its working fine (with and without powering the PCIe port).
We tried these debug methods already, could you help me locate the problematic part? Is it in hardware or in Linux configuration side? We already tried this frame grabber with the Orin devkit-s 16x pcie slot (with a PCIe to mini PCIEe adapter) and we think about presence signals. Or maybe the difference betwen normal PCIe and mini PCIe.
And when we pluged in a wifi modul, its worked fine too! (so maybe the hardver is right??)
As I wrote in the main article above, we test the same from port (mini PCIe on carrier) with a wifi modul from intel and its came up on the PCIe bus and we can program it. But with a Epix frame grabbers mini PCIE port we could achieve this. I wrote this down in the first part please refer to that.
“For the sake of hardware debug I try to measure the clk on the pcie clk lane p and n in this case the frame grabber its never showed 100 MHz. On the other hand I get a wifi card too for testing mini PCIe hardware side (intel centrino advanced-N 6205). This wifi module came up automatically in the slot and I could program it and try to join to wifi network (lspcie showed up and i can start config wlan0). In this case I could measure the 100 MHz on the PCIe CLK N lane.”
From software aspects, this means software side is correctly configured.
I think from hardware aspect they would say the same too.
I also wonder what did you try from the debug tips in document. There were also cases that some users told us “yeah I tried”, but turned out they tried nothing because they don’t know how to….
It is common that specific pcie devices fail to get enumerated. There are always lots of such cases.
The most precise way may be using analyzer to dump LA trace.
