X86 absolutely destroys ARM in the software front. Give me an x86 cpu and I can run any version of linux on it with wide hardware support.
Give me a random ARM computer, you’re lucky if you can get it to boot.
You’re even luckier if the ARM CPU manufacturer releases documentation about how their chips work …. They prefer to keep inner workings secret.
Arm came up with a bunch of standardisation requirements quite a while ago (see: https://developer.arm.com/architectures/system-architectures...) which have been quite successful especially for server designs.
That was an absolute requirement in order for AArch64 to even be considered as an alternative in the datacenter space where it is now a very compelling alternative to x86_64.
What I mean specifically is standardised support for firmware, hypervisor and operating system kernel interfaces for things like system bootstrap, power-perf control etc. Think ACPI, EFI, CPU capability discovery, DVFS, Idle management etc.
Being unable to boot Linux on modern AArch64 server class hardware is actually increasingly rare thanks to the standardisation.
Your comments are more applicable to the general Arm embedded systems scene where fragmentation is understandably rife. It was the price Arm had to pay to keep its royalty model in flight - "Pay the license fee, do what you will with the design".
That's wildly inaccurate. Many distributions have ARM builds that works perfectly fine (at least for me, YMMV), have you tried any of them?
Here is some of them:
- Arch Linux - https://archlinuxarm.org/
- Ubuntu - https://ubuntu.com/download/server/arm
- Alpine Linux - https://alpinelinux.org/downloads/
- Elementary OS - https://blog.elementary.io/elementary-os-on-raspberry-pi/
- NixOS - https://nixos.wiki/wiki/NixOS_on_ARM
Documentation is also excellent. ARM docs are really good, and go in much more detail than Intel and AMD docs about the inner working of their cores.
That’s what we expected, since ARM licenses all their IP, and that’s what our vendor delivered. Everything we wanted to know about the Hw, there were docs and training materials ready for it.
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".
And what about new chips? Look up datasheets for e.g. the (now popular) RK3566. You get a 58 page document which is just a general overview plus pinout and not much else. Does fuck all for you if you actually want to write drivers and get the thing to work.