The Boot Chain: PBL to User Space

Advanced12 min read

Assumes: 0.3 Memory & Boot Media, 5.1 Platform Overview

TL;DR

Every power-on on a Qualcomm cockpit SoC follows a chain of boot stages, each authenticating the next before execution. PBL (Primary Boot Loader, in ROM) is the immutable root. It loads XBL (eXtensible Boot Loader), which brings up AOP, TZ (TrustZone), and QHEE (the hypervisor). ABL (Android Boot Loader / UEFI) then loads guest OS kernels: QNX IFS and AAOS boot.img. Break any link in the chain (bad signature, corrupt partition) and the device refuses to boot, what engineers call bricking. EDL (Emergency Download) mode drops to PBL-level access so QFIL can recover a dead unit by talking below the broken stage.

You flash dozens of images (XBL, ABL, boot, vendor, QNX IFS) but rarely see the order they execute. That order is the boot chain. It’s why some corruption is recoverable and some isn’t. Spoiler: it involves more handshakes than a diplomatic summit.

Chain of Trust: The Core Idea

Qualcomm platforms implement a Chain of Trust (CoT):

1. Root of trust: code in ROM (PBL) that cannot be modified
2. Each stage cryptographically verifies the next stage before jumping to it
3. Only signed images from trusted keys execute
4. Compromise at any stage stops the chain (fail-closed, not fail-open)

Every handoff is inspected, like airport security between connecting flights.

Mental Model

Boot is a relay race with ID checks. PBL is the starter in the blocks — always there, never swapped. Each runner (XBL → TZ → QHEE → ABL → kernel) must show a valid badge (signature) before the next runner leaves the blocks. A forged badge? The race stops. EDL mode is the race official who can reset runners when everyone is stuck at the starting line.

Mnemonic: E-F-R-N-C — EDL recovery, Fail-closed chain, ROM root (PBL), Next stage verified, Chain of trust. Boot stages: Please eXcuse Bad Attitudes — PBL → XBL → (TZ/QHEE) → ABL.

Think About It

PBL takes 200ms to hand off to XBL. XBL takes 3 seconds. Where would you focus to improve boot time?

Reveal Answer

Focus on XBL — it owns DDR training, clock/power init, UFS reads, and loading TZ, QHEE, and early firmware; the PBL→XBL ROM handoff is already bounded and not tunable. On bench, timestamp serial logs from power-on through XBL → QHEE → ABL to see whether time sits in memory training, partition reads, or waiting on PMIC rails. Defer non-critical ADSP/CDSP loads until after first frame, and trim XBL config bloat before touching guest boot.img or QNX IFS.

Stage by Stage

PBL — Primary Boot Loader (ROM)

Property	Detail
Location	On-chip ROM, burned at manufacturing
Mutability	None: the true root of trust
Job	Minimal hardware init; locate and verify XBL in flash (UFS/eMMC)
Failure mode	If XBL is missing or unsigned → device halts or enters EDL

PBL knows nothing about QNX, Android, or your app. It only knows: find valid XBL, jump to it.

PBL is permanent because it lives in ROM.

XBL — eXtensible Boot Loader

Property	Detail
Location	Flash partition (e.g., xbl, xbl_config)
Job	DDR training, clock/power init, load AOP, TZ, QHEE
Your flash tool	QFIL / QPST firehose programmer writes here

XBL is the first flashable stage. Corrupt XBL → device won’t reach TZ or hypervisor. Still recoverable via EDL because PBL can receive a fresh XBL over USB.

AOP — Always-On Processor

Tiny always-on core for low-level power management, sleep/wake, and sensor hub duties. Boots early from XBL. Not your QNX/AAOS world, but AOP crashes can cause mysterious wake failures.

TZ — TrustZone (Secure World)

Property	Detail
ARM level	EL3 (Monitor) / secure world
Job	Key storage, crypto, secure boot enforcement, DRM, eFuse access
Images	tz, devcfg, keymaster region

TrustZone owns secrets. Hypervisor and guest OSes request crypto services through secure monitor calls (SMC). They don’t touch keys directly.

QHEE — Qualcomm Hypervisor Execution Environment

Property	Detail
ARM level	EL2
Job	Type-1 hypervisor: creates VMs, assigns vCPUs, partitions memory and I/O
Images	QHEE firmware partition (vendor-specific naming)

QHEE must be running before QNX or AAOS kernels start. It is the landlord; guest OSes are tenants (Page 5.3).

ABL — Android Boot Loader (UEFI)

Property	Detail
Location	abl partition
Job	UEFI-style loader: picks and verifies guest boot images
Loads	QNX IFS, AAOS boot.img, optionally other VM payloads

Despite the name “Android Boot Loader,” ABL loads all guest kernels configured in the boot flow, not just Android.

Guest OS Kernels — User Space Entry

Guest	Typical Image	What Happens Next
QNX	IFS (Image Filesystem)	QNX microkernel + drivers + hypervisor host services start
AAOS	boot.img + vendor/system	Linux kernel → init → Zygote → Android framework
Linux (optional)	Vendor-specific	Secondary VM for ADAS, logging, etc.

Each guest kernel is verified before execution. Then init systems bring up user space, where your adb shell, VHAL, and QNX services live.

Full Boot Chain Diagram

flowchart TB
    POWER["Power-On / Reset"]
    PBL["PBL<br/>Primary Boot Loader<br/>(ROM — Root of Trust)"]
    XBL["XBL<br/>eXtensible Boot Loader<br/>(DDR · clocks · flash init)"]
    AOP["AOP<br/>Always-On Processor"]
    TZ["TZ — TrustZone<br/>(EL3 Secure World)"]
    QHEE["QHEE<br/>Hypervisor (EL2)"]
    ABL["ABL<br/>Android Boot Loader / UEFI"]
    QNX["QNX IFS<br/>Guest VM — EL1"]
    AAOS["AAOS boot.img<br/>Guest VM — EL1"]
    USERSPACE["User Space<br/>Services · Apps · VHAL"]

    POWER --> PBL
    PBL -->|"verify signature"| XBL
    XBL --> AOP
    XBL --> TZ
    XBL --> QHEE
    QHEE --> ABL
    ABL -->|"verify + load"| QNX
    ABL -->|"verify + load"| AAOS
    QNX --> USERSPACE
    AAOS --> USERSPACE

    EDL["EDL Mode<br/>(Emergency Download)"]
    QFIL["QFIL / Firehose<br/>USB programmer"]
    EDL -.->|"bypass broken chain"| PBL
    QFIL -.-> EDL

Common Gotcha

If you flash only boot.img while XBL, TZ, or QHEE is corrupt or mismatched to the chip, the device stays dead — no kernel will run regardless of a perfect Android build. Always verify foundational partitions before debugging guest OS issues. Symptom: instant EDL or black screen with no fastboot. Think low-level boot, not logcat.

What “Bricking” Actually Means

Bricking is informal. It covers a spectrum:

Severity	What Broke	Recovery
Soft brick	Guest OS (system, QNX IFS) corrupt	Reflash from fastboot/QFIL in normal or EDL mode
Medium brick	ABL or single guest boot image bad	EDL + QFIL with correct programmer
Hard brick	XBL, TZ, or partition table destroyed	EDL + firehose, if PBL/USB still responds
True brick	Hardware fault, blown eFuse, dead USB	JTAG/SDI service tools or RMA

Damage lower layers, need lower tools to fix. QFIL in EDL reaches the bottom layer (PBL).

Bricking is not “the app crashes.” It’s “the SoC refuses to execute the next boot stage.”

EDL Mode: The Escape Hatch

EDL (Emergency Download Mode), also called Qualcomm HS-USB QDLoader 9008 in Device Manager, is a PBL-level USB protocol.

Mode	Who You Talk To	Typical Tool
Normal boot	Running OS (ADB, SSH)	adb, QNX shell
Fastboot	ABL (if reached)	fastboot flash
EDL	PBL via firehose	QFIL, QPST

In EDL:

1. PBL accepts a firehose programmer over USB
2. Programmer can read/write raw partitions on UFS
3. You restore XBL, partition table, full flat build without a working OS

Where You'll See This

This is why QFIL works in EDL mode: it talks to PBL directly.

When a bench unit shows QDLoader 9008 and nothing else:

• Normal flashing tools that expect ADB or fastboot won’t help
• QFIL sends a signed firehose programmer that PBL trusts
• The programmer then writes every partition (XBL through super) as raw bytes

Your daily workflow:

1. Force EDL: test point, adb reboot edl, or power sequence (platform-specific)
2. Load programmer: must match chip (SA8155P vs SA8295P firehose)
3. Flash flat build or individual partitions
4. First boot: watch serial log from PBL through XBL for auth failures

If auth fails after flash, suspect wrong signature keys (dev vs prod) or mismatched TZ/devcfg, not a bad Android app.

Boot Stages vs Partition Names You'll Flash

Build artifacts don’t always match stage names 1:1. A single QFIL session might write: xbl, xbl_config, aop, tz, hyp (QHEE), abl, boot, vendor, system, qnx_ifs, adsp, cdsp, modem (AMSS). Module 8 maps each partition to its boot stage. Rule of thumb: partitions listed before boot in the flash XML are chain-of-trust stages. Get those right first.

Connect the Dots

Page 5.1 identified your silicon. This page explains how it wakes up. Page 5.3 covers QHEE, the stage that creates VMs before ABL loads QNX and AAOS. Page 5.4 shows which OS runs where after boot completes. Page 5.6 (BSP) explains the device tree and config that each stage loads. Module 8 is the partition flash map for every stage named here. Page 10.2 (Boot Modes) maps each boot stage to a debug mode — EDL at PBL, fastboot at XBL, recovery at ABL. Page 10.3 (Debug Interfaces) covers JTAG and SDI, which are available when boot halts before UART output.

• Module 0.4 (Power Architecture): The boot chain can’t start until PMIC power sequencing completes. PBL waits for VDD_CX to stabilize before executing.

What matters

1. Boot is a chain of trust: PBL (ROM) → XBL → AOP/TZ/QHEE → ABL → guest kernels.
2. Each stage verifies signatures on the next. Unsigned or corrupt images halt boot.
3. Bricking means the chain breaks. Severity depends on how low the damage goes.
4. EDL mode lets QFIL talk to PBL directly, the recovery path when everything above ROM is broken.

Check Your Understanding

1. Why can QFIL recover a device in EDL mode when fastboot and ADB cannot?

Applied

A. EDL talks to PBL in ROM below broken stages via the firehose programmerB. EDL launches the Android recovery partition with elevated root accessC. EDL only works when the QNX IFS partition is corrupt or missing on UFSD. EDL bypasses all signature checks and permanently disables secure boot

2. In the boot chain, which stage is responsible for creating virtual machines before guest OS kernels start?

Recall

A. PBL — Primary Boot Loader in ROMB. ABL — Android Boot LoaderC. AAOS boot.img — Linux kernelD. QHEE — Qualcomm Hypervisor Execution Environment at EL2

3. A device has a corrupt system.img but intact XBL, TZ, QHEE, and ABL. This is best described as:

Applied

A. A true hardware brick requiring RMA to the silicon vendor for reworkB. A PBL ROM failure that is only fixable in the factory with JTAG accessC. An AMSS modem-only crash that is completely unrelated to the AP boot pathD. A soft brick — guest OS damage recoverable by reflashing without using EDL

4. What is the immutable root of trust in the Qualcomm cockpit boot chain?

Recall

A. PBL — Primary Boot Loader in on-chip ROMB. QNX IFS on UFSC. XBL in the xbl flash partitionD. ABL — Android Boot Loader in the abl partition

5. After power-on, PMIC sequencing completes but the serial log stops immediately with no XBL output. Which boot stage should you investigate first?

Applied

A. AMSS MPSS image — modem firmware crashed before reaching the ready stateB. PBL → XBL handoff — PBL could not find or verify a valid XBL image in flashC. AAOS Zygote process — the Android app framework failed to start in the VMD. VHAL gRPC service — the inter-VM IPC channel is not ready on vsock port

6. A bench unit shows QDLoader 9008 after a bad flash. You need to restore XBL, TZ, hyp (QHEE), and ABL before guest images. Which recovery workflow applies?

Synthesis

Connects to: Module 8 — Build, Flash & Update

A. QPST QXDM modem trace capture to diagnose the XBL authentication failureB. EDL + QFIL with matching firehose programmer and rawprogram XML for CoTC. fastboot flash boot only — guest kernel fixes lower stages automaticallyD. adb reboot recovery and sideload system.zip from the host PC USB port

Further Reading

• UEFI Specification — The UEFI standard that ABL (Android Boot Loader) implements for loading guest OS kernels, device tree blobs, and boot configuration on Qualcomm platforms.
• Trusted Firmware-A Documentation — ARM reference secure-world firmware at EL3, covering Trusted Board Boot concepts that parallel Qualcomm’s TrustZone (TZ) stage in the chain of trust.
• Trusted Firmware Project — Open-source secure software foundation for Armv8-A/v9-A platforms, providing context for the secure monitor and chain-of-trust principles behind PBL → XBL → TZ boot stages.
• ARM Trusted Board Boot Requirements (TBBR) — ARM’s specification for authenticated boot chains that define how each stage verifies the next before execution — the architectural basis for Qualcomm secure boot.
• Qualcomm Developer Blog — Secure Boot and Virtualization — Qualcomm engineering articles on secure boot, hypervisor integration, and platform security relevant to the XBL → QHEE → ABL sequence.
• Android Boot Image Format — AOSP documentation for boot.img structure that ABL loads after hypervisor initialization, covering kernel, ramdisk, and device tree components.
• ARM Architecture Reference Manual for A-profile — Exception Levels — ARM documentation for the EL0–EL3 privilege model that maps directly to the PBL (ROM) → TZ (EL3) → QHEE (EL2) → kernel (EL1) stack described on this page.