Board: Orange Pi 5 Plus (RK3588)
Armbian image used: Downloaded from https://armbian.cn/boards/orangepi5-plus (Ubuntu 26.04, .img format)
Comparison image: Joshua Riek's Ubuntu for Rockchip – https://joshua-riek.github.io/ubuntu-rockchip-download/boards/orangepi-5-plus.html
Problem Description
I downloaded the Armbian image for Orange Pi 5 Plus from the official Armbian page and flashed it to both a TF card and eMMC. The board fails to boot in either case. However, when I flash Joshua Riek's Ubuntu image using the exact same methods, the board boots successfully without any issues.
I have compared the partition layouts of both images and found them to be essentially identical:
Both use a single ext4 partition scheme.
Both leave approximately 16 MB of unallocated space before the ext4 partition (which is where the RK3588 BootROM expects to find the bootloader at the 32 KB and 8 MB offsets).
Both contain the necessary .dtb files and kernel inside the /boot directory of the ext4 partition.
Given that the partition structures are the same, I am unable to understand why one image boots and the other does not.
What I Have Tried
Flashed the Armbian image to a TF card using balenaEtcher – The board does not boot (no display output, no serial console activity).
Flashed the Armbian image to eMMC using RKDevTool – The board does not boot.
Flashed Joshua Riek's Ubuntu image to a TF card using balenaEtcher – Boots successfully.
Flashed Joshua Riek's Ubuntu image to eMMC using RKDevTool – Boots successfully.
Erased the SPI Flash – I have already cleared the onboard SPI Flash to rule out any interference from a previously installed bootloader. This was done using the following command from within the working Ubuntu system:
sudo dd if=/dev/zero of=/dev/mtdblock0 bs=1M count=4
After erasing, the Armbian image still fails to boot from both TF card and eMMC.
Compared partition tables – Both images show the same layout: ~16 MB of unallocated space before the ext4 partition. I have verified that the partition start offsets are identical.
My Analysis
Since the SPI Flash has been erased and both images share the same partition structure, the issue likely lies in one of the following areas:
The bootloader data in the pre-partition area (the first 16 MB) may be missing or invalid in the Armbian image. The RK3588 BootROM looks for the first-stage bootloader (idbloader) at the 32 KB offset and the second-stage bootloader (u-boot.itb) at the 8 MB offset. It is possible that the Armbian image does not contain valid data at these offsets, while Joshua Riek's image does.
The bootloader format or signing may be incompatible. Even if data exists at the correct offsets, it might not conform to what the RK3588 BootROM expects (e.g., missing Rockchip header, incorrect signing, or wrong image format).
The Armbian image may use a different boot flow (e.g., expecting to chain-load from a FAT32 boot partition) that does not match the Orange Pi 5 Plus hardware boot sequence.
Questions
Does the Armbian image for Orange Pi 5 Plus include a valid idbloader and u-boot at the correct offsets (32 KB and 8 MB) within the pre-partition area?
Is there any additional step required to make the Armbian image bootable on Orange Pi 5 Plus, such as manually writing a bootloader or running a setup script after flashing?
Is the Armbian image for this board known to work when flashed via balenaEtcher or RKDevTool, or is a different flashing method required?
Environment
Board: Orange Pi 5 Plus (RK3588)
Armbian image: Ubuntu 26.04 from https://armbian.cn/boards/orangepi5-plus
Flashing tools used: balenaEtcher (for TF card), RKDevTool (for eMMC)
SPI Flash status: Erased (confirmed)
Comparison image: Joshua Riek's Ubuntu for Rockchip (boots successfully with the same tools and methods)
Any help or guidance would be greatly appreciated. I am happy to provide additional logs or hex dumps of the boot area if needed.

provide boot logs via debug uart console

3 hours ago, 董进 said:

sudo dd if=/dev/zero of=/dev/mtdblock0 bs=1M count=4

Is this the whole SPI/MTD ? Why only 4MiB? My ROCK5B has a 16MiB SPI-flash and I simply wipe all. As I have seen methods to put GPT table in SPI as well, so what happens when and orphan different 2nd/backup table is still there and 1st is different/new or MBR based? 

Same of eMMC

 

And why flash both SD-card and eMMC ? I would saw wipe all HW that is OPi5 and only use SD-card.

 

It might be that Armbian uses a new DDR RAM init code in the bootloader that does not work on your specific OPi5 board revision, so to see what works, you need to post bootloader log (from the working one) as already said. So then people can see what the differences might be.

I have started working on a possible transition to the latest vendor kernel and I am having a display race. Try toggling the display.. unplug / replug. Nice to have a claude SSH'ed in to see everything is fine.