Nota
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare ad accedere o a cambiare directory.
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare a cambiare directory.
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 del firmware separate. La specifica consente al componente incaricato 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.
Annotazioni
CFU è disponibile in Windows 10 versione 2004 (Windows 10 maggio 2020 Update) e versioni successive.
Contenuto
- 1 Introduzione
- 2 Architettura hardware supportata
- 3 Prerequisiti del protocollo
-
4 Panoramica del protocollo CFU
-
4.1 Sequenza di comandi di programmazione degli aggiornamenti del firmware
- 4.1.1 Stato: Notifica di Inizializzazione dell'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 della decisione: Lista delle offerte di ripetizione
- 4.1.8 Stato: il dispositivo è occupato
-
4.1 Sequenza di comandi di programmazione degli aggiornamenti del firmware
- 5 Formato di pacchetto del protocollo CFU
- 6 Appendice 1: Sequenza di comando di programmazione dell'aggiornamento del firmware di esempio
Tabelle
Layout di risposta della tabella 5.1-1 GET_FIRMWARE_VERSION
Tabella 5.1-2 Risposta GET_FIRMWARE_VERSION - Layout intestazione
Tabella 5.1-3 Risposta GET_FIRMWARE_VERSION - Bit dell'intestazione
Tabella 5.1-4 GET_FIRMWARE_VERSION Risposta - Layout delle proprietà e della versione del componente
Tabella 5.1-5 GET_FIRMWARE_VERSION Risposta - Versione componente e bit delle proprietà
Tabella 5.2-1 Layout del comando FIRMWARE_UPDATE_OFFER
Tabella 5.2-2 Comando FIRMWARE_UPDATE_OFFER - Layout delle informazioni del componente
Tabella 5.2-3 comando FIRMWARE_UPDATE_OFFER - Bit di informazioni sui componenti
Tabella 5.2-4 comando FIRMWARE_UPDATE_OFFER - Layout della versione del firmware
Tabella 5.2-5 comando FIRMWARE_UPDATE_OFFER - Bit Versione del 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 del token
Tabella 5.2-10 FIRMWARE_UPDATE_OFFER risposta - Bit di token
Tabella 5.2-11 FIRMWARE_UPDATE_OFFER Risposta - Struttura del Motivo di Rifiuto
Tabella 5.2-12 FIRMWARE_UPDATE_OFFER Risposta - Bit per le ragioni di rifiuto
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 informazione - Bit del componente
Tabella 5.3-4 FIRMWARE_UPDATE_OFFER - Comando informazioni - Valori del codice informativo
Tabella 5.3-5 FIRMWARE_UPDATE_OFFER - Layout della risposta informativa
Tabella 5.3-6 FIRMWARE_UPDATE_OFFER- Layout del token di risposta del pacchetto informativo
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 sull'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 comando esteso - Comando - Struttura del componente
Tabella 5.4-3 FIRMWARE_UPDATE_OFFER - Comando esteso - Bit dei componenti
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 comando dell'offerta - Formato token
Tabella 5.4-7 FIRMWARE_UPDATE_OFFER - Risposta del comando offerta - Bit di token
Tabella 5.4-9 FIRMWARE_UPDATE_OFFER- Risposta del comando 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 della risposta del pacchetto di comandi dell'offerta
Tabella 5.5-1 Layout del comando FIRMWARE_UPDATE_CONTENT
Tabella 5.5-2 FIRMWARE_UPDATE_CONTENT Intestazione Comando Layout
Tabella 5.5-3 bit di intestazione FIRMWARE_UPDATE_CONTENT
Tabella 5.5-4 FIRMWARE_UPDATE_OFFER- Pacchetto di comandi dell'offerta - Valori flag
Tabella 5.5-5 Layout dei dati del comando FIRMWARE_UPDATE_CONTENT
Tabella 5.5-6 Bit di dati del comando FIRMWARE_UPDATE_CONTENT
Tabella 5.5-7 layout della risposta del comando FIRMWARE_UPDATE_CONTENT
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 Strategia 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 in 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 esula dall'ambito della specifica.
Alcune delle funzionalità del protocollo sono:
Il protocollo si basa su HID, 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.
Annotazioni
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 tramite un'unica operazione atomica in un momento in cui l'impatto sull'utente è minimo.
La specifica supporta le configurazioni in cui il componente che accetta il firmware potrebbe avere sottocomponenti, che richiedono immagini del firmware separate.
Annotazioni
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 /ready per accettarla.
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 Ciclica 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 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. |
| Pilota | Driver scritto usando il framework Windows Driver Foundation (WDF). |
| Firmware (software di sistema) | Codice in esecuzione sull'hardware fisico. Il firmware è aggiornabile e in genere risiede nella memoria programmabile associata all'hardware. |
| Componenti fisici | Un pezzo fisico di siliconi sul computer. |
| Componente primario | Un pezzo di 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. |
| Segmento | Un'immagine del firmware per un componente può essere segmentata in segmenti più piccoli. Ogni segmento è una piccola immagine del firmware. |
| 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. |
| Componente secondario | A seconda dell'architettura hardware, non tutti i componenti possono essere visibili al sistema operativo, perché possono essere connessi downstream di un componente visibile al sistema. Questi componenti sono detti sottocomponenti in questa specifica. |
| Telecomunicazioni | Raccolta di livello superiore HID. |
| Token di accesso | Identificatore di 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'altra operazione avviata. |
1.2 Ambito
1.2.1 Obiettivi
È necessaria una soluzione indipendente dal bus per evitare un nuovo protocollo per ogni tipo di autobus. HID è onnipresente e soddisfa 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.
Modello di driver comune per il download dell'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 il firmware in fase di sviluppo/firmware già sul mercato.
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 Obiettivi non inclusi
Definire il formato interno dell'immagine del firmware: per l'host, l'immagine del firmware è un set di elementi 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 sul modo in cui il componente interagisce con i sottocomponenti: l'host interagisce con il dispositivo come singola unità, in genere il componente primario. Il componente deve fungere da bridge 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 (dove un dispositivo può contenere uno o più componenti al suo interno). 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 da implementare per sfruttare questo protocollo:
Utilizzo delle immagini atomiche
Un'immagine del firmware per un componente non viene usata finché l'intera immagine del firmware non viene scaricata correttamente. Nel caso in cui il firmware sia suddiviso in più segmenti, l'immagine non deve essere usata finché 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 quali sono i fattori che costituiscono un'autentica immagine del firmware. È consigliabile che il firmware corrente del componente debba almeno convalidare il CRC dell'immagine del firmware in ingresso. Il firmware corrente deve usare anche la firma digitale o altri algoritmi di rilevamento degli errori. Se la convalida non riesce, il firmware rifiuta l'aggiornamento. Ripristino 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ò ritentare l'aggiornamento. La frequenza di ripetizione dei tentativi è specifica dell'implementazione.
Riservatezza
Opzionale. È possibile crittografare un segmento del 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 rispetto 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 presenta 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 comandi di programmazione degli aggiornamenti del firmware
Ecco la sequenza di comandi 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 Stato: Invia comando FIRMWARE_UPDATE_OFFER
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, affinché il firmware corrente sul componente possa decidere se accettare, posticipare, ignorare o rifiutare l'offerta.
L'offerta può essere per il componente primario o il 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 la stessa) che l'host intende inviare. Per altri motivi, vedere gli esempi descritti nell'Appendice 1: Sequenza di comandi di programmazione dell'aggiornamento del firmware di esempio.
Anche se un'offerta viene accettata, il componente primario può comunque rifiutare l'immagine del firmware dopo il download per errori di integrità e/o controlli di rollback rispetto all'immagine effettiva ricevuta. Il componente deve controllare ogni proprietà dell'immagine del firmware indipendentemente da tutte le informazioni nell'offerta.
L'host rilascia 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, lo fa con lo stato FIRMWARE_UPDATE_OFFER_ACCEPT, accettando così l'offerta.
Se il firmware del dispositivo è occupato e se il componente primario non è in grado di accettare questa offerta o l'offerta successiva, invia una risposta occupata con lo 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 accetta l'offerta (ad esempio, se è una versione precedente), risponde con uno stato FIRMWARE_UPDATE_OFFER_REJECT, fornendo il motivo appropriato del rifiuto. Questo stato non indica che l'host non può inviare nuovamente l'offerta in futuro. L'host invia in genere ogni offerta ogni volta che inizializza o invia nuovamente l'elenco delle offerte al dispositivo (vedere State: OFFER_INFO_START_OFFER_LIST Notification).
4.1.4 Stato: Invio 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 supera i limiti di payload di un singolo comando, l'host suddivide le immagini del firmware in pacchetti. L'host invia ogni pacchetto in sequenza in un comando CONTENT FIRMWARE_UPDATE separato. 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 parziale del firmware. Il componente usa l'offset per determinare l'indirizzo in cui deve essere archiviato il payload parziale del firmware. 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 FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, che indica al dispositivo che si tratta del primo pacchetto dell'immagine del firmware. Se il dispositivo non è già pronto a ricevere il firmware, può farlo in questo momento.
Per l'ultimo pacchetto che l'host invia, imposta il flag FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Dopo che il firmware corrente nel dispositivo ha scritto il payload parziale del firmware incluso in questo comando, deve eseguire controlli di convalida e autenticazione sull'immagine del firmware in ingresso prima di inviare una risposta. Questo include almeno:
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 facoltativo, un controllo della versione per assicurarsi che la nuova versione del firmware sia uguale o successiva rispetto al firmware esistente.
Nel caso in cui l'immagine del firmware in ingresso fosse divisa in segmenti più piccoli, spetta al firmware corrente determinare se è l'ultimo segmento dell'immagine del firmware e successivamente includere tutti i segmenti come parte della convalida.
Se i controlli precedenti sono superati, il firmware corrente può configurare il dispositivo per passare alla nuova immagine al successivo ripristino e segnala all'host l'esito positivo. In genere, il componente non avvia una reimpostazione automatica. Ciò consente di evitare interruzioni in qualsiasi software, firmware, entità hardware con cui interagisce il componente. Tuttavia, questo non è un requisito e può variare a seconda dell'implementazione.
Se i passaggi di verifica hanno esito negativo, il firmware non deve configurare uno scambio al successivo ripristino 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: notifica OFFER_INFO_END_OFFER_LIST
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: Lista delle offerte di rigioco
L'host determina se deve inviare nuovamente tutte le offerte. Questo caso può verificarsi se in precedenza il componente primario aveva ignorato alcune offerte e accettato alcune offerte. L'host deve riprodurre nuovamente l'elenco di offerte.
Potrebbe esserci un'altra logica specifica dell'implementazione che può comportare 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 occupata a un'offerta.
L'host invia un comando OFFER_NOTIFY_ON_READY a cui il dispositivo non risponde con l'accettazione fino a quando il dispositivo non è gratuito.
5 Formato di pacchetto del protocollo CFU
Il protocollo CFU viene implementato come set di comandi e risposte. Il protocollo è di natura sequenziale. Per ogni comando inviato dall'host a un componente, si prevede che il componente risponda (a meno che non sia specificato 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 potrebbe riavviare il processo dall'inizio. Questo protocollo non definisce un valore di timeout specifico.
Sono disponibili 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 è obbligato a trattenere un'offerta in base alla risposta ricevuta dal componente primario relative alle informazioni sulla versione richieste. Le informazioni sono rese individuabili per la registrazione o per altri scopi.
5.1 OTTIENI_VERSIONE_FIRMWARE
Ottiene le versioni correnti del firmware del componente primario (e i relativi sottocomponenti). Il comando non ha argomenti.
5.1.1 Comando
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. Quando riceve questo comando, il componente primario risponde con la versione del firmware per se stessa e tutti i sottocomponenti.
5.1.2 Risposta
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 di risposta
5.1.2.1 Intestazione
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 | Misura | 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 rientrare entro i 60 byte consentiti. |
| 8 | Rsvd | 16 | Campi riservati. Il mittente deve impostare questi parametri su 0. Il ricevitore deve ignorare questo valore. |
| 24 | Versione del protocollo | 4 | I bit di revisione dell'aggiornamento del firmware indicano la revisione del protocollo di aggiornamento del firmware attualmente utilizzato nel trasporto. Per l'interfaccia definita in questo documento, la revisione dell'aggiornamento FW deve essere 0010b. |
| 28 | Rsvd | 3 | Campi riservati. Il mittente deve impostare questi valori 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 Versione e proprietà del componente
Per ogni componente vengono usati due DWORD per descrivere le proprietà del componente fino a 7 componenti. Se il numero di componenti nell'intestazione è minore di 7, la DWORDS inutilizzata alla fine della risposta deve essere impostata su 0.
Tabella 5.1-4 Risposta GET_FIRMWARE_VERSION - Versione del componente e layout delle proprietà
Ogni informazione specifica del componente è descritta in due DWORD come indicato di seguito:
Tabella 5.1-5 Risposta GET_FIRMWARE_VERSION - Versione del componente e bit delle proprietà
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Versione del firmware | 32 | Restituisce la versione del firmware corrente per il 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 | Opzionale. A seconda dell'architettura, l'hardware del componente può avere più banche in cui è possibile archiviare 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, tuttavia non deve essere usato per altri scopi. |
| 34 | Riservato | 2 | Campi riservati. Il mittente deve impostare questi valori su 0. Il ricevitore deve ignorare questo valore. |
| 36 | Specifico 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 come: - 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 | Specifico del fornitore | 16 | Campo specifico del fornitore che può essere usato in modo specifico per l'implementazione. |
5.1.3 Mapping su HID
Questa operazione viene implementata come richiesta di HID Get Feature con una dimensione di risposta pari a 60 byte, oltre all'ID report. La lunghezza del report delle caratteristiche racchiude l'intera risposta GET_FIRMWARE_VERSION. Non sono presenti dati associati alla richiesta Ottieni funzionalità dall'host.
5.2 OFFERTA_AGGIORNAMENTO_FIRMWARE
Determina se il componente primario accetta o rifiuta un firmware.
5.2.1 Comando
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 sul componente
I bit del byte Informazioni componente sono descritti in questa tabella.
Tabella 5.2-3 comando FIRMWARE_UPDATE_OFFER - Bit di informazioni sui componenti
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Numero di 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 di payload successivo. Ad esempio, se l'immagine del firmware per il componente è molto grande e il componente primario può prendere 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 impostare questi valori su 0. Il ricevitore deve ignorare questo valore. |
| 14 | I | 1 | Forza Ripristino Immediato (I) - Questo valore di bit viene usato per indicare al componente di reimpostare immediatamente se stesso 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 a un'immagine firmware in fase di sviluppo 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 multi-componente. 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 valori possibili degli ID componente sono i seguenti: 1 - 0xDF: valido 0xE0 - 0xFD: riservato. Non usare. 0xFF: l'offerta è un pacchetto di informazioni sull'offerta speciale. Consultare le informazioni su FIRMWARE_UPDATE_OFFER per i dettagli. 0xFE: l'offerta è un pacchetto di comandi di offerta speciale. Per informazioni dettagliate, vedere la sezione estesa di FIRMWARE_UPDATE_OFFER. |
| 24 | Token di accesso | 8 | L'host inserisce un token univoco nel pacchetto dell'offerta per il 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 gestire multipli 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. |
5.2.1.2 Versione firmware
Questi quattro byte rappresentano la versione a 32 bit del firmware. Il formato per la versione del firmware non è obbligatorio da questa specifica. È consigliabile seguire questa procedura.
Tabella 5.2-4 comando FIRMWARE_UPDATE_OFFER - Layout della versione del 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 | Misura | Descrizione |
|---|---|---|---|
| 0 | Variante | 8 | Questo campo può essere descritto per distinguere tra un firmware non rilasciato e un firmware di produzione. Può indicare il tipo di firma usato per firmare il firmware. |
| 8 | Versione minore | 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 Specifico del fornitore
Questi quattro byte possono essere usati per codificare tutte le informazioni personalizzate nell'offerta specifica per l'implementazione del fornitore.
5.2.1.4 Misc. e Versione protocollo
Questi quattro byte possono essere usati per codificare tutte le informazioni personalizzate 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 | Misura | 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 | Specifico del fornitore | 16 | Questo campo può essere usato per codificare tutte le informazioni personalizzate nell'offerta specifiche per l'implementazione del fornitore. |
5.2.2 Risposta
Il pacchetto di risposta FIRMWARE_UPDATE_OFFER è definito come segue.
Tabella 5.2-8 Layout del token di risposta FIRMWARE_UPDATE_OFFER
5.2.2.1 Token
Tabella 5.2-9 FIRMWARE_UPDATE_OFFER RISPOSTA - Layout del token
I bit del byte token sono descritti in questa tabella.
Tabella 5.2-10 Risposta FIRMWARE_UPDATE_OFFER - Bit di Token
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Riservato | 8 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Riservato | 8 | Riservato. Non usare. |
| 24 | Token di accesso | 8 | Token per identificare l'host. |
5.2.2.2 Riservato (B7 - B4)
Riservato. Non usare.
5.2.2.3 Motivo del rifiuto (RR)
Tabella 5.2-11 FIRMWARE_UPDATE_OFFER Risposta - Motivo del rifiuto del layout
Tabella 5.2-12 FIRMWARE_UPDATE_OFFER risposta - Bit di Motivo di Rifiuto
I bit del byte Reject Reason sono descritti in questa tabella.
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Codice RR | 8 | Codice motivo rifiuto che indica il motivo fornito dal componente per rifiutare l'offerta. Questo valore dipende dal campo Stato. Per una mappatura dello stato al codice RR, vedere la Tabella 5.2-13. |
| 8 | Riservato | 24 | Riservato. Non usare. |
Tabella 5.2-13 Valori del codice RR di risposta FIRMWARE_UPDATE_OFFER
I valori possibili per il byte di codice RR sono descritti in questa tabella.
| Codice RR | Nome | Descrizione |
|---|---|---|
| 0x00 | FIRMWARE_OFFERTA_RIFIUTA_VECCHIO_FW | L'offerta è stata rifiutata perché la versione del firmware offerto è precedente o uguale al firmware corrente. |
| 0x01 | OFFERTA_FIRMWARE_RIFIUTATA_COMPONENTE_INV | 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 | OFFERTA_AGGIORNAMENTO_FIRMWARE SCAMBIO_IN_ATTESA | Il firmware del componente è stato aggiornato, tuttavia uno scambio al nuovo firmware è in sospeso. L'elaborazione dell'aggiornamento del firmware non può essere eseguita fino al completamento dello scambio, di norma mediante un riavvio. |
| 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 Layout dello Stato della Risposta FIRMWARE_UPDATE_OFFER
I bit del byte Status sono descritti in questa tabella.
Tabella 5.2-15 FIRMWARE_UPDATE_OFFER Risposta - Bit di stato
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | stato | 8 | Questo valore indica la decisione del componente di accettare, tenere in sospeso, ignorare o rifiutare l'offerta. Il componente fornisce il motivo per cui è presente il valore nel campo Codice RR. Per la mappatura da stato a codice RR, vedere la 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 | SALTA OFFERTA AGGIORNAMENTO FIRMWARE | Il componente ha deciso di ignorare l'offerta. L'host deve offrirlo di nuovo in un secondo momento. |
| 0x01 | ACCETTA_OFFERTA_AGGIORNAMENTO_FIRMWARE | Il componente ha deciso di accettare l'offerta. |
| 0x02 | RIFIUTO_OFFERTA_AGGIORNAMENTO_FIRMWARE | Il componente ha deciso di rifiutare l'offerta. |
| 0x03 | OFFERTA_DI_AGGIORNAMENTO_DEL_FIRMWARE_OCCUPATO | Il dispositivo è occupato e l'host deve attendere che il dispositivo sia pronto. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Viene utilizzato quando l'ID componente nei byte delle informazioni sui componenti (vedere 5.1.2.1.1 Component Information) è impostato su 0xFE. Per la richiesta di Command Code impostato su OFFER_NOTIFY_ON_READY, 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 inviato al componente tramite il meccanismo del report di output HID, utilizzando l'ID del report dell'utilità HID dedicato per l'aggiornamento del firmware. La TLC dell'utilità HID da utilizzare è descritta nell'Appendice.
5.3 FIRMWARE_UPDATE_OFFER - Informazioni
Se l'ID componente nei byte di Informazioni componente (vedere Informazioni componente) è impostato su 0xFF, i bit (15 ottetti) vengono ridefiniti per trasmettere solo informazioni sull'offerta dall'host al componente. Questo meccanismo consente l'estensibilità e permette all'host di fornire informazioni specifiche al dispositivo, come Start Offer List, End Offer List, Start Entire Transaction. I pacchetti di informazioni dell'offerta vengono sempre immediatamente accettati dal componente.
5.3.1 Comando
Il pacchetto di comando FIRMWARE_UPDATE_OFFER -Information è definito come segue:
Tabella 5.3-1 FIRMWARE_UPDATE_OFFER - Layout del comando di informazioni
Componente 5.3.1.1
Tabella 5.3-2 FIRMWARE_UPDATE_OFFER - Comando Informazioni - Layout Componente
I bit del byte component sono descritti in questa tabella.
Tabella 5.3-3 FIRMWARE_UPDATE_OFFER - Comando di Informazione - Bit componente
| Bit Offset | Campo | Misura | 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 di accesso | L'host inserisce un token univoco nel pacchetto dell'offerta per il 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 | INFORMAZIONI_OFFERTA_INIZIO_INTERA_TRANSAZIONE | Indica che l'host è nuovo o è stato ricaricato e che l'intera elaborazione dell'offerta è (ri)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 alla verifica che un sottocomponente venga aggiornato prima di un altro sottocomponente nel sistema. |
| 0x02 | FINE_ELENCO_OFFERTE | 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 è definita come segue.
Tabella 5.3-5 FIRMWARE_UPDATE_OFFER - Disposizione delle informazioni di risposta
5.3.2.1 Token
Tabella 5.3-6 FIRMWARE_UPDATE_OFFER- Layout del token di risposta del pacchetto informativo
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 | Misura | Descrizione |
|---|---|---|---|
| 0 | Riservato | 8 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Riservato | 8 | Riservato. Non usare. |
| 24 | Token di accesso | 8 | Token per identificare l'host |
5.3.2.2 Riservato B7 - B4
Riservato. Non usare.
5.3.2.3 Motivo di 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 sull'offerta - Bit di codice RR
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Codice RR | 8 | Codice motivo rifiuto 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_OFFERTA_RIFIUTA_VECCHIO_FW | L'offerta è stata rifiutata perché la versione del firmware offerto è precedente o uguale al firmware corrente. |
| 0x01 | OFFERTA_FIRMWARE_RIFIUTATA_COMPONENTE_INV | 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 | OFFERTA_AGGIORNAMENTO_FIRMWARE SCAMBIO_IN_ATTESA | Il firmware del componente è stato aggiornato, tuttavia uno scambio al nuovo firmware è in sospeso. L'elaborazione dell'aggiornamento del firmware non può essere eseguita fino al completamento dello scambio, di norma mediante un riavvio. |
| 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 OFFERTA_AGGIORNAMENTO_FIRMWARE - Stato della Risposta Informazioni sull'Offerta Layout
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 | Misura | 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 del componente nei byte di informazioni componente è impostato su 0xFE, allora i 15 byte vengono riassegnati per indicare il comando di offerta dall'host al firmware del dispositivo. Questo meccanismo consente l'estendibilità e un modo per consentire all'host di fornire informazioni specifiche al dispositivo. I pacchetti di comandi dell'offerta vengono restituiti quando il componente è pronto a rispondere con lo stato "Accettato".
5.4.1 Comando
Se l'ID componente nei byte di informazioni sui componenti è impostato su 0xFE, i quattro DWORD vengono ridefiniti nel modo seguente:
Tabella 5.4-1 FIRMWARE_UPDATE_OFFER - Layout dei comandi esteso
Componente 5.4.1.1
Tabella 5.4-2 FIRMWARE_UPDATE_OFFER - Pacchetto comando esteso - Comando - Disposizione componenti
I bit del byte component sono descritti in questa tabella.
Tabella 5.4-3 FIRMWARE_UPDATE_OFFER - Comando esteso - Bit del componente
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Codice del comando | 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 di accesso | L'host inserisce un token univoco nel pacchetto dell'offerta per il componente. Questo token deve essere restituito dal componente nella risposta dell'offerta. |
Tabella 5.4-4 FIRMWARE_UPDATE_OFFER - Comando esteso - Valori del codice del 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 risposta al comando FIRMWARE_UPDATE_OFFER - Offer Command proveniente dal dispositivo potrebbe non essere ricevuta immediatamente. La risposta viene definita come segue.
Tabella 5.4-5 FIRMWARE_UPDATE_OFFER - Layout della risposta dei pacchetti di comandi estesi
5.4.2.1 Token
Tabella 5.4-6 FIRMWARE_UPDATE_OFFER - Pacchetto di comandi dell'offerta - Layout del token di risposta
I bit del byte token sono descritti in questa tabella.
Tabella 5.4-7 FIRMWARE_UPDATE_OFFER - Risposta del Comando Offerta - Bit del Token
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Riservato | 8 | Riservato. Non usare. |
| 8 | Riservato | 8 | Riservato. Non usare. |
| 16 | Riservato | 8 | Riservato. Non usare. |
| 24 | Token di accesso | 8 | Token per identificare l'host. |
5.4.2.2 Riservato B7 - B4
Riservato. Non usare.
5.4.2.3 Motivo del rifiuto
Tabella 5.4-8 FIRMWARE_UPDATE_OFFER - Pacchetto informativo dell'offerta, Layout RR della risposta
I bit del byte Reject Reason sono descritti in questa tabella.
Tabella 5.4-9 FIRMWARE_UPDATE_OFFER- Risposta al comando di offerta - Codice RR
| Bit Offset | Campo | Misura | 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_OFFERTA_RIFIUTA_VECCHIO_FW | L'offerta è stata rifiutata perché la versione del firmware offerto è precedente o uguale al firmware corrente. |
| 0x01 | OFFERTA_FIRMWARE_RIFIUTATA_COMPONENTE_INV | 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 | OFFERTA_AGGIORNAMENTO_FIRMWARE SCAMBIO_IN_ATTESA | Il firmware del componente è stato aggiornato, tuttavia uno scambio al nuovo firmware è in sospeso. L'elaborazione dell'aggiornamento del firmware non può essere eseguita fino al completamento dello scambio, di norma mediante un riavvio. |
| 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 di risposta dell'offerta 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 | Misura | 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 CONTENUTO_AGGIORNAMENTO_FIRMWARE
L'host invia questo comando al firmware del dispositivo per fornire il contenuto del firmware, ovvero l'immagine del firmware. Non è previsto che l'intero file di immagine si adatti 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 principale del firmware del dispositivo accetta ogni blocco dell'immagine del firmware in ingresso, lo archivia nella memoria e deve rispondere a ogni comando singolarmente.
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 questi controlli, restituisce una risposta appropriata (errore o esito positivo) per l'ultimo blocco.
5.5.1 Comando
Tabella 5.5-1 Struttura del Comando FIRMWARE_UPDATE_CONTENT
5.5.1.1 Intestazione (B7 - B0)
Tabella 5.5-2 Schema dell’intestazione del comando FIRMWARE_UPDATE_CONTENT
I bit dell'intestazione FIRMWARE_UPDATE_CONTENT sono descritti in questa tabella.
Tabella 5.5-3 bit di intestazione FIRMWARE_UPDATE_CONTENT
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 0 | Bandiere | 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 dati | 8 | Lunghezza del campo Dati applicabile che indica il numero di byte da scrivere. Data la dimensione di questo comando, il valore massimo consentito per la lunghezza è di 52 byte. |
| 16 | Numero di sequenza | 16 | Questo valore viene creato dall'host ed è univoco per ogni pacchetto di contenuto emesso. Il componente deve restituire il numero di sequenza nella risposta a questa richiesta. |
| 32 | Indirizzo firmware | 32 | Indirizzo Little Endian (LSB First) utilizzato per scrivere i dati. L'indirizzo usa un indice che inizia da 0. Il firmware lo usa come offset per determinare l'indirizzo in base alle esigenze durante l'inserimento dell'immagine in memoria. |
I valori possibili per il byte Flags sono descritti in questa tabella.
Tabella 5.5-4 FIRMWARE_UPDATE_OFFER - Pacchetto di comando dell'offerta - Valori del flag
| Bandiera | Nome | Descrizione |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_PRIMO_BLOCCO | 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 nel componente esegua la convalida sull'intera immagine del firmware scaricata dopo aver scritto questo blocco in memoria non volatile. |
5.5.1.2 Dati
Tabella 5.5-5 Struttura dei dati del comando FIRMWARE_UPDATE_CONTENT
I bit dei dati FIRMWARE_UPDATE_CONTENT sono descritti in questa tabella.
Tabella 5.5-6 bit di dati del comando FIRMWARE_UPDATE_CONTENT
| Bit Offset | Campo | Misura | Descrizione |
|---|---|---|---|
| 64 | Dati | Massimo 52. | La 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 riempito con 0. |
5.5.2 Risposta
Tabella 5.5-7 FIRMWARE_UPDATE_CONTENT layout della risposta al comando
5.5.2.1 Numero di sequenza
Tabella 5.5-8 FIRMWARE_UPDATE_CONTENT Risposta - Numero di sequenza
I bit del messaggio di 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 | Misura | Descrizione |
|---|---|---|---|
| 0 | Numero di 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 stato risposta
I bit della risposta FIRMWARE_UPDATE_CONTENT (7-4) sono descritti in questa tabella.
Tabella 5.5-11 FIRMWARE_UPDATE_OFFER - Risposta - Bit di stato
| Bit Offset | Campo | Misura | 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
| Bandiera | Nome | Descrizione |
|---|---|---|
| 0x00 | AGGIORNAMENTO_FIRMWARE_COMPLETATO | La richiesta è stata completata correttamente. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | Il componente non è stato preparato per 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 | ERRORE_AGGIORNAMENTO_FIRMWARE_VERIFICA | La verifica del DWORD non è riuscita, in risposta a FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | Errore di aggiornamento del firmware 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 del firmware fino a quando l'accessorio non viene reimpostato. |
| 0x09 | Errore aggiornamento firmware: indirizzo non valido (FIRMWARE_UPDATE_ERROR_INVALID_ADDR) | Il firmware ha rilevato un indirizzo di destinazione non valido all'interno del contenuto dei dati del messaggio. |
| 0x0A | ERRORE_AGGIORNAMENTO_FIRMWARE_NESSUNA_OFFERTA | Il comando FIRMWARE_UPDATE_OFFER è stato ricevuto senza prima ricevere un'offerta di aggiornamento del firmware valida e accettata. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Errore generale per il comando FIRMWARE_UPDATE_OFFER, ad esempio una lunghezza dati applicabile non valida. |
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
Prendere in considerazione il firmware del dispositivo seguente:
Componente primario - ID componente 1 - Firmware corrente versione 7.0.1
Sottocomponente - ID componente 2 - Versione firmware attuale 12.4.54
Sottocomponente - ID componente 3 - Versione corrente del firmware 4.4.2
Sottocomponente - ID componente 4 - Versione firmware corrente 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 - versione firmware 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
Offerta 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 dall'host: ID componente 1 - Firmware versione 7.1.3
Rifiuta il componente
Offerte host: ID componente 2 - Versione firmware 12.4.54
Rifiuti di componenti
Offerte dell'host: ID componente 3 - Firmware versione 4.5.0
Componenti rifiutati
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 - Versione firmware attuale 12.4.54
Sottocomponente - ID componente 3 - Firmware corrente versione 7.4.2
Sottocomponente - ID componente 4 - Versione firmware attuale 23.32.9
L'host ha queste tre immagini del firmware:
ID componente 1 - Firmware versione 8.0.0
ID componente 2 - Firmware versione 12.4.54
ID componente 3 - Firmware versione 9.0.0
Inoltre, l'implementazione richiede che la versione del firmware dei sottocomponenti non sia inferiore alla versione del firmware in esecuzione nel componente primario. L'host non è a conoscenza di tale requisito ed è up-to il componente principale per garantire questa regola.
La sequenza sarà:
Offerte dell'host: ID del componente 1 - Versione del firmware 8.0.0
Rifiuto del componente principale (poiché l'ID del componente 3 non è ancora aggiornato)
Offerte host: ID componente 2 - Firmware versione 12.4.54
Il componente primario rifiuta
Offerte host: ID del componente 3 - Firmware versione 9.0.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
Il server offre: ID del componente 1 - Versione firmware 8.0.0
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
Offerte host: ID del componente 3 - Versione del firmware 9.0.0
Il componente primario rifiuta