Request. UEFI arm64 iso for Orange pi 5 plus

[yandritos]

Dear MichaIng and team,

I am a fan of dietpi and I have being using this OS from my older raspberry pi 2 and 3, ordroid c2 and now orange pi 5 plus.

This last one is the mobo SOC which is allowing me more options for my NAS, now I have 8 sata ports perfect for all my HDD (6 in the nvme to sata adapter + 2 in M2 wifi port to 2 sata) but I am unable to boot from any of these ports, just from the SD card and USB 2.0 ports (even the USB 3.0 is not booting), all the sata ports work detecting my disks but not working for the boot.

After trying maby boot loaders flasing SPI not without success booting from SATA, I discovered that there is a UEFI firmware (edk2) which can be flashed to the SPI Not and works like a charm! --> https://github.com/edk2-porting/edk2-rk3588/releases

The only problem is that the amount of UEFI isos with linux arm64 distros supporting the soc rk3588 is really low (an old debian/armbian kernel 5.1 and a heavy ubuntu 25 kernel 6.17 distro).

Not sure how difficult could be, but is it possible to have an UEFI iso arm64 for dietpi supporting the soc rk3588? The edk2 uefi firmware is awesome, I am able to boot the available isos from any port USB 2.0 even the USB 3.0 ports plus all the SATA ports of my adapters, I can even use GRUB and have dual boot and boot order.

Thanks in advance and thans for your work!

[MichaIng]

No time for this any time soon, a can of worms on top of a chip that still has no full mainline support. We'd only import tons of potential new issues, while still fiddling with tons of current ones 😅. Someone mentioned this EDK2 earlier, and I wonder: is this an actual bootloader replacement, or just a secondary bootloader loaded by U-Boot? While UEFI on x86_64 is the inevitable closed-source bootloader on ROM, the ARM cases I know so far it is loaded by the actual first bootloader stage (typically U-Boot), while that first stage could load the kernel directly. So there, EFI was just an unnecessary additional step in the boot sequence, additional complexity and point of failure. A true U-Boot replacement would be at least interesting, but with this low support and maintenance I see, it does not seem worth it at all. You can also have a U-Boot boot menu with HDMI and USB if wanted, that is not something where one requires a dedicated bootloader for, and for USB boot not at all anyway.

So while it is interesting to see U-Boot alternatives (if it really is one), out of scope for us, and generally not reasonable for a project like us to start mixing new bootloaders inside, while we try hard to align things and reduce maintenance efforts that way.

Instead, I'd focus on why USB boot does not work for you: You did flash our U-Boot to the SPI flash via dietpi-config? There should be a menu to select between NVMe and SATA support.

EDIT: Ah, and you should definitely try the mainline Linux image with mainline U-Boot! https://dietpi.com/downloads/images/DietPi_OrangePi5Plus-ARMv8-Trixie_mainline.img.xz

EDIT2: I see, no SATA SPI bootloader build included. So this should work with NVMe only on the M.2 port.
If someone finds time to compare the two configs for Orange Pi 5 (non-Plus):

• NVMe: https://github.com/u-boot/u-boot/blob/master/configs/orangepi-5-rk3588s_defconfig
• SATA: https://github.com/armbian/build/blob/main/patch/u-boot/v2026.04/defconfig/orangepi-5-sata-rk3588s_defconfig

Maybe we can implement a similar separate SATA SPI bootloader build for Orange Pi 5 Plus: https://github.com/u-boot/u-boot/blob/master/configs/orangepi-5-plus-rk3588_defconfig

[yandritos]

First of all, thanks a lot for taking the time with your detailed reply, I totally understand this is out of Scope.

Regarding to your questions:

I am already using the last DietPI Trixie from your link (EDIT 1), and I flashed the u-boot provided, but no way to boot from SATA. USB boot works but for some reason only with the USB 2.0 ports, no way from USB 3.0.

EDIT 1. I just see your EDIT 2 :D probably that is the reason because I don´t get any menu for selecting the desired boot between NVME and SATA (I added evidences in the forum https://dietpi.com/forum/t/orange-pi-5-boot-from-sata-m-2-ssd/17884/51 ).

If someone can implemente the separate SATA SPI bootloader for Orange PI 5 Plus, that will make my day for sure. For now, I had to use a SATA to USB adapter and boot my SSD via USB 2.0, not desired because it is slow but at least works.

Thanks again, have a nice weekend!

[MichaIng]

USB boot works but for some reason only with the USB 2.0 ports, no way from USB 3.0.

Does the USB 3.0 port otherwise work well with the same drive? And do you have a UART adapter to check serial console logs when trying to boot from one of the USB 3.0 ports?

And if you find time, please test it with the mainline Linux image. I aim to use those by default for RK3588 boards very soon, aside of for a few exceptions (where onboard WiFi drivers are missing).

[yandritos]

Hi, with the uefi firmware any USB Port is able to boot no Matter It It is 2.0 or 3.0. Not sure why with the dietpi uboot It isn't. I'll loot for the uart wire.

I just Saw with the apt upgrade that new uboot files are available (I assume you added them yeaterday), I am going to take an snapshoot and test.

Keep you posted asap!

[MichaIng]

What do you mean by "overlay mode"? And same DietPi image means same UUIDs? Would need to check boot priorities, but I guess it does boot from SD card in that case, and just mounts the rootfs from the USB drive in userland, which would however be only fragile or coincidence, if the UUID of the SD card is the same. And it would break once you do a kernel upgrade, since from that point on, the loaded kernel from SD card and kernel modules on the USB drive do not match anymore.

Check with:

lsblk -no NAME,UUID,PARTUUID

If the PARTUUIDs differ, it can be checked with

cat /proc/cmdline

which partition the boot.scr was called from. In theory, it is also possible that only the bootloader from SD card was used, but loaded boot.scr and kernel from the USB drive, depending on the boot target order.

[yandritos]

That is just the case! As per your command, the SSD connected via USB3 and the SD card have the same UUID:
1st command
dietpi@DietPi:~$ lsblk -no NAME,UUID,PARTUUID
sda
└─sda1 3ba8f4ea-ef46-4b39-a7b4-eec5efe86fa8 5dc3d057-8b62-4554-8c0c-3af713626004
sdb
└─sdb1 48ef91ac-b62a-4144-a4df-c5db28a6af22 59c40827-e557-447b-9d63-1fbb71b1fd9d
sdc
└─sdc1 9b6e4b67-2856-47af-9330-b728d41ab6e9 57bd0295-4a76-44f7-a5d3-40fb822d3410
mtdblock0

mmcblk1
│
└─mmcblk1p1
3ba8f4ea-ef46-4b39-a7b4-eec5efe86fa8 5dc3d057-8b62-4554-8c0c-3af713626004

2nd command
dietpi@DietPi:~$ cat /proc/cmdline
root=UUID=3ba8f4ea-ef46-4b39-a7b4-eec5efe86fa8 rootfstype=ext4 rootwait console=tty1 consoleblank=0 coherent_pool=2M ubootpart=5dc3d057-8b62-4554-8c0c-3af713626004 fsck.repair=yes net.ifnames=0 androidboot.fwver=bl31-v1.48,uboot-rmbian-201-03/12/2026

As per your comment, I am not going to update the kernel for now :D

EDIT1: Regarding to the overlay, I set manuall the next value under "/boot/dietpiEnv.txt" but maybe it is not having any impact at all. This is the current content in the file ( I wrote manually "overlays=sata"):

GNU nano 8.4 /boot/dietpiEnv.txt
rootdev=UUID=3ba8f4ea-ef46-4b39-a7b4-eec5efe86fa8
rootfstype=ext4

The init system logs to the console defined last.

consoleargs=console=tty1
extraargs=fsck.repair=yes net.ifnames=0
docker_optimizations=off
overlay_path=rockchip

Multiple prefixes are supported separated by space

overlay_prefix=orangepi-5-plus rockchip-rk3588 rk3588 rockchip
overlays=sata
user_overlays=

[Joulinar]

the SSD connected via USB3 and the SD card have the same UUID

This only happens if you flash the very same image twice. Once to the SD card and again to the SSD.

[yandritos]

Yep, in the desperation I burned different units with the same image :) but at least for some reason is helping to get the boot from USB3! Not sure hiw can I preserve in case a new kernel update arrives, for now, I'll stay safe without updates till I get sata bootm Thanks!

[MichaIng]

It could be setup properly/more explicitly by:

1. Changing the UUID of the ext4 partition on the SD card.
2. Removing all but /boot on the SD card, and moving the /boot content to its root.
3. Mounting the SD card to /boot on the system.

So the system boots from SD card as of boot priority, but mounts the USB drive as rootfs explicitly (without UUID collision), and mounts the SD card as boot filesystem. That way, kernel upgrades will upgrade the effective kernel on the SD card, and /boot/dietpiEnv.txt changes are effective etc.