Seminar Trusted Firmware-A – PSCI und Power Management

Die Schulung behandelt PSCI als standardisierte Schnittstelle zwischen Betriebssystem, EL3-Laufzeit und Plattform-Power-Controller. Von CPU_ON und CPU_OFF über CPU_SUSPEND bis zu System Suspend, Reset und Off werden Zustandsmodelle, Affinitätsebenen, Race Conditions und Diagnosewege praktisch erarbeitet.

Inhaltsübersicht

1. PSCI-Rollen und Aufrufpfad
2. Power-Domänen und Zustandsmodell
3. CPU_ON und sekundärer Einstieg
4. CPU_OFF und CPU_SUSPEND
5. System Suspend, Off und Reset
6. Nebenläufigkeit und Synchronisation
7. Validierung und Fehlersuche

Lernziele

• PSCI-Aufrufmodell, Versionen, Rückgabewerte und Zustandsbegriffe sicher anwenden.
• Plattform-Power-Domänen und Affinitätsebenen korrekt modellieren.
• CPU- und Systemzustände einschließlich Suspend und Resume implementieren.
• Nebenläufigkeit, Cachekohärenz und Warm-Boot-Einstieg kontrollieren.
• Fehlerhafte Power-Transitions mit Logs und Test-Payloads eingrenzen.

Seminarinhalte

1. PSCI-Rollen und Aufrufpfad

1. Schritt 1: Aufrufer, SMC-Transport, EL3-Dispatcher und Plattformoperationen werden getrennt betrachtet.
2. Schritt 2: Funktions-IDs, Argumente und Rückgabewerte werden auf 32- und 64-Bit-Aufrufe abgebildet.
3. Schritt 3: Unsupported-, Invalid- und Denied-Fälle werden mit nachvollziehbarer Ursache unterschieden.

Praxis: PSCI-Aufrufe werden aus einer Test-Payload erzeugt und bis zur Plattformoperation verfolgt.

2. Power-Domänen und Zustandsmodell

1. Schritt 1: Core-, Cluster- und Systemebenen werden aus der realen Hardware abgeleitet.
2. Schritt 2: Local State und zusammengesetzter Power State werden konsistent codiert.
3. Schritt 3: Nicht unterstützte Kombinationen werden früh und deterministisch verworfen.

Praxis: Ein hierarchischer Power-State-Baum wird für eine Mehrclusterplattform modelliert.

3. CPU_ON und sekundärer Einstieg

1. Schritt 1: Zielkern, Einstiegspunkt und Kontext-ID werden validiert.
2. Schritt 2: Power-Controller, Mailbox und Cachewartung werden in sicherer Reihenfolge angesteuert.
3. Schritt 3: Der Sekundärkern erreicht über den Warm-Boot-Pfad den übergebenen Entry Point.

Praxis: Mehrere Kerne werden parallel gestartet und auf doppelte oder verlorene Übergänge geprüft.

4. CPU_OFF und CPU_SUSPEND

1. Schritt 1: Off- und Retention-Zustände werden nach Hardwarefähigkeit unterschieden.
2. Schritt 2: Kontext, GIC-Zustand und plattformspezifische Register werden passend gesichert.
3. Schritt 3: Rückkehrpfade vermeiden eine erneute Cold-Boot-Initialisierung.

Praxis: Ein Kern durchläuft Off, Retention und Resume mit definierten Prüfpunkten.

5. System Suspend, Off und Reset

1. Schritt 1: Systemweite Vorbedingungen und Koordination aller Kerne werden festgelegt.
2. Schritt 2: Wakeup-Quellen, DRAM-Erhalt und Resume-Vektor werden validiert.
3. Schritt 3: Reset und Off erhalten getrennte Hardware- und Fehlerpfade.

Praxis: System Suspend und zwei Resetursachen werden reproduzierbar getestet.

6. Nebenläufigkeit und Synchronisation

1. Schritt 1: Locks, Bakery-Mechanismen und atomare Zustandswechsel werden zielgerichtet eingesetzt.
2. Schritt 2: Race Conditions zwischen Kernstart, Suspend und Interrupt werden provoziert.
3. Schritt 3: Barrieren und Cachewartung werden anhand der tatsächlichen Speicherfreigabe platziert.

Praxis: Ein konkurrierender CPU_ON/SUSPEND-Test wird stabilisiert.

7. Validierung und Fehlersuche

1. Schritt 1: PSCI-Statistiken, Tracepunkte und Plattformlogs werden korreliert.
2. Schritt 2: Timeout, falscher MPIDR und Power-Controller-Fehler werden einzeln injiziert.
3. Schritt 3: Testergebnisse werden gegen erwartete PSCI-Rückgabewerte und Hardwarezustände geprüft.

Praxis: Eine Power-Management-Testmatrix wird ausgeführt und dokumentiert.

Zielgruppe

Firmware-Entwickler, BSP- und Kernel-Integratoren, SoC-Teams sowie Entwickler von Power-Management- und Suspend-Funktionen.

Voraussetzungen

TF-A-Architekturgrundlagen, AArch64-Ausführungsmodell, C-Kenntnisse und Verständnis von Multicore-Systemen, Interrupts und Cachekohärenz.

Praxisumgebung

Linux-Arbeitsplatz mit TF-A, Test-Payload oder Betriebssystem, AArch64-Toolchain sowie QEMU, FVP oder Hardware mit zugänglichem Power-Controller.