撰寫韌體更新套件

每個韌體更新套件都包含單一二進位檔案，其中包含整個韌體承載 (，例如 firmware.bin) ，以及 Windows 用來驗證 firmware.bin 的安全性類別目錄。 如需安全性類別目錄和驅動程式的詳細資訊，請參閱類別目錄檔案和數位簽章和建立 PnP 驅動程式套件的類別目錄檔案。

韌體更新套件必須能夠更新下列一或多個韌體類型：

• UEFI 系統韌體。

• 系統中單一裝置的韌體。

建議每個韌體更新套件以單一韌體資源為目標， (UEFI 系統韌體或單一裝置) ，但在某些情況下，有一個可同時更新系統韌體和一或多個裝置的單一韌體更新套件會比較好。

一個以上的韌體更新套件無法將裝置設為目標。 如果裝置是以同時包含系統韌體之韌體更新套件為目標，則只能以裝置為目標的第二個韌體更新套件為目標。

1. 為了允許韌體更新套件以適當系統硬體的韌體更新為目標，Windows 會針對 ESRT 中的每個專案呈現裝置實例，其中這類裝置實例會公開硬體識別碼，以識別它為屬於 ESRT 專案。

2. 安裝韌體更新套件時，Windows 會將它當做驅動程式套件來處理。 Windows 會將每個更新套件的韌體承載複製到系統目錄下的安全位置，準備系統執行韌體更新，並觸發系統重新開機。

   Windows 不支援驅動程式套件之間的相依性。 因此，撰寫新的韌體更新套件時，必須觀察到下列需求：

   • 韌體更新套件必須能夠自行成功安裝，而不需要相依于其他裝置韌體、系統韌體或其他韌體更新套件。

   • 建議每個更新套件都以系統上的單一裝置或 UEFI 系統韌體為目標， (定義于 ESRT) 中。

   • 每個更新套件都必須包含單一韌體更新二進位 (，例如 firmware.bin) 。

3. 每個更新套件中的韌體更新承載都必須包含在單一二進位檔中。 系統重新開機時，OS 載入器會將每個韌體更新套件的每個韌體更新二進位檔載入到實體記憶體中，並建置針對安裝布建之每個承載檔案的指標陣列， (UEFI 2.3.1 規格會將此陣列稱為 CapsuleHeaderArray) 。

4. 這個陣列會傳入對 EFI UpdateCapsule () 函式的呼叫。 UpdateCapsule () 會作為信箱使用，並將每個驅動程式套件的韌體更新承載傳遞至平臺韌體。

5. 每個封裝 (韌體更新承載) 是由韌體資源的 ESRT 專案所指定的韌體識別碼來識別。

6. 收到每個韌體更新承載時，會在適用時處理並套用韌體更新要求。

   CapsuleHeaderArray 中的每個專案都是單一連續的資料區塊，其中包含系統中單一裝置韌體驅動程式套件的韌體更新承載。 針對每個目標韌體資源，韌體更新承載必須包含韌體映射，以及平臺進行驗證所需的所有資訊。

   所有韌體更新驅動程式套件的韌體承載都會透過 UEFI UpdateCapsule 服務傳遞至平臺韌體。 由於整合式裝置的來源是各種不同的 IHV，因此系統 OEM (，而且 SoC 製造商可能) 必須直接使用這些 IHV，以確保為指定的系統適當撰寫裝置韌體更新。 此外，系統 OEM 必須確定 ESRT 專案允許 UpdateCapsule 套件以適當的系統為目標。

   例如，數個 OEM 可能會為其系統選擇相同的行動寬頻 (MBB) 裝置模型。 雖然每個系統中的 MBB 裝置都相同，但每個 OEM 都必須與 MBB IHV 共同作業，以撰寫為其系統自訂的韌體更新套件。 需要此層級的裝置韌體更新，才能解決 OEM 系統上的變數。

   • 根據 OEM 所選擇的 SoC，以及裝置連線到 SoC 的方式，定址裝置可能會有所不同。

   • 系統 OEM 可能會將系統銷售給多個行動網路操作員， (MNOs) 供取用者轉售。 MBB 裝置必須是 MNO 感知裝置，要求韌體同時受到特定 MNO 需求的自訂和認證。

   • 系統可能會在全球多個市場銷售，每個市場都有不同的 RF 法規和無線電頻率指派。 MBB 裝置韌體可能需要自訂以符合這些市場需求。

   每個 OEM 都必須仔細考慮這類裝置特定需求，並採取必要的步驟，以確保裝置韌體可以適當地設定和更新目標。 這需要仔細管理 ESRT 專案，以確保可以正確部署裝置韌體。

7. 在撰寫更新套件之後，必須提交至 Microsoft 進行認證和簽署。

相關文章

透過韌體驅動程式套件進行系統和裝置韌體更新

填入 ESRT 資料表

自訂不同地理區域的韌體

認證和簽署更新套件

安裝更新