Seminar oreboot Intensivseminar 2: Portierung, Hardwareinitialisierung und Debugging

Inhaltsverzeichnis

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

Einordnung

Das zweite Intensivseminar bündelt Mainboard-Portierung, Boarddokumentation, Reset- und Linkerpfad, PAC und HAL, UART, DRAM, SPI, SD und eMMC, Flashing, Recovery, JTAG-Debugging und Hardwareabnahme. Plattformbeispiele aus Canaan K230, Rockchip RK3566, StarFive und Sunxi D1 werden in die Methodik eingeordnet.

Kompetenzziele

• Eine neue Plattform in überprüfbare Bring-up-Meilensteine zerlegen.
• SoC-Register, SVD, PAC und HAL für frühe Initialisierungen nutzen.
• UART, DRAM und Bootmedien mit Timeouts und Diagnosepfaden aktivieren.
• Flash-, Debug- und Recoveryabläufe sicher im Hardwarelabor durchführen.
• Plattformspezifische Abweichungen ohne unwartbare Codekopplung behandeln.
• Einen vollständigen Board-Abnahmenachweis erstellen.

Seminarinhalte

Modul 1: Boarddokumentation und technische Vorprüfung

1. Schritt 1: Unterlagen ordnen

   SoC-Handbuch, Board-Schaltplan, Speicherbestückung, Bootschalter, Pinbelegung und bekannte Errata werden versionsbezogen erfasst.

2. Schritt 2: Bootkonfiguration prüfen

   Straps, eFuses, Bootreihenfolge, Recovery-Modi und Sicherheitszustände werden für das konkrete Board dokumentiert.

3. Schritt 3: Messpunkte festlegen

   UART, JTAG, Reset, Versorgungsschienen, Takte und wichtige Chip-Select-Signale werden für das Labor zugänglich gemacht.

4. Schritt 4: Risiken bewerten

   Fehlende Dokumentation, geschlossene Initialisierungsbestandteile, nicht rücksetzbare Optionen und schwer zugängliche Flashbausteine werden vor Beginn markiert.

Modul 2: Mainboard-Portierung und schrittweises Bring-up

1. Schritt 1: Minimalziel definieren

   Erster serieller Marker, stabiler DRAM, lesbares Bootmedium, SBI-Übergabe und Kernelstart werden als aufeinanderfolgende Meilensteine festgelegt.

2. Schritt 2: Boardstruktur anlegen

   Frühe Stufe, Hauptstufe, Cargo-Dateien, Linkerskripte, Build-Skript, Makefile und Device Tree werden mit minimalen Abhängigkeiten erstellt.

3. Schritt 3: Hardware einzeln aktivieren

   Clock, Reset, Pinmux, UART, Timer, DRAM und Storage werden nacheinander aktiviert und nach jedem Schritt geprüft.

4. Schritt 4: Port stabilisieren

   Fehlerpfade, Timeouts, Dokumentation, reproduzierbarer Build, Emulations- oder Hardwaretests und Reviewaufteilung werden ergänzt.

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: SVD-basierte SoC-Erschließung

1. Schritt 1: Beschreibungsqualität prüfen

   Peripherieblöcke, Adressen, Registerbreiten, Felder, Enumerationen, Resetwerte und bekannte Lücken werden gegen das Handbuch abgeglichen.

2. Schritt 2: PAC generieren

   Namenskonventionen, Feature-Aufteilung, Generierungsparameter und reproduzierbare Erzeugung werden im Projekt festgelegt.

3. Schritt 3: Abweichungen korrigieren

   Fehlerhafte Offsets, fehlende Felder und herstellerspezifische Sonderfälle werden dokumentiert und möglichst an der Beschreibungsquelle behoben.

4. Schritt 4: HAL-Grenzen entwerfen

   Wiederkehrende Abläufe für UART, GPIO, Clock, Reset und Speichercontroller werden oberhalb der Registerebene stabil gekapselt.

Modul 5: Registerzugriffe, PAC und HAL

1. Schritt 1: Registermodell auswählen

   Manuelle Registerdefinition, generierter Peripheral Access Crate und Hardware-Abstraction-Layer werden nach Dokumentationslage und Wiederverwendbarkeit bewertet.

2. Schritt 2: Zugriffe typisieren

   Lesen, Schreiben, Read-Modify-Write, reservierte Bits und write-one-to-clear-Verhalten werden in sichere Bedienmuster überführt.

3. Schritt 3: Takt und Reset berücksichtigen

   Vor jedem Peripheriezugriff werden Clock-Gates, Resetleitungen, Pin-Multiplexing und notwendige Wartezeiten geprüft.

4. Schritt 4: Seiteneffekte testen

   Registerwerte, externe Signale, Timeout-Verhalten und Wiederholbarkeit werden mit serieller Diagnose und Messmitteln validiert.

Modul 6: 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 7: DRAM-Initialisierung und Speichertraining

1. Schritt 1: Parameter beschaffen

   Speichertyp, Takt, Topologie, Breite, Ranks, Timingwerte, Spannungen und Boardrouting werden aus belastbaren Hardwareangaben zusammengestellt.

2. Schritt 2: Controller vorbereiten

   Takt, Reset, PHY, Betriebsmodus, Timingregister und Initialisierungssequenz werden in einer kontrollierten Reihenfolge programmiert.

3. Schritt 3: Training überwachen

   Statusregister, Wartebedingungen, Timeouts und Fehlercodes werden mit frühen Diagnosemarkern sichtbar gemacht.

4. Schritt 4: Speicher validieren

   Adressleitungen, Datenmuster, verschiedene Größen, Cachezustände und Grenzbereiche werden vor dem Laden weiterer Stufen geprüft.

Modul 8: SPI-Flash und Firmwarezugriff

1. Schritt 1: Controller initialisieren

   Takt, Pin-Multiplexing, Chip-Select, Modus, Wortbreite und sichere Anfangsfrequenz werden gesetzt.

2. Schritt 2: Baustein identifizieren

   JEDEC-Kennung, Kapazität, Adressmodus, Statusregister und Schutzbits werden ausgelesen und plausibilisiert.

3. Schritt 3: Lesepfad implementieren

   Befehl, Adresse, Dummy-Zyklen, Transfergrenzen und Timeout werden in einen kleinen, testbaren Treiber überführt.

4. Schritt 4: Schreibschutz beachten

   Löschen, Programmieren, Busy-Prüfung, Verifikation und Recovery werden getrennt vom normalen Boot-Lesepfad behandelt.

Modul 9: SD- und eMMC-Zugriff

1. Schritt 1: Hostcontroller starten

   Clock, Reset, Pins, Versorgung und Identifikationsfrequenz werden vor der Kartenkommunikation geprüft.

2. Schritt 2: Medium identifizieren

   Resetfolge, Fähigkeiten, Kapazität, Blocklänge und Busbreite werden mit klaren Timeouts ermittelt.

3. Schritt 3: Blockleser aufbauen

   Einzel- und Mehrblockzugriff, DMA- oder PIO-Pfad, Alignment, Cachebehandlung und Fehlercodes werden implementiert.

4. Schritt 4: Bootdaten prüfen

   DTFS- oder Payloadbereiche werden blockweise gelesen, auf Grenzen geprüft und vor der Ausführung verifiziert.

Modul 10: 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 11: Flashing, Recovery und sichere Laborabläufe

1. Schritt 1: Bootpfade inventarisieren

   Normales Bootmedium, Boot-ROM-Modus, USB- oder serielle Recovery, Wechselmedium und externe Programmierung werden nach Priorität erfasst.

2. Schritt 2: Sicherungsabbild erstellen

   Originalinhalt, Gerätekonfiguration, eindeutige Hashwerte und Rücksicherungsanweisung werden vor Änderungen gesichert.

3. Schritt 3: Abbild schreiben

   Zieloffset, Löschbereich, Schreibgröße, Versorgung und Schreibschutz werden vor dem Programmiervorgang kontrolliert.

4. Schritt 4: Recovery proben

   Ein absichtlich nicht startendes Testabbild wird über den vorgesehenen Notfallpfad erkannt, ersetzt und anschließend verifiziert.

Modul 12: 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.

Modul 13: Canaan K230 und CanMV-orientierter Boardpfad

1. Schritt 1: K230-Startumgebung einordnen

   Boot-ROM-Verhalten, RISC-V-Harts, frühe Speicherbereiche und verfügbare Recovery-Wege werden für das Zielboard zusammengestellt.

2. Schritt 2: Boarddateien abgleichen

   Vorhandene frühe und spätere Stufen, Linkerannahmen, Device Tree und Payloadpositionen werden gegen das konkrete Board geprüft.

3. Schritt 3: Peripherie priorisieren

   UART, Clock, Reset, DRAM und das vorgesehene Bootmedium werden in einer bring-up-gerechten Reihenfolge bearbeitet.

4. Schritt 4: Boot bis Linux nachweisen

   Serielle Marker, SBI-Übergabe, Device Tree und Kernelstart werden als zusammenhängender Nachweis dokumentiert.

Modul 14: Rockchip RK3566 und boardbezogenes Bring-up

1. Schritt 1: Bootpfad und Speicherfenster prüfen

   Boot-ROM, interne SRAM-Bereiche, DRAM, Memory-Mapped Peripherie und das gewählte Startmedium werden in einer Adresskarte zusammengeführt.

2. Schritt 2: Clock-, Reset- und Pinlogik vorbereiten

   Abhängigkeiten für UART, Speichercontroller und Storage werden aus dem SoC-Modell in kleine Initialisierungsschritte überführt.

3. Schritt 3: Frühe Stufen validieren

   Assemblereinstieg, Stack, serielle Ausgabe und Übergang in die Hauptstufe werden mit Map-Datei und Debugzugang geprüft.

4. Schritt 4: Plattformtests erstellen

   Bootwiederholungen, Speicherprüfung, Mediumswechsel, Negativfälle und Recovery werden als Board-Prüfplan festgehalten.

Modul 15: StarFive JH7100 und JH7110 im Vergleich

1. Schritt 1: Generationen trennen

   CPU-, Boot-, Clock-, Speicher- und Peripherieunterschiede zwischen den beiden SoC-Generationen werden vor gemeinsamer Codebildung dokumentiert.

2. Schritt 2: Gemeinsame Bausteine identifizieren

   RISC-V-Start, SBI-Anbindung, UART-Muster, Device-Tree-Verarbeitung und generische Loaderlogik werden von boardspezifischem Code getrennt.

3. Schritt 3: VisionFive-Varianten konfigurieren

   Boardrevision, DRAM-Bestückung, Bootmedium, Pinbelegung und vorhandene Recovery-Möglichkeiten werden je Zielsystem festgelegt.

4. Schritt 4: Kompatibilität testen

   Je Board werden Build, serielle Ausgabe, DRAM, Storage, SBI und Kernelstart mit identischen Abnahmekriterien geprüft.

Modul 16: Sunxi D1 und Nezha-spezifischer Bootweg

1. Schritt 1: Boot-ROM und FEL einordnen

   Bootreihenfolge, USB-basierter Ladeweg, SRAM-Nutzung und sichere Rückkehr in den Recovery-Modus werden nachvollzogen.

2. Schritt 2: D1-Initialisierung strukturieren

   RISC-V-Einstieg, Clock, Pinmux, UART, DRAM und Speichermedium werden in kleine, beobachtbare Bring-up-Schritte zerlegt.

3. Schritt 3: Firmwareabbild zusammensetzen

   Frühe Stufe, Hauptstufe, Device Tree und Payload werden mit festen Offsets und Größenkontrollen in ein flashbares Abbild integriert.

4. Schritt 4: Linuxstart prüfen

   RustSBI- oder SBI-Übergabe, Hart-ID, Device Tree, Kernelparameter und serielle Kernelmeldungen werden durchgehend kontrolliert.

Praxisübungen

• Boardakte, Speicherkarte, Bootpfade und Bring-up-Plan erstellen.
• Frühe Stufe mit Stack, UART und klaren Fehlercodes entwickeln.
• PAC- oder Registerzugriffe für Clock, Reset und Pinmux implementieren.
• DRAM- und Storagepfad mit Positiv- und Negativtests prüfen.
• Nicht startendes Abbild mit JTAG oder serieller Diagnose eingrenzen und recovern.
• Vier Plattformmuster vergleichen und gemeinsame Portierungsregeln ableiten.
• Board-Abnahme mit Kaltstart, Reset, Mediumsfehler und Rücksicherung durchführen.

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

Erfahrene Firmwareentwickler, Board-Bring-up-Teams, Embedded-Linux-Integration, Hardware-nahe Testteams und Plattformmaintainer.

Vorkenntnisse

Sichere systemnahe Programmierkenntnisse, Rust- oder Embedded-C-Erfahrung, MMIO, Linkerskripte und serielle Diagnose. Ein recoverbares Hardwarelabor ist für den vollen Umfang erforderlich.