元件韌體更新 (CFU) 通訊協議規格
此規格描述一般 HID 通訊協定，以更新電腦或配件上存在的元件韌體。 規格可讓元件接受韌體，而不會在下載期間中斷裝置作業。 規格支援接受韌體之元件可能有子元件的元件，這需要個別的韌體映像。 規格可讓元件負責決定是否要接受韌體。 它也可作為優化，因為韌體映射只有在能夠或準備好接受它時才會傳送至元件。
注意
CFU Windows 10 2004 版 (Windows 10 2020 年 5 月更新) 和更新版本提供。
目錄
- 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 命令 - Misc 和通訊協定版本
表 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 簡介
現今的計算機和配件具有執行複雜作業的內部元件。 為了確保質量產品，需要經常在開發階段中更新這些裝置的行為，或在他們寄送給客戶之後。 更新可能會修正已識別的功能或安全性問題，或需要新增功能。 複雜邏輯的大部分是在裝置上執行的韌體中，這是可更新的。
此規格描述一般 HID 通訊協定，以更新電腦上或其配件上存在的元件韌體。 HID 實作超出規格的範圍。
通訊協定的一些功能包括：
通訊協定是以 HID 為基礎，且具有 Windows 內建支援，可透過各種互連總線，例如 USB 和 I2C。 因此，可以使用相同的軟體 (驅動程式) 解決方案來更新所有元件的韌體。
注意
因為規格是以封包為基礎，所以很容易將它調整為非 HID 案例。
規格可讓元件接受韌體，而不會在下載期間中斷裝置作業。 這可讓用戶獲得更好的體驗，因為他們不需要等待韌體更新程式完成，才能繼續其他工作。 新的韌體一次可以在單一不可部分完成的作業中叫用，對用戶的影響降到最低。
規格支援接受韌體之元件可能有子元件的元件，這需要個別的韌體映像。
注意
將韌體交給子元件的元件程式超出此規格的範圍。
規格支援 供應 專案的概念，並依賴元件收費來決定是否接受韌體。 接受新韌體的決定並不簡單。 韌體類型和/或版本與新韌體套用的基礎類型/硬體版本之間可能會有相依性。 供應專案也會做為優化機制，因為只有在韌體映像能夠 /ready 可接受它時，才會將韌體映射傳送至元件。
1.1 詞彙
| 詞彙 | 描述 |
|---|---|
| 元件識別碼 | 在具有多個元件的裝置中，元件標識碼可唯一識別每個元件。 |
| CRC | 迴圈備援檢查 非密碼編譯哈希演算法，用來產生數據區塊的摘要或指紋。 CRC 是用來做為檢查，以確保數據區塊在計算 CRC 之後尚未變更。 CRC 不符，但提供正確接收數據的信賴度。 |
| 裝置 | 元件集合 (一個主要元件，以及零或多個子元件) 。 操作系統會顯示為單一單位的裝置。 主機會與裝置互動，通常是主要元件。 計算機可能有多個裝置。 針對此規格，與 2 部不同裝置的通訊完全獨立。 |
| 驅動程式 | 使用 Windows Driver Foundation (WDF) 架構所撰寫的驅動程式。 |
| 韌體 | 在實體硬體上執行的程序代碼。 韌體是可更新的，通常位於與硬體相關聯的可程式化記憶體中。 |
| 硬體 | 計算機上的實體晶元片段。 |
| 主要元件 | 計算機上的硬體片段及其韌體。 在此規格的內容中，元件是需要並接受韌體更新的實體。 |
| 區段 | 元件的韌體映像可能會分割成較小的區段。 每個區段都是小型韌體映像。 |
| 區段識別碼 | 如果元件的韌體分割成較小的區段，區段標識符是區段的唯一標識符。 |
| 簽章 | 密碼編譯方式，用來判斷韌體映像是否已遭到未經授權的變更。 簽章是選擇性的，但建議超出此規格的範圍。 |
| 子元件 | 視硬體架構而定，操作系統無法看到所有元件，因為這些元件可能會連線到系統可見的元件下游。 這些元件在此規格中稱為子元件。 |
| 薄 | HID 最上層集合。 |
| 語彙基元 | 主機會話的標識碼。 主機會建立令牌，並在命令中傳送令牌，而裝置會在回應中傳回令牌。 令牌可用來串行化特定交易，或識別會話已遺失，另一個已啟動。 |
1.2 範圍
1.2.1 Goals
需要與總線無關的解決方案，才能避免每種總線類型的新通訊協定。 HID 是普遍的，可解決該需求。
支援多元件裝置韌體更新的能力，其中一個元件會作為主要元件，而其他元件則是連接到主要元件的子元件。 每個元件都需要自己的韌體，彼此之間具有非簡單相依性。
將韌體映像下載至元件的常見驅動程式模型。 接著，元件會有轉送至子元件的子元件特定演算法。 子元件也可能在其韌體上執行有效性檢查，並將結果傳回主要元件。
在裝置作業進行時支援韌體更新的能力。
透過授權的工具更新/復原生產裝置中的韌體，以及透過 Windows Update 更新市場內裝置的能力。
支持開發中韌體/市場內韌體彈性。
將大型韌體映射分割成較小的區段，讓元件更容易接受韌體映像。
1.2.2 非 Goals
定義韌體映像的內部格式：針對主機，韌體映像是一組位址和承載專案。
簽署/加密/驗證已接受的韌體：此規格不會描述如何簽署和加密韌體映像。 在元件上執行的預期目前韌體必須驗證要下載的韌體。
定義元件如何與子元件互動的機制：主機會以單一單位的方式與裝置互動，通常是主要元件。 元件必須作為與子元件韌體相關的通訊網橋。
2 支援的硬體架構
為了支援彈性的硬體設計，通訊協定支援多元件裝置，其中每個元件都需要自己的韌體映像。 在設計中，一個元件是主要元件，而相依子元件會連接到該主要元件。 每個元件都是由元件標識碼唯一描述。
操作系統會顯示多元件裝置做為單一單位。 主機只會與裝置互動，通常是使用此 CFU 通訊協定的主要元件。 元件與其子元件之間的通訊超出此規格的範圍。
在計算機上，可能會有許多不同的裝置 (裝置可能有一或多個元件) 。 在此通訊協定的內容中，每個裝置的通訊都是獨立的。 每個裝置都有對應的主機實例。
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 狀態：傳送韌體
在此狀態中，主機會開始將韌體映射傳送至主要元件，該元件先前已接受供應專案。
因為韌體映像的內容可能會超過單一命令的承載限制，所以主機會將韌體映射分成封包。 主機會依序在個別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 個元件的版本資訊 (一個主要元件，以及最多六個子元件) 。
表 5.1-1 GET_FIRMWARE_VERSION回應配置
5.1.2.1 標頭
表 5.1-2 GET_FIRMWARE_VERSION回應 - 標頭配置
回應的標頭會提供下列資訊。
表 5.1-3 GET_FIRMWARE_VERSION回應 - 標頭位
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 0 | 元件計數 | 8 | 透過此元件這個機制管理的可下載元件數目。 元件計數決定數據表大小上限。 目前支援最多 7 個元件，以確保回應可以符合允許的 60 個字節。 |
| 8 | Rsvd | 16 | 保留欄位。 寄件者必須將這些設定為 0。 接收者必須忽略此值。 |
| 24 | 通訊協定版本 | 4 | 韌體更新修訂位代表 FW 更新通訊協定修訂目前正在傳輸中使用。 針對此處定義的介面，FW 更新修訂必須是 0010b。 |
| 28 | Rsvd | 3 | 保留欄位。 寄件者必須將這些設定為 0。 接收者必須忽略此值。 |
| 31 | E | 1 | 延伸模組旗標是未來通訊協定勾點，可報告其他元件。 |
5.1.2.2元件版本和屬性
針對每個元件，會使用兩個 DWORD 來描述元件最多 7 個元件的屬性。 如果標頭中的元件計數小於 7，則響應結尾的未使用 DWORDS 必須設定為 0。
表 5.1-4 GET_FIRMWARE_VERSION回應 - 元件版本和屬性版面配置
每個元件特定信息都會在兩個 DWORD 中描述，如下所示：
表 5.1-5 GET_FIRMWARE_VERSION回應 - 元件版本和屬性問題
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 0 | 韌體版本 | 32 | 傳回該元件的目前韌體版本。 此規格不會針對韌體版本規定任何特定格式。 如需指導方針，請參閱韌體版本一節。 |
| 32 | Bank | 2 | 選擇性。 根據架構，元件硬體可能會有多個存放韌體的銀行。 視實作而定，傳送者可以指定韌體目前存在的銀行。 此欄位為條件式強制 - 支持是選擇性的，但不得用於任何其他用途。 |
| 34 | 保留 | 2 | 保留欄位。 寄件者必須將這些設定為 0。 接收者必須忽略此值。 |
| 36 | 廠商特定 | 4 | 可能以實作特定方式使用的廠商特定欄位。 廠商可以使用這些位來編碼資訊，例如： - 韌體類型：發行前版本/自我主機/生產;debug/retail - 開發階段 - 產品識別碼，以防止元件使用相同的更新通訊協定接收其他產品的韌體。 |
| 40 | 元件識別碼 | 8 | 元件的唯一標識碼。 |
| 48 | 廠商特定 | 16 | 可能以實作特定方式使用的廠商特定欄位。 |
5.1.3 對應至 HID
除了報表標識碼之外，這會實作為回應大小為60個字節的 HID取得功能 要求。 功能報表長度會容納整個GET_FIRMWARE_VERSION回應。 沒有與主機取得功能要求相關聯的數據。
5.2 FIRMWARE_UPDATE_OFFER
判斷主要元件是否接受或拒絕韌體。
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 | 元件識別碼 | 8 | 此位元組用於多元件案例。 此欄位可用來識別供應專案的子元件。 如果未使用，則值應為 0。 元件識別碼的可能值如下所示： 1 - 0xDF：有效 0xE0 - 0xFD：保留。 請勿使用。 0xFF：供應專案是特殊的供應專案資訊封包。 如需詳細資訊，請參閱FIRMWARE_UPDATE_OFFER資訊。 0xFE：供應專案是特殊的供應專案命令封包。 如需詳細資訊，請參閱FIRMWARE_UPDATE_OFFER擴充一節。 |
| 24 | 語彙基元 | 8 | 主機會將唯一令牌插入供應專案封包至元件。 此令牌必須由供應項目回應中的元件傳回。< 如果元件需要區分不同的主機/主機類型，這會很有用。 要使用的確切值是特定實作。 例如，一個值可用於驅動程式，另一個值則用於應用程式。 這可讓目前的裝置韌體考慮 CFU 命令的潛在多個寄件者。 其中一個可能的實作可能是接受第一個 CFU 命令，並拒絕所有其他具有不同令牌的命令，直到第一個 CFU 交易完成為止。 |
5.2.1.2 韌體版本
這四個字節代表 32 位版本的韌體。 此規格未強制使用韌體版本的格式。 建議使用下列專案。
表 5.2-4 FIRMWARE_UPDATE_OFFER 命令 - 韌體版本配置
此規格未強制使用韌體版本的格式，不過，以下是建議的指導方針。
表 5.2-5 FIRMWARE_UPDATE_OFFER 命令 - 韌體版本位
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 0 | Variant | 8 | 可能會描述此欄位，以區分發行前版本韌體和生產韌體。 它可能表示用來簽署韌體的簽章類型。 |
| 8 | 次要版本 | 16 | 每個韌體組建都應該更新此域值。 每個韌體組建都應該更新此域值。 |
| 24 | 主要版本 | 8 | 此欄位是韌體映像的主要版本。 當寄送新的生產線、韌體的主要新更新等等時，應該更新此字段。 |
5.2.1.3 廠商特定
這四個字節可用來編碼供應專案中廠商實作特有的任何自定義資訊。
5.2.1.4 Misc 和通訊協定版本
這四個字節可用來編碼供應專案中廠商實作特有的任何自定義資訊。
表 5.2-6 FIRMWARE_UPDATE_OFFER 命令 - 廠商特定版面配置
下表說明廠商特定位元組的位。
表 5.2-7 FIRMWARE_UPDATE_OFFER 命令 - Misc 和通訊協定版本
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 0 | 通訊協定版本 | 4 | 此欄位必須設定為 0010b，指出主機 /供應項目對應至 CFU 通訊協定的第 2 版。 |
| 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回應 - 令牌配置
此表格說明 Token 位元組的位。
表 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回應 - 拒絕原因位
下表說明拒絕原因位元組的位。
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 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 | 供應專案遭到拒絕，因為提供的韌體不適用於產品的平臺。 這可能是因為不支援的元件標識碼或提供的映像與系統硬體不相容。 |
| 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 Code 域值中 的原因。 如需 RR 程式代碼的狀態對應，請參閱表 5.2-16。 |
| 8 | 保留 | 24 | 保留的。 請勿使用。 |
下表說明 Status 位元組的可能值。
表 5.2-16 FIRMWARE_UPDATE_OFFER回應狀態值
| 狀態 | 名稱 | 描述 |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | 元件已決定略過供應專案。 主機稍後必須再次提供它。 |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | 元件已決定接受供應專案。 |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | 元件已決定拒絕供應專案。 |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | 裝置忙碌中，且主機必須等到裝置就緒為止。 |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | 當元件資訊位元組中的元件識別碼 (請參閱 5.1.2.1.1 元件資訊) 設為 0xFE時使用。 針對 [命令程序代碼] 設定為 [OFFER_NOTIFY_ON_READY要求]，表示配件已準備好接受其他供應專案。 |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | 無法辨識供應專案要求。 |
5.2.3 對應至 HID 通訊協定
訊息會透過 HID 輸出報告 機制發出給元件，方法是使用韌體更新的專用 HID 公用程式報告標識符。 要用於附錄中所述的 HID 公用程式 TLC。
5.3 FIRMWARE_UPDATE_OFFER - 資訊
如果元件資訊位元組中的元件標識碼 (請參閱元件資訊) 設為 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 中所述的其中一個可能值。 |
| 8 | 保留的。 | 8 | 保留的。 請勿使用。 |
| 16 | 元件識別碼 | 8 | 設定為 0xFF。 |
| 24 | 語彙基元 | 主機會將唯一令牌插入供應專案封包至元件。 此令牌必須由供應項目回應中的元件傳回。 |
表 5.3-4 FIRMWARE_UPDATE_OFFER - 資訊命令 - 資訊碼值
| 狀態 | 名稱 | 描述 |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | 表示主機是新的，或已重載，而且整個供應項目處理 (重新) 啟動。 |
| 0x01 | OFFER_INFO_START_OFFER_LIST | 指出如果 Accessory 有與確保一個子元件在系統中另一個子元件之前更新相關聯的下載規則，則指出主機的供應專案清單開頭。 |
| 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- 資訊封包回應令牌配置
此表格說明 Token 位元組的位。
表 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 程式代碼配置
下表說明拒絕原因位元組的位。
表 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 | 供應專案遭到拒絕，因為提供的韌體不適用於產品的平臺。 這可能是因為不支援的元件標識碼或提供的映像與系統硬體不相容。 |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | 元件韌體已更新，但新韌體的交換擱置中。 在交換完成之前，通常不會再進行韌體更新處理，通常是透過重設。 |
| 0x03 - 0x08 | (保留) | 保留的。 請勿使用。 |
| 0x09 - 0xDF | (保留) | 保留的。 請勿使用。 |
| 0xE0 — 0xFF | (廠商特定) | 這些值是由通訊協議的設計工具所使用，這表示是廠商特定的。 |
5.3.2.4 狀態
表 5.3-11 FIRMWARE_UPDATE_OFFER - 供應專案資訊回應狀態配置
下表說明狀態位元組的位。
表 5.3-12 FIRMWARE_UPDATE_OFFER - 供應項目資訊 - 回應狀態位
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 0 | 狀態 | 8 | 此欄位必須設定為 FIRMWARE_UPDATE_OFFER_ACCEPT。 這表示元件已決定接受供應專案。 |
| 8 | 保留的。 | 24 | 保留的。 請勿使用。 |
5.4 FIRMWARE_UPDATE_OFFER - 擴充
如果元件資訊位元組中的元件標識碼設定為0xFE，則會重新定義 (15 個字節) 的位，以指出從主機到裝置韌體的供應專案命令。 此機制允許擴充性，以及主機提供特定資訊給裝置的方式。 當元件準備好回應 [已接受] 時，會傳回供應專案命令封包。
5.4.1 命令
如果元件資訊位元組中的元件標識碼設定為 0xFE，則會重新定義四個 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 中所述的其中一個可能值。 |
| 8 | 保留的。 | 8 | 保留的。 請勿使用。 |
| 16 | 元件識別碼 | 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 - 來自裝置的供應專案命令回應可能不會立即收到。 回應的定義如下。
表 5.4-5 FIRMWARE_UPDATE_OFFER - 擴充命令封包回應配置
5.4.2.1 令牌
表 5.4-6 FIRMWARE_UPDATE_OFFER- 供應專案命令封包回應 - 令牌配置
此表格說明 Token 位元組的位。
表 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 配置
下表說明拒絕原因位元組的位。
表 5.4-9 FIRMWARE_UPDATE_OFFER- 供應專案命令回應 - RR 程式代碼
| 位位移 | 欄位 | 大小 | 描述 |
|---|---|---|---|
| 0 | RR 程式代碼 | 8 | 此值取決於 [狀態] 欄位。 如需可能的 RR 程式代碼值，請參閱表 5.4-10。 |
| 8 | 保留 | 24 | 保留的。 請勿使用。 |
下表說明 RR 程式代碼位元組的可能值。
表 5.4-10 FIRMWARE_UPDATE_OFFER- 提供命令封包 - RR 程式代碼值
| RR 程式代碼 | 名稱 | 描述 |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | 因為提供的韌體版本較舊或與目前的韌體相同，所以已拒絕供應專案。 |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | 供應專案遭到拒絕，因為提供的韌體不適用於產品的平臺。 這可能是因為不支援的元件標識碼或提供的映像與系統硬體不相容。 |
| 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 FIRMWARE_UPDATE_CONTENT
主機會將此命令傳送至裝置韌體，以提供韌體內容 (，也就是韌體映像) 。 整個圖像檔不預期符合單一命令。 主機必須將映像分成較小的區塊，而且每個命令一次都會傳送一個映像區塊。
使用每個命令時，主機會指出其他資訊—它是否為韌體的第一個區塊、最後一個區塊等等。 裝置韌體的主要元件會接受傳入韌體映像的每個區塊、將其儲存在其記憶體中，而且必須個別回應每個命令。
當主要元件收到最後一個區塊時，元件會驗證整個韌體映射， (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 | Flags | 8 | 此欄位提供命令的額外資訊。 此值是用於數據傳輸的旗標遮罩。 表格 5.5-4 會說明可能的值。 |
| 8 | 數據長度 | 8 | 適用的 [數據] 字段長度，指出要寫入的位元元組數目。 假設此命令的大小，長度允許的最大值為 52 個字節。 |
| 16 | 序號 | 16 | 這個值是由主機所建立，而且對於發出的每個內容封包而言都是唯一的。 元件必須傳回此要求的回應中的序號。 |
| 32 | 韌體位址 | 32 | 小結束 (LSB First) Address 來寫入數據。 位址是以 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 | FIRMWARE_UPDATE_SUCCESS | 要求已順利完成。 |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | 元件未準備好接收韌體內容。 如果使用，此程式代碼通常會用於回應第一個區塊。 例如，清除快閃上的錯誤。 |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | 要求無法寫入位元組。 |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | 要求無法設定交換以回應FIRMWARE_UPDATE_FLAG_LAST_BLOCK。 |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | DWORD 的驗證失敗，以回應FIRMWARE_UPDATE_FLAG_VERIFY。 |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | 韌體映像的CRC無法回應FIRMWARE_UPDATE_FLAG_LAST_BLOCK。 |
| 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_ERROR_NO_OFFER | 收到FIRMWARE_UPDATE_OFFER命令，但未先收到有效且接受的韌體更新供應專案。 |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | FIRMWARE_UPDATE_OFFER命令的一般錯誤，例如無效適用的數據長度。 |
5.5.2.3 保留 B8 - B11
保留的。 請勿使用。
5.5.2.4 保留 B12 - B15
保留的。 請勿使用。
6 附錄 1：韌體更新程序設計命令順序範例
6.1 範例 1
請考慮下列裝置韌體：
主要元件 - 元件識別碼 1 - 目前的韌體版本 7.0.1
子元件 - 元件標識碼 2 - 目前的韌體版本 12.4.54
子元件 - 元件識別碼 3 - 目前的韌體版本 4.4.2
子元件 - 元件標識碼 4 - 目前的韌體版本 23.32.9
主機有下列三個韌體映射：
元件識別碼 1 - 韌體 7.1.3 版
元件識別碼 2 - 韌體版本 12.4.54
元件識別碼 3 - 韌體 4.5.0 版
順序會是：
主機供應專案：元件標識碼 1 - 韌體 7.1.3 版
主要元件接受供應專案
主機傳送韌體映像
主要元件接受韌體，驗證它
主機供應專案：元件標識碼 2 - 韌體 12.4.54 版
主要元件拒絕供應專案
主機供應專案：元件標識碼 3 - 韌體 4.5.0 版
主要元件接受供應專案
主機傳送韌體映像
主要元件接受韌體，驗證它
因為所有供應專案都未遭到拒絕，主機會重新執行所有供應專案：
主機供應專案：元件標識碼 1 - 韌體 7.1.3 版
元件拒絕
主機供應專案：元件標識碼 2 - 韌體 12.4.54 版
元件拒絕
主機供應專案：元件標識碼 3 - 韌體 4.5.0 版
元件拒絕
6.2 範例 2
請考慮下列裝置韌體：
主要元件 - 元件識別碼 1 - 目前的韌體版本 7.0.1
子元件 - 元件標識碼 2 - 目前的韌體版本 12.4.54
子元件 - 元件識別碼 3 - 目前的韌體版本 7.4.2
子元件 - 元件標識碼 4 - 目前的韌體版本 23.32.9
主機有下列三個韌體映射：
元件識別碼 1 - 韌體 8.0.0 版
元件識別碼 2 - 韌體版本 12.4.54
元件識別碼 3 - 韌體版本 9.0.0
此外，實作需要子元件的韌體版本不得小於主要元件上執行的韌體版本。 主機不知道該需求，而且是主要元件，以確保此規則。
順序會是：
主機供應專案：元件標識碼 1 - 韌體 8.0.0 版
主要元件拒絕 (，因為元件標識碼 3 尚未更新)
主機供應專案：元件標識碼 2 - 韌體 12.4.54 版
主要元件拒絕
主機供應專案：元件標識碼 3 - 韌體 9.0.0 版
主要元件接受供應專案
主機傳送韌體映像
主要元件接受韌體，驗證它
因為所有供應專案都未遭到拒絕，主機會重新執行所有供應專案
主機供應專案：元件標識碼 1 - 韌體 8.0.0 版
主要元件接受供應專案
主機傳送韌體映像
主要元件接受韌體，驗證它
主機供應專案：元件標識碼 2 - 韌體 12.4.54 版
主要元件拒絕
主機供應專案：元件標識碼 3 - 韌體 9.0.0 版
主要元件拒絕