this post was submitted on 13 Jan 2026
26 points (100.0% liked)
Linux
11069 readers
1056 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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)
@sga
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.