The gap for generic arm64 has been closing a lot in recent years. These days IME the vast majority of fiddling doesn't have to do with the ARM SoC/CPU itself bu

The gap for generic arm64 has been closing a lot in recent years. These days IME the vast majority of fiddling doesn't have to do with the ARM SoC/CPU itself but rather with getting the right dtb (and sometimes firmware) for other integrated hardware, and u-boot. These issues aren't really inherent to the architecture per-se, more tied to the setups and practices for the kind of devices you tend to find available ARM SoCs/CPUs in. IME from dealing with embedded x86 devboards some years back it was a similar situation. I'd assume units marketed for server loads are comparable to x86 equivalents. I've been trying out Arch Linux on ARM on a secondary workstation recently. In most cases the only thing needed to get a non-supported package working is to add 'aarch64' to the list supported architectures in the PKGBUILD and then proceed like normal. > You’re even luckier if the ARM CPU manufacturer releases documentation about how their chips work …. They prefer to keep inner workings secret. This is the bigger practical issue. Rockchip are in general good, while the kind of chips you find in flagship phones require significant reverse-engineering are unapproachable for the non-hacker. But again, not so much "software-to-CPU", more "drivers-to-everything-around-the-CPU".