The Armbian variant of 2017.09 based for ROCK5B has enough changes/patches such that it runs mainline based Armbian based rockchip64 kernels AFAIK. But never used it on my ROCK5B after many issues with 2017.09 flavors on my ROCK3A, which also was due to PSU (it wants >5V else what should the on-board DC/DC do then). Inside the EDK2 UEFI v1.1 binary there is also the lower level 2027.09 SPL still but the higher level / bigger functionality should be EDK2 based. I don't know exactly how it is all interacting. Maybe a warning is that this UEFI based only is fine if you do not need any special HW (from 40-pin header for example). Also if you use GRUB, there is no support for overlays, so the M.2 E-key slot just stays PCIE2x1 instead of SATA6 when you use the Radxa SATA M.2 E-key breakout adapter, which I do. But luckily that setting is in the EDK2 'BIOS' menu and stored in SPI-flash, so even without loading the devicetree, a rolling release distro generic aarch64 kernel (>= 6.19 works I know) and my 8T SATA HDD is there. I made a sort of automatic change in /etc/grub.d/10_linux so the .dtb was loaded, but then panic days later as my HDD kept ticking like bad sector (so dead I thought) when reboot. Of course it overwrites the devicetree done by EDK2 so default to PCIE2x1 for the multi-PHY in the RK35xx. Also, if boot.scr (or a valid extlinux folder) is found in the first/boot partition, EDK2 UEFI will fall back to that, so make sure to hide/move those. I see I still have this (gdisk -l /dev/nvme0n1) Number Start (sector) End (sector) Size Code Name
1 32768 1081343 512.0 MiB EA00 XBOOTLDR partition
2 1081344 26247167 12.0 GiB 8300 Linux filesystem
3 26247168 38830079 6.0 GiB 8300 Linux filesystem
4 38830080 63995903 12.0 GiB 8300 Linux filesystem
5 63995904 76578815 6.0 GiB 8300 Linux filesystem
6 76578816 391151615 150.0 GiB 8300 Linux filesystem
7 391151616 953188351 268.0 GiB 8E00 Linux LVM
8 953188352 976773119 11.2 GiB 8200 Linux swap
This still works with native/plain/original U-Boot and rk35xx vendor based 6.1 kernel, but I think not in an ARM64 computer that has closed-source UEFI (e.g. like an x86 PC) as that needs ESP, so 0xEF00 instead of 0xEA00 But easy to change, same as un-hiding boot.scr etc. I actually think 0x0700 or 0xEF00 or 0xEA00 all should not matter for U-Boot, at least if there is just 1 path/choice. But if multi OS and the option to store bootpath in SPI-flash (run efibootmgr ), you also can have multiple EFI partitions in theory so not sure what the various bootloaders for ROCK5B will do then. But I keep it simple 1 shared EFI/boot partition. Another note is that (I think) Armbian Build on Debian Trixie cannot build (older) U-Boot like 2017.09 based, you need (older) Ubuntu for that. I use my ROCK5B Armbian Trixie for building u-boot and kernels, I have no Docker installed as that changes up my networking beyond my own understanding, so for stuff connected to internet, I removed all potential show-stoppers and complexity (for me).
