The M4 Mac mini is the machine that made Linux bring-up on Apple silicon hard again, and Yureka Lilian’s new write-up explains why, from the saga’s start to the fix that has now been merged into mainline Linux and m1n1. It begins with a purchase: in November 2024 they bought an M4 mini gambling it would be as easy as the M1 through M3, and had a desk ornament for months once it became clear the M4 is the first Apple silicon generation to mandate SPTM, the Secure Page Table Monitor. That hardening feature exists to protect macOS’s kernel, but it also breaks the standard tracing approach, because the m1n1 hypervisor needs major changes to get macOS running under it before it can watch the hardware.
The trail
The story is a tour of how this work actually gets done: serial consoles, bring-up modes, and a hand-rolled debug print. m1n1 could only start in a bring-up mode at first because its usual initialization crashed against locked hardware features, and a register that sets where each core starts executing, already containing the right value, crashed the machine when written. When the kernel itself kept dying silently, the author built a single-character debug print into the earliest boot code and bisected until the culprit was found: Linux does not map the UART the way m1n1 does, so the serial console died the moment the MMU turned on. A one-to-one mapping for MMIO in the initial page tables fixed that, and the next bisect ended at a write to a virtualization register that crashed the CPU, which newer boot firmware has since unlocked.
The quirk at the center
The best part is the bug the title is about. Previous Apple CPUs handle the WFI instruction, which idles a core until an interrupt, with a quirk: unless a control bit is set, WFI zeroes the general-purpose registers, breaking the ARM64 specification rule that WFI must not lose architectural state. On earlier chips m1n1 cleared the behavior; on the M4 the bit is locked or gone, so the chip is non-compliant by default. After booting all cores in April by replacing every WFI and WFIT instruction with a no-op, kernel maintainer Will Deacon suggested the fix that shipped: a boot parameter that disables WFI idle, which m1n1 adds automatically on machines known to be affected. That mechanism is now in mainline Linux and m1n1, so current releases boot M4 Macs with all cores, and the same work applies to the M4 Pro, M4 Max and M5.
My read
This is the best hardware debugging story of the week and the practical companion to the device-tree news from last week: the trees give the kernel a map of the machine, and this work gives it cores that behave. The method is the point worth taking away, because it is not exotic: print one character, bisect, and read the spec. What is left for the M4 is everything else on the board, from the display to the GPU, which is exactly where the work went last time as well.
Source: the write-up.
