此規格描述一般 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 命令 - 雜項和協議版本
表 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 為基礎，廣泛存在，並透過 USB 和 I2C 等各種互連匯流提供 Windows 原生支援。 因此，可以利用相同的軟體（驅動程式）解決方案來更新所有元件的韌體。
注意
因為規格是以封包為基礎，所以很容易適應非 HID 案例。
規格可讓元件接受韌體，而不會在下載期間中斷裝置作業。 它可讓用戶獲得更好的體驗，因為他們不需要等待韌體更新程式完成，才能繼續其他工作。 新的韌體可以在單一原子操作中被調用，對用戶的影響達到最小程度。
此規格支援允許元件包含子元件的配置，每個子元件需要單獨的韌體映像。
注意
將韌體交給子元件的元件程式超出此規格的範圍。
規格支援 提議的概念，取決於負責的元件來決定是否接受韌體。 接受新韌體的決定並不簡單。 韌體類型和/或版本與套用新韌體之硬體的基礎類型/版本之間可能會有相依性。 供應專案也會做為優化機制，因為韌體映射只有在能夠 /ready 接受時才會傳送至元件。
1.1 詞彙
| 術語 | 描述 |
|---|---|
| 元件識別碼 | 在具有多個元件的裝置中，元件標識碼可唯一識別每個元件。 |
| CRC | 循環冗餘檢查 非密碼編譯哈希演算法，用來產生數據區塊的摘要或指紋。 CRC 是用來做為檢查，以確保計算 CRC 之後，數據區塊尚未變更。 CRC 並非萬無一失，但能讓人有信心正確接收到數據。 |
| 裝置 | 元件的集合（一個主要元件和零個或多個子元件）。 該裝置在操作系統中顯示為單一單元。 主設備會與裝置互動，並且通常作為主要組成元件。 計算機中可能有多個裝置。 就此規格而言，對 2 部不同裝置的通訊完全獨立。 |
| 司機 | 使用 Windows Driver Foundation （WDF） 架構所撰寫的驅動程式。 |
| 固件 | 在實體硬體上執行的程序代碼。 韌體是可更新的，通常位於與硬體相關聯的可程式化記憶體中。 |
| 硬體 | 電腦上的一個實體矽片。 |
| 主要元件 | 計算機上的一個硬體及其韌體。 在此規格的內容中，元件是需要並接受韌體更新的實體。 |
| 段 | 元件的韌體映像可能會分割成較小的區段。 每個區段都是小型韌體映像。 |
| 區段標識碼 | 如果元件的韌體分割成較小的區段，區段標識符是區段的唯一標識符。 |
| 簽名 | 密碼編譯方法，用來判斷韌體映射是否已以未經授權的方式改變。 簽章是可選的，但建議使用，並且超出了此規範的範疇。 |
| 子元件 | 視硬體架構而定，操作系統可能看不到所有元件，因為它們可能連線到系統可見的元件下游。 這些元件在此規格中稱為子元件。 |
| 關愛 | HID 最上層集合。 |
| 令牌 | 主機會話的標識碼。 主機會建立令牌，並在命令中傳送它，而裝置則會在回應中返回該令牌。 令牌可以用於序列化特定交易，或識別已經遺失的會話並啟動另一個。 |
1.2 範圍
1.2.1 目標
需要一種與總線無關的解決方案，以避免為每種總線類型制定新的協定。 HID 無處不在，可解決該需求。
支援多元件裝置韌體更新的功能，其中一個元件會做為主要元件，而其他元件則是連接到主要元件的子元件。 每個元件都需要自己的韌體，彼此之間具有非簡單相依性。
將韌體映像下載至元件的通用驅動程式模型。 接著，元件擁有專為子元件設計的特定演算法來進行轉送。 子元件也可能在其韌體上執行有效性檢查，並將結果傳回主要元件。
在裝置作業進行時支援韌體更新的能力。
透過授權工具更新/復原生產裝置中的韌體，並透過 Windows Update 更新市場上的裝置的能力。
支持開發中韌體/市場上韌體的靈活性。
能夠將大型韌體映射分割成較小的區段，讓元件更容易接受韌體映像。
1.2.2 非目標
定義韌體映像的內部格式：對於主機，韌體映像是一組位址和載荷條目。
簽署/加密/驗證已接受的韌體：此規格不會描述如何簽署和加密韌體映像。 元件目前執行的預期韌體需要驗證正在下載的韌體。
定義一種機制說明元件如何與子元件互動：主機通常作為主要元件，會將裝置視為單一單位來進行互動。 元件必須作為與子元件韌體相關通訊的橋樑。
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 取得固件版本
取得主要元件的目前韌體版本（及其子元件）。 命令沒有任何自變數。
5.1.1 命令
主機會傳送此命令，以查詢主要元件上目前韌體的版本（及其子元件）。 主機可以使用它來確認韌體是否已成功更新。 在收到此命令時，主要元件會回應其自身和所有子元件的韌體版本。
5.1.2 回應
元件會回應主要元件和子元件的韌體版本。 回應大小為60個字節，允許最多七個元件的版本資訊（一個主要元件和最多六個子元件）。
表 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 更新修訂必須是 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 | 銀行 | 2 | 自選。 根據架構，元件硬體可能會有多個存放韌體的銀行。 根據實作而定，傳送者可以指定目前存在韌體所在的銀行。 此欄位為 [條件式強制] - 支援是選擇性的，但不得用於任何其他用途。 |
| 34 | 保留 | 2 | 保留欄位。 寄件者必須將這些設定為 0。 接收者必須忽略此值。 |
| 36 | 廠商專屬 | 4 | 廠商專用欄位可在特定實作中使用。 廠商可以使用這些位來編碼資訊，例如： - 韌體類型：發行前版本/自我托管/生產環境；除錯/零售 - 開發階段 - 產品識別碼，以防止元件使用相同的更新通訊協定接收其他產品的韌體。 |
| 40 | 元件識別碼 | 8 | 元件的唯一標識碼。 |
| 48 | 廠商專屬 | 16 | 廠商專用欄位可在特定實作中使用。 |
5.1.3 對應至 HID
除了報表 ID 以外，這是以 HID Get Feature 要求來實現的，回應大小為 60 個字節。 功能報表長度會容納整個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 | 元件識別碼 | 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 | 變體 | 8 | 此欄位可描述為區分發行前版本韌體與生產韌體。 它可能表示用來簽署韌體之簽章的類型。 |
| 8 | 次要版本 | 16 | 每個韌體組建都應該更新此域值。 每個韌體組建都應該更新此域值。 |
| 24 | 主要版本 | 8 | 此欄位是韌體映像的主要版本。 當運送新的產品線、韌體的重大新更新等等時，應該更新此欄位。 |
5.2.1.3 廠商特定
這四個字節可用來編碼提案中與特定廠商實作相關的任何自訂資訊。
5.2.1.4 雜項和通訊協定版本
這四個字節可用來編碼提案中與特定廠商實作相關的任何自訂資訊。
表格 5.2-6 FIRMWARE_UPDATE_OFFER 命令 - 廠商專用配置
下表說明廠商特定位元組的位元。
表 5.2-7 FIRMWARE_UPDATE_OFFER 命令 - 其他和通訊協定版本
| 位元偏移 | 領域 | 大小 | 描述 |
|---|---|---|---|
| 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 | 固件提供拒絕舊版固件 | 供應專案遭到拒絕，因為提供的韌體版本較舊或與目前的韌體相同。 |
| 0x01 | 韌體提供拒絕無效組件 | 提案被拒絕，因為提供的韌體不適用於產品的平台。 這可能是因為不支援的元件標識碼或提供的映像與系統硬體不相容。 |
| 0x02 | 韌體更新邀約 交換待處理 | 元件韌體已更新，但是目前尚未切換至新的韌體。 在交換完成之前，不會再進行韌體更新處理，通常是透過重設。 |
| 0x03 - 0x08 | （保留） | 保留。 請勿使用。 |
| 0x09 - 0xDF | （保留） | 保留。 請勿使用。 |
| 0xE0 - 0xFF | （廠商特定） | 這些值是由通訊協議的設計工具所使用，其意義是廠商特定的。 |
5.2.2.4 狀態
表格 5.2-14 FIRMWARE_UPDATE_OFFER 回應狀態佈局
這個表格描述了狀態位元組的位元。
表 5.2-15 FIRMWARE_UPDATE_OFFER 回應 - 狀態位
| 位元偏移 | 領域 | 大小 | 描述 |
|---|---|---|---|
| 0 | 地位 | 8 | 此值表示元件決定接受、待定、略過或拒絕報價。 元件提供 RR Code 欄位值中的原因。 如需狀態至 RR 代碼對應，請參閱表 5.2-16。 |
| 8 | 保留 | 24 | 保留。 請勿使用。 |
下表說明 Status byte 的可能值。
表格 5.2-16 FIRMWARE_UPDATE_OFFER 回應狀態值
| 地位 | 名字 | 描述 |
|---|---|---|
| 0x00 | 韌體更新跳過選項 | 元件決定跳過此提案。 主持人稍後必須再次提供這個。 |
| 0x01 | 韌體更新接受邀請 | 部門已決定接受提議。 |
| 0x02 | 韌體更新邀約被拒絕 | 部門已決定拒絕該提議。 |
| 0x03 | 韌體更新提議忙碌中 | 裝置正忙，主機必須等到裝置準備好。 |
| 0x04 | 固件更新邀約命令 | 當元件資訊位元組中的元件標識碼（請參閱 5.1.2.1.1元件資訊）設定為0xFE時使用。 針對指令代碼設為OFFER_NOTIFY_ON_READY之要求，表示配件已準備好接受額外的提議。 |
| 0xFF | 韌體更新命令不支援 | 無法辨識報價要求。 |
5.2.3 對應至 HID 通訊協定
訊息是透過 HID 輸出報告 機制，使用專用於韌體更新的 HID 公用報告 ID，發送給元件。 使用附錄中所述的 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 | 固件提供拒絕舊版固件 | 供應專案遭到拒絕，因為提供的韌體版本較舊或與目前的韌體相同。 |
| 0x01 | 韌體提供拒絕無效組件 | 提案被拒絕，因為提供的韌體不適用於產品的平台。 這可能是因為不支援的元件標識碼或提供的映像與系統硬體不相容。 |
| 0x02 | 韌體更新邀約 交換待處理 | 元件韌體已更新，但是目前尚未切換至新的韌體。 在交換完成之前，不會再進行韌體更新處理，通常是透過重設。 |
| 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 | 提供_通知_準備_完成 | 如果提供的提案先前被元件拒絕，那麼便由主持者傳送。 |
| 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 | 固件提供拒絕舊版固件 | 供應專案遭到拒絕，因為提供的韌體版本較舊或與目前的韌體相同。 |
| 0x01 | 韌體提供拒絕無效組件 | 提案被拒絕，因為提供的韌體不適用於產品的平台。 這可能是因為不支援的元件標識碼或提供的映像與系統硬體不相容。 |
| 0x02 | 韌體更新邀約 交換待處理 | 元件韌體已更新，但是目前尚未切換至新的韌體。 在交換完成之前，不會再進行韌體更新處理，通常是透過重設。 |
| 0x03 - 0x08 | （保留） | 保留。 請勿使用。 |
| 0x09 - 0xDF | （保留） | 保留。 請勿使用。 |
| 0xE0 — 0xFF | （廠商特定） | 這些值是由通訊協議的設計工具所使用，其意義是廠商特定的。 |
5.4.2.4 狀態
表 5.4-11 FIRMWARE_UPDATE_OFFER - 提供命令封包回應狀態結構
這個表格描述了狀態位元組的位元。
表 5.4-12 FIRMWARE_UPDATE_OFFER- 發送命令封包回應 RR 代碼
| 位元偏移 | 領域 | 大小 | 描述 |
|---|---|---|---|
| 0 | 地位 | 8 | 此欄位必須設定為 FIRMWARE_UPDATE_OFFER_ACCEPT。 這表示該模組已決定接受該報價。 |
| 8 | 保留。 | 24 | 保留。 請勿使用。 |
5.5 韌體更新內容
主機會將此命令傳送至裝置韌體，以提供韌體內容（也就是韌體映射）。 整個圖像檔不應該放入單一命令中。 主機必須將映像分成較小的區塊，而且每個命令一次都會傳送映像的一個區塊。
使用每個命令時，主機會指出更多資訊——例如它是否是韌體的第一個區塊、最後一個區塊，等等。 裝置韌體的主要元件會接受傳入韌體映像的每個區塊、將其儲存在記憶體中，而且必須個別回應每個命令。
當主要元件收到最後一個區塊時，元件會驗證整個韌體映射（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 byte 的可能值。
表 5.5-12 FIRMWARE_UPDATE_OFFER - 回應 - 狀態代碼值
| 旗 | 名字 | 描述 |
|---|---|---|
| 0x00 | 韌體更新成功 | 要求成功完成。 |
| 0x01 | 韌體更新錯誤準備 | 元件尚未準備好接收韌體內容。 如果使用，此程式代碼通常會用於第一個區塊的回應中。 例如，清除快閃上的錯誤。 |
| 0x02 | 韌體更新錯誤寫入 | 要求無法寫入位元組。 |
| 0x03 | 固件更新錯誤完成 | 要求無法設定交換以回應FIRMWARE_UPDATE_FLAG_LAST_BLOCK。 |
| 0x04 | 韌體更新錯誤驗證 | DWORD 驗證失敗，以回應FIRMWARE_UPDATE_FLAG_VERIFY。 |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | 韌體映像的CRC因應FIRMWARE_UPDATE_FLAG_LAST_BLOCK的要求而失敗。 |
| 0x06 | 韌體更新錯誤簽名 | 韌體簽章驗證在響應 FIRMWARE_UPDATE_FLAG_LAST_BLOCK 時失敗。 |
| 0x07 | 韌體更新版本錯誤 | 韌體版本驗證無法回應FIRMWARE_UPDATE_FLAG_LAST_BLOCK。 |
| 0x08 | 韌體更新交換待命中 | 韌體已更新，交換待處理中。 在配件重設之前，無法接受任何進一步的韌體更新命令。 |
| 0x09 | 韌體更新錯誤_無效地址 | 韌體偵測到訊息數據內容內無效的目的地位址。 |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER（固件更新錯誤：無可用更新） | 收到FIRMWARE_UPDATE_OFFER命令，但未事先接收到有效且被接受的韌體更新提議。 |
| 0x0B | 韌體更新錯誤：無效 | 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 版
此外，實作要求子元件的韌體版本不得小於主要元件上執行的韌體版本。 主機不知道該需求，而 up-to 作為確保此規則的主要元件。
順序會是：
主機提供：元件標識碼 1 - 韌體版本 8.0.0
主要元件拒絕 （因為元件識別碼 3 尚未更新）
主機提供：元件識別碼 2 - 韌體版本 12.4.54
主要元件被拒
主機提供：元件 ID 3 - 韌體版本 9.0.0
主要元件接受提案
主機傳送韌體映像
主要元件接受韌體，驗證它
因為所有提議都未被拒絕，主持人會重新展示所有提議。
主機提供：元件標識碼 1 - 韌體版本 8.0.0
主要元件接受提案
主機傳送韌體映像
主要元件接受韌體，驗證它
主機提供：元件識別碼 2 - 韌體版本 12.4.54
主要元件被拒
主機提供：元件 ID 3 - 韌體版本 9.0.0
主要元件被拒