Orange Pi 5 | Boot from SATA M.2 SSD

ping @MichaIng

More tests, the Armbian conversion into DietPi does not cold boot. So this is also not an option.

Tried with 3 different bootloaders (16MB and 4MB) to no avail. DietPi changes something from Armbian that breaks the SATA functionality.

The rootdev UUID in dietpiEnv.txt is hardcoded to the SD with the initial DietPi Bookworm install, not the SATA, so it actually did not use the SATA in the first place. Changed this to the Armbian value 99635f0b-c2de-4f29-8c39-056c95217a45, so now I can boot from SD and using root on sda2.

Think I figured it out so far. With the following in dietpiEnv.txt (on sda1) it seems to boot finally from sda1 and uses the rootFS on sda2. This is for the converted install from Armbian to DietPi. Not sure if this causes any other issues. This does not fix the not working installation from the official DietPi image, only the Armbian conversion.

rootdev=UUID=99635f0b-c2de-4f29-8c39-056c95217a45
fdtfile=rockchip/rk3588s-orangepi-5.dtb
overlay_path=rockchip
overlay_prefix=orangepi-5
overlays=sata
rootfstype=ext4
consoleargs=console=tty1 console=ttyFIQ0,1500000
usbstoragequirks=
extraargs=net.ifnames=0
docker_optimizations=off
user_overlays=

We intentionally use a single partition only, which generally works. The UUID is a filesystem parameter, so it is correct regardless where you flash the image to. dietpi-installer adjusts the UUID in /boot/dietpiEnv.txt to whatever either the /boot or the root / mount filesystem has, so that is always correct. I hope you were not somehow trying to boot the rootfs from SATA with the bootloader and dietpiEnv.txt from SD card. That would actually work when adjusting dietpiEnv.txt, but this is not what we want. We want the SPI bootloader to boot the rootfs from SATA directly, so that no SD card is required.

The only issue really is that the Armbian (SPI) bootloader does not support booting from SATA, while the one from Orange Pi seems to.

EDIT: Btw, I guess boot priority prefers the SD card, so as long as there is one attached with a bootloader on it, SATA and NVMe boot cannot be tested properly.

As mentioned these are workarounds to get the converted Armbian to boot and use the SATA. DietPi adjusts the UUID wrongly to it’s own by using the dietpiEnv.txt defaults and not to the already installed and booted converted Armbian on SATA. The correct entry would be 99635f0b-c2de-4f29-8c39-056c95217a45, dietpi-installer changes it to 01030847-19e0-40ba-aa1b-aa37a9feca1d. As this does not exist it cannot boot. Also the overlays are ignored. Not sure if this perhaps works properly with an SD installation, it certainly does not with SATA. Anyways this is not the key issue and can be fixed as explained.

The main problem is that the official DietPi image is unable to boot / install from SATA regardless. And this is most likely caused by the single partition, where the boot files and kernel are already under the /boot directory unlike in Armbian, where they sit flat on sda1 and are only mounted to /boot later. So again, either you would need a bootloader that looks for the files in /boot or you would need to split the system into sda1 with the boot files and sda2 with the rootFS. The converted Armbian keeps this structure with the bootfiles separate on sda1 and thus visible to the bootloader.

Can you check the output of this on the Armbian image:

lsblk
findmnt -Ufnro SOURCE -T /boot

If you are actually booting from SD card or eMMC just with the rootfs on SATA, then it might be the same/similar issue than here: NanoPi R5S - Boot from NVMe - #19 by MichaIng

Do you have any SD card attached? And does the Armbian image still boot when you remove any SD card and USB device so that really the SATA drive is the only attached storage device?

Please note that our image is booting perfectly fine form NVMe, USB and SD card with the currently used single ext4 partition. So both, the MMC bootloader as well as the SPI bootloader do support this perfectly fine. No point in suspecting partitioning any further. SATA vs NVMe is the only difference, and the fact that you used armbian-install to move probably only the rootfs to SATA while keep using the MMC bootloader.


EDIT: Lol, checking the content of the current Armbian U-Boot package, there is actually a dedicated SPI bootloader binary for SATA:

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

And then following from step 3 here, to download and flash the DietPi image to SATA + enable the SATA overlay: Orange Pi 5 | Boot from SATA M.2 SSD - #5 by MichaIng

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.

FYI

dietpi@op5:~$ lsblk -f
NAME      FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─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% /
mtdblock0
zram0
dietpi@op5:~$ findmnt -Ufnro SOURCE -T /boot
/dev/sda1

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
reboot
# 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
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
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
sda
├─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% /
mtdblock0
zram0

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
/boot/dtb/rockchip/rk3588s-orangepi-5-sata.dtb
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.

fdtfile=rockchip/rk3588s-orangepi-5.dtb

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.

#fdtfile=rockchip/rk3588s-orangepi-5.dtb
#fdtfile=rockchip/rk3588s-orangepi-5b.dtb
#overlay_prefix=orangepi-5
#overlays=sata

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:

fdtfile=rockchip/rk3588s-orangepi-5.dtb
overlay_prefix=orangepi-5
overlays=sata

reboot shutdown -r now

check that sata is visible by command lsblk

download required image

curl -fO 'https://dietpi.com/downloads/images/DietPi_OrangePi5-ARMv8-Bookworm.img.xz'
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
sync

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:

fdtfile=rockchip/rk3588s-orangepi-5.dtb
overlay_prefix=orangepi-5
overlays=sata

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