Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Demo-Bootloader für die Microchip Curiosity PIC32MZEF
Wichtig
Diese Demo wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie hier beginnen, wenn Sie ein neues Projekt erstellen. Wenn Sie bereits ein vorhandenes FreeRTOS-Projekt haben, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, finden Sie weitere Informationen unter. Leitfaden zur Migration des kostenlosen RTOS Github-Repositorys von Amazon
Anmerkung
In Absprache mit Microchip entfernen wir den Curiosity PIC32MZEF (DM320104) aus dem Hauptzweig des FreeRTOS Reference Integration-Repositorys und werden ihn nicht mehr in neuen Releases anbieten. Microchip hat eine offizielle Mitteilung
Dieser Demo-Bootloader implementiert die Überprüfung der Firmware-Version, die Verifizierung der kryptografischenSignatur und einen Selbsttest der Anwendung. Diese Funktionen unterstützen Firmware-Updates over-the-air (OTA) für FreeRTOS.
Die Firmware-Verifizierung beinhaltet die Verifizierung der Authentizität und die Integrität der neuen Firmware, die Over The Air empfangen wurde. Vor einem Neustart verifiziert der Bootloader die kryptografische Signatur der Anwendung. Die Demo verwendet einen Elliptic Curve Digital Signature Algorithm (ECDSA) über SHA256. Die bereitgestellten Dienstprogrammen können zur Erstellung einer signierten Anwendung verwendet werden, die auf dem Gerät geflasht werden kann.
Der Bootloader unterstützt die folgenden für OTA erforderlichen Funktionen:
-
Behält Anwendungsabbilder auf dem Gerät und wechselt zwischen ihnen.
-
Ermöglicht die Ausführung eines Selbsttests eines empfangenen OTA-Images und ein Rollback bei Fehlern.
-
Prüft die Signatur und die Version des OTA-Aktualisierungsabbilds.
Anmerkung
Folgen Sie den Schritten unter, um die FreeRTOS-Demos einzurichten und auszuführen. Jetzt kostenlos durchstarten RTOS
Bootloader-Zustände
Der Bootloader-Prozess wird in der folgenden Zustands-Engine gezeigt.
![Starten Sie die Bootloader-Zustandsmaschine mit den Status Initialisierung, Überprüfung, Ausführung und Fehler mit der Option Fehler benachrichtigen.](images/bootloader-states.png)
Die folgende Tabelle beschreibt die Bootloader-Zustände.
Bootloader-Zustand | Beschreibung |
---|---|
Initialisierung |
Der Bootloader befindet sich im Initialisierungszustand. |
Verifizierung |
Der Bootloader verifiziert die auf dem Gerät vorhandenen Abbilder. |
Abbildung ausführen |
Der Bootloader startet das ausgewählte Abbild. |
Standard ausführen |
Der Bootloader startet das Standard-Abbild. |
Fehler |
Der Bootloader befindet sich im Fehlerzustand. |
In der obigen Abbildung werden sowohl Execute Image
als auch Execute
Default
als Execution
-Zustand angezeigt.
- Bootloader-Ausführungszustand
-
Der Bootloader befindet sich im
Execution
-Zustand und ist zum Starten des ausgewählten verifizierten Abbilds bereit. Wenn sich das zu startende Abbild in der oberen Bank befindet, werden die Banken ausgetauscht, bevor das Abbild ausgeführt wird, da die Anwendung immer für die untere Bank erstellt wird. - Bootloader-Standard-Ausführungszustand
-
Wenn die Konfigurationsoption zum Starten des Standard-Abbilds aktiviert ist, startet der Bootloader die Anwendung von einer Standard-Ausführungsadresse. Diese Option muss außer beim Debuggen deaktiviert sein.
- Bootloader-Fehlerzustand
-
Der Bootloader befindet sich in einem Fehlerzustand und es sind keine gültigen Abbilder auf dem Gerät vorhanden. Der Bootloader muss den Benutzer benachrichtigen. Die Standardimplementierung sendet eine Protokollnachricht an die Konsole und löst für eine unbestimmte Zeit ein schnelles Blinken der LED auf der Tafel aus.
Flash-Gerät
Die Microchip Curiosity PIC32MZEF-Plattform enthält einen internen Programm-Flash von zwei Megabyte (MB), der in zwei Banken aufgeteilt ist. Sie unterstützt den Austausch von Memory Maps zwischen diesen beiden Banken und Live-Updates. Der Demo-Bootloader wird in einer separaten niedrigeren Boot-Flash-Region programmiert.
![Das Speicherlayoutdiagramm zeigt die Regionen „Lower Boot Flash“, „Lower Program Flash“ von 1 MB und „Upper Program Flash“ von 2 MB, die jeweils Bootloader, Application Bank 0 und Application Bank 1 zugeordnet sind.](images/flash-device.png)
Struktur des Anwendungsabbilds
![OTA-Bildstruktur mit Kopfzeile, Deskriptor, Anwendungsbinärdatei (signiert vom Signierdienst) und Trailer-Abschnitten mit Feldern wie magischem Code, Sequenznummern, Start- und Endadressen, Ausführungsadresse und Hardware-ID.](images/application-image-structure.png)
Das Diagramm zeigt die Hauptkomponenten des Anwendungsabbilds, die in jeder Bank des Geräts gespeichert sind.
Komponente | Größe (in Bytes) |
---|---|
Abbild-Header |
8 Bytes |
Abbild-Deskriptor |
24 Bytes |
Binärcode der Anwendung |
< 1 MB - (324) |
Trailer |
292 Bytes |
Abbild-Header
Die Anwendungsabbilder auf dem Gerät müssen mit einem Header beginnen, der aus einem magischen Code und Abbild-Flags besteht.
Header-Feld | Größe (in Bytes) |
---|---|
Magischer Code |
7 Bytes |
Abbild-Flags |
1 Byte |
Magischer Code
Das Abbild auf dem Flash-Gerät muss mit einem magischen Code beginnen. Der standardmäßige magische Code lautet @AFRTOS
. Der Bootloader prüft, ob ein gültiger magischer Code vorhanden ist, bevor das Abbild gestartet wird. Dies ist der erste Schritt der Verifizierung.
Abbild-Flags
Die Abbild-Flags werden verwendet, um den Status der Abbilder der Anwendung zu speichern. Die Flags werden im OTA-Prozess verwendet. Die Abbild-Flags beider Banken bestimmen den Zustand des Geräts. Wenn das ausführende Abbild als schwebender Commit markiert ist, bedeutet dies, dass sich das Gerät in der OTA-Selbsttest-Phase befindet. Selbst wenn Abbilder auf den Geräten als gültig markiert sind, durchlaufen sie bei jedem Start dieselben Verifizierungsschritte. Wenn ein Abbild als neu markiert ist, wird es vom Bootloader als schwebender Commit markiert und nach der Überprüfung zum Selbsttest gestartet. Der Bootloader initialisiert und startet außerdem den Watchdog-Timer, sodass das Gerät einen Neustart durchführt, wenn das neue OTA-Abbild den Selbsttest nicht besteht. Der Bootloader weist dann die Abbildung durch Löschen dieser zurück und führt das vorherige gültige Abbild aus.
Das Gerät kann nur ein gültiges Abbild haben. Das andere Abbild kann ein neues OTA-Abbild oder ein schwebender Commit (Selbsttest) sein. Nach einem erfolgreichen OTA-Update wird das alte Abbild vom Gerät gelöscht.
Status | Wert | Beschreibung |
---|---|---|
Neues Abbild |
0xFF |
Das Abbild der Anwendung ist neu und wurde noch nie ausgeführt. |
Schwebender Commit |
0xFE |
Das Abbild der Anwendung ist für die Testausführung gekennzeichnet. |
Valid |
0xFC |
Das Abbild der Anwendung ist als gültig und übernommen markiert. |
Ungültig |
0xF8 |
Das Abbild der Anwendung ist als ungültig markiert. |
Abbild-Deskriptor
Das Abbild der Anwendung auf dem Flash-Gerät muss den Abbild-Deskriptor nach dem Abbild-Header enthalten. Der Abbild-Deskriptor wird von einem Post-Build-Dienstprogramm erstellt, das die Konfigurationsdateien (ota-descriptor.config
) verwendet, um den entsprechenden Deskriptor zu generieren, und stellt diesen dem Binärcode der Anwendung voran. Die Ausgabe dieses Post-Build-Schrittes ist das Binary-Abbild, das für OTA verwendet werden kann.
Feld-Deskriptor | Größe (in Bytes) |
---|---|
Sequenznummer |
4 Bytes |
Startadresse |
4 Bytes |
Endadresse |
4 Bytes |
Ausführungsadresse |
4 Bytes |
Hardware-ID |
4 Bytes |
Reserved Instances |
4 Bytes |
- Sequenznummer
-
Die Sequenznummer muss erhöht werden, bevor ein neues OTA-Abbild erstellt wird. Siehe Datei
ota-descriptor.config
. Der Bootloader ermittelt anhand dieser Nummer das zu startende Abbild. Gültige Werte liegen zwischen 1 und 4294967295. - Startadresse
-
Die Startadresse des Anwendungsabbilds auf dem Gerät. Da der Abbild-Deskriptor der Binärdatei der Anwendung vorangestellt ist, ist diese Adresse der Start des Abbild-Deskriptors.
- Endadresse
-
Die Endadresse des Anwendungsabbilds auf dem Gerät, ohne Abbild-Trailer.
- Ausführungsadresse
-
Die Ausführungsadresse des Abbilds.
- Hardware-ID
-
Eine vom Bootloader verwendete eindeutige Hardware-ID zur Überprüfung, ob das OTA-Abbild für die korrekte Plattform erstellt wurde.
- Reserved Instances
-
Dies ist für die zukünftige Verwendung reserviert.
Abbild-Trailer
Der Abbild-Trailer wird an den Binärcode der Anwendung angehängt. Er enthält die Signaturtyp-Zeichenfolge, die Signaturgröße und die Signatur des Abbilds.
Trailer-Feld | Größe (in Bytes) |
---|---|
Signaturtyp |
32 Bytes |
Signaturgröße |
4 Bytes |
Signature |
256 Byte |
- Signaturtyp
-
Der Signaturtyp ist eine Zeichenfolge, die den verwendeten kryptografischen Algorithmus darstellt und als Markierung für den Trailer dient. Der Bootloader unterstützt den ECDSA-Signaturalgorithmus (Elliptic Curve Digital Signature Algorithm). Der Standardwert ist sig-sha256-ecdsa.
- Signaturgröße
-
Die Größe der kryptografischen Signatur in Bytes.
- Signatur
-
Die kryptografische Signatur des Binärcodes der Anwendung mit dem Abbild-Deskriptor.
Bootloader-Konfiguration
Die grundlegenden Bootloader-Konfigurationsoptionen finden Sie unter
. Einige Optionen werden nur für Debuggingzwecke angeboten.freertos
/vendors/microchip/boards/curiosity_pic32mzef/bootloader/config_files/aws_boot_config.h
- Aktivieren des Standardstarts
-
Aktiviert die Ausführung der Anwendung von der Standardadresse und darf nur für Debugging-Zwecke aktiviert werden. Das Abbild wird ohne Verifizierung von der Standardadresse aus ausgeführt.
- Aktivieren der kryptischen Signaturverifizierung
-
Aktiviert die kryptografische Signaturverifizierung beim Booten. Die fehlgeschlagene Abbilder werden vom Gerät gelöscht. Diese Option steht nur für Debugging-Zwecke zur Verfügung und muss in der Produktivumgebung aktiviert sein.
- Löschen eines ungültigen Abbilds
-
Ermöglicht das vollständige Löschen der Bank, falls die Abbild-Verifizierung für diese Bank fehlschlägt. Diese Option steht nur für Debugging-Zwecke zur Verfügung und muss in der Produktivumgebung aktiviert sein.
- Aktivieren der Hardware-ID-Verifizierung
-
Ermöglicht die Verifizierung der Hardware-ID im Deskriptor des OTA-Abbilds und der Hardware-ID, die im Bootloader programmiert ist. Dies ist optional und kann deaktiviert werden, wenn die Verifizierung der Hardware-ID nicht erforderlich ist.
- Aktivieren der Adressenverifikation
-
Ermöglicht die Überprüfung der Start-, End- und Ausführungsadresse im Deskriptor des OTA-Abbilds. Wir empfehlen, dass Sie diese Option aktiviert lassen.
Entwickeln des Bootloaders
Der Demo-Bootloader ist als ladbares Projekt in dem aws_demos
Projekt enthalten, das sich im FreeRTOS-Quellcode-Repository befindet.
Wenn das freertos
/vendors/microchip/boards/curiosity_pic32mzef/aws_demos/mplab/aws_demos
-Projekt erstellt wurde, wird zuerst der Bootloader, gefolgt von der Anwendung, erstellt. Die endgültige Ausgabe ist ein einheitliches Hex-Abbild für den Bootloader und die Anwendung. Das factory_image_generator.py
-Dienstprogramm wird zum Generieren eines einheitlichen Hex-Abbilds mit kryptografischer Signatur bereitgestellt. Die Skripts des Bootloader-Dienstprogramms befinden sich in
.freertos
/demos/ota/bootloader/utility/
Schritt vor dem Bootloader-Build
Dieser Schritt vor dem Build führt ein Dienstprogramm-Skript mit dem Namen codesigner_cert_utility.py
aus, das den öffentlichen Schlüssel aus dem Codesignierungszertifikat extrahiert und eine C-Header-Datei generiert, die den öffentlichen Schlüssel im Abstract Syntax Notation One (ASN.1)-codierten Format enthält. Dieser Header ist in das Bootloader-Projekt kompiliert. Der generierte Header enthält zwei Konstanten: ein Array des öffentlichen Schlüssels und die Länge des Schlüssels. Das Bootloader-Projekt kann auch ohne aws_demos
erstellt und als normale Anwendung debuggt werden.