In November 2024, developer Yureka Lilian purchased an M4 Mac mini. Given how quickly previous generations of Apple Silicon had been brought up, getting an open-source operating system running on it seemed well within reach. Yet it took 17 months before the machine’s CPU finally booted all cores into a functional command-line interface.
Apple Cuts Off the Virtual Machine Probes
Over the past several years, the open-source community had refined a battle-tested playbook for reverse-engineering Apple Silicon: run macOS inside a specialized hypervisor and intercept the memory-mapped I/O (MMIO) traces between macOS kernel drivers and the hardware. In effect, developers could observe how macOS issued hardware commands and replicate those sequences in Linux.
With the M4, Apple turned out the lights. This generation enforced Secure Page Table Monitor (SPTM) mechanisms to harden the kernel, which rendered the established MMIO tracing hypervisors obsolete. Getting macOS to run under a hypervisor would require sweeping architectural overhauls. As a result, the community had no choice but to confront a completely undocumented black box.
Figure: Sven Peter’s post on Mastodon in April 2025. Source: yuka.dev
Debugging Minefields by Printing a Single Character
With their sophisticated reconnaissance tools neutralized, developers were forced back to the most rudimentary trial and error. The m1n1 bootloader on the M4 could only run in bare BRINGUP mode. Simply initializing certain peripherals or writing to what appeared to be the correct reset base address caused the hardware to instantly panic and crash.
Yureka Lilian turned to the simplest possible assembly routine: an instruction sequence modified to print nothing more than the single character a, injected into the earliest stage of kernel boot. By shifting this tiny snippet around and applying binary search, they narrowed down the failure point instruction by instruction. The locked registers uncovered during this process were only quietly resolved in subsequent firmware updates from Apple.
Figure: Linux booting to a shell for the first time on an M4 Mac mini, with hyfetch showing the host as Apple Mac Mini (M4, 2024). Source: yuka.dev
Hardware Quirk: Sleep Wipes General-Purpose Registers
Early boot crashes were merely the opening hurdles. What truly stumped the developers was an architectural irregularity in the M4 hardware that defies normal CPU design conventions.
Previous M-series chips had featured a hidden control bit: when an idle instruction waiting for an interrupt was executed, the CPU power-gated and wiped all 32 general-purpose registers (GPRs). Linux developers had deliberately opted into this behavior on earlier chips to achieve deeper sleep states and lower power consumption, manually saving and restoring register state across sleep cycles.
Figure: System information after successfully booting all cores to the shell on M4. Source: yuka.dev
On the M4, however, Apple made this register-clearing behavior mandatory and impossible to disable. This directly violates the ARM64 architectural specification, which explicitly mandates that wait-for-interrupt sleep instructions must preserve architectural state. It took extensive investigation in the dark before developers realized what was happening: the moment this CPU naps, its register memory is mercilessly erased.
Bypassing the Wall with NOPs
Faced with such uncompromising hardware behavior, the community’s solution was delightfully straightforward: in April 2026, developers replaced all idle sleep instructions with no-operation instructions (NOPs) in the kernel. With that, all cores of the M4 finally came alive.
Rather than applying an indiscriminate hack that might break other platforms, they submitted an early boot parameter option to the mainline Linux kernel, allowing the system to selectively bypass sleep instructions when running on affected silicon. Apple may have turned undocumented hardware behavior into a barrier, but the open-source community deciphered the mystery through unrelenting trial and error—ultimately winning upstream kernel support to accommodate non-standard hardware designs. Against an insular silicon walled garden, this was a victory forged purely through patience.
Reference Links:
- yuka.dev blog post
- Asahi Linux community updates
