Linux on (non-Apple) ARM, what is the current status?
Qualcomm Snapdragon, Ampere and maybe others. Support of Snapdragons was said to be quite bad due to the lack of upstream “giving a damn about Linux”.
Has this changed?
It’s been continuously improving. There are devices that are a hassle but you’re a lot more likely to have things Just Working compared to a few years ago.
My understanding is that Ampere and others should run perfectly like any old x86 with a normal dist like vanilla Debian mostly due to a lot of hard work from individuals in the wider community.
Much of the time, dtb (device tree) and device drivers are what it comes down to.
For more estoric or finicky hardware, I think the dists with the best ARM support are Armbian, OpenWrt, and PostmarketOS.
Jeff Geerling has been reporting a lot about his experiments. https://www.jeffgeerling.com/
I wrote about getting Debian running on a device based on a popular Rockchip SoC last year. I assume the kernel situation has improved since trixie. https://blog.kumio.org/posts/2025/01/bananapim7-hvm.html
Well, my Raspberry Pi 5 works perfectly.
Huh, so does my Zero W 2.
The Steam Frame will be powered by a Qualcomm Snapdragon arm CPU with Full SteamOS support, so I guess if Valve goes for it it’s good enough and will improve faster.
But I’ve never installed any Linux distro on an arm device myself.
if i am not wrong, boot process on non x86-64 is not standardised (no obivous uefi independent of os or setup). this genuinely limits the distros one can find, and mostly first party support is all you get. when first party does linux (raspberry pi or other sbcs), it is fine, and often their boot can be “used” by other third party distros (assuming license allows that). if first party does not, there is no way to get work done. something like android - if you get first party unlockable boot lock, you can hope for custom roms, without that, its playing darts where board is invisible. with apple mac, enough people had dart boards that random trial (and recovery processes) allowed them to get in. with qualcomm stuff, there is some first party support (and some second party support from nvidia who use qualcomm cpu for their servers) but qualcomm graphics is still a issue (first party support is very slow) and not enough third party interest (not enough people have qualcomm laptops for dartboards)
Well, Asahi development was not random dart throwing. They used some VM that can be loaded in an early boot stage, which apple then removed on later devices, making m4 way harder to support.
On Android, a locked bootloader means you cannot change the core operating system. It has nothing to do with how documented or standards compliant the rest of the system is.
Thank you for telling that, I absolutely had no idea about that. In my mind, it has been a almost brute force reverse engineering effect, with some help from some documentation (for example, reference metal docs) or having some open source stuff for apple stuff (if that even exists).
regarding bootloader, is it not the case that bootloader just checks for signature of os, and it does not allow you to boot anything else. I did not mean that having a bootloader unlockable means having docs, but as i get it, the general approach to get android image working is to load a gsi (generic system image), if that does not work, we swap kernel or some other system stuff from available os images (which are closed black boxes mostly). now if we can not even boot a gsi (or some other android tree for lineage os), then there is no hope in running anything. and even if gsi runs, that may still have broken stuff (eg, camera or wifi, which i know are some of common culprits).
This isn’t exactly true. UEFI supports arm and if I’m not mistaken windows on arm is UEFI only. While UEFI isn’t as standard as it is in the PC world it is very common on servers and windows devices.
i had no idea about this either, thanks for telling. I have almost no idea about server stuff.
There recently was a project that did UEFI on a phone.
Perhaps we can consider doing so with all ARM and RISC V stuff?
Or maybe come up with another common interface more suited to the platform?Considering Qualcomm went and 1TKO’d Arduino, I’d say we are better off not waiting for it to get onboard.
i typically imagine the mess of qualcomm drivers is part of the reason why its hard. regardless of the OS, be it windows, android and in this case, linux, driver support has generally been spotty for snapdragon products.
im curious on what the upstream stuff valve is pushing with its steam frame, as its of the few known companies actually paying for development for arm on linux. the device isnt out yet, but should be opened up within the quarter supposedly.
Qualcomm is merging a lot of drivers for snapdragon 2. Seems like theyre trying to improve on the failure that was snapdragon 1 on linux.
I’d like to know more about it too.
So far, from what I know, the main problem is the drivers for everything but CPU. Linux runs perfectly on ARM, be it Apple or not, but when it comes to something like a video adapter… with HW-accelerated video decoding and stuff… here’s where you start getting problems.
Regarding software, I run an ARM-based distro inside a VM on Apple for work and everything from what I need there exists and works.
pine64 has quite a few devices running different distros, but thats more like low end devices (thoigh they have a tablet, a laptop, phones etc.)
