Seminar oreboot auf Sunxi D1 und Nezha

Inhaltsverzeichnis

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

Einordnung

Der Praxisworkshop behandelt den Sunxi-D1-Bootweg auf einer Nezha-orientierten Plattform. Die kontrollierte Nutzung von Boot-ROM- und FEL-Recovery, frühem SRAM-Code, UART, DRAM, Storage, SBI und Linuxübergabe steht im Vordergrund.

Kompetenzziele

• Boot-ROM, Bootreihenfolge und FEL-Recovery für das Laborgerät sicher anwenden.
• Frühe oreboot-Stufen mit UART-Markern erzeugen und laden.
• D1-spezifische Clock-, Pin-, DRAM- und Storageabhängigkeiten prüfen.
• Firmwareabbild, Device Tree, RustSBI und Kernelübergabe konsistent zusammensetzen.
• Ein fehlgeschlagenes Flashen kontrolliert zurücksetzen und dokumentieren.

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

Modul 3: Entwicklungsumgebung und Rust-Toolchain

1. Schritt 1: Werkzeugbestand erfassen

   Rust-Toolchain, Cross-Compiler, Binutils, Device-Tree-Compiler, Emulator, serielle Werkzeuge und Flash-Hilfen werden versioniert dokumentiert.

2. Schritt 2: Zielplattform einrichten

   Target-Spezifikation, Runner, Linker, Rust-Quellenkomponenten und benötigte Cargo-Erweiterungen werden reproduzierbar konfiguriert.

3. Schritt 3: Build-Umgebung isolieren

   Pfadabhängigkeiten, Umgebungsvariablen, Cache-Verhalten und lokale Werkzeuge werden so festgelegt, dass mehrere Arbeitsplätze gleiche Artefakte erzeugen.

4. Schritt 4: Diagnose durchführen

   Fehlende Targets, Linkerfehler, inkompatible Nightly-Funktionen und Werkzeugsuchpfade werden anhand eines systematischen Prüfablaufs eingegrenzt.

Modul 4: Speicherlayout, Firmwareabbild und DTFS

1. Schritt 1: Adressräume erfassen

   Boot-ROM, SRAM, Memory-Mapped Flash, DRAM, Gerätefenster und reservierte Bereiche werden in einer gemeinsamen Karte dokumentiert.

2. Schritt 2: Abbild gliedern

   Frühe Stufe, Hauptstufe, Device Tree, Payload und optionale Konfigurationsdaten erhalten feste, ausgerichtete Bereiche.

3. Schritt 3: DTFS aufbauen

   Dateinamen, Offsets, Größen, Ausrichtung und maximale Kapazität werden so definiert, dass Loader und Buildwerkzeuge dieselbe Struktur verwenden.

4. Schritt 4: Grenzfälle testen

   Zu große Payloads, überlappende Bereiche, falsche Ausrichtung und unvollständige Abbilder werden vor dem Flashen erkannt.

Modul 5: 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 6: 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 7: 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 8: SBI und RustSBI als Übergabeschicht

1. Schritt 1: SBI-Rolle festlegen

   Timer, Interprozessorunterbrechung, Systemreset, Hartzustand und herstellerspezifische Erweiterungen werden zwischen Firmware und Supervisor getrennt.

2. Schritt 2: Plattformadapter anbinden

   Timerquelle, Interruptmechanismus, Resetpfad und Konsolenausgabe werden in die SBI-Implementierung integriert.

3. Schritt 3: Übergaberegister setzen

   Hart-ID, Device-Tree-Zeiger, Supervisor-Einstieg, Statusregister und Delegationen werden vor dem Moduswechsel verifiziert.

4. Schritt 4: SBI-Aufrufe prüfen

   Kernelanforderungen, Fehlercodes, nicht unterstützte Erweiterungen und Systemreset werden mit reproduzierbaren Tests bewertet.

Modul 9: Übergabe an Kernel und Betriebssystem

1. Schritt 1: Einstiegsvertrag prüfen

   Architekturabhängige Register, Privilegstufe, Interruptzustand, Cachezustand und erwarteter Einstiegspunkt werden festgehalten.

2. Schritt 2: Speicher freigeben

   Firmwarebereiche, reservierter Speicher, Device Tree, Initramfs und Kernel werden ohne Überlappung an das Betriebssystem übergeben.

3. Schritt 3: Gerätebeschreibung abstimmen

   Aktivierte Hardware, Konsolenpfad, Speicherkapazität, Interrupts und Bootargumente werden auf Konsistenz geprüft.

4. Schritt 4: Startnachweis führen

   Letzter Firmwaremarker, erster Kernelmarker, erkannter Speicher, Initialisierung der Konsole und Eintritt in den Userspace werden protokolliert.

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

Praxisübungen

• Bootschalter, FEL-Erkennung und Rückkehr zum Recovery-Modus testen.
• Ein Abbild mit früher Stufe, Hauptstufe, Device Tree und Payload erzeugen.
• UART- und DRAM-Meilensteine mit gezielten Fehlerfällen prüfen.
• RustSBI- und Kernelübergabe einschließlich Device-Tree-Adresse verifizieren.
• Originalabbild sichern, Testabbild flashen 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

Firmware- und Embedded-Linux-Entwicklung, RISC-V-Plattformteams, Board-Labore und technische Systemintegration.

Vorkenntnisse

Rust- oder systemnahe Programmierkenntnisse, RISC-V-Grundlagen, Linux-Kommandozeile und serieller Konsolenzugriff. Ein recoverbares D1- oder Nezha-Laborsystem ist erforderlich.