In November 2024, developer Yureka Lilian bought an M4 Mac mini, expecting it to behave like the M1 through M3 Apple Silicon machines and to receive quick support in Asahi Linux. It did not. The M4 is the first Apple Silicon generation to mandate SPTM (Secure Page Table Monitor), which hardens the XNU kernel of macOS against vulnerabilities. The Linux bringup of earlier generations rested on memory-mapped I/O traces captured with the m1n1 hypervisor, and on M4 those traces cannot be captured without major m1n1 changes. Working through that alone was beyond what a newcomer to the area could produce, so Lilian pursued Linux boot in parallel instead.
Initial boot attempts immediately hit locked registers. GXF (Guarded Exception Levels) is disabled in raw boot mode on M4-class chips, so attempting to initialize it crashed; the correct move was to make that initialization conditional and skip it. Writing to RVBAR, the Reset Vector Base Address Register that tells each CPU core where to start executing, also crashed, though the register already contained the correct value, so that write had to be omitted. For months serial output remained empty even with the earlycon boot parameter. The device tree was simply missing stdout-path = "serial0"; once it was added, Linux printed full register dumps and stack traces on early crashes.
That serial output then enabled a brute-force debugging approach. Lilian inserted a minimal debug_putc routine that printed a single "a" and bisected the boot sequence. The print point stopped once the MMU was enabled, because the UART is memory-mapped I/O and, after the MMU turns on, memory goes through page tables to virtual addresses that Linux does not map one-to-one onto the MMIO space. Adding that 1:1 MMIO mapping in the initial page tables pushed the working print further, until the failure moved to a write to an implementation-specific register, SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, which is related to virtualization. Commenting out that write let the kernel reach a shell; the register has since been unlocked in newer iBoot releases, so the workaround is no longer necessary.
The real obstacle was the second core and the WFI (wait-for-interrupt) instruction. On M1 through M3, a vendor control bit named ARM64_REG_CYC_OVRD_ok2pwrdn_force_mask caused WFI to zero all general-purpose registers; XNU saved and restored those registers around the instruction, and m1n1 disabled the quirk so the CPU behaved like a normal arm64 processor. Asahi Linux later re-enabled the behavior to let cores reach deeper sleep and save power. On M4 that bit appears to be locked or removed, and the default behavior violates the ARM64 specification: if WFI completes, it must not cause loss of architectural state. In April 2026, Lilian booted Linux on the M4 with all cores enabled by replacing every WFI and WFIT instruction in the kernel with NOP (no-op) instructions.
The screenshot shows the M4 Mac mini booted into NixOS, but cpuinfo reports only one core, illustrating the second core boot failure caused by the WFI instruction quirk on M4 chips.
Rather than patching the kernel in memory during early boot, a standard approach for silicon errata, the author discarded it because detecting every case in which WFI should be NOPped is unreliable: a virtual machine running under the macOS hypervisor would trigger the same code path, yet WFI there is trapped by the hypervisor to schedule guests efficiently. Will Deacon proposed a different fix: give the kernel a new idle bootarg, idle=<wfi|yield|nop>, and let m1n1 inject the appropriate argument conditionally when booting on bare-metal hardware known to have broken WFI. Lilian reports that this mechanism for preventing Linux from crashing on WFI and WFIT has been merged into mainline Linux and into m1n1, so the latest releases of both can boot natively with secondary cores on M4 Macs. The same workaround also works on M4 Pro, M4 Max, and M5 chips.
The work is being submitted directly to upstream projects rather than kept in a private fork, so everyone can use it. Peripheral reverse engineering on the M4 — the camera, display controller, and GPU initialization — is progressing more slowly, with further work expected to depend on m1n1 being able to boot and trace macOS on the device. Lilian also notes that more transparent reporting from well-funded upstream projects about how they use this kind of upstream progress would be welcome, and invites support for the work through LiberaPay or GitHub Sponsors, as well as donations to the Asahi Open Collective.