Un desarrollador ha dedicado tres años a transformar un Mac mini M4 en una máquina Linux, y la historia de cómo lo logró se lee como una persecución a cámara lenta a través de un laberinto de registros oscuros. La historia, titulada The Forgetful CPU (Linux on M4), documenta cada fallo, solución alternativa y sesión de depuración que se invirtió en el arranque de Linux en el chip más reciente de Apple.
El proyecto comenzó en noviembre de 2024, cuando el desarrollador compró un Mac mini M4 y apostó a que se comportaría lo suficiente como los chips M1-M3 más antiguos para soportar Asahi Linux. Esa apuesta resultó ser más difícil de lo esperado. El M4 requiere SPTM, una función de seguridad que bloquea las tablas de memoria del sistema, lo que hizo imposible aplicar directamente el enfoque habitual: rastrear cómo los controladores de macOS hablan con el hardware.
En cambio, el desarrollador tomó un camino diferente. Desactivó la estricta seguridad de arranque, instaló m1n1 como un objeto de arranque personalizado a través de la recuperación de macOS y configuró una consola serial para observar los registros del kernel. Los resultados iniciales no fueron prometedores.
Registros bloqueados y el fallo que no quería morir
m1n1 podía iniciarse en modo BRINGUP, pero fallaba casi inmediatamente cuando intentaba inicializar GXF, una función que resultó estar deshabilitada en el modo de arranque sin procesar en el M4. El desarrollador omitió por completo la inicialización de GXF. También descubrió que escribir en el RVBAR —un registro de memoria que define dónde comienza a ejecutarse un núcleo de CPU— provocaba un fallo, a pesar de que el valor correcto ya estaba presente.
El primer gran avance llegó a fines de 2025, en el Congreso de Comunicación del Caos, donde el desarrollador encontró nueva motivación. Ensambló un árbol de dispositivos mínimo que contenía solo los núcleos de la CPU y el controlador de interrupciones AIC, cargó el kernel de Linux con el parámetro earlycon e intentó la depuración debug_putc.
El kernel no imprimió nada después de «Vectoring to next stage». El desarrollador insertó una única rutina debug_putc que imprimía un carácter ‘a’, y funcionó. La búsqueda binaria del código de arranque apuntó al código de inicialización de la MMU, todavía en arch/arm64/kernel/head.S.
UART, MMIO y la instrucción WFI
El problema fue el mapeo de memoria. La UART se accede a través de E/S mapeada en memoria, pero una vez que la MMU está habilitada, todos los accesos a la memoria apuntan a direcciones virtuales. m1n1 expone el espacio MMIO en direcciones virtuales idénticas, pero Linux no, por lo que terminó accediendo a un espacio no mapeado en lugar de la UART.
El desarrollador modificó las tablas de páginas iniciales para agregar un mapeo 1:1 para el espacio MMIO, y debug_putc funcionó mucho más adelante en el proceso de arranque. Otro bisect redujo el fallo a una escritura en el registro específico de la CPU SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, lo que desencadena el nuevo fallo. Comentar esa escritura permitió que el kernel llegara a una shell.
SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, relacionado con la virtualización, desde entonces se ha desbloqueado en versiones más recientes de iBoot, por lo que la escritura ya no es necesaria.
Núcleos Secundarios y el Bit del Pollo
Con el kernel realmente en ejecución, el desarrollador finalmente descubrió por qué la salida de printk nunca se mostró en la consola serial anteriormente. El árbol del dispositivo faltaba stdout-path = «serial0», y agregarlo produjo volcados completos de registros y rastreos de pila de fallos tempranos.
Durante un tiempo, m1n1 no inició los núcleos secundarios porque faltaba smp_start_offset, un desplazamiento codificado de forma rígida en m1n1. Sin él, se omite smp_init. El desarrollador probó el desplazamiento utilizado para los M1-M3 base y los núcleos secundarios se iniciaron.
Otro fallo siguió, esta vez relacionado con la instrucción WFI. Las CPU Apple Silicon anteriores tienen peculiaridades conocidas: dependiendo del estado del bit del pollo, un registro que permite a los vendedores deshabilitar las optimizaciones de la CPU, la instrucción WFI borra los registros x0-x31. XNU guarda esos valores en otra parte.
La secuencia completa de momentos clave se ve así:
| Fecha | Evento |
|---|---|
| Noviembre de 2024 | Comprado M4 Mac mini |
| Diciembre de 2024 | Primer intento de arrancar Linux |
| Finales de 2025 | Congreso Chaos Communication; árbol de dispositivos mínimo ensamblado |
| Enero de 2026 | Se añadió earlycon=s5l,0x3ad200000 a bootargs |
| Enero de 2026 | Se corrigió la ruta stdout en el árbol de dispositivos |
What We Make Of It
Esta no es una historia sobre un producto terminado. Es una historia sobre la paciencia, la documentación y la enorme cantidad de trabajo que implica hacer que un sistema operativo libre funcione en hardware diseñado para uno propietario.
El desarrollador agradece a todo el equipo de Asahi Linux por su trabajo y ayuda previos, y solicita a los lectores que consideren donar a Asahi Open Collective si desean ver más trabajo de Linux mainline en Apple Silicon.
La saga muestra lo que sucede cuando un desarrollador trata un fallo del kernel como una pista en lugar de un muro. Cada registro, cada mapeo, cada escritura fue una hipótesis comprobable. El resultado es un arranque de Linux funcional, construido poco a poco con cada fallo.
Es un recordatorio de que la diferencia entre una máquina que funciona y una que no a menudo se reduce a un solo valor de registro, un desplazamiento olvidado o un mapeo que nadie se molestó en documentar. Y eso, en sí mismo, vale la pena leer.
Material de origen: “The Forgetful CPU (Linux on M4),” yuka.dev.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.