OrangePI 5 NVME / PciE voltage regulator gpio bug

[atlaste]

I've been troubleshooting a little bug all day long, and think I pretty much found it. 

 

vcc3v3_pcie20 specifies gpios = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>, but the M.2 power switch on the Orange Pi 5 is on GPIO2_A1. The vendor DTS uses gpio2 pin 1. With the mainline value, pcie2x1l2 never links (Phy link never came up / LTSSM 0x3); changing it to <&gpio2 RK_PA1 GPIO_ACTIVE_HIGH> brings up PCIe Gen.2 x1 link up and the NVMe enumerates. This was reproduced on vendor 6.1.115, current 6.18.x, and edge 7.1.8.

 

Workaround that I'm currently using is a little user overlay:

 

mkdir -p /boot/overlay-user
cat > /tmp/pcie-m2-power-fix.dts <<'EOF'
/dts-v1/;
/plugin/;

/ {
    compatible = "rockchip,rk3588";

    fragment@0 {
        target = <&vcc3v3_pcie20>;
        __overlay__ {
            gpios = <&gpio2 1 0>;
        };
    };
};
EOF
dtc -@ -I dts -O dtb -o /boot/overlay-user/pcie-m2-power-fix.dtbo /tmp/pcie-m2-power-fix.dts

Hope it helps other people as well,

 

Stefan.

[Boardcon_yang]

Nice find, Stefan — and thanks for including the LTSSM state, that makes the root cause unambiguous. LTSSM 0x3 is Detect.Quiet: the
PHY never even starts link training because the PCIe rail never comes up. That is exactly what you expect when the regulator's
enable GPIO points at a pin that does not drive the M.2 power switch.For anyone wondering how this happened: gpio0 RK_PC5 is a leftover
from the Rockchip EVB reference design. The RK3588 EVB routes vcc3v3_pcie20's enable through GPIO0_C5, but the Orange Pi 5 board
wires the M.2 power switch to GPIO2_A1. When a board DTS is derived from the EVB, the power-tree GPIOs are the first things to silently
go wrong, because everything else (I2C, UART, display) still matches the silicon reference.

A couple of points from the industrial/product side, since we maintain a DTS review checklist for our own RK3588 boards going
through Armbian bring-up:

1. Cross-check enable GPIOs against the schematic, not against the SoC reference. The EVB-derived pins are the single most common
   source of "regulator never enables" bugs on Rockchip platforms.

2. While you are in there, check power sequencing too — not just  the pin number. On designs where PERST# is also GPIO-controlled,
   the enable -> PERST# release -> link training order matters, and regulator-ramp-delay / startup-delay can mask or fix marginal
   boards. A rail that powers up in the wrong order can still enumerate NVMe but fail intermittently at cold boot.

3. Worth pushing the fix upstream: a local overlay is a fine workaround for your own board, but the wrong pin is still in the
   DTS shipped with mainline kernels (and it reproduced across 6.1.115 / 6.18.x / 7.1.8, so it is the shared DTS, not a kernel
   regression). A one-line patch to the board DTS would fix this for every user.