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.

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.

Thanks. I honestly hope the bug will be fixed in future versions. 

 

I also can confirm this is the cause of the NVME not booting. If you toggle the gpio manually before the boot, the NVME will be detected just fine. I tried recompiling the bootloader, but gave up after battling errors for half a day.

 

1. You're right, i found this while checking against the schematic myself, and then verified it.

2. I haven't checked power sequencing. Honestly this is out of my comfort zone at the moment.

3. I would if I knew where. That is why I made the forum post here, i hope it would dripple into the upstream. If you expect something from me here, please let me know,

 

Cheers,

Stefan.

Confirming the bug, plus a data point: the M.2 power pin differs between Orange Pi 5 PCB revisions.

I have two Orange Pi 5 boards:
- PCB v1.3.2 (16 GB): NVMe not detected without a fix
- PCB v1.2: NVMe works out of the box

Both run the same software: Armbian 26.8.3, kernel 6.1.115-vendor-rk35xx (linux-dtb-vendor-rk35xx 26.8.3). The same NVMe drive works in v1.2 and is not detected in v1.3.2.

Symptoms on v1.3.2 (no fix):
- vendor kernel: "rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3", then "failed to initialize host"
- current kernel 6.18.43: "Phy link never came up"
- U-Boot (Armbian 2026.04 SPI): "pcie_dw_rockchip pcie@fe190000: PCIe-0 Link Fail"

Findings:
1. In the stock DTB (vendor), regulator vcc3v3_pcie2x1l2 uses gpios = <... 0x15 ...>, i.e. GPIO0_C5. On v1.2, /sys/kernel/debug/gpio shows:
   gpiochip0: gpio-21 (vcc3v3-pcie2x1l2) out hi
   and NVMe works.
2. On v1.3.2, driving GPIO2_A1 instead (as described in this thread) brings the link up. I used this overlay with the vendor kernel:

   /dts-v1/;
   /plugin/;
   / {
       compatible = "rockchip,rk3588";
       fragment@0 {
           target = <&vcc3v3_pcie2x1l2>;
           __overlay__ {
               gpios = <&gpio2 1 0>;
           };
       };
   };

   Without the overlay the system (rootfs on NVMe) does not boot on v1.3.2; with it, it does.
3. Same story in U-Boot: in the console of the Armbian SPI U-Boot, "gpio set 65; pci enum; nvme scan" makes the NVMe appear. After flashing the SPI bootloader from the official Orange Pi image, U-Boot sees the NVMe and Armbian boots from it.

Conclusion: this does not look like a defective board; the M.2 power switch seems to be on GPIO0_C5 on v1.2 and on GPIO2_A1 on v1.3.2. Simply changing the pin to A1 for all Orange Pi 5 boards would likely break v1.2, so the fix probably needs to be per revision (separate overlay/DTB), and the same applies to U-Boot's device tree.

Caveats: I only have one board of each revision. I tested the overlay on the vendor kernel only (on mainline the label is vcc3v3_pcie20, I did not test that).

Hi,

 

You made my day! 🙂 I have been struggling with nvme ssd not detected on my new opi5 board rev 1.3.2 too. Many thanks!

I confirm the fix is working -  detection of nvme only (not booting from nvme automatically):

• tested with official Armbian v26.8.3 for Orange Pi 5 image + bootloader flashed to SPI
• booted from sdcard with nvme disk attached
• running Armbian Linux 6.1.115-vendor-rk35xx
   

1.  Manual method - activate the pin in fw (uboot):
    

   Boot 2026.04_armbian-2026.04-S88dc-Pb430-H2ebc-Vccc7-B5da4-R448a (Jul 24 2026 - 14:26:33 +0000)
   
   Model: Xunlong Orange Pi 5
   SoC:   RK3588S
   DRAM:  8 GiB
   Core:  726 devices, 33 uclasses, devicetree: separate
   MMC:   mmc@fe2c0000: 0
   Loading Environment from nowhere... OK
   In:    serial@feb50000
   Out:   serial@feb50000
   Err:   serial@feb50000
   Model: Xunlong Orange Pi 5
   SoC:   RK3588S
   Net:   eth0: ethernet@fe1c0000
   Hit any key to stop autoboot: 0
   => pci enum
   pcie_dw_rockchip pcie@fe190000: PCIe-0 Link Fail
   => gpio set 65
   gpio: pin 65 (gpio 65) value is 1
   => pci enum
   => pci
   BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
   _____________________________________________________________
   00.00.00   0x1d87     0x3588     Bridge device           0x04
   01.00.00   0x1c5c     0x1339     Mass storage controller 0x08
   > boot
   
   ...
   
   root@orangepi5:~# lsblk 
   NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
   mtdblock0    31:0    0    16M  0 disk 
   mmcblk1     179:0    0 119.1G  0 disk 
   └─mmcblk1p1 179:1    0 117.9G  0 part /var/log.hdd
                                         /
   zram0       253:0    0   3.9G  0 disk [SWAP]
   zram1       253:1    0    50M  0 disk /var/log
   zram2       253:2    0     0B  0 disk 
   nvme0n1     259:0    0 238.5G  0 disk 
   └─nvme0n1p1 259:1    0 238.5G  0 part 
   root@orangepi5:~# 

    

2. with using user dtb
    

   root@orangepi5:~# cat > /tmp/pcie-m2-power-fix.dts <<'EOF'
   /dts-v1/;
   /plugin/;
   / {
       compatible = "rockchip,rk3588";
       fragment@0 {
           target = <&vcc3v3_pcie2x1l2>;
           __overlay__ {
               gpios = <&gpio2 1 0>;
           };
       };
   }; 
   EOF
   root@orangepi5:~# 
   root@orangepi5:~# armbian-add-overlay /tmp/pcie-m2-power-fix.dts
   Compiling the overlay
   Copying the compiled overlay file to /boot/overlay-user/
   Reboot is required to apply the changes
   root@orangepi5:~# 
   root@orangepi5:~# shutdown -r now
   
   ...
   
   root@orangepi5:~# lsblk
   NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
   mtdblock0    31:0    0    16M  0 disk 
   mmcblk1     179:0    0 119.1G  0 disk 
   └─mmcblk1p1 179:1    0 117.9G  0 part /var/log.hdd
                                         /
   zram0       253:0    0   3.9G  0 disk [SWAP]
   zram1       253:1    0    50M  0 disk /var/log
   zram2       253:2    0     0B  0 disk 
   nvme0n1     259:0    0 238.5G  0 disk 
   └─nvme0n1p1 259:1    0 238.5G  0 part 
   root@orangepi5:~# 

    

EDIT: Tested boot from nvme

Transferred system to nvme via armbian-config with uboot in MTD/SPI. But it did not boot automatically because nvme is not detected in u-boot until I manually set the pin (gpio set 65) so this needs to be fixed in u-boot (in the upstream I would say...)

 

Edited October 12Oct 12 by ferro

moved

Hi,

 

I created the patch for u-boot to fix m2 power pin in u-boot dts (the same way as above for kernel dts). If you use the updated u-boot you do not need user overlay for kernel anymore. Just flash the patched u-boot to MTD/SPI and then nvme disk is detected. Then you can transfer the system to nvme disk by armbian-install and boot from it with bootloader in SPI. I have tested it with vendor and mainline (current) kernel - both works.

 

The patch is attached in this topic - it is for Orange PI 5 V1.3.2 only!

Build patched u-boot package on build machine (the example below is for "vendor" kernel, if you use mainline kernel - replace "vendor" by "current")

 

git clone https://github.com/armbian/build
cd build
mkdir -p userpatches/u-boot/v2026.04
cp ~/u-boot-opi5-v132-m2-power-sw-pin.patch userpatches/u-boot/v2026.04
./compile.sh uboot BOARD=orangepi5 BRANCH=vendor

 

u-boot package is created in build/output/deb directory, eg. output/debs/linux-u-boot-orangepi5-vendor_26.11.0-trunk_arm64__2026.04-S88dc-Peffc-Ha291-Vccc7-B56a7-R448a.deb

 

Transfer the package to your orangepi5 (eg. booted from stable Armbian 26.8.1 image on sdcard) and install it:

sudo dpkg -i linux-u-boot-orangepi5-vendor_26.11.0-trunk_arm64__2026.04-S88dc-Peffc-Ha291-Vccc7-B56a7-R448a.deb

Flash updated SPI u-boot image to MTD/SPI:

sudo flashcp -v -p /usr/lib/linux-u-boot-vendor-orangepi5/u-boot-rockchip-spi.bin /dev/mtd0

Reboot and  check nvme is detected

root@orangepi5:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0    31:0    0    16M  0 disk 
mmcblk0     179:0    0 119.1G  0 disk 
└─mmcblk0p1 179:1    0 117.9G  0 part /var/log.hdd
                                      /
zram0       253:0    0   3.9G  0 disk [SWAP]
zram1       253:1    0    50M  0 disk /var/log
zram2       253:2    0     0B  0 disk 
nvme0n1     259:0    0 238.5G  0 disk

Use armbian-install to transfer the system to nvme with bootloader in MTD/SPI

 

u-boot-opi5-v132-m2-power-sw-pin.patch

Edited October 16Oct 16 by ferro

I hit this same issue on Armbian 26.8.3, vendor 6.1.115, Orange Pi 5 8GB. `lsblk` showed no NVMe, `dmesg` stuck at `PCIe Link Fail, LTSSM is 0x3`.

**What I tried (didn't work):**
- `echo 1 > /sys/bus/pci/rescan` – no effect
- The overlay from @atlaste's post targeting `&vcc3v3_pcie20` – **silently failed** because in the vendor 6.1.115 DTB the node label is `vcc3v3_pcie2x1l2`, not `vcc3v3_pcie20`. The `.dtbo` compiles fine but the fixup never resolves, so the overlay is never applied.
- Switching to a different PSU (5V/5A RPi 5 charger) – no change

**What actually worked (direct DTB patch):**

```bash
# Decompile
dtc -I dtb -O dts /boot/dtb/rockchip/rk3588s-orangepi-5.dtb -o /tmp/opi5.dts

# Find the wrong GPIO line (around line 10720):
#   gpios = <0x15a 0x15 0x00>;   ← gpio0 pin 21 (WRONG)

# Find the correct phandle for gpio2 (node gpio@fec30000, around line 7854):
#   phandle = <0x2ce>

# Patch:
sed -i 's/gpios = <0x15a 0x15 0x00>/gpios = <0x2ce 0x01 0x00>/' /tmp/opi5.dts

# Recompile and replace:
dtc -I dts -O dtb -o /tmp/opi5.dtb /tmp/opi5.dts
sudo cp /tmp/opi5.dtb /boot/dtb/rockchip/rk3588s-orangepi-5.dtb
sudo reboot
```

Verified with `od -A n -t x1 /proc/device-tree/vcc3v3-pcie2x1l2/gpios` → `00 00 02 ce 00 00 00 01 00 00 00 00` (gpio2, pin 1).

**Important caveat – Gen4 drives may not work:**

After the DTB fix, my **Crucial E100 480GB (PCIe Gen4 x4)** still did NOT enumerate. Swapped to a **Gen3 drive** and it appeared immediately in `lsblk`. The M.2 slot itself was fine (verified with a PCIe-to-SATA adapter).

So the full picture:
1. **DTS GPIO bug** – blocks ALL NVMe (Gen2/3/4) → fix as above
2. **Gen4 NVMe drives** – may still fail even after the fix, because RK3588S only does PCIe Gen2 and some Gen4 drives don't negotiate down properly

**TL;DR for anyone hitting LTSSM 0x3:**
- First: patch the DTB (label is `vcc3v3_pcie2x1l2` in vendor 6.1.115, not `vcc3v3_pcie20`)
- If still no luck: try a Gen2/Gen3 drive before blaming the board

 

Hi Vitek, but I think, this will only solve the problem with nvme detection when you boot from sdcard. If you transfer running os from sdcard to nvme (by armbian-install) with bootloader in MTD/SPI, remove the sdcard and try to boot, does it work for you? I doubt it will boot from nvme without patched uboot...

 

Hi,
That’s exactly right – it won’t boot from NVMe. I need to have an SD card in there, but only for booting.

This is solved by the uboot patch in my previous post, which includes step-by-step instructions on how to build and flash it. Once applied, you can boot from NVMe as well. You may give it a try [emoji6]