Seminar Libreboot CBFS und ROM-Anpassung

CBFS enthält zentrale Bestandteile eines Libreboot-ROMs. Änderungen an Payloads, Konfigurationen, Fonts, Keymaps oder Diagnosekomponenten dürfen nur mit klarer Platzplanung, Versionskontrolle und Integritätsprüfung erfolgen.

Inhaltsübersicht

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

Zielsetzung

• CBFS-Inhalte, Typen, Kompression und Speicherbelegung analysieren
• Dateien sicher hinzufügen, ersetzen und entfernen
• ROM-Varianten für Standard-, Diagnose- und Fallbackzwecke strukturieren
• Änderungen mit Prüfsummen, Starttests und Rückfallkopien absichern

Zielgruppe

Firmware-Administratoren, Build-Engineers, technische Integratoren und Entwickler mit Verantwortung für angepasste ROM-Images.

Voraussetzungen

Grundkenntnisse der Libreboot-Architektur und sichere Linux-Shell-Nutzung. Ein vorhandenes Test-ROM und Erfahrung mit Prüfsummen werden vorausgesetzt.

Seminarinhalte

Kapitel 1: Flash-Layout, Regionen und Schreibbereiche

Inhaltsübersicht: Layout analysieren; Schreibziel bestimmen; Grenzen prüfen

1. Schritt 1 – Layout analysieren: Flash-Größe, Descriptor, BIOS-Bereich, Management-Engine-Bereich, GbE-Daten, FMAP und CBFS werden je nach Plattform eingeordnet.
2. Schritt 2 – Schreibziel bestimmen: Vollständiges ROM, definierte Region oder einzelner Baustein werden als Schreibziel festgelegt; unklare Mischformen werden vermieden.
3. Schritt 3 – Grenzen prüfen: Regionale Sperren, Schreibschutz, doppelte Flash-Bausteine und gerätespezifische Reihenfolgen werden vor dem Flashen verifiziert.

Kapitel 2: 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 3: 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 4: Board-, Payload- und Konfigurationsvarianten

Inhaltsübersicht: Varianten definieren; Konfiguration trennen; Freigabe begrenzen

1. Schritt 1 – Varianten definieren: Standard-, Diagnose-, Fallback- und Spezial-ROMs werden mit eindeutigen Namen und festgelegtem Einsatzzweck beschrieben.
2. Schritt 2 – Konfiguration trennen: Gerätespezifische Daten, Payload-Konfiguration und allgemeine Projektkonfiguration werden getrennt verwaltet.
3. Schritt 3 – Freigabe begrenzen: Jede Variante erhält eine explizite Liste zulässiger Boards, Flashgrößen und Teststände.

Kapitel 5: Fallback-Payloads und Diagnosepfade

Inhaltsübersicht: Fehlerszenarien definieren; Fallback integrieren; Bedienung dokumentieren

1. Schritt 1 – Fehlerszenarien definieren: Defekte Konfiguration, nicht auffindbares Betriebssystem, fehlerhaftes Medium und inkompatible Erweiterung werden als Testszenarien angelegt.
2. Schritt 2 – Fallback integrieren: Alternative Payload oder Diagnosekonfiguration wird platzsparend und eindeutig erreichbar im ROM vorgesehen.
3. Schritt 3 – Bedienung dokumentieren: Auslöser, Tastenkombinationen, Konsolenzugriff und Rückkehr zum Normalbetrieb werden in einer kurzen Notfallanweisung festgehalten.

Kapitel 6: 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 7: 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

An einer ROM-Arbeitskopie werden Konfigurations- und Fallbackdateien kontrolliert verändert. Speicherbelegung, CBFS-Liste, Hashwerte und Bootfähigkeit werden vor und nach jedem Schritt verglichen.

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.