コンポーネント ファームウェア更新 (CFU) プロトコルの仕様
この仕様では、PC またはアクセサリに存在するコンポーネントのファームウェアを更新する汎用 HID プロトコルについて説明します。 この仕様により、ダウンロード中にデバイスの操作を中断することなく、コンポーネントがファームウェアを受け入れることが可能になります。 この仕様では、ファームウェアを受け入れるコンポーネントにサブコンポーネントがあり、個別のファームウェア イメージが必要な構成がサポートされています。 この仕様により、コンポーネントは、課金中にファームウェアを受け入れるかどうかを決定できます。 また、ファームウェア イメージは受け入れ可能または準備ができている場合にのみコンポーネントに送信されるため、最適化としても機能します。
手記
CFU は、Windows 10 バージョン 2004 (Windows 10 May 2020 Update) 以降のバージョンで使用できます。
内容
- 1 概要
- 2 サポートされているハードウェアアーキテクチャ
- 3 プロトコルの前提条件
- 4 CFU プロトコルの概要
- 5 CFU プロトコル パケット形式
- 6 付録 1: ファームウェア更新プログラムのプログラミング コマンド シーケンスの例
表
表 5.1-1 GET_FIRMWARE_VERSION の応答レイアウト
表 5.1-2 GET_FIRMWARE_VERSION の応答 - ヘッダー レイアウト
表 5.1-3 GET_FIRMWARE_VERSION の応答 - ヘッダー ビット
表 5.1-4 GET_FIRMWARE_VERSION応答 - コンポーネントのバージョンとプロパティのレイアウト
表 5.1-5 GET_FIRMWARE_VERSION の応答 - コンポーネントのバージョンとプロパティ バイト
表 5.2-1 FIRMWARE_UPDATE_OFFER コマンド レイアウト
表 5.2-2 FIRMWARE_UPDATE_OFFER コマンド - コンポーネント情報レイアウト
表 5.2-3 FIRMWARE_UPDATE_OFFER コマンド - コンポーネント情報ビット
表 5.2-4 FIRMWARE_UPDATE_OFFER コマンド - ファームウェア バージョン レイアウト
表 5.2-5 FIRMWARE_UPDATE_OFFER コマンド - ファームウェア バージョン ビット
表 5.2-6 FIRMWARE_UPDATE_OFFER コマンド - ベンダー固有のレイアウト
表 5.2-7 FIRMWARE_UPDATE_OFFER コマンド - その他およびプロトコルのバージョン
表 5.2-8 FIRMWARE_UPDATE_OFFER応答トークンのレイアウト
表 5.2-9 FIRMWARE_UPDATE_OFFER の応答 - トークン レイアウト
表 5.2-10 FIRMWARE_UPDATE_OFFER の応答 - トークン ビット
表 5.2-11 FIRMWARE_UPDATE_OFFER の応答 - 理由レイアウトの拒否
表 5.2-12 FIRMWARE_UPDATE_OFFER の応答 - 理由ビットの拒否
表 5.2-13 FIRMWARE_UPDATE_OFFER の応答 RR コード値
表 5.2-14 FIRMWARE_UPDATE_OFFER の応答状態レイアウト
表 5.2-15 FIRMWARE_UPDATE_OFFER の応答 - 状態ビット
表 5.2-16 FIRMWARE_UPDATE_OFFER の応答状態の値
表 5.3-1 FIRMWARE_UPDATE_OFFER - 情報コマンド レイアウト
表 5.3-2 FIRMWARE_UPDATE_OFFER - 情報コマンド - コンポーネントレイアウト
表 5.3-3 FIRMWARE_UPDATE_OFFER - 情報コマンド - コンポーネント ビット
表 5.3-4 FIRMWARE_UPDATE_OFFER - 情報コマンド - 情報コード値
表 5.3-5 FIRMWARE_UPDATE_OFFER - 情報応答レイアウト
表 5.3-6 FIRMWARE_UPDATE_OFFER- 情報パケット応答トークンのレイアウト
表 5.3-7 FIRMWARE_UPDATE_OFFER - 情報応答 - トークン ビット
表 5.3-8 FIRMWARE_UPDATE_OFFER - RR コード レイアウト
表 5.3-9 FIRMWARE_UPDATE_OFFER - オファー情報応答 - RR コード ビット
表 5.3-10 FIRMWARE_UPDATE_OFFER - RR コード値
表 5.3-11 FIRMWARE_UPDATE_OFFER - オファー情報の応答状態レイアウト
表 5.3-12 FIRMWARE_UPDATE_OFFER - オファー情報 - 応答状態ビット
表 5.4-1 FIRMWARE_UPDATE_OFFER - 拡張コマンド レイアウト
表 5.4-2 FIRMWARE_UPDATE_OFFER - 拡張コマンド パケット - コマンド - コンポーネント レイアウト
表 5.4-3 FIRMWARE_UPDATE_OFFER - 拡張コマンド - コンポーネントビット
表5.4-4 FIRMWARE_UPDATE_OFFER - 拡張コマンド - コマンドコード値
表 5.4-5 FIRMWARE_UPDATE_OFFER - 拡張コマンド パケット応答レイアウト
表 5.4-6 FIRMWARE_UPDATE_OFFER- オファー コマンド パケットの応答 - トークン レイアウト
表 5.4-7 FIRMWARE_UPDATE_OFFER - オファー コマンドの応答 - トークン ビット
表 5.4-8 FIRMWARE_UPDATE_OFFER - オファー情報パケットの応答 RR レイアウト
表 5.4-9 FIRMWARE_UPDATE_OFFER- オファー コマンドの応答 - RR コード
表 5.4-10 FIRMWARE_UPDATE_OFFER- オファー コマンド パケット - RR コード値
表 5.4-11 FIRMWARE_UPDATE_OFFER- オファー コマンド パケットの応答状態レイアウト
表 5.4-12 FIRMWARE_UPDATE_OFFER- オファー コマンド パケットの応答 RR コード値
表 5.5-1 FIRMWARE_UPDATE_CONTENT コマンド レイアウト
表 5.5-2 FIRMWARE_UPDATE_CONTENT コマンド ヘッダー レイアウト
表 5.5-3 「FIRMWARE_UPDATE_CONTENT」ヘッダー ビット
表 5.5-4 FIRMWARE_UPDATE_OFFER-オファーコマンドパケット - フラグ値
表 5.5-5 FIRMWARE_UPDATE_CONTENT コマンド データ レイアウト
表 5.5-6 FIRMWARE_UPDATE_CONTENT コマンド データ ビット
表 5.5-7 FIRMWARE_UPDATE_CONTENTコマンドの応答レイアウト
表 5.5-8 FIRMWARE_UPDATE_CONTENT の応答 - シーケンス番号
表 5.5-9 FIRMWARE_UPDATE_CONTENT コマンド データ - 応答ビット
表 5.5-10 FIRMWARE_UPDATE_CONTENT の応答状態レイアウト
表 5.5-11 FIRMWARE_UPDATE_OFFER - 応答 - 状態ビット
表 5.5-12 FIRMWARE_UPDATE_OFFER - 応答 - 状態コード値
1 概要
今日の PC とアクセサリには、複雑な操作を実行する内部コンポーネントがあります。 品質の高い製品を確保するには、開発の後の段階で、または顧客に出荷した後に、これらのデバイスの動作を頻繁に更新する必要があります。 この更新プログラムは、特定された機能またはセキュリティの問題を修正したり、新しい機能を追加する必要がある場合があります。 複雑なロジックの大部分は、更新可能なデバイスで実行されているファームウェアにあります。
この仕様では、PC またはそのアクセサリに存在するコンポーネントのファームウェアを更新する汎用 HID プロトコルについて説明します。 HID の実装は、仕様の範囲を超えています。
プロトコルの機能の一部は次のとおりです。
プロトコルは HID (ユビキタス) に基づいており、USB や I2C などのさまざまな相互接続バスに対する Windows インボックス サポートを備えます。 したがって、同じソフトウェア (ドライバー) ソリューションを利用して、すべてのコンポーネントのファームウェアを更新できます。
手記
仕様はパケット ベースであるため、HID 以外のシナリオに適応するのは簡単です。
この仕様により、ダウンロード中にデバイスの操作を中断することなく、コンポーネントがファームウェアを受け入れることが可能になります。 これにより、他のタスクを再開する前にファームウェアの更新プロセスが完了するのを待つ必要がないため、ユーザーのエクスペリエンスが向上します。 新しいファームウェアは、ユーザーへの影響を最小限に抑える 1 回のアトミック操作で呼び出すことができます。
この仕様では、ファームウェアを受け入れるコンポーネントにサブコンポーネントがあり、個別のファームウェア イメージが必要な構成がサポートされています。
手記
サブコンポーネントにファームウェアを引き渡すコンポーネントのプロセスは、この仕様の範囲外です。
この仕様はオファーの概念を支持し、ファームウェアを受け入れるかどうかを決定するために、対応するコンポーネントに依存しています。 新しいファームウェアを受け入れるという決定は簡単ではありません。 ファームウェアの種類またはバージョンと、新しいファームウェアが適用されるハードウェアの基になる種類/バージョンの間に依存関係がある可能性があります。 また、オファーは最適化メカニズムとしても機能します。これは、ファームウェア イメージが受け入れ可能な場合にのみコンポーネントに送信されるためです。
1.1 用語集
| 用語 | 説明 |
|---|---|
| コンポーネント ID | 複数のコンポーネントを持つデバイスでは、コンポーネント ID によって各コンポーネントが一意に識別されます。 |
| CRC | 巡回冗長検査 データ ブロックのダイジェストまたはフィンガープリントを生成するために使用される非暗号化ハッシュ アルゴリズム。 CRC は、CRC が計算されてからデータ ブロックが変更されていないという保証を提供するためのチェックとして使用されます。 CRC は完璧ではないが、データが正しく受信されたことを保証する信頼性を与える。 |
| デバイス | コンポーネントのコレクション (1 つのプライマリ コンポーネントと 0 個以上のサブコンポーネント)。 デバイスは、1 つのユニットとしてオペレーティング システムに表示されます。 ホストはデバイスとやり取りします。これは通常、プライマリ コンポーネントです。 1 つのコンピューターに複数のデバイスが含まれる場合があります。 この仕様に関して、2つの異なるデバイスへの通信は完全に独立しています。 |
| 運転手 | Windows Driver Foundation (WDF) フレームワークを使用して記述されたドライバー。 |
| ファームウェア | 物理ハードウェアで実行されているコード。 ファームウェアは更新可能であり、通常はハードウェアに関連付けられているプログラミング可能なメモリ内に存在します。 |
| ハードウェア | コンピューター上のシリコンの物理的な部分。 |
| プライマリ コンポーネント | コンピューター上のハードウェアとそのファームウェア。 この仕様のコンテキストでは、コンポーネントはファームウェアの更新を必要とし、受け入れるエンティティです。 |
| セグメント | コンポーネントのファームウェア イメージは、より小さなセグメントにセグメント化できます。 各セグメントは小さなファームウェア イメージです。 |
| Segment ID | コンポーネントのファームウェアがより小さいセグメントにセグメント化されている場合、セグメント ID はセグメントの一意識別子です。 |
| 署名 | 暗号化とは、ファームウェア イメージが未承認の手段によって変更されたかどうかを判断する手段です。 署名は省略可能ですが、この仕様の範囲を超えて推奨されます。 |
| サブコンポーネント | ハードウェア アーキテクチャによっては、システムに表示されるコンポーネントのダウンストリームに接続されている可能性があるため、すべてのコンポーネントがオペレーティング システムに表示されるわけではありません。 これらのコンポーネントは、この仕様ではサブコンポーネントと呼ばれます。 |
| TLC | HID 最上位レベルのコレクション。 |
| トークン | ホスト セッションの識別子。 ホストがトークンを作成し、コマンドで送信すると、デバイスは応答でトークンを返します。 トークンは、特定のトランザクションをシリアル化したり、セッションが失われ、別のトランザクションが開始されたことを識別したりするために使用できます。 |
1.2 スコープ
1.2.1 目標
バスに依存しないソリューションは、すべての種類のバスの新しいプロトコルを回避するために必要です。 HID はユビキタスであり、その要件に対処します。
1 つのコンポーネントがプライマリ コンポーネントとして機能し、他のコンポーネントがプライマリ コンポーネントに接続されているサブコンポーネントであるマルチコンポーネント デバイスのファームウェア更新をサポートする機能。 各コンポーネントには、互いに単純でない依存関係を持つ独自のファームウェアが必要です。
ファームウェア イメージをコンポーネントにダウンロードするための一般的なドライバー モデル。 その後、コンポーネントには、サブコンポーネントに転送するためのサブコンポーネント固有のアルゴリズムがあります。 サブコンポーネントは、ファームウェアに対して有効性チェックを実行し、結果をプライマリ コンポーネントに戻すこともできます。
デバイス操作の進行中にファームウェアの更新をサポートする機能。
承認されたツールを使用して実稼働デバイスのファームウェアを更新/ロールバックし、Windows Update を使用して市場のデバイスを更新する機能。
開発中のファームウェア/市場内ファームウェアをサポートする柔軟性。
コンポーネントがファームウェア イメージを受け入れやすくするために、大きなファームウェア イメージをより小さなセグメントにセグメント化する機能。
1.2.2 目標外
ファームウェア イメージの内部形式を定義します。ホストの場合、ファームウェア イメージはアドレスとペイロード エントリのセットです。
受け入れられたファームウェアに署名/暗号化/検証する: この仕様では、ファームウェア イメージに署名して暗号化する方法については説明しません。 コンポーネントで実行されている予想される現在のファームウェアが、ダウンロードされているファームウェアを検証する必要があります。
コンポーネントがサブコンポーネントと対話する方法に関するメカニズムを定義します。ホストは、デバイスと 1 つのユニット (通常はプライマリ コンポーネント) として対話します。 コンポーネントは、サブコンポーネント ファームウェアに関連する通信のブリッジとして機能する必要があります。
2 サポートされているハードウェア アーキテクチャ
柔軟なハードウェア設計をサポートするために、プロトコルは、各コンポーネントが独自のファームウェア イメージを必要とするマルチコンポーネント デバイスをサポートします。 設計では、1 つのコンポーネントがプライマリ コンポーネントであり、依存サブコンポーネントがそのプライマリ コンポーネントに接続されています。 各コンポーネントは、コンポーネント ID によって一意に記述されます。
マルチコンポーネント デバイスは、オペレーティング システムから単一ユニットとして表示されます。 ホストはデバイス (通常は、この CFU プロトコルを使用するプライマリ コンポーネント) とのみ対話します。 コンポーネントとそのサブコンポーネント間の通信は、この仕様の範囲外です。
PC には、さまざまなデバイスが存在する可能性があります (デバイスに 1 つ以上のコンポーネントが存在する場合があります)。 このプロトコルのコンテキストでは、各デバイスへの通信は独立しています。 各デバイスには、ホストの対応するインスタンスがあります。
3 プロトコルの前提条件
このセクションでは、このプロトコルを活用するために実装する必要がある前提条件とベスト プラクティスを示します。
アトミック イメージの使用
コンポーネントのファームウェア イメージは、ファームウェア イメージ全体が正常にダウンロードされるまで使用されません。 ファームウェアが複数のセグメントに分割されている場合は、送信側から最終的なセグメントを受信するまでイメージを使用しないでください。 整合性チェックは、最終的なイメージで実行する必要があります。 トランスポートは、ファームウェア イメージの配信に使用され、トランスポート エラーが発生した場合に繰り返しダウンロードを回避するために、エラー修正と再試行メカニズムを備えておくことをお勧めします。
ファームウェアの更新でデバイスの操作を中断してはならない
ファームウェア イメージを受け入れるデバイスは、更新中に動作できる必要があります。 現在のファームウェアは上書きされませんが、デバイスには、受信ファームウェアを格納して検証するための追加のメモリが必要です。
認証と整合性
実装者は、本物のファームウェア イメージを構成する要素を決定します。 コンポーネントの現在のファームウェアは、少なくとも着信ファームウェア イメージの CRC を検証する必要があります。 現在のファームウェアでは、デジタル署名、またはその他のエラー検出アルゴリズムも使用する必要があります。 検証が失敗した場合、ファームウェアは更新プログラムを拒否します。 障害復旧
ファームウェア イメージのダウンロードに失敗した場合、デバイスは新しいファームウェアを呼び出さず、既存のファームウェアで動作し続ける必要があります。 ホストは更新を再試行できます。 再試行の頻度は実装固有です。
機密性
随意。 ファームウェア セグメントを暗号化できます。 暗号化と復号化の手法は、この仕様の範囲外です。 この仕様では、暗号化されているかどうかに関係なく、ファームウェアペイロードをデータストリームとして扱います。
ロールバック保護
ロールバック ポリシーは、プライマリ コンポーネントによって適用され、実装固有です。 コンポーネントの現在のファームウェアは、バージョン番号が新しい必要がある、リリースの種類をリリースからデバッグに切り替えることができないなどの内部ポリシーに対して、受信ファームウェア イメージを検証します。 このプロトコルでは、ロールバック ポリシーに違反している場合でも更新プログラムが受け入れられることを示すメッセージが許可されます。
4 CFU プロトコルの概要
CFU プロトコルは、新しいファームウェア イメージをホストからファームウェアの対象デバイスに送信するために必要な一連のコマンドと応答です。
大まかに言えば、プロトコルはデバイスに送信するすべてのファームウェア イメージを反復処理します。 ファームウェア イメージごとに、ホスト はデバイスにファイルを送信する を提供します。 デバイスがオファーを受け入れた場合にのみ、ホストはファイルを送信します。
デバイスの更新順序に依存関係がある場合をサポートするために、デバイスは最初のパスで特定のオファーを受け入れられない可能性があるため、プロトコルにより、すべての依存関係が解決されるまで、ホストはすべてのファームウェア オファーをデバイスに再送信できます。
4.1 ファームウェアアップデートプログラミングコマンドシーケンス
ファームウェア イメージを更新するための CFU コマンド シーケンスを次に示します。
4.1.1 状態: ホスト起動通知
ホストが自身を初期化し、デバイスに送信する必要があるオファーのセットを特定した後、ホストは、ホストが初期化されたことをコンポーネントに示すOFFER_INFO_START_ENTIRE_TRANSACTION コマンドを発行します。 このコマンドの目的は、ホストの新しいインスタンスが使用可能であることを現在のデバイス ファームウェアに通知することです。 この通知は、ホストの以前のインスタンスが予期せず終了した場合に役立ちます。 このコマンドを正しく完了する必要があります。
4.1.2 ステータス: OFFER_INFO_START_OFFER_LIST の通知
この状態では、ホストは OFFER_INFO_START_OFFER_LIST コマンドを発行して、オファーを現在のデバイス ファームウェアに送信する準備ができていることを示します。 デバイスのプライマリ コンポーネントは、成功した状態でこのコマンドを完了する必要があります。
このコマンドは、ホストがデバイスにすべてのオファーを複数回送信する可能性があるため便利です。
4.1.3 状態: FIRMWARE_UPDATE_OFFERコマンドを送信する
ホストは、プライマリ コンポーネント (またはそのサブコンポーネント) にオファーを送信して、コンポーネントがファームウェアを受け入れる/拒否するかどうかを確認します。 このオファーには、ファームウェア イメージに関して必要なすべてのメタデータが含まれているため、コンポーネントの現在のファームウェアは、オファーを受け入れる、ペンする、スキップする、または拒否するかどうかを決定できます。
オファーは、プライマリ コンポーネントまたはサブコンポーネント用の場合があります。 コンポーネントがオファーを受け入れる場合は、ファームウェアを受け取る準備をします。 これには、受信ファームウェア イメージを受信するためのメモリ バンクの準備が含まれる場合があります。 たとえば、コンポーネントはオファーを受け入れられない場合があります。たとえば、コンポーネントには、ホストが送信する新しい (または同じ) ファームウェア バージョンが既に存在している可能性があります。 その他の理由については、「付録 1: ファームウェア更新プログラムのプログラミング コマンド シーケンスの例」で説明されている例を参照してください。
オファーが受け入れられた場合でも、プライマリ コンポーネントは、ダウンロード後もファームウェア イメージを拒否して、整合性の障害や、受信した実際のイメージに対するロールバック チェックを拒否する可能性があります。 コンポーネントは、オファー内の情報に関係なく、各ファームウェア イメージ プロパティを確認する必要があります。
ホストは、FIRMWARE_UPDATE_OFFER コマンドを発行して、ホストが送信しようとしているファームウェア イメージについてプライマリ コンポーネントに通知します。
コンポーネントがオファーを受け入れる場合は、FIRMWARE_UPDATE_OFFER_ACCEPT状態でオファーを受け入れます。
デバイスのファームウェアがビジー状態で、プライマリ コンポーネントが現在このオファーまたは次のオファーを受け入れられない場合は、FIRMWARE_UPDATE_OFFER_BUSY状態のビジー状態の応答を送信します。
現在のファームウェアがオファーに関心があるが、オファーを受け入れることができない場合 (たとえば、サブコンポーネントの更新プログラムが不足しているため) は、このファームウェアに関心があることを示すFIRMWARE_UPDATE_OFFER_SKIPで応答しますが、それを受け入れることができません。 ホストは次のオファーに進み、後でこのファームウェアを再提供する必要があります。
現在のファームウェアがオファーに関心がない場合 (古いバージョンなど)、適切な拒否理由を提供するFIRMWARE_UPDATE_OFFER_REJECT状態で応答します。 この状態は、今後ホストがこのオファーを再送信できないことを示すわけではありません。 ホストは通常、オファーの一覧を初期化または再送信するたびに各オファーをデバイスに送信します (状態: OFFER_INFO_START_OFFER_LIST通知を参照)。
4.1.4 状態: ファームウェアの送信
この状態では、ホストは、コンポーネントが以前にオファーを受け入れたプライマリ コンポーネントへのファームウェア イメージの送信を開始します。
ファームウェア イメージの内容は 1 つのコマンドのペイロード制限を超える可能性が高いため、ホストはファームウェア イメージをパケットに分割します。 ホストは、個別の FIRMWARE_UPDATE CONTENT コマンドで各パケットを順番に送信します。 プライマリ コンポーネントは、コマンドごとに応答パケットを生成する必要があります。
各FIRMWARE_UPDATE CONTENT コマンドは、部分的なファームウェア ペイロードを含むオフセット アドレスを記述します。 コンポーネントはオフセットを使用して、部分的なファームウェア ペイロードを格納する必要があるアドレスを決定します。 デバイスはコンテンツを適切な場所に書き込み、応答を送信してコマンドを確認します。
ホストが送信する最初のパケットに対して、FIRMWARE_UPDATE_FLAG_FIRST_BLOCK フラグを設定し、これがファームウェア イメージの最初のパケットであることをデバイスに示します。 デバイスがファームウェアを受信するための準備をまだ行っていない場合は、この時点で行うことができます。
最後のパケットの場合、ホストは送信し、FIRMWARE_UPDATE_FLAG_LAST_BLOCK フラグを設定します。
デバイス上の現在のファームウェアがこのコマンドに含まれる部分的なファームウェア ペイロードを書き込んだ後、応答を送信する前に、受信ファームウェア イメージの検証と認証チェックを実行
ファームウェア イメージ全体の整合性を確認するための CRC チェック。
CRC チェックが成功した場合、受信イメージの署名のオプション検証。
オプションの署名チェックの後、新しいファームウェアのバージョンが既存のファームウェアと同じか新しいかどうかを確認するバージョン チェックを行います。
受信ファームウェア イメージがより小さいセグメントに分割された場合、ファームウェア イメージの最後のセグメントかどうかを判断するのは現在のファームウェアにかかっており、その後、検証の一部としてすべてのセグメントが含まれます。
上記のチェックに合格した場合、現在のファームウェアは、次回のリセット時に新しいイメージにスワップするようにデバイスを設定し、成功をホストに報告できます。 通常、コンポーネントは自己リセットを開始しません。 これは、コンポーネントが対話しているソフトウェア、ファームウェア、ハードウェア エンティティの中断を防ぐためです。 ただし、これは要件ではなく、実装によって異なる場合があります。
検証手順が失敗した場合、ファームウェアは次のリセット時にスワップを設定せず、ホストへのエラー応答を示す必要があります。
4.1.5 意思決定の状態: 他にもオファーがあるか
この状態では、ホストは、デバイスに送信するオファーが他にあるかどうかを判断します。
4.1.6 状態: OFFER_INFO_END_OFFER_LIST の通知
ホストが現在のデバイス ファームウェアのプライマリ コンポーネントにすべてのオファーを送信すると、この状態に達します。 ホストは、OFFER_INFO_END_OFFER_LIST コマンドを送信して、すべてのオファーがコンポーネントに送信されたことを示します。
デバイスは、このコマンドを成功裏に完了する必要があります。
4.1.7 決定状態: オファー一覧の再生
ホストは、すべてのオファーを再送信する必要があるかどうかを判断します。 このケースは、以前にプライマリ コンポーネントが一部のオファーをスキップし、一部のオファーを受け入れた場合に発生する可能性があります。 ホストは、オファーの一覧をもう一度再生する必要があります。
他の実装固有のロジックがあり、その結果、オファー一覧の再生が決定される可能性があります。
4.1.8 状態: デバイスがビジー状態
この状態は、デバイスがオファーに対してビジー応答を返したことを意味します。
ホストは OFFER_NOTIFY_ON_READY コマンドを送信しますが、デバイスは忙しくなくなるまで受け入れの応答をしません。
5 CFU プロトコル パケット形式
CFU プロトコルは、コマンドと応答のセットとして実装されます。 プロトコルは本質的にシーケンシャルです。 ホストがコンポーネントに送信するコマンドごとに、コンポーネントは応答する必要があります (この仕様で明示的に明記されていない限り)。 ホストは、送信した前のコマンドに対して有効な応答を受信するまで、次のコマンドを送信しません。
コンポーネントが一定期間内に応答しない場合、または無効な応答を送信した場合、ホストは最初からプロセスを再起動する可能性があります。 このプロトコルでは、特定のタイムアウト値は定義されません。
コンポーネント上の現在のファームウェアのバージョン情報を取得するコマンドがあります。オファーを送信し、ファームウェア イメージを送信します。
ただし、ホストは、クエリされたバージョン情報に関するプライマリ コンポーネントから受信した応答に基づいてオファーを保留する必要はありません。 情報は、ログやその他の目的で検出可能になります。
5.1 GET_FIRMWARE_VERSION（ファームウェアのバージョンを取得）
プライマリ コンポーネント (およびそのサブコンポーネント) の現在のファームウェア バージョンを取得します。 このコマンドには引数がありません。
5.1.1 コマンド
このコマンドは、プライマリ コンポーネント (およびそのサブコンポーネント) 上の現在のファームウェアのバージョンを照会するためにホストによって送信されます。 ホストはそれを使用して、ファームウェアが正常に更新されたかどうかを確認できます。 このコマンドを受信すると、プライマリ コンポーネントはそれ自体とすべてのサブコンポーネントのファームウェア バージョンで応答します。
5.1.2 応答
コンポーネントは、プライマリ コンポーネントとサブコンポーネントのファームウェア バージョンで応答します。 応答サイズは 60 バイトで、最大 7 つのコンポーネント (1 つのプライマリおよび最大 6 つのサブコンポーネント) のバージョン情報を許可します。
表 5.1-1 GET_FIRMWARE_VERSION応答レイアウト
5.1.2.1 ヘッダー
表5.1-2 GET_FIRMWARE_VERSION 応答 - ヘッダーレイアウト
応答のヘッダーは、次の情報を提供します。
表 5.1-3 GET_FIRMWARE_VERSION の応答 - ヘッダー ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | コンポーネント数 | 8 | このコンポーネントのこのメカニズムによって管理されるダウンロード可能なコンポーネントの数。 コンポーネント数によって、テーブルの最大サイズが決まります。 現在、応答が許可されている 60 バイト内に収まるように、最大 7 つのコンポーネントがサポートされています。 |
| 8 | 予約済み | 16 | 予約済みのフィールド。 送信者はこれらを 0 に設定する必要があります。 受信者はこの値を無視する必要があります。 |
| 24 | プロトコル のバージョン | 4 | ファームウェア更新リビジョン ビットは、現在トランスポートで使用されている FW 更新プロトコルのリビジョンを表します。 ここで定義するインターフェイスの場合、FW 更新リビジョンは 0010b である必要があります。 |
| 28 | 予約済み | 3 | 予約済みのフィールド。 送信者はこれらを 0 に設定する必要があります。 受信者はこの値を無視する必要があります。 |
| 31 | E | 1 | 拡張フラグは、追加のコンポーネントを報告できるようにするための将来のプロトコル フックです。 |
5.1.2.2 コンポーネントのバージョンとプロパティ
コンポーネントごとに、2 つの DWORD を使用して、最大 7 個のコンポーネントのプロパティを記述します。 ヘッダー内のコンポーネント数が 7 未満の場合は、応答の最後にある未使用の DWORDS を 0 に設定する必要があります。
表 5.1-4 GET_FIRMWARE_VERSION応答 - コンポーネントのバージョンとプロパティのレイアウト
各コンポーネント固有の情報は、次のように 2 つの DWORD で説明されています。
表 5.1-5 GET_FIRMWARE_VERSION 応答 - コンポーネントのバージョンとプロパティのバイト
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | ファームウェアのバージョン | 32 | そのコンポーネントの現在のファームウェアのバージョンを返します。 この仕様では、ファームウェアのバージョンに特定の形式は必要ありません。 ガイドラインについては、「ファームウェアのバージョン」セクションを参照してください。 |
| 32 | 銀行 | 2 | 随意。 アーキテクチャによっては、コンポーネント ハードウェアにファームウェアを格納できる複数のバンクが存在する場合があります。 実装によっては、送信側がファームウェアが現在存在する銀行を指定する場合があります。 このフィールドは条件付き必須です。サポートは省略可能ですが、他の目的には使用しないでください。 |
| 34 | 予約されています。 | 2 | 予約済みのフィールド。 送信者はこれらを 0 に設定する必要があります。 受信者はこの値を無視する必要があります。 |
| 36 | ベンダー固有 | 4 | 実装固有の方法で使用できるベンダー固有のフィールド。 ベンダーは、次のような情報をエンコードするためにこれらのビットを使用できます。 - ファームウェアの種類: プレリリース、セルフホスト、運用、デバッグ、小売用 - 開発フェーズ - 同じ更新プロトコルを使用してコンポーネントが他の製品のファームウェアを受信できないようにする製品 ID。 |
| 40 | コンポーネント ID | 8 | コンポーネントの一意の識別子。 |
| 48 | ベンダー固有 | 16 | 実装固有の方法で使用できるベンダー固有のフィールド。 |
5.1.3 HID へのマッピング
これは、レポート ID に加えて、応答サイズが 60 バイトの HID Get Feature 要求として実装されます。 機能レポートの長さは、GET_FIRMWARE_VERSION応答全体に対応します。 ホストからの機能の取得要求に関連付けられているデータはありません。
5.2 ファームウェア更新の提案
プライマリ コンポーネントがファームウェアを受け入れるか拒否するかを決定します。
5.2.1 コマンド
ホストは、このコマンドをコンポーネントに送信して、ファームウェアを受け入れるか拒否するかを判断します。 ホストはオファーを送信する必要があり、コンポーネントは、ホストがファームウェアを送信する前にオファーを受け入れる必要があります。
FIRMWARE_UPDATE_OFFER コマンド パケットは次のように定義されます。
表 5.2-1 FIRMWARE_UPDATE_OFFER コマンド レイアウト
5.2.1.1 コンポーネント情報
表 5.2-2 FIRMWARE_UPDATE_OFFER コマンド - コンポーネント情報のレイアウト
この表では、コンポーネント情報バイトのビットについて説明します。
表 5.2-3 FIRMWARE_UPDATE_OFFER コマンド - コンポーネント情報ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | セグメント番号 | 8 | このフィールドは、コンポーネントのファームウェアがより小さいセグメントにセグメント化される場合に使用されます。 この値を使用すると、後続のペイロード パケットに含まれるセグメントが示されます。 たとえば、コンポーネントのファームウェア イメージが非常に大きく、プライマリ コンポーネントが一度にイメージの小さい部分のみを取ることができる場合、このフィールドを使用して、このオファーが完全なイメージの iセグメント用であることを示すことができます。 i +1 番目のセグメントを含む主要コンポーネントには、個別にオファーが送信される場合があります。 |
| 8 | 予約されています。 | 6 | 予約済みのフィールド。 送信者はこれらを 0 に設定する必要があります。 受信者はこの値を無視する必要があります。 |
| 14 | I | 1 | 即時リセットを強制する (I) - このビット値は、ファームウェアのダウンロードが完了し、直ちに呼び出されるように検証された後、コンポーネントに直ちにリセットするように指示するために使用されます。 - このフラグは、開発フェーズを対象としています。 |
| 15 | V | 1 | バージョンを強制的に無視する (V) - このフラグは、プレリリースまたはデバッグ ファームウェア イメージを対象としています。 これは、ファームウェアのバージョンに基づいてファームウェアを拒否しないことをコンポーネントに示します。 - このフラグは、開発フェーズを対象としています。 これは、以前のファームウェア バージョンに意図的にロールバックするために使用できます。 - このフラグは、運用ファームウェアでは無視する必要があります。 |
| 16 | コンポーネント ID | 8 | このバイトは、複数コンポーネントのシナリオで使用されます。 このフィールドは、オファーの対象となるサブコンポーネントを識別するために使用できます。 使用しない場合、値は 0 にする必要があります。 コンポーネント ID の使用可能な値は次のとおりです。 1 - 0xDF: 有効 0xE0 - 0xFD: 予約済み。 使用しないでください。 0xFF: オファーは特別オファー情報パケットです。 詳細については、「ファームウェア更新オファー情報」を参照してください。 0xFE: オファーは特別なオファー コマンド パケットです。 詳細については、「FIRMWARE_UPDATE_OFFER拡張セクション」を参照してください。 |
| 24 | トークン | 8 | ホストは、コンポーネントへのオファー パケットに一意のトークンを挿入します。 このトークンは、オファーの応答でコンポーネントによって返される必要があります。 これは、異なるホスト/タイプのホストをコンポーネントが区別する必要がある場合に便利です。 使用する正確な値は実装固有です。 たとえば、1 つの値をドライバーに使用し、もう 1 つの値をアプリケーションに使用できます。 これにより、現在のデバイス ファームウェアは、CFU コマンドの潜在的な複数の送信者を考慮できます。 考えられる実装の 1 つは、最初の CFU コマンドを受け入れ、最初の CFU トランザクションが完了するまで、異なるトークンを持つ他のすべてのコマンドを拒否することです。 |
5.2.1.2 ファームウェアのバージョン
これら 4 バイトは、ファームウェアの 32 ビット バージョンを表します。 ファームウェア バージョンの形式は、この仕様では必須ではありません。 次の方法をお勧めします。
表 5.2-4 FIRMWARE_UPDATE_OFFER コマンド - ファームウェアバージョンのレイアウト
ファームウェア バージョンの形式は、この仕様では必須ではありませんが、推奨されるガイドラインを次に示します。
表 5.2-5 FIRMWARE_UPDATE_OFFER コマンド - ファームウェア バージョン ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 変異型 | 8 | このフィールドは、プレリリース ファームウェアと実稼働ファームウェアを区別するために記述できます。 ファームウェアの署名に使用される署名の種類を示している場合があります。 |
| 8 | マイナー バージョン | 16 | このフィールド値は、ファームウェアのビルドごとに更新する必要があります。 このフィールド値は、ファームウェアのビルドごとに更新する必要があります。 |
| 24 | メジャー バージョン | 8 | このフィールドは、ファームウェア イメージのメジャー バージョンです。 このフィールドは、新しい製品ライン、ファームウェアのメジャーな新しい更新プログラムなどを出荷するときに更新する必要があります。 |
5.2.1.3 ベンダー固有
これらの 4 バイトは、ベンダーの実装に固有のオファー内のカスタム情報をエンコードするために使用できます。
5.2.1.4 その他のバージョンとプロトコルのバージョン
これらの 4 バイトは、ベンダーの実装に固有のオファー内のカスタム情報をエンコードするために使用できます。
表 5.2-6 FIRMWARE_UPDATE_OFFER コマンド - ベンダー固有のレイアウト
ベンダー固有バイトのビットを次の表に示します。
表 5.2-7 FIRMWARE_UPDATE_OFFER コマンド - その他およびプロトコルのバージョン
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | プロトコル のバージョン | 4 | このフィールドは、ホスト/オファーが CFU プロトコルのバージョン 2 に対応することを示す 0010b に設定する必要があります。 |
| 4 | 予約されています。 | 4 | 予約済み。 使用しないでください。 |
| 8 | 予約されています。 | 8 | 予約済み。 使用しないでください。 |
| 16 | ベンダー固有 | 16 | このフィールドは、ベンダーの実装に固有のオファー内のカスタム情報をエンコードするために使用できます。 |
5.2.2 応答
FIRMWARE_UPDATE_OFFER応答パケットは次のように定義されます。
表 5.2-8 FIRMWARE_UPDATE_OFFER応答トークンのレイアウト
5.2.2.1 トークン
表 5.2-9 FIRMWARE_UPDATE_OFFER応答 - トークンレイアウト
この表では、トークン バイトのビットについて説明します。
表 5.2-10 FIRMWARE_UPDATE_OFFER応答 - トークンビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 予約されています。 | 8 | 予約済み。 使用しないでください。 |
| 8 | 予約されています。 | 8 | 予約済み。 使用しないでください。 |
| 16 | 予約されています。 | 8 | 予約済み。 使用しないでください。 |
| 24 | トークン | 8 | ホストを識別するトークン。 |
5.2.2.2 予約済み (B7 ～ B4)
予約済み。 使用しないでください。
5.2.2.3 理由の却下 (RR)
表 5.2-11 FIRMWARE_UPDATE_OFFER応答 - 却下理由のレイアウト
表 5.2-12 FIRMWARE_UPDATE_OFFER の応答 - 理由ビットの拒否
この表では、Reject Reason バイトのビットについて説明します。
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | RR コード | 8 | オファーを拒否するためにコンポーネントによって提供される理由を示す拒否理由コード。 この値は、[状態] フィールドによって異なります。 ステータスから RR コードへのマッピングについては、表 5.2-13 を参照してください。 |
| 8 | 予約されています。 | 24 | 予約済み。 使用しないでください。 |
表 5.2-13 FIRMWARE_UPDATE_OFFER の応答 RR コード値
RR コード バイトに使用できる値については、次の表を参照してください。
| RR コード | 名前 | 説明 |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | 提供されているファームウェアのバージョンが古いか、現在のファームウェアと同じであるため、オファーが拒否されました。 |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | 提供されたファームウェアが製品のプラットフォームに適用されないため、オファーは拒否されました。 これは、サポートされていないコンポーネント ID または提供されるイメージがシステム ハードウェアと互換性がないために発生する可能性があります。 |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | コンポーネント ファームウェアは更新されましたが、新しいファームウェアへのスワップは保留中です。 通常はリセットによってスワップが完了するまで、ファームウェア更新処理は実行できません。 |
| 0x03 - 0x08 | (予約済み) | 予約済み。 使用しないでください。 |
| 0x09 - 0xDF | (予約済み) | 予約済み 使用しないでください。 |
| 0xE0 - 0xFF | (ベンダー固有) | これらの値はプロトコルの設計者によって使用され、意味はベンダー固有です。 |
5.2.2.4 状態
表 5.2-14 FIRMWARE_UPDATE_OFFER応答状態のレイアウト
この表では、Status バイトのビットについて説明します。
表 5.2-15 FIRMWARE_UPDATE_OFFER の応答 - 状態ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 地位 | 8 | この値は、オファーを受け入れる、保留する、スキップする、または拒否するコンポーネントの決定を示します。 コンポーネントは、RR コード・フィールド値の理由を提供します。 ステータスから RR コードへのマッピングについては、表 5.2-16 を参照してください。 |
| 8 | 予約されています。 | 24 | 予約済み 使用しないでください。 |
Status バイトに指定できる値については、次の表を参照してください。
表 5.2-16 FIRMWARE_UPDATE_OFFER応答ステータス値
| 地位 | 名前 | 説明 |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | コンポーネントは、オファーをスキップすることを決定しました。 ホストが後で再度オファーする必要があります。 |
| 0x01 | ファームウェア更新の提案を承諾する | コンポーネントは、オファーを受け入れることを決定しました。 |
| 0x02 | ファームウェア更新オファー拒否 | コンポーネントは、オファーを拒否することを決定しました。 |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | デバイスはビジー状態であり、ホストはデバイスの準備ができるまで待機する必要があります。 |
| 0x04 | ファームウェア更新オファーコマンド | コンポーネント情報バイトのコンポーネント ID (5.1.2.1.1 コンポーネント情報を参照) が0xFEに設定されている場合に使用されます。 コマンド コードが OFFER_NOTIFY_ON_READY 要求に設定されている場合は、アクセサリが追加のオファーを受け入れる準備ができているかどうかを示します。 |
| 0xFF | ファームウェア更新コマンドがサポートされていません | オファー要求が認識されません。 |
5.2.3 HID プロトコルへのマッピング
メッセージは、ファームウェア更新用の専用 HID ユーティリティ レポート ID を使用して、HID 出力レポート メカニズムを介してコンポーネントに発行されます。 付録で説明されている HID ユーティリティ TLCの使用。
5.3 ファームウェア更新のオファー - 情報
コンポーネント情報バイト内のコンポーネント ID (コンポーネント情報を参照) が0xFFに設定されている場合、ビット (15 バイト) が再定義されて、ホストからコンポーネントへのオファー情報のみを示します。 このメカニズムにより、拡張と、ホストがデバイスに特定の情報を提供する方法 (スタート オファー リスト、オファー 一覧の終了、トランザクション全体の開始など) が可能になります。 オファー情報パケットは常にコンポーネントによってすぐに受け入れられます。
5.3.1 コマンド
FIRMWARE_UPDATE_OFFER -Information コマンド パケットは次のように定義されます。
表 5.3-1 FIRMWARE_UPDATE_OFFER - 情報コマンドのレイアウト
5.3.1.1 コンポーネント
表 5.3-2 FIRMWARE_UPDATE_OFFER - 情報コマンド - コンポーネントレイアウト
この表では、コンポーネント バイトのビットについて説明します。
表 5.3-3 FIRMWARE_UPDATE_OFFER - 情報コマンド - コンポーネント ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 情報コード | 8 | この値は、情報の種類を示します。 この値はビットマスクではなく、表 5.3-4 で説明されている使用可能な値の 1 つしか指定できません。 |
| 8 | 予約済み。 | 8 | 予約済み 使用しないでください。 |
| 16 | コンポーネント ID | 8 | 0xFFに設定します。 |
| 24 | トークン | ホストは、コンポーネントへのオファー パケットに一意のトークンを挿入します。 このトークンは、オファーの応答でコンポーネントによって返される必要があります。 |
表 5.3-4 FIRMWARE_UPDATE_OFFER - 情報コマンド - 情報コード値
| 地位 | 名前 | 説明 |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | ホストが新規であるか、再読み込みされ、オファー処理全体が (再) 開始されていることを示します。 |
| 0x01 | OFFER_INFO_START_OFFER_LIST | アクセサリに、システム内の別のサブコンポーネントの前に 1 つのサブコンポーネントが更新されるように関連付けられているダウンロード ルールがある場合に、ホストからのオファー リストの先頭を示します。 |
| 0x02 | OFFER_INFO_END_OFFER_LIST | ホストからのオファー リストの末尾を示します。 |
5.3.1.2 予約済み B7 ～ B4
予約済み。 使用しないでください。
5.3.1.3 予約済み B11 ～ B8
予約済み。 使用しないでください。
5.3.1.4 予約済み B15 ～ B12
予約済み 使用しないでください。
5.3.2 応答
FIRMWARE_UPDATE_OFFER - オファー情報応答パケット応答は、次のように定義されます。
表 5.3-5 FIRMWARE_UPDATE_OFFER - 情報応答レイアウト
5.3.2.1 トークン
表 5.3-6 FIRMWARE_UPDATE_OFFER- 情報パケット応答トークンのレイアウト
この表では、トークン バイトのビットについて説明します。
表 5.3-7 FIRMWARE_UPDATE_OFFER - 情報応答 - トークン ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 予約されています。 | 8 | 予約済み 使用しないでください。 |
| 8 | 予約されています。 | 8 | 予約済み 使用しないでください。 |
| 16 | 予約されています。 | 8 | 予約済み 使用しないでください。 |
| 24 | トークン | 8 | ホストを識別するトークン |
5.3.2.2 予約済み B7 ～ B4
予約済み。 使用しないでください。
5.3.2.3 理由の却下 (RR)
表 5.3-8 FIRMWARE_UPDATE_OFFER - 情報応答 - RR コードレイアウト
この表では、Reject Reason バイトのビットについて説明します。
表 5.3-9 FIRMWARE_UPDATE_OFFER - オファー情報応答 - RR コード ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | RR コード | 8 | オファーを拒否するためにコンポーネントによって提供される理由を示す拒否理由コード。 使用可能な値は表 5.3-10 で説明されています。 この値は、[状態] フィールドによって異なります。 |
| 8 | 予約されています。 | 24 | 予約済み。 使用しないでください。 |
RR コード バイトに使用できる値については、次の表を参照してください。
表5.3-10 FIRMWARE_UPDATE_OFFER - 情報応答 - RRコード値
| RR コード | 名前 | 説明 |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | 提供されているファームウェアのバージョンが古いか、現在のファームウェアと同じであるため、オファーが拒否されました。 |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | 提供されたファームウェアが製品のプラットフォームに適用されないため、オファーは拒否されました。 これは、サポートされていないコンポーネント ID または提供されるイメージがシステム ハードウェアと互換性がないために発生する可能性があります。 |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | コンポーネント ファームウェアは更新されましたが、新しいファームウェアへのスワップは保留中です。 通常はリセットによってスワップが完了するまで、ファームウェア更新処理は実行できません。 |
| 0x03 - 0x08 | (予約済み) | 予約済み。 使用しないでください。 |
| 0x09 - 0xDF | (予約済み) | 予約済み。 使用しないでください。 |
| 0xE0 — 0xFF | (ベンダー固有) | これらの値はプロトコルの設計者によって使用され、意味はベンダー固有です。 |
5.3.2.4 状態
表 5.3-11 FIRMWARE_UPDATE_OFFER - オファー情報の応答状態レイアウト
この表では、Status バイトのビットについて説明します。
表 5.3-12 FIRMWARE_UPDATE_OFFER - オファー情報 - 応答状態ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 地位 | 8 | このフィールドはFIRMWARE_UPDATE_OFFER_ACCEPTに設定する必要があります。 これは、コンポーネントがオファーを受け入れることを決定したことを示します。 |
| 8 | 予約済み。 | 24 | 予約済み 使用しないでください。 |
5.4 ファームウェア_アップデート_オファー - 拡張
コンポーネント情報バイトのコンポーネント ID が 0xFE に設定されている場合、ビット (15 バイト) が再定義され、ホストからデバイス ファームウェアへのオファー コマンドが示されます。 このメカニズムにより、拡張性と、ホストが特定の情報をデバイスに提供する方法が可能になります。 Offer Command パケットは、コンポーネントが Accepted に応答する準備ができたときに返されます。
5.4.1 コマンド
コンポーネント情報バイトのコンポーネント ID が 0xFE に設定されている場合、4 つの DWORD は次のように再定義されます。
表 5.4-1 FIRMWARE_UPDATE_OFFER - 拡張コマンド レイアウト
5.4.1.1 コンポーネント
表 5.4-2 FIRMWARE_UPDATE_OFFER - 拡張コマンド パケット - コマンド - コンポーネント レイアウト
この表では、コンポーネント バイトのビットについて説明します。
表 5.4-3 FIRMWARE_UPDATE_OFFER - 拡張コマンド - コンポーネント ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | コマンド コード | 8 | この値は、コマンドの種類を示します。 この値はビットマスクではなく、表 5.4-4 で説明されている使用可能な値の 1 つしか指定できません。 |
| 8 | 予約済み。 | 8 | 予約済み。 使用しないでください。 |
| 16 | コンポーネント ID | 8 | 0xFEに設定します。 |
| 24 | トークン | ホストは、コンポーネントへのオファー パケットに一意のトークンを挿入します。 このトークンは、オファーの応答でコンポーネントによって返される必要があります。 |
表 5.4-4 FIRMWARE_UPDATE_OFFER - 拡張コマンド - コマンド コード値
| 地位 | 名前 | 説明 |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | オファーが以前にコンポーネントによって拒否された場合にホストによって送信されます。 |
| 0x02 - 0xFF | 予約されています。 | 予約されています。 |
5.4.1.2 予約済み B7 ～ B4
予約済み 使用しないでください。
5.4.1.3 予約済み B11 ～ B8
予約済み 使用しないでください。
5.4.1.4 予約済み B15 ～ B12
予約済み 使用しないでください。
5.4.2 応答
デバイスからの FIRMWARE_UPDATE_OFFER - Offer Command 応答がすぐに受信されない場合があります。 応答は次のように定義されます。
表 5.4-5 FIRMWARE_UPDATE_OFFER - 拡張コマンド パケット応答レイアウト
5.4.2.1 トークン
表 5.4-6 FIRMWARE_UPDATE_OFFER- コマンド パケット応答の提供 - トークン レイアウト
この表では、トークン バイトのビットについて説明します。
表 5.4-7 FIRMWARE_UPDATE_OFFER - オファー コマンドの応答 - トークン ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 予約されています。 | 8 | 予約済み。 使用しないでください。 |
| 8 | 予約されています。 | 8 | 予約済み 使用しないでください。 |
| 16 | 予約されています。 | 8 | 予約済み。 使用しないでください。 |
| 24 | トークン | 8 | ホストを識別するトークン。 |
5.4.2.2 予約済み B7 ～ B4
予約済み 使用しないでください。
5.4.2.3 拒否理由
表 5.4-8 FIRMWARE_UPDATE_OFFER - オファー情報パケットの応答 RR レイアウト
この表では、Reject Reason バイトのビットについて説明します。
表 5.4-9 FIRMWARE_UPDATE_OFFER- オファー コマンドの応答 - RR コード
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | RR コード | 8 | この値は、[状態] フィールドによって異なります。 可能な RR コード値については、表 5.4-10 を参照してください。 |
| 8 | 予約されています。 | 24 | 予約済み 使用しないでください。 |
RR コード バイトに使用できる値については、次の表を参照してください。
表 5.4-10 ファームウェア更新オファー - オファーコマンドパケット - RRコード値
| RR コード | 名前 | 説明 |
|---|---|---|
| 0x00 | ファームウェア更新案内を拒否 (古いファームウェア) | 提供されているファームウェアのバージョンが古いか、現在のファームウェアと同じであるため、オファーが拒否されました。 |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | 提供されたファームウェアが製品のプラットフォームに適用されないため、オファーは拒否されました。 これは、サポートされていないコンポーネント ID または提供されるイメージがシステム ハードウェアと互換性がないために発生する可能性があります。 |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | コンポーネント ファームウェアは更新されましたが、新しいファームウェアへのスワップは保留中です。 通常はリセットによってスワップが完了するまで、ファームウェア更新処理は実行できません。 |
| 0x03 - 0x08 | (予約済み) | 予約済み 使用しないでください。 |
| 0x09 - 0xDF | (予約済み) | 予約済み 使用しないでください。 |
| 0xE0 — 0xFF | (ベンダー固有) | これらの値はプロトコルの設計者によって使用され、意味はベンダー固有です。 |
5.4.2.4 状態
表 5.4-11 FIRMWARE_UPDATE_OFFER- オファー コマンド パケットの応答状態レイアウト
この表では、Status バイトのビットについて説明します。
表 5.4-12 FIRMWARE_UPDATE_OFFER- オファー コマンド パケットの応答 RR コード値
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 地位 | 8 | このフィールドはFIRMWARE_UPDATE_OFFER_ACCEPTに設定する必要があります。 これは、コンポーネントがオファーを受け入れることを決定したことを示します。 |
| 8 | 予約済み。 | 24 | 予約済み 使用しないでください。 |
5.5 ファームウェア更新内容
ホストは、このコマンドをデバイス ファームウェアに送信して、ファームウェアの内容 (つまり、ファームウェア イメージ) を提供します。 イメージ ファイル全体が 1 つのコマンドに収まることは想定されていません。 ホストはイメージをより小さなブロックに分割する必要があり、各コマンドはイメージのブロックを一度に 1 つ送信します。
各コマンドで、ホストはファームウェアの最初のブロック、最後のブロックなど、追加情報を示します。 デバイス ファームウェアのプライマリ コンポーネントは、受信ファームウェア イメージの各ブロックを受け入れ、そのメモリに格納し、各コマンドに個別に応答する必要があります。
プライマリ コンポーネントが最後のブロックを受け取ると、コンポーネントはファームウェア イメージ全体を検証します (CRC チェック、署名検証)。 これらのチェックの結果に基づいて、最後のブロックに対する適切な応答 (失敗または成功) が返されます。
5.5.1 コマンド
表 5.5-1 FIRMWARE_UPDATE_CONTENT コマンド レイアウト
5.5.1.1 ヘッダー (B7 - B0)
表 5.5-2 FIRMWARE_UPDATE_CONTENT コマンド ヘッダーのレイアウト
この表では、FIRMWARE_UPDATE_CONTENT ヘッダーのビットについて説明します。
表 5.5-3 FIRMWARE_UPDATE_CONTENT のヘッダービット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | フラグ | 8 | このフィールドは、コマンドに関する追加情報を提供します。 この値は、データ転送に使用するフラグのマスクです。 使用可能な値については、表 5.5-4 で説明します。 |
| 8 | データの長さ | 8 | 書き込むバイト数を示す該当するデータ フィールドの長さ。 このコマンドのサイズを指定すると、長さの最大値は 52 バイトです。 |
| 16 | シーケンス番号 | 16 | この値はホストによって作成され、発行されたコンテンツ パケットごとに一意です。 コンポーネントは、この要求への応答でシーケンス番号を返す必要があります。 |
| 32 | ファームウェア アドレス | 32 | リトルエンディアン（LSB First）のデータを書き込むアドレス。 アドレスは 0 から始まります。 ファームウェアはこれをオフセットとして使用して、イメージをメモリに配置するときに必要に応じてアドレスを決定します。 |
Flags バイトに指定できる値については、次の表で説明します。
表 5.5-4 FIRMWARE_UPDATE_OFFER- オファー コマンド パケット - フラグ値
| 旗 | 名前 | 説明 |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | このフラグは、これがファームウェア イメージの最初のブロックであることを示します。 |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK (ファームウェア更新フラグの最終ブロック) | このフラグは、これがファームウェア イメージの最後のブロックであり、イメージを検証する準備ができていることを示します。 コンポーネントの現在のファームウェアは、このブロックを不揮発性メモリに書き込んだ後、ダウンロードしたファームウェア イメージ全体に対して検証を実行することが重要です。 |
5.5.1.2 データ
表 5.5-5 FIRMWARE_UPDATE_CONTENT コマンド データのレイアウト
この表では、FIRMWARE_UPDATE_CONTENT データのビットについて説明します。
表 5.5-6 FIRMWARE_UPDATE_CONTENT コマンドデータビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 64 | データ | 最大 52。 | 書き込むバイト配列。 ホストは通常、製品アーキテクチャに基づいて 4 バイトのブロックを送信します。 末尾の未使用のバイトは、0で埋める必要があります。 |
5.5.2 応答
表 5.5-7 FIRMWARE_UPDATE_CONTENT コマンド応答のレイアウト
コマンド応答レイアウトを 
5.5.2.1 シーケンス番号
表 5.5-8 FIRMWARE_UPDATE_CONTENT の応答 - シーケンス番号
この表では、FIRMWARE_UPDATE_CONTENT応答 (3- 0) のビットについて説明します。
表 5.5-9 FIRMWARE_UPDATE_CONTENT コマンド データ - 応答ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | シーケンス番号 | 16 | このフィールドは、要求でホストによって送信されたシーケンス番号です。 |
| 16 | 予約されています。 | 16 | 予約済み。 使用しないでください。 |
5.5.2.2 状態
表 5.5-10 FIRMWARE_UPDATE_CONTENT応答状態のレイアウト
この表では、FIRMWARE_UPDATE_CONTENT応答 (7 から 4) のビットについて説明します。
表 5.5-11 FIRMWARE_UPDATE_OFFER - 応答 - 状態ビット
| ビット オフセット | フィールド | サイズ | 説明 |
|---|---|---|---|
| 0 | 地位 | 8 | この値は、デバイス コンポーネントによって返される状態コードを示します。 これはビット単位ではなく、表 5.5-12 で説明されている値のいずれかになります。 |
| 8 | 予約されています。 | 24 | 予約済み。 使用しないでください。 |
Status バイトに指定できる値については、次の表を参照してください。
表 5.5-12 FIRMWARE_UPDATE_OFFER- 応答 - 状態コード値
| 旗 | 名前 | 説明 |
|---|---|---|
| 0x00 | ファームウェアの更新が成功しました | 要求が正常に完了しました。 |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | コンポーネントは、ファームウェアの内容を受け取る準備ができていませんでした。 このコードを使用する場合、通常、最初のブロックへの応答でこのコードが使用されます。 たとえば、フラッシュ時にエラーを消去します。 |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | 要求でバイトを書き込むことができませんでした。 |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | 要求は、FIRMWARE_UPDATE_FLAG_LAST_BLOCKに応答してスワップを設定できませんでした。 |
| 0x04 | ファームウェア更新エラー検証 | FIRMWARE_UPDATE_FLAG_VERIFY に対する DWORD の検証に失敗しました。 |
| 0x05 | ファームウェアアップデートエラー_CRC | FIRMWARE_UPDATE_FLAG_LAST_BLOCKに応答してファームウェア イメージの CRC が失敗しました。 |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | FIRMWARE_UPDATE_FLAG_LAST_BLOCKに応答してファームウェア署名の検証に失敗しました。 |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | FIRMWARE_UPDATE_FLAG_LAST_BLOCKに応答してファームウェアバージョンの検証に失敗しました。 |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | ファームウェアは既に更新されており、スワップが保留中です。 アクセサリがリセットされるまで、それ以上のファームウェアアップデートコマンドは受け入れできません。 |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR（ファームウェア更新のエラー: 無効なアドレス） | メッセージ データ コンテンツ内の無効な宛先アドレスがファームウェアによって検出されました。 |
| 0x0A | ファームウェア更新エラー：オファーなし | FIRMWARE_UPDATE_OFFER コマンドは、最初に有効で受け入れられたファームウェア更新プログラムオファーを受け取らずに受信されました。 |
| 0x0B | ファームウェア更新エラー_無効 | FIRMWARE_UPDATE_OFFER コマンドの一般的なエラー (無効な適用可能なデータ長など)。 |
5.5.2.3 予約済み B8 ～ B11
予約済み。 使用しないでください。
5.5.2.4 予約済み B12 ～ B15
予約済み 使用しないでください。
6 付録 1: ファームウェア更新プログラムのプログラミング コマンド シーケンスの例
6.1 例 1
次のデバイス ファームウェアについて考えてみましょう。
プライマリ コンポーネント - コンポーネント ID 1 - 現在のファームウェア バージョン 7.0.1
サブコンポーネント - コンポーネント ID 2 - 現在のファームウェア バージョン 12.4.54
サブコンポーネント - コンポーネント ID 3 - 現在のファームウェア バージョン 4.4.2
サブコンポーネント - コンポーネント ID 4 - 現在のファームウェア バージョン 23.32.9
ホストには、次の 3 つのファームウェア イメージがあります。
コンポーネント ID 1 - ファームウェア バージョン 7.1.3
コンポーネント ID 2 - ファームウェア バージョン 12.4.54
コンポーネント ID 3 - ファームウェア バージョン 4.5.0
シーケンスは次のようになります。
ホスト オファー: コンポーネント ID 1 - ファームウェア バージョン 7.1.3
プライマリ コンポーネントがオファーを受け入れる
ホストがファームウェア イメージを送信する
プライマリ コンポーネントがファームウェアを受け入れ、検証する
ホスト オファー: コンポーネント ID 2 - ファームウェア バージョン 12.4.54
プライマリ コンポーネントがオファーを拒否する
ホスト オファー: コンポーネント ID 3 - ファームウェア バージョン 4.5.0
プライマリ コンポーネントがオファーを受け入れる
ホストがファームウェア イメージを送信する
プライマリ コンポーネントがファームウェアを受け入れ、検証する
すべてのオファーが拒否されなかったため、ホストはすべてのオファーを再生します。
ホスト オファー: コンポーネント ID 1 - ファームウェア バージョン 7.1.3
コンポーネント拒否
ホスト オファー: コンポーネント ID 2 - ファームウェア バージョン 12.4.54
コンポーネント拒否
ホスト オファー: コンポーネント ID 3 - ファームウェア バージョン 4.5.0
コンポーネント拒否
6.2 例 2
次のデバイス ファームウェアについて考えてみましょう。
プライマリ コンポーネント - コンポーネント ID 1 - 現在のファームウェア バージョン 7.0.1
サブコンポーネント - コンポーネント ID 2 - 現在のファームウェア バージョン 12.4.54
サブコンポーネント - コンポーネント ID 3 - 現在のファームウェア バージョン 7.4.2
サブコンポーネント - コンポーネント ID 4 - 現在のファームウェア バージョン 23.32.9
ホストには、次の 3 つのファームウェア イメージがあります。
コンポーネント ID 1 - ファームウェア バージョン 8.0.0
コンポーネント ID 2 - ファームウェア バージョン 12.4.54
コンポーネント ID 3 - ファームウェア バージョン 9.0.0
さらに、この実装では、サブコンポーネントのファームウェア バージョンが、プライマリ コンポーネントで実行されているファームウェア バージョンより小さくすることはできません。 ホストはその要件を知らず、この規則を保証するための主要な構成要素であるup-toについて認識していません。
シーケンスは次のようになります。
ホスト オファー: コンポーネント ID 1 - ファームウェア バージョン 8.0.0
プライマリ コンポーネントが拒否される (コンポーネント ID 3 がまだ更新されていないため)
ホスト オファー: コンポーネント ID 2 - ファームウェア バージョン 12.4.54
主要コンポーネントの拒否
ホスト オファー: コンポーネント ID 3 - ファームウェア バージョン 9.0.0
プライマリ コンポーネントがオファーを受け入れる
ホストがファームウェア イメージを送信する
プライマリ コンポーネントがファームウェアを受け入れ、検証する
すべてのオファーが拒否されなかったため、ホストはすべてのオファーを再生します。
ホスト オファー: コンポーネント ID 1 - ファームウェア バージョン 8.0.0
プライマリ コンポーネントがオファーを受け入れる
ホストがファームウェア イメージを送信する
プライマリ コンポーネントがファームウェアを受け入れ、検証する
ホスト オファー: コンポーネント ID 2 - ファームウェア バージョン 12.4.54
主要コンポーネントの拒否
ホスト オファー: コンポーネント ID 3 - ファームウェア バージョン 9.0.0
主要コンポーネントの拒否