Author Topic: RK3588 PCIe 3.0 PHY_MODE_PCIE_NANBNB with Shared/Single Reset GPIO  (Read 115 times)

0 Members and 1 Guest are viewing this topic.

Offline GajendranKTopic starter

  • Contributor
  • Posts: 10
  • Country: in
RK3588 PCIe 3.0 PHY_MODE_PCIE_NANBNB with Shared/Single Reset GPIO
« on: September 01, 2026, 06:23:13 am »
Hello folks!
I’ve been working on a custom PCIe-to-SATA HAT for an RK3588-based Single Board Computer (SBC).On this board, the primary M.2 NVMe interface is wired for PCIe 3.0 x4. However, my SATA HAT application only requires 2 lanes. To bridge the SBC and the HAT, I'm using a custom M.2 redriver board.

As per the RK3588 TRM, the chip features two internal PCIe 3.0 PHY blocks: PHY0 (controlling Lane 0 and Lane 1) and PHY1 (controlling Lane 2 and Lane 3).
2887930-0

Due to specific hardware routing constraints on our setup, my application explicitly utilizes the latter set of lanes (Lanes 2 & 3 via PHY1). Currently, the PCIe-to-SATA bridge IC is not being detected at all.

While digging into the Rockchip Linux PCIe Development Guide, I noticed that their reference example for 2Lane + 2Lane (PHY_MODE_PCIE_NANBNB) assigns independent reset-gpios to each controller (pcie3x4 / fe150000 for Port 0 and pcie3x2 / fe160000 for Port 1).
2887934-1

Here is my issue: our SBC hardware only routes a single physical PERST# GPIO line to the M.2 slot (which was originally intended for the x4 configuration). Since my HAT routes signals through PHY1, I attempted to assign that single physical PERST# GPIO directly to the pcie3x2 (fe160000) controller in the Device Tree, while completely removing the reset-gpios property from pcie3x4 (fe150000).

However, checking dmesg shows that fe150000 reaches LTSSM 0x3 (Polling.Compliance), whereas fe160000 (pcie3x2) remains frozen solid at LTSSM 0x0 (Detect.Quiet) and fails to initialize. 
2887926-22887938-3

My questions are:
1. Is assigning the main M.2 PERST# GPIO exclusively to the pcie3x2 controller node (while disabling or stripping reset-gpios from pcie3x4) a valid configuration in the Rockchip kernel driver framework, or will fe150000 always hold primary clocking/reset gating over fe160000?
2. Has anyone successfully brought up PCIe 3.0 PHY1 (pcie3x2 / fe160000) standalone on an RK3588 without an active PHY0 link?

Any insights, DTS examples, or debugging tips would be greatly appreciated! Thank you!
« Last Edit: September 01, 2026, 06:24:58 am by GajendranK »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf