Seminar Trusted Firmware-A – Platform-Portierung – Grundlagen

Die Schulung führt schrittweise von einer vorhandenen Referenzplattform zu einer eigenen TF-A-Plattformportierung. Im Zentrum stehen Verzeichnisstruktur, Build-Integration, frühe Initialisierung, Konsolentreiber, Speicherlayout, Image-Laden, Topologie, PSCI-Grundfunktionen und der erste reproduzierbare Boot. Jeder Portierungsschritt wird unmittelbar gebaut, ausgeführt und anhand definierter Prüfpunkte abgesichert.

Inhaltsübersicht

1. Portierungsauftrag und Referenzwahl
2. Plattformverzeichnis und Build-Anbindung
3. Frühe Initialisierung und Konsole
4. Speicherlayout und Imagebereiche
5. BL2-Plattformfunktionen und Image-Laden
6. BL31-Plattformsetup
7. Topologie und Sekundärkerne
8. PSCI-Grundintegration
9. Erster vollständiger Boot und Dokumentation

Lernziele

• Eine neue Plattformstruktur aus einer geeigneten Referenz ableiten und sauber in das Build-System integrieren.
• Frühe Initialisierung, Konsole, Speicherlayout und Image-Ladevorgang implementieren.
• Prozessortopologie und grundlegende PSCI-Plattformoperationen bereitstellen.
• BL2 und BL31 bis zur kontrollierten Übergabe an BL33 in Betrieb nehmen.
• Den Portierungsstand mit Logs, Tests und einer nachvollziehbaren Plattformdokumentation absichern.

Seminarinhalte

1. Portierungsauftrag und Referenzwahl

1. Schritt 1: SoC-, Board- und Produktanforderungen werden getrennt erfasst.
2. Schritt 2: Eine Referenzplattform wird nach Architekturähnlichkeit statt nach oberflächlicher Verwandtschaft ausgewählt.
3. Schritt 3: Ein minimaler erster Meilenstein mit klarer Bootgrenze wird festgelegt.

Praxis: Für eine Zielplattform wird ein Portierungssteckbrief mit Referenz und Meilensteinen erstellt.

2. Plattformverzeichnis und Build-Anbindung

1. Schritt 1: Plattform-, Board- und Treiberdateien werden in einer wartbaren Struktur angelegt.
2. Schritt 2: Makefile-Fragmente, Include-Pfade und Build-Optionen werden ergänzt.
3. Schritt 3: Ein leerer Plattformbuild wird reproduzierbar erzeugt und archiviert.

Praxis: Eine neue Plattformkennung wird angelegt und mit zwei Buildvarianten kompiliert.

3. Frühe Initialisierung und Konsole

1. Schritt 1: Resetzustand, Stack, Takt und minimale Pin-Konfiguration werden überprüft.
2. Schritt 2: Eine frühe serielle Konsole wird mit korrekter Basisadresse und Taktquelle initialisiert.
3. Schritt 3: Jede Bootstufe erhält eindeutige, zeitlich geordnete Prüfausgaben.

Praxis: Der erste BL2- oder BL31-Konsolentext wird auf der Zielplattform ausgegeben.

4. Speicherlayout und Imagebereiche

1. Schritt 1: ROM, SRAM, DRAM, Gerätebereiche und reservierte sichere Regionen werden inventarisiert.
2. Schritt 2: Linker-, Laufzeit- und Ladeadressen werden auf Überlappungen geprüft.
3. Schritt 3: Stack-, Heap- und temporäre Ladepuffer erhalten belastbare Größen und Grenzen.

Praxis: Ein Plattform-Speicherplan wird erstellt und durch Build- sowie Laufzeitprüfungen validiert.

5. BL2-Plattformfunktionen und Image-Laden

1. Schritt 1: Bootmedium und elementare I/O-Schicht werden initialisiert.
2. Schritt 2: Image-Policies ordnen Image-IDs den korrekten Quellen und Ladebereichen zu.
3. Schritt 3: Fehlende, zu große oder beschädigte Images erzeugen eindeutige Fehlerpfade.

Praxis: BL31 und BL33 werden aus einer vorbereiteten Bootquelle geladen und verifiziert übergeben.

6. BL31-Plattformsetup

1. Schritt 1: Frühe und architekturelle Initialisierung werden von der späten Plattforminitialisierung getrennt.
2. Schritt 2: GIC, Timer und notwendige Systemregister werden in der richtigen Reihenfolge eingerichtet.
3. Schritt 3: Entry-Point-Informationen für nachfolgende Images werden vollständig und konsistent erzeugt.

Praxis: BL31 erreicht den Runtime-Service-Setup und dokumentiert alle Übergabeparameter.

7. Topologie und Sekundärkerne

1. Schritt 1: Vorhandene Kerne und Cluster werden in einer Plattformtopologie beschrieben.
2. Schritt 2: Mailbox-, Holding-Pen- oder Power-Controller-Mechanismen werden für Sekundärkerne vorbereitet.
3. Schritt 3: Ungültige MPIDR-Werte und nicht vorhandene Kerne werden zuverlässig abgewiesen.

Praxis: Ein Sekundärkern wird gestartet und sein Eintritt in die vorgesehene Softwarestufe nachgewiesen.

8. PSCI-Grundintegration

1. Schritt 1: CPU_ON, CPU_OFF und SYSTEM_RESET werden mit Plattformoperationen verbunden.
2. Schritt 2: Zustandsübergänge und Rückgabewerte werden gegen die tatsächliche Hardware geprüft.
3. Schritt 3: Fehler in Power-Controller oder Mailbox werden in definierte PSCI-Ergebnisse übersetzt.

Praxis: Grundlegende PSCI-Aufrufe werden aus einer Test-Payload ausgelöst und protokolliert.

9. Erster vollständiger Boot und Dokumentation

1. Schritt 1: Alle Stufen werden mit einer festen Buildkonfiguration zu einem reproduzierbaren Image zusammengeführt.
2. Schritt 2: Cold Boot und mehrere Wiederholungen werden mit identischen Prüfpunkten ausgeführt.
3. Schritt 3: Offene Punkte, Plattformverträge und nächste Ausbaustufen werden versionsbezogen dokumentiert.

Praxis: Die neue Plattform startet bis BL33; Build, Logs und Prüfergebnisse werden als Baseline gesichert.

Zielgruppe

Firmware- und BSP-Entwickler, SoC-Integratoren sowie Embedded-Linux-Teams, die eine neue Arm-Plattform mit TF-A in Betrieb nehmen.

Voraussetzungen

Gute C- und Linux-Kenntnisse, AArch64-Grundlagen, Erfahrung mit Cross-Compilation und grundlegendes Verständnis von Bootloadern, Speicherplänen und Hardwaredatenblättern.

Praxisumgebung

Linux-Arbeitsplatz mit TF-A-Quellbaum, AArch64-Toolchain, Binutils, Debugger sowie QEMU, FVP oder einer vorbereiteten Entwicklungsplattform.