Seminar Libreboot Intensivseminar Entwicklung, Build und Portierung

Das technische Intensivformat verbindet lbmk, Quell- und Patchverwaltung, CBFS, Payloads, Vendor-Dateien, reproduzierbare Builds, Qualitätssicherung und die Grundlagen einer neuen Boardportierung. Der Schwerpunkt liegt auf wartbaren Änderungen statt einmaliger ROM-Manipulation.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Eine reproduzierbare lbmk- und Patchumgebung aufbauen
• ROMs, CBFS-Inhalte und Payloadvarianten kontrolliert entwickeln
• Boardportierung, frühe Initialisierung, Speicher und Geräte strukturiert bearbeiten
• Änderungen mit Zweitbuild, Hardwaretest, Review und Pflegeplan absichern

Zielgruppe

Firmware-Entwickler, Coreboot- und Libreboot-Integratoren, Build-Engineers, Embedded-Linux-Teams und technische Architekten.

Voraussetzungen

Gute Linux-, Git- und Shell-Kenntnisse, Grundverständnis von C, Hardwareinitialisierung und Firmware-Builds. Serieller Debugzugang und geeignete Testhardware sind für den Portierungsanteil erforderlich.

Seminarinhalte

Kapitel 1: lbmk-Arbeitsumgebung und Quellstand

Inhaltsübersicht: Buildhost vorbereiten; Quellstand festhalten; Umgebung testen

1. Schritt 1 – Buildhost vorbereiten: Unterstütztes Betriebssystem, Pakete, Speicherplatz, Netzwerkzugriff, Benutzerrechte und getrennte Arbeitsverzeichnisse werden eingerichtet.
2. Schritt 2 – Quellstand festhalten: Repository, Commit, lokale Änderungen, Submodule und verwendete Konfigurationsdateien werden eindeutig dokumentiert.
3. Schritt 3 – Umgebung testen: Werkzeuge, Compiler, Downloadpfade und ein kleiner Referenzbuild werden geprüft, bevor produktive ROMs erzeugt werden.

Kapitel 2: lbmk-Befehle, Targets und Abhängigkeiten

Inhaltsübersicht: Befehlsstruktur lesen; Target auswählen; Abhängigkeiten kontrollieren

1. Schritt 1 – Befehlsstruktur lesen: Build-, Fetch-, Update-, Release- und Bereinigungsfunktionen werden anhand ihres Datenflusses eingeordnet.
2. Schritt 2 – Target auswählen: Board, ROM-Größe, Payload-Variante und optionale Konfiguration werden bewusst statt über pauschale Sammelbefehle gewählt.
3. Schritt 3 – Abhängigkeiten kontrollieren: Quellen, Patches, Toolchains, Konfigurationen und Ausgabepfade werden zwischen zwei Builds verglichen.

Kapitel 3: Quellen, Patches und Konfigurationsschichten

Inhaltsübersicht: Patchreihenfolge verstehen; Änderung isolieren; Konflikte lösen

1. Schritt 1 – Patchreihenfolge verstehen: Projektpatches, boardbezogene Änderungen und Payload-Anpassungen werden ihrer jeweiligen Quellkomponente zugeordnet.
2. Schritt 2 – Änderung isolieren: Eine lokale Anpassung wird als kleiner, dokumentierter Patch statt als unkontrollierte Änderung im Arbeitsbaum geführt.
3. Schritt 3 – Konflikte lösen: Fehlgeschlagene Patchanwendung wird anhand von Kontext, Upstream-Änderung und gewünschtem Ergebnis fachlich bereinigt.

Kapitel 4: ROM-Build, Artefakte und Prüfsummen

Inhaltsübersicht: Build ausführen; Artefakte prüfen; Hashwerte veröffentlichen

1. Schritt 1 – Build ausführen: Ein einzelnes Boardtarget wird mit protokollierter Umgebung erzeugt; Fehler werden am ersten ursächlichen Schritt analysiert.
2. Schritt 2 – Artefakte prüfen: Dateinamen, Größe, enthaltene Payloads, Konfiguration, CBFS-Inhalt und erwartete Boardvarianten werden kontrolliert.
3. Schritt 3 – Hashwerte veröffentlichen: Freigegebene ROMs erhalten Prüfsummen, Buildprotokoll, Quellstand und eindeutige Zuordnung zum Zielgerät.

Kapitel 5: CBFS-Dateien hinzufügen, ersetzen und entfernen

Inhaltsübersicht: Änderung planen; ROM-Kopie bearbeiten; Integrität verifizieren

1. Schritt 1 – Änderung planen: Dateiname, Typ, Kompression, Zielpfad, Größe und Abhängigkeit zur Payload werden festgelegt.
2. Schritt 2 – ROM-Kopie bearbeiten: Änderungen erfolgen ausschließlich an einer Arbeitskopie; jede Operation wird protokolliert und sofort kontrolliert.
3. Schritt 3 – Integrität verifizieren: CBFS-Liste, ROM-Größe, Prüfsumme und Starttest werden nach der Änderung mit der Freigabebasis verglichen.

Kapitel 6: Payload-Konzept und Auswahlkriterien

Inhaltsübersicht: Bootanforderungen sammeln; Payload vergleichen; Entscheidung dokumentieren

1. Schritt 1 – Bootanforderungen sammeln: Betriebssysteme, Legacy-Erweiterungen, direkte Kernelstarts, Menüs, Verschlüsselung und Diagnosebedarf werden erfasst.
2. Schritt 2 – Payload vergleichen: GRUB, SeaBIOS und U-Boot werden nach Hardwareklasse, Bootpfad, Konfigurierbarkeit und Wartungsaufwand bewertet.
3. Schritt 3 – Entscheidung dokumentieren: Primär- und Fallback-Payload sowie deren Grenzen werden pro Gerätegruppe festgelegt.

Kapitel 7: GRUB als Firmware-Payload

Inhaltsübersicht: Menüstruktur entwerfen; Konfiguration testen; Wartung vorbereiten

1. Schritt 1 – Menüstruktur entwerfen: Startziele, Suchlogik, Zeitlimits, Fallbacks, Tastaturlayout und administrative Einträge werden geplant.
2. Schritt 2 – Konfiguration testen: Interne Datenträger, externe Medien, verschiedene Dateisysteme und Fehlerfälle werden in einer Testmatrix geprüft.
3. Schritt 3 – Wartung vorbereiten: Konfiguration, Schlüsselmaterial und ROM-Variante werden versioniert und mit einem sicheren Aktualisierungsweg versehen.

Kapitel 8: SeaBIOS für klassische Bootpfade

Inhaltsübersicht: Kompatibilitätsbedarf prüfen; Bootreihenfolge konfigurieren; Gerätetests ausführen

1. Schritt 1 – Kompatibilitätsbedarf prüfen: Legacy-Boot, Option-ROMs, Erweiterungskarten und Betriebssystemanforderungen werden gegen den tatsächlichen Bedarf abgewogen.
2. Schritt 2 – Bootreihenfolge konfigurieren: Datenträger, Netzwerk, Wechselmedien und Fallbackverhalten werden reproduzierbar eingestellt.
3. Schritt 3 – Gerätetests ausführen: Massenspeicher, Grafikpfad, Erweiterungskarten und Startmedien werden mit definierten Positiv- und Negativtests geprüft.

Kapitel 9: U-Boot auf geeigneten Plattformen

Inhaltsübersicht: Plattformbezug klären; Umgebung aufbauen; Recovery testen

1. Schritt 1 – Plattformbezug klären: Boardunterstützung, Gerätebaum, Speicherlayout, Konsolenzugriff und erwarteter Bootflow werden bestimmt.
2. Schritt 2 – Umgebung aufbauen: Bootvariablen, Startskripte, Kernel, Initramfs und Gerätebaum werden als reproduzierbare Konfiguration vorbereitet.
3. Schritt 3 – Recovery testen: Serielle Konsole, alternatives Medium und manuelle Startbefehle werden als Rückfallweg praktisch erprobt.

Kapitel 10: Extraktion, Einfügung und Validierung von Vendor-Dateien

Inhaltsübersicht: Quelle prüfen; Bestandteile einfügen; Ergebnis kontrollieren

1. Schritt 1 – Quelle prüfen: Ausgangsabbild, Boardzuordnung, Version, Prüfsumme und Eigentumsbezug werden vor der Extraktion dokumentiert.
2. Schritt 2 – Bestandteile einfügen: Erforderliche Dateien werden mit dem vorgesehenen Verfahren in eine eindeutig zugeordnete ROM-Kopie integriert.
3. Schritt 3 – Ergebnis kontrollieren: Werkzeugausgabe, ROM-Struktur, Dateigröße, Hashwert und Boardtest werden gegen die Freigabekriterien geprüft.

Kapitel 11: Reproduzierbarkeit und Build-Nachweis

Inhaltsübersicht: Einflussgrößen erfassen; Zweitbuild erzeugen; Abweichungen erklären

1. Schritt 1 – Einflussgrößen erfassen: Zeitstempel, Toolchain, Quellarchive, lokale Patches, Umgebungsvariablen und nicht deterministische Schritte werden identifiziert.
2. Schritt 2 – Zweitbuild erzeugen: Ein zweiter Build in sauberer Umgebung wird mit identischer Definition ausgeführt und byteweise verglichen.
3. Schritt 3 – Abweichungen erklären: Unterschiede werden lokalisiert, klassifiziert und entweder beseitigt oder im Freigabenachweis begründet.

Kapitel 12: Portierungsziel, Dokumentation und Machbarkeit

Inhaltsübersicht: Board erfassen; Unterlagen bewerten; Aufwand entscheiden

1. Schritt 1 – Board erfassen: Chipsatz, Prozessor, Super-I/O, EC, Flash, Takt, Spannungsversorgung, Speicher, Grafik und Peripherie werden technisch aufgenommen.
2. Schritt 2 – Unterlagen bewerten: Schaltplan, Datenblätter, Boardview, Hersteller-ROM, Debugzugänge und Referenzboards werden auf Verfügbarkeit geprüft.
3. Schritt 3 – Aufwand entscheiden: Vorhandene Referenzplattform, proprietäre Initialisierung, Boot Guard, fehlende Dokumentation und Testzugang bestimmen Go oder No-Go.

Kapitel 13: Coreboot-Boardstruktur und frühe Initialisierung

Inhaltsübersicht: Referenz auswählen; Boardcode anlegen; Frühen Start prüfen

1. Schritt 1 – Referenz auswählen: Ein möglichst ähnliches bereits unterstütztes Board wird anhand von Chipsatz, Super-I/O, EC und Speicherpfad ausgewählt.
2. Schritt 2 – Boardcode anlegen: Verzeichnisstruktur, Kconfig, devicetree, GPIO-Definitionen, ACPI und Buildintegration werden kontrolliert aufgebaut.
3. Schritt 3 – Frühen Start prüfen: Reset, Bootblock, romstage, Speicherinitialisierung und Übergang in ramstage werden über geeignete Debugausgaben verfolgt.

Kapitel 14: Speicherinitialisierung und Plattformparameter

Inhaltsübersicht: Speicheraufbau erfassen; Parameter übernehmen; Stabilität testen

1. Schritt 1 – Speicheraufbau erfassen: DIMM- oder verlötete Speicherbestückung, SPD-Daten, Topologie, Takt und Versorgung werden dokumentiert.
2. Schritt 2 – Parameter übernehmen: Referenzwerte werden nur nach Abgleich mit Schaltplan und Hardware übernommen; blindes Kopieren wird vermieden.
3. Schritt 3 – Stabilität testen: Kaltstart, verschiedene Module, Speichertest, Temperaturwechsel und wiederholte Neustarts werden zur Freigabe herangezogen.

Kapitel 15: Geräte, ACPI und Betriebssystemintegration

Inhaltsübersicht: Gerätebaum vervollständigen; ACPI prüfen; Fehler priorisieren

1. Schritt 1 – Gerätebaum vervollständigen: PCIe, SATA, USB, Audio, Netzwerk, Grafik, Sensoren und Eingabegeräte werden korrekt beschrieben und aktiviert.
2. Schritt 2 – ACPI prüfen: Energiezustände, Akku, Tasten, Thermik, Suspend und Wake-Ereignisse werden mit dem Betriebssystem getestet.
3. Schritt 3 – Fehler priorisieren: Bootkritische, sicherheitsrelevante und Komfortfehler werden getrennt bewertet und in einer Portierungsrestliste geführt.

Kapitel 16: Patchqualität, Review und langfristige Pflege

Inhaltsübersicht: Änderungen schneiden; Nachweise beilegen; Pflege planen

1. Schritt 1 – Änderungen schneiden: Boardenablement, allgemeine Fehlerkorrektur und Refactoring werden in prüfbare Einzelpatches getrennt.
2. Schritt 2 – Nachweise beilegen: Buildprotokoll, Bootlog, Hardwareinventar, Testmatrix und bekannte Einschränkungen begleiten die technische Änderung.
3. Schritt 3 – Pflege planen: Eigentümerschaft, Regressionsgeräte, Aktualisierungspfad und Reaktion auf Upstream-Änderungen werden verbindlich festgelegt.

Kapitel 17: Integrierter Build-, Anpassungs- und Portierungsfall

Inhaltsübersicht: Quellstand aufbauen; ROM anpassen; Qualität nachweisen

1. Schritt 1 – Quellstand aufbauen: lbmk, Quellen, Patches, Boardkonfiguration und Payload werden reproduzierbar vorbereitet.
2. Schritt 2 – ROM anpassen: CBFS-Inhalt, Bootkonfiguration und eine begrenzte Board- oder Payload-Änderung werden versioniert umgesetzt.
3. Schritt 3 – Qualität nachweisen: Zweitbuild, ROM-Analyse, Hardwaretest, Regressionsvergleich und Patchdokumentation schließen den Entwicklungsfall ab.

Praxisübungen

Ein reproduzierbares ROM mit angepasster Payloadkonfiguration wird gebaut und geprüft. Danach wird an einem vorbereiteten Referenzboard eine begrenzte Portierungsänderung entwickelt, geloggt, getestet und als reviewfähiger Patch dokumentiert.

Methodik

Technische Kurzvorträge wechseln mit Shell-, Build-, ROM-Analyse- und Debuglaboren. Änderungen werden in Versionsverwaltung geführt, auf Testhardware geprüft und mit reproduzierbarem Build- sowie Review-Nachweis abgeschlossen.