Hello Vileer! Quick question…I am on the Radxa CM5 with the AIO v2 and NVME board. After extensive custom patches and kernel mods on the Arch build floating around, I’ve managed to get everything working EXCEPT the PCIe. SDR, Lora, GPS, USB 3.0, proper full shutdown, power management…but after 3 known working NVME drives and several random adapters, LTSSM is always stuck at 0x3. I can paste my project log in trying to get this to work…can you shed some light on this? Session Log: PCIe/NVMe Fix Attempts — 2026-03-12
Starting State
- Device: uConsole with Radxa CM5 (RK3588S), Arch Linux ARM, BSP kernel 6.1.84
- PCIe controller: pcie2x1l2 @ fe190000, CombPHY0 @ fee00000
- Symptom: LTSSM stuck at 0x3 (Polling.Active) — root complex detects endpoint, sends TS1 training sequences, never receives valid TS2 back
- USB 3.0: working. Ethernet: working. Only PCIe/NVMe remains broken.
What was done this session
- Identified combphy driver is built-in (=y), not a module
- CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY=y in .config
- Previous suggestion of “just swap the .ko file” was wrong — there IS no .ko
- Must rebuild full kernel Image to change combphy behavior
- Fetched mainline combphy driver from torvalds/linux master
- Sparse-cloned drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
- Did line-by-line diff of rk3588_combphy_cfg() between BSP 6.1.84 and mainline
- Identified specific register value differences for PCIe 100MHz path
┌─────────────────┬─────────┬───────────┬──────────────────────┬─────────────────────┐
│ Register │ Address │ BSP Value │ Mainline Value │ Purpose │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ su_trim[7:0] │ 0x28 │ 0x90 │ 0xF0 │ PLL tuning │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ PLL LPF │ 0x2c │ 0x43 │ 0x04 │ PLL loop filter │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ PHYREG13 │ 0x30 │ 0x88 │ not written │ Extra BSP write │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ PHYREG14 │ 0x34 │ 0x56 │ not written │ Extra BSP write │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ gate_tx_pck_sel │ 0x74 │ 0xc0 │ not written │ L1SS (BSP only) │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ SSC direction │ 0x7c │ BIT(4) │ not written for PCIe │ SSC disabled anyway │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ PLL KVCO │ 0x80 │ 4 │ 4 │ Same │
├─────────────────┼─────────┼───────────┼──────────────────────┼─────────────────────┤
│ rx_trim │ 0x6c │ 0x4c │ 0x4c │ Same │
└─────────────────┴─────────┴───────────┴──────────────────────┴─────────────────────┘
- Identified structural differences NOT patched
- Mainline uses priv->type vs BSP priv->mode (field rename)
- Mainline stores priv->refclk, priv->id, priv->enable_ssc, priv->ext_refclk in struct
- Mainline adds PHY-ID-based mux selection (pipe_pcie1l0_sel/pipe_pcie1l1_sel) — but this only triggers for PHY IDs 1 and 2. This device uses combphy0 (ID 0), so the mux fix is NOT relevant
here. - Mainline removed force_det_out, pipe_phy_grf_reset, pcie1ln-sel-bits DT handling
- Mainline changed reset from get_optional(“combphy”) to get_exclusive(“phy”) with fallback
- BSP has separate rockchip_combphy_pcie_init wrapper — mainline doesn’t
- Applied patch to device (SSH to 192.168.1.146)
- Backed up original: phy-rockchip-naneng-combphy.c.bak
- Edit 1: Removed SSC direction write from PCIe case (line 1212-1213)
- Edit 2: Replaced 100MHz PCIe block — removed gate_tx_pck_sel, changed su_trim from 0x90→0xF0, changed PLL LPF from 0x43→0x04, removed PHYREG13/14 writes
- Verified both edits applied correctly via sed -n reads
- Built kernel natively on device
- Native gcc 15.2.1 on aarch64 (cross-compiler not installed)
- make ARCH=arm64 -j4 Image modules
- Had to install cpio package (missing dependency for kheaders)
- Had to clean stale .o.d files from killed previous builds
- Build succeeded: 6.1.84-gc1945a11d0b4-dirty
- Deployed and rebooted
- sudo make ARCH=arm64 modules_install
- sudo cp arch/arm64/boot/Image /boot/vmlinuz-linux-uconsole
- sudo mkinitcpio -k 6.1.84-gc1945a11d0b4-dirty -g /boot/initramfs-linux-uconsole.img
- Warning about missing crypto_lz4 module (non-critical, rootfs is ext4)
- sudo reboot
- Result: LTSSM still 0x3. Patch did NOT fix it.
- New kernel confirmed running: uname -r = 6.1.84-gc1945a11d0b4-dirty
- GRF registers confirmed combphy code executed: con0=0x1000, con2=0x101
- Ethernet confirmed still working: “Link is Up - 1Gbps/Full”
- PCIe identical failure: PCIe Link Fail, LTSSM is 0x3
- Added to failed-approaches.md as item #21
Research findings this session
Confirmed: Daniel_Ueki’s NVMe success is RPi CM5, NOT Radxa CM5
- Post #834 mentions “CM5 lite 16GB” and “EEPROM” boot order
- Radxa CM5 has no EEPROM — only RPi CM5 does
- Trinity (post #891) “NVMe works fine with CM5” — also RPi CM5 (confirmed from post #852)
Confirmed: No verified Radxa CM5 NVMe success found anywhere
- Rex’s Bookworm 6.1.y thread for Radxa CM5: zero mentions of NVMe/PCIe on page 1 or 2
- Rex’s Bookworm 6.12.y thread: PCIe enabled for RPi CM5 adapter boards
- “Radxa CM5 on uConsole, tell your experience” thread: zero NVMe/PCIe mentions
- “Anyone tried the Radxa CM5 on the uconsole?” thread: perillamint (post #9) notes Radxa CM5 “has an extra PCIe lane broken out” but no NVMe success reported
- dev-null2019/radxa-cm5-uconsole GitHub: lists what works (display, keyboard, USB, power, 4G, microSD) — NVMe/PCIe NOT listed
- clockworkpi/uConsole official GitHub: no Radxa CM5 device tree files at all
- idjibb (post #899, March 10): asking for Radxa AIO v2 documentation, can’t find GPIO mappings
- Rex (page 2): confirms “The script from hackergadgets was made for the RPi CMs” and “The Radxa CMs don’t use pinctrl”
Hackergadgets adapter board
- Product page confirms Radxa CM5 variant exists and claims to “expose the PCIe” signals
- No schematic, no FPC pinout, no PCIe routing documentation available
- The RPi CM4/CM5 variant has confirmed NVMe — the Radxa CM5 variant does NOT have confirmed NVMe from any user
- Downloaded Radxa CM5 v2.21 schematic PDF (saved locally) — needs poppler to read for PCIe pin mapping on B2B connector
Radxa CM5 PCIe architecture
- 2x PCIe 2.0 1-lane: one shared with USB3+SATA (combphy2), one shared with SATA (combphy0)
- combphy0 → pcie2x1l2 is the lane that should go to NVMe
- combphy2 → USB3 (currently working, confirmed Bus 004 at 5000M)
What is now known / ruled out
- PLL tuning values (su_trim, PLL LPF) are NOT the root cause
- SSC direction write is NOT the root cause
- gate_tx_pck_sel is NOT the root cause
- All GRF register configuration is confirmed correct
- The combphy driver executes and configures the PHY — the configuration itself isn’t the problem
- LTSSM 0x3 = Polling.Active = endpoint detected, but no valid TS2 response
- No one has publicly confirmed NVMe working on Radxa CM5 + hackergadgets adapter board
- All NVMe successes in the forum are RPi CM5 users
Unresolved questions
- Does the hackergadgets Radxa CM5 adapter board actually route PCIe differential pairs to the FPC connector?
- Does the FPC cable carry the PCIe signals to the NVMe battery board?
- Which specific pins on the Radxa CM5 B2B connector carry pcie2x1l2 TX/RX? (Schematic downloaded but unread)
- Has vileer (hackergadgets) actually tested PCIe on the Radxa variant?
- Is there a power rail issue specific to the Radxa adapter board path?
- Could forcing Gen 1 (2.5 GT/s) help if the signal path is marginal?
- What do the remaining mainline structural changes (init sequence, reset handling) do differently?
