Understanding various firmware Boot Process

When a computer or smartphone is powered on, the operating system is not immediately available. The processor must begin executing code, initialize enough hardware to access additional software, establish a chain of trust, locate an operating system, and transfer control to it.

This process is called booting. Although the underlying objective is similar across devices, the implementation differs considerably between desktop computers, Android smartphones, Apple devices, embedded systems, and other platforms.

A modern PC might use UEFI firmware and Windows Boot Manager. An Android smartphone might start with an immutable Boot ROM, continue through several vendor-specific bootloaders, verify Android partitions using Android Verified Boot, and eventually launch the Android runtime. An Apple silicon Mac uses Apple's own boot architecture, including Boot ROM, Low-Level Bootloader (LLB), and iBoot. Embedded devices may use U-Boot, Trusted Firmware-A, EDK II, or a combination of these components.

Understanding these differences requires separating several concepts that are frequently treated as interchangeable: firmware, bootloader, UEFI, Secure Boot, Verified Boot, and the operating system's initialization process.

1. The Fundamental Concepts

1.1 Firmware

Firmware is software associated with a hardware device. It initializes hardware, configures platform-specific functionality, and provides the low-level services needed by later software.

Examples include motherboard firmware, smartphone boot firmware, storage-controller firmware, embedded-controller firmware, and firmware running inside a system-on-chip (SoC).

Firmware is not necessarily stored in ROM. It may reside in mask ROM, electrically programmable memory, SPI flash, eMMC, UFS, or other non-volatile storage. Some firmware is loaded into RAM before execution.

1.2 Bootloader

A bootloader is a program that locates, prepares, verifies where required, and loads another software component. The component it loads might be another bootloader, a firmware environment, a hypervisor, a recovery environment, or an operating-system kernel.

Bootloaders are often divided into multiple stages because the earliest code has very limited resources. For example, the first stage may execute from a small internal SRAM region before external DRAM has been initialized.

1.3 Boot ROM

Boot ROM is code stored in read-only memory associated with the processor or SoC. When the processor starts, its reset logic directs execution to a platform-defined entry point, which may lead into this immutable code.

On platforms that use Boot ROM as the hardware root of trust, the ROM contains or references trusted public keys and verifies the next boot stage before transferring execution to it.

However, Boot ROM does not mean exactly the same thing on every platform. Some systems begin in other immutable or hardware-controlled execution environments. The important question is which component executes first and how the integrity of subsequent components is established.

1.4 UEFI

The Unified Extensible Firmware Interface (UEFI) is a firmware interface specification. It defines interfaces and services through which platform firmware can discover devices, access storage, load EFI applications, and transfer control to an operating system.

UEFI is not itself an operating system, a universal bootloader, or a synonym for Secure Boot. A UEFI implementation may support Secure Boot, but the security policy depends on the platform configuration and implementation.

UEFI also does not describe every stage that executes before its own environment becomes available. Platform Initialization (PI) specifications describe additional architectural concepts for implementing firmware initialization.

Official references:

1.5 Secure Boot and Verified Boot

These terms describe related security objectives, but they are not interchangeable.

Secure Boot generally refers to a mechanism that prevents unauthorized executable components from being loaded according to a defined trust policy. UEFI Secure Boot is a well-known example.

Verified Boot refers to a process in which software components or system data are cryptographically checked against trusted metadata before execution or use. Android Verified Boot is a prominent example.

Some platforms combine both approaches. Others use a custom secure boot chain without UEFI. The exact names and verification boundaries vary.

1.6 A Typical High-Level Boot Sequence

Power-on or reset

↓

Initial processor execution
Reset vector, Boot ROM, or platform-specific entry point

↓

Early hardware initialization
Clocks, memory, security hardware, and boot-device access

↓

Subsequent firmware or bootloader stages

↓

Operating-system selection and verification

↓

Kernel and initial userspace loading

↓

Operating-system services and applications

This diagram is conceptual. Not every platform has a distinct component at every level, and some components perform multiple functions. The exact sequence depends on the processor architecture, firmware implementation, and security design.

2. What Happens When a Processor Starts?

A processor cannot simply execute an operating system stored somewhere on a disk without first establishing an execution environment.

After power-on or reset, the hardware places the processor into a defined initial state. Depending on the architecture, it begins execution at a reset vector or another implementation-defined entry point.

The earliest code has to work within severe limitations. External RAM may not be initialized, storage controllers may not be ready, and ordinary operating-system services do not exist yet.

Early firmware may therefore need to perform the following tasks:

Establish a minimal execution environment.
Initialize clocks, power-management components, and essential peripherals.
Configure or train DRAM, where necessary.
Initialize storage access sufficiently to read the next stage.
Establish or consult the platform's root of trust.
Authenticate the next firmware component when secure boot is implemented.
Transfer control to the next stage.

The order is not universal. Some security hardware is initialized before external memory; other operations may depend on platform-specific prerequisites. Firmware implementations are designed around these constraints.

2.1 Why Multiple Boot Stages Exist

A small Boot ROM may be unable to initialize every peripheral or load a complete firmware environment. It may contain only enough functionality to find a specific image, authenticate it, and load it into a limited memory region.

The next stage can initialize DRAM, access more storage devices, configure additional hardware, and load larger components.

A typical multi-stage embedded design might contain:

Stage 0: Immutable startup code or hardware-controlled initialization.
Stage 1: A small loader that initializes essential hardware and loads the next component.
Stage 2: A more capable firmware environment or boot manager.
Final loader: A component that prepares the operating-system kernel and its boot parameters.

These labels are descriptive, not universal standards. One manufacturer's PBL may be another manufacturer's first-stage loader, and the same product may use different terminology across chip generations.

3. The Root of Trust and the Chain of Trust

A secure boot chain needs an initial trusted reference. Otherwise, an attacker who replaces the first verification program could replace every subsequent component without detection.

The initial reference is called a root of trust. It may be implemented using immutable code, hardware-protected public keys, one-time-programmable storage, dedicated security hardware, or a combination of these mechanisms.

3.1 How Cryptographic Verification Works

Consider a firmware image that the manufacturer has digitally signed.

The manufacturer creates the firmware image.
A cryptographic hash is calculated over the relevant image data.
The manufacturer signs the hash or corresponding signed metadata using a private signing key.
The device contains or can securely obtain the corresponding trusted public key.
The bootloader checks the signature and validates the image according to its security policy.
If verification succeeds, execution may continue. If it fails, the device follows its configured failure or recovery policy.

A digital signature provides a way to verify authenticity and integrity. It does not, by itself, prove that software is free from vulnerabilities, that its behavior is benign, or that it is the newest permitted version.

Rollback protection addresses a different problem: preventing an attacker from replacing a newer, vulnerable-software-resistant version with an older signed version that contains known vulnerabilities.

3.2 Chain of Trust

A simplified chain of trust looks like this:

Hardware-protected root of trust

↓ verifies

First authenticated firmware stage

↓ verifies

Subsequent firmware or bootloader

↓ verifies

Operating-system loader or kernel

↓ verifies or measures according to platform policy

Additional system components

The critical property is that trust is established through verifiable relationships rather than merely assuming that software is trustworthy because it resides on internal storage.

Not every stage must verify every subsequent component directly. A component may verify a signed metadata structure that authorizes several images or delegates verification to another component.

3.3 Authentication Is Not the Same as Measurement

Authentication determines whether an image is acceptable under a trust policy. Measurement calculates a cryptographic digest and records it, often in hardware-protected registers, for later inspection or attestation.

Measured boot can record what was loaded without necessarily preventing it from loading. Secure boot generally makes an authorization decision before allowing an executable component to run.

A system can implement both.

4. Traditional PC Boot: BIOS and MBR

Before UEFI became common, personal computers generally used legacy BIOS firmware and the Master Boot Record (MBR) boot method.

The traditional process is approximately:

The processor begins executing firmware initialization code.
The BIOS performs hardware initialization and discovers boot devices.
The BIOS selects a boot device according to its configured order.
It loads the initial boot sector from that device into memory.
The boot-sector code locates or loads a more capable bootloader.
The bootloader loads the operating-system kernel.

On a conventional MBR-formatted disk, the first sector contains boot code, a partition table, and a signature. The first-stage code is very small, so it often hands control to a second-stage bootloader.

For example, a Linux installation might use GRUB, while a Windows installation uses Windows-specific boot components.

Legacy BIOS and MBR are related but distinct concepts. BIOS is firmware, whereas MBR is a disk-partitioning and boot-sector convention. UEFI systems commonly use GPT, but UEFI and GPT are not inseparable requirements in every possible configuration.

4.1 Limitations of the Traditional Boot Model

The limited size of the initial boot sector makes complex filesystem handling difficult. The traditional process also lacks the standardized firmware interfaces provided by UEFI.

Legacy boot does not inherently provide the same signature-verification framework as UEFI Secure Boot. Additional security mechanisms can exist, but they must be implemented separately.

5. Modern PC Boot: UEFI, GPT, and the EFI System Partition

Modern desktop and laptop computers commonly use UEFI firmware instead of the traditional BIOS boot model.

UEFI provides a standardized environment for discovering devices, accessing supported storage interfaces, loading EFI applications, and transferring control to operating-system software.

5.1 Typical UEFI Boot Sequence

Reset and early initialization: The processor begins execution, and platform firmware initializes essential hardware.
Platform initialization: Firmware configures memory, processors, chipsets, and other required devices.
UEFI driver and service initialization: Firmware establishes the services needed to access boot devices and execute boot applications.
Boot-manager execution: The UEFI boot manager evaluates boot entries and selects a boot target.
EFI application loading: Firmware loads the selected executable, subject to applicable security policies.
Operating-system loader execution: The loader prepares the kernel and required boot information.
Kernel handoff: Control transfers to the operating system, which initializes its own environment.

UEFI implementations often describe initialization phases using terms such as SEC, PEI, DXE, and BDS in architectures based on the Platform Initialization specification. These phases are implementation architecture concepts, not mandatory names for every UEFI implementation.

5.2 SEC, PEI, DXE, and BDS

SEC — Security Phase: Establishes a minimal execution environment and transfers control to early initialization code. The exact responsibilities depend on the implementation.
PEI — Pre-EFI Initialization: Performs early platform initialization, commonly including memory initialization.
DXE — Driver Execution Environment: Loads and executes drivers and establishes many of the firmware services required for boot.
BDS — Boot Device Selection: Selects a boot target and initiates the appropriate boot application or operating-system loader.

These phase names come from the UEFI Platform Initialization architecture. They should not be interpreted as a universal sequence that every PC implements identically.

5.3 What Is the EFI System Partition?

The EFI System Partition (ESP) is a special disk partition used by UEFI-based operating systems to store boot applications and related files.

On a typical Windows installation, the ESP contains Windows Boot Manager and supporting boot files. On a Linux system, it may contain GRUB, systemd-boot, kernel images, initramfs images, or other EFI applications depending on the installation.

The ESP is commonly formatted using FAT. UEFI firmware does not generally need to understand every filesystem supported by the operating system; it needs an appropriate method of accessing the boot application.

Official reference: UEFI specifications.

5.4 What Is GPT?

GUID Partition Table (GPT) describes a disk-partitioning format. It identifies partitions using globally unique identifiers and supports a more flexible partition layout than traditional MBR.

GPT does not verify operating-system images. Its role is to describe the organization of storage.

This distinction matters because several different components work together during startup:

UEFI provides firmware interfaces and boot-management services.
GPT describes the disk's partition layout.
The ESP stores EFI applications and related files.
The boot manager chooses what to execute.
Secure Boot can authorize EFI executable images.
The operating-system loader prepares the kernel.

6. UEFI Secure Boot: PK, KEK, db, and dbx

UEFI Secure Boot uses a firmware-managed trust policy to decide which EFI executable images are permitted to run.

Common UEFI Secure Boot variables include the following:

PK — Platform Key: Establishes the platform owner or authority for managing Secure Boot configuration.
KEK — Key Exchange Keys: Authorize certain updates to the signature and revocation databases.
db — Signature Database: Contains trusted certificates, hashes, or other supported authorization entries.
dbx — Forbidden Signature Database: Contains revoked or forbidden entries that must not be accepted.

The exact configuration depends on the platform and its firmware implementation. Some systems allow users to manage keys; others expose a more restricted configuration.

6.1 How the Verification Decision Works

When Secure Boot is enabled, firmware checks whether a boot executable is authorized by the applicable trust policy. It also applies relevant revocation information.

An executable that is signed by a trusted authority can still be rejected if its signature or image hash has been revoked. Conversely, an operating system that is not signed by a currently trusted authority may be rejected even if its files are otherwise intact.

Secure Boot therefore answers a policy question: Is this executable authorized to run under the current firmware trust configuration?

6.2 Does UEFI Secure Boot Verify the Entire Operating System?

Not necessarily.

UEFI Secure Boot typically establishes authorization at the firmware-to-boot-application boundary. The operating-system loader and later components may provide additional verification.

For Windows, Trusted Boot continues the security process after the firmware stage. Other operating systems may use signed kernels, bootloader verification, integrity-protected root filesystems, or additional mechanisms.

It is therefore inaccurate to claim that enabling UEFI Secure Boot automatically verifies every file in an installed operating system.

References:

7. Windows Boot: From UEFI to the Windows Kernel

On a typical modern UEFI-based Windows PC, the boot process proceeds through several components.

Platform firmware initializes hardware.
UEFI Boot Manager selects the Windows boot entry.
Windows Boot Manager, commonly bootmgfw.efi, begins the Windows boot process.
Windows Boot Manager uses the Boot Configuration Data (BCD) store to determine the selected operating system and its boot configuration.
Windows OS Loader, commonly winload.efi, prepares the kernel, HAL, boot-start drivers, and other required components.
The Windows kernel begins execution and initializes the operating system.
Kernel initialization proceeds to the appropriate session and user-mode startup components.

The exact sequence and the components involved depend on the Windows version, device configuration, and recovery or resume path.

7.1 Secure Boot, Trusted Boot, and Measured Boot

Windows uses several related security mechanisms.

Secure Boot: Helps prevent unauthorized EFI executables from loading.
Trusted Boot: Extends integrity checking into the Windows boot process.
Early Launch Anti-Malware (ELAM): Provides an early opportunity to evaluate boot-start drivers before ordinary anti-malware protection is fully active.
Measured Boot: Records measurements of relevant startup components in a Trusted Platform Module (TPM), when supported and configured.

Measured Boot is especially important because it can provide evidence about the startup configuration. Measurement is not identical to prevention: recording a component's hash does not automatically stop that component from running.

A TPM can also support platform attestation, in which a verifier evaluates evidence about a machine's state. This can be used in enterprise security and device-compliance systems.

Reference: Microsoft — Secure the Windows boot process.

8. Linux Boot: GRUB, systemd-boot, and the EFI Stub

Linux does not require one universal bootloader. Depending on the platform, Linux can be started through GRUB, systemd-boot, U-Boot, an EFI application, or another loader.

8.1 Linux on a Typical UEFI PC

A common Linux boot sequence is:

UEFI firmware initializes the platform.
The firmware selects a Linux boot entry.
GRUB, systemd-boot, or another loader starts.
The loader loads the Linux kernel and, when required, an initramfs image.
The loader supplies kernel parameters and relevant platform information.
The kernel initializes its own subsystems.
The kernel starts the initial userspace process.
The userspace initialization system starts services and the graphical or command-line environment.

8.2 GRUB

GRUB is a bootloader that can support multiple operating systems and a variety of filesystems and boot configurations. It is commonly used on Linux desktops and servers.

GRUB can load a Linux kernel and initramfs, pass kernel command-line parameters, and present a menu for selecting operating systems or kernel versions.

8.3 systemd-boot

systemd-boot is a relatively simple UEFI boot manager. It reads boot-entry information and loads EFI executable images.

Linux kernels configured with the EFI stub can be executed directly as EFI applications. This means a traditional intermediate bootloader is not always required for the kernel-loading step.

However, the EFI stub does not replace the platform firmware. It provides a way for a Linux kernel to be loaded through the UEFI execution model.

References:

8.4 What Is an Initramfs?

An initramfs is an early userspace environment made available to the Linux kernel during startup.

It can contain tools, drivers, scripts, libraries, and an initial init program. It is particularly useful when the kernel needs additional functionality before it can mount the final root filesystem.

For example, an initramfs may unlock an encrypted root partition, assemble a RAID array, discover a storage device, or prepare a complex filesystem layout.

Once the real root filesystem is ready, the system transitions into the main userspace environment.

8.5 Is Secure Boot Mandatory for Linux?

No. Linux can boot on systems without Secure Boot, and Linux distributions differ in how they integrate with firmware trust policies.

When UEFI Secure Boot is enabled, a distribution may use a trusted first-stage EFI executable, such as a signed shim, which can then validate GRUB and the kernel according to the distribution's configuration.

Other configurations use different signed loaders or direct kernel boot. The details depend on the distribution, signing keys, firmware, and security policy.

UEFI Secure Boot also does not automatically mean that every file on a Linux root filesystem is verified. Additional mechanisms are required for that objective.

9. ARM TrustZone and Trusted Firmware-A

Many ARM-based systems have a more complex firmware architecture than the simple model of a single bootloader loading a kernel.

ARM TrustZone is a hardware security architecture that separates certain secure and non-secure execution environments. It is not itself a bootloader, an operating system, or a complete secure boot implementation.

Trusted Firmware-A (TF-A) is an open-source reference implementation for firmware used on Arm application processors. It provides software for secure initialization and runtime services on supported platforms.

9.1 Common TF-A Boot Stages

TF-A documentation uses stage names such as BL1, BL2, BL31, BL32, and BL33. Their use depends on the platform configuration.

BL1: The first TF-A boot stage in designs that use this arrangement. It commonly performs early initialization and loads the next stage.
BL2: Performs additional platform initialization and loads later firmware components.
BL31: Provides EL3 runtime firmware services, including the secure monitor functionality needed for transitions between security states.
BL32: An optional secure-world payload, such as a Trusted Execution Environment.
BL33: A non-secure-world payload, often a bootloader such as U-Boot or a UEFI implementation.

These labels describe the TF-A architecture. They do not imply that every ARM smartphone or PC uses these exact stages, nor that BL1 is always the first code executed by the physical processor.

A vendor may use immutable silicon Boot ROM before loading TF-A, or integrate different components into its proprietary firmware.

Official reference: Trusted Firmware-A documentation.

10. U-Boot and Embedded Linux Devices

U-Boot is a widely used open-source bootloader in embedded systems. It supports many processor architectures and can load operating systems through different storage devices, network interfaces, and firmware environments.

It is used in various development boards, embedded Linux devices, appliances, and other products. Its presence does not imply that a device uses UEFI.

10.1 U-Boot TPL, VPL, SPL, and Main U-Boot

Some U-Boot configurations divide startup into several stages.

TPL — Tertiary Program Loader: A very small early stage used when the platform needs an additional initialization step.
VPL — Verifying Program Loader: An optional stage associated with verified boot configurations. Its availability and implementation maturity depend on the U-Boot version and platform.
SPL — Secondary Program Loader: A small loader that initializes enough hardware to load the main U-Boot image and potentially other firmware components.
Main U-Boot: Provides the more capable bootloader environment and can load an operating system, launch another firmware environment, or perform recovery tasks.

Not all platforms use TPL or VPL. Many use SPL followed by main U-Boot, while others employ different arrangements.

10.2 U-Boot Can Load UEFI

U-Boot can be configured to load and execute UEFI applications. In some systems, it can launch an EDK II implementation or another EFI environment.

Consequently, U-Boot and UEFI are not necessarily competing alternatives. U-Boot may be used as a stage that eventually launches UEFI firmware or an operating system through UEFI interfaces.

Conversely, U-Boot can boot Linux directly without UEFI.

References:

11. Coreboot: An Alternative PC Firmware Architecture

Coreboot is an open-source firmware project designed to initialize hardware and hand control to a subsequent payload.

It is particularly interesting because it demonstrates that PC firmware does not have to follow the same internal architecture as a conventional vendor UEFI implementation.

11.1 Typical Coreboot Stages

Bootblock: The earliest coreboot stage. It establishes a minimal execution environment and loads the next stage.
Verstage: An optional verification stage used by supported verified boot configurations.
Romstage: Performs early initialization, commonly including memory initialization.
Post-CAR or other transition stages: Some configurations use additional stages when moving from temporary cache-backed memory to ordinary RAM.
Ramstage: Performs later initialization and prepares the system for the payload.
Payload: The software that coreboot launches, such as a Linux kernel or a UEFI implementation.

The precise stage names and transitions vary by architecture, mainboard, and configuration. The important architectural point is that coreboot focuses on hardware initialization and then hands off to a payload.

A payload can be an operating system or a more complete firmware environment. Coreboot can therefore be paired with projects that provide UEFI functionality.

Reference: Coreboot architecture documentation.

12. Android Boot Architecture: A Different Approach

Android smartphones generally do not follow the same boot sequence as an ordinary UEFI-based Windows PC.

Although some Android boot architectures use UEFI internally, many phones rely on a vendor-specific sequence involving immutable Boot ROM code, several firmware images, a device-specific bootloader, and Android-specific verified boot mechanisms.

The boot architecture is determined by the SoC vendor, the device manufacturer, the device generation, and the Android implementation.

12.1 Typical Android Boot Sequence

Power-on and SoC reset

↓

Boot ROM / initial trusted code

↓

Primary or early bootloader

↓

Platform initialization and subsequent firmware

↓

Device bootloader

↓

Verified Boot and boot-image selection

↓

Linux kernel and initramfs

↓

Android init and system services

↓

Zygote, system_server, and Android applications

This is a conceptual overview, not a universal list of firmware partitions. Some components may be combined, renamed, or absent, and additional security firmware may execute alongside the main boot chain.

Official reference: Android Open Source Project — Bootloader overview.

12.2 Primary Bootloader and Boot ROM

The earliest boot code is often referred to as the Primary Bootloader (PBL) on Qualcomm platforms.

Depending on the device, the Boot ROM may authenticate the next stage, configure initial hardware, and load a subsequent firmware image from the device's storage or another supported boot source.

On Qualcomm platforms, the PBL authenticates the eXtensible Boot Loader (XBL) in the documented boot architecture. The exact implementation varies across chip generations and products.

The PBL is generally not an ordinary user-updatable Android partition. It is closely tied to the SoC's hardware and its boot security design.

12.3 Secondary Bootloader and Platform Initialization

Once the initial boot stage has established enough hardware functionality, later firmware can perform more complex initialization.

This may include:

DRAM initialization and memory training.
Power-management and peripheral initialization.
Initialization of trusted execution environments.
Loading additional security firmware or hypervisors.
Storage access and operating-system boot selection.
Verification of later firmware and operating-system images.

The division of responsibility differs among manufacturers. A component named XBL, SBL, LK, ABL, or S-Boot should not automatically be assumed to perform exactly the same work as a similarly named component on another device.

13. Qualcomm Boot Architecture: PBL, XBL, ABL, and EDL

Qualcomm Snapdragon devices use a vendor-specific firmware architecture. The boot sequence differs across SoC families, but modern Qualcomm Linux documentation describes a chain that includes PBL, XBL, a Trusted Execution Environment, a hypervisor where applicable, and UEFI.

13.1 Qualcomm PBL

The Primary Bootloader is the initial boot component in the documented Qualcomm boot architecture. It authenticates and loads XBL from the boot device.

On a typical secure-boot-enabled device, the initial verification process depends on trust information established through hardware-backed mechanisms. Exact key-storage arrangements and image formats depend on the SoC and its security configuration.

13.2 XBL — eXtensible Boot Loader

XBL is a subsequent boot stage that performs more extensive platform initialization.

Qualcomm's documented Linux boot flow describes XBL initializing hardware and memory, loading and authenticating additional firmware, and loading a UEFI image. The specific set of components depends on the platform.

This illustrates an important distinction: a bootloader can perform substantial hardware initialization and also load or authenticate another firmware environment.

13.3 ABL — Android Bootloader

On many Qualcomm-based Android devices, Android Bootloader (ABL) is associated with the Android boot and fastboot environment.

Depending on the implementation, the device may use UEFI facilities alongside Android-specific bootloader functionality. The precise boundary between XBL, UEFI, and ABL varies by generation.

It is therefore too simplistic to say that every Qualcomm smartphone uses exactly the same sequence of XBL followed by ABL, with no intermediate firmware or architectural differences.

13.4 EDL — Emergency Download Mode

Qualcomm Emergency Download Mode (EDL) is a low-level recovery and programming environment used by supported Qualcomm platforms.

EDL is distinct from Android recovery, fastboot, and normal operating-system startup. It can be useful when the ordinary boot chain cannot successfully launch the installed operating system.

On supported devices, EDL may be entered through a hardware-specific recovery path or another platform-dependent mechanism. The exact behavior depends on the SoC, device design, security configuration, and available authorized programming tools.

A failed verification does not universally imply that a device will enter EDL. Failure handling is implementation-dependent and may instead halt, retry another boot slot, enter a recovery environment, or display an error.

EDL availability also does not guarantee that arbitrary firmware can be flashed. Secure programming requirements and device-specific authorization can restrict what operations are permitted.

Official references:

14. Samsung Exynos, S-Boot, and Samsung Secure Boot

Samsung Exynos devices have their own vendor-specific boot architecture. The names and implementation details vary by generation, and not every Samsung smartphone uses an Exynos SoC.

S-Boot is a bootloader associated with Samsung's Android boot architecture. The complete sequence may also involve earlier immutable code, platform initialization firmware, trusted execution components, and other proprietary stages.

Samsung devices establish a platform-specific chain of trust. Public technical discussions sometimes use the term Samsung Secure Boot Key (SSBK), but it should not be treated as a universal, fully documented description of every Samsung boot implementation.

The exact key hierarchy, key-storage arrangements, verification stages, and rollback protections depend on the device and its SoC generation. These details should be established from documentation or analysis specific to the hardware in question.

14.1 What Happens When Verification Fails?

A Samsung device does not necessarily behave like a Qualcomm device when an image fails verification.

Its response depends on which component detects the failure and the policy associated with that component. Possible outcomes include stopping the boot process, entering a recovery or download mode, or presenting a security warning.

Download Mode, Android recovery, and emergency programming interfaces should not be treated as equivalent mechanisms.

For Samsung-specific research, device-specific bootloader documentation and hardware research are particularly important because many production details are proprietary.

15. MediaTek Boot Architecture: Boot ROM, Preloader, and LK

MediaTek-based Android devices also use a vendor-specific boot chain. The precise stage names, image formats, and security mechanisms depend on the SoC family and device manufacturer.

A common historical MediaTek sequence includes Boot ROM, a preloader, and a later bootloader such as Little Kernel (LK), although modern devices can use different firmware architectures.

15.1 Boot ROM

The earliest immutable code performs the initial boot operations and determines how the next stage is located and loaded.

Depending on the platform, it may support a hardware-defined download or recovery path. The available interfaces and security restrictions vary by device.

15.2 Preloader

The preloader is an early firmware component used on many MediaTek devices.

Its responsibilities may include initializing essential hardware, preparing memory, configuring storage access, and loading later firmware components. The exact duties differ by platform.

15.3 LK and Other Bootloaders

Little Kernel is a small embedded operating-system kernel that has been adapted for bootloader use in various products.

Some MediaTek Android devices use LK-derived bootloaders, while other generations and product families employ different implementations.

It is not accurate to classify all modern MediaTek devices as using one universal UEFI-based architecture. UEFI may be used in particular configurations, but the boot chain must be identified for the specific SoC and device.

15.4 MediaTek Download and Recovery Interfaces

MediaTek platforms have used download and service interfaces for device programming and recovery. Their availability, security restrictions, and implementation vary by generation.

A low-level download interface is not equivalent to an unlocked Android bootloader. A device may expose a recovery interface while still requiring authenticated or authorized firmware operations.

16. Other Smartphone and Embedded SoC Architectures

Qualcomm, MediaTek, and Samsung are important examples, but they do not cover every mobile or embedded platform.

16.1 Rockchip

Rockchip-based boards and devices commonly use Rockchip-specific early firmware together with U-Boot or related bootloader implementations, depending on the platform.

Some products use vendor firmware packages, device trees, and specialized recovery mechanisms. The details vary between SoC families and product manufacturers.

16.2 Allwinner

Allwinner platforms have used Boot ROM-based startup and support mechanisms such as FEL on supported SoCs. U-Boot is commonly used in open-source embedded Linux configurations.

FEL is a Boot ROM-based mechanism used for supported recovery and programming workflows. Its existence does not imply that every Allwinner device has identical firmware security or recovery behavior.

16.3 NXP i.MX

NXP i.MX platforms commonly use ROM-based startup and can support boot flows involving SPL, U-Boot, and other firmware components.

Depending on the processor family, secure boot may use hardware-supported authentication and platform-specific key-management mechanisms.

U-Boot documentation describes USB Serial Download Protocol support for supported i.MX configurations.

16.4 RISC-V Platforms

RISC-V does not prescribe a single universal bootloader architecture for all implementations.

A RISC-V system may start in platform-specific firmware, initialize hardware, enter OpenSBI or another supervisor interface implementation, and then load a bootloader or operating system.

OpenSBI provides an open-source implementation of the RISC-V Supervisor Binary Interface (SBI). It commonly supplies machine-mode firmware services to supervisor-mode software, such as an operating-system kernel.

U-Boot can be used with OpenSBI in supported configurations. Other systems may use different firmware stacks.

The processor instruction-set architecture alone does not determine the entire boot sequence or security policy.

References:

17. Apple iPhone and iPad: Boot ROM, iBoot, and the Secure Boot Chain

Apple mobile devices use a secure boot architecture that differs from both conventional UEFI PCs and most Android smartphones.

Apple's documented startup process begins with immutable Boot ROM code in the application processor. This code acts as the hardware root of trust and verifies the next boot component.

17.1 Simplified iPhone and iPad Boot Flow

Boot ROM: Immutable code executes first and verifies the next boot component according to the platform's trust policy.
Low-level boot components: Subsequent boot firmware is loaded and authenticated.
iBoot: Apple's bootloader performs further initialization and verifies the relevant operating-system components.
Kernel loading: iBoot loads the operating-system kernel and related boot data.
Kernel initialization: The kernel initializes the operating system.
Userspace startup: The system starts its userspace services and applications.

The actual boot sequence includes additional details and can vary by device generation. The list above is intended as a conceptual outline.

17.2 How Apple's Chain of Trust Works

Apple documents that the application processor begins with Boot ROM, which contains a trusted public key used to verify iBoot. Subsequent components are checked as the boot process continues.

This makes the chain of trust dependent on cryptographic relationships between stages rather than merely relying on software being stored in an internal partition.

Apple's approach also includes security mechanisms that are specific to its hardware and software ecosystem.

Official reference: Apple Platform Security — Boot process for iPhone and iPad.

18. Apple Silicon Mac: Why It Is Not a Conventional UEFI PC

Apple silicon Macs use a boot architecture related to the one used by Apple mobile devices. They should not be assumed to follow the conventional PC sequence of motherboard UEFI, Windows Boot Manager, and an operating-system loader.

Apple documents a sequence involving Boot ROM, the Low-Level Bootloader (LLB), and iBoot.

18.1 Simplified Apple Silicon Boot Flow

Boot ROM: The first stage of the hardware-rooted chain of trust.
LLB — Low-Level Bootloader: Verifies and loads subsequent boot components and relevant system-paired firmware.
LocalPolicy evaluation: The system evaluates the policy associated with the selected operating-system installation.
iBoot: Loads and verifies relevant operating-system components and boot data.
Kernel and kernel collections: The required kernel and authorized extensions are prepared for execution.
Signed System Volume verification: The system verifies the root hash associated with the signed system volume according to its security policy.
macOS startup: The kernel and userspace initialize the operating system.

The exact sequence depends on the selected operating system and its startup-security configuration.

18.2 Full Security, Reduced Security, and Permissive Security

Apple silicon Macs support different startup-security policies.

Full Security: Enforces Apple's strongest standard startup policy for supported macOS installations.
Reduced Security: Permits certain configurations that require reduced restrictions, such as some older operating-system versions or third-party kernel extensions.
Permissive Security: Supports additional flexibility for certain custom kernel and development configurations.

These policies do not mean that the machine has abandoned its entire chain of trust. Rather, they change which components and configurations are accepted under the relevant verification rules.

LocalPolicy is important because Apple silicon Macs can maintain an authorized security policy for a particular operating-system installation. This provides a more nuanced model than treating the machine as having only one global boot-security setting.

Official references:

18.3 Intel Macs and the T2 Security Chip

Intel-based Macs should be considered separately from Apple silicon Macs.

Some Intel Macs include Apple's T2 Security Chip, which provides additional security and startup functionality. On supported T2-equipped models, Apple documents a secure boot sequence involving the T2 chip, iBoot, and the UEFI firmware used by the Intel processor.

Other Intel Macs have different security architectures. Therefore, Apple's mobile-style secure boot model should not be generalized to every Mac ever manufactured.

Reference: Apple Platform Security — Boot process for an Intel-based Mac.

19. Huawei Devices and HarmonyOS: What Can Be Established?

Huawei's smartphone platforms require special care when discussing boot architecture because HarmonyOS is not a single, publicly documented firmware stack that can be mapped identically across all Huawei products.

Huawei devices have evolved across different hardware generations, software platforms, and product categories. The term HarmonyOS can also refer to different platform generations and implementations.

Consequently, a description of one Huawei device's boot chain should not automatically be applied to every device marketed with HarmonyOS.

19.1 The General Architecture

At a conceptual level, a secure smartphone platform needs a mechanism to begin execution, establish trust in subsequent firmware, initialize essential hardware, select an operating system, and transfer control to it.

Huawei's specific implementation may use proprietary boot firmware and hardware security mechanisms. The precise names, number of stages, image formats, key hierarchy, and verification boundaries depend on the device and its hardware generation.

However, it would be misleading to claim a universal Huawei boot sequence such as:

Boot ROM → PBL → XBL → ABL → AVB → HarmonyOS

That sequence combines terminology associated with other vendor architectures and should not be presented as a documented HarmonyOS boot chain.

19.2 HarmonyOS Is Not a Bootloader

HarmonyOS is an operating-system platform, not the name of a firmware initialization stage.

The operating system and the software that loads it occupy different positions in the boot architecture. A proprietary bootloader can launch an operating system without being part of that operating system's userspace.

The precise relationship between HarmonyOS components and earlier firmware stages must be established using documentation specific to the relevant device or platform release.

19.3 HarmonyOS and OpenHarmony

OpenHarmony is an open-source project associated with the broader HarmonyOS ecosystem. Its source code and documentation can provide insight into supported operating-system architectures, kernel components, and some system-level implementation details.

However, open-source operating-system code does not necessarily expose the complete production boot chain of a commercial Huawei smartphone. Proprietary firmware, secure boot keys, SoC initialization, and device-specific verification policies may remain outside the publicly available source tree.

Likewise, an implementation documented for an OpenHarmony development board should not automatically be treated as the implementation used by a commercial HarmonyOS smartphone.

19.4 What About Secure Boot?

Secure startup, code authentication, and hardware-backed security are important concepts when evaluating mobile platforms. But the exact mechanism should be described using evidence for the specific implementation.

Without device-specific technical documentation, it is not possible to establish that every HarmonyOS device uses Android Verified Boot, UEFI Secure Boot, or an identical Huawei-specific chain of trust.

Android Verified Boot is an Android implementation with defined metadata structures and bootloader integration. A different operating system can implement analogous security properties without using AVB itself.

References for further investigation:

Research note: A complete, authoritative stage-by-stage description of Huawei's production boot chain should be tied to a specific model, SoC, and HarmonyOS release. Where that evidence is unavailable, the architecture should be described as proprietary or insufficiently documented rather than filled in with assumptions.

20. Android Verified Boot (AVB): The Operating-System Integrity Layer

Android Verified Boot is one of the most important parts of the Android startup architecture. It is designed to establish the integrity and authenticity of Android software through a chain of trust.

Android 8.0 and later include a reference implementation called Android Verified Boot 2.0, commonly abbreviated AVB.

AVB is not a replacement for the SoC's initial secure boot mechanism. It is an Android-specific verified-boot implementation integrated with the bootloader and Android image formats.

20.1 Where AVB Fits in the Boot Chain

A simplified Android startup chain looks like this:

Hardware root of trust

↓

Authenticated early firmware

↓

Android-capable bootloader

↓

AVB metadata and image verification

↓

Kernel, ramdisk, and related boot images

↓

Integrity-protected Android partitions

↓

Android userspace

The root of trust and the bootloader provide the foundation needed for the Android-specific verification process. AVB then defines how Android image metadata, signatures, hashes, and rollback protection can be used.

20.2 What Is VBMeta?

VBMeta is a central data structure in Android Verified Boot. It contains descriptors and other metadata, with cryptographic authentication used to establish trust in the described images or verification information.

Descriptors can describe different kinds of verification information, including:

Image hashes.
Hashtree metadata.
Chained partitions and delegated verification.

VBMeta is not simply a list of filenames or a checksum file. Its signed metadata allows a bootloader using AVB to determine whether relevant images and their verification metadata are acceptable.

20.3 Hash Descriptors

A hash descriptor is useful for an image that can be verified by hashing the relevant image data and comparing the result with the expected digest.

For example, the AVB metadata may describe the expected hash of a boot image. The verification process calculates the appropriate digest and checks it against the trusted metadata.

If the digest does not match, the image has not passed the integrity check. The bootloader must then follow the applicable verification-failure policy.

20.4 Hashtree Descriptors and dm-verity

Large filesystem images can require a different verification strategy because verifying the entire partition in one operation is less practical than verifying data as it is accessed.

Android can use a cryptographic hash tree, commonly called a hashtree, together with the Linux kernel's dm-verity mechanism.

A hash tree contains digests arranged so that the root hash commits to the integrity of the underlying data and the intermediate hash structure.

In an AVB hashtree configuration, metadata can include the root hash, salt, offsets, and other parameters needed to verify the partition.

As data is read, dm-verity checks the relevant blocks against the hash tree. This allows integrity verification to continue during normal operation rather than only during the initial boot.

The distinction is important:

Image hash: Verifies a defined image using a calculated digest.
Hashtree verification: Supports integrity checking of larger data regions through a tree of hashes.
dm-verity: Provides kernel-level block verification for supported configurations.

20.5 Chained Partitions

AVB supports delegated verification through chained partitions.

Instead of placing all verification information directly into a single top-level metadata structure, a chain descriptor can establish trust in another VBMeta structure using the relevant key and rollback-index information.

This supports a modular design in which different groups of partitions can have separate verification metadata and keys.

20.6 Rollback Protection

Signature verification alone cannot prevent an attacker from installing an older, correctly signed image that contains known vulnerabilities.

AVB supports rollback protection using version indices and tamper-resistant storage integrated by the device implementation.

The device compares the relevant rollback indices with its protected state and rejects images that violate the applicable rollback policy.

This means that a cryptographically authentic image is not necessarily acceptable: it must also satisfy the device's security policy.

20.7 A/B Updates and Boot Slots

Many Android devices support A/B-style updates. In a typical implementation, the device has two sets of bootable system components or slots.

An update can be written to the inactive slot while the currently working system remains available. After the update is installed, the bootloader can attempt to start the new slot.

If the updated system fails to boot successfully, the update framework and boot-control mechanism can arrange for a fallback to the previously working slot, provided the relevant slot and rollback policies permit it.

Rollback protection and slot selection must be coordinated. A fallback cannot simply bypass a security policy that forbids an older version.

Official references:

21. Android Partitions: boot, init_boot, vendor_boot, system, and vbmeta

Android uses several partition types to separate kernel-related images, generic operating-system components, vendor-specific software, and verification metadata.

The exact layout depends on the device's Android version, launch configuration, partitioning scheme, and update design.

21.1 boot

The boot partition commonly contains the Linux kernel and, depending on the device's Android version and boot-image configuration, a generic ramdisk.

The bootloader loads the required boot image and prepares the kernel to execute.

21.2 init_boot

On devices launched with Android 13 and later, the init_boot partition is used for the generic ramdisk in the relevant boot architecture.

This reflects changes in Android's generic boot-image organization. Older devices and other configurations may place the ramdisk elsewhere.

21.3 vendor_boot

The vendor_boot partition stores vendor-specific boot information, which can include vendor ramdisk content and related data required by the platform.

Its role is part of Android's effort to separate generic operating-system boot components from hardware-specific components.

21.4 system and system_ext

The system partition contains core Android operating-system software. The system_ext partition can contain system extensions associated with the product.

The exact division depends on the Android release and device implementation.

21.5 vendor and odm

The vendor partition contains hardware-specific software and vendor implementations. The odm partition can contain additional device-manufacturer-specific components.

These partitions help separate the generic Android framework from software that is specific to the hardware and product.

21.6 vbmeta

The vbmeta partition commonly contains AVB metadata used to verify other partitions. Additional VBMeta structures may be associated with chained verification arrangements.

It is therefore possible for the verification of one partition to depend on metadata and keys associated with another part of the boot chain.

21.7 Dynamic Partitions

Dynamic partitions allow certain logical Android partitions to be managed within a larger physical partition, often called super.

They change how some partitions are allocated and updated, but they do not eliminate the need for the bootloader or AVB to verify the relevant images according to the device's security policy.

Official reference: Android — Partitions overview.

22. Android Bootloader, Fastboot, Recovery, and Fastbootd

Several different operating modes are often confused because they can all be accessed before the normal Android interface starts.

22.1 Bootloader Mode

Bootloader mode is a device-specific environment controlled by the boot firmware. Depending on the device, it can provide boot selection, diagnostic commands, flashing interfaces, and device-state information.

Many Android devices expose a fastboot interface in this environment.

22.2 Fastboot

Fastboot is a protocol and associated tool used to communicate with a compatible bootloader or fastboot implementation.

It supports operations such as querying device variables, downloading images, flashing permitted partitions, and requesting reboot operations.

The commands accepted by a device depend on its bootloader implementation, security state, and partition layout.

22.3 Bootloader Unlocking

Unlocking a bootloader changes the device's policy regarding the installation or execution of alternative software.

On supported Android devices, the user may explicitly authorize unlocking through the device's bootloader interface. Unlocking commonly causes a data wipe to protect user information.

An unlocked bootloader does not mean that all hardware security features have been disabled. It means that the bootloader's acceptance policy has changed in ways defined by the implementation.

22.4 Android Recovery

Recovery is a separate boot environment intended for maintenance, updates, repair, and related operations.

It may use its own kernel and ramdisk or share components with another boot environment, depending on the device.

Recovery is not the same thing as the earliest bootloader stage, even when the device provides a hardware key combination to enter it.

22.5 Fastbootd

Fastbootd is a userspace implementation of fastboot used by supported Android devices.

It was introduced to support operations associated with modern Android partitioning, including dynamic partitions. Rather than performing every flashing operation inside the bootloader, the device can enter a userspace environment that has the relevant operating-system infrastructure.

This makes fastbootd distinct from the bootloader's own fastboot implementation.

References:

23. Android Kernel Startup: init, Zygote, and system_server

After the bootloader has loaded the kernel and the kernel begins execution, the device still has substantial work to perform before the Android home screen becomes available.

23.1 Kernel Initialization

The Linux kernel initializes processors, memory management, device drivers, security facilities, and other core subsystems.

On Android, the kernel receives platform-specific information and loads the initial userspace environment according to the boot configuration.

23.2 init

The Android init process is responsible for early userspace initialization and starting numerous system services.

Its tasks include processing initialization rules, preparing required filesystems and directories, setting permissions, configuring properties, and launching services.

The exact sequence depends on the Android version and device configuration.

23.3 Filesystem Integrity

Verified Boot can establish integrity guarantees for Android partitions, while dm-verity can check protected filesystem blocks as they are read.

Mounting a filesystem and verifying its integrity are separate operations. The operating system must establish the correct filesystem configuration, while the relevant verification mechanism enforces the applicable integrity policy.

23.4 Zygote

Zygote is a core Android runtime process. It initializes runtime components and preloads classes and resources commonly used by applications.

When an application process is created, Android can use Zygote's process-forking mechanism to avoid repeating certain initialization work for every application.

This is one reason Android's application startup architecture differs from a simple model in which each application is launched independently from the earliest stages of userspace.

23.5 system_server

system_server hosts many important Android framework services. These services coordinate major operating-system functions and provide functionality used by applications and other system components.

After the kernel and early userspace initialize, Zygote and the Android framework bring up the higher-level services that make the device usable.

Reference: Android Open Source Project — Architecture.

24. Generic Bootloader for Android: A Move Toward Standardization

Android has historically relied on bootloaders that differ significantly between SoC vendors and device manufacturers.

That fragmentation makes firmware maintenance, security updates, and consistent boot behavior more difficult.

The Android Open Source Project describes a Generic Bootloader (GBL) designed to standardize more of the Android boot process.

24.1 What GBL Provides

GBL includes common Android boot logic, fastboot functionality, optional vendor extensions, and UEFI protocol handlers needed for the supported architecture.

It also defines Android-specific UEFI protocols for functions such as AVB integration, fastboot, slot selection, and operating-system configuration.

This does not mean that every Android smartphone already uses an identical generic bootloader. Integration depends on the platform and device implementation.

The AOSP documentation recommends that manufacturers shipping Android 16 devices based on ARM64 use the latest Google-certified GBL implementation.

Official reference: Android — Generic Bootloader overview.

25. Why Some Devices Use UEFI and Others Do Not

UEFI is common on desktop PCs, laptops, servers, and certain embedded platforms. However, its presence is not a universal requirement for a secure boot process.

Several architectural approaches can accomplish the task of loading an operating system:

UEFI-based boot: Platform firmware exposes UEFI services and loads EFI applications.
Direct bootloader-to-kernel: A bootloader loads the kernel without an intermediate UEFI environment.
ROM-based multi-stage boot: Immutable initial code loads successive firmware stages until a capable operating-system loader is available.
Apple's proprietary boot chain: Apple-specific firmware verifies and loads operating-system components.
Embedded firmware with a payload: Firmware such as coreboot initializes hardware and launches a payload that may itself be UEFI or an operating system.

These are different implementations of a common architectural objective, not competing definitions of what booting means.

25.1 Why UEFI Is Common on PCs

PC platforms benefit from standardized firmware interfaces, common storage conventions, support for multiple operating systems, and a defined EFI application model.

UEFI provides an established framework for these requirements.

25.2 Why Smartphones Often Have Proprietary Boot Chains

Smartphones are tightly integrated systems. The SoC, power management, memory, storage, cellular modem, secure hardware, and other components are designed as a coordinated platform.

Manufacturers may use proprietary firmware because they need to initialize specialized hardware, enforce product-specific security requirements, manage modem and trusted firmware, and support device-specific update or recovery behavior.

Android's use of a Linux kernel does not require every Android device to use the same firmware architecture.

26. What Happens When Verification Fails?

Verification failure is not a single universal event with one standard response. The response depends on which component detects the failure, what is being verified, and what policy the device implements.

Possible outcomes include:

Refusing to execute an unauthenticated firmware image.
Trying another permitted boot image or slot.
Entering a recovery environment.
Displaying a warning about the device's security state.
Stopping the boot process until the software is repaired.
Entering a platform-specific service or download mode.

A failure in the first authenticated firmware stage can have different consequences from a failure in an Android system partition. Similarly, a runtime dm-verity error is not identical to a boot-time signature failure.

26.1 Android Verified Boot States

Android defines recognizable verified-boot states that can be communicated to the operating system and user.

Green: A locked device using the normal embedded root of trust.
Yellow: A locked device using a user-configured root of trust.
Orange: An unlocked device, indicating that the normal locked-device integrity guarantees do not apply in the same way.

Android also defines error states associated with verified-boot failures. The actual warning behavior depends on the device's implementation and the kind of failure detected.

An orange state does not by itself prove that the operating system is malicious. It indicates that the bootloader is unlocked and that the normal locked-device verification guarantees cannot be assumed.

Likewise, a green state is not a guarantee that every component is free from vulnerabilities. It indicates that the relevant boot verification policy has accepted the system.

Reference: Android — Verified Boot flow and user-visible states.

27. Secure Boot Does Not Guarantee a Vulnerability-Free Device

Secure boot and verified boot protect specific boundaries in the startup process. They do not automatically eliminate every possible attack.

Several limitations should be understood.

27.1 Trusted Software Can Contain Vulnerabilities

A correctly signed component may still contain exploitable bugs. Signature verification establishes that the component is authorized under a particular trust policy; it does not establish that its code is perfect.

27.2 Rollback Protection Must Be Implemented

Without appropriate rollback protection, an attacker may be able to install an older but correctly signed image. Whether this is possible depends on the device's update and security design.

27.3 Runtime Attacks Are a Separate Problem

Even if a device boots verified software, vulnerabilities in the kernel, drivers, privileged services, or applications can still be exploited after startup.

Secure boot primarily protects the startup trust chain. Runtime security requires additional protections.

27.4 The Root of Trust Must Remain Trustworthy

A compromised signing key, flawed verification implementation, or vulnerability in an early boot stage can undermine later security guarantees.

This is why the earliest stages are especially important and why hardware-backed key protection and carefully designed update mechanisms matter.

28. Boot Process Comparison Across Platforms

Platform	Typical early boot	OS-loading approach	Security model
Legacy PC	BIOS firmware	Boot sector and bootloader	Depends on additional protections
Modern Windows PC	Platform firmware and UEFI	Windows Boot Manager and OS Loader	UEFI Secure Boot, Trusted Boot, optional measured boot
Linux PC	UEFI or legacy firmware	GRUB, systemd-boot, EFI stub, or another loader	Configuration-dependent
Android smartphone	Boot ROM and vendor firmware	Device bootloader loads kernel and ramdisk	Hardware root of trust and device-specific verified boot
Qualcomm-based Android	PBL and XBL in documented architectures	Later firmware and Android bootloader	Qualcomm secure boot plus Android verification where implemented
Apple iPhone/iPad	Boot ROM and subsequent Apple boot components	iBoot loads the operating system	Apple-specific hardware-rooted chain of trust
Apple silicon Mac	Boot ROM, LLB	iBoot loads macOS components	Apple secure boot and LocalPolicy
Embedded Linux	ROM and optional SPL/TPL	U-Boot, UEFI, or direct kernel boot	Platform-dependent
Coreboot-based PC	Bootblock and subsequent stages	UEFI payload or another supported payload	Depends on firmware configuration and payload
Huawei HarmonyOS devices	Device-specific firmware	Proprietary and platform-specific	Must be established from device-specific evidence

The table presents representative architectures, not mandatory implementations. In particular, the presence of a Linux kernel or ARM processor does not determine which bootloader or security scheme a manufacturer uses.

29. Common Misconceptions

Misconception 1: Every device uses UEFI.

Correction: UEFI is widely used on modern PCs and some other platforms, but many embedded systems and smartphones use different boot architectures.

Misconception 2: The bootloader is always stored in ROM.

Correction: The earliest boot code may be immutable, but subsequent bootloaders are commonly stored in non-volatile memory and loaded into RAM for execution.

Misconception 3: Secure Boot and Verified Boot are the same technology.

Correction: They share security objectives, but the implementations, metadata, trust policies, and verification boundaries differ.

Misconception 4: AVB is responsible for authenticating every stage from power-on.

Correction: AVB is an Android verified-boot implementation integrated with the Android bootloader. The earlier firmware chain establishes the trust needed to reach that verification process.

Misconception 5: Every Qualcomm device uses exactly the same PBL → XBL → ABL sequence.

Correction: Qualcomm architectures differ across SoC generations and product configurations. Some documented boot flows include UEFI and additional trusted firmware between early boot and the operating system.

Misconception 6: A failed signature always sends a phone into EDL.

Correction: Failure behavior is platform-specific. A device may halt, try another boot slot, enter recovery, or use a specialized recovery path.

Misconception 7: An unlocked bootloader means that all security has been disabled.

Correction: Unlocking changes the acceptance policy for software. Other hardware protections and security mechanisms may remain active.

Misconception 8: A signed operating system cannot be vulnerable.

Correction: Cryptographic authentication does not guarantee that software is free from exploitable vulnerabilities.

Misconception 9: A partition table determines whether a system uses Secure Boot.

Correction: GPT and MBR describe disk organization. Secure Boot is a separate firmware authorization mechanism.

Misconception 10: All HarmonyOS devices use Android Verified Boot.

Correction: AVB is an Android-specific implementation. Claims about Huawei's production boot architecture require evidence for the relevant device and platform version.

30. Conclusion

The boot process is not a single program that starts an operating system. It is a sequence of hardware initialization, firmware execution, operating-system selection, and control transfers.

The earliest stages operate under strict resource limitations and may be responsible for establishing the platform's root of trust. Later stages can initialize more hardware, verify additional components, and prepare the operating-system kernel.

On modern PCs, UEFI provides a standardized firmware environment, and Secure Boot can enforce a policy for loading authorized EFI executables. Windows and Linux then use their respective loaders and operating-system initialization mechanisms.

On Android smartphones, the initial boot chain is usually more closely tied to the SoC and device manufacturer. Android Verified Boot provides a standardized approach to verifying operating-system images, while the Linux kernel, initramfs, and Android userspace complete the startup process.

Apple devices use Apple's own secure boot architecture, while embedded systems may combine Boot ROM, U-Boot, Trusted Firmware-A, coreboot, or UEFI in different arrangements.

Huawei HarmonyOS devices should be analyzed in the same careful way: distinguish the operating system from the firmware that loads it, and avoid asserting undocumented boot stages as facts.

The central principle is that boot architecture and boot security are related but separate design dimensions. Understanding a device requires identifying what executes first, how subsequent components are loaded, which components verify them, where trust is stored, and what happens when verification fails.

References and Further Reading

The following sources provide primary documentation for the concepts discussed in this article.

UEFI and PC Firmware

Windows

Linux and Embedded Firmware

Android

Qualcomm

Apple

Huawei and OpenHarmony

Note: Boot architecture is hardware- and version-dependent. Public documentation may describe a reference implementation rather than every detail of a commercial device. Vendor-specific stage names and security properties should be verified against documentation for the particular SoC and device being studied.