Seminar Libreboot Portierung auf neue Mainboards

Eine neue Boardportierung verbindet Hardwareanalyse, coreboot-Boardcode, frühe Initialisierung, Speichertraining, Gerätebeschreibung, ACPI, Payloadintegration und umfangreiche Tests. Das Seminar vermittelt einen realistischen, reviewfähigen Entwicklungsweg mit klaren Abbruchkriterien.

Inhaltsübersicht

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

Zielsetzung

• Portierungsfähigkeit anhand von Plattform, Dokumentation und Debugzugang bewerten
• Boardstruktur, Kconfig, Gerätebaum und frühe Initialisierung aufbauen
• Speicher, Geräte, ACPI und Betriebssystemintegration systematisch testen
• Änderungen als prüfbare Patches mit Nachweisen und Pflegeplan vorbereiten

Zielgruppe

Erfahrene Firmware- und Embedded-Entwickler, Coreboot-Integratoren, Hardwareentwickler und technische Maintainer.

Voraussetzungen

Gute C-, Git-, Linux- und Hardwarekenntnisse, Erfahrung mit serieller Diagnose sowie Grundverständnis von coreboot. Ein geeignetes Referenzboard, vollständiger Recovery-Zugang und technische Unterlagen sind erforderlich.

Seminarinhalte

Kapitel 1: 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 2: Hardwareinventar und eindeutige Board-Identifikation

Inhaltsübersicht: Systemdaten aufnehmen; Varianten unterscheiden; Nachweis sichern

1. Schritt 1 – Systemdaten aufnehmen: Hersteller, Modell, Board-Revision, Prozessor, Chipsatz, Flash-Baustein, Display, Netzwerkadapter und vorhandene Firmwareversion werden inventarisiert.
2. Schritt 2 – Varianten unterscheiden: Ähnlich bezeichnete Modelle werden über Board-ID, Revision, Bestückung und Flash-Größe voneinander abgegrenzt.
3. Schritt 3 – Nachweis sichern: Fotos, Etiketten, Auslesedaten und Prüfergebnisse werden in einem Geräteprotokoll zusammengeführt.

Kapitel 3: 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 4: 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 5: 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 6: 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 7: 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 8: Diagnoseprotokolle und systematische Ursachenanalyse

Inhaltsübersicht: Daten erfassen; Vergleich bilden; Ursache belegen

1. Schritt 1 – Daten erfassen: Serielle Ausgabe, POST-Verhalten, Payload-Meldungen, Kernelprotokolle, PCI- und USB-Inventar sowie Strommessungen werden gesammelt.
2. Schritt 2 – Vergleich bilden: Fehlergerät, Referenzgerät, altes ROM und neues ROM werden mit jeweils nur einer geänderten Variable verglichen.
3. Schritt 3 – Ursache belegen: Hypothese, Test, Ergebnis und verbleibende Unsicherheit werden so dokumentiert, dass ein zweites Team die Analyse nachvollziehen kann.

Kapitel 9: 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 10: 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 11: 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 12: Regressionstests und Fehlerlokalisierung

Inhaltsübersicht: Referenzvergleich aufbauen; Änderung eingrenzen; Freigabe blockieren

1. Schritt 1 – Referenzvergleich aufbauen: Letzter freigegebener Stand und Kandidat werden auf identischer Hardware mit derselben Testmatrix verglichen.
2. Schritt 2 – Änderung eingrenzen: Quellstand, Konfiguration, Payload und Hardware werden einzeln variiert, um den ersten fehlerhaften Stand einzugrenzen.
3. Schritt 3 – Freigabe blockieren: Kritische oder ungeklärte Regressionen verhindern den Rollout; Ausnahmen benötigen dokumentierte Risikofreigabe.

Kapitel 13: 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.

Praxisübungen

An einem vorbereiteten Board oder Portierungsstub werden Referenzplattform, Boardstruktur und frühe Debugausgabe aufgebaut. Eine begrenzte Geräte- oder Konfigurationsänderung wird getestet, regressionsgeprüft und als reviewfähige Patchserie dokumentiert.

Methodik

Technische Analyse, Quellcodearbeit, serielle Diagnose, Buildzyklen und Hardwaretests wechseln sich ab. Der Schwerpunkt liegt auf kleinen reviewfähigen Änderungen, reproduzierbaren Logs und einem jederzeit verfügbaren externen Recovery-Zugang.