October 10Oct 10 Hi eselarm, Quote - why is 1st timestamp not 0, but already about 6 minutes ongoing: [ 586.150768] Booting Linux ... 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:~#
October 10Oct 10 4 hours ago, ferro said: 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... OK clear; also I see I made an error ~586sec is about 10m not 6. Anyway, if you want to run Armbian you have now on SD-card to run from NVME, I would take the older U-Boot package 'linux-u-boot-orangepi5-vendor' and write its binary to SPI-flash (or first try SD-card only) with armbian-config, that I expect to work. Then you have vendor U-Boot and vendor kernel. What is wrong with the mainline based U-Boot for OPi5, I really don't know. Mainline U-Boot on SD-card and mainline based kernel maybe detects NVME, but depends on what your OPi5 should do if that is OK for you. Edited October 10Oct 10 by eselarm
October 10Oct 10 Quote Anyway, if you want to run Armbian you have now on SD-card to run from NVME, I would take the older U-Boot package 'linux-u-boot-orangepi5-vendor' and write its binary to SPI-flash (or first try SD-card only) with armbian-config, that I expect to work. Then you have vendor U-Boot and vendor kernel. What is wrong with the mainline based U-Boot for OPi5, I really don't know. 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
October 10Oct 10 That package is in standard Armbian Trixie, a test run on my NanoPi-R6C: root@ranc:~# apt install linux-u-boot-orangepi5-vendor Installing: linux-u-boot-orangepi5-vendor REMOVING: linux-u-boot-nanopi-r6c-edge Summary: Upgrading: 0, Installing: 1, Removing: 1, Not Upgrading: 2 Download size: 920 kB Space needed: 3423 kB / 5394 MB available Continue? [Y/n] BUT, I see it is also 2026.04_armbian, so I am a bit surprised by that. The 'legacy' can also be installed the same way (what you did) and indeed 2017.09. I expected that to work, I use also that version on my ROCK3A, else I can't get NVME+SATA working at the same time. I am out of ideas w.r.t. this armbian U-Boot variants, but as I mentioned earlier in this thread, EDK2 UEFI v1.1 is also an option. I use that on both NanoPi-R6C and ROCK5B, now in mainline mode, but you can set it to vendor in the settings, that it should run 6.1.115 kernel. Edited October 10Oct 10 by eselarm
October 10Oct 10 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.
October 10Oct 10 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.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.