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.
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
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]
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.
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
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.
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.
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.
(file with name …legacy… doesnt exists in this directory) , device doesnt boot wihtout sdcard.
I also tried this bootloader: https://github.com/orangepi-xunlong/orangepi-build/blob/c8894b658cefdd33738e2275ef3741895050d833/external/packages/bsp/rk3588/usr/share/orangepi5/rkspi_loader_sata.img
but accoridng to gdisk, gpt partition is corrupted.
Any idea why? I was trying all the tutorials I could find on the internet for the past 48 hours, but still no success…
Something broke again with the latest update. I can also not boot anymore. Just stuck. Need to get that serial kit back on the table. Maybe tomorrow if I have time. It is either related to the bootloader or the new kernel 6.1 which were both in the update. I suspect the uBoot that supposedly keeps the MAC fixed (and I flashed without thinking).
Laters.
As expected, the bootloader is the culprit. If you updated it, the SATA is no longer detected. Thus the system will not boot.
You need to revert back to the previous one or alternatively download an Armbian image, boot from SD and update rkspi_loader_sata.img. Note that the directories have changed. The full command is now
rkspi_loader_sata.img from the Dietpi image does not work.
Also do not update the kernel to 6.x if you are on 5.10. It will fail and hang during boot. If you want to move to kernel 6.x do it manually, not with the dietpi-update script.
The DietPi update does it not any different (kernel migration) but more complete, including headers and libc library if those were installed before. Also, it does not flash the bootloader, but only installs the package.
So the bootloader image from “vendor” branch does not boot from SATA, but the “legacy” one and “current” ones do? Weird is that all branches use the same U-Boot source. Maybe we just need to build a new package. I’ll trigger one, would be great if you could test.
