Armbian distro support for SBCs

[sairuk]

We are considering switching our primary focus for Arm SBC's to Armbian (moving away from RPIOS).

Why?

• Closer to base x86/x64 Debian than RPIOS
• Work we want to do (e.g. firewall) is on hold because customization and tooling choices in RPIOS complicate things
• Wider range of SBC support, you can probably find stock of something

Armbian boasts support for a number of SBCs. It also does generic intel machines, although I've not tested that.

We will still continue to support RPIOS in its current state but some new features may not be able to be installed until RPIOS starts to move closer to a vanilla release. Some of that work is already planned; when they do it should just work with whatever we are doing. Although we can specifically test as we move forward.

I am going to be re-rolling my RPI4 RetroNAS to Armbian full time soon to see how it goes. I also recently setup a RockPI4 SE with RetroNAS on Armbian to test it out; everything seemed to work fine, including taking my (production/main) RPI4 RetroNAS profile and letting it reinstall on Armbian, it did so without issue.

Opening the floor to the community for comments, concerns or suggestions

[sairuk]

Take a look here at the SBC support https://armbian.tnahosting.net/archive/

Looks like they only support Ubuntu based distros for rpib4? that in itself is problematic for a few things so maybe this wont work out. need to look into it further

[danmons]

From what I can tell, a fair chunk of them dual-support Ubuntu (currently Jammy) and Debian (currently Buster). I think standardising on "vanilla Debian Buster" (or whatever is current Debian Stable into the future), including Armbian for ARM SoCs as a target is a fair call, as that would cover almost any bit of hardware around right here and now, and then we can deal with edge cases of things that do or do not work as they pop up.

I've just got myself an Orange Pi 5 delivered, and it is supplied by the vendor with a Debian Buster distro (custom kernel missing some useful things we require for advanced stuff, but the main OS/distro is all there for most userspace stuff).

Going with "Debian/Armbian" as the target, RPiOS can be considered a fork of sorts, and I think 95% of our stuff will work with it fine. Of note, all of the SMB/CIFS/NFS/HTTP/PS2/PS3/GC type stuff that requires nothing from the kernel other than UDP/TCP works on everything I've tested to date. Whatever's missing (specific protocols like AppleTalk or iSCSI, as an example) we can put in a todo and investigate on a platform-by-platform basis when time permits.

Most of these non-standard tools at least give kernel sources/headers/config, so building loadable kernel modules for edge cases isn't out of the question. We already do this for at least one protocol from memory (my memory is hazy, but I remember building a kernel module for one of the tools we added a while back).

This will likely futureproof us for the next generation of SoCs as well, with things like RISC-V already beginning to grow in popularity. I'm certain there'll be a wild array of weird Debian forks for those too, and in a similar vein standardising on a more centralised, less vendor-specific Debian project for those will help us in the future.