Debugging von Embedded Linux- Anwendungen auf ARM9/ARM11- Prozessoren Zusammenfassung Um das Linux Kernel- und Applikationsdebugging auf ARM9/ARM11-basierten Embedded-Systemen parallel und ohne die heutzutage üblichen Risiken gegenseitiger Blockaden durchführen zu können, ist eine Synchronisation der gebräuchlichen Debug- Arten notwendig. Dafür bedarf es allerdings neuer innovativer Werkzeuge wie der Universal Debug Engine, die ein Kernel- und Applikationsdebugging über eine einzige JTAG-Schnittstelle erlauben und durch die Integration beider Ansätze deren Vorteile vereinen, ohne das der Anwender dafür die Nachteile durch fehlende Synchronisation in Kauf nehmen muss. Inhaltsverzeichnis Debugging von Embedded... 1 Die Wahl der Kommunikationskanäle... 1 Das Applikations-Debugging (Execution Mode Debugging)... 2 Generelle Arbeitsweise eines GDB-Server... 2 Zusätzliche Features für Embedded-Applikationen... 3 Das Remote Serial Protocol des GDB-Servers... 3 Kernel- und Applikationsdebugging (Freeze Mode Debugging)... 5 Darstellung von Prozessinformationen... 5 Integriertes Terminal-Window... 6 Manuelles Laden des Linux-Kernels... 7 Fazit... 7 Autor... 8 Quelleangaben... 8 Firmenprofil... 8 Kontaktdaten... 8
Debugging von Embedded Embedded Linux als Betriebssystem für moderne ARM-Prozessoren? Keine schlechte Idee? Oder etwa doch? Da Linux ein Multitasking-Betriebssystem ist, muss jedem Prozess ein eigener Prozessadressraum zugewiesen werden. Diese Unterteilung verkompliziert jedoch das Debuggen von Prozessen bzw. prozessübergreifender Funktionalität enorm. Was also tun? Folgender Beitrag zeigt einige Möglichkeiten auf, wie Sie trotzdem erfolgreich zum Ziel kommen. Bei der Software-Entwicklung auf Embedded-Systemen werden heute üblicherweise noch zwei unterschiedliche Debug-Ansätze verwendet. Da ist zum einen meist das klassische Debug-Werkzeug, mit dem das Verhalten des Linux-Kernels untersucht wird. Dieses Tool hilft dem Entwickler, Probleme während der Bootphase des Betriebssystems aufzuspüren, Fehler in selbst erstellten Treibermodulen zu entdecken oder sich den Backtrace von Kernelroutinen anzeigen zu lassen. Für das Debuggen auf Applikationsebene wird in der Regel ein eigener Debug-Server explizit auf dem Target-System gestartet. Dieser Server bietet eine Schnittstelle, um vom Entwickler Befehle für das Debugging entgegen nehmen können. Er kommuniziert mit dem Host-PC meist über die Ethernet-Schnittstelle. Das Betriebssystem wird durch die Debug-Session nicht beeinflusst. Beide Ansätze haben einige ganz spezifische Vorteile. Diese werden jedoch durch diverse Nachteile zunichte gemacht: Die unterschiedlichen Werkzeuge bzw. Komponenten arbeiten nicht synchron und können sich schlimmstenfalls sogar gegenseitig blockieren! Da kann es dann schon einmal passieren, dass die Verbindung des Applikationsdebuggers zum Zielsystem unterbrochen wird, weil das Betriebssystem durch den Kerneldebugger angehalten wurde und auch der Debug- Server zum Stillstand kommt. Desweiteren muss immer zwischen beiden Debug- Werkzeugen gewechselt werden, was das Debugging unhandlich macht bzw. den Entwickler verwirrt. Im Folgenden werden die technischen Grundlagen im Einzelnen beleuchtet und mit dem Freeze Mode Debugging eine Methode vorgestellt, die einen Großteil der Nachteile zu vermeiden hilft. Die Wahl der Kommunikationskanäle Je nach Hardwareausstattung und Anforderungsprofil werden für die Verbindung zwischen dem Host-PC und dem Linux-Zielsystem bis zu zwei Kommunikationskanäle benutzt (Bild 1). Beim Applikations-Debugging kann die Verbindung wahlweise über Ethernet oder den JTAG-Port erfolgen. Die serielle Verbindung ist optional und kann neben der JTAG Konsole als zusätzliches Terminal verwendet werden. Für das Kernel-Debugging kommt allerdings definitiv nur der JTAG-Port in Frage. 1
Windows + Linux Development PC Universal Access Device Custom Specific Target Hardware Host Interface JTAG Serial 192.168.0.1 Serial Ethernet Ethernet 192.168.0.101 Bild 1: Mögliche Debug-Kommunikationskanäle zum Embedded-Linux-Target Nur über ihn lässt sich wahlfrei auf den virtuell gemappten Speicher zugreifen und ein resourcen-schonender Zugang zum On-chip -Debug-Modul realisieren. Das Applikations-Debugging (Execution Mode Debugging) Lassen Sie uns zuerst näher auf das Applikations- oder auch Execution Mode Debugging eingehen. Hier befindet sich das Zielsystem permanent im laufenden Zustand ( Running State ). Für das Debugging wird ein modifizierter GDB-Server verwendet, der beim Booten des Kernels auf dem Zielsystem gestartet wird. Der Server wartet auf eine Verbindungsanforderung des Host-Debuggers über den gewählten Kommunikationskanal und leitet den Debug-Prozess nach einer entsprechenden Anforderung durch den Host-Debugger ein. Als Kommunikationskanal kommt hier wahlweise eine Ethernet-Verbindung oder der JTAG-Port in Frage (Bild 2). Bild 2: Für die Verbindung zum GDB-Server kann wahlweise ein Ethernet- oder JTAG-Port genutzt werden Generelle Arbeitsweise eines GDB-Server Die Arbeitsweise des GDB-Servers ist einfach strukturiert. Der Host-Debugger veranlasst das Laden der zu debuggenden Applikation, indem er diese "Lade- Anforderung" an den GDB-Server weiterleitet. Der GDB-Server startet einen neuen Prozess und ruft vor dem Start der eigentlichen Applikation den System-Call "ptrace" auf, um die Kontrolle über den Applikationsprozess zu erlangen. Dieser System-Call sorgt dafür, dass der Prozess als TRACED markiert und alle auftretenden Signale an den Erzeugerprozess (parent process) übergeben werden. 2
Wird nun während des Debug-Prozesses ein beliebiges Signal an die Applikation gesendet, so erkennt der Linux-Kernel anhand von zuvor gesetzten Flags, dass dieser Prozess kontrolliert (getraced) abläuft und veranlasst das Stoppen der Applikation. Im Anschluss wird dem wartenden GDB-Server das Signal, das eigentlich für die Applikation bestimmt war, gesendet. Der GDB-Server kann das Signal dann weiterverarbeiten oder an den Prozess weiterleiten. Mit Hilfe dieser Technik ist ein Auswerten und Debuggen auch auf Signalebene möglich. Neben dem Debuggen von Signalen sind auch klassische Methoden wie das Step-in oder Step-over von Funktionen, ein Single-Step oder das Setzen von Breakpoints möglich. Grundlage dieser Methoden sind Unterbrechungspunkte, also das Anhalten der Applikation beim Erreichen festgelegter Programmstellen. Der GDB-Server fügt dafür im Code an der entsprechenden Stelle einen Unterbrechungscode ein, der bei Ausführung ein SIGTRAP -Signal auslöst. Durch dieses Signal wird dem GDB-Server mitgeteilt, dass die Applikation angehalten wurde und die Kontrolle wieder dem GDB zugeteilt ist. Der Host-PC kann dann über weitere Anforderungen beispielsweise die aktuellen Registerinhalte auslesen oder Informationen zum Call Stack abrufen. Zusätzliche Features für Embedded-Applikationen Im beschriebenen System kommt ein modifizierter GDB-Server zum Einsatz, der dem Anwender neben den beschriebenen Grundfunktionen einige interessante zusätzliche Optionen speziell für den Einsatz in Embedded-Systemen bietet. Zu den wichtigsten Merkmalen zählen die JTAG-Schnittstelle kann als Kommunikationskanal für das Applikations- Debugging verwendet werden der Upload von ELF-Files über Ethernet oder JTAG auf das Target-System Applikations-ELF-Files können via Windowsfreigabe oder Samba Common Interface File System (CIFS) vom Host-PC in das Zielsystem geladen werden die Unterstützung der Fehlersuche in Shared Libraries (*.so Files) das Attachen zu mehreren gestarteten Prozessen das Debugging mehrerer Prozesse in einer Debugger-Instanz Das Remote Serial Protocol des GDB-Servers Als Kommunikationsprotokoll zwischen dem modifizierten GDB-Server und dem Host- PC kommt das "Remote Serial Protocol" zum Einsatz, das um einige Features erweitert wurde (Bild 3). Das Protokoll setzt sich dabei aus drei Teilen zusammen: Der erste Teil ist der ein Byte große Header, der den Beginn des zu übertragenden Datenstromes einleitet. Darauf folgt der Datenteil, der die eigentlichen Nutzdaten beinhaltet. Da die Wahrscheinlichkeit einer aufeinanderfolgenden Redundanz im Nutzdatenstrom sehr hoch ist, wurde ein Komprimierungsalgorithmus eingesetzt, der gleiche Teile im Datenstrom zusammenfasst. 3
Durch diese Methode lassen sich nicht nur mehr Informationen pro Paket zusammenfassen, auch die Übertragung von identischen nacheinander folgenden Mustern wird unterbunden. Als Abschluss der eigentlichen Nutzdaten folgt ein Byte als terminierendes Zeichen, gefolgt von einer ein Byte langen Prüfziffer. Die Prüfziffer errechnet sich aus der Quersumme des Nutzdatenstroms und dient zur Sicherheit vor Manipulation oder Beschädigung. Eine Rekonstruktion des Datenstromes mit Hilfe der Prüfziffer ist aufgrund der Prüfzifferlänge und deren Zusammensetzung nicht möglich. Bild 3: Aufbau des Remote Serial Protocol (vereinfachte Darstellung) Das beschriebene Execution Mode Debugging lässt sich immer dann sinnvoll einsetzen, wenn das Hauptaugenmerk der Applikationsentwicklung gilt. Ein Anhalten des gesamten Systems ist bei dieser Konstellation für das Debugging definitiv nicht notwendig (Bild 4) Bild 4: Linux Applikations - Debugging (Execution Mode) mit der Universal Debug Engine (UDE) 4
Kernel- und Applikationsdebugging (Freeze Mode Debugging) Das Freeze Mode Debugging wird im Gegensatz zum Execution Mode-Debugging hauptsächlich bei der Fehlersuche auf dem Kernel eingesetzt. Es unterscheidet sich vor allem dadurch, dass das gesamte System bei Erreichen eines Unterbrechungspunktes angehalten wird. Diese Debug-Methode erweist sich sinnvoll, wenn zum Beispiel bei Kernel-Oops/Ooms der Bootvorgang des Linux-Kernels untersucht werden muss, das Laden beziehungsweise Entladen eines Treibermoduls fehlschlägt oder der Treiber während des Betriebes auf Fehler oder Performance- Engpässen zu überprüfen ist. Als Werkzeuge können alle Standard-Debug-Funktionen, wie zum Beispiel das Setzen von Code- oder Daten-Breakpoint, Step-in/Step-over-Routinen, asynchrone, vom Nutzer getriggert Breaks oder das Auslesen des Call Stack verwendet werden. Darstellung von Prozessinformationen Neben dem Debuggen von Kernel-Routinen oder Treibermodulen durch Unterbrechungspunkte ist auch das Anzeigen von Informationen aktuell gestarteter Prozesse, Dienste oder Kernelthreads möglich. In der Übersicht in Bild 5 werden nicht nur alle Prozessnamen angezeigt, sondern auch Informationen wie der aktuelle Running-Zustand, die dynamische beziehungsweise statische Priorität, Prozessflags, die aktuell zugewiesene Prozessorzeit (time slice) oder die virtuelle Adresse der Page, die die angezeigte Applikation enthält, dargestellt. Der Detailierungsgrad ist dabei wahlfrei einstellbar. Bild 5: UDE ermöglicht dem Anwender beim Freeze Mode Debugging einen schnellen Überblick über alle wesentlichen Parameter der Prozesse. Durch die Verwendung eines speziellen JTAG-I/O-Treibers können Prozessinformationen übrigens nicht nur im angehaltenen Zustand, sondern auch im laufenden Betrieb ausgewertet und analysiert werden. Dieser Treiber kann nachladbar als Modul oder als Build-in -Treiber im Kernel eingebunden werden. 5
Die Performance des Targets wird dabei nur geringfügig beeinflusst. Neben dem Anzeigen von Prozessen ist auch das Debuggen von Applikationen möglich. Nachdem eine Applikation gestartet wurde, erkennt der Debugger dies automatisch und stoppt das System je nach Konfiguration bei Eintritt in die main - Routine. Von dort aus ist ein Steppen wie beim Execution Mode Debugging möglich. Auch das Debuggen von bereits gestarteten Applikationen ist gestattet. Die gewünschte Applikation wird dazu aus der Prozessliste ausgewählt. Integriertes Terminal-Window Über das in das Debug-Werkzeug eingebundene SimIO-Window steht während der Debug-Session ein Terminal-Window mit einer minimalen Shell (ash) zu Verfügung (Bild 6). Über diese Shell können zum Beispiel Applikationen gestartet und Kernelmodul-Treiber geladen oder entfernt werden. Auch Debug-Ausgaben von Treibermodulen oder Applikationen werden in diesem Terminal-Window angezeigt. Je nach Konfiguration des Linux-Kernels lassen sich auch Kernel-Oops/Ooms oder Kernel-Back-Traces im Terminal-Window darstellen. Da die Terminalverbindung beim Freeze Mode Debugging über den JTAG-Kanal erfolgt, ist keine weitere Verbindung zum Target-System notwendig. Bild 6: Linux Kernel-Debugging (Freeze Mode) mit Terminal-Window in der Universal Debug Engine (UDE) 6
Manuelles Laden des Linux-Kernels Zusätzlich zum Debuggen eines bereits gestarteten Linux-Kernels ist es mit Hilfe der UDE auch möglich, ein neu übersetztes Kernel-Image in das RAM des Zielsystems zu kopieren. Dies hat den Vorteil, dass das Debuggen des Kernels ab der ersten Zeile, also noch vor Einschalten der MMU, möglich ist. Auch die Bootparameter ATAG List oder Kernel command line, können bequem über eine in der UDE integrierte HTML-Seite eingestellt und an die richtige Stelle des Target- Speichers kopiert werden (Bild 7). Über eine Auswahlbox kann zudem entschieden werden, ob das Target-System eine Initrd oder via NFS das Root-Filesystem lädt. Fällt die Wahl auf das Laden einer Initrd, so kann mit der UDE eine mit dem Build-Prozess generierte minimale Initial RAM Disk ( Initrd ) direkt auf das Target kopiert werden. Die Verwendung von externen Tools entfällt somit vollständig. Bild 7: Initialisierung der Bootparameter des Linux Kernels Fazit Um das Linux Kernel- und Applikationsdebugging auf ARM9/ARM11-basierten Embedded-Systemen parallel und ohne die heutzutage üblichen Risiken gegenseitiger Blockaden durchführen zu können, ist eine Synchronisation der gebräuchlichen Debug- Arten notwendig. Dafür bedarf es allerdings neuer innovativer Werkzeuge wie der Universal Debug Engine, die ein Kernel- und Applikationsdebugging über eine einzige JTAG-Schnittstelle erlauben und durch die Integration beider Ansätze deren Vorteile vereinen, ohne das der Anwender dafür die Nachteile durch fehlende Synchronisation in Kauf nehmen muss. 7
Autor Herr, Herr Quelleangaben [1] Linux Kernel Organisation: The Linux Kernel Archives, http://www.kernel.org, 2009 [2] Free Software Foundation (FSF): gdb Server Documentation, http://www.gnu.org/software/gdb/, 2009 Firmenprofil mit Sitz in Lauta wurde 1990 von Thomas Bauch und Dr. Stefan Weiße gegründet. Das Unternehmen zählt zu den weltweit führenden Anbietern von Software-Debugging-Lösungen und kompletten Entwicklungstools für 16- und 32-Bit-Mikrocontroller. Unterstützt werden wichtige Architekturen wie TriCore, PowerArchitecture, SH-2A, XC2000/XE166, ARM, Cortex, XScale und C16x/ST10. Die innovative Softwarearchitektur der Universal Debug Engine (UDE) garantiert optimale Voraussetzungen für das Debuggen moderner SoC-basierter Systeme. Die zugehörige Gerätefamilie Universal Access Device 2 (UAD2) bietet mit Transferraten von bis zu 3,5 MByte/s und einer Vielzahl von Schnittstellen zudem völlig neue Dimensionen beim schnellen und flexiblen Zugang zu Multi-Core-Systemen. Kontaktdaten Tel: 035722-384 - 0 Fax: 035722-384 - 69 Web: www.pls-mc.com Email: info@pls-mc.com 8