Seminar MCUboot Build- und Laufzeitintegration für weitere RTOS

Das dreitägige Fachseminar vermittelt die Einbindung von MCUboot in Mynewt-, NuttX-, Mbed- oder proprietäre RTOS-Umgebungen jenseits einer Zephyr-Standardintegration. 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 Portvergleich und Buildintegration, Flash, Plattformdienste und Anwendungssprung, Update-Agent, Bestätigung 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: Portvergleich und Buildintegration
• Tag 2: Flash, Plattformdienste und Anwendungssprung
• Tag 3: Update-Agent, Bestätigung und Abnahme
• Praxisanteil
• Arbeitsweise

Zielgruppe

RTOS-Integratoren, BSP-Teams, Firmware-Architekten und Plattformentwickler.

Voraussetzungen

Sehr gute C-Kenntnisse, Erfahrung mit dem Ziel-RTOS, Linkern, Startup-Code und Flash-Treibern.

Lernziele

• vorhandene MCUboot-Portschichten und die Anforderungen des Ziel-RTOS bewerten
• Build, Partitionierung, Flash-API und Bootübergabe in die jeweilige Umgebung integrieren
• Update-Agent und Bestätigungslogik an RTOS-Dienste anbinden
• Plattformabweichungen mit portablen Tests und klaren Wartungsgrenzen beherrschen

Seminarinhalte

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

Tag 1: Portvergleich und Buildintegration

Inhaltsverzeichnis des Tageskapitels

• bootutil-Kern gegenüber RTOS-spezifischer Bootanwendung
• Projektstruktur und Buildadapter für Mynewt, NuttX, Mbed oder Eigenentwicklung
• Toolchain, Linkerskript, Startdateien und Binärformate
• Konfigurationsabbildung ohne Zephyr-Kconfig-Abhängigkeit
• Upstream-Nähe, lokale Patches und Wartungsstrategie

Schrittweise Bearbeitung

1. Schritt 1: „bootutil-Kern gegenüber RTOS-spezifischer Bootanwendung“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Projektstruktur und Buildadapter für Mynewt, NuttX, Mbed oder Eigenentwicklung“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Toolchain, Linkerskript, Startdateien und Binärformate“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Konfigurationsabbildung ohne Zephyr-Kconfig-Abhängigkeit“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Upstream-Nähe, lokale Patches und Wartungsstrategie“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Für das gewählte Ziel-RTOS wird eine Integrationsmatrix erstellt und ein minimaler MCUboot-Build bis zum linkfähigen Bootloader aufgebaut.

Tag 2: Flash, Plattformdienste und Anwendungssprung

Inhaltsverzeichnis des Tageskapitels

• Flash-Area-API und Abbildung auf RTOS- oder BSP-Treiber
• Partitionstabellen, Sektorlisten, Alignment und externe Speicher
• Logging, Zeitbasis, Watchdog und Hardwareinitialisierung
• Cache, MPU, Interruptzustand und Vektortabellenübergabe
• Anwendungseinstieg und optionaler Boot-Datenaustausch

Schrittweise Bearbeitung

1. Schritt 1: „Flash-Area-API und Abbildung auf RTOS- oder BSP-Treiber“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Partitionstabellen, Sektorlisten, Alignment und externe Speicher“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Logging, Zeitbasis, Watchdog und Hardwareinitialisierung“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Cache, MPU, Interruptzustand und Vektortabellenübergabe“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Anwendungseinstieg und optionaler Boot-Datenaustausch“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Die Plattformadapter werden implementiert und mit einem fest eingebrachten signierten Image bis zum stabilen Anwendungssprung getestet.

Tag 3: Update-Agent, Bestätigung und Abnahme

Inhaltsverzeichnis des Tageskapitels

• RTOS-spezifischer Download- oder Managementdienst
• Schreiben des Sekundärslots und Setzen des Testzustands
• Selbsttest und Bestätigung durch die Anwendung
• Revert, Stromausfall und serieller oder eigener Recovery-Pfad
• portabler Regressionstest und Dokumentation verbleibender Abhängigkeiten

Schrittweise Bearbeitung

1. Schritt 1: „RTOS-spezifischer Download- oder Managementdienst“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Schreiben des Sekundärslots und Setzen des Testzustands“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Selbsttest und Bestätigung durch die Anwendung“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Revert, Stromausfall und serieller oder eigener Recovery-Pfad“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „portabler Regressionstest und Dokumentation verbleibender Abhängigkeiten“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein kompletter Updateablauf wird in das Ziel-RTOS integriert und mit Reset-Injektion sowie ausbleibender Bestätigung belastet.

Praxisanteil

Der praktische Anteil umfasst für das gewählte ziel-rtos wird eine integrationsmatrix erstellt und ein minimaler mcuboot-build bis zum linkfähigen bootloader aufgebaut; die plattformadapter werden implementiert und mit einem fest eingebrachten signierten image bis zum stabilen anwendungssprung getestet; ein kompletter updateablauf wird in das ziel-rtos integriert und mit reset-injektion sowie ausbleibender bestätigung belastet. 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.