Specifica del protocollo CFU (Component Firmware Update)
Questa specifica descrive un protocollo HID generico per aggiornare il firmware per i componenti presenti in un PC o accessori. La specifica consente a un componente di accettare il firmware senza interrompere l'operazione del dispositivo durante un download. La specifica supporta le configurazioni in cui il componente che accetta il firmware potrebbe avere sottocomponenti, che richiedono immagini firmware separate. La specifica consente al componente in carica di decidere se accettare il firmware. Funge anche da ottimizzazione perché l'immagine del firmware viene inviata al componente solo se è in grado o pronta ad accettarla.
Nota
CFU è disponibile in Windows 10 versione 2004 (Windows 10 aggiornamento di maggio 2020) e versioni successive.
Contenuto
- 1 Introduzione
- 2 Architettura hardware supportata
- 3 Prerequisiti del protocollo
- 4 Panoramica del protocollo CFU
- 4.1 Sequenza di comando di programmazione dell'aggiornamento del firmware
- 4.1.1 Stato: notifica inizializzata host
- 4.1.2 Stato: notifica OFFER_INFO_START_OFFER_LIST
- 4.1.3 State: Send FIRMWARE_UPDATE_OFFER Command
- 4.1.4 State: Send Firmware
- 4.1.5 Stato decisionale: sono disponibili altre offerte
- 4.1.6 Stato: notifica OFFER_INFO_END_OFFER_LIST
- 4.1.7 Stato decisionale: Elenco di offerte di riproduzione
- 4.1.8 Stato: il dispositivo è occupato
- 4.1 Sequenza di comando di programmazione dell'aggiornamento del firmware
- 5 Formato di pacchetto del protocollo CFU
- 6 Appendice 1: Sequenza di comando di programmazione dell'aggiornamento del firmware di esempio
Tabelle
Tabella 5.1-1 GET_FIRMWARE_VERSION layout di risposta
Tabella 5.1-2 GET_FIRMWARE_VERSION risposta - Layout intestazione
Tabella 5.1-3 GET_FIRMWARE_VERSION risposta - Bit intestazione
Tabella 5.1-4 GET_FIRMWARE_VERSION Response - Component Version and Properties Layout
Tabella 5.1-5 GET_FIRMWARE_VERSION Risposta - Versione dei componenti e bit delle proprietà
Tabella 5.2-1 FIRMWARE_UPDATE_OFFER layout dei comandi
Tabella 5.2-2 comando FIRMWARE_UPDATE_OFFER - Layout delle informazioni sui componenti
Tabella 5.2-3 comando FIRMWARE_UPDATE_OFFER - Bit di informazioni sui componenti
Tabella 5.2-4 FIRMWARE_UPDATE_OFFER Comando - Layout versione firmware
Tabella 5.2-5 FIRMWARE_UPDATE_OFFER comando - Bit versione firmware
Tabella 5.2-6 comando FIRMWARE_UPDATE_OFFER - Layout specifico del fornitore
Tabella 5.2-7 FIRMWARE_UPDATE_OFFER Comando - Misc. e Versione del protocollo
Tabella 5.2-8 FIRMWARE_UPDATE_OFFER layout del token di risposta
Tabella 5.2-9 FIRMWARE_UPDATE_OFFER Risposta - Layout token
Tabella 5.2-10 FIRMWARE_UPDATE_OFFER risposta - Bit di token
Tabella 5.2-11 FIRMWARE_UPDATE_OFFER Risposta - Rifiuta layout motivo
Tabella 5.2-12 FIRMWARE_UPDATE_OFFER Risposta - Rifiuta bit motivo
Tabella 5.2-13 FIRMWARE_UPDATE_OFFER valori del codice RR di risposta
Tabella 5.2-14 FIRMWARE_UPDATE_OFFER layout dello stato della risposta
Tabella 5.2-15 FIRMWARE_UPDATE_OFFER Risposta - Bit di stato
Tabella 5.2-16 FIRMWARE_UPDATE_OFFER valori di stato della risposta
Tabella 5.3-1 FIRMWARE_UPDATE_OFFER - Layout dei comandi informazioni
Tabella 5.3-2 FIRMWARE_UPDATE_OFFER - Comando informazioni - Layout componente
Tabella 5.3-3 FIRMWARE_UPDATE_OFFER - Comando informazioni - Bit componente
Tabella 5.3-4 FIRMWARE_UPDATE_OFFER - Comando informazioni - Valori del codice informativo
Tabella 5.3-5 FIRMWARE_UPDATE_OFFER - Layout di risposta delle informazioni
Tabella 5.3-6 FIRMWARE_UPDATE_OFFER- Layout del token di risposta dei pacchetti di informazioni
Tabella 5.3-7 FIRMWARE_UPDATE_OFFER - Risposta alle informazioni - Bit di token
Tabella 5.3-8 FIRMWARE_UPDATE_OFFER - Risposta alle informazioni - Layout del codice RR
Tabella 5.3-9 FIRMWARE_UPDATE_OFFER- Risposta alle informazioni dell'offerta - Bit di codice RR
Tabella 5.3-10 FIRMWARE_UPDATE_OFFER- Risposta alle informazioni - Valori del codice RR
Tabella 5.3-12 FIRMWARE_UPDATE_OFFER - Informazioni sull'offerta - Bit di stato della risposta
Tabella 5.4-1 FIRMWARE_UPDATE_OFFER - Layout dei comandi esteso
Tabella 5.4-2 FIRMWARE_UPDATE_OFFER - Pacchetto di comandi esteso - Comando - Layout del componente
Tabella 5.4-3 FIRMWARE_UPDATE_OFFER - Comando esteso - Bit componente
Tabella 5.4-4 FIRMWARE_UPDATE_OFFER - Comando esteso - Valori del codice del comando
Tabella 5.4-5 FIRMWARE_UPDATE_OFFER - Layout della risposta dei pacchetti di comandi estesi
Tabella 5.4-6 FIRMWARE_UPDATE_OFFER - Risposta del pacchetto di comandi dell'offerta - Layout token
Tabella 5.4-7 FIRMWARE_UPDATE_OFFER - Risposta al comando dell'offerta - Bit di token
Tabella 5.4-9 FIRMWARE_UPDATE_OFFER- Risposta al comando dell'offerta - Codice RR
Tabella 5.4-10 FIRMWARE_UPDATE_OFFER- Pacchetto di comandi dell'offerta - Valori del codice RR
Tabella 5.4-12 FIRMWARE_UPDATE_OFFER- Codice RR di risposta al pacchetto di comandi dell'offerta
Tabella 5.5-1 FIRMWARE_UPDATE_CONTENT Layout dei comandi
Tabella 5.5-2 FIRMWARE_UPDATE_CONTENT layout dell'intestazione del comando
Tabella 5.5-3 FIRMWARE_UPDATE_CONTENT bit di intestazione
Tabella 5.5-4 FIRMWARE_UPDATE_OFFER- Pacchetto di comandi dell'offerta - Valori dei flag
Tabella 5.5-5 FIRMWARE_UPDATE_CONTENT Layout dei dati dei comandi
Tabella 5.5-6 FIRMWARE_UPDATE_CONTENT bit di dati dei comandi
Tabella 5.5-7 FIRMWARE_UPDATE_CONTENT layout della risposta del comando
Tabella 5.5-8 FIRMWARE_UPDATE_CONTENT Risposta - Numero di sequenza
Tabella 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bit di risposta
Tabella 5.5-10 FIRMWARE_UPDATE_CONTENT layout dello stato della risposta
Tabella 5.5-11 FIRMWARE_UPDATE_OFFER - Risposta - Bit di stato
Tabella 5.5-12 FIRMWARE_UPDATE_OFFER- Risposta - Valori del codice di stato
1 Introduzione
I PC e gli accessori di oggi hanno componenti interni che eseguono operazioni complesse. Per garantire un prodotto di qualità, è necessario aggiornare frequentemente il comportamento di questi dispositivi nelle fasi successive dello sviluppo o dopo che sono stati spediti ai clienti. L'aggiornamento potrebbe risolvere i problemi funzionali o di sicurezza identificati o la necessità di aggiungere nuove funzionalità. Una grande parte della logica complessa si trova nel firmware in esecuzione nel dispositivo, che è aggiornabile.
Questa specifica descrive un protocollo HID generico per aggiornare il firmware per i componenti presenti in un PC o nei relativi accessori. L'implementazione HID non rientra nell'ambito della specifica.
Alcune delle funzionalità del protocollo sono:
Il protocollo è basato su HID, che è onnipresente e supporta Windows in-box su vari bus di interconnessione, ad esempio USB e I2C. Pertanto, la stessa soluzione software (driver) può essere sfruttata per aggiornare il firmware per tutti i componenti.
Nota
Poiché la specifica è basata su pacchetti, è semplice adattarla a scenari non HID.
La specifica consente a un componente di accettare il firmware senza interrompere l'operazione del dispositivo durante il download. Consente un'esperienza migliore per gli utenti perché non devono attendere il completamento del processo di aggiornamento del firmware prima di poter riprendere altre attività. Il nuovo firmware può essere richiamato in una singola operazione atomica alla volta con un impatto minimo sull'utente.
La specifica supporta le configurazioni in cui il componente che accetta il firmware potrebbe avere sottocomponenti, che richiedono immagini firmware separate.
Nota
Il processo di un componente che passa il firmware al componente secondario non rientra nell'ambito di questa specifica.
La specifica supporta il concetto di offerta e si basa sul componente incaricato per decidere se accettare il firmware. La decisione di accettare un nuovo firmware non è semplice. Potrebbero esserci dipendenze tra il tipo di firmware e/o la versione e il tipo/versione sottostante dell'hardware a cui si applica il nuovo firmware. Un'offerta funge anche da meccanismo di ottimizzazione perché l'immagine del firmware viene inviata al componente solo se è in grado di accettarla.An offer also as an optimization mechanism because the firmware image is sent to the component only if it's able /ready to accept it.
1.1 Glossario
| Termine | Descrizione |
|---|---|
| ID componente | In un dispositivo con più componenti, un ID componente identifica in modo univoco ogni componente. |
| CRC | Controllo della ridondanza ciclico Algoritmo hash non crittografico usato per produrre un digest o un'impronta digitale di un blocco di dati. Il CRC viene usato come controllo per garantire che il blocco di dati non sia stato modificato dopo il calcolo di CRC. Il CRC non è infallibile, ma garantisce la certezza che i dati siano stati ricevuti correttamente. |
| Dispositivo | Raccolta di componenti (un componente primario e zero o più sottocomponenti). Il dispositivo è visibile al sistema operativo come singola unità. L'host interagisce con il dispositivo, che in genere è il componente primario. In un computer possono essere presenti più dispositivi. Per quanto riguarda questa specifica, le comunicazioni con 2 dispositivi diversi sono totalmente indipendenti. |
| Driver | Driver scritto usando il framework Windows Driver Foundation (WDF). |
| Firmware | Codice in esecuzione sull'hardware fisico. Il firmware è aggiornabile e in genere risiede nella memoria programmabile associata all'hardware. |
| Hardware | Un pezzo fisico di siliconi sul computer. |
| Componente primario | Un componente hardware in un computer e il firmware per esso. Nel contesto di questa specifica, un componente è l'entità necessaria e accetta l'aggiornamento del firmware. |
| Segment | Un'immagine del firmware per un componente può essere segmentata in segmenti più piccoli. Ogni segmento è un'immagine di firmware di piccole dimensioni. |
| ID segmento | Se un firmware di un componente viene segmentato in segmenti più piccoli, l'ID segmento è l'identificatore univoco per il segmento. |
| Firma | Un mezzo crittografico per determinare se l'immagine del firmware è stata modificata da mezzi non autorizzati. Le firme sono facoltative, ma consigliate e non rientrano nell'ambito di questa specifica. |
| Sottocomponente | A seconda dell'architettura hardware, non tutti i componenti possono essere visibili al sistema operativo, perché possono essere connessi a valle di un componente visibile al sistema. Questi componenti vengono definiti sottocomponenti in questa specifica. |
| TLC | Raccolta hid di primo livello. |
| token | Identificatore per una sessione host. Un host crea un token e lo invia nei comandi e il dispositivo lo restituisce nella risposta. I token possono essere usati per serializzare determinate transazioni o per identificare che una sessione è stata persa e un altro avvio. |
1.2 Ambito
1.2.1 Goals
È necessaria una soluzione indipendente dall'autobus per evitare un nuovo protocollo per ogni tipo di autobus. HID è onnipresente e risponde a tale requisito.
La possibilità di supportare l'aggiornamento del firmware per un dispositivo multicomponente, in cui un componente funge da componente primario e altri sono sottocomponenti connessi al componente primario. Ogni componente richiede il proprio firmware con dipendenze non semplici tra loro.
Un modello di driver comune per scaricare l'immagine del firmware nel componente. Il componente dispone quindi di algoritmi specifici del sottocomponente per l'inoltro ai sottocomponenti. I sottocomponenti possono anche eseguire controlli di validità sul firmware e passare i risultati al componente primario.
Possibilità di supportare l'aggiornamento del firmware mentre è in corso l'operazione del dispositivo.
Possibilità di aggiornare o eseguire il rollback del firmware nei dispositivi di produzione tramite strumenti autorizzati e aggiornare i dispositivi sul mercato tramite Windows Update.
La flessibilità di supportare firmware/firmware in-market in-development.
La possibilità di segmentare un'immagine di firmware di grandi dimensioni in segmenti più piccoli per semplificare l'accettazione dell'immagine del firmware da parte del componente.
1.2.2 Non Goals
Definire il formato interno dell'immagine del firmware: per l'host, l'immagine del firmware è un set di voci di indirizzo e payload.
Firmare/crittografare/convalidare il firmware accettato: questa specifica non descrive come firmare e crittografare le immagini del firmware. È necessario che il firmware corrente previsto in esecuzione nel componente convalide il firmware scaricato.
Definire un meccanismo sulla modalità di interazione del componente con i sottocomponenti: l'host interagisce con il dispositivo come singola unità, in genere il componente primario. Il componente deve fungere da ponte per la comunicazione correlata al firmware del sottocomponente.
2 Architettura hardware supportata
Per supportare una progettazione hardware flessibile, il protocollo supporta un dispositivo multi-componente in cui ogni componente richiede una propria immagine del firmware. Nella progettazione, un componente è il componente primario e i sottocomponenti dipendenti sono connessi a tale componente primario. Ogni componente è descritto in modo univoco da un ID componente.
Il dispositivo multi-componente è visibile al sistema operativo come singola unità. L'host interagisce solo con il dispositivo, in genere il componente primario usando questo protocollo CFU. La comunicazione tra il componente e i relativi sottocomponenti esula dall'ambito di questa specifica.
In un PC potrebbero essere presenti molti dispositivi diversi (in cui un dispositivo può avere uno o più componenti in tale dispositivo). Nel contesto di questo protocollo, la comunicazione con ogni dispositivo è indipendente. Ogni dispositivo ha un'istanza corrispondente dell'host.
3 Prerequisiti del protocollo
Questa sezione elenca i perquisite e le procedure consigliate che devono essere implementate per sfruttare questo protocollo:
Utilizzo dell'immagine atomica
Un'immagine del firmware per un componente non viene usata fino a quando l'intera immagine del firmware non è stata scaricata correttamente. Nel caso in cui il firmware sia suddiviso in più segmenti, l'immagine non deve essere usata fino a quando il segmento finale non viene ricevuto dal mittente. I controlli di integrità devono essere eseguiti sull'immagine finale. È consigliabile che il trasporto, usato per recapitare l'immagine del firmware, disponga di meccanismi di correzione e ripetizione degli errori per evitare un download ripetuto in caso di errori di trasporto.
L'aggiornamento del firmware non deve interrompere l'operazione del dispositivo
Il dispositivo che accetta l'immagine del firmware deve essere in grado di funzionare durante l'aggiornamento. Il dispositivo deve avere memoria aggiuntiva per archiviare e convalidare il firmware in ingresso, mentre il firmware corrente non viene sovrascritto.
Autenticazione e integrità
L'implementatore decide che i fattori che costituiscono un'immagine del firmware autentica. È consigliabile che il firmware corrente del componente debba almeno convalidare il CRC dell'immagine del firmware in ingresso. Il firmware corrente deve anche usare la firma digitale o altri algoritmi di rilevamento degli errori. Se la convalida non riesce, il firmware rifiuta l'aggiornamento. Ripristino degli errori
Se l'immagine del firmware viene scaricata e non riesce, il dispositivo non deve richiamare il nuovo firmware e continuare a funzionare con il firmware esistente. L'host può ripetere l'aggiornamento. La frequenza di ripetizione dei tentativi è specifica dell'implementazione.
Riservatezza
facoltativo. È possibile crittografare un segmento di firmware. Le tecniche di crittografia e decrittografia non rientrano nell'ambito di questa specifica. Questa specifica considera il payload del firmware come flusso di dati, indipendentemente dal fatto che sia crittografato.
Protezione del rollback
I criteri di rollback vengono applicati dal componente primario e sono specifici dell'implementazione. Il firmware corrente nel componente convalida le immagini del firmware in ingresso in base a criteri interni, ad esempio il numero di versione, deve essere più recente o il tipo di versione non può essere passato dal rilascio al debug e così via. Il protocollo consente la messaggistica per indicare che un aggiornamento viene accettato anche se viola i criteri di rollback.
4 Panoramica del protocollo CFU
Il protocollo CFU è un set di comandi e risposte necessari per inviare le nuove immagini del firmware dall'host al dispositivo per cui è previsto il firmware.
A livello generale, il protocollo scorre tutte le immagini del firmware da inviare al dispositivo. Per ogni immagine del firmware, l'host offre di inviare il file al dispositivo. Solo se il dispositivo accetta l'offerta, l'host invia il file.
Per supportare i casi in cui un ordine di aggiornamento del dispositivo ha dipendenze, il dispositivo potrebbe non accettare determinate offerte nel primo passaggio, pertanto il protocollo consente all'host di inviare nuovamente tutte le offerte del firmware al dispositivo fino a quando non vengono risolte tutte le dipendenze.
4.1 Sequenza di comando di programmazione dell'aggiornamento del firmware
Ecco la sequenza di comando CFU per l'aggiornamento dell'immagine del firmware.
4.1.1 Stato: notifica inizializzata host
Dopo che l'host si inizializza e ha identificato un set di offerte che deve inviare al dispositivo, l'host emette un comando OFFER_INFO_START_ENTIRE_TRANSACTION per indicare al componente che l'host è ora inizializzato. Lo scopo di questo comando è notificare al firmware del dispositivo corrente che è disponibile una nuova istanza dell'host. Questa notifica è utile quando un'istanza precedente dell'host viene terminata in modo imprevisto. Il dispositivo deve completare questo comando con esito positivo.
4.1.2 Stato: notifica OFFER_INFO_START_OFFER_LIST
In questo stato, l'host rilascia il comando OFFER_INFO_START_OFFER_LIST per indicare che è pronto per inviare le offerte al firmware del dispositivo corrente. Il componente principale del dispositivo deve completare questo comando con esito positivo.
Questo comando è utile perché l'host può inviare tutte le offerte al dispositivo più volte.
4.1.3 State: Send FIRMWARE_UPDATE_OFFER command
L'host invia un'offerta al componente primario (o al relativo sottocomponente) per verificare se il componente vuole accettare o rifiutare il firmware. L'offerta contiene tutti i metadati necessari sull'immagine del firmware, in modo che il firmware corrente nel componente possa decidere se accettare, inserire, ignorare o rifiutare l'offerta.
L'offerta può essere relativa al componente primario o al sottocomponente. Se il componente può accettare l'offerta, si prepara a ricevere il firmware. Ciò può comportare la preparazione di una banca di memoria per ricevere l'immagine del firmware in ingresso. Il componente potrebbe non accettare l'offerta, ad esempio, il componente potrebbe avere già una versione del firmware più recente (o uguale) che l'host intende inviare. Per altri motivi, vedere gli esempi descritti nell'Appendice 1: Sequenza di comando di programmazione dell'aggiornamento del firmware di esempio.
Anche se viene accettata un'offerta, il componente primario può comunque rifiutare l'immagine del firmware dopo il download per errori di integrità e/o i controlli di rollback rispetto all'immagine effettiva ricevuta. Il componente deve controllare ogni proprietà dell'immagine del firmware indipendentemente da qualsiasi informazione nell'offerta.
L'host invia il comando FIRMWARE_UPDATE_OFFER per notificare al componente primario l'immagine del firmware che l'host intende inviare.
Se il componente accetta l'offerta, con FIRMWARE_UPDATE_OFFER_ACCEPT stato accettando l'offerta.
Se il firmware del dispositivo è occupato e il componente primario non è in grado di accettare questo o l'offerta successiva, invia una risposta occupata con stato FIRMWARE_UPDATE_OFFER_BUSY.
Se il firmware corrente è interessato all'offerta, tuttavia non può accettare l'offerta (ad esempio, a causa di una dipendenza da un aggiornamento mancante per il sottocomponente) risponde con un FIRMWARE_UPDATE_OFFER_SKIP che indica che è interessato a questo firmware, tuttavia non è in grado di accettarlo. L'host procede quindi all'offerta successiva e deve offrire nuovamente questo firmware in un secondo momento.
Se il firmware corrente non è interessato all'offerta (ad esempio, si tratta di una versione precedente), risponde con uno stato di FIRMWARE_UPDATE_OFFER_REJECT fornendo il motivo di rifiuto appropriato. Questo stato non indica che l'host non può inviare di nuovo questa offerta in futuro. L'host invia in genere ogni offerta ogni volta che inizializza o invia nuovamente l'elenco di offerte al dispositivo (vedere State: OFFER_INFO_START_OFFER_LIST Notification).
4.1.4 State: Send Firmware
In questo stato l'host inizia a inviare l'immagine del firmware al componente primario, per cui il componente ha accettato in precedenza l'offerta.
Poiché il contenuto dell'immagine del firmware è probabilmente superiore ai limiti del payload di un singolo comando, l'host interrompe le immagini del firmware nei pacchetti. L'host invia ogni pacchetto in sequenza in un comando CONTENT separato FIRMWARE_UPDATE. Il componente primario deve generare un pacchetto di risposta per ogni comando.
Ogni comando FIRMWARE_UPDATE CONTENT descrive un indirizzo di offset che include un payload del firmware parziale. Il componente usa l'offset per determinare l'indirizzo in cui deve essere archiviato il payload del firmware parziale. Il dispositivo scrive il contenuto in una posizione appropriata e riconosce il comando inviando una risposta.
Per il primo pacchetto inviato dall'host, imposta il flag di FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, che indica al dispositivo il primo pacchetto dell'immagine del firmware. Se il dispositivo non è già stato preparato per ricevere il firmware, può farlo in questo momento.
Per l'ultimo pacchetto, l'host invia, imposta il flag di FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Dopo che il firmware corrente nel dispositivo ha scritto il payload del firmware parziale incluso in questo comando, deve eseguire controlli di convalida e autenticazione sull'immagine del firmware in ingresso prima di inviare una risposta. Ciò include in modo minimo:
Controllo CRC per verificare l'integrità dell'intera immagine del firmware.
Se il controllo CRC ha esito positivo, verifica facoltativa di una firma dell'immagine in ingresso.
Dopo il controllo della firma facoltativa, un controllo della versione per assicurarsi che la nuova versione del firmware sia uguale o più recente del firmware esistente.
Nel caso in cui l'immagine del firmware in ingresso sia stata divisa in segmenti più piccoli, è fino al firmware corrente per determinare se è l'ultimo segmento dell'immagine del firmware e successivamente includere tutti i segmenti come parte della convalida.
Se i controlli precedenti passano, il firmware corrente può configurare il dispositivo per scambiare la nuova immagine alla reimpostazione successiva e segnala l'esito positivo all'host. In genere, il componente non avvia una reimpostazione automatica. Si tratta di impedire interruzioni in qualsiasi software, firmware, entità hardware con cui il componente interagisce. Tuttavia, questo non è un requisito e può variare a seconda dell'implementazione.
Se i passaggi di verifica non riescono, il firmware non deve configurare uno scambio nella reimpostazione successiva e deve indicare una risposta di errore all'host.
4.1.5 Stato decisionale: sono disponibili altre offerte
In questo stato, l'host determina se sono presenti più offerte da inviare al dispositivo.
4.1.6 Stato: OFFER_INFO_END_OFFER_LIST notifica
Questo stato viene raggiunto quando l'host ha inviato tutte le offerte al componente primario nel firmware del dispositivo corrente. L'host invia il comando OFFER_INFO_END_OFFER_LIST per indicare che ha inviato tutte le offerte al componente.
Il dispositivo deve completare questo comando con esito positivo.
4.1.7 Stato decisionale: Elenco offerte di riproduzione
L'host determina se deve inviare nuovamente tutte le offerte. Questo caso potrebbe verificarsi se in precedenza il componente primario aveva ignorato alcune offerte e accettato alcune offerte. L'host deve riprodurre di nuovo l'elenco di offerte.
Potrebbe esserci un'altra logica di implementazione specifica che potrebbe causare una decisione di riprodurre l'elenco di offerte.
4.1.8 Stato: il dispositivo è occupato
Questo stato implica che un dispositivo ha restituito una risposta occupato a un'offerta.
L'host invia un comando OFFER_NOTIFY_ON_READY, a cui il dispositivo non risponde con accettazione fino a quando il dispositivo non è libero.
5 Formato pacchetto del protocollo CFU
Il protocollo CFU viene implementato come set di comandi e risposte. Il protocollo è sequenziale in natura. Per ogni comando inviato dall'host a un componente, il componente deve rispondere (a meno che non sia indicato in modo esplicito in questa specifica). L'host non invia il comando successivo finché non viene ricevuta una risposta valida per il comando precedente inviato.
Se il componente non risponde entro un periodo o invia una risposta non valida, l'host può riavviare il processo dall'inizio. Questo protocollo non definisce un valore di timeout specifico.
Esistono comandi per ottenere le informazioni sulla versione del firmware corrente nel componente; per inviare l'offerta e per inviare l'immagine del firmware.
Tuttavia, l'host non deve mantenere un'offerta in base alla risposta ricevuta dal componente primario sulle informazioni sulla versione query. Le informazioni vengono rese individuabili per la registrazione o per altri scopi.
5.1 GET_FIRMWARE_VERSION
Ottiene le versioni correnti del firmware del componente primario (e i relativi sottocomponenti). Il comando non include argomenti.
Comando 5.1.1
Questo comando viene inviato dall'host per eseguire una query sulle versioni del firmware corrente nel componente primario (e sui relativi sottocomponenti). L'host può usarlo per verificare se il firmware è stato aggiornato correttamente. Durante la ricezione di questo comando, il componente primario risponde con la versione del firmware stessa e tutti i sottocomponenti.
Risposta 5.1.2
Il componente risponde con la versione del firmware del componente primario e i sottocomponenti. Le dimensioni della risposta sono di 60 byte che consentono informazioni sulla versione per un massimo di sette componenti (un componente primario e fino a sei sottocomponenti).
Tabella 5.1-1 GET_FIRMWARE_VERSION Layout risposta
Intestazione 5.1.2.1
Tabella 5.1-2 GET_FIRMWARE_VERSION Risposta - Layout intestazione
L'intestazione per la risposta fornisce le informazioni seguenti.
Tabella 5.1-3 GET_FIRMWARE_VERSION risposta - Bit di intestazione
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Conteggio componenti | 8 | Numero di componenti scaricabili gestiti tramite questo meccanismo per questo componente. Il conteggio componenti determina le dimensioni massime della tabella. Attualmente sono supportati fino a 7 componenti per garantire che la risposta possa adattarsi entro i 60 byte consentiti. |
| 8 | Rsvd | 16 | Campi riservati. Il mittente deve impostarlo su 0. Il ricevitore deve ignorare questo valore. |
| 24 | Versione del protocollo | 4 | I bit di revisione dell'aggiornamento del firmware rappresentano la revisione del protocollo di aggiornamento FW attualmente in uso nel trasporto. Per l'interfaccia definita in questo caso, la revisione dell'aggiornamento FW deve essere 0010b. |
| 28 | Rsvd | 3 | Campi riservati. Il mittente deve impostarlo su 0. Il ricevitore deve ignorare questo valore. |
| 31 | E | 1 | Il flag di estensione è un hook di protocollo futuro per consentire la segnalazione di componenti aggiuntivi. |
5.1.2.2 Componente versione e proprietà
Per ogni componente vengono usati due DWORD per descrivere le proprietà del componente fino a 7 componenti. Se il conteggio dei componenti nell'intestazione è minore di 7, la DWORDS inutilizzata alla fine della risposta deve essere impostata su 0.
Tabella 5.1-4 GET_FIRMWARE_VERSION Risposta - Versione componente e layout proprietà
Ogni informazione specifica del componente è descritta in due DWORD come indicato di seguito:
Tabella 5.1-5 GET_FIRMWARE_VERSION Risposta - Versione componente e bit proprietà
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Versione del firmware | 32 | Restituisce la versione del firmware corrente per tale componente. Questa specifica non impone alcun formato specifico per la versione del firmware. Vedere la sezione Versione firmware per le linee guida. |
| 32 | Banca | 2 | facoltativo. A seconda dell'architettura, l'hardware del componente può avere più banche in cui può essere archiviato il firmware. A seconda dell'implementazione, il mittente può specificare la banca in cui è attualmente presente il firmware. Questo campo è obbligatorio condizionale. Il supporto è facoltativo, ma non deve essere usato per altri scopi. |
| 34 | Riservato | 2 | Campi riservati. Il mittente deve impostarli su 0. Il ricevitore deve ignorare questo valore. |
| 36 | Specifica del fornitore | 4 | Campo specifico del fornitore che può essere usato in modo specifico per l'implementazione. Un fornitore può usare questi bit per codificare informazioni quali: - Tipo di firmware: pre-rilascio/self-host/produzione; debug/vendita al dettaglio - Fase di sviluppo - ID prodotto, per impedire ai componenti di ricevere firmware per altri prodotti che usano lo stesso protocollo di aggiornamento. |
| 40 | ID componente | 8 | Identificatore univoco per il componente. |
| 48 | Specifica del fornitore | 16 | Campo specifico del fornitore che può essere usato in modo specifico per l'implementazione. |
5.1.3 Mapping a HID
Questa operazione viene implementata come richiesta di recupero della funzionalità HID con dimensioni di risposta pari a 60 byte, oltre all'ID report. La lunghezza del report delle funzionalità supporta l'intera risposta GET_FIRMWARE_VERSION. Non sono presenti dati associati alla richiesta Ottieni funzionalità dall'host.
5.2 FIRMWARE_UPDATE_OFFER
Determina se il componente primario accetta o rifiuta un firmware.
Comando 5.2.1
L'host invia questo comando al componente per determinare se accetta o rifiuta un firmware. L'host deve inviare un'offerta e il componente deve accettare l'offerta prima che l'host possa inviare il firmware.
Il pacchetto di comando FIRMWARE_UPDATE_OFFER è definito come segue.
Tabella 5.2-1 FIRMWARE_UPDATE_OFFER layout dei comandi
5.2.1.1 Informazioni sui componenti
Tabella 5.2-2 comando FIRMWARE_UPDATE_OFFER - Layout delle informazioni sui componenti
I bit del byte di informazioni sui componenti sono descritti in questa tabella.
Tabella 5.2-3 comando FIRMWARE_UPDATE_OFFER - Bit di informazioni sui componenti
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Numero segmento | 8 | Questo campo viene usato nel caso in cui il firmware per un componente sia segmentato in segmenti più piccoli. Se usato, questo valore indica il segmento contenuto nel pacchetto payload successivo. Ad esempio, se l'immagine del firmware per il componente è molto grande e il componente primario può accettare solo parti più piccole dell'immagine alla volta, questo campo può essere usato per indicare che questa offerta è per il segmento i-th dell'immagine completa. È possibile inviare un'offerta separata al componente primario che contiene il segmento i+1 dell'immagine e così via. |
| 8 | Riservato | 6 | Campi riservati. Il mittente deve impostarli su 0. Il ricevitore deve ignorare questo valore. |
| 14 | I | 1 | Forzare la reimpostazione immediata (I) - Questo valore di bit viene usato per indicare al componente di reimpostarsi immediatamente dopo che il download del firmware è stato completato e verificato per richiamarlo immediatamente. - Questo flag è destinato alla fase di sviluppo. |
| 15 | V | 1 | Forza ignora versione (V) - Questo flag è destinato all'immagine del firmware non definitive o di debug. Indica al componente di non rifiutare il firmware in base alla versione del firmware. - Questo flag è destinato alla fase di sviluppo. Può essere usato per eseguire intenzionalmente il rollback a una versione precedente del firmware. - Questo flag deve essere ignorato dal firmware di produzione. |
| 16 | ID componente | 8 | Questo byte viene usato per scenari a più componenti. Questo campo può essere utilizzato per identificare il sottocomponente per il quale è prevista l'offerta. Se non viene usato, il valore deve essere 0. I possibili valori degli ID componente sono i seguenti: 1 - 0xDF: valido 0xE0 - 0xFD: riservato. Non usare. 0xFF: l'offerta è un pacchetto di informazioni sull'offerta speciale. Per informazioni dettagliate, vedere FIRMWARE_UPDATE_OFFER Informazioni. 0xFE: l'offerta è un pacchetto di comando speciale dell'offerta. Per informazioni dettagliate, vedere FIRMWARE_UPDATE_OFFER sezione Estesa. |
| 24 | token | 8 | L'host inserisce un token univoco nel pacchetto dell'offerta al componente. Questo token deve essere restituito dal componente nella risposta dell'offerta.< Ciò è utile se è necessario che il componente distingua i diversi host/tipi di host. I valori esatti da usare sono specifici dell'implementazione. Ad esempio, un valore può essere usato per un driver e un altro per l'applicazione. Ciò consente al firmware del dispositivo corrente di tenere conto di potenziali mittenti di comandi CFU. Una possibile implementazione può essere accettare il primo comando CFU e rifiutare tutti gli altri comandi con token diversi fino al completamento delle prime transazioni CFU. |
Versione del firmware 5.2.1.2
Questi quattro byte rappresentano la versione a 32 bit del firmware. Il formato per la versione del firmware non è richiesto da questa specifica. È consigliabile eseguire le operazioni seguenti.
Tabella 5.2-4 FIRMWARE_UPDATE_OFFER Comando - Layout versione firmware
Il formato per la versione del firmware non è obbligatorio da questa specifica, ma è consigliabile seguire le linee guida consigliate.
Tabella 5.2-5 FIRMWARE_UPDATE_OFFER comando - Bit versione firmware
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Variant | 8 | Questo campo può essere descritto per distinguere tra un firmware non rilasciato e un firmware di produzione. Può indicare il tipo di firma usata per firmare il firmware. |
| 8 | Versione secondaria | 16 | Questo valore di campo deve essere aggiornato per ogni build del firmware. Questo valore di campo deve essere aggiornato per ogni build del firmware. |
| 24 | Versione principale | 8 | Questo campo è la versione principale dell'immagine del firmware. Questo campo deve essere aggiornato quando si spedirà una nuova linea di prodotti, nuovi aggiornamenti principali al firmware e così via. |
5.2.1.3 Specifica del fornitore
Questi quattro byte possono essere usati per codificare qualsiasi informazione personalizzata nell'offerta specifica per l'implementazione del fornitore.
5.2.1.4 Misc. e Versione del protocollo
Questi quattro byte possono essere usati per codificare qualsiasi informazione personalizzata nell'offerta specifica per l'implementazione del fornitore.
Tabella 5.2-6 comando FIRMWARE_UPDATE_OFFER - Layout specifico del fornitore
I bit del byte specifico del fornitore sono descritti in questa tabella.
Tabella 5.2-7 FIRMWARE_UPDATE_OFFER Comando - Misc. e Versione del protocollo
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Versione del protocollo | 4 | Questo campo deve essere impostato su 0010b che indica che l'host/offerta corrisponde alla versione 2 del protocollo CFU. |
| 4 | Riservato | 4 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Specifica del fornitore | 16 | Questo campo può essere usato per codificare qualsiasi informazione personalizzata nell'offerta specifica per l'implementazione del fornitore. |
5.2.2 Risposta
Il pacchetto di FIRMWARE_UPDATE_OFFER Response viene definito come segue.
Tabella 5.2-8 FIRMWARE_UPDATE_OFFER layout del token di risposta
5.2.2.1 Token
Tabella 5.2-9 FIRMWARE_UPDATE_OFFER Risposta - Layout token
I bit del byte token sono descritti in questa tabella.
Tabella 5.2-10 FIRMWARE_UPDATE_OFFER risposta - Bit di token
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Riservato | 8 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Riservato | 8 | Riservato. Non usare. |
| 24 | token | 8 | Token per identificare l'host. |
5.2.2.2 Riservato (B7 - B4)
Riservato. Non usare.
5.2.2.3 Rifiuta motivo (RR)
Tabella 5.2-11 FIRMWARE_UPDATE_OFFER risposta - Rifiuta layout motivo
Tabella 5.2-12 FIRMWARE_UPDATE_OFFER risposta - Rifiutare bit di motivo
I bit del byte Reject Reason sono descritti in questa tabella.
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Codice RR | 8 | Codice di rifiuto motivo che indica il motivo fornito dal componente per rifiutare l'offerta. Questo valore dipende dal campo Stato. Per un mapping di codice status to RR, vedere Tabella 5.2-13. |
| 8 | Riservato | 24 | Riservato. Non usare. |
Tabella 5.2-13 FIRMWARE_UPDATE_OFFER valori del codice RR della risposta
I valori possibili per il byte di codice RR sono descritti in questa tabella.
| Codice RR | Nome | Descrizione |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | L'offerta è stata rifiutata perché la versione del firmware offerto è precedente o uguale al firmware corrente. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | L'offerta è stata rifiutata perché il firmware offerto non è applicabile alla piattaforma del prodotto. Ciò può essere dovuto a un ID componente non supportato o a un'immagine offerta non è compatibile con l'hardware di sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Il firmware del componente è stato aggiornato, tuttavia uno scambio al nuovo firmware è in sospeso. Nessun'ulteriore elaborazione dell'aggiornamento del firmware può verificarsi fino al completamento dello scambio, in genere tramite una reimpostazione. |
| 0x03 - 0x08 | (Riservato) | Riservato. Non usare. |
| 0x09 - 0xDF | (Riservato) | Riservato. Non usare. |
| 0xE0 - 0xFF | (Specifico del fornitore) | Questi valori vengono usati dai progettisti del protocollo e il significato è specifico del fornitore. |
5.2.2.4 Stato
Tabella 5.2-14 FIRMWARE_UPDATE_OFFER Layout stato risposta
I bit del byte Status sono descritti in questa tabella.
Tabella 5.2-15 FIRMWARE_UPDATE_OFFER Risposta - Bit di stato
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Stato | 8 | Questo valore indica la decisione del componente di accettare, penna, ignorare o rifiutare l'offerta. Il componente fornisce il motivo del valore del campo Codice RR. Per un mapping di codice stato a RR, vedere Tabella 5.2-16. |
| 8 | Riservato | 24 | Riservato. Non usare. |
I valori possibili per il byte Status sono descritti in questa tabella.
Tabella 5.2-16 FIRMWARE_UPDATE_OFFER valori di stato della risposta
| Stato | Nome | Descrizione |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | Il componente ha deciso di ignorare l'offerta. L'host deve offrirlo di nuovo in un secondo momento. |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | Il componente ha deciso di accettare l'offerta. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | Il componente ha deciso di rifiutare l'offerta. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | Il dispositivo è occupato e l'host deve attendere fino a quando il dispositivo è pronto. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Usato quando l'ID componente nei byte di informazioni sui componenti (vedere 5.1.2.1.1 Informazioni sui componenti) è impostato su 0xFE. Per Il codice comando impostato su OFFER_NOTIFY_ON_READY richiesta, indica che l'accessorio è pronto per accettare offerte aggiuntive. |
| 0xff | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | La richiesta di offerta non viene riconosciuta. |
5.2.3 Mapping al protocollo HID
Il messaggio viene rilasciato al componente tramite il meccanismo del report di output HID usando l'ID report dell'utilità HID dedicato per l'aggiornamento del firmware. Il TLC dell'utilità HID da usare descritto nell'appendice.
5.3 FIRMWARE_UPDATE_OFFER - Informazioni
Se l'ID componente nei byte delle informazioni sui componenti (vedere Informazioni componente) è impostato su 0xFF, i bit (15 byte) vengono ridefiniti per indicare Solo informazioni sull'offerta, dall'host al componente. Questo meccanismo consente l'estendibilità e un modo per consentire all'host di fornire informazioni specifiche al dispositivo, ad esempio Start Offer List, End Offer List, Start Entire Transaction. I pacchetti di informazioni dell'offerta vengono sempre accettati immediatamente dal componente.
Comando 5.3.1
Il pacchetto FIRMWARE_UPDATE_OFFER -Information Command è definito come segue:
Tabella 5.3-1 FIRMWARE_UPDATE_OFFER - Layout dei comandi informazioni
Componente 5.3.1.1
Tabella 5.3-2 FIRMWARE_UPDATE_OFFER - Comando informazioni - Layout componente
I bit del byte componente sono descritti in questa tabella.
Tabella 5.3-3 FIRMWARE_UPDATE_OFFER - Comando informazioni - Bit componente
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Codice informativo | 8 | Questo valore indica il tipo di informazioni. Questo valore non è una maschera di bit e può essere solo uno dei valori possibili descritti nella tabella 5.3-4. |
| 8 | Riservato. | 8 | Riservato. Non usare. |
| 16 | ID componente | 8 | Impostare su 0xFF. |
| 24 | token | L'host inserisce un token univoco nel pacchetto dell'offerta al componente. Questo token deve essere restituito dal componente nella risposta dell'offerta. |
Tabella 5.3-4 FIRMWARE_UPDATE_OFFER - Comando informazioni - Valori del codice informativo
| Stato | Nome | Descrizione |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Indica che l'host è nuovo o è stato ricaricato e che l'intera elaborazione dell'offerta è (nuovamente)avviata. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Indica l'inizio dell'elenco di offerte dall'host nel caso in cui l'accessorio abbia regole di download associate a garantire che un sottocomponente venga aggiornato prima di un altro sottocomponente nel sistema. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Indica la fine dell'elenco di offerte dall'host. |
5.3.1.2 Riservato B7 - B4
Riservato. Non usare.
5.3.1.3 Riservato B11 - B8
Riservato. Non usare.
5.3.1.4 Riservato B15 - B12
Riservato. Non usare.
5.3.2 Risposta
La risposta FIRMWARE_UPDATE_OFFER - Offer Information Response viene definita come segue.
Tabella 5.3-5 FIRMWARE_UPDATE_OFFER - Layout di risposta delle informazioni
5.3.2.1 Token
Tabella 5.3-6 FIRMWARE_UPDATE_OFFER- Layout del token di risposta dei pacchetti di informazioni
I bit del byte token sono descritti in questa tabella.
Tabella 5.3-7 FIRMWARE_UPDATE_OFFER - Risposta alle informazioni - Bit di token
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Riservato | 8 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Riservato | 8 | Riservato. Non usare. |
| 24 | token | 8 | Token per identificare l'host |
5.3.2.2 Riservato B7 - B4
Riservato. Non usare.
5.3.2.3 Motivo rifiuto (RR)
Tabella 5.3-8 FIRMWARE_UPDATE_OFFER - Risposta alle informazioni - Layout del codice RR
I bit del byte Reject Reason sono descritti in questa tabella.
Tabella 5.3-9 FIRMWARE_UPDATE_OFFER- Risposta alle informazioni dell'offerta - Bit di codice RR
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Codice RR | 8 | Codice di rifiuto motivo che indica il motivo fornito dal componente per rifiutare l'offerta. I valori possibili sono descritti nella tabella 5.3-10. Questo valore dipende dal campo Stato. |
| 8 | Riservato | 24 | Riservato. Non usare. |
I valori possibili per il byte di codice RR sono descritti in questa tabella.
Tabella 5.3-10 FIRMWARE_UPDATE_OFFER- Risposta alle informazioni - Valori del codice RR
| Codice RR | Nome | Descrizione |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | L'offerta è stata rifiutata perché la versione del firmware offerto è precedente o uguale al firmware corrente. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | L'offerta è stata rifiutata perché il firmware offerto non è applicabile alla piattaforma del prodotto. Ciò può essere dovuto a un ID componente non supportato o a un'immagine offerta non è compatibile con l'hardware di sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Il firmware del componente è stato aggiornato, tuttavia uno scambio al nuovo firmware è in sospeso. Nessun'ulteriore elaborazione dell'aggiornamento del firmware può verificarsi fino al completamento dello scambio, in genere tramite una reimpostazione. |
| 0x03 - 0x08 | (Riservato) | Riservato. Non usare. |
| 0x09 - 0xDF | (Riservato) | Riservato. Non usare. |
| 0xE0 — 0xFF | (Specifico del fornitore) | Questi valori vengono usati dai progettisti del protocollo e il significato è specifico del fornitore. |
5.3.2.4 Stato
Tabella 5.3-11 FIRMWARE_UPDATE_OFFER - Layout dello stato della risposta delle informazioni dell'offerta
I bit del byte Status sono descritti in questa tabella.
Tabella 5.3-12 FIRMWARE_UPDATE_OFFER - Informazioni sull'offerta - Bit di stato della risposta
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Stato | 8 | Questo campo deve essere impostato su FIRMWARE_UPDATE_OFFER_ACCEPT. Ciò indica che il componente ha deciso di accettare l'offerta. |
| 8 | Riservato. | 24 | Riservato. Non usare. |
5.4 FIRMWARE_UPDATE_OFFER - Esteso
Se l'ID componente nei byte di informazioni sui componenti è impostato su 0xFE, i bit (15 byte) vengono ridefiniti per indicare il comando Dell'offerta dall'host al firmware del dispositivo. Questo meccanismo consente l'estendibilità e un modo per l'host di fornire informazioni specifiche al dispositivo. I pacchetti di comandi dell'offerta vengono restituiti quando il componente è pronto per rispondere accettato.
Comando 5.4.1
Se l'ID componente nei byte di informazioni sui componenti è impostato su 0xFE, i quattro DWORD vengono ridefiniti come segue:
Tabella 5.4-1 FIRMWARE_UPDATE_OFFER - Layout dei comandi estesi
Componente 5.4.1.1
Tabella 5.4-2 FIRMWARE_UPDATE_OFFER - Pacchetto di comandi estesi - Comando - Layout componente
I bit del byte componente sono descritti in questa tabella.
Tabella 5.4-3 FIRMWARE_UPDATE_OFFER - Comando esteso - Bit componente
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Codice dei comandi | 8 | Questo valore indica il tipo di comando. Questo valore non è una maschera di bit e può essere solo uno dei valori possibili descritti nella tabella 5.4-4. |
| 8 | Riservato. | 8 | Riservato. Non usare. |
| 16 | ID componente | 8 | Impostare su 0xFE. |
| 24 | token | L'host inserisce un token univoco nel pacchetto dell'offerta a componente. Questo token deve essere restituito dal componente nella risposta dell'offerta. |
Tabella 5.4-4 FIRMWARE_UPDATE_OFFER - Comando esteso - Valori del codice comando
| Stato | Nome | Descrizione |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Inviato dall'host se l'offerta è stata rifiutata in precedenza dal componente. |
| 0x02 - 0xFF | Riservato | Riservato |
5.4.1.2 Riservato B7 - B4
Riservato. Non usare.
5.4.1.3 Riservato B11 - B8
Riservato. Non usare.
5.4.1.4 Riservato B15 - B12
Riservato. Non usare.
5.4.2 Risposta
La FIRMWARE_UPDATE_OFFER - Risposta al comando offerta dal dispositivo potrebbe non essere ricevuta immediatamente. La risposta è definita come segue.
Tabella 5.4-5 FIRMWARE_UPDATE_OFFER - Layout della risposta dei pacchetti di comandi estesi
Token 5.4.2.1
Tabella 5.4-6 FIRMWARE_UPDATE_OFFER- Risposta del pacchetto di comandi offerta - Layout token
I bit del byte token sono descritti in questa tabella.
Tabella 5.4-7 FIRMWARE_UPDATE_OFFER - Risposta al comando dell'offerta - Bit token
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Riservato | 8 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Riservato | 8 | Riservato. Non usare. |
| 24 | token | 8 | Token per identificare l'host. |
5.4.2.2 Riservato B7 - B4
Riservato. Non usare.
5.4.2.3 Rifiutare il motivo
Tabella 5.4-8 FIRMWARE_UPDATE_OFFER - Layout RR dei pacchetti di informazioni
I bit del byte Reject Reason sono descritti in questa tabella.
Tabella 5.4-9 FIRMWARE_UPDATE_OFFER- Risposta al comando dell'offerta - Codice RR
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Codice RR | 8 | Questo valore dipende dal campo Stato. Per i possibili valori di codice RR, vedere Tabella 5.4-10. |
| 8 | Riservato | 24 | Riservato. Non usare. |
I valori possibili per il byte di codice RR sono descritti in questa tabella.
Tabella 5.4-10 FIRMWARE_UPDATE_OFFER- Pacchetto di comandi dell'offerta - Valori del codice RR
| Codice RR | Nome | Descrizione |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | L'offerta è stata rifiutata perché la versione del firmware offerto è precedente o uguale al firmware corrente. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | L'offerta è stata rifiutata perché il firmware offerto non è applicabile alla piattaforma del prodotto. Ciò può essere dovuto a un ID componente non supportato o a un'immagine offerta non è compatibile con l'hardware di sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Il firmware del componente è stato aggiornato, tuttavia uno scambio al nuovo firmware è in sospeso. Nessun'ulteriore elaborazione dell'aggiornamento del firmware può verificarsi fino al completamento dello scambio, in genere tramite una reimpostazione. |
| 0x03 - 0x08 | (Riservato) | Riservato. Non usare. |
| 0x09 - 0xDF | (Riservato) | Riservato. Non usare. |
| 0xE0 — 0xFF | (Specifico del fornitore) | Questi valori vengono usati dai progettisti del protocollo e il significato è specifico del fornitore. |
5.4.2.4 Stato
Tabella 5.4-11 FIRMWARE_UPDATE_OFFER - Layout dello stato della risposta del pacchetto di comandi
I bit del byte Status sono descritti in questa tabella.
Tabella 5.4-12 FIRMWARE_UPDATE_OFFER- Codice RR della risposta del pacchetto di comandi dell'offerta
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Stato | 8 | Questo campo deve essere impostato su FIRMWARE_UPDATE_OFFER_ACCEPT. Ciò indica che il componente ha deciso di accettare l'offerta. |
| 8 | Riservato. | 24 | Riservato. Non usare. |
5,5 FIRMWARE_UPDATE_CONTENT
L'host invia questo comando al firmware del dispositivo per fornire il contenuto del firmware, ovvero l'immagine del firmware. L'intero file di immagine non è previsto adattarsi a un singolo comando. L'host deve suddividere l'immagine in blocchi più piccoli e ogni comando invia un blocco dell'immagine alla volta.
Con ogni comando l'host indica informazioni aggiuntive, ovvero il primo blocco, l'ultimo blocco e così via, del firmware. Il componente primario del firmware del dispositivo accetta ogni blocco dell'immagine del firmware in ingresso, lo archivia nella memoria e deve rispondere singolarmente a ogni comando.
Quando il componente primario riceve l'ultimo blocco, il componente convalida l'intera immagine del firmware (controllo CRC, convalida della firma). In base ai risultati di tali controlli restituisce una risposta appropriata (errore o esito positivo) per l'ultimo blocco.
Comando 5.5.1
Tabella 5.5-1 FIRMWARE_UPDATE_CONTENT Layout dei comandi
5.5.1.1 Intestazione (B7 - B0)
Tabella 5.5-2 FIRMWARE_UPDATE_CONTENT layout intestazione comando
I bit dell'intestazione di FIRMWARE_UPDATE_CONTENT sono descritti in questa tabella.
Tabella 5.5-3 FIRMWARE_UPDATE_CONTENT bit intestazione
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Flags | 8 | Questo campo fornisce informazioni aggiuntive sul comando. Questo valore è una maschera di flag da usare per i trasferimenti di dati. I valori possibili sono descritti nella tabella 5.5-4. |
| 8 | Lunghezza dei dati | 8 | Lunghezza del campo Dati applicabile che indica il numero di byte da scrivere. Dato le dimensioni di questo comando, il valore massimo consentito per la lunghezza è di 52 byte. |
| 16 | Numero sequenza | 16 | Questo valore viene creato dall'host ed è univoco per ogni pacchetto di contenuto rilasciato. Il componente deve restituire il numero di sequenza nella risposta a questa richiesta. |
| 32 | Indirizzo firmware | 32 | Indirizzo di Little Endian (LSB First) per scrivere i dati. L'indirizzo è basato su 0. Il firmware usa questo valore come offset per determinare l'indirizzo in base alle esigenze quando si inserisce l'immagine in memoria. |
I valori possibili per il byte Flags sono descritti in questa tabella.
Tabella 5.5-4 FIRMWARE_UPDATE_OFFER- Pacchetto di comandi dell'offerta - Valori flag
| Contrassegno | Nome | Descrizione |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Questo flag indica che si tratta del primo blocco dell'immagine del firmware. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Questo flag indica che si tratta dell'ultimo blocco dell'immagine del firmware e che l'immagine è pronta per la convalida. È importante che il firmware corrente del componente esegue la convalida sull'intera immagine del firmware scaricato dopo aver scritto questo blocco in memoria non volatile. |
5.5.1.2 Dati
Tabella 5.5-5 FIRMWARE_UPDATE_CONTENT Layout dei dati dei comandi
I bit dei dati FIRMWARE_UPDATE_CONTENT sono descritti in questa tabella.
Tabella 5.5-6 FIRMWARE_UPDATE_CONTENT bit di dati dei comandi
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 64 | Dati | Max 52. | Matrice di byte da scrivere. L'host invia in genere blocchi di 4 byte in base all'architettura del prodotto. Qualsiasi byte inutilizzato alla fine deve essere 0 riempimento. |
Risposta 5.5.2
Tabella 5.5-7 FIRMWARE_UPDATE_CONTENT Layout risposta comando
5.5.2.1 Numero di sequenza
Tabella 5.5-8 FIRMWARE_UPDATE_CONTENT Risposta - Numero di sequenza
I bit della risposta FIRMWARE_UPDATE_CONTENT (3-0) sono descritti in questa tabella.
Tabella 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bit di risposta
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Numero sequenza | 16 | Questo campo è il numero di sequenza inviato dall'host nella richiesta. |
| 16 | Riservato | 16 | Riservato. Non usare. |
5.5.2.2 Stato
Tabella 5.5-10 FIRMWARE_UPDATE_CONTENT layout dello stato della risposta
I bit della FIRMWARE_UPDATE_CONTENT Response (7-4) sono descritti in questa tabella.
Tabella 5.5-11 FIRMWARE_UPDATE_OFFER - Risposta - Bit di stato
| Bit Offset | Campo | Dimensione | Descrizione |
|---|---|---|---|
| 0 | Stato | 8 | Questo valore indica il codice di stato restituito dal componente del dispositivo. Questo non è bit per bit e può essere uno dei valori descritti nella tabella 5.5-12. |
| 8 | Riservato | 24 | Riservato. Non usare. |
I valori possibili per il byte Status sono descritti in questa tabella.
Tabella 5.5-12 FIRMWARE_UPDATE_OFFER- Risposta - Valori del codice di stato
| Contrassegno | Nome | Descrizione |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | La richiesta è stata completata correttamente. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | Il componente non era pronto a ricevere il contenuto del firmware. Se usato, questo codice viene in genere usato in una risposta al primo blocco. Ad esempio, cancellare l'errore in flash. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | La richiesta non è riuscita a scrivere i byte. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | La richiesta non è riuscita a configurare lo scambio in risposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | La verifica della DWORD non è riuscita, in risposta a FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | CRC dell'immagine del firmware non è riuscita in risposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | La verifica della firma del firmware non è riuscita in risposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | La verifica della versione del firmware non è riuscita in risposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | Il firmware è già stato aggiornato e uno scambio è in sospeso. Non è possibile accettare altri comandi di Aggiornamento firmware fino a quando l'accessorio non viene reimpostato. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | Il firmware ha rilevato un indirizzo di destinazione non valido all'interno del contenuto dei dati del messaggio. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | Il comando FIRMWARE_UPDATE_OFFER è stato ricevuto senza prima ricevere un'offerta di aggiornamento firmware valida e accettata. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Errore generale per il comando FIRMWARE_UPDATE_OFFER, ad esempio una lunghezza dati non valida applicabile. |
5.5.2.3 Riservato B8 - B11
Riservato. Non usare.
5.5.2.4 Riservato B12 - B15
Riservato. Non usare.
6 Appendice 1: Sequenza di comando di programmazione dell'aggiornamento del firmware di esempio
6.1 Esempio 1
Considerare il firmware del dispositivo seguente:
Componente primario - ID componente 1 - Firmware corrente versione 7.0.1
Sottocomponente - ID componente 2 - Firmware corrente versione 12.4.54
Sottocomponente - ID componente 3 - Firmware corrente versione 4.4.2
Sottocomponente - ID componente 4 - Firmware corrente versione 23.32.9
L'host ha queste tre immagini del firmware:
ID componente 1 - Firmware versione 7.1.3
ID componente 2 - Firmware versione 12.4.54
ID componente 3 - Firmware versione 4.5.0
La sequenza sarà:
Offerte host: ID componente 1 - Firmware versione 7.1.3
Il componente primario accetta l'offerta
L'host invia l'immagine del firmware
Il componente primario accetta il firmware, lo convalida
Offerte host: ID componente 2 - Firmware versione 12.4.54
Il componente primario rifiuta l'offerta
Offerte host: ID componente 3 - Firmware versione 4.5.0
Il componente primario accetta l'offerta
L'host invia l'immagine del firmware
Il componente primario accetta il firmware, lo convalida
Poiché tutte le offerte non sono state rifiutate, l'host riproduce tutte le offerte:
Offerte host: ID componente 1 - Firmware versione 7.1.3
Rifiuta i componenti
Offerte host: ID componente 2 - Firmware versione 12.4.54
Rifiuta i componenti
Offerte host: ID componente 3 - Firmware versione 4.5.0
Rifiuta i componenti
6.2 Esempio 2
Prendere in considerazione il firmware del dispositivo seguente:
Componente primario - ID componente 1 - Firmware corrente versione 7.0.1
Sottocomponente - ID componente 2 - Firmware corrente versione 12.4.54
Sottocomponente - ID componente 3 - Firmware corrente versione 7.4.2
Sottocomponente - ID componente 4 - Firmware corrente versione 23.32.9
L'host include queste tre immagini del firmware:
ID componente 1 - Versione del firmware 8.0.0
ID componente 2 - Versione del firmware 12.4.54
ID componente 3 - Versione del firmware 9.0.0
Inoltre, l'implementazione richiede che la versione del firmware dei sottocomponenti non sia minore della versione del firmware in esecuzione nel componente primario. L'host non è consapevole di tale requisito ed è aggiornato al componente primario per garantire questa regola.
La sequenza sarà:
Offerte host: ID componente 1 - Versione firmware 8.0.0
Il componente primario rifiuta (perché l'ID componente 3 non è ancora aggiornato)
Offerte host: ID componente 2 - Versione firmware 12.4.54
Il componente primario rifiuta
Offerte host: ID componente 3 - Versione firmware 9.0.0
Componente primario accetta l'offerta
L'host invia l'immagine del firmware
Il componente primario accetta il firmware, convalidandolo
Poiché tutte le offerte non sono state rifiutate, l'host riproduce tutte le offerte
Offerte host: ID componente 1 - Versione firmware 8.0.0
Componente primario accetta l'offerta
L'host invia l'immagine del firmware
Il componente primario accetta il firmware, convalidandolo
Offerte host: ID componente 2 - Versione firmware 12.4.54
Il componente primario rifiuta
Offerte host: ID componente 3 - Versione firmware 9.0.0
Il componente primario rifiuta