Seminar oreboot auf Rockchip RK3566: Bring-up-Workshop

Inhaltsverzeichnis

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

Einordnung

Der Workshop behandelt das kontrollierte Bring-up einer RK3566-basierten Plattform mit oreboot. Der Schwerpunkt liegt auf der Abfolge von Boot-ROM-Annahmen, SRAM-Code, Clock- und Resetlogik, UART, DRAM, Storage und der Übergabe an eine Linux-Nutzlast.

Kompetenzziele

• RK3566-Adressräume, Bootpfade und boardabhängige Voraussetzungen strukturiert erfassen.
• Frühe Stufen und Linkerlayout für den konkreten Startpfad prüfen.
• Clock, Reset, Pinmux, UART, DRAM und Storage schrittweise in Betrieb nehmen.
• Fehler mit serieller Diagnose, Map-Datei und Debugzugang eingrenzen.
• Ein reproduzierbares Abbild mit Recovery- und Abnahmeverfahren bereitstellen.

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: 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 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: 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 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: 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 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 Adress- und Taktabhängigkeitskarte für das Zielboard ausarbeiten.
• Assemblereinstieg, Stack und UART-Ausgabe in einer minimalen frühen Stufe prüfen.
• DRAM-Initialisierung mit Timeouts und Speichertest instrumentieren.
• Firmwareabbild auf SPI- oder vorgesehenem Bootmedium verifizieren.
• Kaltstart-, Reset- und Recovery-Testfälle als Board-Abnahmeprotokoll ausfü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

Firmwareentwicklung, Embedded-Linux-Teams, Board-Bring-up, Hardware-nahe Systemintegration und Plattformwartung.

Vorkenntnisse

Erfahrung mit Rust oder C-naher Firmwareentwicklung, MMIO, Linkerskripten und serieller Diagnose. Zugriff auf Schaltplan, RK3566-Unterlagen und ein recoverbares Laborboard ist erforderlich.