Raul

My gathered info :
 
RK3588(S) comparison -------------------- RK3588(S) 8nm LP process 4 x A55 @ 1.8Ghz + 4 x A76 @ 2.4Ghz (Not the same for all boards, between 2.2Ghz and 2.4Ghz) Mali-G610 MP4 "Odin" 6TOPs NPU Up to 32GB memory theoretically (haven't seen any 32GB yet) RK3588 RK3588S PCIE3.0 2x2 Lanes PCIe3.0 N/A PCIe2.0/SATA3.0/USB3.0 MUX 3x1 Lane PCIE2.0 2x1 Lane PCIE2.0 3x SATA 3.0 2x SATA 3.0 1x USB3.0 (refer USB section) 1x USB3.0 (refer USB section) Board SoC Memory eMMC SD-Reader NVMe/PCIe/SATA Network USB2 USB3 USB-C (dp) HDMI-out HDMI-in DP Active cooling Powered with 1. Khadas Edge 2 Pro Rockchip RK3588S 16 GB LPDDR4X 2112 MHz 64 GB xxx xxx xxx 1 x 1 x 1 x DP 1 x xxx xxx xxx (Case not out yet) USB-C PD 2. NanoPi R6S Rockchip RK3588S 8 GB LPDDR4X 2133 MHz 32 GB yes xxx 2 x 2.5GbE + 1GbE 1 x 1 x xxx 1 x xxx xxx Metal case USB-C PD 3. Radxa Rock5B Rockchip RK3588 16 GB LPDDR4X 2112 MHz Module yes 2 x M.2 NVMe 2.5GbE 2 x 2 x xxx 2 x 1 x micro-HDMI xxx XU4 heatsink no sufficient USB-C PD (Issue with PD, I'm using 5V 4A PSU) 4. Mekotronics R58 Mini Rockchip RK3588 16 GB LPDDR4X 64 GB xxx SATA ribbon 1GbE 2 x 1 x 1 x (no DP) 2 x 1 x full size 1 x Big heatsink sufficient *** 12V barrel jack *** Case could also be used to cool with a thermal pad 5. Mekotronics R58X-4G Rockchip RK3588 8 GB LPDDR4X 64 GB xxx SATA/NVMe/mini-PCIe 1GbE 2 x 1 x 1 x DP 1 x 1 x full size 1 x Big heatsink sufficient *** 12V barrel jack 6. Orange Pi 5 Rockchip RK3588S 4/8 GB LPDDR4(x) xxx yes NVMe 1GbE 1 x 2 x 1 x DP 1 x xxx xxx No USB-C 5V Other specs Khadas Edge 2 Pro also has 3 x CSI + 2 x DSI, and can have an I/O board for SD-card and uart Radxa Rock5B has 1 x CSI + 1 x DSI OPi5 has 2 x DSI + 3 x Camera port Benchmarks ---------- Board | OS | Kernel | Clockspeeds | 7z b all cores | 7z b core small core | 7z b big core | NicoD Blender | Supertuxkart | SBC-Bench Radxa Rock 5B Armbian Jammy cinnamon 5.10.110 1.8Ghz A55/2.4Ghz A76 15996 1533 (core 0) 2651 (core 7) 3m25s 65fps (panfork) http://ix.io/4jOb Radxa Rock 5B Radxa Bullseye xfce4 5.10.66-27 1.8Ghz A55/2.4Ghz A76 16138 1522 (core 0) 2649 (core 4/7) 4m35s V2.83.5 xxx Khadas Edge2 Ubuntu 22.04 Gnome 5.10.66 1.8Ghz A55/2.35Ghz* A76 16901 1766 (core 0) 2930 (core 7) 3m25s 110fps (wayland) http://ix.io/4e8w ****SBC-Bench broken big cores at 408Mhz NanoPi R6S Ubuntu 22.04 Gnome Headless 5.10.110 1.8Ghz A55/2.3Ghz * A76 16385 1449 (core 0) 2493 (core 7) 3m27s 110fps (wayland) http://ix.io/4gSl Mekotronics R58 Debian Bullseye wayland 5.10.110 1.8Ghz A53/2.2Ghz A76 16803 1777 (core 0) 2879 (core 1) 4m35s 110fps (wayland) http://ix.io/4j40 Mekotronics R58 Ubuntu 20.04 x11 5.10.66 1.8Ghz A53/2.2Ghz A76 16477 1765 (core 0) 2897 (core 1) 5m53s V2.82 4fps (llvmpipe) Mekotronics R58X-G4 Armbian Jammy Gnome 5.10.110 1.8Ghz A53/2.4Ghz A76 16421 1767 (core 0) 2852 (core 1) 3m28s 75fps (panfork) SBC-bench broken Pros+++ ------- Khadas Edge2 Pro Small and USB-C PD powered, so great for my trips but needs a metal case for that. Having the extra USB-C is great. It is either a 2nd fast access to the SoC, and can be used for 2nd HDMI display. OOWOW is great to install new software, no need for RKDevTool. The Khadas software is pretty good. Khadas has a great team that's active on their forum. NanoPi R6S Metal case makes it awesome. It is limited, but for what I wanted it's doing the job better than expected(fast NAS and even watching video). USB-C PD powered, so if I don't find a case for Edge2 I can also use the R6S on my trips. SD-Reader is great for booting and installing software. Mekotronics R58 mini Full sized ports. For home use it's good to have a device that's not tiny. Great to have the display ports on back and side and USB on the front. Case is nice, but not used for cooling. Great for digital signage with 2x HDMI + 1 x DP. Mekotronics R58X-4G mini-PCIe, NVMe and SATA. Full sized ports. USB-C with DP. Nice case, can be used to cool the board with a thermal pad but not needed. Rock5B Armbian support. Has dual M.2 sockets. SD-card reader and eMMC socket. Full sized HDMI-out ports. 2.5GbE. Cons--- ------- Khadas Edge2 Pro No metal case yet(March). Missing SD-card, IO board can add that but then doesn't fit in the case. Seems designed for use in a small kiosk/digital signage, so all small special connectors for additional devices like displays and camera's. NanoPi R6S Designed for networking and so missing a lot of other features(NVMe, PCIe, extra USB-C with DP, multiple USB3 ports...). Mekotronics R58 mini Not the best I/O. No sd-reader what makes the use of RKDevTool needed. Expensive. Wouldn't be as good for me if I didn't know great Armbian devs(MonkaBlyat). Mekotronics R58X-4G No sd-reader what makes the use of RKDevTool needed. Expensive. Wouldn't be as good for me if I didn't know great Armbian devs(MonkaBlyat). Rock5B Software not ready for my daily needs, seems the worst supported board. USB-C PD has issue's. No good cooling sollution comes with the board. My opinion on available software -------------------------------- 1. Khadas Edge2 Ubuntu 22.04 works great with panfork. You can also use the blob GPU driver if you start with the Gnome image. Almost everything works as it should. 2. Mekotronics R58(X-4G) Armbian Jammy Gnome works great with panfork. The Mekotronics images aren't perfect. Works well for desktop/video/gaming. 3. NanoPi R6S Ubuntu 22.04 gnome works well, but panfork doesn't work with it. It's very stable, did my desktop tasks as a champ. But I'm missing gaming on it with x11. 4. Radxa Rock5B Armbian Jammy Gnome is buggy as hell. Only Armbian runs ok on it. The Debian image from Radxa is a mess, Android is unusable. DTB file seems badly hacked together. My favorite ranking for now --------------------------- 1. Mekotronics R58X-4G It has it all. Good cooling, nice it's not tiny, NVMe and SATA and mini-PCIe. 1 less full sized HDMI vs R58 but USB-C DP works too. Armbian thanks to MonkaBlyat brings this on top. 2. NanoPi R6S Limited but works well for what I wanted from it. The case is a big plus. Panfork not working. But the Ubuntu 22.04 Gnome image is great for desktop tasks. Stable, great video playback. Performs well as NAS too. Love that it has an SD-reader. I do not need dual 2.5GbE, so could have been better having NVMe instead of 2nd 2.5GbE port. 3. Khadas Edge 2 Missing of a metal case brings this down, waiting for the case to be released. The software from Khadas is the best of all. No SD-card is also a big minor. Best board for travel laptop. 4. Mekotronics R58X Works well. But has a lot less I/O than R58X-4G. Then again has 2 x full sized HDMI-out vs 1 x on R58X-4G. 5. Radxa Rock5B Bit dissapointed by the software. It does have all the bells and whistles I want. But it isn't ready for daily use yet. Armbian is the only ok-working image for it. And that is a lot more buggy than all the others. ***Don't have the OPi5***  

Hi all.
I made a new video on how to build Armbian images.
These days you can use your ARM64 SBC to do this.

For Windows users there's WSL2 you can use. Here my video about that.

Greetings, NicoD

Full root filesystem encryption on an Armbian system
(new, fully rewritten, replaces my earlier tutorial on this topic)
 
MMGen (https://github.com/mmgen)
 
This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian system.  The disk can be unlocked remotely via SSH or the serial console, permitting unattended bootup.
 
An automated script that performs the same steps, saving you much time and effort, can be found at https://github.com/mmgen/mmgen-geek-tools
 
Note that unlike my earlier tutorial all steps are performed within a running Armbian system.
 
The tutorial is known to work with the following board/image combinations (plus possibly others—follow the comments in this thread for additional info):
 
 Orange Pi PC2  Debian Buster mainline / Ubuntu Focal legacy  RockPi 4  Debian Trixie  mainline / Ubuntu Focal legacy  RockPro 64  Ubuntu Focal mainline  Odroid HC4  Debian Buster mainline / Ubuntu Focal mainline  
 
 
 
Pinebook Pro Debian Bookworm current minimal Rock Pi 4A+ Unknown Pine A64 Unknown Orange Pi 5 Debian Bookworm mainline / Ubuntu Noble mainline minimal Rock 5B Debian Trixie mainline Nano Pi M6 Noble mainline minimal / Noble Gnome desktop vendor Raspberry Pi 5** Debian Trixie minimal (see note) Banana Pi F3 Debian Trixie mainline minimal / Ubuntu Noble vendor minimal * Boards/images in bold blue type are personally tested by the author. Others may have issues or require additional steps provided by users below.
** For instructions on how to adapt this tutorial for the Raspberry Pi, see here (instructions are provided by a third party and are untested by the author).
 
You may have success with other boards/images too. If so, please post the details below (or open an issue in the mmgen-geek-tools Github repository), and I’ll add your board to the list.
 
Requirements:
A SoC with a running, upgradeable and Internet-connected Armbian system A blank Micro-SD card and USB card reader, or, alternatively, an eMMC installed on the board The ability to edit text files and do simple administrative tasks on the Linux command line  
Step 1 - Preliminaries
 
All steps in this tutorial are performed as root user on a running Armbian system (the “host”).
 
The encrypted system (the “target”) will be created on a blank micro-SD card (the “target device”).
 
If the board has an eMMC, it may be used as the target device instead of an SD card. Depending on your platform, you may need to run “armbian-install” and select “Install/Update the bootloader on MTD Flash” (preferable) or “Install/Update the bootloader on eMMC” to enable booting from the eMMC.
 
Architecture of host and target (e.g. 64-bit or 32-bit ARM) must be the same.
 
For best results, the host and target hardware should also be identical or similar.  Building on a host with more memory than the target, for example, may lead to disk unlocking failure on the target.
 
If you’re building the target system for the currently running board and with the currently running image, which is the recommended approach, the two preceding points will be a non-issue.
 
Packages will be installed using APT, so the host machine must be Internet-connected and its clock correctly set.
 
 
Step 2 - Upgrade your system and install the cryptsetup package
 
# apt update && apt upgrade # apt install cryptsetup  
Step 3 - Get and unpack the latest Armbian image for your board
 
Create your build directory:
# mkdir armbenc-build && cd armbenc-build  
Download the Armbian image of your choice for your board, place it in this directory and unpack:
# xz -dv *.img.xz  
 
Step 4 - Create mount directories and set up the loop mount
 
Create the mount directories:
# mkdir -p mnt boot root  
Determine your first free loop device:
# losetup -f  
Associate the image file with the loop device name displayed by the previous command.  This will be '/dev/loop0' in most cases, but if your output was different, substitute that for '/dev/loop0' in the following steps.
# losetup -P /dev/loop0 *.img  
Examine the disk image using fdisk on the loop device:
# fdisk -l /dev/loop0  
The output should look something like this:
Device Start End Sectors Size Type /dev/loop0p1 32768 61931519 61898752 29.5G Linux filesystem  
Make a note of the start sector (32768 in this case).  You’ll need this value in the steps below.
 
Now mount the loop device:
# mount /dev/loop0p1 mnt  
 
Step 5 - Copy the boot loader to the target device
 
If applicable, insert a blank micro-SD card and card reader into a USB port.
 
Determine the target device name using 'dmesg' or 'lsblk'.  We’ll assume it to be '/dev/sda', since that’s the most likely case.  If your device name is different, substitute it for '/dev/sda' in the the following steps.  For an eMMC, the device name will be something like '/dev/mmcblk1'.
 
WARNING: if '/dev/sda' refers to some other storage device, running the following commands unchanged will destroy data on that device, so always remember to substitute the correct device name!!!  The best way to eliminate this danger is to disconnect all unused storage devices on the board before proceeding further.
 
Determine whether your image has a GPT partition table or a legacy MBR (i.e. DOS) one. This can be done by running fdisk -l on the image file and examining the “Disklabel type” entry. For GPT images, also make note of the value in the “Type” column. On ARM devices, it’s likely to be “Linux root (ARM-64)”, for example. You’ll need this information soon when partitioning the target device:
# fdisk -l *.img  
Copy the image’s boot loader to the target device. With MBR-partitioned images, we use the Start sector value from Step 4 as the argument for 'count', while with GPT ones we skip the first 64 sectors and correspondingly subtract 64 from 'count', reducing the number of copied sectors by 64:
### MBR (DOS) images: # dd if=$(echo *.img) of=/dev/sda bs=512 count=32768 ### GPT images: # dd if=$(echo *.img) of=/dev/sda bs=512 skip=64 seek=64 count=32704  
 
Step 6 - Partition the target device
 
# fdisk /dev/sda  
At the fdisk prompt, create a new disk label with the 'o' command (for MBR images) or 'g' (for GPT images).  Use the 'n' command to create a partition of size +400M beginning at the same Start sector as the disk image (for MBR images, select the “primary” partition type).  Type 'p' to view the partition table, which should now look something like this:
Device Start End Sectors Size Type /dev/sda1 32768 851967 819200 400M Linux root (ARM-64)  
Use 'n' again to create another partition beginning one sector after the first partition’s end sector and filling the remainder of the device (for MBR, select “primary” again). Type 'p' once more to view the partition table:
Device Start End Sectors Size Type /dev/sda1 32768 851967 819200 400M Linux root (ARM-64) /dev/sda2 851968 120829951 119977984 57.2G Linux root (ARM-64)  
Ensure that the first partition’s Start sector matches that of the disk image (32768 in this example) and that the second partition’s Start sector is one greater than the End sector of the first (851967 and 851968, respectively, in this example).  If you’ve made a mistake, use 'd' to delete a partition and start again.
 
With GPT images, you’ll need to change the partition type of your two partitions to match that of the image. Type 'l' to list the known partition types and find the entry matching the value of the “Type” column you made note of above. Note the entry’s integer code and exit the pager with 'q'. Using the 't' command, change the type of your two partitions using this code. Type 'p' once again to view the partition table, which should now look something like this (depending on your platform):
Device Boot Start End Sectors Size Id Type /dev/sda1 32768 442367 409600 200M 83 Linux root (ARM-64) /dev/sda2 442368 30636031 30193664 14.4G 83 Linux root (ARM-64)
Once everything looks correct, type 'w' to write the partition table to disk.
 
 
Step 7 - Copy the system to the target device
 
The following commands will create a filesystem on the target device’s boot partition and copy the boot partition data from the image file to it.  Don’t forget to substitute the correct device name if necessary.  If you’re building the system on an eMMC, the boot partition device will be something like '/dev/mmcblk1p1' instead of '/dev/sda1'.
# mkfs.ext4 /dev/sda1 # or '/dev/mmcblk1p1', for an eMMC target # e2label /dev/sda1 CRYPTO_BOOT # mount /dev/sda1 boot # cp -av mnt/boot/* boot # (cd boot; ln -s . boot)  
Create the encrypted root partition.  When prompted for a passphrase, it’s advisable to choose an easy one like 'abc' for now.  The passphrase can be changed later with the 'cryptsetup luksChangeKey' command (type 'man cryptsetup' for details) once your encrypted system is up and running.
# cryptsetup luksFormat /dev/sda2 # or '/dev/mmcblk1p2', for an eMMC target  
Activate the encrypted root partition and create a filesystem on it:
# cryptsetup luksOpen /dev/sda2 rootfs # enter your passphrase from above # mkfs.ext4 /dev/mapper/rootfs  
Mount the encrypted root partition and copy the system to it:
# mount /dev/mapper/rootfs root # (cd mnt && rsync -a --info=progress2 --exclude=boot * ../root) # sync # be patient, this could take a while # mkdir root/boot # touch root/root/.no_rootfs_resize  
Unmount the boot partition and image and free the loop device:
# umount mnt boot # losetup -d /dev/loop0  
 
Step 8 - Prepare the target system chroot
 
# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT)) # ROOT_PART=${BOOT_PART%1}2 # ROOT_UUID="$(lsblk --nodeps --noheadings --output=UUID /dev/$ROOT_PART)" # BOOT_UUID="$(lsblk --noheadings --output=UUID /dev/$BOOT_PART)" # cd root # mount /dev/$BOOT_PART boot # mount -o rbind /dev dev # mount -t proc proc proc # mount -t sysfs sys sys  
Copy '/etc/resolv.conf' and '/etc/hosts' so you’ll have a working Internet connection within the chroot:
# cat /etc/resolv.conf > etc/resolv.conf # cat /etc/hosts > etc/hosts  
If you’re using non-default APT repositories, you may need to copy their configuration files as well so that 'apt update' and 'apt install' will use them inside the chroot.  Note that you can only do this if the host and target systems have the same distro/version.  If that’s not the case, you’ll have to edit the target files by hand.
# cat /etc/apt/sources.list > etc/apt/sources.list # cat /etc/apt/sources.list.d/armbian.list > etc/apt/sources.list.d/armbian.list  
If you’re using an apt proxy, then copy its configuration file too:
# cp /etc/apt/apt.conf.d/*proxy etc/apt/apt.conf.d/  
 
Step 9 - Edit or create required configuration files in the target system
 
Perform the editing steps below using a text editor of your choice:
If the file 'boot/armbianEnv.txt' exists, edit it so that the 'rootdev', 'console' and 'bootlogo' lines read as follows.  If you’ll be unlocking the disk via the serial console, then use 'console=serial' instead of 'console=display'. Note that enabling the serial console will make it impossible to unlock the disk from the keyboard and monitor, though unlocking via SSH will still work:
rootdev=/dev/mapper/rootfs console=display bootlogo=false If your image lacks an 'armbianEnv.txt' file, you’ll need to edit the file 'boot/extlinux/extlinux.conf' instead. All changes will be made to the line beginning with “append”. Alter the argument beginning with “root=” so that it reads “root=/dev/mapper/rootfs”. If you’ll be unlocking the disk via the serial console, remove the “console=tty1” argument. If not, remove the argument beginning with “console=ttyS...”. Replace the “splash plymouth...” argument with “splash=verbose”. Make sure to read the note about unlocking via serial console in the previous step.
Edit 'etc/initramfs-tools/initramfs.conf'.  If your board will have a statically configured IP, add the following line to the end of the file, substituting the correct IP in place of 192.168.0.88:
IP=192.168.0.88:::255.255.255.0::end0:off If the board will be configured via DHCP, then edit the DEVICE line as follows:
DEVICE=end0 If your default network device has a different name, say eth0, then use that instead of end0. The device name can be discovered by issuing the command ip link and looking for the device labelled link/ether.
If host and target systems are both Debian buster, you may wish add some key modules to the initramfs to avoid a blank display at bootup time.  The easiest way to do this is to add all currently loaded modules as follows: # lsmod | cut -d ' ' -f1 | tail -n+2 > etc/initramfs-tools/modules Retrieve the SSH public key from the remote unlocking host and copy it to the target:
# mkdir -p etc/dropbear/initramfs # rsync yourusername@remote_machine:.ssh/id_*.pub etc/dropbear/initramfs/authorized_keys If you want to unlock the disk from more than one host, then edit the authorized_keys file by hand, adding the required additional keys.
Create 'etc/crypttab':
# echo "rootfs UUID=$ROOT_UUID none initramfs,luks" > etc/crypttab Create 'etc/fstab':
# echo '/dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1' > etc/fstab # echo "UUID=$BOOT_UUID /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2" >> etc/fstab # echo 'tmpfs /tmp tmpfs defaults,nosuid 0 0' >> etc/fstab Create the dropbear configuration file:
# echo 'DROPBEAR_OPTIONS="-p 2222"' > etc/dropbear/initramfs/dropbear.conf # echo 'DROPBEAR=y' >> etc/dropbear/initramfs/dropbear.conf  
If the target is Ubuntu bionic, then a deprecated environment variable must be set as follows:
# echo 'export CRYPTSETUP=y' > etc/initramfs-tools/conf.d/cryptsetup  
Set up automatic disk unlock prompt. Performing this optional step will cause the disk password prompt to appear automatically when you log in remotely via SSH to unlock the disk. Using your text editor, create the file 'etc/initramfs-tools/hooks/cryptroot-unlock.sh' with the following contents: #!/bin/sh if [ "$1" = 'prereqs' ]; then echo 'dropbear-initramfs'; exit 0; fi . /usr/share/initramfs-tools/hook-functions source='/tmp/cryptroot-unlock-profile' root_home=$(echo $DESTDIR/root-*) root_home=${root_home#$DESTDIR} echo 'if [ "$SSH_CLIENT" ]; then /usr/bin/cryptroot-unlock; fi' > $source copy_file ssh_login_profile $source $root_home/.profile exit 0  
Save the file and execute the command:
chmod 755 'etc/initramfs-tools/hooks/cryptroot-unlock.sh'  
 
Step 10 - Chroot into the target system, install packages and configure
 
Now chroot into the encrypted system.  All remaining steps will be performed inside the chroot:
# chroot .  
Install the cryptsetup package and the dropbear SSH server:
# apt update # echo 'force-confdef' > /root/.dpkg.cfg # apt --yes install cryptsetup-initramfs dropbear-initramfs # for a buster or focal image # apt --yes install cryptsetup dropbear-initramfs # for a bionic image # rm /root/.dpkg.cfg  
Make sure everything was included in the initramfs (all three commands should produce output):
# lsinitramfs /boot/initrd.img-* | grep 'usr.*cryptsetup' # lsinitramfs /boot/initrd.img-* | grep dropbear # lsinitramfs /boot/initrd.img-* | grep authorized_keys  
Now regenerate your SSH host keys:
# ssh-keygen -A  
Your work is finished! Exit the chroot and shut down the board:
# exit # halt -p  
Insert your freshly written SD card into the board’s main SD slot (or, if the target is an eMMC, just remove the SD card from that slot) and reboot.

Unlock the disk by executing the following command on your remote unlocking machine, substituting the correct IP address if necessary:
$ ssh -p 2222 root@192.168.0.88  
If you performed step 9.10 above, the disk password prompt should appear automatically after login.  If not, you must enter the command 'cryptroot-unlock'.
 
You may also unlock the disk from the target board’s console if you wish.  Note, however, that certain disk images (RockPi 4 buster mainline, for example) might give you a blank display at startup, so you’ll have to enter your disk password “blindly”.  This bug will hopefully be fixed in the future.

If all went well, your root-filesystem encrypted Armbian system is now up and running!

This will cause update-grub to add the following a devicetree line to all menu entries. This example is based on Debian Trixie's grub-efi.
 
This example will expect dtb directories (or links) to be in the /boot directory, using the convention that I've seen Armbian use. Here is an example of a /boot directory listing for (pure) Debian Trixie with two kernels:
-rw-r--r-- 1 root root 336036 Aug 27 04:10 config-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 343394 Sep 6 12:48 config-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 42 Sep 20 16:17 dtb -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ lrwxrwxrwx 1 root root 43 Sep 20 16:17 dtb-6.12.43+deb13-arm64 -> ../usr/lib/linux-image-6.12.43+deb13-arm64/ lrwxrwxrwx 1 root root 42 Sep 20 16:18 dtb-6.16.3+deb13-arm64 -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ drwxr-xr-x 3 root root 4096 Sep 20 15:13 efi drwxr-xr-x 5 root root 4096 Sep 20 16:26 grub lrwxrwxrwx 1 root root 29 Sep 15 21:30 initrd.img -> initrd.img-6.16.3+deb13-arm64 -rw------- 1 root root 42521317 Sep 20 16:26 initrd.img-6.12.43+deb13-arm64 -rw------- 1 root root 43760872 Sep 20 16:25 initrd.img-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 30 Sep 15 20:38 initrd.img.old -> initrd.img-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 83 Aug 27 04:10 System.map-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 92 Sep 6 12:48 System.map-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 26 Sep 15 21:30 vmlinuz -> vmlinuz-6.16.3+deb13-arm64 -rw-r--r-- 1 root root 37449664 Aug 27 04:10 vmlinuz-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 41507328 Sep 6 12:48 vmlinuz-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 27 Sep 15 20:38 vmlinuz.old -> vmlinuz-6.12.43+deb13-arm64 Note: The relative pathways of the dtb links above assume that the /boot directory is part of the main OS partition, not on its own boot partition. Otherwise you'd need to copy those directories to /boot/ as Armbian does.
 
 
For The Current Partition's OS Entries (each devicetree will be specific to the respective kernel)
1. Open the file with a text/source editor (using sudo):
/etc/grub.d/10_linux  
2. Find every line that looks something like this (currently on my system, there is only one, and it's line 189)
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}  
3. Just above it, add your own system's version of this line:
devicetree ${rel_dirname}/dtb-${version}/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb  
Specific Example: OrangePI-5-Plus
devicetree ${rel_dirname}/dtb-${version}/rockchip/rk3588-orangepi-5-plus.dtb  
Specific Example from the resulting grub.cfg, of the current trixie-backport kernel, again on the OrangePI-5-Plus:
devicetree /boot/dtb-6.16.3+deb13-arm64/rockchip/rk3588-orangepi-5-plus.dtb  
 
For Other Partitions' OS Entries, via os-prober (I'm unfamiliar with the variables in this so each devicetree will be the same generic path, regardless of kernel)
1. Open the file with a text/source editor (using sudo):
/etc/grub.d/30_os-prober  
2. Find every line that looks something like this (currently on my system, there are two, lines 277 and 297)
linux ${LKERNEL} ${LPARAMS}  
3. Just above it, add your own system's version of this line:
devicetree /boot/dtb/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb  
Specific Example: OrangePI-5-Plus
devicetree /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb  
 
Then run update-grub, and take a look at the resulting /boot/grub/grub.cfg