Seminar MCUboot Plattformportierung auf neue MCUs und RTOS

Das viertägige Fachseminar vermittelt die vollständige Portierung von MCUboot auf eine neue Hardware- oder Betriebssystemplattform. Die technischen Zusammenhänge werden nicht nur beschrieben, sondern an einem durchgängigen Beispielsystem bis zu prüfbaren Boot- und Updatezuständen nachvollzogen.

Die Bearbeitung umfasst die Themenfelder Portierungsarchitektur und minimaler Bootpfad, Flash-API, Partitionen und Updatezustand, Kryptografie, Validierung und Übergabe, Updateverfahren, Recovery und Abnahme. Jeder Themenblock beginnt mit einem eigenen Inhaltsverzeichnis, wird anschließend in klaren Arbeitsschritten umgesetzt und endet mit einer praktischen Prüfung einschließlich typischer Fehler- und Grenzfälle.

Inhaltsverzeichnis

• Zielgruppe
• Voraussetzungen
• Lernziele
• Seminarinhalte
• Tag 1: Portierungsarchitektur und minimaler Bootpfad
• Tag 2: Flash-API, Partitionen und Updatezustand
• Tag 3: Kryptografie, Validierung und Übergabe
• Tag 4: Updateverfahren, Recovery und Abnahme
• Praxisanteil
• Arbeitsweise

Zielgruppe

Senior Embedded-Entwickler, BSP-Teams, SoC-Hersteller, RTOS-Integratoren und Security-Architekten.

Voraussetzungen

Sehr gute C-Kenntnisse, Erfahrung mit Startup-Code, Linkern, Flash-Treibern, Debuggern und Build-Systemen.

Lernziele

• den minimalen Portierungsumfang und die Plattformgrenzen von MCUboot bestimmen
• Flash-Area-, Startup-, Logging-, Watchdog- und Zeitquellen sauber implementieren
• Kryptografie, Speicherlayout und Ausführungsübergabe auf der Zielhardware integrieren
• die Portierung mit Simulator-, Hardware- und Störtests produktionsfähig absichern

Seminarinhalte

Die Inhalte werden in aufeinander aufbauenden Kapiteln bearbeitet. Jedes Tageskapitel enthält ein eigenes Inhaltsverzeichnis und einen schrittweisen Praxisablauf.

Tag 1: Portierungsarchitektur und minimaler Bootpfad

Inhaltsverzeichnis des Tageskapitels

• Trennung von bootutil-Kern, Bootanwendung und Plattformabstraktion
• Startup-Code, Vektortabelle, Stack, Takt und minimale Hardwareinitialisierung
• Buildsystem, Toolchain, Linkerskript und Binärformat
• Bootloader-Region, Anwendungsslot und grundlegende Sprunglogik
• frühe Diagnose über Debugger und minimales Logging

Schrittweise Bearbeitung

1. Schritt 1: „Trennung von bootutil-Kern, Bootanwendung und Plattformabstraktion“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Startup-Code, Vektortabelle, Stack, Takt und minimale Hardwareinitialisierung“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Buildsystem, Toolchain, Linkerskript und Binärformat“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Bootloader-Region, Anwendungsslot und grundlegende Sprunglogik“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „frühe Diagnose über Debugger und minimales Logging“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein leerer Plattformrahmen wird bis zum sicheren Start einer fest eingebrachten Anwendung aufgebaut und im Debugger verfolgt.

Tag 2: Flash-API, Partitionen und Updatezustand

Inhaltsverzeichnis des Tageskapitels

• Flash-Area-Öffnen, Lesen, Schreiben, Löschen und Sektorabfrage
• Write-Alignment, Erase-Geometrie und Fehlerweitergabe
• Zuordnung von Image-Kennungen und Slots zu physischen Speichern
• Trailer, Swap-Status und Schutz angrenzender Datenbereiche
• Tests mit internen, externen und unterschiedlich segmentierten Flash-Bausteinen

Schrittweise Bearbeitung

1. Schritt 1: „Flash-Area-Öffnen, Lesen, Schreiben, Löschen und Sektorabfrage“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Write-Alignment, Erase-Geometrie und Fehlerweitergabe“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Zuordnung von Image-Kennungen und Slots zu physischen Speichern“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Trailer, Swap-Status und Schutz angrenzender Datenbereiche“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Tests mit internen, externen und unterschiedlich segmentierten Flash-Bausteinen“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein Flash-Backend wird implementiert und mit Grenz-, Alignment-, Erase- und Fehler-Injektionstests gegen ein definiertes Vertragsmodell geprüft.

Tag 3: Kryptografie, Validierung und Übergabe

Inhaltsverzeichnis des Tageskapitels

• Auswahl und Integration des kryptografischen Backends
• öffentlicher Schlüssel, Hash, Signatur und optional verschlüsselte Images
• Image-Header, TLV-Parsing und sichere Fehlerpfade
• Cache, MPU, TrustZone und Vorbereitung des Anwendungskontexts
• Sprungadresse, Vektortabelle und Übergabe von Bootinformationen

Schrittweise Bearbeitung

1. Schritt 1: „Auswahl und Integration des kryptografischen Backends“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „öffentlicher Schlüssel, Hash, Signatur und optional verschlüsselte Images“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Image-Header, TLV-Parsing und sichere Fehlerpfade“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Cache, MPU, TrustZone und Vorbereitung des Anwendungskontexts“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Sprungadresse, Vektortabelle und Übergabe von Bootinformationen“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein signiertes Image wird auf der neuen Plattform validiert; danach werden mehrere manipulierte Images und ein fehlerhafter Anwendungseinstieg abgefangen.

Tag 4: Updateverfahren, Recovery und Abnahme

Inhaltsverzeichnis des Tageskapitels

• Auswahl von Swap, Overwrite, Direct-XIP oder RAM-Load
• Unterbrechungssicherheit, Watchdog und lange Flash-Operationen
• Serial Recovery oder plattformspezifischer Notfallkanal
• Simulator-, Unit-, Integrations- und Hardware-Störtests
• Portierungsdokumentation, Sicherheitsannahmen und Produktionsfreigabe

Schrittweise Bearbeitung

1. Schritt 1: „Auswahl von Swap, Overwrite, Direct-XIP oder RAM-Load“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Unterbrechungssicherheit, Watchdog und lange Flash-Operationen“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Serial Recovery oder plattformspezifischer Notfallkanal“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Simulator-, Unit-, Integrations- und Hardware-Störtests“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Portierungsdokumentation, Sicherheitsannahmen und Produktionsfreigabe“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Die Portierung durchläuft einen vollständigen Update-, Stromausfall-, Revert- und Recovery-Test; die Ergebnisse werden in einer Abnahmematrix festgehalten.

Praxisanteil

Der praktische Anteil umfasst ein leerer plattformrahmen wird bis zum sicheren start einer fest eingebrachten anwendung aufgebaut und im debugger verfolgt; ein flash-backend wird implementiert und mit grenz-, alignment-, erase- und fehler-injektionstests gegen ein definiertes vertragsmodell geprüft; ein signiertes image wird auf der neuen plattform validiert; danach werden mehrere manipulierte images und ein fehlerhafter anwendungseinstieg abgefangen; die portierung durchläuft einen vollständigen update-, stromausfall-, revert- und recovery-test; die ergebnisse werden in einer abnahmematrix festgehalten. Die Übungen verwenden signierte Test-Images, kontrollierte Flashzustände und nachvollziehbare Prüfergebnisse.

Arbeitsweise

Kurzvorträge ordnen die Konzepte ein. Demonstrationen zeigen die Wirkung der Konfiguration auf Image, Flash und Bootentscheidung. Die anschließenden Übungen werden schrittweise durchgeführt, durch Negativtests ergänzt und mit einer technischen Prüfliste dokumentiert.