# How to
## Trigger the capsule update
You need to consider two scenarios:
>
>
> - OsIndications enabled
>
> - When you enable OsIndications, the capsule update is triggered if a capsule is found in the EFI.
> - Additionally, you can enable the trialboot rollback feature based on the value of OsTrialBootStatus.
> - OsIndications disabled
>
> - When you disable OsIndications but enable OsTrialBootStatus, the capsule update isn’t triggered.
Note
>
>
> - Multiple capsules in ESP partition: If the ESP partition contains multiple capsules in EFI/UpdateCapsule, the system considers all capsules for the update and updates them alphabetically.
- UEFI non-volatile variables: The system stores all the UEFI non-volatile variables in the RPMB partition, which must be in a provisioned state. On a Qualcomm secure-boot-enabled device, the system automatically provisions the RPMB.
- Qualcomm non-secure devices: On Qualcomm non-secure devices, the system doesn’t automatically provision RPMB, but you can provision it using test keys. If you provision RPMB with test keys on a non-secure device, you can’t re-provision RPMB with a device key while enabling Qualcomm secure boot on the device.
For more details about how to trigger the capsule, see [OTA update](https://docs.qualcomm.com/doc/80-70030-27/topic/update_fw_and_os_qualcomm_linux_using_capsule_and_ostree_mechanisms.html).
## Authenticate and sign the capsule
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 system uses the private key to sign the firmware update capsules, and the UEFI firmware uses the public certificate to verify the signature.
2. **Sign the firmware update capsule**:
- Use the signing keys to sign the firmware
update capsule. This process authenticates the capsule and ensures it hasn’t been tampered with.
- The signing process 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.
- The boot Devicetree (DT) provides the root certificate—either `QcFMPRoot.cer` or `NewRoot.cer` at the following node: `/sw/uefi/uefiplat/QcCapsuleRootCert`.
- This boot DT is part of the `xbl_config.elf` binary and can be updated using the QDTE tool.
- Capsule update can only be performed if the root certificate is already present on the device, specifically within the boot DT node in xbl\_config.elf.
- Ensure the certificate is correctly embedded in the binary(xbl\_config.elf) and available on the device before initiating any capsule update process.
This verification step ensures the system applies only authorized firmware updates.
## Update the device firmware using a capsule
To update the device firmware through a capsule, do the following:
1. **Preparation**: Create a capsule containing the firmware update.
2. **Staging**: The system copies the capsule to the /EFI/UpdateCapsule/<capsule>.cap file in the EFI system partition (ESP), before OS triggers capsule update. Create a directory “UpdateCapsule” under /EFI directory if not available already.
3. **Reboot**: The OS triggers the capsule update and restarts the system to enter the UEFI environment.
4. **Update initiation**: The UEFI firmware detects the capsule and starts the update process.
5. **Verification**: The firmware checks the capsule integrity and authenticity.
6. **Installation**: The system updates the firmware using the capsule data.
7. **Completion**: The system reboots again to complete the update.
For advanced variants, the capsule updates only after the system sets `OsIndications` and the `OsTrialBootStatus` variable is present.
To generate a capsule, see [Generate the capsule](https://docs.qualcomm.com/doc/80-70030-4/topic/capsule-generation-in-uefi.html#capsule-generation-in-uefi).
## Configure QDTE
The QDTE graphical user interface (GUI) tool configures and modifies Devicetree Binary (DTB) files. For more information, see [Interfaces](https://docs.qualcomm.com/doc/80-70030-4/topic/interfaces.html#interfaces).
For more details about QDTE features, see [QDTE](https://docs.qualcomm.com/doc/80-70030-4/topic/qdte-tools.html#qdte-tools).
This section explains how to use QDTE tool to do the following:
>
>
> - Load, parse, edit and save the DTB file.
> - Read and write the DTB file from device or on the device.
> - Set up the configuration on your host PC, whether it’s Linux or Windows.
Set up the configuration on your host device as follows:
Table : Configuration for Linux/Windows
| Property | File path for Linux/Windows host PC |
| --- | --- |
| **SecTool path**: Installation path to SecToolsv2, a tool used to perform secure operations on software images. |
Linux: SECTOOLS=”META_PATH”/<chipset>.LE.X.x/common/sectoolsv2/ext/Linux/sectools
Windows: SECTOOLS=”META_PATH”\<chipset>.LE.X.x\common\sectoolsv2\ext\windows\sectools.
For more information about SecToolsv2 for Windows, see SecTools V2: Metabuild Secure Image User Guide
|
| **Profile file**: Used for signing the security profile XML files. | |
| **Sign cmd json**: Used for signing the JSON file from the QDTE installation directory. The test signing mode is used for working on a nonsecure device. For secure devices, see [enable secure boot](https://docs.qualcomm.com/doc/80-70030-11/topic/enable-secure-boot.html). | |
| **Devprg file**: Device programmer file. |
Linux: "META_PATH”/<chipset>.LE.X.x/BOOT.MXF.1.0.c1-00134-KODIAKLA-2/boot_images/boot/QcomPkg/SocPkg/Kodiak/Bin/LAA/DEBUG/prog_firehose_ddr.elf
Windows: "META_PATH”\<chipset>.LE.X.x\BOOT.MXF.1.0.c1\boot_images\boot\QcomPkg\SocPkg\Kodiak\Bin\LAA\DEBUG\prog_firehose_ddr.elf
|
| **Flash type**: Type of storage, which in this case is UFS. | – |

**Figure : Settings for Linux signature configuration**

**Figure : Settings for Windows signature configuration**
Use the following procedure to configure the DTB files using QDTE. This
procedure is applicable only to XBL and UEFI DTB.
1. To open the XBLConfig ELF file, go to File > Open DTB Elf > From Build.
- If the file is invalid or corrupted, the system generates an error. To prevent the error, ensure that you download the valid boot binaries, including `xbl_config.elf`, and use them with the XBL configuration. The binary includes the boot component, which is part of the firmware.
- If the file loads successfully, a tree view appears, populated
with the DTB elements.
2. Select the XBLConfig ELF file to edit it.
The primary QDTE interface displays the file.
The figure shows an XBLConfig helper window displaying the disassembled results of an XBLConfig file containing two DTBs.
>
>
> 
The figure shows an example file opened in a tree view with all four
columns populated.
>
>
> 
3. To discard all the changes and reload the file from the disk (if the file undergoes changes on the disk while the QDTE tool is open),
select File > Reload File.
4. To add items to the tree, right-click on a node. The following items
are displayed:
Table : DT items
| Tree item | Description |
| --- | --- |
| Add New Child | Adds a child in the tree. |
| Node | Asks for the name of the new node and adds it. If the node name is invalid, an error occurs. |
| Property of Type | Opens a menu that allows you to choose the type of property to add.
Adding a property displays the Edit dialog box corresponding to the type of the new property.
On confirmation, a new property of the specified type is added. |
You can remove all items in the DT, except for the root node. To delete an item, right-click on it and select Delete. Deleting a node also removes its child nodes, if any.
5. To edit a property, you can either right-click and select Edit or double-click to open a dialog box. This dialog box allows you to
edit both the property name and value.
6. To view the DTB file as a binary hexadecimal dump, go to View > Raw, which displays the exported DTB file.
The following example of the raw view shows the offset, hexadecimal
value, and corresponding character columns, with a node highlighted
in orange.
>
>
> 
To remove all highlights, go to View > Clear Highlights.
7. To save the modified DTBs, you can either go to File > Save (or press **CTRL + S**) to overwrite the existing file or go to
File > Save Copy As (or press **CTRL + SHIFT + S**) to save
a copy of the DTB to a new file.
8. To generate a summary of the changes, select File > Export Change Report.
A JSON file is created, which lists all changes made to the DT in the
session, along with the result of the DTB after the operation.
9. To save the modified DTB files within the main QDTE, go to the
XBLConfig helper window, and select Reassemble and Sign. The modified file is saved.
10. Next, choose a name for the output file.
The toolchain re-assembles the ELF using XBLConfig. If an error message indicates that a signed XBLConfig wasn’t generated, it downgrades the error to a warning and shows a success message instead.

Last Published: Jul 20, 2026
[Previous Topic
Detection of RAM dump](https://docs.qualcomm.com/bundle/publicresource/80-70030-4/topics/ram-dump-detection.md) [Next Topic
References](https://docs.qualcomm.com/bundle/publicresource/80-70030-4/topics/references.md)