Debugging eines Linux-Treibers
Fortsetzung des Artikels von Teil 1
Fehler behoben!
Mit Hilfe der gewonnenen Informationen konnten die Entwickler die Spezifikationen des UARTs überprüfen und fanden eine Mehrdeutigkeit: Der UART sollte einen Interrupt senden, wenn sein Puffer leer war. Es war jedoch nicht klar, ob er einen Interrupt auslösen sollte, wenn sein Puffer leer war und der UART im Interrupt-Modus beschrieben werden sollte. Es handelte sich also um ein sprachliches Interpretationsproblem: »... wenn der Puffer leer ist« oder »... wenn der Puffer leer wird«. Basierend auf dem erwarteten Verhalten des Softwaretreibers und der Wellenformen passten die Entwickler also das Verhalten des UARTs so an, dass er jedes Mal einen Interrupt generierte, wenn der Puffer leer war. Nach der Reparatur der UART-Logik erschien der Bootvorgang auf der Konsole ().
Jobangebote+ passend zum Thema
Linux bootete also vollständig bis zur Shell. Der Kernel selbst lud auf dem Emulator in weniger als zwei Sekunden. Etwa zehn Sekunden benötigte er, um das Disk-Image zu entpacken und den »init«-Prozess ablaufen zu lassen. Dieser startete wiederum den Login-Vorgang und die Shells. Anschließend geht es weiter mit den anderen Peripheriegeräten wie TFT-Display, Ethernetcontroller, etc.
Eine Frage bleibt jedoch: Wie konnte Linux überhaupt so weit booten und sich erst kurz vor Schluss »aufhängen «, wenn die UARTs nicht richtig funktionierten? Das Betriebssystem verwendet zwei unterschiedliche UART-Treiber. Der erste (serial 8250_early) wird als sicherer eingestuft, sodass er bereits in frühen Phasen des Bootvorgangs Zeichen ohne Interrupts ausgeben darf. Der zweite ist der »echte« UART-Treiber, der jedoch erst aktiviert wird, wenn der Kernel fertig initialisiert ist. Hätte die Hardwareprüfung bereits vor Ende des Bootvorgangs die Arbeit eingestellt und sich auf die frühe Treiberversion verlassen, so wäre das Problem unentdeckt geblieben. Es wäre zwar möglich, noch nach dem Tape-out mit dem Softwaretreiber zu tricksen, doch hätte das die Belastung des Prozessors deutlich erhöht. Schließlich erforderte dies aktives Abfragen anstelle von Interrupts. Daraus lässt sich die Lehre ziehen, dass man am besten feststellt, ob ein SoC so mit einer Zielanwendung funktioniert wie er sollte, wenn man die Anwendung bereits vor dem Tapeout laufen lässt. Emulation bleibt also interessant! (mc)
Alain Raynaud
ist Technical Director von
Eve
Telefon 00 33/16 45 32 73 0
www.eve-team.com
Siehe auch:
Beseitigung von Produktivitätshemmnissen in der Linux-Entwicklung
Neuer Debugger für die Systemanalyse
- Debugging eines Linux-Treibers
- Fehler behoben!
- Blick in den Quellcode
