Seminar oreboot auf StarFive JH7100 und JH7110

Inhaltsverzeichnis

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

Einordnung

Das Seminar verbindet die Portierungsmethodik mit den Besonderheiten der StarFive-Generationen JH7100 und JH7110. Gemeinsame RISC-V-Bausteine werden von generations- und boardspezifischen Initialisierungen getrennt, damit VisionFive-Plattformen nachvollziehbar gebaut und getestet werden können.

Kompetenzziele

• JH7100- und JH7110-Unterschiede für Boot, Speicher und Peripherie technisch einordnen.
• Gemeinsame und getrennte Codepfade für SoC und Mainboard entwerfen.
• Frühe Ausgabe, DRAM, Storage, SBI und Device Tree je Plattform prüfen.
• Einheitliche Abnahmekriterien für mehrere Boardvarianten anwenden.
• Wartbare Änderungen mit dokumentiertem Testnachweis vorbereiten.

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: 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 3: Quellbaum, Mainboards und Build-Zusammenhang

1. Schritt 1: Verzeichnisstruktur lesen

   Workspace, Architekturcode, SoC-Unterstützung, Mainboard-Verzeichnisse, Bibliotheken und Werkzeuge werden funktional zugeordnet.

2. Schritt 2: Boardpfad nachvollziehen

   Die Trennung von früher Stufe und Hauptstufe sowie die Rollen von Cargo-Konfiguration, Linkerskript, Build-Skript und Makefile werden untersucht.

3. Schritt 3: Abhängigkeiten prüfen

   Crates, Features, Zielarchitektur und lokale Pfade werden auf Reproduzierbarkeit, unnötige Kopplung und Plattformabhängigkeit geprüft.

4. Schritt 4: Änderungsumfang planen

   Neue Treiber, SoC-Bausteine, Boarddateien, Dokumentation und Tests werden als getrennte, reviewfähige Arbeitspakete vorbereitet.

Modul 4: 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 5: 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 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: 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 9: 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 10: 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

• Eine Differenzmatrix für JH7100, JH7110 und die verwendeten Boardrevisionen erstellen.
• Gemeinsame RISC-V- und SBI-Komponenten von boardspezifischen Initialisierungen trennen.
• UART-, DRAM- und Storage-Meilensteine auf mindestens einer Plattform praktisch prüfen.
• Device Tree und Kernelübergabe anhand eines konsistenten Testfalls verifizieren.
• Eine plattformübergreifende Regressionstestliste formulieren.

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-Firmwareentwicklung, Embedded-Linux-Teams, VisionFive-Plattformbetreuung, Board-Portierung und technische Architektur.

Vorkenntnisse

Systemnahe Programmierkenntnisse, RISC-V-Grundlagen, Cross-Build-Erfahrung und sichere serielle Diagnose. Für Vergleichsübungen sind JH7100- und JH7110-Unterlagen oder entsprechende Laborboards hilfreich.