Seminar oreboot UART-, GDB- und OpenOCD-Debugging

Inhaltsverzeichnis

• Einordnung
• Kompetenzziele
• Seminarinhalte
• Praxisübungen
• Methodik
• Zielgruppe
• Vorkenntnisse

Einordnung

Das Seminar kombiniert frühe UART-Diagnose mit symbolischem Debugging über GDB und einen JTAG-Server. Bootmarker, Takt- und Pinfehler, Breakpoints, Register, Speicher, Disassemblierung, Map-Datei und dokumentierte Reproduktionsfälle werden zu einem systematischen Fehlersuchverfahren verbunden.

Kompetenzziele

• UART-Signalweg und Minimalinitialisierung zuverlässig prüfen.
• Kompakte Bootmarker für frühe Stufen und Fehlercodes entwerfen.
• JTAG-Kette und Debugserver für das Zielsystem einrichten.
• ELF-Symbole, Ladeadressen und Quellpfade korrekt mit der Firmware verbinden.
• Breakpoints, Watchpoints, Register- und Speicheransicht gezielt einsetzen.
• Fehlerbefunde klein, reproduzierbar und reviewfähig dokumentieren.

Seminarinhalte

Modul 1: UART als frühe Diagnose-Schnittstelle

1. Schritt 1: Signalweg klären

   SoC-Pins, Pegel, Adapter, Baudrate, Taktquelle und Massebezug werden vor dem ersten Zugriff geprüft.

2. Schritt 2: Minimalinitialisierung schreiben

   Clock-Gate, Reset, Pinmux, Teiler, Rahmenformat und FIFO werden mit möglichst wenigen Registerzugriffen gesetzt.

3. Schritt 3: Bootmarker definieren

   Kurze, eindeutige Marker kennzeichnen Reset, DRAM, Storage, SBI und Payload, ohne frühe Stufen unnötig zu vergrößern.

4. Schritt 4: Fehler robust erfassen

   Timeouts, unplausible Zeichen, falsche Taktrate und blockierende Ausgabe werden mit Alternativprüfungen eingegrenzt.

Modul 2: GDB-, JTAG- und OpenOCD-Debugging

1. Schritt 1: Debugzugang vorbereiten

   JTAG-Pins, Adapterspannung, Resetführung, Kettenerkennung und Zugriffsrechte des SoC werden kontrolliert.

2. Schritt 2: Symbole laden

   ELF-Datei, Architektur, Ladeadresse, Relokation und Quellpfade werden zur tatsächlich laufenden Firmware passend eingerichtet.

3. Schritt 3: Frühen Ablauf stoppen

   Hardware-Breakpoints, Watchpoints, Registeransicht und disassemblierte Einzelschritte werden ohne zerstörerische Seiteneffekte eingesetzt.

4. Schritt 4: Befund dokumentieren

   Stopppunkt, Registerzustand, Speicherinhalt, erwarteter Zustand und kleinste reproduzierbare Abweichung werden für die Korrektur festgehalten.

Modul 3: Resetvektor, Assemblereinstieg und Linkerskript

1. Schritt 1: Einstiegspunkt festlegen

   Resetadresse, Symbolname, Ausrichtungsanforderungen und der Übergang vom Assemblereinstieg zu Rust werden eindeutig definiert.

2. Schritt 2: Minimalzustand herstellen

   Stackzeiger, globale Pointer, BSS-Löschung, erforderliche Register und mehrere Harts werden kontrolliert initialisiert.

3. Schritt 3: Sektionen platzieren

   Code, schreibgeschützte Daten, initialisierte Daten, BSS, Stack und eingebettete Binärdaten werden passenden Speicherbereichen zugewiesen.

4. Schritt 4: Abbild prüfen

   Map-Datei und Disassemblierung werden genutzt, um Einstieg, Sprungweiten, Adressen und unerwartete Laufzeitabhängigkeiten zu kontrollieren.

Modul 4: Build, Artefakte und Reproduzierbarkeit

1. Schritt 1: Boardziel auswählen

   Mainboard, Architektur, Feature-Satz, Payload und Ausgabeziel werden in einem nachvollziehbaren Build-Aufruf zusammengeführt.

2. Schritt 2: Zwischenprodukte untersuchen

   ELF-Dateien, Binärabbilder, Map-Dateien, Disassemblierung und Größeninformationen werden den Bootstufen zugeordnet.

3. Schritt 3: Layout kontrollieren

   Startadressen, Sektionen, Ausrichtung, BSS, Stack, eingebettete Daten und freie Bereiche werden gegen das geplante Speicherlayout geprüft.

4. Schritt 4: Buildvergleich etablieren

   Hashwerte, Werkzeugversionen, Buildprotokoll und deterministische Parameter werden für wiederholbare Ergebnisse erfasst.

Modul 5: RISC-V-Privilegien, Harts und Trap-Verhalten

1. Schritt 1: Startprivileg bestimmen

   Machine-, Supervisor- und gegebenenfalls User-Modus werden den Firmware- und Betriebssystemaufgaben zugeordnet.

2. Schritt 2: CSR-Zustand prüfen

   Status-, Interrupt-, Trap-, Delegations- und Adressübersetzungsregister werden vor jedem Moduswechsel kontrolliert.

3. Schritt 3: Mehrere Harts koordinieren

   Boot-Hart, wartende Harts, Interprozessorunterbrechungen und gemeinsame Initialisierungsdaten werden ohne Rennen organisiert.

4. Schritt 4: Trap-Pfade testen

   Unerlaubte Instruktion, Zugriffsfault, Timer- und Softwareinterrupt werden mit eindeutigen Diagnoseinformationen behandelt.

Modul 6: Hardwarelabor und Abnahmemessungen

1. Schritt 1: Laborzustand standardisieren

   Versorgung, Adapter, Kabel, Bootschalter, Flashinhalt, Messgeräte und Hostsoftware werden vor jedem Versuch dokumentiert.

2. Schritt 2: Beobachtungspunkte verbinden

   Serielle Konsole, JTAG, Logikanalysator und Strommessung werden so vorbereitet, dass Bootphasen zeitlich zugeordnet werden können.

3. Schritt 3: Testfälle ausführen

   Kaltstart, Warmstart, wiederholter Reset, fehlendes Medium, beschädigtes Abbild und Recovery werden mit festen Erwartungswerten geprüft.

4. Schritt 4: Abnahme protokollieren

   Firmwarehash, Boardrevision, Messergebnis, Konsolenausgabe, Abweichung und Entscheidung werden in einem reproduzierbaren Prüfprotokoll zusammengeführt.

Praxisübungen

• UART-Pegel, Baudrate, Taktteiler und Pinmux anhand eines Fehlerbilds prüfen.
• Bootmarker für Reset, DRAM, Storage und Payload einbauen.
• GDB mit dem ELF-Artefakt und einem Debugserver verbinden.
• Frühen Einstieg stoppen, Register prüfen und kontrolliert weiterschalten.
• Watchpoint auf eine kritische Speicherstelle setzen.
• Einen vollständigen Fehlerbefund mit Reproduktionsschritten erstellen.

Methodik

Fachliche Einordnung, kommentierte Demonstrationen und schrittweise Laboraufgaben werden eng miteinander verbunden. Jeder Arbeitsabschnitt beginnt mit einem überprüfbaren Zielzustand, wird anhand von Konsolen-, Build- oder Messdaten kontrolliert und endet mit einer dokumentierten Fehler- oder Abnahmeprüfung. Vorbereitete Negativfälle verhindern, dass ausschließlich der erfolgreiche Idealfall betrachtet wird.

Zielgruppe

Firmwareentwicklung, Board-Bring-up, Embedded-Linux-Integration, Hardwaretest und technische Supportteams.

Vorkenntnisse

Grundkenntnisse in Rechnerarchitektur, serieller Konsole und systemnaher Programmierung. Für den JTAG-Teil sind ein unterstützter Adapter und ein zugänglicher Debugport erforderlich.