This setup works fine on the official Orange PI Debian distribution as it uses only the SATA drive to boot, and nothing else. However, it does not work on Armbian. I am aware that the paths and files are different in Armbian, and I have tried various methods, but no one has confirmed that it works.
My question is, how can I activate SATA on DietPI? I need to know because I am running only one instance of this board, and it serves a rather extensive home automation installation. I would like to migrate from Orange PI Debian to DietPI, and I need instructions on how to replicate the same functionality (SATA SSD) on this operating system.
Seems so. I was not aware that it supports SATA on the M.2 port even hardware-wise. @Joulinar did you not buy an NVMe because we thought SATA can simply not work?
Actually we might be able to add some check to boot.scr to pick the SATA overlay automatically. @Joulinar when you find time, could you paste the env print again from serial console, e.g. when breaking boot by renaming the kernel image or so. There should be some variable indicating whether it is NVMe or SATA when the boot.scr runs from thia drive already.
The bootloader itself must support SATA, and it seems the one from Armbian we use does not, while the one from Orange Pi does. Since also Armbian’s “legacy” bootloader package is based on vendor sources, I see no issue to instead use the one from Orange Pi. We could create a package from it to make it transparent: https://github.com/orangepi-xunlong/orangepi-build/tree/next/external/packages/bsp/rk3588/usr/share/orangepi5
What needs to be tested is whether it does not break NMVe or USB boot. I can test USB, would be great if someone could test NVMe.
The second thing is adding the SATA device tree overlay, so that also the kernel/OS can detect and mount the rootfs on the SATA SSD. I am pretty sure that it disables NVMe support in the same turn, so we cannot enable it OOTB. But as said, since we use a boot script instead of limited extlinux or similar, we should be able to auto-detect the boot media and select the overlay automatically on demand. For this, I need help form someone with an NVMe and/or SATA SSD to past the output of env print from U-Boot console here, so I can check which variable to check for.
And some simplified instructions to enable SATA boot, which do not require flashing the Orange Pi image or Armbian:
Flash a DietPi image to SD card, eMMC or USB to boot from. Do just a speedy first run setup, or hit CRTL+C at some point to abort and get to a shell prompt quickly.
Download and flash the Orange Pi SPI bootloader:
cd /tmp
curl -fO 'https://raw.githubusercontent.com/orangepi-xunlong/orangepi-build/next/external/packages/bsp/rk3588/usr/share/orangepi5/rkspi_loader_sata.img'
dd if=rkspi_loader_sata.img of=/dev/mtdblock0 conv=notrunc,fdatasync
Flash DietPi image to SATA (attach it if not done yet). PLEASE verify that /dev/sda really is the SATA SSD and not e.g. the USB drive you are booting from . Check e.g. via lsblk.
mkdir sata
mount /dev/sda1 sata
G_CONFIG_INJECT 'overlay_prefix=' 'overlay_prefix=orangepi-5' sata/boot/dietpiEnv.txt
G_CONFIG_INJECT 'overlays=' 'overlays=sata' sata/boot/dietpiEnv.txt
poweroff, detach the SD card/eMMC module/USB drive you booted from to boot from the attached SATA SSD.
Also you need to add the SATA overlay on the SD card, then reboot and then /dev/sda should show up. Then flash the image on the SATA and add the overlay also there, then restart and install should start from /dev/sda SATA.
Addition, the 4M bootloader seems to work with an original Armbian image on SATA, but not with DietPi on SATA. It works with DietPi on SD and can see /dev/sda then only.
Addition 2, did some more testing. Neither Bullseye, Bookworm nor Trixie images of DietPi 8.22.3 boot from SATA but they do from MicroSD. Latest original Armbian image (tested with Bookworm and Jammy) however does without any issue. So something is wrong inside the DietPi images. May be caused by that extra FAT partition with the preconfiguration, but that’s just a guess. All tested with above mentioned bootloader of 4MB in size.
Addition 3, the only way to get a clean DietPi running from SATA in the moment is to first install Armbian minimal using the procedure above (replace the not working DietPi image with Armbian) and then convert it into a clean DietPi using the dietpi-installer. Details can be found here: Supported hardware - DietPi.com Docs
It will complain that it cannot remove /var/lock as this is missing, simply open a subshell, create the stubborn “mkdir /var/lock”, then exit back, let the installer delete it again and be happy and continue.
Guys, this is not helpful!
“An error occurred: We’re sorry, but new users are temporarily limited to 3 replies in the same topic.”
To continue:
Haven’t tried this, you should not use dd for such scenario anyways in a running system. Will only cause more issues. You could of course disassemble the OPi5 and take out SD and SATA, connect them to another system and copy the SD over. Too much work.
Clean way to install for now is as described, use a minimal Armbian and convert it.
This may work but there is still the issue with the bootloader. Basically there are 2 versions, an older one with 16MB of size (or rather 2 with different behavior) and now the newer 4MB one. Maybe someone could try how this works with a copied SD to SATA or NVME.
Interestingly the 4MB version can boot the DietPi image from the SD but it sits dead with the SATA.
One thing I noticed, in Armbian sda1 contains the boot folder, sda2 the system. When imaging DietPi to the disk sda1 contains the system and sda2 the 4 editable setup files. This may simply confuse the bootloader after all.
Copying the SD onto SATA results in only one partition sda1 that contains the whole system boot+rootFS. Does not boot and just sits dead.
The bootloader apparently assumes sda1 to include the boot folder unmounted. So if the whole system is in sda1, the kernel and boot files are already under /boot, where sda1 in Armbian is mounted to.
DietPi would either need a different bootloader that looks for the kernel to be in /boot if the whole rootFS is used under sda1, or split it like Armbian does into boot with the files under / in sda1 and the root in sda2 then mounting sda1 under /boot.
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.
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.
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:
. Check e.g. via