En noviembre de 2024, el desarrollador Yureka Lilian compró una Mac mini M4, esperando que se comportara como las máquinas Apple Silicon M1, M2 y M3 y que recibiera soporte rápido en Asahi Linux. No fue así. El M4 es la primera generación de Apple Silicon que requiere SPTM (Secure Page Table Monitor), lo que refuerza el kernel XNU de macOS contra vulnerabilidades. La puesta en marcha de Linux en generaciones anteriores se basaba en rastros de E/S mapeados en memoria capturados con el hipervisor m1n1, y en el M4 esos rastros no pueden ser capturados sin cambios importantes en m1n1. Resolver esto por sí solo estaba más allá de lo que un recién llegado al área podía producir, así que Lilian persiguió el arranque de Linux en paralelo.
Los primeros intentos de arranque fallaron inmediatamente con registros bloqueados. GXF (Guarded Exception Levels) está desactivado en modo de arranque en chips de clase M4, por lo que intentar inicializarlo provocó un bloqueo; lo correcto era hacer esa inicialización condicional y omitirla. Escribir en RVBAR, el Registro de Dirección del Vector de Reinicio que indica a cada núcleo de CPU dónde empezar a ejecutar, también bloqueó, aunque el registro ya contenía el valor correcto, por lo que esa escritura tenía que omitirse. Durante meses, la salida serial permaneció vacía incluso con el parámetro earlycon. El árbol de dispositivos simplemente carecía de stdout-path = "serial0"; una vez que se añadió, Linux imprimió volcado de registros completos y trazas de pila en fallos tempranos.
Esa salida serial luego permitió un enfoque de depuración por fuerza bruta. Lilian insertó una rutina mínima de debug_putc que imprimía una sola "a" y dividía la secuencia de arranque. El punto de impresión se detuvo una vez que el MMU estaba habilitado, porque el UART es E/S mapeada en memoria y, después de que el MMU se enciende, la memoria pasa a través de tablas de páginas a direcciones virtuales que Linux no asigna uno a uno al espacio MMIO. Añadir ese mapeo 1:1 MMIO en las tablas de páginas iniciales empujó el punto de impresión de trabajo más adelante, hasta que el fallo se trasladó a una escritura a un registro específico de la implementación, SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, que está relacionado con la virtualización. Comentar esa escritura permitió que el kernel alcanzara una shell; el registro ha sido desbloqueado desde entonces en versiones más nuevas de iBoot, por lo que la solución alternativa ya no es necesaria.
El verdadero obstáculo fue el segundo núcleo y la instrucción WFI (wait-for-interrupt). En M1 a M3, un bit de control de proveedor llamado ARM64_REG_CYC_OVRD_ok2pwrdn_force_mask causaba que WFI cero todos los registros de propósito general; XNU guardaba y restauraba esos registros alrededor de la instrucción, y m1n1 desactivaba el recurso para que el CPU se comportara como un procesador arm64 normal. Asahi Linux luego reactivó el comportamiento para permitir que los núcleos alcanzaran estados de reposo más profundos y ahorraran energía. En el M4 ese bit parece estar bloqueado o eliminado, y el comportamiento por defecto viola la especificación ARM64: si WFI completa, no debe causar pérdida de estado arquitectónico. En abril de 2026, Lilian arrancó Linux en el M4 con todos los núcleos habilitados reemplazando cada instrucción WFI y WFIT en el kernel con instrucciones NOP (no-op).
La captura de pantalla muestra el Mac mini M4 arrancado en NixOS, pero cpuinfo informa solo un núcleo, ilustrando el fallo en el arranque del segundo núcleo causado por el recurso de instrucción WFI en chips M4.
En lugar de parchear el kernel en memoria durante el arranque temprano, un enfoque estándar para erratas de silicio, el autor descartó esto porque detectar cada caso en el que WFI debería ser NOPpeado es poco confiable: una máquina virtual ejecutándose bajo el hipervisor de macOS estaría disparando la misma ruta de código, sin embargo, WFI allí es atrapada por el hipervisor para programar invitados eficientemente. Will Deacon propuso un enfoque diferente: darle al kernel un nuevo bootarg de idle, idle=<wfi|yield|nop>, y dejar que m1n1 inyecte el argumento apropiado condicionalmente cuando se arranque en hardware de serie conocido por tener WFI roto. Lilian informa que este mecanismo para prevenir que Linux se bloquee en WFI y WFIT ha sido fusionado al Linux principal y a m1n1, así que las versiones más recientes de ambos pueden arrancar en serie con núcleos secundarios en Macs M4. La misma solución alternativa también funciona en chips M4 Pro, M4 Max y M5.
El trabajo se está presentando directamente a proyectos upstream en lugar de mantenerse en un fork privado, así que todos pueden usarlo. La ingeniería inversa de periféricos en el M4 — la cámara, el controlador de pantalla y la inicialización del GPU — avanza más lentamente, y se espera que trabajos futuros dependan de que m1n1 pueda arrancar y rastrear macOS en el dispositivo. Lilian también señala que una mayor transparencia desde proyectos upstream bien financiados sobre cómo utilizan este tipo de progreso upstream sería bienvenida, e invita a apoyar el trabajo a través de LiberaPay o GitHub Sponsors, así como donaciones al Asahi Open Collective.