Ein Entwickler hat drei Jahre damit verbracht, einen M4 Mac mini in eine funktionierende Linux-Maschine zu verwandeln, und die Geschichte, wie er das gemacht hat, liest sich wie eine Zeitrafferaufnahme durch ein Labyrinth obskurer Register. Der Bericht mit dem Titel „The Forgetful CPU (Linux on M4)“ dokumentiert jeden Absturz, jede Umgehung und jede Debugging-Sitzung, die für das Booten von Linux auf Apples neuestem Chip erforderlich waren.
Das Projekt begann im November 2024, als der Entwickler einen M4 Mac mini kaufte und darauf setzte, dass er dem älteren M1-M3-Chip genügend ähnlich sei, um Asahi Linux zu unterstützen. Diese Annahme erwies sich als schwieriger als erwartet. Der M4 benötigt SPTM, ein Sicherheitsmerkmal, das die Speichertabellen des Systems sperrt, was die übliche Vorgehensweise – das Verfolgen, wie macOS-Treiber mit Hardware interagieren – unmöglich machte.
Stattdessen schlug der Entwickler einen anderen Weg ein. Er deaktivierte die strikte Boot-Sicherheit, installierte m1n1 als benutzerdefiniertes Bootobjekt über macOS Recovery und richtete eine serielle Konsole ein, um die Kernel-Protokolle zu beobachten. Die ersten Ergebnisse waren nicht vielversprechend.
Gesperrte Register und der Absturz, der nicht verschwand
m1n1 konnte im BRINGUP-Modus starten, stürzte aber fast sofort ab, als es versuchte, GXF zu initialisieren, ein Feature, das sich herausstellte, im Raw-Boot-Modus auf dem M4 deaktiviert war. Der Entwickler übersprang die GXF-Initialisierung vollständig. Er stellte auch fest, dass das Schreiben in das RVBAR – ein Speichterreister, der festlegt, wo ein CPU-Kern mit dem Ausführen beginnt – zu einem Absturz führte, obwohl der korrekte Wert bereits vorhanden war.
Der erste echte Durchbruch kam Ende 2025 auf dem Chaos Communication Congress, wo der Entwickler neue Motivation fand. Er erstellte eine minimale Device Tree, die nur die CPU-Kerne und den AIC-Interrupt-Controller enthielt, lud den Linux-Kernel mit dem Earlycon-Parameter und versuchte debug_putc-Debugging.
Der Kernel druckte nach „Vectoring to next stage“ nichts aus. Der Entwickler fügte eine einzelne debug_putc-Routine ein, die ein ‚a‘-Zeichen druckte, und es funktionierte. Das Halbieren des Boot-Codes deutete auf den MMU-Init-Code hin, der sich immer noch in arch/arm64/kernel/head.S befand.
UART, MMIO und die WFI-Anweisung
Das Problem war Memory Mapping. Der UART wird über Memory-mapped I/O angesprochen, aber sobald die MMU aktiviert ist, verweisen alle Speicherzugriffe auf virtuelle Adressen. m1n1 legt den MMIO-Bereich bei identischen virtuellen Adressen frei, Linux aber nicht, so dass es stattdessen unzugeordneten Speicher zugriff.
Der Entwickler modifizierte die anfänglichen Pagetables, um eine 1:1-Abbildung für den MMIO-Bereich hinzuzufügen, und debug_putc funktionierte deutlich weiter im Bootprozess. Eine weitere Bisect-Suche schloss den Absturz auf einen Schreibvorgang auf das implementierungs-spezifische CPU-Register SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2 ein, was den neuen Absturz auslöste. Durch Auskommentieren dieses Schreibvorgangs konnte der Kernel in eine Shell gebracht werden.
SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, das mit Virtualisierung zusammenhängt, wurde inzwischen in neueren iBoot-Versionen entsperrt, so dass der Schreibvorgang nicht mehr erforderlich ist.
Sekundäre Kerne und das Chicken Bit
Mit dem Kernelbetrieb konnte der Entwickler schließlich herausfinden, warum die printk-Ausgabe zuvor nicht auf der seriellen Konsole angezeigt wurde. Der Device Tree fehlte stdout-path = „serial0“, und das Hinzufügen von stdout-path erzeugte vollständige Registerdumps und Stack Traces von frühen Abstürzen.
Für eine Weile startete m1n1 nicht die sekundären Kerne, da smp_start_offset fehlte, ein Offset, das in m1n1 fest codiert war. Ohne dieses Offset wird smp_init übersprungen. Der Entwickler versuchte das Offset, das für die Basis-M1-M3 verwendet wurde, und brachte die sekundären Kerne zum Laufen.
Ein weiterer Absturz folgte, diesmal mit der WFI-Anweisung verbunden. Bei früheren Apple Silicon-CPUs gibt es bekannte Eigenheiten: Je nach Zustand des Chicken Bits, eines Registers, das es Herstellern ermöglicht, CPU-Optimierungen zu deaktivieren, setzt die WFI-Anweisung Register x0-x31 zurück. XNU speichert diese Werte an anderer Stelle.
Die vollständige Sequenz der wichtigsten Momente sieht wie folgt aus:
| Datum | Ereignis |
|---|---|
| November 2024 | Gekauft M4 Mac mini |
| Dezember 2024 | Erster Versuch, Linux zu starten |
| Spätes Jahr 2025 | Chaos Communication Congress; minimales Device Tree zusammengebaut |
| Januar 2026 | Added earlycon=s5l,0x3ad200000 zu bootargs |
| Januar 2026 | Fixed stdout-path im Device Tree |
What We Make Of It
Dies ist keine Geschichte über ein fertiges Produkt. Es ist eine Geschichte über Geduld, Dokumentation und die schiere Menge an Arbeit, die erforderlich ist, um ein freies Betriebssystem auf Hardware zum Laufen zu bringen, die für ein einziges proprietäres System entwickelt wurde.
Der Entwickler dankt dem gesamten Asahi Linux-Team für ihre bisherige Arbeit und Hilfe und bittet die Leser, eine Spende an das Asahi Open Collective in Betracht zu ziehen, wenn sie mehr Mainline-Linux-Arbeit auf Apple Silicon sehen möchten.
Die Saga zeigt, was passiert, wenn ein Entwickler einen Kernel-Absturz als Hinweis und nicht als Mauer betrachtet. Jeder Register, jede Zuordnung, jeder Schreibvorgang war eine testbare Hypothese. Das Ergebnis ist ein funktionierender Linux-Boot, aufgebaut Crash für Crash.
Es ist eine Erinnerung daran, dass der Unterschied zwischen einer funktionierenden und einer nicht funktionierenden Maschine oft auf einen einzelnen Registerwert, einen vergessenen Offset oder eine Mapping-Zuordnung zurückzuführen ist, die niemand dokumentiert hat. Und das ist an sich lesenswert.
Quelle: “The Forgetful CPU (Linux on M4),” yuka.dev.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.