Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Diese Spezifikation beschreibt ein generisches HID-Protokoll zum Aktualisieren der Firmware für Komponenten, die auf einem PC oder Zubehör vorhanden sind. Die Spezifikation ermöglicht es einer Komponente, Firmware zu akzeptieren, ohne den Gerätebetrieb während eines Downloads zu unterbrechen. Die Spezifikation unterstützt Konfigurationen, bei denen die Komponente, die die Firmware akzeptiert, möglicherweise Unterkomponenten aufweist, die separate Firmwareimages erfordern. Die Spezifikation ermöglicht es den verantwortlichen Komponenten, zu entscheiden, ob die Firmware akzeptiert werden soll. Es fungiert auch als Optimierung, da das Firmwareimage nur dann an die Komponente gesendet wird, wenn es akzeptiert werden kann oder bereit ist.
Hinweis
CFU ist in Windows 10 Version 2004 (Windows 10 Update vom Mai 2020) und höheren Versionen verfügbar.
Inhalte
- 1 Einführung
- 2 Unterstützte Hardwarearchitektur
- 3 Protokollvoraussetzungen
-
4 Übersicht über das CFU-Protokoll
-
4.1 Befehlssequenz für die Programmierung des Firmwareupdates
- 4.1.1 Zustand: Host initialisierte Benachrichtigung
- 4.1.2 Status: OFFER_INFO_START_OFFER_LIST Benachrichtigung
- 4.1.3 Status: Befehl FIRMWARE_UPDATE_OFFER senden
- 4.1.4 Zustand: Firmware senden
- 4.1.5 Entscheidungszustand: Gibt es weitere Angebote?
- 4.1.6 Status: OFFER_INFO_END_OFFER_LIST Benachrichtigung
- 4.1.7 Entscheidungsstatus: Wiedergabeangebotsliste
- 4.1.8 Zustand: Gerät ist ausgelastet
-
4.1 Befehlssequenz für die Programmierung des Firmwareupdates
- 5 CFU-Protokollpaketformat
- 6 Anhang 1: Beispielbefehlssequenz für die Programmierung von Firmwareupdates
Tabellen
Tabelle 5.1-1 GET_FIRMWARE_VERSION Antwortlayout
Tabelle 5.1-2 GET_FIRMWARE_VERSION Antwort – Headerlayout
Tabelle 5.1-3 GET_FIRMWARE_VERSION Antwort – Headerbits
Tabelle 5.1-4 GET_FIRMWARE_VERSION Antwort – Komponentenversions- und Eigenschaftenlayout
Tabelle 5.1-5 GET_FIRMWARE_VERSION Response – Komponentenversion und Eigenschaften Bites
FIRMWARE_UPDATE_OFFER Befehlslayout in Tabelle 5.2-1
Tabelle 5.2-2 FIRMWARE_UPDATE_OFFER-Befehl – Komponenteninformationslayout
Tabelle 5.2-3 FIRMWARE_UPDATE_OFFER-Befehl – Komponenteninformationsbits
Tabelle 5.2-4 FIRMWARE_UPDATE_OFFER Befehl – Layout der Firmwareversion
Tabelle 5.2-5 FIRMWARE_UPDATE_OFFER Befehl – Firmwareversionsbits
Tabelle 5.2-6 FIRMWARE_UPDATE_OFFER-Befehl – herstellerspezifisches Layout
Tabelle 5.2-7 FIRMWARE_UPDATE_OFFER Befehl – Andere Und Protokollversion
Tabelle 5.2-8 FIRMWARE_UPDATE_OFFER Antworttokenlayout
Tabelle 5.2-9 FIRMWARE_UPDATE_OFFER Antwort – Tokenlayout
Tabelle 5.2-10 FIRMWARE_UPDATE_OFFER-Antwort – Tokenbits
Tabelle 5.2-11 FIRMWARE_UPDATE_OFFER Antwort – Grundlayout ablehnen
Tabelle 5.2-12 FIRMWARE_UPDATE_OFFER Antwort – Ablehnung von Grundbits
Tabelle 5.2-13 FIRMWARE_UPDATE_OFFER Antwort-RR-Codewerte
Tabelle 5.2-14 FIRMWARE_UPDATE_OFFER Antwortstatuslayout
Tabelle 5.2-15 FIRMWARE_UPDATE_OFFER Antwort – Statusbits
Tabelle 5.2-16 FIRMWARE_UPDATE_OFFER Antwortstatuswerte
Tabelle 5.3-1 FIRMWARE_UPDATE_OFFER : Layout des Befehls "Information"
Tabelle 5.3-2 FIRMWARE_UPDATE_OFFER – Informationsbefehl – Komponentenlayout
Tabelle 5.3-3 FIRMWARE_UPDATE_OFFER – Informationsbefehl – Komponentenbits
Tabelle 5.3-4 FIRMWARE_UPDATE_OFFER – Information Command – Information Code Values
Tabelle 5.3-5 FIRMWARE_UPDATE_OFFER – Informationsantwortlayout
Tabelle 5.3-6 FIRMWARE_UPDATE_OFFER: Layout des Informationspaket-Antworttokens
Tabelle 5.3-7 FIRMWARE_UPDATE_OFFER – Informationsantwort – Tokenbits
Tabelle 5.3-8 FIRMWARE_UPDATE_OFFER – Informationsantwort – RR-Codelayout
Tabelle 5.3-9 FIRMWARE_UPDATE_OFFER: Antwort auf Angebotsinformationen – RR-Codebits
Tabelle 5.3-10 FIRMWARE_UPDATE_OFFER- Informationsantwort – RR-Codewerte
Tabelle 5.3-11 FIRMWARE_UPDATE_OFFER : Layout des Status der Angebotsinformationsantwort
Tabelle 5.3-12 FIRMWARE_UPDATE_OFFER – Angebotsinformationen – Antwortstatusbits
Tabelle 5.4-1 FIRMWARE_UPDATE_OFFER: Erweitertes Befehlslayout
Tabelle 5.4-2 FIRMWARE_UPDATE_OFFER : Erweitertes Befehlspaket – Befehl – Komponentenlayout
Tabelle 5.4-3 FIRMWARE_UPDATE_OFFER – Erweiterter Befehl – Komponentenbits
Tabelle 5.4-4 FIRMWARE_UPDATE_OFFER : Erweiterter Befehl – Befehlscodewerte
Tabelle 5.4-5 FIRMWARE_UPDATE_OFFER: Layout der erweiterten Befehlspaketantwort
Tabelle 5.4-6 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaketantwort – Tokenlayout
Tabelle 5.4-7 FIRMWARE_UPDATE_OFFER : Angebotsbefehlsantwort – Tokenbits
Tabelle 5.4-8 FIRMWARE_UPDATE_OFFER : RR-Layout der Angebotsinformationspaketantwort
Tabelle 5.4-9 FIRMWARE_UPDATE_OFFER: Angebotsbefehlsantwort – RR-Code
Tabelle 5.4-10 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaket – RR-Codewerte
Tabelle 5.4-11 FIRMWARE_UPDATE_OFFER : Layout des Paketantwortstatus des Angebotsbefehls
Tabelle 5.4-12 FIRMWARE_UPDATE_OFFER: RR-Code für Angebotsbefehlspaketantwort
Tabelle 5.5-1 FIRMWARE_UPDATE_CONTENT Befehlslayout
Tabelle 5.5-2 FIRMWARE_UPDATE_CONTENT Befehlsheaderlayout
Tabelle 5.5-3 FIRMWARE_UPDATE_CONTENT Headerbits
Tabelle 5.5-4 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaket – Flagwerte
Tabelle 5.5-5 FIRMWARE_UPDATE_CONTENT Befehlsdatenlayout
Tabelle 5.5-6 FIRMWARE_UPDATE_CONTENT Befehlsdatenbits
Tabelle 5.5-7 FIRMWARE_UPDATE_CONTENT Befehlsantwortlayout
Tabelle 5.5-8 FIRMWARE_UPDATE_CONTENT Antwort – Sequenznummer
Tabelle 5.5-9 FIRMWARE_UPDATE_CONTENT – Befehl – Antwortbits
Tabelle 5.5-10 FIRMWARE_UPDATE_CONTENT Antwortstatuslayout
Tabelle 5.5-11 FIRMWARE_UPDATE_OFFER – Antwort – Statusbits
Tabelle 5.5-12 FIRMWARE_UPDATE_OFFER: Antwort – Statuscodewerte
1 Einführung
Heutige PCs und Zubehör verfügen über interne Komponenten, die komplexe Vorgänge ausführen. Um ein Qualitätsprodukt sicherzustellen, müssen Sie das Verhalten dieser Geräte in späteren Entwicklungsphasen oder nach der Auslieferung an die Kunden häufig aktualisieren. Das Update kann identifizierte Funktions- oder Sicherheitsprobleme beheben oder neue Features hinzufügen. Ein großer Teil der komplexen Logik befindet sich in der Auf dem Gerät ausgeführten Firmware, die aktualisierbar ist.
Diese Spezifikation beschreibt ein generisches HID-Protokoll zum Aktualisieren der Firmware für Komponenten, die auf einem PC oder dessen Zubehör vorhanden sind. Die HID-Implementierung geht über den Rahmen der Spezifikation hinaus.
Einige der Features des Protokolls sind:
Das Protokoll basiert auf HID – ubiquitous und verfügt über Windows-In-Box-Unterstützung über verschiedene Verbindungsbusse wie USB undI2C. Daher kann dieselbe Softwarelösung (Treiber) verwendet werden, um die Firmware für alle Komponenten zu aktualisieren.
Hinweis
Da die Spezifikation paketbasiert ist, ist es einfach, sie an Nicht-HID-Szenarien anzupassen.
Die Spezifikation ermöglicht es einer Komponente, Firmware zu akzeptieren, ohne den Gerätevorgang während des Downloads zu unterbrechen. Es ermöglicht eine bessere Erfahrung für Benutzer, da sie nicht warten müssen, bis der Firmwareupdatevorgang abgeschlossen ist, bevor sie andere Aufgaben fortsetzen können. Die neue Firmware kann in einem einzelnen atomaren Vorgang zu einem Zeitpunkt aufgerufen werden, der nur minimale Auswirkungen auf den Benutzer hat.
Die Spezifikation unterstützt Konfigurationen, bei denen die Komponente, die die Firmware akzeptiert, möglicherweise Unterkomponenten aufweist, die separate Firmwareimages erfordern.
Hinweis
Der Prozess, bei dem eine Komponente die Firmware an die Unterkomponente übergibt, liegt außerhalb des Geltungsbereichs dieser Spezifikation.
Die Spezifikation unterstützt das Konzept eines Angebots und basiert auf der zuständigen Komponente, um zu entscheiden, ob die Firmware akzeptiert werden soll. Die Entscheidung, neue Firmware zu akzeptieren, ist nicht trivial. Es kann Abhängigkeiten zwischen dem Firmwaretyp und/oder der Version und dem zugrunde liegenden Hardwaretyp bzw. der zugrunde liegenden Hardwareversion geben, auf die die neue Firmware angewendet wird. Ein Angebot fungiert auch als Optimierungsmechanismus, da das Firmwareimage nur dann an die Komponente gesendet wird, wenn es akzeptiert werden kann.
1.1 Glossar
| Begriff | BESCHREIBUNG |
|---|---|
| Komponenten-ID | Auf einem Gerät mit mehreren Komponenten identifiziert eine Komponenten-ID jede Komponente eindeutig. |
| CRC | Zyklische Redundanzprüfung Ein nicht kryptografischer Hashingalgorithmus, der verwendet wird, um einen Digest oder Fingerabdruck eines Datenblocks zu erstellen. Der CRC wird als Überprüfung verwendet, um sicherzustellen, dass sich der Datenblock seit der Berechnung des CRC nicht geändert hat. Der CRC ist nicht unfehlbar, bietet aber die Gewissheit, dass die Daten ordnungsgemäß empfangen wurden. |
| Sicherungsmedium | Eine Auflistung von Komponenten (eine primäre Komponente und null oder mehr Unterkomponenten). Das Gerät ist für das Betriebssystem als einzelne Einheit sichtbar. Der Host interagiert mit dem Gerät, das in der Regel die primäre Komponente ist. Ein Computer kann mehrere Geräte enthalten. In Bezug auf diese Spezifikation ist die Kommunikation mit 2 verschiedenen Geräten völlig unabhängig. |
| Treiber | Ein Treiber, der mit dem WDF-Framework (Windows Driver Foundation) geschrieben wird. |
| Firmware | Der Code, der auf der physischen Hardware ausgeführt wird. Die Firmware ist aktualisierbar und befindet sich in der Regel im programmierbaren Speicher, der der Hardware zugeordnet ist. |
| Hardware | Ein physisches Stück Silizium auf dem Computer. |
| Primäre Komponente | Ein Stück Hardware auf einem Computer und die Firmware dafür. Im Kontext dieser Spezifikation ist eine Komponente die Entität, die das Firmwareupdate benötigt und akzeptiert. |
| Segment | Ein Firmwareimage für eine Komponente kann in kleinere Segmente unterteilt werden. Jedes Segment ist ein kleines Firmwareimage. |
| Segment-ID | Wenn eine Firmware einer Komponente in kleinere Segmente unterteilt ist, ist die Segment-ID der eindeutige Bezeichner für das Segment. |
| Signatur | Eine kryptografische Methode, um festzustellen, ob das Firmwareimage nicht autorisiert geändert wurde. Signaturen sind optional, aber empfohlen und gehen über den Rahmen dieser Spezifikation hinaus. |
| Unterkomponente | Abhängig von der Hardwarearchitektur sind möglicherweise nicht alle Komponenten für das Betriebssystem sichtbar, da sie möglicherweise nach einer Komponente verbunden sind, die für das System sichtbar ist. Diese Komponenten werden in dieser Spezifikation als Unterkomponenten bezeichnet. |
| TLC | HID-Auflistung der obersten Ebene. |
| Token | Ein Bezeichner für eine Hostsitzung. Ein Host erstellt ein Token und sendet es in Befehlen, und das Gerät gibt es in der Antwort zurück. Token können verwendet werden, um bestimmte Transaktionen zu serialisieren oder zu identifizieren, dass eine Sitzung verloren und eine andere gestartet wurde. |
1.2 Bereich
1.2.1 Goals
Eine busunabhängige Lösung ist erforderlich, um ein neues Protokoll für jeden Bustyp zu vermeiden. HID ist allgegenwärtig und erfüllt diese Anforderung.
Die Möglichkeit, Firmwareupdates für ein Gerät mit mehreren Komponenten zu unterstützen, bei dem eine Komponente als primäre Komponente fungiert und andere Teilkomponenten sind, die mit der primären Komponente verbunden sind. Jede Komponente benötigt eine eigene Firmware mit nicht trivialen Abhängigkeiten untereinander.
Ein gängiges Treibermodell zum Herunterladen des Firmwareimages in die Komponente. Die Komponente verfügt dann über spezifische Unterkomponentenalgorithmen für die Weiterleitung an die Unterkomponenten. Die Unterkomponenten können auch Gültigkeitsprüfungen für ihre Firmware durchführen und die Ergebnisse an die primäre Komponente zurückgeben.
Die Möglichkeit, firmwareupdates zu unterstützen, während der Gerätebetrieb ausgeführt wird.
Die Möglichkeit, die Firmware in Produktionsgeräten über autorisierte Tools zu aktualisieren/rollbacken und marktinterne Geräte über Windows Update zu aktualisieren.
Die Flexibilität, firmware/in-market-Firmware in der Entwicklung zu unterstützen.
Die Möglichkeit, ein großes Firmwareimage in kleinere Segmente zu segmentieren, um es der Komponente zu erleichtern, das Firmwareimage zu akzeptieren.
1.2.2 Nicht Goals
Definieren Sie das interne Format des Firmwareimages: Für den Host ist das Firmwareimage eine Gruppe von Adress- und Nutzlasteinträgen.
Signieren/Verschlüsseln/Überprüfen der akzeptierten Firmware: In dieser Spezifikation wird nicht beschrieben, wie die Firmwareimages signiert und verschlüsselt werden. Es ist erforderlich, dass die erwartete aktuelle Firmware, die für die Komponente ausgeführt wird, die heruntergeladene Firmware überprüft.
Definieren Sie einen Mechanismus zur Interaktion der Komponente mit den Unterkomponenten: Der Host interagiert mit dem Gerät als einzelne Einheit, in der Regel die primäre Komponente. Die Komponente muss als Brücke für die Kommunikation im Zusammenhang mit der Firmware des Teilkomponentens fungieren.
2 Unterstützte Hardwarearchitektur
Um ein flexibles Hardwaredesign zu unterstützen, unterstützt das Protokoll ein Gerät mit mehreren Komponenten, bei dem jede Komponente ein eigenes Firmwareimage benötigt. Im Entwurf ist eine Komponente die primäre Komponente, und die abhängigen Unterkomponenten sind mit dieser primären Komponente verbunden. Jede Komponente wird durch eine Komponenten-ID eindeutig beschrieben.
Das Gerät mit mehreren Komponenten ist für das Betriebssystem als einzelne Einheit sichtbar. Der Host interagiert nur mit dem Gerät, in der Regel die primäre Komponente, die dieses CFU-Protokoll verwendet. Die Kommunikation zwischen der Komponente und ihren Unterkomponenten sprengt den Rahmen dieser Spezifikation.
Auf einem PC gibt es möglicherweise viele verschiedene Geräte (bei denen ein Gerät möglicherweise eine oder mehrere Komponenten enthält). Im Kontext dieses Protokolls ist die Kommunikation mit jedem Gerät unabhängig. Jedes Gerät verfügt über eine entsprechende instance des Hosts.
3 Protokollvoraussetzungen
In diesem Abschnitt werden die Voraussetzungen und bewährten Methoden aufgeführt, die implementiert werden müssen, um dieses Protokoll zu nutzen:
Verwendung von atomaren Bildern
Ein Firmwareimage für eine Komponente wird erst verwendet, wenn das gesamte Firmwareimage erfolgreich heruntergeladen wurde. Falls die Firmware in mehrere Segmente unterteilt ist, darf das Image erst verwendet werden, wenn das letzte Segment vom Absender empfangen wird. Integritätsprüfungen müssen für das endgültige Image durchgeführt werden. Es wird empfohlen, dass der Transport, der zum Übermitteln des Firmwareimages verwendet wird, über Fehlerkorrektur- und Wiederholungsmechanismen verfügt, um einen wiederholten Download im Falle von Transportfehlern zu vermeiden.
Firmwareupdate darf gerätebetrieb nicht unterbrechen
Das Gerät, das das Firmwareimage akzeptiert, muss während des Updates funktionieren können. Das Gerät muss über zusätzlichen Arbeitsspeicher verfügen, um die eingehende Firmware zu speichern und zu überprüfen, während die aktuelle Firmware nicht überschrieben wird.
Authentifizierung und Integrität
Der Implementor entscheidet, welche Faktoren ein authentisches Firmwareimage darstellen. Es wird empfohlen, dass die aktuelle Firmware der Komponente mindestens den CRC des eingehenden Firmwareimages überprüfen muss. Die aktuelle Firmware sollte auch digitale Signatur oder andere Fehlererkennungsalgorithmen verwenden. Wenn die Überprüfung fehlschlägt, lehnt die Firmware das Update ab. Fehlerwiederherstellung
Wenn das Firmwareimage heruntergeladen wird und nicht erfolgreich ist, darf das Gerät die neue Firmware nicht aufrufen und weiterhin mit der vorhandenen Firmware arbeiten. Der Host kann das Update wiederholen. Die Wiederholungshäufigkeit ist implementierungsspezifisch.
Vertraulichkeit
Optional. Ein Firmwaresegment kann verschlüsselt sein. Die Verschlüsselungs- und Entschlüsselungstechniken liegen außerhalb des Geltungsbereichs dieser Spezifikation. Diese Spezifikation behandelt die Firmwarenutzlast als Datenstrom, unabhängig davon, ob sie verschlüsselt ist.
Rollback-Schutz
Rollbackrichtlinien werden von der primären Komponente erzwungen und sind implementierungsspezifisch. Die aktuelle Firmware der Komponente überprüft eingehende Firmwareimages anhand interner Richtlinien, z. B. dass die Versionsnummer neuer sein muss, oder der Releasetyp kann nicht von Release zu Debug umgestellt werden usw. Mit dem Protokoll kann Messaging angeben, dass ein Update akzeptiert wird, auch wenn es gegen Rollbackrichtlinien verstößt.
4 Übersicht über das CFU-Protokoll
Das CFU-Protokoll ist eine Reihe von Befehlen und Antworten, die erforderlich sind, um die neuen Firmwareimages vom Host an das Gerät zu senden, für das die Firmware vorgesehen ist.
Auf hoher Ebene durchläuft das Protokoll alle Firmwareimages, die an das Gerät gesendet werden sollen. Für jedes Firmwareimage bietet der Host an, die Datei an das Gerät zu senden. Nur wenn das Gerät das Angebot akzeptiert, sendet der Host die Datei.
Um Fälle zu unterstützen, in denen eine Geräteupdatereihenfolge Abhängigkeiten aufweist, akzeptiert das Gerät bestimmte Angebote möglicherweise nicht im ersten Durchgang. Daher ermöglicht das Protokoll dem Host, alle Firmwareangebote erneut an das Gerät zu senden, bis alle Abhängigkeiten aufgelöst sind.
4.1 Befehlssequenz für die Programmierung des Firmwareupdates
Hier sehen Sie die CFU-Befehlssequenz zum Aktualisieren des Firmwareimages.
4.1.1 Zustand: Host initialisierte Benachrichtigung
Nachdem der Host sich selbst initialisiert und eine Reihe von Angeboten identifiziert hat, die er an das Gerät senden muss, gibt der Host einen OFFER_INFO_START_ENTIRE_TRANSACTION-Befehl aus, um der Komponente anzugeben, dass der Host jetzt initialisiert wird. Der Zweck dieses Befehls besteht darin, die aktuelle Gerätefirmware zu benachrichtigen, dass eine neue instance des Hosts verfügbar ist. Diese Benachrichtigung ist nützlich, wenn eine vorherige instance des Hosts unerwartet beendet wird. Das Gerät muss diesen Befehl erfolgreich ausführen.
4.1.2 Status: OFFER_INFO_START_OFFER_LIST Benachrichtigung
In diesem Zustand gibt der Host den Befehl OFFER_INFO_START_OFFER_LIST aus, um anzugeben, dass er bereit ist, die Angebote an die aktuelle Gerätefirmware zu senden. Die primäre Komponente des Geräts muss diesen Befehl erfolgreich ausführen.
Dieser Befehl ist nützlich, da der Host alle Angebote mehrmals an das Gerät sendet.
4.1.3 Status: Befehl senden FIRMWARE_UPDATE_OFFER
Der Host sendet ein Angebot an die primäre Komponente (oder deren Unterkomponente), um zu überprüfen, ob die Komponente die Firmware akzeptieren/ablehnen möchte. Das Angebot enthält alle erforderlichen Metadaten zum Firmwareimage, sodass die aktuelle Firmware der Komponente entscheiden kann, ob das Angebot angenommen, geschrieben, übersprungen oder abgelehnt werden soll.
Das Angebot kann für die primäre Komponente oder den Teilkomponenten sein. Wenn die Komponente das Angebot annehmen kann, bereitet sie sich auf den Empfang der Firmware vor. Dies kann die Vorbereitung einer Speicherbank auf den Empfang des eingehenden Firmwareimages umfassen. Die Komponente akzeptiert das Angebot möglicherweise nicht, z. B. verfügt die Komponente möglicherweise bereits über eine neuere (oder dieselbe) Firmwareversion, die der Host senden möchte. Weitere Gründe finden Sie in den Beispielen, die in Anhang 1: Beispiel-Firmwareupdateprogrammierungsbefehlssequenz beschrieben sind.
Selbst wenn ein Angebot angenommen wird, kann die primäre Komponente das Firmwareimage auch nach dem Download aufgrund eines Fehlers der Integrität und/oder rollback-Überprüfungen mit dem tatsächlich empfangenen Image ablehnen. Die Komponente muss jede Firmwareimageeigenschaft unabhängig von allen Informationen im Angebot überprüfen.
Der Host gibt den Befehl FIRMWARE_UPDATE_OFFER aus, um die primäre Komponente über das Firmwareimage zu benachrichtigen, das der Host senden möchte.
Nimmt die Komponente das Angebot an, so nimmt sie mit FIRMWARE_UPDATE_OFFER_ACCEPT status das Angebot an.
Wenn die Gerätefirmware ausgelastet ist und die primäre Komponente dieses oder das nächste Angebot derzeit nicht annehmen kann, sendet sie eine Ausgelastete Antwort mit FIRMWARE_UPDATE_OFFER_BUSY status.
Wenn die aktuelle Firmware an dem Angebot interessiert ist, das Angebot jedoch nicht annehmen kann (z. B. aufgrund einer Abhängigkeit von einem fehlenden Update für einen Teilkomponenten), antwortet sie mit einem FIRMWARE_UPDATE_OFFER_SKIP der an dieser Firmware interessiert ist, es jedoch nicht annehmen kann. Der Host fährt dann mit dem nächsten Angebot fort und muss diese Firmware später erneut anbieten.
Wenn die aktuelle Firmware nicht an dem Angebot interessiert ist (z. B. eine ältere Version), antwortet sie mit einem FIRMWARE_UPDATE_OFFER_REJECT status mit dem entsprechenden Ablehnungsgrund. Diese status bedeutet nicht, dass der Host dieses Angebot in Zukunft nicht erneut senden kann. Der Host sendet in der Regel jedes Angebot jedes Mal, wenn er die Liste der Angebote initialisiert oder erneut an das Gerät sendet (siehe Zustand: OFFER_INFO_START_OFFER_LIST Benachrichtigung).
4.1.4 Zustand: Firmware senden
In diesem Zustand beginnt der Host mit dem Senden des Firmwareimages an die primäre Komponente, für die die Komponente das Angebot zuvor angenommen hat.
Da der Inhalt des Firmwareimages wahrscheinlich die Nutzlastgrenzwerte eines einzelnen Befehls übergeht, unterbricht der Host die Firmwareimages in Pakete. Der Host sendet jedes Paket sequenziell in einem separaten FIRMWARE_UPDATE CONTENT-Befehl. Die primäre Komponente muss für jeden Befehl ein Antwortpaket generieren.
Jeder FIRMWARE_UPDATE CONTENT-Befehl beschreibt eine Offsetadresse, die eine partielle Firmwarenutzlast enthält. Die Komponente verwendet den Offset, um die Adresse zu bestimmen, an der die partielle Firmwarenutzlast gespeichert werden muss. Das Gerät schreibt den Inhalt an einen geeigneten Speicherort und bestätigt den Befehl durch Senden einer Antwort.
Für das erste Paket, das der Host sendet, wird das flag FIRMWARE_UPDATE_FLAG_FIRST_BLOCK festgelegt, das dem Gerät angibt, dass dies das erste Paket des Firmwareimages ist. Wenn sich das Gerät bereits nicht auf den Empfang der Firmware vorbereitet hat, kann es dies zu diesem Zeitpunkt tun.
Für das letzte Paket, das der Host sendet, wird das flag FIRMWARE_UPDATE_FLAG_LAST_BLOCK festgelegt.
Nachdem die aktuelle Firmware auf dem Gerät die teilbasierte Firmwarenutzlast geschrieben hat, die in diesem Befehl enthalten ist, muss sie Validierungs- und Authentifizierungsprüfungen für das eingehende Firmwareimage durchführen, bevor eine Antwort gesendet wird. Dies umfasst mindestens:
Eine CRC-Überprüfung, um die Integrität des gesamten Firmwareimages zu überprüfen.
Wenn die CRC-Überprüfung erfolgreich ist, kann optional eine Signatur des eingehenden Images überprüft werden.
Nach der optionalen Signaturprüfung wird eine Versionsüberprüfung durchgeführt, um sicherzustellen, dass die neue Firmwareversion identisch oder neuer als die vorhandene Firmware ist.
Falls das eingehende Firmwareimage in kleinere Segmente unterteilt wurde, muss die aktuelle Firmware bestimmen, ob es sich um das letzte Segment des Firmwareimages handelt, und anschließend alle Segmente als Teil der Validierung einbeziehen.
Wenn die vorherigen Überprüfungen erfolgreich sind, kann die aktuelle Firmware das Gerät so einrichten, dass es beim nächsten Zurücksetzen auf das neue Image ausgetauscht wird, und meldet den Erfolg an den Host. In der Regel initiiert die Komponente keine Selbstzurücksetzung. Dadurch sollen Unterbrechungen in software-, firmware- und hardwarebasierten Entitäten verhindert werden, mit denen die Komponente interagiert. Dies ist jedoch keine Anforderung und kann je nach Implementierung variieren.
Wenn die Überprüfungsschritte fehlschlagen, darf die Firmware beim nächsten Zurücksetzen keinen Austausch einrichten und muss eine Fehlerantwort für den Host anzeigen.
4.1.5 Entscheidungszustand: Gibt es weitere Angebote?
In diesem Zustand bestimmt der Host, ob weitere Angebote zum Senden an das Gerät vorhanden sind.
4.1.6 Status: OFFER_INFO_END_OFFER_LIST Benachrichtigung
Dieser Zustand wird erreicht, wenn der Host alle Angebote an die primäre Komponente in der aktuellen Gerätefirmware gesendet hat. Der Host sendet den Befehl OFFER_INFO_END_OFFER_LIST, um anzugeben, dass er alle Angebote an die Komponente gesendet hat.
Das Gerät muss diesen Befehl erfolgreich ausführen.
4.1.7 Entscheidungszustand: Wiedergabeangebotsliste
Der Host bestimmt, ob er alle Angebote erneut senden muss. Dieser Fall kann auftreten, wenn die primäre Komponente zuvor einige Angebote übersprungen und einige Angebote akzeptiert hat. Der Host muss die Angebotsliste erneut wiedergeben.
Möglicherweise gibt es eine andere implementierungsspezifische Logik, die zu einer Entscheidung zur Wiedergabe der Angebotsliste führen kann.
4.1.8 Status: Gerät ist ausgelastet
Dieser Zustand impliziert, dass ein Gerät eine ausgelastete Antwort auf ein Angebot zurückgegeben hat.
Der Host sendet einen OFFER_NOTIFY_ON_READY-Befehl, auf den das Gerät erst dann mit Zustimmung reagiert, wenn das Gerät frei ist.
5 CFU-Protokollpaketformat
Das CFU-Protokoll wird als Satz von Befehlen und Antworten implementiert. Das Protokoll ist sequenziell. Für jeden Befehl, den der Host an eine Komponente sendet, wird erwartet, dass die Komponente reagiert (sofern in dieser Spezifikation nicht explizit anders angegeben). Der Host sendet den nächsten Befehl erst, wenn eine gültige Antwort für den vorherigen gesendeten Befehl empfangen wird.
Falls die Komponente nicht innerhalb eines Zeitraums antwortet oder eine ungültige Antwort sendet, kann der Host den Prozess von Anfang an neu starten. Dieses Protokoll definiert keinen bestimmten Timeoutwert.
Es gibt Befehle zum Abrufen der Versionsinformationen der aktuellen Firmware für die Komponente. , um das Angebot zu senden und das Firmwareimage zu senden.
Der Host muss jedoch kein Angebot zurückhalten, das auf der antwort basiert, die von der primären Komponente zu den abgefragten Versionsinformationen empfangen wurde. Die Informationen werden für protokollierungs- oder andere Zwecke auffindbar gemacht.
5.1 GET_FIRMWARE_VERSION
Ruft die aktuelle(n) Firmwareversion(en) der primären Komponente (und deren Unterkomponenten) ab. Der Befehl weist keine Argumente auf.
5.1.1 Befehl
Dieser Befehl wird vom Host gesendet, um die Versionen der aktuellen Firmware(n) für die primäre Komponente (und deren Unterkomponenten) abzufragen. Der Host kann sie verwenden, um zu überprüfen, ob die Firmware erfolgreich aktualisiert wurde. Beim Empfang dieses Befehls antwortet die primäre Komponente mit der Firmwareversion für sich selbst und alle Unterkomponenten.
5.1.2 Antwort
Die Komponente antwortet mit der Firmwareversion der primären Komponente und den Unterkomponenten. Die Antwortgröße beträgt 60 Bytes, sodass Versionsinformationen für bis zu sieben Komponenten (eine primäre komponente und bis zu sechs Teilkomponenten) möglich sind.
Tabelle 5.1-1 GET_FIRMWARE_VERSION Antwortlayout
5.1.2.1-Header
Tabelle 5.1-2 GET_FIRMWARE_VERSION Antwort – Headerlayout
Der Header für die Antwort enthält die folgenden Informationen.
Tabelle 5.1-3 GET_FIRMWARE_VERSION Antwort – Headerbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Komponentenanzahl | 8 | Die Anzahl der herunterladbaren Komponenten, die über diesen Mechanismus für diese Komponente verwaltet werden. Die Komponentenanzahl bestimmt die maximale Tabellengröße. Derzeit werden bis zu 7 Komponenten unterstützt, um sicherzustellen, dass die Antwort innerhalb der zulässigen 60 Bytes passen kann. |
| 8 | Rsvd | 16 | Reservierte Felder. Der Absender muss diese auf 0 festlegen. Der Empfänger muss diesen Wert ignorieren. |
| 24 | Protokollversion | 4 | Die Firmwareupdate-Revisionsbits stellen die FW Update Protocol-Revision dar, die derzeit beim Transport verwendet wird. Für die hier definierte Schnittstelle muss die FW-Updaterevision 0010b sein. |
| 28 | Rsvd | 3 | Reservierte Felder. Der Absender muss diese auf 0 festlegen. Der Empfänger muss diesen Wert ignorieren. |
| 31 | E | 1 | Das Erweiterungsflag ist ein zukünftiger Protokollhook, mit dem zusätzliche Komponenten gemeldet werden können. |
5.1.2.2 Komponentenversion und Eigenschaften
Für jede Komponente werden zwei DWORDs verwendet, um die Eigenschaften der Komponente bis zu 7 Komponenten zu beschreiben. Wenn die Anzahl der Komponenten im Header kleiner als 7 ist, muss der nicht verwendete DWORDS-Wert am Ende der Antwort auf 0 festgelegt werden.
Tabelle 5.1-4 GET_FIRMWARE_VERSION Antwort : Komponentenversion und Eigenschaftenlayout
Jede komponentenspezifische Information wird in zwei DWORDs wie folgt beschrieben:
Tabelle 5.1-5 GET_FIRMWARE_VERSION Antwort : Komponentenversions- und Eigenschaftenstiche
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Firmware Version | 32 | Gibt die Version der aktuellen Firmware für diese Komponente zurück. Diese Spezifikation schreibt kein bestimmtes Format für die Firmwareversion vor. Richtlinien finden Sie im Abschnitt Firmwareversion. |
| 32 | Bank | 2 | Optional. Je nach Architektur kann die Komponentenhardware über mehrere Banken verfügen, in denen die Firmware gespeichert werden kann. Je nach Implementierung kann der Absender die Bank angeben, in der die Firmware derzeit vorhanden ist. Dieses Feld ist bedingt obligatorisch. Die Unterstützung ist optional, darf jedoch nicht für andere Zwecke verwendet werden. |
| 34 | Reserviert | 2 | Reservierte Felder. Der Absender muss diese auf 0 festlegen. Der Empfänger muss diesen Wert ignorieren. |
| 36 | Herstellerspezifisch | 4 | Anbieterspezifisches Feld, das auf implementierungsspezifische Weise verwendet werden kann. Ein Anbieter kann diese Bits verwenden, um Informationen zu codieren, z. B.: - Typ der Firmware: Vorabversion/Selbsthost/Produktion; debuggen/retail - Entwicklungsphase - Produkt-ID, um zu verhindern, dass Komponenten Firmware für andere Produkte empfangen, die dasselbe Updateprotokoll verwenden. |
| 40 | Komponenten-ID | 8 | Ein eindeutiger Bezeichner für die Komponente. |
| 48 | Herstellerspezifisch | 16 | Anbieterspezifisches Feld, das auf implementierungsspezifische Weise verwendet werden kann. |
5.1.3 Zuordnung zu HID
Dies wird als HID Get Feature-Anforderung mit einer Antwortgröße von 60 Byte zusätzlich zur Berichts-ID implementiert. Die Länge des Featureberichts enthält die gesamte GET_FIRMWARE_VERSION Antwort. Der Anforderung Feature abrufen vom Host sind keine Daten zugeordnet.
5.2 FIRMWARE_UPDATE_OFFER
Bestimmt, ob die primäre Komponente eine Firmware akzeptiert oder ablehnt.
5.2.1 Befehl
Der Host sendet diesen Befehl an die Komponente, um zu bestimmen, ob eine Firmware akzeptiert oder abgelehnt wird. Der Host muss ein Angebot senden, und die Komponente muss das Angebot annehmen, bevor der Host die Firmware senden kann.
Das FIRMWARE_UPDATE_OFFER-Befehlspaket ist wie folgt definiert.
Tabellen 5.2-1 FIRMWARE_UPDATE_OFFER Befehlslayout
5.2.1.1 Komponenteninformationen
Tabelle 5.2-2 FIRMWARE_UPDATE_OFFER Befehl – Komponenteninformationslayout
Die Bits des Komponenteninformationsbytes werden in dieser Tabelle beschrieben.
Tabelle 5.2-3 FIRMWARE_UPDATE_OFFER Befehl – Komponenteninformationsbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Segmentnummer | 8 | Dieses Feld wird für den Fall verwendet, dass die Firmware für eine Komponente in kleinere Segmente unterteilt ist. Bei Verwendung gibt dieser Wert das Segment an, das im nachfolgenden Nutzlastpaket enthalten ist. Beispiel: Wenn das Firmwareimage für die Komponente sehr groß ist und die primäre Komponente nur kleinere Teile des Bilds gleichzeitig annehmen kann, kann dieses Feld verwendet werden, um anzugeben, dass dieses Angebot für das i-ten Segment des vollständigen Bilds gilt. Ein separates Angebot kann an die primäre Komponente gesendet werden, die das i+1. Segment des Bilds enthält usw. |
| 8 | Reserviert | 6 | Reservierte Felder. Der Absender muss diese auf 0 festlegen. Der Empfänger muss diesen Wert ignorieren. |
| 14 | I | 1 | Sofortiges Zurücksetzen erzwingen (I) - Dieser Bitwert wird verwendet, um der Komponente mitzuteilen, dass sie sich nach Abschluss des Firmwaredownloads sofort selbst zurücksetzt und überprüft wird, um sie sofort aufzurufen. - Dieses Flag ist für die Entwicklungsphase vorgesehen. |
| 15 | V | 1 | Erzwingen des Ignorierens von Version (V) – Dieses Flag ist für Vorabversionen oder Debuggen von Firmwareimages vorgesehen. Es gibt an, dass die Komponente die Firmware basierend auf der Firmwareversion nicht zurückweist. - Dieses Flag ist für die Entwicklungsphase vorgesehen. Es kann verwendet werden, um absichtlich ein Rollback auf eine frühere Firmwareversion durchzuführen. - Dieses Flag sollte von der Produktionsfirmware ignoriert werden. |
| 16 | Komponenten-ID | 8 | Dieses Byte wird für Szenarien mit mehreren Komponenten verwendet. Dieses Feld kann verwendet werden, um den Teilkomponenten zu identifizieren, für den das Angebot vorgesehen ist. Wenn nicht verwendet, sollte der Wert 0 sein. Die möglichen Werte von Komponenten-IDs sind wie folgt: 1 - 0xDF: Gültig 0xE0 – 0xFD: Reserviert. Nicht verwenden. 0xFF: Das Angebot ist ein spezielles Angebotsinformationspaket. Weitere Informationen finden Sie unter FIRMWARE_UPDATE_OFFER Informationen. 0xFE: Das Angebot ist ein spezielles Angebotsbefehlspaket. Weitere Informationen finden Sie im Abschnitt FIRMWARE_UPDATE_OFFER Erweitert. |
| 24 | Token | 8 | Der Host fügt ein eindeutiges Token in das Angebotspaket an die Komponente ein. Dieses Token muss von der Komponente in der Angebotsantwort zurückgegeben werden.< Dies ist nützlich, wenn die Komponente zwischen den verschiedenen Hosts/Typen von Hosts unterscheiden muss. Genaue werte, die verwendet werden sollen, sind implementierungsspezifisch. Beispielsweise kann ein Wert für einen Treiber und ein anderer für die Anwendung verwendet werden. Dadurch kann die aktuelle Gerätefirmware potenzielle mehrere Absender von CFU-Befehlen berücksichtigen. Eine mögliche Implementierung kann sein, den ersten CFU-Befehl zu akzeptieren und alle anderen Befehle mit unterschiedlichen Token abzulehnen, bis die ersten CFU-Transaktionen abgeschlossen sind. |
5.2.1.2 Firmwareversion
Diese vier Bytes stellen die 32-Bit-Version der Firmware dar. Das Format für die Firmwareversion ist in dieser Spezifikation nicht vorgeschrieben. Folgendes wird empfohlen.
Tabelle 5.2-4 FIRMWARE_UPDATE_OFFER Befehl – Layout der Firmwareversion
Das Format für die Firmwareversion ist in dieser Spezifikation nicht vorgeschrieben. Dies ist jedoch eine empfohlene Richtlinie.
Tabelle 5.2-5 FIRMWARE_UPDATE_OFFER Befehl – Firmwareversionsbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Variant | 8 | Dieses Feld kann beschrieben werden, um zwischen vorab veröffentlichter Firmware und Produktionsfirmware zu unterscheiden. Es kann den Typ der Signatur angeben, die zum Signieren der Firmware verwendet wird. |
| 8 | Nebenversion | 16 | Dieser Feldwert sollte für jeden Build der Firmware aktualisiert werden. Dieser Feldwert sollte für jeden Build der Firmware aktualisiert werden. |
| 24 | Hauptversion | 8 | Dieses Feld ist die Hauptversion des Firmwareimages. Dieses Feld sollte aktualisiert werden, wenn eine neue Produktlinie, wichtige neue Firmwareupdates usw. versendet werden. |
5.2.1.3 Herstellerspezifisch
Diese vier Bytes können verwendet werden, um benutzerdefinierte Informationen im Angebot zu codieren, die speziell für die Anbieterimplementierung gelten.
5.2.1.4 Sonstige Und Protokollversion
Diese vier Bytes können verwendet werden, um benutzerdefinierte Informationen im Angebot zu codieren, die speziell für die Anbieterimplementierung gelten.
Tabelle 5.2-6 FIRMWARE_UPDATE_OFFER Befehl – herstellerspezifisches Layout
Die Bits des anbieterspezifischen Bytes werden in dieser Tabelle beschrieben.
Tabelle 5.2-7 FIRMWARE_UPDATE_OFFER Befehl – Andere Und Protokollversion
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Protokollversion | 4 | Dieses Feld muss auf 0010b festgelegt werden, was angibt, dass der Host/das Angebot der Version 2 des CFU-Protokolls entspricht. |
| 4 | Reserviert | 4 | Reserviert. Nicht verwenden. |
| 8 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 16 | Herstellerspezifisch | 16 | Dieses Feld kann verwendet werden, um benutzerdefinierte Informationen im Angebot zu codieren, die speziell für die Anbieterimplementierung gelten. |
5.2.2 Antwort
Das FIRMWARE_UPDATE_OFFER Antwortpaket ist wie folgt definiert.
Tabelle 5.2-8 FIRMWARE_UPDATE_OFFER Antworttokenlayout
5.2.2.1 Token
Tabelle 5.2-9 FIRMWARE_UPDATE_OFFER Antwort – Tokenlayout
Die Bits des Tokenbytes werden in dieser Tabelle beschrieben.
Tabelle 5.2-10 FIRMWARE_UPDATE_OFFER Antwort : Tokenbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 8 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 16 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 24 | Token | 8 | Token zum Identifizieren des Hosts. |
5.2.2.2 Reserviert (B7 - B4)
Reserviert. Nicht verwenden.
5.2.2.3 Ablehnungsgrund (RR)
Tabelle 5.2-11 FIRMWARE_UPDATE_OFFER Antwort – Grundlayout ablehnen
Tabelle 5.2-12 FIRMWARE_UPDATE_OFFER Antwort : Bits "Reason Bits ablehnen"
Die Bits des Bytes "Grund ablehnen" werden in dieser Tabelle beschrieben.
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | RR-Code | 8 | Der Ablehnungsgrundcode, der den von der Komponente angegebenen Grund für die Ablehnung des Angebots angibt. Dieser Wert hängt vom Feld Status ab. Eine Zuordnung zwischen Status und RR-Code finden Sie in Tabelle 5.2-13. |
| 8 | Reserviert | 24 | Reserviert. Nicht verwenden. |
Tabelle 5.2-13 FIRMWARE_UPDATE_OFFER RR-Codewerte der Antwort
Die möglichen Werte für das RR-Codebyte werden in dieser Tabelle beschrieben.
| RR-Code | Name | BESCHREIBUNG |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Das Angebot wurde abgelehnt, weil die Version der angebotenen Firmware älter oder mit der aktuellen Firmware identisch ist. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Das Angebot wurde abgelehnt, da die angebotene Firmware nicht auf die Plattform des Produkts anwendbar ist. Dies kann auf eine nicht unterstützte Komponenten-ID zurückzuführen sein, oder das angebotene Image ist nicht mit der Systemhardware kompatibel. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Die Komponentenfirmware wurde aktualisiert, ein Austausch auf die neue Firmware steht jedoch aus. Es kann keine weitere Verarbeitung von Firmwareupdates erfolgen, bis der Austausch abgeschlossen ist, in der Regel durch eine Zurücksetzung. |
| 0x03 - 0x08 | (Reserviert) | Reserviert. Nicht verwenden. |
| 0x09 – 0xDF | (Reserviert) | Reserviert. Nicht verwenden. |
| 0xE0 – 0xFF | (Herstellerspezifisch) | Diese Werte werden von den Designern des Protokolls verwendet, und die Bedeutung ist herstellerspezifisch. |
5.2.2.4 Status
Tabelle 5.2-14 FIRMWARE_UPDATE_OFFER Antwortstatuslayout
Die Bits des Statusbytes werden in dieser Tabelle beschrieben.
Tabelle 5.2-15 FIRMWARE_UPDATE_OFFER Antwort – Statusbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Status | 8 | Dieser Wert gibt die Entscheidung der Komponente an, das Angebot anzunehmen, zu stiften, zu überspringen oder abzulehnen. Die -Komponente gibt den Grund für im RR-Code-Feldwert an. Eine Zuordnung zwischen Status und RR-Code finden Sie in Tabelle 5.2-16. |
| 8 | Reserviert | 24 | Reserviert. Nicht verwenden. |
Die möglichen Werte für das Statusbyte werden in dieser Tabelle beschrieben.
Tabelle 5.2-16 FIRMWARE_UPDATE_OFFER Antwortstatuswerte
| Status | Name | BESCHREIBUNG |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | Die Komponente hat beschlossen, das Angebot zu überspringen. Der Host muss es später erneut anbieten. |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | Die Komponente hat sich entschieden, das Angebot anzunehmen. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | Die Komponente hat beschlossen, das Angebot abzulehnen. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | Das Gerät ist ausgelastet, und der Host muss warten, bis das Gerät bereit ist. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Wird verwendet, wenn komponenten-ID in den Komponenteninformationsbytes (siehe 5.1.2.1.1 Komponenteninformationen) auf 0xFE festgelegt ist. Wenn Befehlscode auf OFFER_NOTIFY_ON_READY Anforderung festgelegt ist, gibt an, dass das Zubehör bereit ist, zusätzliche Angebote anzunehmen. |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | Die Angebotsanforderung wird nicht erkannt. |
5.2.3 Zuordnung zum HID-Protokoll
Die Meldung wird über den HID-Ausgabeberichtsmechanismus an die Komponente ausgegeben, indem die dedizierte HID-Hilfsprogrammberichts-ID für Firmwareupdate verwendet wird. Der zu verwendende HID-Hilfsprogramm-TLC, der im Anhang beschrieben wird.
5.3 FIRMWARE_UPDATE_OFFER - Informationen
Wenn die Komponenten-ID in den Komponenteninformationsbytes (siehe Komponenteninformationen) auf 0xFF festgelegt ist, werden Bits (15 Bytes) neu definiert, um nur Angebotsinformationen anzugeben, vom Host zur Komponente. Dieser Mechanismus ermöglicht die Erweiterbarkeit und eine Möglichkeit für den Host, dem Gerät bestimmte Informationen bereitzustellen, z. B. Startangebotsliste, Angebotsliste beenden, gesamte Transaktion starten. Angebotsinformationspakete werden immer sofort von der Komponente akzeptiert.
5.3.1 Befehl
Das FIRMWARE_UPDATE_OFFER -Information Command-Paket ist wie folgt definiert:
Tabelle 5.3-1 FIRMWARE_UPDATE_OFFER : Layout des Informationsbefehls
5.3.1.1 Komponente
Tabelle 5.3-2 FIRMWARE_UPDATE_OFFER – Informationsbefehl – Komponentenlayout
Die Bits des Komponentenbytes werden in dieser Tabelle beschrieben.
Tabelle 5.3-3 FIRMWARE_UPDATE_OFFER – Informationsbefehl – Komponentenbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Informationscode | 8 | Dieser Wert gibt den Typ der Informationen an. Dieser Wert ist keine Bitmaske und kann nur einer der möglichen Werte sein, die in Tabelle 5.3-4 beschrieben werden. |
| 8 | Reserviert. | 8 | Reserviert. Nicht verwenden. |
| 16 | Komponenten-ID | 8 | Legen Sie auf 0xFF fest. |
| 24 | Token | Der Host fügt ein eindeutiges Token in das Angebotspaket in die Komponente ein. Dieses Token muss von der Komponente in der Angebotsantwort zurückgegeben werden. |
Tabelle 5.3-4 FIRMWARE_UPDATE_OFFER – Informationsbefehl – Informationscodewerte
| Status | Name | BESCHREIBUNG |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Gibt an, dass der Host neu ist oder neu geladen wurde und die gesamte Angebotsverarbeitung (neu)gestartet wird. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Gibt den Anfang der Angebotsliste vom Host an, falls das Zubehör Über Downloadregeln verfügt, die sicherstellen, dass eine Teilkomponente vor einem anderen Teilkomponenten im System aktualisiert wird. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Gibt das Ende der Angebotsliste vom Host an. |
5.3.1.2 Reserviert B7 - B4
Reserviert. Nicht verwenden.
5.3.1.3 Reserviert B11 - B8
Reserviert. Nicht verwenden.
5.3.1.4 Reserviert B15 - B12
Reserviert. Nicht verwenden.
5.3.2 Antwort
Die Antwort FIRMWARE_UPDATE_OFFER – Angebotsinformationsantwort ist wie folgt definiert.
Tabelle 5.3-5 FIRMWARE_UPDATE_OFFER : Layout der Informationsantwort
5.3.2.1 Token
Tabelle 5.3-6 FIRMWARE_UPDATE_OFFER: Informationspaket-Antworttokenlayout
Die Bits des Tokenbytes werden in dieser Tabelle beschrieben.
Tabelle 5.3-7 FIRMWARE_UPDATE_OFFER – Informationsantwort – Tokenbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 8 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 16 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 24 | Token | 8 | Token zum Identifizieren des Hosts |
5.3.2.2 Reserviert B7 - B4
Reserviert. Nicht verwenden.
5.3.2.3 Ablehnungsgrund (RR)
Tabelle 5.3-8 FIRMWARE_UPDATE_OFFER – Informationsantwort – RR-Codelayout
Die Bits des Byte "Ablehnungsgrund" werden in dieser Tabelle beschrieben.
Tabelle 5.3-9 FIRMWARE_UPDATE_OFFER: Antwort auf Angebotsinformationen – RR-Codebits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | RR-Code | 8 | Der Ablehnungsgrundcode, der den von der Komponente angegebenen Grund für die Ablehnung des Angebots angibt. Die möglichen Werte werden in Tabelle 5.3-10 beschrieben. Dieser Wert hängt vom Feld Status ab. |
| 8 | Reserviert | 24 | Reserviert. Nicht verwenden. |
Die möglichen Werte für das RR-Code-Byte werden in dieser Tabelle beschrieben.
Tabelle 5.3-10 FIRMWARE_UPDATE_OFFER: Informationsantwort – RR-Codewerte
| RR-Code | Name | BESCHREIBUNG |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Das Angebot wurde abgelehnt, da die Version der angebotenen Firmware älter oder mit der aktuellen Firmware identisch ist. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Das Angebot wurde abgelehnt, da die angebotene Firmware nicht auf die Plattform des Produkts anwendbar ist. Dies kann auf eine nicht unterstützte Komponenten-ID zurückzuführen sein oder das angebotene Image ist nicht mit der Systemhardware kompatibel. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Die Komponentenfirmware wurde aktualisiert, ein Austausch auf die neue Firmware steht jedoch aus. Bis der Austausch abgeschlossen ist, in der Regel durch ein Zurücksetzen, kann keine weitere Verarbeitung der Firmwareupdates durchgeführt werden. |
| 0x03 – 0x08 | (Reserviert) | Reserviert. Nicht verwenden. |
| 0x09 – 0xDF | (Reserviert) | Reserviert. Nicht verwenden. |
| 0xE0 – 0xFF | (Herstellerspezifisch) | Diese Werte werden von den Designern des Protokolls verwendet, und die Bedeutung ist herstellerspezifisch. |
5.3.2.4 Status
Tabelle 5.3-11 FIRMWARE_UPDATE_OFFER : Layout der Antwortstatus von Angebotsinformationen
Die Bits des Statusbytes werden in dieser Tabelle beschrieben.
Tabelle 5.3-12 FIRMWARE_UPDATE_OFFER : Angebotsinformationen – Antwortstatusbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Status | 8 | Dieses Feld muss auf FIRMWARE_UPDATE_OFFER_ACCEPT festgelegt werden. Dies gibt an, dass die Komponente entschieden hat, das Angebot anzunehmen. |
| 8 | Reserviert. | 24 | Reserviert. Nicht verwenden. |
5.4 FIRMWARE_UPDATE_OFFER – Erweitert
Wenn die Komponenten-ID in den Komponenteninformationsbytes auf 0xFE festgelegt ist, werden Bits (15 Bytes) neu definiert, um den Angebotsbefehl vom Host auf die Gerätefirmware anzugeben. Dieser Mechanismus ermöglicht die Erweiterbarkeit und eine Möglichkeit für den Host, dem Gerät bestimmte Informationen bereitzustellen. Angebotsbefehlspakete werden zurückgegeben, wenn die Komponente bereit ist, auf Akzeptiert zu reagieren.
5.4.1 Befehl
Wenn die Komponenten-ID in den Komponenteninformationsbytes auf 0xFE festgelegt ist, werden die vier DWORDs wie folgt neu definiert:
Tabelle 5.4-1 FIRMWARE_UPDATE_OFFER : Erweiterte Befehlslayout
5.4.1.1 Komponente
Tabelle 5.4-2 FIRMWARE_UPDATE_OFFER – Erweitertes Befehlspaket – Befehl – Komponentenlayout
Die Bits des Komponentenbytes werden in dieser Tabelle beschrieben.
Tabelle 5.4-3 FIRMWARE_UPDATE_OFFER – Erweiterter Befehl – Komponentenbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Befehlscode | 8 | Dieser Wert gibt den Typ des Befehls an. Dieser Wert ist keine Bitmaske und kann nur einer der in Tabelle 5.4-4 beschriebenen möglichen Werte sein. |
| 8 | Reserviert. | 8 | Reserviert. Nicht verwenden. |
| 16 | Komponenten-ID | 8 | Legen Sie auf 0xFE fest. |
| 24 | Token | Der Host fügt ein eindeutiges Token in das Angebotspaket in die Komponente ein. Dieses Token muss von der Komponente in der Angebotsantwort zurückgegeben werden. |
Tabelle 5.4-4 FIRMWARE_UPDATE_OFFER – Erweiterter Befehl – Befehlscodewerte
| Status | Name | BESCHREIBUNG |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Wird vom Host gesendet, wenn das Angebot zuvor von der Komponente abgelehnt wurde. |
| 0x02 – 0xFF | Reserviert | Reserviert |
5.4.1.2 Reserviert B7 - B4
Reserviert. Nicht verwenden.
5.4.1.3 Reserviert B11 - B8
Reserviert. Nicht verwenden.
5.4.1.4 Reserviert B15 - B12
Reserviert. Nicht verwenden.
5.4.2 Antwort
Die FIRMWARE_UPDATE_OFFER - Angebotsbefehlsantwort vom Gerät wird möglicherweise nicht sofort empfangen. Antwort wird wie folgt definiert.
Tabelle 5.4-5 FIRMWARE_UPDATE_OFFER– Layout für erweiterte Befehlspakete
5.4.2.1 Token
Tabelle 5.4-6 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaketantwort – Tokenlayout
Die Bits des Tokenbytes werden in dieser Tabelle beschrieben.
Tabelle 5.4-7 FIRMWARE_UPDATE_OFFER : Angebotsbefehlsantwort – Tokenbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 8 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 16 | Reserviert | 8 | Reserviert. Nicht verwenden. |
| 24 | Token | 8 | Token, um den Host zu identifizieren. |
5.4.2.2 Reserviert B7 - B4
Reserviert. Nicht verwenden.
5.4.2.3 Ablehnungsgrund
Tabelle 5.4-8 FIRMWARE_UPDATE_OFFER: RR-Layout für Angebotsinformationspakete
Die Bits des Byte "Ablehnungsgrund" werden in dieser Tabelle beschrieben.
Tabelle 5.4-9 FIRMWARE_UPDATE_OFFER: Angebotsbefehlsantwort – RR-Code
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | RR-Code | 8 | Dieser Wert hängt vom Feld Status ab. Mögliche RR-Codewerte finden Sie in Tabelle 5.4-10. |
| 8 | Reserviert | 24 | Reserviert. Nicht verwenden. |
Die möglichen Werte für das RR-Code-Byte werden in dieser Tabelle beschrieben.
Tabelle 5.4-10 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaket – RR-Codewerte
| RR-Code | Name | BESCHREIBUNG |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Das Angebot wurde abgelehnt, da die Version der angebotenen Firmware älter oder mit der aktuellen Firmware identisch ist. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Das Angebot wurde abgelehnt, da die angebotene Firmware nicht auf die Plattform des Produkts anwendbar ist. Dies kann auf eine nicht unterstützte Komponenten-ID zurückzuführen sein oder das angebotene Image ist nicht mit der Systemhardware kompatibel. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Die Komponentenfirmware wurde aktualisiert, ein Austausch auf die neue Firmware steht jedoch aus. Bis der Austausch abgeschlossen ist, in der Regel durch ein Zurücksetzen, kann keine weitere Verarbeitung der Firmwareupdates durchgeführt werden. |
| 0x03 – 0x08 | (Reserviert) | Reserviert. Nicht verwenden. |
| 0x09 – 0xDF | (Reserviert) | Reserviert. Nicht verwenden. |
| 0xE0 – 0xFF | (Herstellerspezifisch) | Diese Werte werden von den Designern des Protokolls verwendet, und die Bedeutung ist herstellerspezifisch. |
5.4.2.4 Status
Tabelle 5.4-11 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaket-Antwortstatuslayout
Die Bits des Statusbytes werden in dieser Tabelle beschrieben.
Tabelle 5.4-12 FIRMWARE_UPDATE_OFFER: Angebotsbefehl Paketantwort-RR-Code
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Status | 8 | Dieses Feld muss auf FIRMWARE_UPDATE_OFFER_ACCEPT festgelegt werden. Dies gibt an, dass die Komponente entschieden hat, das Angebot anzunehmen. |
| 8 | Reserviert. | 24 | Reserviert. Nicht verwenden. |
5.5 FIRMWARE_UPDATE_CONTENT
Der Host sendet diesen Befehl an die Gerätefirmware, um den Firmwareinhalt (also das Firmwareimage) bereitzustellen. Es wird nicht erwartet, dass die gesamte Imagedatei in einen einzelnen Befehl passt. Der Host muss das Bild in kleinere Blöcke unterteilen, und jeder Befehl sendet jeweils einen Block des Bilds.
Mit jedem Befehl gibt der Host zusätzliche Informationen an– ob es sich um den ersten Block, den letzten Block usw. der Firmware handelt. Die primäre Komponente der Gerätefirmware akzeptiert jeden Block des eingehenden Firmwareimages, speichert ihn im Arbeitsspeicher und muss auf jeden Befehl einzeln reagieren.
Wenn die primäre Komponente den letzten Block empfängt, überprüft die Komponente das gesamte Firmwareimage (CRC-Überprüfung, Signaturüberprüfung). Basierend auf den Ergebnissen dieser Überprüfungen wird eine geeignete Antwort (Fehler oder Erfolg) für den letzten Block zurückgegeben.
5.5.1 Befehl
Tabelle 5.5-1 FIRMWARE_UPDATE_CONTENT Befehlslayout
5.5.1.1 Header (B7 - B0)
Tabelle 5.5-2 FIRMWARE_UPDATE_CONTENT Befehlsheaderlayout
Die Bits des FIRMWARE_UPDATE_CONTENT-Headers werden in dieser Tabelle beschrieben.
Tabelle 5.5-3 FIRMWARE_UPDATE_CONTENT Headerbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Flags | 8 | Dieses Feld enthält zusätzliche Informationen zum Befehl. Dieser Wert ist eine Maske von Flags, die für die Datenübertragungen verwendet werden sollen. Die möglichen Werte werden in Tabelle 5.5-4 beschrieben. |
| 8 | Datenlänge | 8 | Die Länge des anwendbaren Datenfelds, das die Anzahl der zu schreibenden Bytes angibt. Angesichts der Größe dieses Befehls beträgt der maximal zulässige Wert für die Länge 52 Bytes. |
| 16 | Sequenznummer | 16 | Dieser Wert wird vom Host erstellt und ist für jedes ausgegebene Inhaltspaket eindeutig. Die Komponente muss die Sequenznummer in ihrer Antwort auf diese Anforderung zurückgeben. |
| 32 | Firmwareadresse | 32 | Little Endian (LSB First) Adresse zum Schreiben der Daten. Die Adresse ist 0-basiert. Die Firmware verwendet dies als Offset, um die Adresse bei Bedarf zu bestimmen, wenn das Image im Speicher platziert wird. |
Die möglichen Werte für das Flags-Byte werden in dieser Tabelle beschrieben.
Tabelle 5.5-4 FIRMWARE_UPDATE_OFFER: Angebotsbefehlspaket – Flagwerte
| Flag | Name | BESCHREIBUNG |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Dieses Flag gibt an, dass dies der erste Block des Firmwareimages ist. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Dieses Flag gibt an, dass dies der letzte Block des Firmwareimages ist und dass das Image zur Überprüfung bereit ist. Es ist wichtig, dass die aktuelle Firmware für die Komponente die Überprüfung für das gesamte heruntergeladene Firmwareimage durchführt, nachdem dieser Block in nicht flüchtigen Speicher geschrieben wurde. |
5.5.1.2 Daten
Tabelle 5.5-5 FIRMWARE_UPDATE_CONTENT Befehlsdatenlayout
Die Bits der FIRMWARE_UPDATE_CONTENT Daten werden in dieser Tabelle beschrieben.
Tabelle 5.5-6 FIRMWARE_UPDATE_CONTENT Befehlsdatenbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 64 | Daten | Max. 52. | Das zu schreibende Bytearray. Der Host sendet in der Regel Blöcke mit 4 Bytes basierend auf der Produktarchitektur. Alle nicht verwendeten Bytes am Ende müssen 0 aufgefüllt sein. |
5.5.2 Antwort
Tabelle 5.5-7 FIRMWARE_UPDATE_CONTENT Befehlsantwortlayout
5.5.2.1 Sequenznummer
Tabelle 5.5-8 FIRMWARE_UPDATE_CONTENT-Antwort – Sequenznummer
Die Bits der FIRMWARE_UPDATE_CONTENT Response (3-0) werden in dieser Tabelle beschrieben.
Tabelle 5.5-9 FIRMWARE_UPDATE_CONTENT : Befehl – Antwortbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Sequenznummer | 16 | Dieses Feld ist die Sequenznummer, die vom Host in der Anforderung gesendet wurde. |
| 16 | Reserviert | 16 | Reserviert. Nicht verwenden. |
5.5.2.2 Status
Tabelle 5.5-10 FIRMWARE_UPDATE_CONTENT Antwortstatuslayout
Die Bits der FIRMWARE_UPDATE_CONTENT-Antwort (7-4) werden in dieser Tabelle beschrieben.
Tabelle 5.5-11 FIRMWARE_UPDATE_OFFER – Antwort – Statusbits
| Bitoffset | Feld | Size | BESCHREIBUNG |
|---|---|---|---|
| 0 | Status | 8 | Dieser Wert gibt den von der Gerätekomponente zurückgegebenen status Code an. Dies ist kein bitweiser Wert und kann einer der in Tabelle 5.5-12 beschriebenen Werte sein. |
| 8 | Reserviert | 24 | Reserviert. Nicht verwenden. |
Die möglichen Werte für das Statusbyte werden in dieser Tabelle beschrieben.
Tabelle 5.5-12 FIRMWARE_UPDATE_OFFER: Antwort – Statuscodewerte
| Flag | Name | BESCHREIBUNG |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | Die Anforderung wurde erfolgreich abgeschlossen. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | Die Komponente war nicht darauf vorbereitet, den Firmwareinhalt zu empfangen. Bei Verwendung wird dieser Code in der Regel in einer Antwort auf den ersten Block verwendet. Beispiel: Löschfehler bei Flash. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | Die Anforderung konnte die Bytes nicht schreiben. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | Die Anforderung konnte den Austausch als Reaktion auf FIRMWARE_UPDATE_FLAG_LAST_BLOCK nicht einrichten. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | Fehler bei der Überprüfung des DWORD als Reaktion auf FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | Fehler beim CRC des Firmwareimages als Reaktion auf FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Fehler bei der Überprüfung der Firmwaresignatur als Reaktion auf FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Fehler bei der Überprüfung der Firmwareversion als Reaktion auf FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | Die Firmware wurde bereits aktualisiert, und ein Austausch steht aus. Es können keine weiteren Firmwareupdatebefehle akzeptiert werden, bis das Zubehör zurückgesetzt wurde. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | Die Firmware hat eine ungültige Zieladresse innerhalb des Nachrichtendateninhalts erkannt. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | Der FIRMWARE_UPDATE_OFFER-Befehl wurde empfangen, ohne zuerst ein gültiges und akzeptiertes Firmwareupdateangebot zu erhalten. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Allgemeiner Fehler für den FIRMWARE_UPDATE_OFFER-Befehl, z. B. ungültige anwendbare Datenlänge. |
5.5.2.3 Reserviert B8 - B11
Reserviert. Nicht verwenden.
5.5.2.4 ReserviertE B12 - B15
Reserviert. Nicht verwenden.
6 Anhang 1: Beispielbefehlssequenz für die Firmwareupdateprogrammierung
6.1 Beispiel 1
Betrachten Sie die folgende Gerätefirmware:
Primäre Komponente – Komponenten-ID 1 – Aktuelle Firmwareversion 7.0.1
Teilkomponente – Komponenten-ID 2 – Aktuelle Firmwareversion 12.4.54
Teilkomponente – Komponenten-ID 3 – Aktuelle Firmwareversion 4.4.2
Teilkomponente – Komponenten-ID 4 – Aktuelle Firmwareversion 23.32.9
Der Host verfügt über die folgenden drei Firmwareimages:
Komponenten-ID 1: Firmwareversion 7.1.3
Komponenten-ID 2: Firmwareversion 12.4.54
Komponenten-ID 3: Firmwareversion 4.5.0
Die Sequenz sieht wie folgt aus:
Hostangebote: Komponenten-ID 1 – Firmwareversion 7.1.3
Die primäre Komponente nimmt das Angebot an
Der Host sendet das Firmwareimage.
Die primäre Komponente akzeptiert Firmware und überprüft sie.
Hostangebote: Komponenten-ID 2 – Firmwareversion 12.4.54
Die primäre Komponente lehnt das Angebot ab.
Hostangebote: Komponenten-ID 3 – Firmwareversion 4.5.0
Die primäre Komponente nimmt das Angebot an
Der Host sendet das Firmwareimage.
Die primäre Komponente akzeptiert Firmware und überprüft sie.
Da nicht alle Angebote abgelehnt wurden, gibt der Host alle Angebote wieder:
Hostangebote: Komponenten-ID 1 – Firmwareversion 7.1.3
Komponenten weisen zurück
Hostangebote: Komponenten-ID 2 – Firmwareversion 12.4.54
Komponenten weisen zurück
Hostangebote: Komponenten-ID 3 – Firmwareversion 4.5.0
Komponenten weisen zurück
6.2 Beispiel 2
Betrachten Sie die folgende Gerätefirmware:
Primäre Komponente – Komponenten-ID 1 – Aktuelle Firmwareversion 7.0.1
Teilkomponente – Komponenten-ID 2 – Aktuelle Firmwareversion 12.4.54
Teilkomponente – Komponenten-ID 3 – Aktuelle Firmwareversion 7.4.2
Unterkomponente – Komponenten-ID 4 – Aktuelle Firmwareversion 23.32.9
Der Host verfügt über die folgenden drei Firmwareimages:
Komponenten-ID 1: Firmwareversion 8.0.0
Komponenten-ID 2 : Firmwareversion 12.4.54
Komponenten-ID 3: Firmwareversion 9.0.0
Darüber hinaus erfordert die Implementierung, dass die Firmwareversion der Unterkomponenten nicht kleiner als die Firmwareversion sein darf, die für die primäre Komponente ausgeführt wird. Der Host ist sich dieser Anforderung nicht bewusst, und er ist bis zur primären Komponente bereit, um diese Regel sicherzustellen.
Die Sequenz ist:
Hostangebote: Komponenten-ID 1 – Firmwareversion 8.0.0
Primäre Komponente lehnt ab (da die Komponenten-ID 3 noch nicht aktualisiert wurde)
Hostangebote: Komponenten-ID 2 – Firmwareversion 12.4.54
Primäre Komponente lehnt ab
Hostangebote: Komponenten-ID 3 – Firmwareversion 9.0.0
Primäre Komponente akzeptiert Angebot
Host sendet das Firmwareimage
Primäre Komponente akzeptiert Firmware und überprüft sie
Da nicht alle Angebote abgelehnt wurden, gibt der Host alle Angebote wieder.
Hostangebote: Komponenten-ID 1 – Firmwareversion 8.0.0
Primäre Komponente akzeptiert Angebot
Host sendet das Firmwareimage
Primäre Komponente akzeptiert Firmware und überprüft sie
Hostangebote: Komponenten-ID 2 – Firmwareversion 12.4.54
Primäre Komponente lehnt ab
Hostangebote: Komponenten-ID 3 – Firmwareversion 9.0.0
Primäre Komponente lehnt ab