> 7:0 - Version - Version number of OsTrialBootStatus
> 11:8 - TrialBootMaxCount - This is set by the OS before triggering the capsule update.
> 15:12 - TrialBootCount - This is set/incremented by UEFI (if TrialBootEnabled isn’t cleared by OS). The OS can set to TrialBootMaxCount, if the OS wants to trigger a firmware rollback.
> 16 - TrialBootEnabled - This is set to 1 by UEFI after capsule update and cleared by the OS after successful OTA update.
> 31:17 - Unused
>
|
| EFI system resource table (ESRT) | The ESRT table is set by the UEFI after the capsule update. |
For more information about the OsIndications and OsIndicationsSupported variables, see
[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
- If there is more than one capsule in the ESP partition (in EFI/UpdateCapsule), consider all the capsules for the update and update them alphabetically.
- Store all UEFI non-volatile variables in the rollback protection memory block (RPMB) partition, which must be in a Provisioned state.
>
>
> - Autoprovision the RPMB on Qualcomm secure-boot enabled devices.
> - On Qualcomm non-secure devices, don’t autoprovision the RPMB; instead, provision it with test keys.
> - If you provision the RPMB with test keys on non-secure devices, you can’t re-provision it with a device key when enabling Qualcomm secure boot on the device.
> - Use the `rpmbClient` application for RPMB provisioning from Linux. For more information, see [Qualcomm Security Linux Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11/bring-up.html#verify-trustzone/device-configuration/hypervisor-image-loading).
## EFI system resource table for capsule update status from HLOS
>
>
> The EFI System Resource Table (ESRT) is an optional mechanism for identifying the device and the system firmware resources to target firmware updates. Each ESRT entry describes a firmware resource that can be updated and reports the status of the last attempted update.
> The entries in ESRT, which are used to report status of the last attempted update are:
Table: ESRT entries
| **ESRT field** | **Description** |
| --- | --- |
| FwClass | The firmware class field contains a GUID that identifies a firmware component that can be updated through *UpdateCapsule().* |
| FwType | Identifies the type of firmware resource. |
| FwVersion | The firmware version field represents the current version of the firmware resource. The value must always increase as a larger number represents a newer version. |
| LowestSupportedFwVersion | The lowest firmware resource version to which a firmware resource can be rolled back for the specified system/device. |
| CapsuleFlags | The capsule flag field contains the *CapsuleGuid* flags (bits 0- 15) as defined in the *EFI\_CAPSULE\_HEADER* that’s set in the capsule header. |
| LastAttemptVersion | The field describes the last firmware version for which an update was attempted (uses the same format as the firmware version). |
| LastAttemptStatus | The field describes the result of the last firmware update attempt for the firmware resource entry. |
The ESRT content is exposed by the OS from the sysfs path.
/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 table is set by UEFI after the capsule update. X is the firmware version before the capsule update. Y is the version of the firmware, which is available in the capsule [.cap] file.
| **Last attempted firmware version** | **Current firmware version** | **last\_attempt satus** | **Capsule update scenario** |
| --- | --- | --- | --- |
| Y | Y | 0 | Update success |
| Y | X | 1 | Capsule update failure |
| 0 | X | 0 | Capsule meta-data failure |
| Y | X | 0 | Firmware rollback done |
For more information about ESRT, see [Firmware Update and Reporting - UEFI Specification 2.10 documentation](https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html#efi-system-resource-table)
The flowchart explains how the device firmware is updated using the UEFI capsule solution/method using different UEFI variables along with the rollback support.
1. **Initiation**: The over the air (OTA) update process starts, and the OS prepares
to update the capsule, signaling the UEFI (through setting
`OsIndications`) to begin the update. The OS sets a
`TrialBootMaxCount` to track the number of trial boots allowed and
then reboots the device.
2. **UEFI update**: Upon reboot, the system checks for
`OsIndications`. If present, it performs the capsule update,
updates the EFI system resource table (ESRT), clears `OsIndications`, and if
`TrialBootMaxCount` is set, allows `TrialBootEnabled` and
restarts the system again.
3. **Trialboot handling**:
- If the `OsIndications` aren’t set, the system checks if the
`TrialBootEnabled` is active.
- If the `TrialBootEnabled` is active and the `TrialBootCount`
equals the `TrialBootMaxCount`, it checks the rollback count.
- If a rollback is allowed, the UEFI reverts to the firmware, updates the ESRT, and reboots.
- If a rollback isn’t allowed, it indicates that the rollback limit is reached.
- If the `TrialBootCount` is less than the `TrialBootMaxCount`, it
increments the `TrialBootCount` and continues the process.
4. **Completion**: The system boots to the OS, checks the ESRT, and if
the OS boots successfully, it resets the `TrialBootEnabled` field.
5. **Result**:
- If `TrialBootEnabled` isn’t active, the OTA update is confirmed
as complete.
- The system clears the `OtaTrialBootStatus` and sets the
`LwSupportedFwVersion` to the current firmware version to
disable rollback.
6. **Recovery**:
If a firmware capsule update fails during the update process, UEFI has a
recovery mechanism to maintain the stability and functionality.
>
>
> 1. **Rollback**: If a rollback is allowed, UEFI reverts to the previous firmware version. This involves restoring the firmware to the state before the update attempt.
> 2. **ESRT update**: The ESRT is updated to reflect the rollback.
> 3. **Reboot**: After the rollback is complete, the UEFI triggers a restart to ensure it’s running the previous, stable firmware version.
This process ensures that the update is applied and allows for rollback if any issues are encountered during the trial period.
## Authentication and signing
Authentication is essential for firmware updates to ensure security and
stability. It guarantees that only updates from trusted sources are
applied, preventing malicious or unauthorized updates. By verifying the
digital signature of the capsule, it ensures the update hasn’t been
tampered with during transmission and that only verified and tested
updates are installed. This reduces the risk of system crashes or
malfunctions due to faulty firmware.
To authenticate capsule-based system firmware updates using the
instructions from the [Tianocore GitHub -](https://github.com/quic/cbsp-boot-utilities/tree/main/uefi_capsule_generation#3-working-of-the-host-signing-tool) , follow these steps:
1. **Generate signing keys**:
- Use OpenSSL command line utilities to create a new self-signed
X.509 certificate chain. This involves generating a private key
and a corresponding public certificate.
- The private key is used to sign the firmware update capsules,
while the public certificate is used by the UEFI firmware to
verify the signature.
2. **Sign the firmware update capsule**:
- Use the signing keys to sign the firmware
update capsule. This ensures that the capsule is authenticated and
hasn’t been tampered with.
- The signing process typically involves creating a hash of the
firmware update payload and then encrypting this hash with the
private key to create a digital signature.
- Place these certificates in a folder named `Certificates’. Sample
files available in this folder might include `QcFMPCert.pem`,
`QcFMPRoot.pub.pem`, and `QcFMPSub.pub.pem`.
3. **Verify the capsule**:
- The UEFI firmware uses the public certificate to verify the
digital signature on the capsule. If the signature is valid and
matches the trusted certificate, the firmware update process will
proceed.
- `QcFMPRoot.cer` (or `NewRoot.cer`) should be provided in
the boot DT at `/sw/uefi/uefiplat/QcCapsuleRootCert`.
This verification step ensures that only authorized firmware updates are applied to the system.
Last Published: Apr 30, 2025
[Previous Topic
RTSS cold boot flow](https://docs.qualcomm.com/bundle/publicresource/80-70018-4/topics/Sail.md) [Next Topic
Capsule update and trailboot rollback feature in base and advance variants](https://docs.qualcomm.com/bundle/publicresource/80-70018-4/topics/capsule-update-for-base-and-advance-variants.md)