Seminar oreboot RISC-V Privilegien, SBI und RustSBI

Inhaltsverzeichnis

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

Einordnung

Das Seminar vertieft die RISC-V-Mechanismen zwischen früher Firmware und Linux. Machine- und Supervisor-Modus, CSRs, Trap- und Interruptpfade, Hartkoordination, Delegation, SBI-Erweiterungen, RustSBI-Plattformadapter und der kontrollierte Moduswechsel werden praktisch geprüft.

Kompetenzziele

• Privilegstufen und Zuständigkeiten von Firmware, SBI und Kernel sauber trennen.
• CSR-, Trap-, Interrupt- und Delegationszustände nachvollziehbar konfigurieren.
• Mehrere Harts sicher starten, parken und an den Supervisor übergeben.
• Timer-, Reset- und Hartfunktionen über SBI bereitstellen und testen.
• RustSBI-Plattformadapter mit oreboot-Initialisierung und Device Tree verbinden.
• Fehler beim Moduswechsel anhand von Register- und Trapdaten diagnostizieren.

Seminarinhalte

Modul 1: 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 2: 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 3: 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 4: 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 5: Device Tree, DTB und Hardwarebeschreibung

1. Schritt 1: Hardwareknoten erfassen

   CPU, Speicher, UART, Timer, Interruptcontroller, Flash, SD-Schnittstelle und reservierte Speicherbereiche werden fachlich geprüft.

2. Schritt 2: Bootparameter pflegen

   Konsolenpfad, Kernelparameter, Initrd-Bereich und gewählte Knoten werden für die geplante Nutzlast konsistent gesetzt.

3. Schritt 3: DTB erzeugen und prüfen

   Quellbaum, Includes, Kompilierung, Deassemblierung und strukturelle Plausibilitätsprüfung werden als fester Arbeitsablauf ausgeführt.

4. Schritt 4: Übergabe verifizieren

   Adresse, Größe, Speicherüberlappung und tatsächlich vom Betriebssystem erkannte Hardware werden mit der Firmwarekonfiguration abgeglichen.

Modul 6: Ü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 7: 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 8: QEMU-Emulation und kontrollierter Erststart

1. Schritt 1: Maschinenmodell vorbereiten

   CPU, Arbeitsspeicher, Firmwareabbild, serielle Konsole, Laufwerke und Payload werden als reproduzierbares Emulationsprofil festgelegt.

2. Schritt 2: Bootausgabe beobachten

   Frühe Marker, UART-Ausgabe, SBI-Meldungen, Device-Tree-Übergabe und Kernelstart werden einer erwarteten Sequenz gegenübergestellt.

3. Schritt 3: Fehler gezielt erzeugen

   Fehlende Payload, falsche Adresse, beschädigtes Dateisystem und ungültiger Device Tree werden als Negativfälle getestet.

4. Schritt 4: Testlauf automatisieren

   Timeout, erwartete Konsolenmuster, Rückgabestatus und Artefaktsicherung werden in einen wiederholbaren Testschritt überführt.

Praxisübungen

• CSR-Zustand vor und nach einem geplanten Privilegwechsel vergleichen.
• Trap-Handler für unerlaubte Instruktion und Zugriffsfault instrumentieren.
• Boot-Hart und sekundäre Harts mit eindeutigem Zustandsmodell koordinieren.
• SBI-Timer- und Systemresetpfad in QEMU oder Laborumgebung testen.
• Kernelübergabe mit Hart-ID und Device-Tree-Zeiger verifizieren.

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

RISC-V-Firmwareentwickler, Embedded-Linux-Teams, RustSBI-Integration, Plattformarchitektur und technische Debug-Verantwortliche.

Vorkenntnisse

Gute Kenntnisse in Rechnerarchitektur und systemnaher Programmierung. RISC-V-Assemblergrundlagen, Rust und Erfahrung mit GDB oder QEMU sind hilfreich.