Orange Pi 5 | Boot from SATA M.2 SSD

Yes, there is a SATA bootloader and it looks for sda1 including the bootfiles flat, not under /boot, as I mentioned already.

There is no SD, MMC, USB involved, just straight SATA, it works with separate boot dir in sda1 and rootFS in sda2, it does not work with the single partition.


dietpi@op5:~$ lsblk -f
NAME      FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
├─sda1    vfat   FAT16 armbi_boot 4F43-B4EA                             158.9M    38% /boot
└─sda2    ext4   1.0   armbi_root 99635f0b-c2de-4f29-8c39-056c95217a45  115.4G     1% /
dietpi@op5:~$ findmnt -Ufnro SOURCE -T /boot

And this prints the correct SATA rootfs UUID, right?

findmnt -Ufnro UUID -M /

This is what dietpi-installer does:

sed -i "/rootdev=/c\rootdev=UUID=$(findmnt -Ufnro UUID -M /)" /boot/dietpiEnv.txt

So I have no idea how a wrong UUID could have landed in your dietpiEnv.txt unless the system was still booted from SD card.

Yes, there is a SATA bootloader and it looks for sda1 including the bootfiles flat, not under /boot, as I mentioned already.

Is this with the Orange Pi SPI bootloader, or the one from Armbian? I.e. does it look for files below /boot when you flash the one from Armbian?

dd if=/usr/lib/linux-u-boot-legacy-orangepi5/rkspi_loader_sata.img of=/dev/mtdblock0 conv=notrunc,fdatasync

And when booting from SATA, can someone please do the following, so I can adjust our boot script to load the SATA overlay automatically:

sed -i '/^setenv bootargs/s/"$/ ${devtype}"/' /boot/boot.cmd
mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr
# after reboot
cat /proc/cmdline

I hope there is a “sata” at the end of the cmdline now, i.e. we can use the devtype variable as indicator.

That’s with the bootloader from your previous post here (the 4MB one), I haven’t tried with the Armbian one. The UUID is from Armbian, I don’t know where dietpi-installer gets its UUID from, but it was the DietPi default UUID and that does not match sda2, so it did not boot.

It could not have come from SD as the system was booted into Armbian from SATA and thus had no DietPi image or SD with DietPi involved at all. I ran the dietpi-installer on a fresh Armbian Bookworm minimal installation only.

Will try the setup again tomorrow when I have time with the Armbian bootloader and see if it can boot the single partition. I’ve tried with 2 other Orangepi 16MB bootloaders and they did not work either.

As I tried to explain, there is no “DietPi default UUID”, but dietpi-installer obtains the UUID directly form the system is runs on, with the command(s) I posted above. So with this command, you should actually see the UUID that you will find in dietpiEnv.txt after running our installer.

Okay so you used the Orange Pi bootloader. In this case it is quite possible that it requires the boot scripts in the partition’s root and does not look into /boot. Armbian’s bootloader builds however look into /boot as well, at least in all other cases. Now that we know there is even a dedicated SATA build shipped with their package (and hence with our images), that would be of course the preferred option anyway.

I did this method to move “root partition” aka / to my USB->SSD, but still leave the /boot partition on the SD card…it “should” work with almost all versions of linux with a bit of tweaking…but the principle is sound

Which leads to their github script (that is busted…arrrgh adafruit!!!) but this guy fixed it with his github repository script )

This is how I have my POE RPi2W boot from SD to a 32GB / USB, w/ a 64GB /home USB. It works a treat and boots every time with NO issues…no need to flash custom bootloaders or firmware…by default almost ALL SBC’s boot from an SD card…

warhawk@RPiZero2:~ $ lsblk
sda           8:0    1 57.3G  0 disk
└─sda1        8:1    1 57.3G  0 part /home
sdb           8:16   1 28.7G  0 disk
└─sdb1        8:17   1 28.7G  0 part /
mmcblk0     179:0    0 14.4G  0 disk
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14.2G  0 part
zram0       254:0    0  512M  0 disk [SWAP]
1 Like

I tried the Armbian bootloader from the Bookworm minimal image, it’s a 16MB size version again.

It does not recognize the single partition from DietPi and does not boot. But it boots the converted DietPi from sda1.

Ran your small script from above.

dietpi@op5:~$ cat /proc/cmdline
root=UUID=99635f0b-c2de-4f29-8c39-056c95217a45 rootfstype=ext4 rootwait console=tty1 console=ttyFIQ0,1500000 consoleblank=0 coherent_pool=2M usb-storage.quirks= net.ifnames=0 scsi

It says scsi, not sata.

lsblk for this

dietpi@op5:~$ lsblk -f
NAME      FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
├─sda1    vfat   FAT16 armbi_boot 4F43-B4EA                             158.9M    38% /boot
└─sda2    ext4   1.0   armbi_root 99635f0b-c2de-4f29-8c39-056c95217a45  115.4G     1% /

In all these tests there is never a SD card involved, neither a DietPi image. So I have no idea where dietpi-installer gets its own UUID from. Certainly not from any Armbian filesystem. It can only come from some files/scripts it downloads during the conversion.

1 Like

Okay thanks for testing. Very strange, since Armbian sets up most of their images via single partition as well, so very strange that their SATA bootloader build does not look into /boot, while the non-SATA (NVMe) one and the MMC one do. Did you check via serial console again that the problem really is that it does not look into /boot sub directory?

When it boots from SATA, devtype is scsi, thanks for that. Hmm, when conversing an Armbian image, our boot script /boot/boot.cmd is installed as well, which does not contain the SATA overlay. Did you add this manually or did it successfully boot without it?

I’d guess they just reuse the OrangePi bootloader for SATA, thus the same behaviour. Unfortunately I do not have a serial adapter, so I cannot check the console.

I did not modify boot.cmd other than your one-liner sed copied 1:1. The overlay was only manually added to armbianEnv.txr or dietpiEnv.txt respectivley.

Alright guys, got my hands on an adapter and now it gets interesting. The (Armbian) bootloader sees the /boot directory (here on the official single-partition DietPi bookworm installation image written to sda1).

Apparently it has problems with the overlay, particularly it cannot find
which does not exist

scanning bus for devices...
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp fbss pio slum part ccc apst
  Device 0: (0:0) Vendor: ATA Prod.: Teclast 128GB NS Rev: Q092
            Type: Hard Disk
            Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)

Device 0: (0:0) Vendor: ATA Prod.: Teclast 128GB NS Rev: Q092
            Type: Hard Disk
            Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
2666 bytes read in 48 ms (53.7 KiB/s)
## Executing script at 00500000
311 bytes read in 37 ms (7.8 KiB/s)
34920960 bytes read in 657 ms (50.7 MiB/s)
6885498 bytes read in 1886 ms (3.5 MiB/s)
** File not found /boot/dtb/rockchip/rk3588s-orangepi-5-sata.dtb **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Default at 0xeb9f91a8
350 bytes read in 634 ms (0 Bytes/s)
Applying kernel provided DT overlay orangepi-5-sata.dtbo
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@
Error applying DT overlays, restoring original DT
** File not found /boot/dtb/rockchip/rk3588s-orangepi-5-sata.dtb **
Fdt Ramdisk skip relocation
## Loading init Ramdisk from Legacy Image at 0a200000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6885434 Bytes = 6.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...

And then the conclusion :grinning:
Comparing with armbianEnv.txt, there is the device tree missing in dietpiEnv.txt and this is what stops it from booting after all.
Just one additional line needs to be added besides the overlay.


With this it can boot from the single partition in sda1.

1 Like

Okay then it is as I expected, thanks for checking with a serial adapter! Armbian uses the vendor kernel and bootloader sources for “legacy” builds, but always does own builds, with own configs, hence I was so confused why it would not check /boot, and finally the instinct was correct.

Looks like there was some oversights when patching the U-Boot sources/config regarding the SATA device tree: It implicitly looks for an SATA device tree while only an overlay is available, even with the original Orange Pi kernel packages.

The problem with hardcoding the device tree is that would look support for Orange Pi 5B, which uses a different device tree, which is correctly selected by U-Boot when not hardcoding it. But this can be also scripted.

You could simply make it an option in dietpiEnv.txt to uncomment the corresponding lines. After all this is what the file is for.

3/4 lines that could be put in dietpiEnv.txt in the image and just add some instructions to uncomment when using with SATA. Eventually add the 5B device tree too.


Short update, ran the dietpi-update to 8.23.3, works flawlessly and keeps booting functionality from SATA. No issues.

1 Like

great work guys.
I have a question - was it integrated into default installation image?

Full instruction

boot from SD card

change /boot/dietpiEnv.txt to have:


reboot shutdown -r now

check that sata is visible by command lsblk

download required image

curl -fO ''
apt install xz-utils
xz -d DietPi_OrangePi5-ARMv8-Bookworm.img.xz

copy dietpi image to sata

dd if=DietPi_OrangePi5-ARMv8-Bookworm.img of=/dev/sda conv=notrunc

copy bootloader

dd if=/usr/lib/linux-u-boot-legacy-orangepi5/rkspi_loader_sata.img of=/dev/mtdblock0 conv=notrunc,fdatasync

mount sata

mkdir sata
mount /dev/sda1 sata

change sata/boot/dietpiEnv.txt to have:


shutdown, remove SD card, power on, system should load from sata drive

I’m testing booting from SATA on Orange PI 5, but it doesn’t work.
@Mac, I have a question, what adapter did you use? I used a PCIe card with 4 SATA ports and 20 SATA ports. U-Boot doesn’t see the disk on the PCI card, but it does see the card. The U-Boot scsci scan command does not show any devices.

I don’t use an adapter, only a M.2 SATA SSD direct in the (supposedly NVME) M.2 slot on the OPi5.