Zum Hauptinhalt Zur Navigation Zur Suche

Auf Fehlersuche im Kernel

Eigentlich funktioniert das sehr bequem direkt über Buildroot. Nur haben Loongsons Entwickler das nicht vorgesehen, sondern ein fertiges Kernel-Abbild ins Buildroot-Verzeichnis gepackt. Im Loongson-Repository finden sich aber auch zwei angepasste Kernel – neben dem alten 5.10 ein halbwegs aktueller 6.12. Hier sind Treiber für spezifische Hardware der verschiedenen Loongson-SoCs enthalten, die nicht in den Mainline-Kernel eingepflegt sind. Den Grund dafür werden wir noch sehen.

Praktischerweise erlaubt Buildroot, direkt Git-Repositories als Softwarequelle anzugeben. Für den Linux-Kernel ist das direkt im Konfigurationsprogramm möglich, benötigt wird nur die ID des auszucheckenden Commit-Stands. Leider gelang es uns nicht, mit einer RAM-Disk zu booten. Ein Archiv mit Kernel und Root-File-System war zu groß und hätte einen reservierten Speicherbereich beschrieben.

Zwar lässt sich das CPIO-Archiv auch manuell laden. Das entsprechende Boot-Kommando, das dem Linux-Kernel die Adresse des Archivs übergibt, führte aber stets zu TLB-Fehlern. Unsere Analyse des Bootloader-Codes von Loongson kam zu dem ernüchternden Ergebnis: Ein Booten mit RAM-Disk ist hier einfach nicht vorgesehen.

Schuld war ein kaputter Treiber

Also suchten wir nach einem anderen Ansatz und aktivierten die Debugging-Optionen des Linux-Kernels. Denn unsere zweite Hypothese war ein anhand der Kernel-Ausgaben nicht erkennbarer Fehler in einem Treiber.

Als hilfreich erwies sich der Kernel-Kommandozeilen-Option inicall_debug: Sie veranlasst den Kernel, vor Aufruf und nach Rückkehr der init-Funktion eines Moduls eine Nachricht auszugeben. Damit ist erkennbar, wenn die Initialisierung ungewöhnlich lange dauert oder aufgrund eines Fehlers nie abgeschlossen wird. Letzteres war tatsächlich der Fall: Der an sich sehr unauffällige Treiber für die Echtzeituhr brachte das gesamte System zum Stillstand.

Vermutlich ist eine falsche Speicheradresse der Grund für den Absturz. Das haben wir aber noch nicht weiter untersucht, sondern den Treiber einfach deaktiviert. Nachdem wir noch den Bootloader kompiliert hatten, um eine Version des Tools mkimage zu kommen, welche die Loongarch kennt, und manuell einen symbolischen Link gesetzt haben, baute uns Buildroot endlich ohne Fehler ein komplettes Betriebssystemabbild.

Dem fügten wir noch einige Benchmarks hinzu – die wir uns nun ansehen können.


Relevante Themen