创作固件更新包

每个固件更新包都包含一个包含整个固件有效负载的二进制文件 (例如 firmware.bin) 以及一个安全目录Windows用于验证 firmware.bin。 有关安全目录和驱动程序详细信息, 请参阅目录文件和 数字签名和 为 PnP 驱动程序包创建目录文件

固件更新包必须能够更新以下一种或多种固件类型:

  • UEFI 系统固件。

  • 系统中单个设备的固件。

建议每个固件更新包以单个固件资源 (UEFI 系统固件或单个设备) 为目标,但在某些情况下,具有一个更新系统固件和一个或多个设备的固件更新包可能更有利。

注意

设备不能成为多个固件更新包的目标。 如果设备的目标固件更新包也包含系统固件,则它不能被仅面向该设备的第二个固件更新包作为目标。

  1. 若要允许固件更新包将固件更新目标定向到相应的系统硬件,Windows 将针对 ESRT 中每个条目显示一个设备实例,其中此类设备实例会公开一个硬件 ID,该 ID 标识它属于 ESRT 条目。

  2. 安装固件更新包时,它由Windows驱动程序包进行处理。 Windows将每个更新包的固件有效负载复制到系统目录下的安全位置,请准备系统以执行固件更新并触发系统重启。

    Windows不支持驱动程序包之间的依赖关系。 因此,创作新的固件更新包时,必须遵守以下要求:

    • 固件更新包必须能够自行成功安装,且无需依赖于其他设备固件、系统固件或其他固件更新包。

    • 建议将每个更新包定目标到系统上的单个设备或 UEFI 系统固件 (ESRT) 。

    • 每个更新包必须包含单个固件更新二进制文件 (例如 firmware.bin) 。

  3. 每个更新包中的固件更新有效负载需要包含在单个二进制文件中。 在系统重新启动时,OS 加载程序将每个固件更新包的每个固件更新二进制文件载入物理内存,并生成一个指向为安装预配的每个有效负载文件的指针数组 (UEFI 2.3.1 规范将此数组引用为"可能"HeaderArray) 。

  4. 此数组在调用 EFI UpdateCapsule () 函数时传递。 UpdateCapsule () 用作邮箱,将每个驱动程序包的固件更新有效负载传递到平台固件。

  5. 每个 (一个固件更新有效负载) 由固件资源的 ESRT 条目指定的固件 ID 标识。

  6. 收到每个固件更新有效负载后,将处理并应用固件更新请求(如果适用)。

    HeaderArray 中的每个条目都是一个连续的数据块,其中包含来自系统中单个设备的固件驱动程序包的固件更新有效负载。 对于每个目标固件资源,固件更新有效负载必须包含固件映像和平台验证所需的所有信息。

    所有固件更新驱动程序包的固件有效负载都通过 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 表

自定义不同地理区域的固件

认证和签署更新包

安装更新