Spezifikation des Komponenten-Firmware-Updates (CFU)

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ätevorgang 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. Mit der Spezifikation kann die für die Komponente verantwortliche Person entscheiden, ob die Firmware akzeptiert wird. Sie fungiert auch als Optimierung, da das Firmwareimage nur an die Komponente gesendet wird, wenn es in der Lage oder bereit ist, es anzunehmen.

Inhalt

• 1 Einführung
  • 1.1 Glossar
  • 1.2 Umfang
    • 1.2.1 Ziele
    • 1.2.2 Nichtziele
• 2 Unterstützte Hardwarearchitektur
• 3 Protokollvoraussetzungen
• 4 Übersicht über das CFU-Protokoll
  • 4.1 Firmware-Update-Programmierbefehlabfolge
    • 4.1.1 Zustand: Benachrichtigung über die Initialisierung des Hosts
    • 4.1.2 Status: OFFER_INFO_START_OFFER_LIST Benachrichtigung
    • 4.1.3 Status: Befehl "FIRMWARE_UPDATE_OFFER senden"
    • 4.1.4 Status: Firmware senden
    • 4.1.5 Entscheidungsstaat: Gibt es weitere Angebote
    • 4.1.6 Status: OFFER_INFO_END_OFFER_LIST Benachrichtigung
    • 4.1.7 Entscheidungszustand: Angebotsliste erneut darstellen
    • 4.1.8 Zustand: Gerät ist ausgelastet
• 5 CFU-Protokollpaketformat
  • 5.1 GET_FIRMWARE_VERSION
    • Befehl 5.1.1
    • 5.1.2 Antwort
      • 5.1.2.1 Kopfzeile
      • 5.1.2.2 Komponentenversion und -eigenschaften
    • 5.1.3 Zuordnung zu HID
  • 5.2 FIRMWARE_UPDATE_OFFER
    • Befehl 5.2.1
      • 5.2.1.1 Komponenteninformationen
      • 5.2.1.2 Firmwareversion
      • 5.2.1.3 Anbieterspezifisch
      • 5.2.1.4 Sonstige Und Protokollversion
    • 5.2.2 Antwort
      • 5.2.2.1 Token
      • 5.2.2.2 Reserviert (B7 - B4)
      • 5.2.2.3 Ablehnungsgrund (RR)
      • 5.2.2.4 Status
    • 5.2.3 Zuordnung zum HID-Protokoll
  • 5.3 FIRMWARE_UPDATE_OFFER - Informationen
    • Befehl 5.3.1
      • 5.3.1.1 Komponente
      • 5.3.1.2 Reserviert B7 - B4
      • 5.3.1.3 Reserviert B11 - B8
      • 5.3.1.4 Reservierte B15 - B12
    • 5.3.2 Antwort
      • 5.3.2.1 Token
      • 5.3.2.2 Reserviert B7 - B4
      • 5.3.2.3 Ablehnungsgrund (RR)
      • 5.3.2.4 Status
  • 5.4 FIRMWARE_UPDATE_OFFER - Erweitert
    • Befehl 5.4.1
      • 5.4.1.1 Komponente
      • 5.4.1.2 Reserviert B7 - B4
      • 5.4.1.3 Reserviert B11 - B8
      • 5.4.1.4 Reserviert B15 - B12
    • 5.4.2 Antwort
      • 5.4.2.1 Token
      • 5.4.2.2 Reserviert B7 - B4
      • 5.4.2.3 Ablehnungsgrund
      • 5.4.2.4 Status
  • 5.5 FIRMWARE_UPDATE_INHALT
    • Befehl 5.5.1
      • 5.5.1.1 Kopfzeile (B7 - B0)
      • 5.5.1.2 Daten
    • 5.5.2 Antwort
      • 5.5.2.1 Sequenznummer
      • 5.5.2.2 Status
      • 5.5.2.3 Reserviert B8 - B11
      • 5.5.2.4 Reserviert B12 - B15
• 6 Anhang 1: Beispiel für einen Firmware-Update-Programmiervorgang
  • 6.1 Beispiel 1
  • 6.2 Beispiel 2

Tabellen

Tabelle 5.1-1 GET_FIRMWARE_VERSION Antwortlayout

Tabelle 5.1-2 GET_FIRMWARE_VERSION Antwort – Kopfzeilenlayout

Tabelle 5.1-3 GET_FIRMWARE_VERSION Antwortnachricht – Header-Bits

Tabelle 5.1-4 GET_FIRMWARE_VERSION Antwort – Komponentenversions- und Eigenschaftenlayout

Tabelle 5.1-5 GET_FIRMWARE_VERSION Antwort – Komponentenversion und Eigenschaften Bits

Tabelle 5.2-1 FIRMWARE_UPDATE_OFFER Befehlslayout

Tabelle 5.2-2 FIRMWARE_UPDATE_OFFER Befehl – Komponenten-Informationslayout

Tabelle 5.2-3 FIRMWARE_UPDATE_OFFER Befehl – Komponenten-Informationsbits

Tabelle 5.2-4 FIRMWARE_UPDATE_OFFER Befehl – Firmwareversionslayout

Tabelle 5.2-5 FIRMWARE_UPDATE_OFFER Befehl – Firmwareversionsbits

Tabelle 5.2-6 FIRMWARE_UPDATE_OFFER Befehl – Anbieterspezifisches Layout

Tabelle 5.2-7 FIRMWARE_UPDATE_OFFER Befehl – Sonstiges und Protokollversion

Tabelle 5.2-8 FIRMWARE_UPDATE_OFFER Antwort-Token-Layout

Tabelle 5.2-9 FIRMWARE_UPDATE_OFFER-Antwort – Token-Layout

Tabelle 5.2-10 FIRMWARE_UPDATE_OFFER Antwort – Tokenbits

Tabelle 5.2-11 FIRMWARE_UPDATE_OFFER Antwort – Ablehnungsgrundlayout

Tabelle 5.2-12 FIRMWARE_UPDATE_OFFER Antwort – Ablehnungsgrund-Bits

Tabelle 5.2-13 FIRMWARE_UPDATE_OFFER Antwort-RR-Codewerte

Tabelle 5.2-14 FIRMWARE_UPDATE_OFFER Antwortstatus-Layout

Tabelle 5.2-15 FIRMWARE_UPDATE_OFFER Antwort – Statusbits

Tabelle 5.2-16 FIRMWARE_UPDATE_OFFER Antwortstatuswerte

Tabelle 5.3-1 FIRMWARE_UPDATE_OFFER – Informationsbefehlslayout

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 – Informationsbefehl – Werte des Informationscodes

Tabelle 5.3-5 FIRMWARE_UPDATE_OFFER – Layout der Informationsantwort

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 – Angebotsinformationsantwort – RR-Codebits

Tabelle 5.3-10 FIRMWARE_UPDATE_OFFER– Informationsantwort – RR-Codewerte

Tabelle 5.3-11 FIRMWARE_UPDATE_OFFER – Angebotsinformationen Antwortstatus-Layout

Tabelle 5.3-12 FIRMWARE_UPDATE_OFFER – Angebotsinformationen – Antwortstatus-Bits

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 – Erweitertes Befehlspaketantwortlayout

Tabelle 5.4-6 FIRMWARE_UPDATE_OFFER – Antwort auf Befehlsdatenpaket – Tokenlayout

Tabelle 5.4-7 FIRMWARE_UPDATE_OFFER – Befehlsantwort-Angebot – Token-Bits

Tabelle 5.4-8 FIRMWARE_UPDATE_OFFER – Angebotsinformationspaket-Response-RR-Layout

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 Befehls-Paketantwortstatus

Tabelle 5.4-12 FIRMWARE_UPDATE_OFFER: Befehlspaketantwort-RR-Code anbieten

Tabelle 5.5-1 Befehlslayout für FIRMWARE_UPDATE_CONTENT

Tabelle 5.5-2 FIRMWARE_UPDATE_CONTENT Befehlskopflayout

Tabelle 5.5-3 FIRMWARE_UPDATE_CONTENT Header-Bits

Tabelle 5.5-4 FIRMWARE_UPDATE_OFFER - Befehlsangebotspaket - Flagwerte

Tabelle 5.5-5 FIRMWARE_UPDATE_CONTENT Befehlsdatenlayout

Tabelle 5.5-6 FIRMWARE_UPDATE_CONTENT Datenbits des Befehls

Tabelle 5.5-7 FIRMWARE_UPDATE_CONTENT Befehls-Antwortlayout

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 Layout des Antwortstatus

Tabelle 5.5-11 FIRMWARE_UPDATE_OFFER – Antwort – Statusbits

Tabelle 5.5-12 FIRMWARE_UPDATE_OFFER– Antwort – Statuscodewerte

1 Einführung

Die heutigen PCs und Zubehör verfügen über interne Komponenten, die komplexe Vorgänge ausführen. Um ein qualitativ hochwertiges Produkt sicherzustellen, muss das Verhalten dieser Geräte in späteren Entwicklungsphasen oder nach der Auslieferung an die Kunden häufig aktualisiert werden. Das Update kann identifizierte Funktions- oder Sicherheitsprobleme beheben oder neue Features hinzufügen. Ein großer Teil der komplexen Logik befindet sich in der Firmware, die auf dem Gerät ausgeführt wird, was aktualisierbar ist.

Diese Spezifikation beschreibt ein generisches HID-Protokoll zum Aktualisieren der Firmware für Komponenten, die auf einem PC oder zubehör vorhanden sind. DIE HID-Implementierung geht über den Umfang 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 und I²C. Daher kann die gleiche 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. Dies ermöglicht eine bessere Benutzererfahrung, 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 atombasierten Vorgang gleichzeitig aufgerufen werden, der 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 einer Komponente, die die Firmware an die Unterkomponente übergibt, liegt außerhalb des Umfangs dieser Spezifikation.

• Die Spezifikation unterstützt das Konzept eines Angebots und basiert auf der verantwortlichen Komponente, um zu entscheiden, ob die Firmware akzeptiert werden soll. Die Entscheidung, neue Firmware anzunehmen, ist nicht trivial. Es kann Abhängigkeiten zwischen dem Firmwaretyp und/oder der version und dem zugrunde liegenden Typ/der zugrunde liegenden Hardware geben, für den die neue Firmware gilt. Ein Angebot fungiert auch als Optimierungsmechanismus, da das Firmwareimage nur dann an die Komponente gesendet wird, wenn es /bereit ist, es anzunehmen.

1.1 Glossar

1.2 Umfang

1.2.1 Ziele

• Eine Lösung, die unabhängig von der Busspezifikation ist, ist erforderlich, um zu vermeiden, dass für jeden Bustyp ein neues Protokoll erforderlich wird. HID ist allgegenwärtig und behebt diese Anforderung.

• Die Möglichkeit zum Unterstützen des Firmwareupdates für ein Mehrkomponentengerät, bei dem eine Komponente als primäre Komponente fungiert und andere Unterkomponenten mit der primären Komponente verbunden sind. Jede Komponente erfordert eine eigene Firmware mit nicht trivialen Abhängigkeiten miteinander.

• Ein gängiges Treibermodell zum Herunterladen des Firmwareimages in die Komponente. Die Komponente verfügt dann über unterkomponnente spezifische Algorithmen 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 übergeben.

• Die Möglichkeit, firmwareupdates zu unterstützen, während der Gerätevorgang ausgeführt wird.

• Die Möglichkeit, die Firmware auf Produktionsgeräten über autorisierte Tools zu aktualisieren/zurückzugeben und Marktgeräte über Windows Update zu aktualisieren.

• Die Flexibilität, Firmware in der Entwicklung sowie Markt-Firmware zu unterstützen.

• Die Möglichkeit, ein großes Firmwareimage in kleinere Segmente zu segmentieren, damit die Komponente das Firmwareimage leichter akzeptiert.

1.2.2 Nichtziele

• Definieren Sie das interne Format des Firmwareimages: Für den Host ist das Firmwareimage eine Reihe von Adress- und Nutzlasteinträgen.

• Signieren/verschlüsseln/überprüfen Sie die akzeptierte Firmware: Diese Spezifikation beschreibt nicht, wie die Firmwareimages signiert und verschlüsselt werden. Es ist erforderlich, dass die erwartete aktuelle Firmware, die auf der Komponente ausgeführt wird, die Firmware überprüft, die heruntergeladen wird.

• 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 Unterkomponentenfirmware fungieren.

2 Unterstützte Hardwarearchitektur

Um ein flexibles Hardwaredesign zu unterstützen, unterstützt das Protokoll ein Mehrkomponentengerät, auf 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 Mehrkomponentengerät ist für das Betriebssystem als 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 liegt außerhalb des Umfangs dieser Spezifikation.

Auf einem PC gibt es möglicherweise viele verschiedene Geräte (bei denen ein Gerät möglicherweise über eine oder mehrere Komponenten verfügt). Im Rahmen dieses Protokolls ist die Kommunikation mit jedem Gerät unabhängig. Jedes Gerät verfügt über eine entsprechende Instanz des Hosts.

3 Protokollvoraussetzungen

In diesem Abschnitt werden die bewährten Methoden und Voraussetzungen aufgeführt, die implementiert werden müssen, um dieses Protokoll zu nutzen:

• Verwendung von Atombildern

  Ein Firmwareimage für eine Komponente wird erst verwendet, wenn das gesamte Firmwareimage erfolgreich heruntergeladen wurde. Falls die Firmware in mehrere Segmente aufgeteilt ist, darf das Bild erst verwendet werden, wenn das endgültige Segment vom Absender empfangen wird. Integritätsprüfungen müssen für das endgültige Abbild durchgeführt werden. Es wird empfohlen, dass der Transport, der zum Bereitstellen des Firmwareimages verwendet wird, Fehlerkorrektur- und Wiederholungsmechanismen enthält, um einen wiederholten Download bei Transportfehlern zu vermeiden.

• Das Firmwareupdate darf den Gerätebetrieb nicht unterbrechen.

  Das Gerät, das das Firmwareimage akzeptiert, muss während des Updates ausgeführt werden können. Das Gerät muss zusätzlichen Arbeitsspeicher haben, um die eingehende Firmware zu speichern und zu überprüfen, während die aktuelle Firmware nicht überschrieben wird.

• Authentifizierung und Integrität

  Der Implementierer entscheidet, welche Faktoren ein authentisches Firmwareimage darstellen. Es wird empfohlen, dass die aktuelle Firmware der Komponente mindestens das CRC des eingehenden Firmwareimages überprüfen muss. Die aktuelle Firmware sollte auch digitale Signaturen oder andere Fehlererkennungsalgorithmen verwenden. Wenn die Überprüfung fehlschlägt, lehnt die Firmware das Update ab. Fehlerwiederherstellung

  Wenn das Firmwareimage heruntergeladen 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 Häufigkeit der Wiederholungsversuche ist implementierungsspezifisch.

• Vertraulichkeit

  Wahlfrei. Ein Firmwaresegment kann verschlüsselt werden. Die Verschlüsselungs- und Entschlüsselungstechniken liegen außerhalb des Umfangs dieser Spezifikation. Diese Spezifikation behandelt die Firmwarenutzlast als Datenstrom, unabhängig davon, ob sie verschlüsselt ist.

• Rollbackschutz

  Rollbackrichtlinien werden von der primären Komponente erzwungen und sind implementierungsspezifisch. Die aktuelle Firmware der Komponente überprüft eingehende Firmwareimages anhand interner Richtlinien, wie zum Beispiel, dass die Versionsnummer neuer sein muss oder der Versionstyp nicht von einer finalen Version zu einer Debug-Version gewechselt werden kann, und so weiter. Das Protokoll erlaubt es der Nachrichtenübermittlung anzugeben, dass ein Update akzeptiert wird, selbst wenn es gegen die Rollback-Richtlinien 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äteaktualisierungsreihenfolge Abhängigkeiten hat, akzeptiert das Gerät möglicherweise bestimmte Angebote im ersten Durchgang nicht, daher ermöglicht es dem Host, alle Firmwareangebote an das Gerät erneut zu senden, bis alle Abhängigkeiten aufgelöst werden.

4.1 Firmware-Update-Programmierungsbefehlssequenz

Hier sehen Sie die CFU-Befehlssequenz zum Aktualisieren des Firmwareimages.

4.1.1 Status: Initialisierte Hostbenachrichtigung

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 anzugeben, dass der Host jetzt initialisiert ist. Der Zweck dieses Befehls besteht darin, die aktuelle Gerätefirmware zu benachrichtigen, dass eine neue Instanz des Hosts verfügbar ist. Diese Benachrichtigung ist nützlich, wenn eine vorherige Instanz des Hosts unerwartet beendet wird. Das Gerät muss diesen Befehl erfolgreich abschließen.

4.1.2 Zustand: OFFER_INFO_START_OFFER_LIST Benachrichtigung

In diesem Zustand gibt host den befehl OFFER_INFO_START_OFFER_LIST aus, um anzugeben, dass es bereit ist, die Angebote an die aktuelle Gerätefirmware zu senden. Die primäre Komponente des Geräts muss diesen Befehl erfolgreich abschließen.

Dieser Befehl ist nützlich, da der Host möglicherweise alle Angebote mehrmals an das Gerät sendet.

4.1.3 Status: Befehl "FIRMWARE_UPDATE_OFFER senden"

Der Host sendet ein Angebot an die primäre Komponente (oder deren Unterkomponente), um zu überprüfen, ob die Komponente die Firmware annehmen/ablehnen möchte. Das Angebot enthält alle erforderlichen Metadaten zum Firmwareimage, damit die aktuelle Firmware der Komponente entscheiden kann, ob das Angebot angenommen, pendiert, übersprungen oder abgelehnt werden soll.

Das Angebot kann für die primäre Komponente oder den Unterkomponenten gelten. Wenn die Komponente das Angebot annehmen kann, bereitet sie sich auf den Empfang der Firmware vor. Dies kann die Vorbereitung einer Speicherbank für den Empfang des eingehenden Firmwareimages umfassen. Die Komponente akzeptiert das Angebot möglicherweise nicht, beispielsweise verfügt die Komponente bereits über eine neuere (oder dieselbe) Firmwareversion, die der Host senden möchte. Weitere Gründe finden Sie in den in Anhang 1 beschriebenen Beispielen: Beispiel für die Firmwareupdateprogrammierungsbefehlssequenz.

Auch wenn ein Angebot akzeptiert wird, kann die primäre Komponente das Firmwareimage nach dem Download auf Integritätsfehler und/oder Rollbackprüfungen auf das empfangene tatsächliche Image weiterhin ablehnen. Die Komponente muss jede Firmware-Image-Eigenschaft unabhängig von 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.

Wenn die Komponente das Angebot akzeptiert, erhält sie FIRMWARE_UPDATE_OFFER_ACCEPT Status und akzeptiert damit das Angebot.

Wenn die Gerätefirmware ausgelastet ist und die primäre Komponente dieses oder das nächste Angebot derzeit nicht akzeptieren kann, sendet sie eine Beschäftigt-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 Unterkomponenten), antwortet sie mit einem FIRMWARE_UPDATE_OFFER_SKIP, der angibt, dass es an dieser Firmware interessiert ist, kann es jedoch nicht annehmen. 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, der den entsprechenden Ablehnungsgrund angibt. Dieser Status gibt nicht an, dass der Host dieses Angebot in Zukunft nicht erneut senden kann. Der Host sendet jedes Angebot in der Regel jedes Mal, wenn es die Liste der Angebote an das Gerät initialisiert oder erneut sendet (siehe Status: OFFER_INFO_START_OFFER_LIST Benachrichtigung).

4.1.4 Status: Firmware senden

In diesem Zustand beginnt der Host, das Firmwareimage an die primäre Komponente zu senden, für die die Komponente das Angebot zuvor akzeptiert hat.

Da der Inhalt des Firmwareimages wahrscheinlich die Nutzlastgrenzwerte eines einzelnen Befehls übergehen wird, bricht der Host die Firmwareimages in Pakete auf. Der Host sendet jedes Paket sequenziell in einem separaten FIRMWARE_UPDATE CONTENT-Befehl. Die primäre Komponente muss ein Antwortpaket für jeden Befehl 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, legt es das FIRMWARE_UPDATE_FLAG_FIRST_BLOCK Flag fest, das angibt, dass es sich um das erste Paket des Firmwareimages handelt. Falls sich das Gerät noch nicht darauf vorbereitet hat, die Firmware zu empfangen, kann es dies jetzt tun.

Für das letzte Paket, das der Host sendet, setzt er das Flag FIRMWARE_UPDATE_FLAG_LAST_BLOCK.

Nachdem die aktuelle Firmware auf dem Gerät die teilielle 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 minimal Folgendes:

• Eine CRC-Überprüfung, um die Integrität des gesamten Firmwareimages zu überprüfen.

• Wenn die CRC-Überprüfung erfolgreich ist, kann optional die Signatur des eingehenden Bildes überprüft werden.

• Nach der optionalen Signaturüberprüfung wird eine Version überprüft, um sicherzustellen, dass die neue Firmwareversion identisch oder neuer ist als die vorhandene Firmware.

Falls das eingehende Firmwareimage in kleinere Segmente unterteilt wurde, liegt es bei der aktuellen Firmware, um festzustellen, ob es sich um das letzte Segment des Firmwareimages handelt, und anschließend alle Segmente als Teil der Überprüfung einschließen.

Wenn die vorherigen Überprüfungen bestehen, kann die aktuelle Firmware das Gerät so einrichten, dass es beim nächsten Zurücksetzen auf das neue Image wechselt, und meldet den Erfolg an den Host. In der Regel führt die Komponente keinen Selbstreset durch. Dies ist die Verhinderung von Unterbrechungen in Software, Firmware, Hardwareentitäten, 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 Swap einrichten und muss dem Host eine Fehlerantwort zurückgeben.

4.1.5 Entscheidungsstaat: 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 abschließen.

4.1.7 Entscheidungszustand: Angebotsliste wiederholen

Der Host bestimmt, ob es alle Angebote erneut senden muss. Dieser Fall kann auftreten, wenn zuvor die primäre Komponente einige Angebote übersprungen und einige Angebote akzeptiert hatte. Der Host muss die Angebotsliste erneut abspielen.

Möglicherweise gibt es eine andere implementierungsspezifische Logik, die zu einer Entscheidung zur Wiedergabe der Angebotsliste führen kann.

4.1.8 Zustand: 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, an den das Gerät nicht mit Akzeptanz reagiert, bis das Gerät frei ist.

5 CFU Protokollpaket-Format

Das CFU-Protokoll wird als Satz von Befehlen und Antworten implementiert. Das Protokoll ist in der Natur sequenziell. Für jeden Befehl, den der Host an eine Komponente sendet, wird erwartet, dass die Komponente antwortet (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, basierend auf der Antwort, die von der primären Komponente über die abgefragten Versionsinformationen empfangen wurde. Die Informationen werden für die Protokollierung oder andere Zwecke auffindbar gemacht.

5.1 GET_FIRMWARE_VERSION (Firmwareversion abrufen)

Ruft die aktuelle Firmwareversion(en) der primären Komponente (und deren Unterkomponenten) ab. Der Befehl hat keine Argumente.

Befehl 5.1.1

Dieser Befehl wird vom Host gesendet, um die Version(en) der aktuellen Firmware(en) der primären Komponente (und deren Unterkomponenten) abzufragen. Der Host kann es verwenden, um zu bestätigen, ob die Firmware erfolgreich aktualisiert wurde. Beim Empfang dieses Befehls antwortet die primäre Komponente mit der Firmwareversion für sich selbst und allen Unterkomponenten.

5.1.2 Antwort

Die Komponente antwortet mit der Firmwareversion der primären Komponente und den Unterkomponenten. Die Antwortgröße beträgt 60 Byte, die Versionsinformationen für bis zu sieben Komponenten zulassen (eine primäre und bis zu sechs Unterkomponenten).

Tabelle 5.1-1 GET_FIRMWARE_VERSION Antwortlayout

5.1.2.1 Kopfzeile

Tabelle 5.1-2 GET_FIRMWARE_VERSION Antwort – Kopfzeilenlayout

Der Header für die Antwort enthält die folgenden Informationen.

Tabelle 5.1-3 GET_FIRMWARE_VERSION Antwort – Header-Bits

5.1.2.2 Komponentenversion und -eigenschaften

Für jeweils bis zu 7 Komponenten werden zwei DWORDs verwendet, um deren Eigenschaften zu beschreiben. Wenn die Anzahl der Komponenten im Header kleiner als 7 ist, muss das nicht verwendete DWORDS am Ende der Antwort auf 0 festgelegt werden.

Tabelle 5.1-4 GET_FIRMWARE_VERSION Antwort – Komponentenversions- und Eigenschaftenlayout

Jede Komponentenspezifische Informationen werden in zwei DWORDs wie folgt beschrieben:

Tabelle 5.1-5 GET_FIRMWARE_VERSION-Antwort – Komponentenversion und Eigenschaften Bits

5.1.3 Zuordnung zu HID

Dies wird zusätzlich zur Berichts-ID als HID Get Feature-Anforderung mit einer Antwortgröße von 60 Byte implementiert. Die Länge des Featureberichts entspricht der gesamten GET_FIRMWARE_VERSION Antwort. Der Anforderung "Feature abrufen" vom Host sind keine Daten zugeordnet.

5.2 FIRMWARE_AKTUALISIERUNGSANGEBOT

Bestimmt, ob die primäre Komponente eine Firmware akzeptiert oder ablehnt.

Befehl 5.2.1

Der Host sendet diesen Befehl an die Komponente, um festzustellen, ob er eine Firmware akzeptiert oder ablehnt. Der Host muss ein Angebot senden, und die Komponente muss das Angebot akzeptieren, bevor der Host die Firmware senden kann.

Das FIRMWARE_UPDATE_OFFER Befehlspaket wird wie folgt definiert.

Tabelle 5.2-1 FIRMWARE_UPDATE_OFFER Befehlsstruktur

5.2.1.1 Komponenteninformationen

Tabelle 5.2-2 FIRMWARE_UPDATE_OFFER-Befehl – Komponenten-Informationslayout

Die Bits des Komponenteninformationsbytes werden in dieser Tabelle beschrieben.

Tabelle 5.2-3 FIRMWARE_UPDATE_OFFER Befehl – Komponenteninformationsbits

5.2.1.2 Firmwareversion

Diese vier Bytes stellen die 32-Bit-Version der Firmware dar. Das Format für die Firmwareversion wird von dieser Spezifikation nicht vorgeschrieben. Folgendes wird empfohlen.

Tabelle 5.2-4 FIRMWARE_UPDATE_OFFER Befehl – Firmwareversionslayout

Das Format für die Firmwareversion wird von dieser Spezifikation nicht vorgeschrieben, es folgt jedoch eine empfohlene Richtlinie.

Tabelle 5.2-5 FIRMWARE_UPDATE_OFFER Befehl – Firmwareversionsbits

5.2.1.3 Anbieterspezifisch

Diese vier Bytes können verwendet werden, um benutzerdefinierte Informationen im Angebot zu codieren, die für die Anbieterimplementierung spezifisch sind.

5.2.1.4 Sonstige und Protokollversion

Diese vier Bytes können verwendet werden, um benutzerdefinierte Informationen im Angebot zu codieren, die für die Anbieterimplementierung spezifisch sind.

Tabelle 5.2-6 FIRMWARE_UPDATE_OFFER Befehl – Anbieterspezifisches Layout

Die Bits des anbieterspezifischen Byte werden in dieser Tabelle beschrieben.

Tabelle 5.2-7 FIRMWARE_UPDATE_OFFER Befehl – Sonstiges und Protokollversion

5.2.2 Antwort

Das FIRMWARE_UPDATE_OFFER Antwortpaket wird 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 – Token Bits

5.2.2.2 Reserviert (B7 - B4)

Reserviert. Verwenden Sie es nicht.

5.2.2.3 Ablehnungsgrund (RR)

Tabelle 5.2-11 FIRMWARE_UPDATE_OFFER Antwort - Layout der Ablehnungsgründe

Tabelle 5.2-12 FIRMWARE_UPDATE_OFFER Antwort – Ablehnungsgrund-Bits

Die Bits des "Ablehnungsgrund"-Bytes werden in dieser Tabelle beschrieben.

Tabelle 5.2-13 FIRMWARE_UPDATE_OFFER Antwort-RR-Codewerte

Die möglichen Werte für das RR-Codebyte werden in dieser Tabelle beschrieben.

5.2.2.4 Status

Tabelle 5.2-14 FIRMWARE_UPDATE_OFFER Antwortstatus-Layout

Die Bits des Statusbytes werden in dieser Tabelle beschrieben.

Tabelle 5.2-15 FIRMWARE_UPDATE_OFFER Rückmeldung – Statusbits

Die möglichen Werte für das Statusbyte werden in dieser Tabelle beschrieben.

Tabelle 5.2-16 FIRMWARE_UPDATE_OFFER Antwortstatuswerte

5.2.3 Zuordnung zum HID-Protokoll

Die Nachricht wird über den HID-Ausgabeberichtsmechanismus an die Komponente ausgegeben, indem die dedizierte HID-Hilfsprogrammbericht-ID für Firmwareupdates verwendet wird. ** Die HID Utility TLC, die im Anhang beschrieben wird, zu verwenden.

5.3 FIRMWARE_UPDATE_OFFER - Informationen

Wenn die Komponenten-ID in den Komponenteninformationsbytes (siehe Komponenteninformationen) auf 0xFF festgelegt ist, werden Bits (15 Byte) neu definiert, um nur Angebotsinformationen anzugeben, vom Host bis zur Komponente. Dieser Mechanismus ermöglicht die Erweiterbarkeit und eine Möglichkeit für den Host, bestimmte Informationen für das Gerät bereitzustellen, z. B. "Angebotsliste starten", "Angebotsliste beenden", "Gesamte Transaktion starten". Angebotsinformationspakete werden immer sofort von der Komponente akzeptiert.

Befehl 5.3.1

Das FIRMWARE_UPDATE_OFFER -Information Befehlspaket ist wie folgt definiert:

Tabelle 5.3-1 FIRMWARE_UPDATE_OFFER – Informationsbefehlslayout

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 – Informationskommando – Komponenten-Bits

Tabelle 5.3-4 FIRMWARE_UPDATE_OFFER – Informationsbefehl – Werte des Informationscodes

5.3.1.2 Reserviert b7 - B4

Reserviert. Verwenden Sie es nicht.

5.3.1.3 Reserviert B11 - B8

Reserviert. Verwenden Sie es nicht.

5.3.1.4 Reserviert B15 - B12

Reserviert. Verwenden Sie es nicht.

5.3.2 Antwort

Das Antwortpaket für das "Angebot zur Firmware-Aktualisierung" – "Information Response" wird wie folgt definiert.

Tabelle 5.3-5 FIRMWARE_UPDATE_OFFER – Informationsantwortlayout

5.3.2.1 Kennung

Tabelle 5.3-6 FIRMWARE_UPDATE_OFFER– Layout des Informationspaket-Antworttokens

Die Bits des Tokenbytes werden in dieser Tabelle beschrieben.

Tabelle 5.3-7 FIRMWARE_UPDATE_OFFER – Informationsantwort – Token-Bits

5.3.2.2 Reserviert B7 - B4

Reserviert. Verwenden Sie es nicht.

5.3.2.3 Ablehnungsgrund (RR)

Tabelle 5.3-8 FIRMWARE_UPDATE_OFFER – Informationsantwort – RR-Codelayout

Die Bits des "Ablehnungsgrund"-Bytes werden in dieser Tabelle beschrieben.

Tabelle 5.3-9 FIRMWARE_UPDATE_OFFER – Angebotsinformationsantwort – RR-Code-Bits

Die möglichen Werte für das RR-Codebyte werden in dieser Tabelle beschrieben.

Tabelle 5.3-10 FIRMWARE_UPDATE_OFFER– Informationsantwort – RR-Codewerte

5.3.2.4 Status

Tabelle 5.3-11 FIRMWARE_UPDATE_OFFER – Angebotsinformationsantwortstatus-Layout

Die Bits des Statusbytes werden in dieser Tabelle beschrieben.

Tabelle 5.3-12 FIRMWARE_UPDATE_OFFER – Angebotsinformationen – Antwortstatus-Bits

5.4 FIRMWARE_UPDATE_OFFER - Erweitert

Wenn die Komponenten-ID in den Komponenteninformationsbytes auf 0xFE festgelegt ist, werden Bits (15 Byte) neu definiert, um den Angebotsbefehl vom Host bis zur Gerätefirmware anzugeben. Dieser Mechanismus ermöglicht die Erweiterbarkeit und eine Möglichkeit für den Host, bestimmte Informationen für das Gerät bereitzustellen. Angebotsbefehlspakete werden zurückgegeben, wenn die Komponente bereit ist, auf "Accepted" zu antworten.

Befehl 5.4.1

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 – Erweitertes 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

Tabelle 5.4-4 FIRMWARE_UPDATE_OFFER – Erweiterter Befehl – Befehlscodewerte

5.4.1.2 Reserviert B7 - B4

Reserviert. Verwenden Sie es nicht.

5.4.1.3 Reserviert B11 - B8

Reserviert. Verwenden Sie es nicht.

5.4.1.4 Reserviert B15 - B12

Reserviert. Verwenden Sie es nicht.

5.4.2 Antwort

Die FIRMWARE_UPDATE_OFFER – Angebotsbefehlsantwort vom Gerät wird möglicherweise nicht sofort empfangen. Die Antwort wird wie folgt definiert.

Tabelle 5.4-5 FIRMWARE_UPDATE_OFFER – Layout der erweiterten Befehlspaket-Antwort

5.4.2.1 Token

Tabelle 5.4-6 FIRMWARE_UPDATE_OFFER – Befehlsantwort auf Angebotspaket – Tokenlayout

Die Bits des Tokenbytes werden in dieser Tabelle beschrieben.

Tabelle 5.4-7 FIRMWARE_UPDATE_OFFER – Befehlsantwort anbieten – Tokenbits

5.4.2.2 Reserviert B7 - B4

Reserviert. Verwenden Sie es nicht.

5.4.2.3 Ablehnungsgrund

Tabelle 5.4-8 FIRMWARE_UPDATE_OFFER – Angebotsinformationspaket-Response-RR-Layout

Die Bits des "Ablehnungsgrund"-Bytes werden in dieser Tabelle beschrieben.

Tabelle 5.4-9 FIRMWARE_UPDATE_OFFER – Angebotene Befehlsantwort – RR Code

Die möglichen Werte für das RR-Codebyte werden in dieser Tabelle beschrieben.

Tabelle 5.4-10 FIRMWARE_UPDATE_OFFER- Angebotsbefehlspaket - RR-Codewerte

5.4.2.4 Status

Tabelle 5.4-11 FIRMWARE_UPDATE_OFFER – Layout des Paketantwortstatus für Angebotsbefehl

Die Bits des Statusbytes werden in dieser Tabelle beschrieben.

Tabelle 5.4-12 FIRMWARE_UPDATE_OFFER: Befehlspaketantwort-RR-Code anbieten

5.5 FIRMWARE_UPDATE_CONTENT

Der Host sendet diesen Befehl an die Gerätefirmware, um den Firmwareinhalt (d. a. das Firmwareimage) bereitzustellen. Es wird nicht erwartet, dass die gesamte Bilddatei in einen einzelnen Befehl passt. Der Host muss das Bild in kleinere Blöcke unterteilen, und jeder Befehl sendet jeweils einen Block des Bilds.

Bei jedem Befehl gibt der Host zusätzliche Informationen an – unabhängig davon, 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 Speicher 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 Prüfungen wird für den letzten Block eine entsprechende Antwort (Fehler oder Erfolg) zurückgegeben.

Befehl 5.5.1

Tabelle 5.5-1, FIRMWARE_UPDATE_CONTENT Befehlsstruktur

5.5.1.1 Kopfzeile (B7 - B0)

Tabelle 5.5-2 FIRMWARE_UPDATE_CONTENT Befehlsheader-Layout

Die Bits des FIRMWARE_UPDATE_CONTENT Headers werden in dieser Tabelle beschrieben.

Tabelle 5.5-3 FIRMWARE_UPDATE_CONTENT Kopfzeilenbits

Die möglichen Werte für das Flags-Byte werden in dieser Tabelle beschrieben.

Tabelle 5.5-4 FIRMWARE_UPDATE_OFFER - Angebots-Befehlsdatenpaket - Flagwerte

5.5.1.2 Daten

Tabelle 5.5-5 FIRMWARE_UPDATE_CONTENT Command Data Layout

Die Bits der FIRMWARE_UPDATE_CONTENT Daten werden in dieser Tabelle beschrieben.

Tabelle 5.5-6 FIRMWARE_UPDATE_CONTENT Befehlsdaten-Bits

5.5.2 Antwort

Tabelle 5.5-7 FIRMWARE_UPDATE_CONTENT Befehlsantwort-Layout

5.5.2.1 Sequenznummer

Tabelle 5.5-8 FIRMWARE_UPDATE_CONTENT Antwort – Sequenznummer

Die Bits der FIRMWARE_UPDATE_CONTENT Antwort (3-0) werden in dieser Tabelle beschrieben.

Tabelle 5.5-9 FIRMWARE_UPDATE_CONTENT – Befehl – Antwortbits

5.5.2.2 Status

Tabelle 5.5-10 FIRMWARE_UPDATE_CONTENT Antwort-Status-Layout

Die Bits der FIRMWARE_UPDATE_CONTENT Antwort (7-4) werden in dieser Tabelle beschrieben.

Tabelle 5.5-11 FIRMWARE_UPDATE_OFFER – Antwort – Status-Bits

Die möglichen Werte für das Statusbyte werden in dieser Tabelle beschrieben.

Tabelle 5.5-12 FIRMWARE_UPDATE_OFFER– Antwort – Statuscodewerte

5.5.2.3 Reserviert B8 - B11

Reserviert. Verwenden Sie es nicht.

5.5.2.4 Reserviert B12 - B15

Reserviert. Verwenden Sie es nicht.

6 Anhang 1: Beispiel für eine Firmware-Update-Programmierungsbefehlssequenz

6.1 Beispiel 1

Berücksichtigen Sie die folgende Gerätefirmware:

• Primäre Komponente – Komponenten-ID 1 – Aktuelle Firmwareversion 7.0.1

• Unterkomponente - Komponenten-ID 2 - Aktuelle Firmwareversion 12.4.54

• Unterkomponente – Komponenten-ID 3 – Aktuelle Firmwareversion 4.4.2

• Unterkomponente - Komponenten-ID 4 - Aktuelle Firmwareversion 23.32.9

Der Host verfügt über diese 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 wird wie folgt sein:

1. Hostangebote: Komponenten-ID 1 – Firmware-Version 7.1.3

2. Primäre Komponente akzeptiert das Angebot

3. Host sendet das Firmwareimage

4. Primäre Komponente akzeptiert Firmware, überprüft sie.

5. Hostangebote: Komponenten-ID 2 – Firmware-Version 12.4.54

6. Primäre Komponente lehnt das Angebot ab

7. Hostangebote: Komponenten-ID 3 - Firmware-Version 4.5.0

8. Primäre Komponente akzeptiert das Angebot

9. Host sendet das Firmwareimage

10. Primäre Komponente akzeptiert Firmware, überprüft sie.

Da nicht alle Angebote abgelehnt wurden, spielt der Host alle Angebote erneut ab.

1. Hostangebote: Komponenten-ID 1 – Firmware-Version 7.1.3

2. Komponente lehnt ab

3. Angebote des Hosts: Komponenten-ID 2 – Firmware-Version 12.4.54

4. Komponente lehnt ab

5. Hostangebote: Komponenten-ID 3 - Firmware-Version 4.5.0

6. Komponente lehnt ab

6.2 Beispiel 2

Berücksichtigen Sie die folgende Gerätefirmware:

• Primäre Komponente – Komponenten-ID 1 – Aktuelle Firmwareversion 7.0.1

• Unterkomponente - Komponenten-ID 2 - Aktuelle Firmwareversion 12.4.54

• Unterkomponente - Komponenten-ID 3 - Aktuelle Firmwareversion 7.4.2

• Unterkomponente - Komponenten-ID 4 - Aktuelle Firmwareversion 23.32.9

Der Host verfügt über diese 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 sein darf als die Firmwareversion, die auf der primären Komponente ausgeführt wird. Der Host ist sich dieser Anforderung nicht bewusst, und up-to ist die primäre Komponente, um diese Regel sicherzustellen.

Die Sequenz wird wie folgt sein:

1. Hostangebote: Komponenten-ID 1 – Firmware-Version 8.0.0

2. Primäre Komponente lehnt ab (da die Komponenten-ID 3 noch nicht aktualisiert wurde)

3. Host-Angebote: Komponenten-ID 2 – Firmware-Version 12.4.54

4. Primäre Komponente lehnt ab

5. Host-Angebote: Komponenten-ID 3 – Firmware-Version 9.0.0

6. Primäre Komponente akzeptiert Angebot

7. Host sendet das Firmwareimage

8. Primäre Komponente akzeptiert Firmware, überprüft sie.

Da alle Angebote nicht abgelehnt wurden, gibt der Host alle Angebote wieder.

1. Hostangebote: Komponenten-ID 1 – Firmware-Version 8.0.0

2. Primäre Komponente akzeptiert Angebot

3. Host sendet das Firmwareimage

4. Primäre Komponente akzeptiert Firmware, überprüft sie.

5. Hostangebote: Komponenten-ID 2 – Firmware-Version 12.4.54

6. Primäre Komponente lehnt ab

7. Hostangebote: Komponenten-ID 3 – Firmware-Version 9.0.0

8. Primäre Komponente lehnt ab