ferro

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]

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, 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

FYI, this is it 🙂

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 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:~# 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...)

eselarm, many thanks for your help and ideas so far. I will yet try with mainline kernels (I'm big fan of mainline but i wanted to use this board for running Frigate so I need to stick to vendor kernel for video accel and NPU until it is fully working in mainline kernel and adopted in Frigate). I will yet do the test with edk2 uefi bootloader too.

yes and this package linux-u-boot-orangepi5-vendor (26.8.3) is installed from the image with vendor kernel. It provides version of "U-Boot 2026.04_armbian-2026.04-S88dc-Pb430-H2ebc-Vccc7-B5da4-R448a (Jul 24 2026 - 14:26:33 +0000)" and with this version pci enumeration fails (see my previous post). That's why i thought you recommended to try older version of this package but the older version is not present in the repository and Amrbian does not provide archive of old images too.

hm, I don't know where to get older u-boot package 'linux-u-boot-orangepi5-vendor'. I tried to install linux-u-boot-orangepi5-legacy_24.5.1_arm64__2017.09-S0f76-Pa68f-Hddab-Vfb72-B2e16-R448a.deb from armbian repository and flashed to SPI by armbian-install but it does not boot - it ends up in boot loop on serial console with the following messages printed in loop: DR d5483af87d cym 23/11/23-16:15:24,fwver: v1.15 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB Manufacturer ID:0x13 CH0 RX Vref:30.5%, TX Vref:23.8%,0.0% CH1 RX Vref:29.3%, TX Vref:21.8%,0.0% CH2 RX Vref:32.2%, TX Vref:22.8%,0.0% CH3 RX Vref:31.0%, TX Vref:22.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init U-Boot SPL 2017.09 (May 19 2024 - 19:17:26) Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking u-boot 0x00800000 ... sha256(7b055a3e13...) + OK ## Checking fdt-1 0x008d5ae8 ... sha256(7b2c4c6dbe...) + OK ## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK ## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK Jumping to U-Boot(0x00800000) via ARM Trusted Firmware(0x00040000) Total: 610.383 ms

Hi eselarm, It is because I interrupted the boot process in bootloader to check pci enumeration in u-boot and then continued to boot the os after some time... Normally it takes ~9 sec, no issue... Anyway, I tried also your idea and cleared MTD/SPI with "flash_erase /dev/mtd0 0 0" and booted from sdcard but still the same - nvme not detected root@orangepi5:~# dmesg | grep -i pcie [ 10.199979] reg-fixed-voltage vcc3v3-pcie2x1l2: Looking up vin-supply from device tree [ 10.199985] vcc3v3_pcie2x1l2: supplied by vcc5v0_sys [ 10.257742] vcc3v3_pcie2x1l2: 1800 mV, enabled [ 10.257810] reg-fixed-voltage vcc3v3-pcie2x1l2: vcc3v3_pcie2x1l2 supplying 1800000uV [ 10.745649] dw-pcie fe190000.pcie: invalid resource [ 10.745663] dw-pcie fe190000.pcie: Failed to initialize host [ 10.745671] dw-pcie: probe of fe190000.pcie failed with error -22 [ 10.746219] rk-pcie fe190000.pcie: invalid prsnt-gpios property in node [ 10.746314] rk-pcie fe190000.pcie: Looking up vpcie3v3-supply from device tree [ 10.746811] rk-pcie fe190000.pcie: can't get current limit. [ 10.747168] rk-pcie fe190000.pcie: host bridge /pcie@fe190000 ranges: [ 10.747216] rk-pcie fe190000.pcie: IO 0x00f4100000..0x00f41fffff -> 0x00f4100000 [ 10.747253] rk-pcie fe190000.pcie: MEM 0x00f4200000..0x00f4ffffff -> 0x00f4200000 [ 10.747284] rk-pcie fe190000.pcie: MEM 0x0a00000000..0x0a3fffffff -> 0x0a00000000 [ 10.747353] rk-pcie fe190000.pcie: iATU unroll: enabled [ 10.747374] rk-pcie fe190000.pcie: iATU regions: 8 ob, 8 ib, align 64K, limit 8G [ 10.949578] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 10.970643] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 10.991697] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.011989] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.033044] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.053424] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.074548] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.095679] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.116756] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.137898] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 11.354114] rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up pcie-supply from device tree [ 11.354126] rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up pcie-supply property in node /power-management@fd8d8000/power-controller failed [ 13.049206] rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=0 [ 15.958825] rk_pcie_establish_link: 170 callbacks suppressed [ 15.958845] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 15.980104] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.001345] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.022603] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.043829] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.065047] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.086296] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.107514] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.128768] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.149859] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [ 16.381321] rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=1 [ 17.388646] rk-pcie fe190000.pcie: failed to initialize host root@orangepi5:~# 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 root@orangepi5:~#

Hi, I recently bought an Orange Pi 5 and installed Armbian 26.8.3 with the vendor kernel on an SD card. Everything has been working great so far. After installing an nvme ssd, I noticed that the drive is not detected at all under Armbian. There is no /dev/nvme* device present, and the ssd does not appear to be recognized during boot. To rule out a hardware issue, I tested the same board and ssd using the official Opi Ubuntu Jammy image, where the nvme drive is detected and works correctly. Armbian v26.8.3 + kernel 6.1.115-vendor-rk35xx When I interrupt the boot process and check PCIe enumeration directly from U-Boot, I see: U-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 => pci pcie_dw_rockchip pcie@fe190000: PCIe-0 Link Fail => Here are the logs from armbianmonitor -u: https://paste.armbian.com/wudukomiki

You are not alone seeing this problem, check this topic https://forum.armbian.com/topic/31682-poor-network-performance-send-only/?do=findComment&comment=235234 I think your finding points to the same solution mentioned there, where changing tx_delay to 0x35 resolved the speed issue.

Hi, Many thanks for your hard work on the Mesa patches and for adapting the stack to the RK3568 platform. It's great to see it running on the ODROID-M1. Keep it up! 🙂 I managed to get it working on my ODROID-M1 (8 GB) systems running my own Armbian build based on v26.08 and 7.2.0-rc7-bleedingedge-rockchip64 with this iommu patch: (npu-test) fero@odroidtest:~/rk3568-npu$ sudo dmesg | grep -w npu [ 9.743716] rockchip-pm-domain fdd90000.power-management:power-controller: failed to get ack on domain 'npu', val=0x1ee [ 10.753390] platform fde40000.npu: Adding to iommu group 3 [ 14.203903] rocket fde40000.npu: npu-supply enabled at 850000 uV [ 14.204531] rocket fde40000.npu: TEST scmi npu clk: enable=0 set_rate=0 rate=800000000 [ 14.215487] rocket fde40000.npu: raw VERSION=0x00000000 VERSION_NUM=0x00000000 [ 14.216241] rocket fde40000.npu: Rockchip NPU core 0 version: 0 and here are the results from some of your test scripts: (npu-test) fero@odroidtest:~/rk3568-npu$ python tests/suite.py models/layer-c28.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. layer-c28.tflite f0:1/0.09 f128:1/0.22 f255:1/0.06 colgrad:1/0.06 rowgrad:1/0.07 chan:1/0.20 mix:1/0.06 (npu-test) fero@odroidtest:~/rk3568-npu$ python tests/mob.py INFO: Created TensorFlow Lite XNNPACK delegate for CPU. mobilenet_v1_1.0_224_quant.tflite cpu 111ms npu 5.4ms top5 5/5 logit diff max 16 mean 0.03 | npu top5 [412, 742, 736, 886, 912]

Update: I found that the original IOMMU patch (see 1st post) - Armbian PR #9403 was incomplete for my case! I created an updated IOMMU patch based on the original upstream discussion. The important difference is that iommu_data_ops_v2 is forced back to 32-bit DMA addressing and GFP_DMA32 allocations: - .dma_bit_mask = DMA_BIT_MASK(40), - .gfp_flags = 0, + .dma_bit_mask = DMA_BIT_MASK(32), + .gfp_flags = GFP_DMA32, After rebuilding the kernel with this updated patch, the NPU now works correctly with the IOMMU enabled. root@odroidtest:~# dmesg | grep -i iommu [ 0.147669] iommu: Default domain type: Translated [ 0.147794] iommu: DMA domain TLB invalidation policy: strict mode [ 2.495423] platform fde40000.npu: Adding to iommu group 0 [ 2.498138] platform fdea0000.video-codec: Adding to iommu group 1 [ 2.500670] platform fdee0000.video-codec: Adding to iommu group 2 [ 2.503131] platform fe040000.vop: Adding to iommu group 3 root@odroidtest:~# root@odroidtest:~# dmesg | grep -i rkn [ 6.142497] [drm] Initialized rknpu 0.9.8 for fde40000.npu on minor 1 [ 6.143858] RKNPU fde40000.npu: RKNPU: DKMS: /dev/rknpu registered (DMA-BUF import only) [ 6.160736] RKNPU fde40000.npu: RKNPU: SCMI clock 198 MHz [ 6.169001] RKNPU fde40000.npu: RKNPU: devfreq active (SCMI-only, OPP 200-1000 MHz) [ 6.180806] RKNPU fde40000.npu: RKNPU: thermal throttling enabled [ 6.188054] RKNPU fde40000.npu: RKNPU: sram region: [0x00000000fdcc0000, 0x00000000fdccb000), sram size: 0xb000

Hi, As I mentioned earlier, after updating the DTS I was able to get the driver loaded and the NPU detected. I then started testing it using rknn-toolkit2 and a model from rknn_model_zoo. The RKNN runtime was able to load and inspect the model successfully, but the first NPU job submission failed: ./rknn_yolov5_demo model/yolov5s_relu.rknn model/bus.jpg ... rknn_run E RKNN: failed to submit, op id: 1, op name: Conv:/model.0/convsp/Conv ... rknn_run fail! ret=-1 init_yolov5_model fail! ret=-1 After a lot of testing and troubleshooting, I found that the failure appears to be related to the NPU IOMMU path. After disabling the NPU IOMMU in the DTS: iommu@fde4b000 { ... status = "disabled"; ... }; the NPU started working correctly. The demo completed successfully and produced valid object detection results: (base) fero@odroidtest:~/rk356x_linux_aarch64/rknn_yolov5_demo$ ./rknn_yolov5_demo model/yolov5s_relu.rknn model/bus.jpg load lable ./model/coco_80_labels_list.txt model input num: 1, output num: 3 input tensors: index=0, name=images, n_dims=4, dims=[1, 640, 640, 3], n_elems=1228800, size=1228800, fmt=NHWC, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 output tensors: index=0, name=output0, n_dims=4, dims=[1, 255, 80, 80], n_elems=1632000, size=1632000, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 index=1, name=286, n_dims=4, dims=[1, 255, 40, 40], n_elems=408000, size=408000, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 index=2, name=288, n_dims=4, dims=[1, 255, 20, 20], n_elems=102000, size=102000, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 model is NHWC input fmt model input height=640, width=640, channel=3 origin size=640x640 crop size=640x640 input image: 640 x 640, subsampling: 4:2:0, colorspace: YCbCr, orientation: 1 scale=1.000000 dst_box=(0 0 639 639) allow_slight_change=1 _left_offset=0 _top_offset=0 padding_w=0 padding_h=0 convert image use cpu finish rknn_run person @ (209 243 286 510) 0.880 person @ (479 238 560 526) 0.871 person @ (109 238 231 534) 0.840 bus @ (91 129 555 464) 0.692 person @ (79 353 121 517) 0.301 write_image path: out.png width=640 height=640 channel=3 data=0x3d269000 The remaining issue is understanding why inference fails when the NPU IOMMU is enabled. Nevertheless, the NPU now appears to be fully usable in non-IOMMU mode. I will continue testing with additional RKNN models and workloads while investigating the underlying IOMMU problem.

Hi, Finally, I made some good progress. I updated the DTS by starting with the DTS from Armbian 26.5.1 for current 6.18.x kernels and then merged the missing NPU and Power Domain nodes from the original DTS provided by @m1zfs. While comparing the original DTS with the current Armbian DTS, I also found that one of the phandle references in the NPU power-domain definition needed to be adjusted to match the phandle numbering used in the current Armbian DTS. After fixing that, the system booted successfully and the NPU was detected correctly. I'm now testing it with rknn_toolkit2 to verify that the NPU is fully functional. root@odroidtest:~# uname -a Linux odroidtest 6.18.35-current-rockchip64 #2 SMP PREEMPT Tue Jun 9 10:28:53 UTC 2026 aarch64 GNU/Linux root@odroidtest:~# root@odroidtest:~# lsmod | grep -E '^(rknpu|dma32_heap)\b' rknpu 94208 0 dma32_heap 12288 0 root@odroidtest:~# root@odroidtest:~# ls -l /dev/rknpu /dev/dri/by-path/platform-fde40000.npu-render /dev/dma_heap/system /dev/dma_heap/dma32 crw------- 1 root root 251, 3 Jul 25 21:19 /dev/dma_heap/dma32 lrwxrwxrwx 1 root root 19 Jul 25 21:19 /dev/dma_heap/system -> /dev/dma_heap/dma32 lrwxrwxrwx 1 root root 13 Jul 25 21:19 /dev/dri/by-path/platform-fde40000.npu-render -> ../renderD128 crw------- 1 root root 10, 261 Jul 25 21:19 /dev/rknpu root@odroidtest:~# root@odroidtest:~# dmesg | grep -i rknpu [ 6.108962] [drm] Initialized rknpu 0.9.8 for fde40000.npu on minor 1 [ 6.110169] RKNPU fde40000.npu: RKNPU: DKMS: /dev/rknpu registered (DMA-BUF import only) [ 6.132583] RKNPU fde40000.npu: RKNPU: SCMI clock 198 MHz [ 6.133433] RKNPU fde40000.npu: RKNPU: devfreq active (SCMI-only, OPP 200-1000 MHz) [ 6.134599] RKNPU fde40000.npu: RKNPU: thermal throttling enabled [ 6.139965] RKNPU fde40000.npu: RKNPU: sram region: [0x00000000fdcc0000, 0x00000000fdccb000), sram size: 0xb000 root@odroidtest:~#