> 7:0 - Version - OsTrialBootStatus 的版本号
> 11:8 - TrialBootMaxCount - 在触发 capsule 更新之前由操作系统设置。
> 15:12 - TrialBootCount - 由 UEFI 设置/递增（如果 OS 未清除 TrialBootEnabled）。如果操作系统想要触发固件回滚，则操作系统可以设置为 TrialBootMaxCount。
> 16 - TrialBootEnabled - 在 capsule 更新后由 UEFI 设置为 1，并在 OTA 成功更新后由操作系统清除。
> 31:17 - 未使用
>
|
| EFI 系统资源表 (ESRT) | ESRT 表由 UEFI 在 capsule 更新后设置。 |
有关 OsIndications 和 OsIndicationsSupported 变量的更多信息，请参见 [https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html?highlight=osindications#exchanging-information-between-the-os-and-firmware](https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html?highlight=osindications#exchanging-information-between-the-os-and-firmware)。
Note
- 如果 ESP 分区（在 EFI/UpdateCapsule 中）中有多个 capsule，则考虑更新所有 capsule，并按字母顺序更新。
- 将所有 UEFI 非易失性变量均存储在必须处于已配置状态的回滚保护内存块 (RPMB) 分区中。
>
>
> - 在启用 Qualcomm 安全启动的设备上自动配置 RPMB。
> - 在 Qualcomm 非安全设备上，请勿自动配置 RPMB，而是使用测试密钥进行配置。
> - 如果在非安全设备上使用测试密钥配置 RPMB，则在设备上启用 Qualcomm 安全启动时无法使用设备密钥重新配置。
> - 使用 `rpmbClient` 应用从 Linux 配置 RPMB。有关详细信息，请参阅 [Qualcomm 安全 Linux 指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11/bring-up.html#verify-trustzone/device-configuration/hypervisor-image-loading)。
## 用于 HLOS 的 capsule 更新状态的 EFI 系统资源表
>
>
> EFI 系统资源表 (ESRT) 是一种可选机制，用于识别设备和系统固件资源以进行固件更新。每个 ESRT 条目都描述一个可以更新的固件资源，并报告上次尝试更新的状态。ESRT 中用于报告上次尝试更新状态的条目有：
表：ESRT 条目
| **ESRT 字段** | **说明** |
| --- | --- |
| FwClass | 固件类字段包含一个 GUID，用于标识可通过 *UpdateCapsule()* 更新的固件组件。 |
| FwType | 标识固件资源的类型。 |
| FwVersion | 固件版本字段表示固件资源的当前版本。该值必须始终增加，因为较大的数字代表较新的版本。 |
| LowestSupportedFwVersion | 指定系统/设备的固件资源可以回滚到的最低固件资源版本。 |
| CapsuleFlags | capsule 标志字段包含在 capsule 标头中设置的 *EFI\_CAPSULE\_HEADER* 中定义的 *CapsuleGuid* 标志（ 0-15 位）。 |
| LastAttemptVersion | 该字段用于描述尝试更新的最后一个固件版本（使用与固件版本相同的格式）。 |
| LastAttemptStatus | 该字段用于描述固件资源条目的最后一次固件更新尝试的结果。 |
ESRT 内容由操作系统从 sysfs 路径公开。
/sys/firmware/efi/esrt/entries/entry0/
sh-5.1# cd /sys/firmware/efi/esrt/entries/entry0/
sh-5.1# ls
capsule_flags fw_type last_attempt_status lowest_supported_fw_version
w_class fw_version last_attempt_version
Copy to clipboard
ESRT 表由 UEFI 在胶囊更新后设置。X 代 capsule 更新之前的固件版本。Y 代表固件的版本，可在capsule [.cap] 文件中找到。
| **上次尝试的固件版本** | **当前固件版本** | **last\_attempt 状态** | **Capsule 更新场景** |
| --- | --- | --- | --- |
| Y | Y | 0 | 更新成功 |
| Y | X | 1 | Capsule 更新失败 |
| 0 | X | 0 | Capsule 元数据故障 |
| Y | X | 0 | 固件回滚完成 |
关于 ESRT 的更多信息，请参见[固件更新和报告 - UEFI Specification 2.10 documentation](https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html#efi-system-resource-table)
该流程图解释了如何使用 UEFI capsule 解决方案/方法（使用不同的 UEFI 变量以及回滚支持）更新设备固件。
1. **启动**: 无线 (OTA) 更新过程开始，操作系统准备更新 capsule ，向 UEFI 发出信号（通过设置 `OsIndications`）开始更新。操作系统设置 `TrialBootMaxCount` 来跟踪允许的尝试启动次数，然后重新启动设备。
2. **UEFI 更新**：重新启动时，系统会检查 `OsIndications`。如果存在，它将执行 capsule 更新，更新 EFI 系统资源表 (ESRT)，清除 `OsIndications`，如果设置了 `TrialBootMaxCount`，则允许 `TrialBootEnabled` 并再次重启系统。
3. **Trialboot 处理**：
- 如果未设置 `OsIndications`，系统将检查 `TrialBootEnabled` 是否处于活动状态。
- 如果 `TrialBootEnabled` 有效并且 `TrialBootCount` 等于 `TrialBootMaxCount`，则检查回滚计数。
- 如果允许回滚，UEFI 将恢复为固件、更新 ESRT，然后重新启动。
- 如果不允许回滚，则表明已达到回滚限制。
- 如果 `TrialBootCount` 小于 `TrialBootMaxCount`，则增加 `TrialBootCount` 并继续该过程。
4. **完成**: 系统启动到操作系统，检查 ESRT，如果操作系统成功启动，则会重置 `TrialBootEnabled` 字段。
5. **结果**：
- 如果 `TrialBootEnabled` 未激活，则确认 OTA 更新已完成。
- 系统清除 `OtaTrialBootStatus` 并将 `LwSupportedFwVersion` 设置为当前固件版本以禁用回滚。
6. **恢复**：如果固件封装更新在更新过程中失败，UEFI 具有恢复机制来保持稳定性和功能。
>
>
> 1. **回滚**：如果允许回滚，UEFI 将恢复到之前的固件版本。这涉及将固件恢复到尝试更新之前的状态。
> 2. **ESRT 更新**：更新 ESRT，以反映回滚情况。
> 3. **重启**：回滚完成后，UEFI 会触发重新启动，以确保其运行之前的稳定固件版本。
此过程可确保应用更新，并在设备试用期间遇到任何问题时允许回滚。
## 身份验证和签名
身份验证对于固件更新而言具有至关重要的意义，以确保安全性和稳定性。它保证仅应用来自可信来源的更新，从而防止恶意或未经授权的更新。通过验证 capsule 的数字签名，它可以确保更新在传输过程中未被篡改，并且仅安装经过验证和测试的更新。这降低了由于固件故障而导致系统崩溃或故障的风险。
要使用 [Tianocore GitHub -](https://github.com/quic/cbsp-boot-utilities/tree/main/uefi_capsule_generation#3-working-of-the-host-signing-tool) 中的说明验证基于 capsule 的系统固件更新，请执行以下步骤：
1. **生成签名密钥**：
- 使用 OpenSSL 命令行实用工具创建新的自签名 X.509 证书链。这涉及生成私钥和相应的公共证书。
- 私钥用于对固件更新 capsule 进行签名，而公共证书由 UEFI 固件用于验证签名。
2. **签署固件更新 capsule**：
- 使用签名密钥对固件更新 capsule 进行签名。这确保了 capsule 经过验证且未被篡改。
- 签名过程通常涉及创建固件更新有效负载的哈希值，然后使用私钥加密该哈希值以创建数字签名。
- 将这些证书放在名为 `Certificates’ 的文件夹中。此文件夹中可用的示例文件可能包括 `QcFMPCert.pem`、`QcFMPRoot.pub.pem` 和 `QcFMPSub.pub.pem`。
3. **验证 capsule**：
- UEFI 固件使用公共证书来验证 capsule 上的数字签名。如果签名有效并且与受信任的证书匹配，则固件更新过程将继续。
- 应在启动 DT 的 `/sw/uefi/uefiplat/QcCapsuleRootCert` 处提供 `QcFMPRoot.cer`（或 `NewRoot.cer`）。
此验证步骤可确保仅将授权的固件更新应用于系统。
Last Published: May 13, 2025
[Previous Topic
RTSS 冷启动流](https://docs.qualcomm.com/bundle/publicresource/80-70018-4SC/topics/RTSS_Cold_Boot_Flow.md) [Next Topic
基础版和高级版中的 capsule 更新和 trailboot 回滚功能](https://docs.qualcomm.com/bundle/publicresource/80-70018-4SC/topics/capsule-update-for-base-and-advance-variants.md)