I am doing a custom carrier bringup and I am stuck on this. I also have a m.2 on the carrier with a nvme ssd which works just fine with 2 lanes wired up. But I cannot get the WLE900VX wifi card to even show up on lspci.
Tried:
- Base image with eeprom fix so it boots up on carrier
- Forcing pcie gen1 with kernel modifications
- Lots of power cycles and relink attempts.
- Verified card gets power
- Tried another wle900vx
- Went over the HW design multiple times, all is looking fine. My only concern is the diff pairs are really short but they are still impedance matched.
I am waiting on a mini pcie to m.2 adapter, I will try hooking up the devkit’s wifi card on my carrier once that arrives.
I can share the carrier kicad files in private if needed, but I prefer not to share them publicly
Here’s claude’s overview of the situation:
PCIe C1 “Phy link never came up” — WLE900VX (QCA9880) on Custom Carrier
Hardware
- Jetson Orin Nano 8GB (P3767-0003)
- Custom carrier board (no EEPROM, no FUSB301)
- Compex WLE900VX (Qualcomm QCA9880, mini PCIe, PCIe Gen1 x1)
- JetPack 6.2.2 (L4T 36.5.0, kernel 5.15.185-tegra)
- PCIe C1 (pcie@14100000, HSIO UPHY Lane 3)
- ODMDATA:
gbe-uphy-config-8,hsstp-lane-map-3,hsio-uphy-config-0
- Board .conf sources
p3768-0000-p3767-0000-super.conf (super BPMP)
Symptom
tegra194-pcie 14100000.pcie: Phy link never came up
Card never shows up on lspci. No ath10k driver messages. Same result on cold boot, warm reboot, and driver unbind/rebind (tested 4+ cycles).
What works on the same board
- PCIe C4 (pcie@14160000): NVMe SSD, Gen3 x2, no issues
- PCIe C7 (pcie@141e0000): RTL8168 Ethernet, Gen1 x1, no issues (on-module)
- USB, SPI, UART, I2C all functional
Pinmux (from NVIDIA spreadsheet, matches stock p3768 devkit)
| Pin |
Function |
Config |
| pex_l1_clkreq_n_pk2 |
PE1_CLKREQ_L |
Bidirectional, Z |
| pex_l1_rst_n_pk3 |
PE1_RST_L |
Output, Drive 0 |
| pex_clk1p/n |
PEX_CLK_OUT_1_P/N |
Output (REFCLK) |
| pex_rx3p/n, pex_tx3p/n |
PEX1 data lanes |
SFIO |
| soc_gpio58_pac5 |
WiFi W_DISABLE# |
GPIO Output High (enabled) |
Register reads during link training
Read with busybox devmem 0.5s after driver bind (during link training window):
| Register |
Address |
Value |
Decode |
| APPL_DEBUG (LTSSM) |
0x141000D0 |
0x00000018 |
bits [8:3] = 0x03 = Polling.Compliance |
| APPL_LINK_STATUS |
0x141000CC |
0x00000002 |
bit 0 = 0, link down |
| DBI LNKCTL2 (TLS) |
0x300800A0 |
0x02010001 |
bits [3:0] = 0x01 = Gen1 2.5GT/s |
| DBI 0x80C (speed change) |
0x3008080C |
0x00020150 |
bit 17 = 1, directed speed change armed |
LTSSM is stuck at Polling.Compliance (0x03) every time. Detect.Active passes (receiver is found), Polling starts, but the endpoint never responds to TS1/TS2 and the state machine drops into Compliance.
With the WiFi card physically removed, LTSSM reads 0x00000000 (Detect.Quiet) — confirming the card IS being detected and the controller does enter Polling only when the card is present. The failure is specifically in the TS1/TS2 training exchange, not in receiver detect.
The PCIe differential pairs on this carrier are relatively short traces. Could this be an impedance matching issue on the PCB routing (e.g. trace impedance not hitting 85-ohm differential, or stub/via effects on short traces)?
PADCTL registers
| Register |
Value |
| PEX_L1_RST_N (PERST) |
0x00000050 |
| PEX_L1_CLKREQ_N |
0x00000460 |
What I already tried
max-link-speed = <1> in DT overlay — UEFI overrides it to Gen3 at boot- Patched pcie-tegra194.c to write TLS=Gen1 directly to the DBI register before LTSSM enable — confirmed TLS=0x01 via register read, link still fails at same LTSSM state
- Cold boot (full power off 10s, reconnect)
- Warm reboot
- Driver unbind/rebind, 3 consecutive attempts
- ASPM is disabled by default
- W_DISABLE# confirmed driven high via GPIO boot config
DT for pcie@14100000
status = "okay"
compatible = "nvidia,tegra234-pcie"
num-lanes = <1>
Questions
- LTSSM stuck in Polling.Compliance with receiver detected — is this a REFCLK problem or TX/RX signal integrity?
- Any way to read REFCLK PLL lock status from software?
- Known issues with QCA9880/WLE900VX on Tegra234 PCIe C1?
- PERST register 0x00000050 — is this correct for PE1_RST_L with proper assertion/deassertion?
- Any DT properties or kernel params worth trying? (nvidia,disable-clock-request, EQ settings, etc.)
Carrier design
- CLKREQ routed (PE1_CLKREQ_L)
- PERST hardware-controlled (PE1_RST_L, not GPIO)
- REFCLK pair (PEX_CLK_OUT_1_P/N) routed per reference design
- mini PCIe connector, standard pinout
- No retimers or amplifiers on C1 lanes
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, I will attempt to address the issues and questions raised.
Issue Summary:
The user is experiencing difficulties with a custom carrier board bring-up for the Jetson Orin Nano module. Specifically, they are unable to get the WLE900VX WiFi card to show up on lspci. They have tried various troubleshooting steps, including forcing PCIe Gen1, verifying power and signal integrity, and testing with a different WiFi card.
Analysis:
- LTSSM Stuck in PollingCompliance: The LTSSM (Link Training and Status State Machine) is stuck in the PollingCompliance state, indicating that the receiver is detected, but the endpoint never responds to TS1-TS2 training. This suggests a potential issue with the REFCLK or TX/RX signal integrity.
- REFCLK PLL Lock Status: Unfortunately, there is no direct way to read the REFCLK PLL lock status from software. However, the user can try to verify the REFCLK signal integrity using a oscilloscope or a signal analyzer.
- PERST Register Value: The PERST register value (0x00000050) seems correct for PE1RSTL with proper assertion/deassertion.
- Carrier Design: The carrier design appears to be correct, with CLKREQ routed to PE1CLKREQL, PERST hardware-controlled, and REFCLK pair routed per reference design.
Potential Causes and Solutions:
- Impedance Matching Issue: The short differential pairs on the carrier board might be causing impedance matching issues. The user should verify that the trace impedance is close to 85 ohms differential and that there are no stub/via effects on the short traces.
- REFCLK Signal Integrity: The REFCLK signal might be degraded or not meeting the required specifications. The user should verify the REFCLK signal integrity using a oscilloscope or a signal analyzer.
- TX/RX Signal Integrity: The TX/RX signal integrity might be affected by the short differential pairs or other factors. The user should verify the TX/RX signal integrity using a oscilloscope or a signal analyzer.
- QCA9880/WLE900VX Compatibility: There might be known issues with the QCA9880/WLE900VX WiFi card on the Tegra234 PCIe C1 interface. The user should research and verify any potential compatibility issues.
Recommendations:
- Verify Signal Integrity: Use a oscilloscope or a signal analyzer to verify the REFCLK, TX/RX, and CLKREQ signal integrity.
- Check Impedance Matching: Verify that the trace impedance is close to 85 ohms differential and that there are no stub/via effects on the short traces.
- Research Compatibility Issues: Research and verify any potential compatibility issues with the QCA9880/WLE900VX WiFi card on the Tegra234 PCIe C1 interface.
- Try Different DT Properties or Kernel Params: The user can try different DT properties or kernel params, such as nvidiadisableclockrequest or EQ settings, to see if it resolves the issue.
Comparison with Other Modules:
The user has mentioned that the NVMe SSD and RTL8168 Ethernet work fine on the same board, which suggests that the PCIe interface is functional. However, the WiFi card is not working, which might indicate a specific issue with the QCA9880/WLE900VX WiFi card or the PCIe C1 interface.
In summary, the issue is likely related to signal integrity or impedance matching issues on the carrier board. The user should verify the signal integrity and impedance matching, research compatibility issues, and try different DT properties or kernel params to resolve the issue.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
max-link-speed = <1> in DT overlay — UEFI overrides it to Gen3 at boot
Then you could do full flash to make it work in UEFI too.
There is nothing to configure for C1 in software (pinmux/DT) because it should be enabled by default
Already tried that. Didnt work. What else should I check or try? Is there a known issue with qca9980? Or is this my hardware at fault?
Not able to tell from my side.
The most precise way here is to use the PCIe analyzer to capture the trace.
If you have other PCIe device to test, then you could check if they could be detected too.
If they can be, then it means nothing to do with pinmux, ODMDATA and device tree.
I dont have access to a pcie analyzer or a similar high end tool. Best I have is a 500 MSPS general purpose scope.
I have a mini pcie to m.2 e key converter on they way. I will try connecting devkit’s wifi card once that arrives.
Is there anything else I can do / try / check while I wait for that to narrow the problem down? I still have no idea what the issue is.
UPDATE:
I got the mini pcie to M.2 Adapter, and using that I managed to connect the devkit wifi card (RTL8822CE) to my carrier. It also shows up on lspci without a problem.
Does this mean my problem isnt hardware? Is there an incompatibility between jetson orin nano and qca9880?
It could be the compatibility problem here but as we don’t have such device tested before, not able to know what is wrong there.
Just as I said, using a PCIe analyzer to capture trace might be the most precise way to tell what is wrong there.
I have a Jetson Orin Nano DevKit and a WLE900VX too. It works plug and play for me on Ubuntu 22.04 with kernel 5.15.
I think it should compatible with WLE900VX.
What is your kernel version？
