# Architecture The boot architecture includes boot loaders and board support packages (BSP) images that are used at each stage of boot. The boot loaders are involved at different stages of the boot process until the Linux kernel and applications are enabled. ## Boot loader The boot loader software runs when the system is powered on and serves as an interface for loading the operating system and other required applications. Qualcomm chipsets, including the ones supported by Qualcomm Linux, use a multistage boot process as follows:  ### Primary boot loader (PBL) - Establishes a secure root-of-trust (RoT) and secure boot process for applications. For more information, see [Secure boot](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11/secure-boot.html). - Identifies the primary storage device and loads the secondary boot loader called the eXtensible boot loader (XBL). If any recoverable error occurs while loading the XBL image, the PBL enters the emergency download (EDL) mode. For more information on how EDL mode is detected, see [Enumeration of EDL device manager](https://docs.qualcomm.com/doc/80-70017-4/topic/examples.html#edl-device-manager-enumeration). - Loads XBL segments into the boot SoC internal memory. For more information on how PBL loads the XBL segments, see [Cold boot architecture](https://docs.qualcomm.com/doc/80-70017-4/topic/architecture.html#cold-boot-architecture). ### eXtensible Boot Loader (XBL) - Initializes the hardware, firmware images, CPU cache, MMU, boot device, PMIC, and DDR. - Sets up the RAM dump USB driver, USB charging, thermal check, power management integrated circuit ([PMIC](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-4/pmic-developer-touchpoints.html)), and low-power double data rate (LPDDR) clock functions. - Collects the RAM dump over USB to the host PC. - Loads and verifies the Qualcomm^®^ Trusted Execution Environment (Qualcomm TEE), Qualcomm Hypervisor, and UEFI image. - Provides the XBL configuration (XBL\_CFG), which is part of the cold boot flow and includes PMIC and other driver settings. - Provides XBL with a Qualcomm-signed ELF segment to initialize the external protection units (xPU). - XBL\_CFG is a standalone binary with platform-specific configurations and settings. The XBL uses the XBL\_CFG driver to load and configure the required settings. The driver uses the binary to provide on-demand read access to each setting of XBL\_CFG. ### Unified Extensible Firmware Interface (UEFI) UEFI is the software interface between an operating system (OS) and the platform firmware. It includes data tables with platform information, along with the boot and runtime service calls that the OS and its loader can use. Together, they create a standard environment for booting an operating system and running UEFI applications. Qualcomm uses TianocoreEDK2, an open-source implementation available at [http://www.tianocore.org/edk2/](https://github.com/tianocore/tianocore.github.io/wiki/EDK-II/) which follows the [UEFI specification](https://uefi.org/specs/UEFI/2.10/). There are two build options, which are: - Retail build: Has minimal debug features and an optimal memory footprint, making it ideal for production environments. - Debug build: Ideal for development environments, with all debug features enabled. For developing a UEFI application, see [Unified Extensible Firmware Interface (UEFI)](https://docs.qualcomm.com/doc/80-70017-4/topic/uefi-develop.html#uefi-develop). ### systemd-boot OS manager systemd-boot is a UEFI boot manager which executes configured EFI images. It supports systems with UEFI firmware exclusively and does the following: - Loads boot entry information from the EFI system partition (ESP), typically mounted at `/efi`, `/boot`, or `/boot/efi` during the Linux OS runtime and from the extended boot loader partition (XBOOTLDR) (mounted to `/boot`). The configuration file fragments, kernels, initial RAM disk (initrd), and other EFI images must be located within the ESP or XBOOTLDR. - Reads simple and generic boot loader configuration files, and selects one file per boot loader entry. All the files are in the ESP partition. To ensure that the Qualcomm Linux kernel can be directly run as an EFI image, use the `CONFIG_EFI_STUB` compilation option. For more information on: - EFI boot stub, see [https://docs.kernel.org/admin-guide/efi-stub.html](https://docs.kernel.org/admin-guide/efi-stub.html). - A sample structure of the EFI partition, see [Systemd-boot in Qualcomm Linux Yocto Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-27/platform_software_features.html#systemd-boot). ## Cold boot architecture A cold boot starts the system from a power-off state. This process begins with the PBL. The following figure shows the cold boot flow:  **Figure : Cold boot flow** The cold boot process operates in two security modes: Secure and Nonsecure. At the EL0, EL1, and EL2 [exception levels](https://developer.arm.com/documentation/102412/0103/Privilege-and-Exception-levels/Exception-levels), the boot core can operate in either Secure or Nonsecure mode, however at the EL3 it always operates in Secure mode. For more information on the security modes, see [Software Security Architecture](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11/architecture.html). The Linux kernel runs in the Nonsecure EL1 state. After the security settings are completed in the secure EL3 state, the XBL may switch to the UEFI nonsecure EL1 state. The cold boot sequence involves the following steps: 1. After a reset, the boot core exits the Reset state and executes the PBL. The PBL initializes the hardware clocks, CPU caches, memory management unit (MMU), and identifies the boot device based on the boot option settings. 2. The PBL loads and authenticates the XBL from the boot device. The XBL runs the security setup in EL3 Secure state and performs the following tasks: 1. Initializes the hardware, firmware images, CPU cache, MMU, boot device, PMIC, and DDR. 2. Loads and authenticates the Qualcomm TEE image from the boot device. 3. Loads and authenticates the Qualcomm Hypervisor image. 4. Loads and authenticates the UEFI image. 5. Makes a secure channel manager (SCM) call to jump to the Qualcomm TEE image. SCM is the driver that communicates with Qualcomm TEE using a [secure monitor call](https://developer.arm.com/documentation/ddi0333/latest/programmer-s-model/exceptions/secure-monitor-call--smc-) (SMC). 3. The Qualcomm TEE sets up the secure environment and runs the Qualcomm Hypervisor image. 4. The Qualcomm Hypervisor hands over control to UEFI, which then loads and authenticates the systemd-boot EFI image using the [UEFI secure boot](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11/enable-uefi-secure-boot.html). 5. The systemd-boot image loads and authenticates the Qualcomm Linux kernel image, and then passes control to the Qualcomm Linux kernel. If kernel-based virtual machine (KVM) mode is enabled, UEFI will shutdown Qualcomm Hypervisor and exit the UEFI boot services; it then passes off the control to Linux KVM in EL2. 6. The Qualcomm Linux kernel launches the Linux application such as the bash shell. ## Update and recovery The firmware on a device is updated using a capsule, through the UEFI. This process involves encapsulating the firmware update payload in a capsule [.cap file], which is then processed by the system firmware to update the device’s firmware. Note The mentioned capsule update is applicable to Qualcomm Linux advanced/custom variant only. To generate a capsule, see [Capsule generation in UEFI](https://docs.qualcomm.com/doc/80-70017-4/topic/tools.html#capsule-generation-in-uefi). ### Update device firmware Updating device firmware involves installing new software onto a device’s firmware, which is the low-level software that controls the hardware. This process can improve the device’s performance, fix bugs, add new features, or enhance security. To update the device firmware through a capsule, do the following: 1. **Preparation**: The OS creates a capsule containing the firmware update. 2. **Staging**: This capsule is accessible in the EFI system partition (ESP). [/EFI/UpdateCapsule/<capsule>.cap], before the OS loads. 3. **Reboot**: The OS will trigger the capsule update and reboot 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’s integrity and authenticity. 6. **Installation**: The firmware is updated using the capsule’s data. 7. **Completion**: The system reboots again to complete the update. In this process, the firmware update payload is encapsulated in a.cap file. This capsule (.cap) file is then processed to ensure secure and reliable firmware updates. ### **UEFI variables involved in capsule update** Communication between the OS and UEFI uses protocols and services to interact with platform firmware. UEFI offers a standard boot environment, data tables with platform information, and boot/runtime service calls for the OS loader and OS. The UEFI variables for capsule updates include: | Variable name | Description | | --- | --- | | OsIndications | This variable is owned by the OS and is used to indicate the features the OS wants the firmware to enable or the OS wants the firmware to take. This variable is set by OS and cleared by UEFI. | | OsIndicationsSupported | This variable is owned by the firmware and indicates which of the OS indication features and actions the firmware supports. | | OsTrialBootStatus |
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 is not 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