Xopek1986

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).