piter75

There might also be some variances in components between units (different manufacturers, batches, etc..) that might have been "uncovered" by some minor change in kernel code. I remember having a unit of Rock Pi 4A (no wifi) that did not boot with eMMC while the other unit 4GB 4B (wifi) did boot without issues. I consulted other Rock Pi 4A Armbian users and they did not observe such behaviour. I finally found the cause in the mmc kernel driver and even implemented a patch for it in Armbian, but that did require lots of fiddling and debugging. Unfortunately at this point I cannot reproduce the issue with my NanoPi R4S unit.

Is anything printed on the serial console during boot?

With Armbian v20.11 one can write mainline u-boot image to board's SPI and enjoy booting nvme drives without any mmc devices. Prerequisities: ROCK Pi 4(A/B/C) v1.4 or 1.3 with SPI soldered in (v1.3 comes without SPI flash from the factory). If you already have Radxa's u-boot written to SPI you need to short pins 23 and 25 for Armbian to boot Boot fresh image of Armbian v20.11.x for ROCK Pi 4(A/B/C) Add the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 Reboot If you shorted 23-25 pins in 1.) then: disconnect them after the ROCK Pi 4 fully boot's enable spi-nor by executing (as root): echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind verify that the SPI mtd interface is enabled by running ls /dev/mtdblock0 if the last command does not list any file then something went wrong between 3.) and 5.) Run nand-sata-install choose option: "Boot from SPI - system on SATA, USB or NVMe" choose NVMe partition, eg. /dev/nvme0n1p1 accept erasing of the choosen partition with "Yes" choose fs type (tested with ext4) wait a few minutes for rootfs transfer to chosen partition choose writing SPI bootloader with "Yes" confirm that you want to flash it with "Yes" wait ~60 seconds for writing choose Exit Reboot Enjoy Armbian booting with SPI / NVMe Why bother with mainline u-boot? It is known to boot some NVMe drives that legacy u-boot from Radxa has issues with, eg. SAMSUNG 970 EVO Plus and SAMSUNG PM981. This does not mean that all NVMe drives are supported, YMMV. Which NVMe drives are known to be working? Corsair MP510 240GB/480GB/960GB Gigabyte SSD M.2 2280 PCIe x2 Model:GP-GSM2NE8128GNTD HP SSD EX900 M.2 NVMe 120GB. Model: 2YY42AA#ABB Intel SSD 660p Model:SSDPEKNW512GB Kingston A1000 SSD 240GB (PHISON PS5008-E8-10) Kingston A2000 M.2 2280 PCIe NVMe PNY 250GB XLR8 CS3030 M.2 NVMe SSD PCIe Gen3 x4 Sabrent Rocket 256GB NVMe PCIe M.2 2280 Samsung 970 EVO Plus SSD 250GB M.2 2280, PCIe 3.0 x4, NVMe, 3500/2300 MB/s Samsung PM981 256GB XPG SX6000 Lite 128GB (ASX6000LNP-128GT-C) Why not using Radxa's u-boot SPI image? Ambian's u-boot configuration is incompatible with Radxa's SPI image Why Armbian is using u-boot that is incompatible with Radxa's? It uses mainline u-boot with Open Source TPL/SPL/proper and BL31 from Rockchip packaged into u-boot and we may switch to using open source ATF instead of the BL31 in the future. Can I boot Radxa's images with Armbian's u-boot written to SPI? Yes. Armbian's SPI u-boot is compatible with Radxa's images available here: https://github.com/radxa/rock-pi-images-released/releases It may not be compatible with some older images (released before July 2020) because of the device tree filename change.