Seminar barebox – Diagnose, Debugging und Boot-Fehleranalyse

Bootfehler treten in sehr unterschiedlichen Phasen auf und erzeugen entsprechend unterschiedliche Symptome. Das Seminar vermittelt eine phasenorientierte Diagnosemethode von der fehlenden frühen Ausgabe bis zum Kernelstillstand und verbindet Konsole, Speicherprüfung, Device Tree und externe Debughilfen.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Fehler anhand der letzten sicher erreichten Bootphase klassifizieren
• frühe Konsolenausgabe, Initcalls, Geräte- und Speicherdiagnose gezielt einsetzen
• PBL-, Treiber-, Dateisystem- und Kernelübergabefehler voneinander trennen
• reproduzierbare Fehlerberichte und belastbare Recovery-Schritte erstellen

Zielgruppe

BSP-Entwicklung, Support, Systemintegration, Qualitätssicherung, Produktion und technische Betriebsverantwortung.

Voraussetzungen

Grundkenntnisse zu barebox-Architektur, serieller Konsole, Device Tree und Linux-Boot.

Seminarinhalte

1. Schritt 1: Fehlerphase und Symptom erfassen

   Der Abschnitt ordnet „Fehlerphase und Symptom erfassen“ in den Gesamtprozess ein. Zunächst werden Voraussetzungen und Abhängigkeiten erfasst. Danach werden die Arbeitspunkte am System umgesetzt, geprüft und mit eindeutigen Abbruchkriterien dokumentiert.

   • kein Startsignal oder kein Konsolentext
   • Abbruch im PBL oder in barebox proper
   • Fehler beim Laden oder Starten von Linux
2. Schritt 2: Frühe Konsole und PBL untersuchen

   Ausgehend von einem definierten Ausgangszustand wird „Frühe Konsole und PBL untersuchen“ schrittweise aufgebaut. Konfiguration, Laufzeitverhalten und typische Fehlersignale werden miteinander verglichen. Der fertige Ablauf bleibt reproduzierbar und für weitere Projektphasen verwendbar.

   • richtige UART und Pinbelegung
   • Program Counter und Stackbereich
   • DRAM-Initialisierung und Rücksprungadressen
3. Schritt 3: Initcalls und Geräte-Probe verfolgen

   Im Mittelpunkt steht „Initcalls und Geräte-Probe verfolgen“. Die zugehörigen Daten, Ressourcen und Zustandsübergänge werden sichtbar gemacht, anschließend praktisch verändert und danach gegen den erwarteten Sollzustand validiert.

   • Initcall-Ausgaben
   • Probe-Rückgabewerte
   • Clocks, Resets, Regulatoren und Pinctrl
4. Schritt 4: Shellbasierte Systemdiagnose durchführen

   Für „Shellbasierte Systemdiagnose durchführen“ wird eine feste Prüfreihenfolge verwendet. Jeder Teilschritt erhält Eingangsdaten, eine konkrete Aktion, erwartete Ausgaben und einen definierten Fehlerpfad. Dadurch entstehen belastbare Diagnose- und Integrationsschritte.

   • Geräte- und Treiberstatus
   • Speicher- und Dateisystemzugriff
   • Environment, State und Boot Entries
5. Schritt 5: Device Tree und Speicherfehler isolieren

   Der Abschnitt ordnet „Device Tree und Speicherfehler isolieren“ in den Gesamtprozess ein. Zunächst werden Voraussetzungen und Abhängigkeiten erfasst. Danach werden die Arbeitspunkte am System umgesetzt, geprüft und mit eindeutigen Abbruchkriterien dokumentiert.

   • memory und reserved-memory
   • reg-Bereiche und Adressübersetzung
   • Fixups und Overlays
6. Schritt 6: Kernelübergabe und frühen Linux-Start prüfen

   Ausgehend von einem definierten Ausgangszustand wird „Kernelübergabe und frühen Linux-Start prüfen“ schrittweise aufgebaut. Konfiguration, Laufzeitverhalten und typische Fehlersignale werden miteinander verglichen. Der fertige Ablauf bleibt reproduzierbar und für weitere Projektphasen verwendbar.

   • Imageformat und Ladeadresse
   • Konsole und earlycon-Parameter
   • DTB und reservierter Speicher
7. Schritt 7: Externe Debugwege einsetzen

   Im Mittelpunkt steht „Externe Debugwege einsetzen“. Die zugehörigen Daten, Ressourcen und Zustandsübergänge werden sichtbar gemacht, anschließend praktisch verändert und danach gegen den erwarteten Sollzustand validiert.

   • JTAG oder OpenOCD
   • Breakpoints in frühem Code
   • Speicherinspektion und kontrollierter Neustart
8. Schritt 8: Fehlerbericht und Recovery-Ablauf standardisieren

   Für „Fehlerbericht und Recovery-Ablauf standardisieren“ wird eine feste Prüfreihenfolge verwendet. Jeder Teilschritt erhält Eingangsdaten, eine konkrete Aktion, erwartete Ausgaben und einen definierten Fehlerpfad. Dadurch entstehen belastbare Diagnose- und Integrationsschritte.

   • Minimalfall und Vergleichssystem
   • Konsolenprotokoll und Artefaktidentität
   • Rückkehr in einen bekannten Zustand

Praxisübungen

• Mehrere vorbereitete Bootfehler anhand der Phase klassifizieren
• PBL-Stillstand mit frühem Diagnosepfad eingrenzen
• Treiber-Probe anhand fehlender Ressourcen korrigieren
• Kernelübergabe mit absichtlich falschem Device Tree analysieren
• standardisierten Supportdatensatz erstellen

Methodik

Der erste Tag schafft Modell, Konfiguration und einen funktionsfähigen Grundpfad. Der zweite Tag vertieft Integration, Fehlerbehandlung und Praxisfälle. Konsolenprotokolle, Konfigurationsstände und Prüflisten werden fortlaufend dokumentiert.