Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Bootloader demo per Microchip Curiosity PIC32MZEF
Importante
Questa demo è ospitata nel repository Amazon-FreeRTOS che è obsoleto. Ti consigliamo di iniziare da qui quando crei un nuovo progetto. Se disponi già di un progetto FreeRTOS esistente basato sull'ormai obsoleto repository Amazon-FreerTOS, consulta il. Guida alla migrazione del RTOS repository Github gratuito da Amazon
Nota
In accordo con Microchip, stiamo rimuovendo Curiosity PIC32MZEF (DM320104) dal ramo principale del repository FreerTOS Reference Integration e non lo utilizzeremo più nelle nuove versioni. Microchip ha emesso un avviso ufficiale
Questo bootloader demo implementa il controllo della versione firmware, verifica la firma crittografica e il self-test dell'applicazione. Queste funzionalità supportano gli aggiornamenti del firmware over-the-air (OTA) per FreerTOS.
La verifica del firmware include il controllo dell'autenticità e dell'integrità del nuovo firmware ricevuto over-the-air. Il bootloader consente di verificare la firma crittografica dell'applicazione prima dell'avvio. La demo utilizza l'ECDSA (Elliptic-Curve Digital Signature Algorithm) su SHA-256. L'utilità fornita può essere utilizzata per generare un'applicazione firmata che è possibile attivare sul dispositivo.
Il bootloader supporta le seguenti caratteristiche necessarie per OTA:
-
Mantiene le immagini dell'applicazione sul dispositivo e passa da una all'altra.
-
Consente il self-test di un'immagine OTA ricevuta e il rollback in caso di errore.
-
Controlla la firma e la versione dell'immagine di aggiornamento OTA.
Nota
Per configurare ed eseguire le demo di FreerTOS, segui i passaggi indicati. Inizia con Free RTOS
Stati del bootloader
Il processo bootloader è illustrato nel seguente stato della macchina.
![Avvia la macchina a stati Bootloader mostrando gli stati di inizializzazione, verifica, esecuzione e lo stato di errore con l'opzione Notify Error.](images/bootloader-states.png)
Nella seguente tabella vengono descritti gli stati del bootloader.
Stato del bootloader | Descrizione |
---|---|
Inizializzazione |
Il bootloader è in stato di inizializzazione. |
Verifica |
Il bootloader verifica le immagini presenti sul dispositivo. |
Esegui immagine |
Il bootloader lancia l'immagine selezionata. |
Esegui predefinita |
Il bootloader lancia l'immagine predefinita. |
Errore |
Il bootloader è in stato di errore. |
Nel diagramma precedente, sia Execute Image
che Execute
Default
vengono visualizzati come stato Execution
.
- Stato di esecuzione del bootloader
-
Il bootloader è nello
Execution
ed è pronto per avviare l'immagine verificata selezionata. Se l'immagine da avviare si trova nel banco di memoria superiore, i banchi vengono scambiati prima di eseguire l'immagine, poiché l'applicazione è sempre sviluppata per il banco di memoria inferiore. - Stato di esecuzione predefinito del bootloader
-
Se l'opzione di configurazione per avviare l'immagine predefinita è abilitata, il bootloader lancia l'applicazione da un indirizzo di esecuzione predefinito. Questa opzione deve essere disabilitata, ma non durante il debug.
- Stato di errore del bootloader
-
Il bootloader è in stato di errore e sul dispositivo non è presente nessuna immagine valida. Il bootloader deve inviare notifica all'utente. L'implementazione predefinita invia un messaggio di log alla console e il LED sulla scheda lampeggia velocemente in modo continuo.
Dispositivo Flash
La piattaforma Microchip Curiosity PIC32MZEF contiene un dispositivo Flash del programma interno di due megabyte (MB) diviso in due banchi di memoria. Supporta lo scambio della mappa di memoria tra questi due banchi e gli aggiornamenti in tempo reale. Il bootloader demo è programmato in un'altra regione flash di avvio inferiore separata.
![Diagramma del layout della memoria che mostra le regioni Lower Boot Flash, Lower Program Flash di 1 MB e Upper Program Flash di 2 MB mappate rispettivamente su Bootloader, Application Bank 0 e Application Bank 1.](images/flash-device.png)
Struttura dell'immagine di un'applicazione
![Struttura dell'immagine OTA che mostra le sezioni dell'intestazione, del descrittore, del file binario dell'applicazione (firmato dal servizio firmatario) e del trailer con campi come codice magico, numeri di sequenza, indirizzi di inizio e fine, indirizzo di esecuzione, ID hardware.](images/application-image-structure.png)
Il diagramma mostra i componenti principali dell'immagine di applicazione archiviata su ogni banco di memoria del dispositivo.
Componente | Dimensione (in byte) |
---|---|
Intestazione immagine |
8 byte |
Descrittore immagine |
24 byte |
File binario applicazione |
< 1 MB – (324) |
Trailer |
292 byte |
Intestazione immagine
Le immagini dell'applicazione presenti sul dispositivo devono iniziare con un'intestazione che comprende un codice magic e flag dell'immagine.
Campo intestazione | Dimensione (in byte) |
---|---|
Codice magic |
7 byte |
Flag immagine |
1 byte |
Codice magic
L'immagine sul dispositivo flash deve iniziare con un codice magic. Il codice magic predefinito è @AFRTOS
. Il bootloader verifica se il codice magic valido è presente prima di avviare l'immagine. Questa è la prima fase della verifica.
Flag immagine
I flag dell'immagine vengono utilizzati per memorizzare lo stato delle immagini dell'applicazione. I flag sono utilizzati nel processo OTA. I flag dell'immagine di entrambi i banchi di memoria determinano lo stato del dispositivo. Se l'esecuzione di immagine viene contrassegnata come commit in sospeso, significa che il dispositivo è in fase di self-test OTA. Anche se le immagini sui dispositivi contrassegnate come valide, sono sottoposte alle stesse fasi di verifica a ogni avvio. Se un'immagine viene contrassegnato come nuova, il bootloader la contrassegna come commit in sospeso e la avvia per il self-test dopo la verifica. Il bootloader, inoltre, inizializza e avvia il timer di watchdog, in modo che se il self-test della nuova immagine OTA ha esito negativo, il dispositivo si riavvia e bootloader rifiuta l'immagine cancellandola, quindi esegue l'immagine valida precedente.
Il dispositivo può avere una sola immagine valida. L'altra immagine può essere una nuova immagine OTA o un commit in sospeso (self-test). Dopo aver eseguito correttamente l'aggiornamento OTA, l'immagine precedente viene cancellata dal dispositivo.
Stato | Valore | Descrizione |
---|---|---|
Nuova immagine |
0xFF |
Applicazione immagine è nuova e non è stata mai eseguita. |
Commit in sospeso |
0xFE |
L'immagine dell'applicazione viene contrassegnata per l'esecuzione del test. |
Valida |
0xFC |
L'immagine dell'applicazione viene contrassegnata come valida e sottoposta a commit. |
Non valido |
0xF8 |
L'immagine dell'applicazione viene contrassegnata come non valida. |
Descrittore immagine
L'immagine dell'applicazione sul dispositivo flash deve contenere il descrittore immagine appena dopo l'intestazione immagine. Il descrittore immagine viene generato da una utilità post-build che utilizza i file di configurazione (ota-descriptor.config
) per generare il descrittore appropriato e lo antepone al file binario dell'applicazione. L'output di questa fase post-build è l'immagine binaria da utilizzare per l'OTA.
Campo descrittore | Dimensione (in byte) |
---|---|
Numero sequenza |
4 byte |
Indirizzo iniziale |
4 byte |
Indirizzo finale |
4 byte |
Indirizzo di esecuzione |
4 byte |
ID hardware |
4 byte |
Riservata |
4 byte |
- Numero sequenza
-
Il numero di sequenza deve essere incrementato prima di creare una nuova immagine OTA. Consulta il file
ota-descriptor.config
. Il bootloader utilizza questo numero per determinare l'immagine di avvio. I valori validi sono compresi tra 1 e 4294967295. - Indirizzo iniziale
-
L'indirizzo iniziale dell'immagine dell'applicazione sul dispositivo. Poiché il descrittore dell'immagine viene anteposto al file binario dell'applicazione, questo indirizzo è l'avvio del descrittore dell'immagine.
- Indirizzo finale
-
L'indirizzo finale dell'immagine dell'applicazione sul dispositivo, escluso il trailer dell'immagine.
- Indirizzo di esecuzione
-
L'indirizzo di esecuzione dell'immagine.
- ID hardware
-
Un ID univoco dell'hardware utilizzato dal bootloader per verificare che l'immagine OTA sia creata per la piattaforma corretta.
- Riservata
-
Questo campo è riservato per un utilizzo futuro.
Trailer dell'immagine
Il trailer dell'immagine viene accodato al file binario dell'applicazione. Contiene la stringa di tipo firma, le dimensioni della firma e la firma dell'immagine.
Campo trailer | Dimensione (in byte) |
---|---|
Tipo firma |
32 byte |
Dimensioni firma |
4 byte |
Firma |
256 byte |
- Tipo firma
-
Il tipo di firma è una stringa che rappresenta l'algoritmo crittografico utilizzato e rappresenta un contrassegno per il trailer. Il bootloader supporta l'ECDSA (Elliptic-Curve Digital Signature Algorithm). Il valore predefinito è sig-sha256-ecdsa.
- Dimensioni firma
-
La dimensione della firma crittografica in byte.
- Firma
-
La firma crittografica del file binario dell'applicazione preceduta dal descrittore dell'immagine.
Configurazione del bootloader
Le opzioni di configurazione del bootloader di base sono fornite in
. Alcune opzioni vengono fornite esclusivamente a scopo di debug.freertos
/vendors/microchip/boards/curiosity_pic32mzef/bootloader/config_files/aws_boot_config.h
- Abilita avvio predefinito
-
Abilita l'esecuzione dell'applicazione dall'indirizzo predefinito e deve essere abilitato solo per il debug. L'immagine viene eseguita dall'indirizzo predefinito senza alcuna verifica.
- Abilita verifica firma crittografica
-
Abilita verifica firma crittografica. Le immagini con stato non riuscito vengono cancellate dal dispositivo. Questa opzione è disponibile solo per scopi di debug e deve rimanere abilitata in produzione.
- Cancella immagine non valida
-
Abilita la cancellazione dell'intero banco di memoria se la verifica dell'immagine su quel banco ha esito negativo. L'opzione è disponibile solo per scopi di debug e deve rimanere abilitata in produzione.
- Abilita verifica ID hardware
-
Abilita la verifica dell'ID hardware nel descrittore dell'immagine OTA e dell'ID hardware programmati nel bootloader. Si tratta di un'opzione facoltativa che può essere disattivata se la verifica dell'ID hardware non è richiesta.
- Abilita verifica indirizzo
-
Abilita la verifica degli indirizzi di inizio, di fine e di esecuzione nel descrittore dell'immagine OTA. Ti consigliamo di tenere questa opzione abilitata.
Creazione del bootloader
Il bootloader demo è incluso come progetto caricabile nel progetto che si trova nel
repository del freertos
/vendors/microchip/boards/curiosity_pic32mzef/aws_demos/mplab/aws_demos
codice sorgente di FreerTOS. Quando viene creato il progetto aws_demos
, crea prima il bootloader, poi l'applicazione. L'output finale è un'immagine esadecimale unificata che include il bootloader e l'applicazione. L'utilità factory_image_generator.py
viene fornita per generare un'immagine esadecimale unificata con firma crittografica. Gli script dell'utilità bootloader si trovano in
.freertos
/demos/ota/bootloader/utility/
Fase di pre-compilazione del bootloader
Questa utilità preinstallata esegue uno script dell'utilità chiamato codesigner_cert_utility.py
che estrae la chiave pubblica dal certificato di firma del codice e genera un file di intestazione C che contiene la chiave pubblica nel formato codificato ASN.1 (Abstract Syntax Notation One). Questa intestazione è compilata nel progetto bootloader. L'intestazione generata contiene due costanti: una serie di chiavi pubbliche e la lunghezza della chiave. Il progetto bootloader può anche essere creato senza aws_demos
e può essere sottoposto a debug come una normale applicazione.