Seminar Trusted Firmware-A – Build-System, Toolchains und FIP-Images

Das Seminar behandelt den reproduzierbaren Aufbau von Trusted Firmware-A für unterschiedliche Plattformen und Konfigurationen. Die Build-Logik wird nicht nur bedient, sondern bis zu ihren Abhängigkeiten, Artefakten und Sicherheitsoptionen nachvollzogen. Ein besonderer Schwerpunkt liegt auf Firmware Image Packages, unterstützenden Werkzeugen und der kontrollierten Übergabe von Build-Ergebnissen an Integration, Test und Freigabe.

Inhaltsübersicht

1. Build-Voraussetzungen und Toolchain-Auswahl
2. Build-Struktur und Make-Ziele
3. Plattform- und Feature-Optionen
4. Firmware Image Package verstehen
5. FIP erstellen und pflegen
6. Zertifikate, Schlüssel und optionale Verschlüsselung
7. Reproduzierbarkeit und Fehlerbehebung

Lernziele

• Eine belastbare TF-A-Build-Umgebung für AArch64 und bei Bedarf AArch32 einrichten.
• Plattform-, Architektur-, Debug- und Sicherheitsoptionen nachvollziehbar kombinieren.
• FIP-Dateien erstellen, untersuchen, aktualisieren und auf Vollständigkeit prüfen.
• Werkzeuge wie fiptool und cert_create in einen reproduzierbaren Ablauf integrieren.
• Build-Fehler anhand von Abhängigkeiten, Map-Dateien und Kommandozeilenparametern systematisch beheben.

Seminarinhalte

1. Build-Voraussetzungen und Toolchain-Auswahl

1. Schritt 1: Host-Werkzeuge, Cross-Compiler, Binutils, Python-Werkzeuge und Device-Tree-Compiler werden geprüft.
2. Schritt 2: GNU-, LLVM- und Arm-Compiler-Konfigurationen werden nach Zielarchitektur und Supportbedarf unterschieden.
3. Schritt 3: Umgebungsvariablen, Suchpfade und Versionsprüfungen werden reproduzierbar dokumentiert.

Praxis: Eine frische Build-Umgebung wird mit einem automatisierten Vorabtest aufgesetzt.

2. Build-Struktur und Make-Ziele

1. Schritt 1: Top-Level-Makefiles, Plattform-Makefiles und gemeinsam eingebundene Fragmente werden gelesen.
2. Schritt 2: Ziele wie all, bl1, bl2, bl31, fip und unterstützende Werkzeuge werden voneinander abgegrenzt.
3. Schritt 3: Release-, Debug- und Clean-Builds werden mit eindeutigen Ausgabeordnern ausgeführt.

Praxis: Ein Build wird von der Kommandozeile bis zu den erzeugten ELF- und Binärdateien vollständig protokolliert.

3. Plattform- und Feature-Optionen

1. Schritt 1: PLAT, ARCH, CROSS_COMPILE, DEBUG und LOG_LEVEL werden als Grundkonfiguration gesetzt.
2. Schritt 2: Sicherheits-, Architektur- und Laufzeitoptionen werden nach Abhängigkeiten gruppiert.
3. Schritt 3: Änderungen an Optionen werden mit Clean-Build, Konfigurationsnachweis und Artefaktvergleich abgesichert.

Praxis: Eine Build-Matrix aus Plattform, Debug-Modus und Sicherheitsprofil wird automatisiert erzeugt.

4. Firmware Image Package verstehen

1. Schritt 1: Aufbau, Inhaltsverzeichnis und UUID-basierte Einträge eines FIP werden analysiert.
2. Schritt 2: BL-Images, Konfigurationsdateien, Zertifikate und optionale Nutzlasten werden korrekt zugeordnet.
3. Schritt 3: Fehlende, doppelte oder veraltete Einträge werden vor der Integration erkannt.

Praxis: Mehrere FIP-Dateien werden extrahiert, verglichen und auf definierte Freigabekriterien geprüft.

5. FIP erstellen und pflegen

1. Schritt 1: Ein FIP wird aus TF-A, BL32, BL33 und Konfigurationsartefakten erzeugt.
2. Schritt 2: Einzelne Komponenten werden mit fiptool aktualisiert, entfernt und erneut eingespielt.
3. Schritt 3: Hashwerte, Größen, Build-Informationen und Freigabestatus werden in einem Manifest festgehalten.

Praxis: Eine Nutzlast wird kontrolliert ausgetauscht, ohne die übrigen Paketbestandteile zu verändern.

6. Zertifikate, Schlüssel und optionale Verschlüsselung

1. Schritt 1: cert_create und die Build-Integration für Zertifikate werden eingeordnet.
2. Schritt 2: Entwicklungs- und Produktionsschlüssel werden organisatorisch und technisch getrennt.
3. Schritt 3: Verschlüsselungsoptionen werden nach Schlüsselbereitstellung, Nonce-Verwendung und Entschlüsselungspfad geprüft.

Praxis: Ein Testpaket mit signierten Komponenten wird erstellt und auf nachvollziehbare Schlüsselverwendung kontrolliert.

7. Reproduzierbarkeit und Fehlerbehebung

1. Schritt 1: Build-Ausgaben werden bereinigt, versioniert und mit festen Eingaben erneut erzeugt.
2. Schritt 2: Linkerfehler, fehlende Symbole, falsche Pfade und inkonsistente Optionen werden anhand einer Prüfreihenfolge behoben.
3. Schritt 3: Artefakte werden für CI, Integration und spätere Rekonstruktion eindeutig archiviert.

Praxis: Ein absichtlich inkonsistenter Build wird analysiert und in einen reproduzierbaren Zustand überführt.

Zielgruppe

Firmware-Entwickler, Build Engineers, BSP-Teams, DevOps-Engineers für Embedded-Systeme und technische Integratoren.

Voraussetzungen

Linux- und Shell-Kenntnisse, Grundkenntnisse in C, Make und Cross-Compilation; TF-A-Architekturwissen ist hilfreich.

Praxisumgebung

Linux-Arbeitsplatz mit GNU Make, AArch64-Toolchain, Git, Python, OpenSSL, Device-Tree-Compiler und den TF-A-Werkzeugen.