Developer Documents Three Years of Crashes Booting Linux on the M4 Mac Mini

A developer has spent three years turning an M4 Mac mini into a working Linux machine, and the tale of how he did it reads like a slow-motion chase through a maze of obscure registers. The story, titled The Forgetful CPU (Linux on M4), documents every crash, workaround and debugging session that went into booting Linux on Apple’s latest chip.

The project began in November 2024, when the developer bought an M4 Mac mini and wagered that it would behave enough like the older M1-M3 chips to support Asahi Linux. That bet proved harder than expected. The M4 requires SPTM, a security feature that locks down the system’s memory tables, which made the usual approach — tracing how macOS drivers talk to hardware — impossible to apply directly.

Instead, the developer took a different path. He disabled strict boot security, installed m1n1 as a custom boot object via macOS recovery, and set up a serial console to watch the kernel logs. The early results were not promising.

Locked Registers and the Crash That Wouldn’t Die

m1n1 could start in BRINGUP mode but crashed almost immediately when it tried to initialize GXF, a feature that turned out to be disabled in raw boot mode on the M4. The developer skipped GXF initialization entirely. He also found that writing to the RVBAR — a memory register that sets where a CPU core starts running — caused a crash, even though the correct value was already present.

The first real breakthrough came in late 2025, at the Chaos Communication Congress, where the developer found fresh motivation. He assembled a minimal device tree containing only the CPU cores and the AIC interrupt controller, loaded the Linux kernel with the earlycon parameter, and tried debug_putc debugging.

The kernel printed nothing after “Vectoring to next stage.” The developer inserted a single debug_putc routine that printed an ‘a’ character, and it worked. Bisecting the boot code pointed to the MMU init code, still in arch/arm64/kernel/head.S.

UART, MMIO and the WFI Instruction

The problem was memory mapping. The UART is accessed via memory-mapped I/O, but once the MMU is enabled, all memory accesses point to virtual addresses. m1n1 exposes the MMIO space at identical virtual addresses, but Linux does not, so it ended up accessing unmapped space instead of the UART.

The developer modified the initial pagetables to add a 1:1 mapping for the MMIO space, and debug_putc worked much further into the boot process. Another bisect narrowed the crash to a write to the implementation-specific CPU register SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, which triggers the new crash. Commenting out that write got the kernel to a shell.

SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, related to virtualization, has since been unlocked in newer iBoot versions, so the write is no longer necessary.

Secondary Cores and the Chicken Bit

With the kernel actually running, the developer finally figured out why printk output never showed on the serial console earlier. The device tree was missing stdout-path = “serial0”, and adding it produced full register dumps and stack traces from early crashes.

For a while, m1n1 did not start secondary cores because smp_start_offset was missing, an offset hardcoded in m1n1. Without it, smp_init is skipped. The developer tried the offset used for base M1-M3 and got the secondary cores running.

Another crash followed, this time tied to the WFI instruction. Previous Apple Silicon CPUs have known quirks: depending on the state of the chicken bit, a register that lets vendors disable CPU optimizations, the WFI instruction zeroes registers x0-x31. XNU saves those values elsewhere.

The full sequence of key moments looks like this:

What We Make Of It

This is not a story about a finished product. It is a story about patience, documentation and the sheer amount of work that goes into making a free operating system run on hardware designed for a single proprietary one.

The developer thanks the entire Asahi Linux team for their prior work and help along the way, and asks readers to consider donating to the Asahi Open Collective if they want to see more mainline Linux on Apple Silicon work.

The saga shows what happens when a developer treats a kernel crash as a clue rather than a wall. Each register, each mapping, each write was a testable hypothesis. The result is a working Linux boot, built one crash at a time.

It is a reminder that the difference between a machine that works and one that does not often comes down to a single register value, a forgotten offset, or a mapping that nobody bothered to document. And that, in itself, is worth reading about.

Source material: “The Forgetful CPU (Linux on M4),” yuka.dev.

Apple Silicon · Asahi Linux · kernel hacking · open source · tech policy