I’ve long been interested in new and different platforms. I ran Debian on an Alpha back in the late 1990s and was part of the Alpha port team; then I helped bootstrap Debian on amd64. I’ve got somewhere around 8 Raspberry Pi devices in active use right now, and the free NNCPNET Internet email service I manage runs on an ARM instance at a cloud provider.
ARM-based devices are cheap in a lot of ways: they use little power and there are many single-board computers based on them that are inexpensive. My 8-year-old’s computer is a Raspberry Pi 400, in fact.
So I like ARM.
I’ve been looking for ARM devices that have accelerated AES (Raspberry Pi 4 doesn’t) so I can use full-disk encryption with them. There are a number of options, since ARM devices are starting to go more mid-range. Radxa’s ROCK 5 series of SBCs goes up to 32GB RAM. The Orange Pi 5 Max and Ultra have up to 16GB RAM, as does the Raspberry Pi 5. Pine64’s Quartz64 has up to 8GB of RAM. I believe all of these have the ARM cryptographic extensions. They’re all small and most are economical.
But I also dislike ARM. There is a terrible lack of standardization in the ARM community. They say their devices run Linux, but the default there is that every vendor has their own custom Debian fork, and quite likely kernel fork as well. Most don’t maintain them very well.
Imagine if you were buying x86 hardware. You might have to manage AcerOS, Dellbian, HPian, etc. Most of them have no security support (particularly for the kernel). Some are based on Debian 11 (released in 2021), some Debian 12 (released in 2023), and none on Debian 13 (released a month ago).
That is exactly the situation we have on ARM. While Raspberry Pi 4 and below can run Debian trixie directly, Raspberry Pi has not bothered to upstream support for the Pi 5 yet, and Raspberry Pi OS is only based on Debian bookworm (released in 2023) and very explicitly does not support a key Debian feature: you can’t upgrade from one Raspberry Pi OS release to the next, so it’s a complete reinstall every 2 years instead of just an upgrade. OrangePiOS only supports Debian bookworm — but notably, their kernel is mostly stuck at 5.10 for every image they have (bookworm shipped with 6.1 and bookworm-backports supports 6.12).
Radxa has a page on running Debian on one specific board, they seem to actually not support Debian directly, but rather their fork Radxa OS. There’s a different installer for every board; for instance, this one for the Rock 4D. Looking at it, I can see that it uses files from here and here, with custom kernel, gstreamer, u-boot, and they put zfs in main for some reason.
From Pine64, the Quartz64 seems to be based on an ancient 4.6 or 4.19 kernel. Perhaps, though, one might be able to use Debian’s Pine A64+ instructions on it. Trixie doesn’t have a u-boot image for the Quartz64 but it does have device tree files for it.
RISC-V seems to be even worse; not only do we have this same issue there, but support in trixie is more limited and so is performance among the supported boards.
The alternative is x86-based mini PCs. There are a bunch based on the N100, N150, or Celeron. Many of them support AES-NI and the prices are roughly in line with the higher-end ARM units. There are some interesting items out there; for instance, the Radxa X4 SBC features both an N100 and a RP2040. Fanless mini PCs are available from a number of vendors. Companies like ZimaBoard have interesting options like the ZimaBlade also.
The difference in power is becoming less significant; it seems the newer ARM boards need 20W or 30W power supplies, and that may put them in the range of the mini PCs. As for cost, the newer ARM boards need a heat sink and fan, so by the time you add SBC, fan, storage, etc. you’re starting to get into the price range of the mini PCs.
It is great to see all the options of small SBCs with ARM and RISC-V processors, but at some point you’ve got to throw up your hands and go “this ecosystem has a lot of problems” and consider just going back to x86. I’m not sure if I’m quite there yet, but I’m getting close.
Update 2025-09-11: I found a performant encryption option for the Pi 4, but was stymied by serial console problems; see the update post.
@jgoerzen
I was running a number of RPi4 boards for various tasks. I now have a cluster of 5 mini PCs running Proxmox. 3 of them were leftovers I had from older desktop/media PCs and 2 are newer devices for heavier lifting. I changed for reasons you mentioned… Upgradeability, compatibility, encryption, etc
Remote Reply
Original Comment URL
Your Profile
One thing I can’t seem to understand is why the low-power side of things doesn’t seem to have progressed beyond the Raspberry Pi 3 speeds. Does nobody care about that market segment any more, or is there some reason that low-power performance has stagnated?
@matt Thanks! I hadn’t seen that before. Glad to know of it.
@matt If you’ve got Linux running on it, cat /proc/cpuinfo will probably have something to indicate that. It looks like it does; I went to https://radxa.com/products/rock5/5b/#techspec which led me to https://www.armdesigner.com/download/Rockchip_RK3588_Datasheet_V1.7-20231117.pdf which says it has “ARMv8 Cryptography Extensions” which is the magic thing you want to have.
Radxa ROCK 5B
@jgoerzen we decided to go back to SPARC instead, for similar "dear gods, we just want it to work" reasons
Remote Reply
Original Comment URL
Your Profile
You went back to SPARC? Now I am intrigued! What kind of SPARC systems are you using and for what kinds of tasks?
@jgoerzen got a Sun Blade 150 running a heavily modified Solaris 10 1/13, she's currently running DHCP, DNS, NIS, rarpd, bootparamd, and tftp boot, and will likely end up being our https reverse proxy server to allow extertnal users access to locally hosted web services, and we have a Sun Fire T1000 that we're setting up as a Solaris 10 automated build host to automatically download, build, sign, and package a large number of modern packages for that OS on sparc64
Remote Reply
Original Comment URL
Your Profile
@jgoerzen we would like to see some openSPARC-T2-based SBCs, even just like small-scale dual-core implementations of that design, given that right now, OpenSPARC is right about the most open ISA and CPU design there is, we'd love to see like a SPARCpi based on two OpenSPARC-T2 cores, that'd be 16 threads due to CMT, that would be super cool
Remote Reply
Original Comment URL
Your Profile
Interesting! It’s too bad that sparc64 isn’t a release architecture most places anymore.
@jgoerzen yeah, mostly because people went "SPARC? that's Sun, that's bad" and ran the fuck away, not helped by oracle being, uh, assholes
@jgoerzen Debian still runs SPARC64, NetBSD and OpenBSD still do, Solaris still does, Illumos does…
Next time buy a device supported by Armbian: https://www.armbian.com/
I’m running NanoPI R4S and a couple of NanoPI R2S, and I can upgrade Armbian without problems.
I looked into Armbian, but according to https://docs.armbian.com/User-Guide_FAQ/#can-i-upgrade-my-userspace-flavor-like-bullseye-to-bookworm-or-jammy-to-noble such upgrades aren’t supported. I also much prefer Debian’s long-term release cycle to Armbian’s, which seems to have a new release every 3 months (requiring a reinstall?) It’s a bit confusing since they seem to be based on Trixie, Ubuntu, or some other OSs sometimes.
Also I strongly prefer having the same environment everywhere. Makes it a lot easier to manage. Having different OSs for each different architecture makes that difficult.
John – You can persuade a Raspberry Pi 4 to run UEFI and then stock Debian will “just install” – there is at least one blog on this.
The Radxa 5 ITX can also be persuaded to run Debian but I haven’t tried an upgrade to Trixie. Blog from Steve on this one.
But yes, the ARM and RISC-V ecosystems are full of barely-maintained forks of Debian built on vendor kernels :(
You can upgrade images, just distro upgrades are upstream thing thus not something Armbian could guarantee to work. But generally works. Armbian is not different then Debian or Ubuntu in this sense.
@jgoerzen Thanks for all those details. Yes, it's a big mess, and I think Raspberry Pi "gets it" the most of all the ARM SBC vendors you mentioned – they are the closest thing to a "good guy" in that ecosystem. Raspberry Pi will certainly support a trixie-based Raspberry Pi OS (but not stock Debian) in the months ahead. As to doing an in-place upgrade from 12 -> 13, they have a forum post explaining how, but it's an ugly, messy process.
Remote Reply
Original Comment URL
Your Profile
Have a look at ASRock 4×4. while the N100-like option exists, I’d go for a proper cpu. especially the AMD high-end ones that are still below $500.
@jgoerzen
this isn't entirely the point of the article, but do note that upstream support for the rock 5 family has progressed pretty far: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md
Remote Reply
Original Comment URL
Your Profile
In my post yesterday, ARM is great, ARM is terrible (and so is RISC-V), I described my desire to find ARM hardware with AES instructions…
In an update to yesterday’s post, I found I could get reasonably good full-disk encryption on a #RaspberryPi 4 with the xchacha12/Adiantum configuration.
BUT, there is no way to enter the passphrase at boot when trying to use a USB-to-serial device.
If you like, follow me down this path of encryption and weird Pi UARTs (one of which changes its baud rate when the VPU clock speed changes).
https://changelog.complete.org/archives/10868-performant-full-disk-encryption-on-a-rasberry-pi-foiled-by-uarts
RaspberryPi
Performant Full-Disk Encryption on a Raspberry Pi, but Foiled by Twisty UARTs | The Changelog
@ttyS1 Thanks! I wish it wasn’t, though.
Most of the problem with RISCV in my experience is that it just takes absolutely feckin forever to get stuff upstreamed. I have a SpacemiT M1 board right now, and they are upstreaming it so it will eventually have general Debian support for example. But that’s been a project for more than a year now, and it’s still not bootable. The VisionFive2 is completely upstreamed, and having just done a completely bog-standard Debian 13 install on it a few weeks ago I can definitively say that it’s seamless, with no real problems. Boot to USB Just Works ™, and the installer happily runs and installs to the NVMe drive. The only real blocker from using it like a normal desktop is Imagination (GPU IP owner in both the VisionFive and SpacemiT chips) taking forever to upstream their port of mesa.
I can’t speak to Arm in any capacity, but RISCV seems to be pretty readily targetting UEFI nowadays, meaning installs are easier, and they’re working harder than I’ve seen for Arm stuff to upstream their patches (in all likelihood so they can drop official support for their old boards in favour of the new shiny, but that’s my own conspiracy theory)
Not trying to disagree with your observation of the current state of affairs. But I do feel like there’s a lot more intent to make RISCV computing of all shapes and sizes better than the Arm SBC dumpster fire.
I hold out a lot of hope for RISC-V. It is great to see it as a release architecture in Debian now, and growing support. From what I can see, the performance of current boards (and the ones supported by Debian) is disappointing, but RVA23 seems to be doing a lot of good in advancing the platform.
More open hardware can only be good for everyone, and I hope that RISC-V advances more quickly in the near future.
I was just talking about the state TODAY, and as you say, things haven’t always been upstreamed very fast — but I am glad to see attention to that issue and hope it changes soon!
today arm and risc have blobs for running linux ;(
in network (ethernet, wifi, bt etc) and sometimes in normal boot motherboard.
this is still big problem
Arm is not efficient. Show me any board computer, Raspberry Pi or other, that works twice as long as x86.
All laptops work the same (too short). It’s not a week, it’s not a month on a single charge. It’s hours, and well below 24.
You’re partially right: sbc arm ecosystem is crappy, with their cheap components and vendors who don’t care as soon as the product is shipped or rely on “community” (aka free labor) are part of the problem.
Arm has been pushed in the right direction by Red Hat and others in order to create and adopt the Server Base System Architecture standard. But this has server or workstation as target:
– https://system76.com/desktops/thelio-astra-a1.1-n1/configure
– https://www.adlinktech.com/Products/Computer_on_Modules/COM-HPC-Server-Module/Ampere_Altra_Developer_Platform?lang=en
– https://www.mifcom.de/workstations-ampere-altra-cid774
Nonetheless if you search there are a lot of project that ported Tiano Core UEFI firmware to the various SBC boards (e.g. github.com/pftf/RPi4) to bring such seamless experience.
Installing UEFI on your SBC will make your life easier, but a lot depends on the porting: it may happen that not all devices present in the SBC works.
While you’re right that the RaspberryPi people does not support nor endorse standard dist-upgrades for their linux distribution, they did provide a guide for going from bookworm to trixie on their forum.
The thread is called “Updating to trixie” and was posted by spl23 (“Raspberry Pi Engineer & Forum Moderator”) on July 1, 2025.
I’ve done it and it worked fine, but I have a very vanilla installation.
Anyone attempting this should definitely first read through the thread for caveats and potential issues.
Link: https://forums.raspberrypi.com/viewtopic.php?t=389477
I think maybe I should state this more generally:
We have a number of operating systems that support a wide set of architectures and platforms. Hardware vendors are using these, but are not sending their changes upstream. As end users, it is neither sustainable nor secure to expect to use a different OS for every different brand’s board. Raspberry Pi OS lags Debian with its releases, officially states it doesn’t support upgrades (yes I have unofficially done them in the past, but still), and makes some other questionable decisions as well.
It’s all fine if they want to offer a fork as an option. But making it a REQUIREMENT, that I dislike.