Every now and then someone asks "why can't I just try installing Asahi on an M3 or M4 even if they aren't supported?".

The answer is, because that would make no sense. Apple Silicon machines do not have a standard platform firmware like EFI/BIOS. We are writing that for them. That means that for every single machine Apple releases, we have to do the work to configure everything. At the very least, for new machines on existing SoCs, that means writing device trees and porting drivers to new firmware interfaces (since every new machine means a new baseline firmware version).

With new SoCs like M3 and M4, that means we even have to write things like CPU initialization code. If you try to run our existing bootloader on M3 or M4, it would barely run a few instructions before failing because it has no idea how to configure the CPUs to work properly.

So no, you can't install Asahi Linux on M3 until we support it, and you can't try either "just to see what happens". Sorry.

Apple Silicon Macs are not PCs, they do not work like PCs, and there is no baseline standard firmware interface to run anything on them like on PCs.

@marcan Can't they akschually try to see what happens just to find out the answer is "largely nothing"? :P

@marcan is this like with Android phones where you have to port the custom ROMs to every new model?

@me @marcan
yes

arm macs are very much like phones, routers, game consoles in this regard

@tthbaltazar @me @marcan Someone said "I wish the iPad ran Mac OS X/OS X/macOS", the monkey's paw curled, and we got the ARM Macs of today.

@marcan this is my issue when the M1 came out and everyone was praising it like crazy. Like ... sure it's more efficient for battery life ... is that worth having laptops now firmware-locked like phones are?

Shit, the more time passes the more I'm realising that the relaticely open PC was an anomaly. If it were up to these companies (especially Apple because they seem to get away with everything), you'd never have owned a computer ever

@engravecavedave There are no firmware locks. The platforms are open to third-party OSes. It's not a phone. There is a whole user-controlled secure boot mechanism that allows you full control over what you approve to boot on your machine and not.

Heck, if anything, you have more control than on a PC, since on a PC you don't get to change or modify the low-level platform init code to the extent you do on a Mac.

They just don't ship with a standard firmware layer. You can love or hate that, but it doesn't make them "locked".

@marcan And its why I'll never buy one, I'll wait for an ARM system with a much more standard BIOS.

@CommieGIR You might *think* a more standard BIOS would help, but even on PCs, that's partially a thing of the past. It will help with supporting new hardware to an extent, but not new SoCs. Even on PCs these days, you do not have a usable machine unless you run a kernel that has things like GPU drivers updated specifically for your hardware.

@ozzelot @marcan
Correction: Absolutely nothing. I’m not sure the kernel is even compiled for M3 or M4 if the configuration for those machines doesn’t exist.

@tertle950 @ozzelot If you managed to hack the installer enough to get the installation process to succeed, you would end up at a black screen as the bootloader would halt after it fails to initialize the CPUs. You wouldn't get anywhere near a Linux kernel.

@marcan UEFI still emulates and supports BIOS-like options and and is still far more open than what Mac does.

@CommieGIR BIOS does not exist on ARM machines, UEFI is pure UEFI only. CSM is for x86 machines.

Feel free to try ARM SystemReady systems (which is the spec for "standard UEFI stuff on ARM"), but from what I hear, you aren't going to have an x86-like experience there either. Sure you'll probably get a framebuffer console or something with an unsupported kernel, but not much more.

Ultimately, does it matter? Why do you care who writes the UEFI layer for your machine, the manufacturer or us? With our work, Apple Silicon machines are easily the best supported ARM platform on Linux today in the desktop/laptop space.

@marcan Ah, true, but I think there should be an attempt to create a bootloader that emulates BIOS/UEFI.

@CommieGIR That's what we do, U-Boot provides the UEFI layer on Asahi Linux systems. GRUB (a pure UEFI app) needed zero changes to work on Macs after our firmware enablement.

@marcan @tertle950 And installing Asahi, booting the bootloader, initializing the CPUs, that's already a lot of something in my book. "Absolutely nothing" would be, to me: "The device has no reaction whatsoever to any attempts at running the specified operation."

@marcan I used to hate PCs. They are misdesigned and boring. But every single ARM machine is e-waste or quickly becoming one, while PC-compatible 386sx is still fun machine today. PC world is doing stuff right :-(.

@CommieGIR @marcan There's no such thing as "emulating BIOS/UEFI". There's no "BIOS" on ARM.

You have six major options:
- EDK2 (which sucks, it's codebase is a disaster - but it can boot WoA because it has complete implementation of UEFI services)
- U-Boot with UEFI implementation: Has sane implementation of UEFI services that can "load" PE32 executables, but works only with Linux and BSD (so it likely wouldn't get certified for SystemReady)
- XBL (Qualcomm's cursed implementation of EDK2 on every non-automotive Qualcomm SoC past SDM820)
- Little Kernel (used on Android phones/IoT devices)
- coreboot with depthcharge payload (Google devices like Chromebooks, Chromeboxes, Routers, Nest products etc)
- iBoot

AFAIK Asahi uses U-Boot UEFI that loads GRUBA64.EFI, and then loads the Linux kernel - which is the sanest option.

If you think Ampere or something along those lines is better - you would be *very* disappointed. Ampere won't give you access to their Trusted Firmware sources (much like Intel/AMD FSP, but they're much worse). You will see exactly zero documentation from them, only contact to engineer who you will have to bother with each single question about memory addresses, DRAM initialization etc.

Every ARM vendor uses different "bits" in their design (like interrupt controllers, PMICs etc), which is why you see so much fragmentation. Having documentation makes things a lot easier of course - but it is incredibly impressive what Asahi folks managed to do in relatively short time even though they had to reverse-engineer *everything*.

@marcan one of reasons why people ask about M3/M4 is content of Apple store.

You cannot buy brand new Mac with older cpu (I do not count 8GB ram models).

I am using Asahi Fedora Remix on M1 Pro macbook. Warranty for it ends in a few months.

If I will be asked to replace it with new one then either going back to x86-64 or having to live with MacOS which I never used before.

I never asked "when M3/M4 support" cause you wrote about it several times. Will wait.

@marcan @tertle950 @ozzelot I really would like to understand how you develop such code? Do you reverse engineer the Apple bootloader? I suspect there is no public readable spec. Also debugging such early code really looks messy as you can't really log somewhere.

@hikhvar @tertle950 @ozzelot There is a special build flag for the m1n1 bootloader that disables a lot of features, even the MMU, enough that it usually boots to a serial proxy mode. Then we can use the usual Python host environment we have for research, over the 115200 baud serial interface, to try things.

The CPU configuration is reverse engineered from macOS (pretty much the only part that we look at the binary for, it's just the chicken bit settings). After that we make USB work so we can switch to a faster interface. At that point regular builds should be functional or at least debuggable. Then we bring up the m1n1 hypervisor, and run macOS in it so we can log what it does to figure out the rest of the hardware/changes.

@ozzelot @tertle950 Well the installer will just fail telling you your device is unsupported. What I describe is what happens if you try to install our bootloader manually, bypassing the installer or hacking it to "work". You get an instant reboot loop since it will fail before even showing anything on the screen.

@marcan without knowing anything about this, is this due to the M series being a new platform and do you expect changes to stagnate over time to the point where you can develop a generic enough bootloader to handle new versions?

@callin No. There is no such thing as a "generic" way of configuring CPU chicken bits.

There's a special, stripped-down build of our bootloader that can run without changes most of the time, but it runs on a single core at default frequency, without MMU or caching, and only provides a serial UART interface. That's about as much as you can do "generically".

Even turning on the MMU on the P-cores quickly leads to a crash without the chicken bits configured properly, and there isn't even a standard way for starting up the secondary cores at all.

@marcan @tertle950 Eh, a failed model check is something, but it's close enough to nothing that I'll allow it in with absolute nothing. :D A reboot loop though, that I would already consider "largely nothing". (I realize I'm diverging far too much into purely philosophical territory.)

@marcan IMHO it's a testament to the great work the Asahi Linux project achieved that this question comes up so often… you set expectations very high, so now people are expecting :-)

@hrw @marcan

I would never consider buying a brand new apple because of their offensively hostile attitude towards users.
Eg. No serviceable components in their latest laptops.

But if I was going to slap that kind of cash on a machine, I would defo buy #framework.
Love the concept and it should sit well with anyone who's remotely concerned with resource use.

https://frame.work/au/en

@n_dimension @marcan there are no better Arm laptops than Apple ones.

Framework or MNT Reform are using Arm SoCs which are dead slow compared even to M1 Pro I have in 3 years old Macbook.

This laptop is my development environment for Arm work. And sometimes device I use on conferences and travels.

@marcan "Why can't I just try installing macOS 12 on M4 even if it's not supported?"

@marcan @callin which is pretty weird in a way; you'd expect the bootloader to leave you with reasonably configured chicken bits, but...

@erincandescent @callin Only for the boot CPU, and only the subset the bootloader needs, which isn't everything a full-blown OS needs.