Seminar Libreboot Buildsystem lbmk und reproduzierbare ROM-Erstellung

Eigene ROMs müssen aus einem definierten Quellstand, nachvollziehbaren Patches und kontrollierten Buildparametern entstehen. Das Seminar führt von der sauberen lbmk-Arbeitsumgebung bis zu prüfbaren Artefakten und einem wiederholbaren Zweitbuild.

Inhaltsübersicht

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

Zielsetzung

• lbmk-Struktur, Befehle, Targets und Abhängigkeiten sicher einordnen
• Quellen, Patches, Boardkonfigurationen und Payloadvarianten kontrolliert verwalten
• ROM-Artefakte technisch prüfen und eindeutig Zielboards zuordnen
• Reproduzierbarkeit, Prüfsummen und interne Freigaben nachweisen

Zielgruppe

Linux-Administratoren, Firmware-Entwickler, Build-Engineers, technische Consultants und erfahrene Libreboot-Betreiber.

Voraussetzungen

Sichere Linux-Shell-Kenntnisse, Git-Grundlagen und Verständnis der Bootkette. Für Laborübungen werden ausreichend Speicherplatz und Buildressourcen benötigt.

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-Struktur und sichere Inhaltsanalyse

Inhaltsübersicht: Inhalt auflisten; Platzbedarf bewerten; Referenz sichern

1. Schritt 1 – Inhalt auflisten: Payloads, Konfigurationen, Fonts, Keymaps, Option-ROMs, Gerätebäume und weitere Dateien werden mit Größe und Position erfasst.
2. Schritt 2 – Platzbedarf bewerten: Freier Speicher, Kompression, Alignment und notwendige Reserven werden vor jeder Änderung geprüft.
3. Schritt 3 – Referenz sichern: Die unveränderte CBFS-Liste und ein Hash des Ausgangs-ROMs werden als Vergleichsbasis abgelegt.

Kapitel 6: 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 7: Releasepaket und interne Freigabe

Inhaltsübersicht: Artefakte erzeugen; Vier-Augen-Prüfung durchführen; Paket versiegeln

1. Schritt 1 – Artefakte erzeugen: ROMs, Prüfsummen, Buildprotokolle, Konfigurationsstände und Recovery-Dateien werden als geschlossenes Paket erstellt.
2. Schritt 2 – Vier-Augen-Prüfung durchführen: Boardzuordnung, Dateigröße, Payload, Hashwert, Vendor-Dateien und Freigabestatus werden unabhängig kontrolliert.
3. Schritt 3 – Paket versiegeln: Freigegebene Dateien werden schreibgeschützt abgelegt; nachträgliche Änderungen erzeugen zwingend eine neue Version.

Kapitel 8: Testmatrix für Firmware und Zielhardware

Inhaltsübersicht: Prüfbereiche definieren; Varianten abdecken; Erwartungen festlegen

1. Schritt 1 – Prüfbereiche definieren: Kaltstart, Warmstart, Payload, Datenträger, USB, Netzwerk, Grafik, Audio, Suspend, Akku und Erweiterungskarten werden erfasst.
2. Schritt 2 – Varianten abdecken: Boardrevision, RAM-Bestückung, Display, Massenspeicher, Payload und Betriebssystem werden nach Risiko kombiniert.
3. Schritt 3 – Erwartungen festlegen: Jeder Test erhält Vorbedingung, Schrittfolge, Sollresultat, Beleg und Schweregrad eines Fehlers.

Kapitel 9: Testbelege, Defect-Management und Abnahme

Inhaltsübersicht: Belege sammeln; Fehler bearbeiten; Abnahme durchführen

1. Schritt 1 – Belege sammeln: Logs, Fotos, Messwerte, Hashwerte und Testausgaben werden direkt dem jeweiligen Prüffall zugeordnet.
2. Schritt 2 – Fehler bearbeiten: Reproduktionsweg, Auswirkung, Schweregrad, Workaround, Verantwortlichkeit und Zielversion werden gepflegt.
3. Schritt 3 – Abnahme durchführen: Vollständigkeit, offene Risiken, Recovery-Nachweis und Freigabesignatur werden vor Produktivnutzung kontrolliert.

Praxisübungen

Ein Boardtarget wird aus einem festgehaltenen Quellstand gebaut, analysiert und in einer zweiten sauberen Umgebung erneut erzeugt. Abweichungen werden lokalisiert und als Freigabenachweis dokumentiert.

Methodik

Fachliche Kurzvorträge, Live-Demonstrationen, geführte Laborphasen, Checklisten und dokumentierte Kontrollpunkte wechseln sich ab. Schreiboperationen am Firmware-Flash erfolgen ausschließlich an freigegebenen Übungsgeräten mit vorhandenem Original-ROM und vorbereitetem Recovery-Weg.