this post was submitted on 20 Aug 2024
141 points (93.8% liked)
Technology
59989 readers
3015 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
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
I found this very interesting detailed writeup from a developer of Asahi Linux about the difference in the boot process from an Intel UEFI and the current Apple silicon, starting at the M1. Mind you, this is from 2021, and surely some things have changed in respect to the M3, but this can give folks a general idea of maybe what to expect from BIOS/UEFI alternatives in the ARM chip space.
Comment from Hackernews: https://news.ycombinator.com/item?id=26114417
More detailed writeup on Github: https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
Apple is Apple, it's not a super great example. They already had iBoot from the iPhones and iPads that they just adapted for the laptops, which is also what the M chips are. Apple's firmware has always been rather quirky compared to more standard machines.
If you look at the cloud, like AWS and their Graviton instances, they use plain old regular UEFI but ARM, which then can load GRUB and the kernel as usual there. Completely generic and basically the same as x86_64 UEFI. You can load any generic ARM distro there. We already know what ARM PCs would look like.
The main thing here isn't really x86 vs ARM, it's embedded vs PCs. You can totally have non-BIOS and non-UEFI compatible machines with x86 CPUs in them, but I only saw this being done embedded in devices, in my case those were industrial machines. With ARM you'll also see U-boot which is common in stuff like routers and IoT devices because it's fairly easy to get working and can be controlled with serial ports. But for PCs, it's gonna be UEFI if anything because Windows support. In the end, CPU is CPU, it runs code.
Why not UEFI everywhere then? Because it's overkill most of the time, and orders of magnitude more code and complexity which you just don't need for a router. Your router can start executing its operating system directly from flash. You know in advance where the kernel is located, you don't need to start initializing PCIe devices and a SATA controller and scan disks for GPT headers and find an EFI partition formatted as FAT32 to find an executable to load into memory and execute, no graphics card to initialize, no keyboard and mouse to monitor for menu, no menus to display because there's no options, etc. UEFI firmwares aren't small. The arm64 OVMF firmware for QEMU is a whopping 64MB, that's more flash than my router even have.
A bootloader is a bootloader is a bootloader be it grub or legacy or uefi or coreboot. However most hardware that isn't a phone or an appliance, be it firewall or smartfridge have a BIOS which might be the nature of the original question.
Why's it so goddamned hard to put desktop linux on my phone.
A functional desktop Linux is hard. Getting desktop Linux to boot and run stuff isn't that hard in itself.
The problem is mostly drivers. They're made for Android specifically, and often for that device specifically as well, so getting them working outside of Android is hard. The second problem is of course manufacturer obstacles, they really don't want you to do that.
Technically getting a kernel and a working framebuffer is fairly "easy", because it's mostly already there, you could just replace the initramfs and run whatever init and software you want. It's getting the GPU to do stuff that's a lot harder. WiFi is alright but cellular is a complete nightmare. A lot of those are Java native libraries, which makes it non-trivial to use outside of the Android Framework. But all the kernel stuff, you already have ready to steal right from the manufacturer, or you can take the ones LineageOS uses. It's only a matter of getting a useful userspace.
And the phone landscape on Linux isn't that interesting, so people's attention have been around improving Android itself as it's much more capable and mature, and is open-source. If Android was closed source we'd have Linux phones already, but for many FOSS entheusiasts, Android is fine and much better polished.
If you're lucky, PostmarketOS might support your device well. If you're less lucky you might get a kernel that boots but you can only get a serial shell to it over USB. If you're unlucky, nothing exists, and you have to do it yourself.
Oh hey sorry, I agree on all those points. I run a hacked kernel on my phone from the Ubuntu touch days. I know what a binary blob is. I was joking that the OP was asking asking the desktop linux on a phone question.
RISC-V may be of interest to you