Seminar MCUboot Intensivseminar – Integration, Portierung und Delivery

Das fünftägige Fachseminar vermittelt die durchgängige Integration von MCUboot in Buildsysteme, RTOS-Plattformen, Update-Infrastruktur und automatisierte Releaseprozesse. 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 Zephyr, Kconfig, CMake und Sysbuild, Firmware-Management und OTA-Agenten, Portierungskern und Flash-Backend, Weitere RTOS, Espressif und Trusted Firmware-M, CI/CD, Release 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: Zephyr, Kconfig, CMake und Sysbuild
• Tag 2: Firmware-Management und OTA-Agenten
• Tag 3: Portierungskern und Flash-Backend
• Tag 4: Weitere RTOS, Espressif und Trusted Firmware-M
• Tag 5: CI/CD, Release und Abnahme
• Praxisanteil
• Arbeitsweise

Zielgruppe

Senior Embedded-Entwickler, Build- und DevOps-Ingenieure, BSP-Teams, IoT-Architekten und Integratoren.

Voraussetzungen

Sehr gute C-Kenntnisse, praktische Buildsystem-Erfahrung und MCUboot-Grundlagen.

Lernziele

• MCUboot mit Zephyr, Sysbuild und alternativen RTOS-Strukturen integrieren
• Flash-, Startup-, Kryptografie- und Sprungadapter für neue Plattformen entwickeln
• MCUmgr-, SMP- und eigene OTA-Agenten in den Updatezyklus einbinden
• Build, Signierung, Test und Freigabe als reproduzierbare Lieferkette automatisieren

Seminarinhalte

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

Tag 1: Zephyr, Kconfig, CMake und Sysbuild

Inhaltsverzeichnis des Tageskapitels

• Konfigurationsschichten für Bootloader und Anwendung
• Devicetree-Partitionen, Linkerregionen und Flash-Areas
• Sysbuild-Domänen und domänenspezifische Einstellungen
• automatische Signierung und erzeugte Upgrade-Artefakte
• gemeinsames Flashen, Diagnose und reproduzierbarer Build

Schrittweise Bearbeitung

1. Schritt 1: „Konfigurationsschichten für Bootloader und Anwendung“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Devicetree-Partitionen, Linkerregionen und Flash-Areas“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Sysbuild-Domänen und domänenspezifische Einstellungen“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „automatische Signierung und erzeugte Upgrade-Artefakte“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „gemeinsames Flashen, Diagnose und reproduzierbarer Build“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein vollständiges Zephyr-Sysbuild-Projekt wird erstellt und mit automatisch signiertem Update-Image auf Hardware ausgeführt.

Tag 2: Firmware-Management und OTA-Agenten

Inhaltsverzeichnis des Tageskapitels

• SMP-Server, Image-Management und Transportauswahl
• Upload, Slot-Informationen, Test, Reset und Bestätigung
• protokollunabhängiger OTA-Zustandsautomat
• Downloadfortsetzung, Telemetrie und gestaffelter Rollout
• Recovery bei Netzwerk-, Flash- und Versionsfehlern

Schrittweise Bearbeitung

1. Schritt 1: „SMP-Server, Image-Management und Transportauswahl“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Upload, Slot-Informationen, Test, Reset und Bestätigung“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „protokollunabhängiger OTA-Zustandsautomat“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Downloadfortsetzung, Telemetrie und gestaffelter Rollout“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Recovery bei Netzwerk-, Flash- und Versionsfehlern“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein Image wird über SMP sowie über einen abstrahierten Update-Agenten übertragen; beide Wege münden in denselben geprüften MCUboot-Zustandszyklus.

Tag 3: Portierungskern und Flash-Backend

Inhaltsverzeichnis des Tageskapitels

• bootutil-Kern, Plattformschicht und minimale Bootanwendung
• Startup, Linker, Takt, Logging und Watchdog
• Flash-Area-API, Sektorgeometrie und externe Speicher
• Image-Slots, Trailer und Updateverfahren
• Unit- und Hardwaretests für Plattformadapter

Schrittweise Bearbeitung

1. Schritt 1: „bootutil-Kern, Plattformschicht und minimale Bootanwendung“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Startup, Linker, Takt, Logging und Watchdog“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Flash-Area-API, Sektorgeometrie und externe Speicher“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Image-Slots, Trailer und Updateverfahren“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Unit- und Hardwaretests für Plattformadapter“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein neues Flash-Backend wird implementiert und gegen Grenz-, Alignment-, Fehler- und Stromausfallszenarien geprüft.

Tag 4: Weitere RTOS, Espressif und Trusted Firmware-M

Inhaltsverzeichnis des Tageskapitels

• Build- und Laufzeitintegration in Mynewt, NuttX, Mbed oder Eigenentwicklung
• Espressif-spezifische Boot- und Flasharchitektur
• MCUboot als BL2 in Trusted Firmware-M
• Secure und Non-secure Images, Multi-Core und Abhängigkeiten
• Wartungsstrategie für plattformspezifische Anpassungen

Schrittweise Bearbeitung

1. Schritt 1: „Build- und Laufzeitintegration in Mynewt, NuttX, Mbed oder Eigenentwicklung“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Espressif-spezifische Boot- und Flasharchitektur“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „MCUboot als BL2 in Trusted Firmware-M“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Secure und Non-secure Images, Multi-Core und Abhängigkeiten“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Wartungsstrategie für plattformspezifische Anpassungen“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Drei Integrationsprofile werden verglichen; eines davon wird bis zum signierten Update praktisch umgesetzt und dokumentiert.

Tag 5: CI/CD, Release und Abnahme

Inhaltsverzeichnis des Tageskapitels

• Pipeline für Build, Signierung, Prüfung, Verpackung und Archivierung
• isolierte Schlüsselverwendung und Promotion unveränderter Artefakte
• Simulator-, Hardware- und Revert-Tests als Freigabegates
• Version, Security Counter und Release-Manifest
• End-to-End-Abnahme von Commit bis bestätigter Firmware

Schrittweise Bearbeitung

1. Schritt 1: „Pipeline für Build, Signierung, Prüfung, Verpackung und Archivierung“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „isolierte Schlüsselverwendung und Promotion unveränderter Artefakte“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Simulator-, Hardware- und Revert-Tests als Freigabegates“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Version, Security Counter und Release-Manifest“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „End-to-End-Abnahme von Commit bis bestätigter Firmware“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Eine Pipeline erzeugt, prüft und promoted ein Release; fehlerhafte Signatur, Slot-Größe und fehlende Bestätigung sperren die Freigabe automatisch.

Praxisanteil

Der praktische Anteil umfasst ein vollständiges zephyr-sysbuild-projekt wird erstellt und mit automatisch signiertem update-image auf hardware ausgeführt; ein image wird über smp sowie über einen abstrahierten update-agenten übertragen; beide wege münden in denselben geprüften mcuboot-zustandszyklus; ein neues flash-backend wird implementiert und gegen grenz-, alignment-, fehler- und stromausfallszenarien geprüft; drei integrationsprofile werden verglichen; eines davon wird bis zum signierten update praktisch umgesetzt und dokumentiert; eine pipeline erzeugt, prüft und promoted ein release; fehlerhafte signatur, slot-größe und fehlende bestätigung sperren die freigabe automatisch. 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.