Task description
Hello,
I recently bought a FriendlyElec NanoPi M5 based on the RK3576 SoC. The hardware itself is excellent and I had high expectations for it, but since this is still a relatively new board, software support is currently quite limited and many things do not work as smoothly as they should.
One of the main features I would like to achieve is booting directly from an NVMe SSD using the onboard SPI NOR flash as the bootloader storage.
I found that someone from the Armbian community had already implemented a similar setup for the RK3588-based NanoPC-T6: https://wiki.friendlyelec.com/wiki/index.php/Armbian_Installation_Guide
Since RK3576 is closely related to RK3588, I thought a similar solution might also be possible for the NanoPi M5.
My knowledge of Rockchip boot internals is still limited because I am relatively new to the SBC world. However, I learn quickly, and I am also using AI tools to help me understand and investigate the platform. I would be happy to perform tests, collect logs and experiment with different builds if someone with more experience could point me in the right direction.
Perhaps, with some guidance from the Armbian developers, we could eventually add proper SPI NOR → NVMe boot support for the NanoPi M5 as well.
Here is what I have tested so far.
I started an experiment to boot a FriendlyElec NanoPi M5 directly from its onboard SPI NOR flash. The board is based on RK3576 and has a 16 MiB SPI NOR flash together with a hardware switch that selects either UFS/SD or SPIF.
FriendlyElec confirmed to me that SPI boot is not currently supported by their official firmware, but that this is not a hardware limitation. They explained that they currently do not have enough resources to maintain multiple firmware variants and that the SPI NOR is intended for advanced uses, such as a custom U-Boot implementation.
As a reference, I used the Armbian SPI boot procedure for the RK3588-based NanoPC-T6.
I downloaded and analyzed the RK3588 rkspi_loader.img. Its structure is:
LBA 0 Protective MBR
LBA 1 GPT header
LBA 2... GPT partition entries
LBA 64 idbloader
LBA 7168 vnvme
LBA 7680 reserved_space
LBA 8064 reserved1
LBA 8128 uboot_env
LBA 8192 reserved2
LBA 16384 uboot
Except for the idbloader and uboot partitions, all other partitions were completely empty and filled with 0x00.
For RK3576, I found an official idbloader.img on FriendlyElec’s file server:
/dvdfiles/RK3576/tools/idbloader.img
The file is 413,696 bytes long and starts with the RKNS signature.
It contains:
RK3576 DDR initialization firmware
U-Boot SPL
MMC/UFS support
FSPI/SFC support
SPI NOR support
GPT parsing support
NanoPi M5 device tree
I also verified that this file is byte-for-byte identical to the loader stored at sector 64 of the official NanoPi M5 Debian SD card.
The SHA-256 hash is:
ca21a83f50aa20de2202e1b18548b27634b483babb3257a4f4f1c2df15742d7f
The embedded SPL contains references to:
rockchip,fspi
rockchip,sfc
jedec,spi-nor
spi_flash
u-boot,spl-boot-order
same-as-spl
/ufs@2a2d0000
/spi@2a300000/flash@0
This suggests that the FriendlyElec SPL already has support for booting from SPI NOR.
I then extracted the uboot partition from the official Debian SD card. It is a valid FIT image for:
It contains:
U-Boot proper
ARM Trusted Firmware
OP-TEE
NanoPi M5 U-Boot DTB
The SHA-256 hash of the 4 MiB U-Boot partition is:
fd321b734eba7f32fc324ac1b3ced734380472c5d544b8e8ba5a1643605552bc
The FIT configuration reported by dumpimage is:
FIT description: FIT Image with ATF/OP-TEE/U-Boot/MCU
Configuration:
Description: rk3576-nanopi-m5
Firmware: atf-1
FDT: fdt
Loadables:
uboot
atf-2
atf-3
optee
I used the RK3588 SPI image as a structural template. I cleared the original RK3588 contents of the idbloader and uboot partitions and replaced them with the RK3576/NanoPi M5 components:
idbloader.img written at offset 0x00008000
rk3576 Debian U-Boot FIT written at offset 0x00800000
All other partitions and the GPT layout were left unchanged. The replacement files were verified byte-for-byte after insertion.
The resulting image is exactly 16 MiB.
I wrote it to the onboard SPI NOR using:
flashcp -v rk3576-rkspi_loader.img /dev/mtd0
The SPI NOR is detected as:
Winbond W25Q128FW
16 MiB
4 KiB erase blocks
writable
The first boot test was performed with:
switch: SPIF
Debian SD card: inserted
The board booted Debian successfully.
This demonstrates that the following boot chain works:
RK3576 Boot ROM
→ SPI NOR
→ RKNS idbloader
→ DDR initialization
→ U-Boot SPL
→ FIT U-Boot from SPI
→ Debian from SD
I then wrote the following Armbian image directly to the NVMe SSD:
Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_kde-plasma_desktop.img.xz
The image was written to the whole NVMe device using:
xzcat Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_kde-plasma_desktop.img.xz \
| sudo dd of=/dev/nvme0n1 bs=4M status=progress conv=fsyncThe resulting NVMe layout contains a single Linux root filesystem partition, which is expected for this Armbian image.
For the second boot test I used:
switch: SPIF
SD card: removed
Armbian installed on NVMe
In this configuration, the board did not boot Armbian.
There was no HDMI output and no Linux heartbeat LED activity. However, the board also did not fall back into Maskrom mode. This suggests that the Boot ROM successfully found and executed the SPI loader, but the boot process stopped later, most likely during SPL, U-Boot or NVMe initialization.
At this point my main hypotheses are:
- The vendor U-Boot does not initialize PCIe/NVMe during cold boot.
- NVMe is not included in the automatic U-Boot boot order.
- U-Boot detects NVMe but does not search it for Armbian boot files.
- The old FriendlyElec vendor U-Boot does not support the boot mechanism used by this newer Armbian image.
- Additional U-Boot device-tree or PCIe power/reset configuration is required.
I have ordered a 3.3 V USB-to-UART adapter and will collect the full SPL and U-Boot console output as soon as it arrives.
The important result so far is that SPI NOR boot itself is already working on the NanoPi M5. The remaining problem is continuing the boot process from the SPI-hosted U-Boot to the NVMe SSD.
I would greatly appreciate any guidance. I can perform hardware tests, flash experimental images and provide complete UART logs...
Task description
Hello,
I recently bought a FriendlyElec NanoPi M5 based on the RK3576 SoC. The hardware itself is excellent and I had high expectations for it, but since this is still a relatively new board, software support is currently quite limited and many things do not work as smoothly as they should.
One of the main features I would like to achieve is booting directly from an NVMe SSD using the onboard SPI NOR flash as the bootloader storage.
I found that someone from the Armbian community had already implemented a similar setup for the RK3588-based NanoPC-T6: https://wiki.friendlyelec.com/wiki/index.php/Armbian_Installation_Guide
Since RK3576 is closely related to RK3588, I thought a similar solution might also be possible for the NanoPi M5.
My knowledge of Rockchip boot internals is still limited because I am relatively new to the SBC world. However, I learn quickly, and I am also using AI tools to help me understand and investigate the platform. I would be happy to perform tests, collect logs and experiment with different builds if someone with more experience could point me in the right direction.
Perhaps, with some guidance from the Armbian developers, we could eventually add proper SPI NOR → NVMe boot support for the NanoPi M5 as well.
Here is what I have tested so far.
I started an experiment to boot a FriendlyElec NanoPi M5 directly from its onboard SPI NOR flash. The board is based on RK3576 and has a 16 MiB SPI NOR flash together with a hardware switch that selects either
UFS/SDorSPIF.FriendlyElec confirmed to me that SPI boot is not currently supported by their official firmware, but that this is not a hardware limitation. They explained that they currently do not have enough resources to maintain multiple firmware variants and that the SPI NOR is intended for advanced uses, such as a custom U-Boot implementation.
As a reference, I used the Armbian SPI boot procedure for the RK3588-based NanoPC-T6.
I downloaded and analyzed the RK3588
rkspi_loader.img. Its structure is:Except for the
idbloaderandubootpartitions, all other partitions were completely empty and filled with0x00.For RK3576, I found an official
idbloader.imgon FriendlyElec’s file server:The file is 413,696 bytes long and starts with the
RKNSsignature.It contains:
I also verified that this file is byte-for-byte identical to the loader stored at sector 64 of the official NanoPi M5 Debian SD card.
The SHA-256 hash is:
The embedded SPL contains references to:
This suggests that the FriendlyElec SPL already has support for booting from SPI NOR.
I then extracted the
ubootpartition from the official Debian SD card. It is a valid FIT image for:It contains:
The SHA-256 hash of the 4 MiB U-Boot partition is:
The FIT configuration reported by
dumpimageis:I used the RK3588 SPI image as a structural template. I cleared the original RK3588 contents of the
idbloaderandubootpartitions and replaced them with the RK3576/NanoPi M5 components:All other partitions and the GPT layout were left unchanged. The replacement files were verified byte-for-byte after insertion.
The resulting image is exactly 16 MiB.
I wrote it to the onboard SPI NOR using:
The SPI NOR is detected as:
The first boot test was performed with:
The board booted Debian successfully.
This demonstrates that the following boot chain works:
I then wrote the following Armbian image directly to the NVMe SSD:
The image was written to the whole NVMe device using:
xzcat Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_kde-plasma_desktop.img.xz \ | sudo dd of=/dev/nvme0n1 bs=4M status=progress conv=fsyncThe resulting NVMe layout contains a single Linux root filesystem partition, which is expected for this Armbian image.
For the second boot test I used:
In this configuration, the board did not boot Armbian.
There was no HDMI output and no Linux heartbeat LED activity. However, the board also did not fall back into Maskrom mode. This suggests that the Boot ROM successfully found and executed the SPI loader, but the boot process stopped later, most likely during SPL, U-Boot or NVMe initialization.
At this point my main hypotheses are:
I have ordered a 3.3 V USB-to-UART adapter and will collect the full SPL and U-Boot console output as soon as it arrives.
The important result so far is that SPI NOR boot itself is already working on the NanoPi M5. The remaining problem is continuing the boot process from the SPI-hosted U-Boot to the NVMe SSD.
I would greatly appreciate any guidance. I can perform hardware tests, flash experimental images and provide complete UART logs...