Fact-checked by Grok 2 weeks ago

Booting

Booting, also known as bootstrapping, is the startup process by which a computer system initializes its hardware components, performs diagnostic checks, loads the operating system kernel into memory, and prepares the device for user interaction and software execution. The term derives from the phrase "pulling oneself up by one's bootstraps," emphasizing the computer's ability to initialize itself without external assistance.^[1] This fundamental sequence ensures that the system's resources, such as the CPU, RAM, and storage devices, are properly configured before the operating system takes control.^[2] The process begins immediately upon powering on the device and is essential for transforming raw hardware into a functional computing environment.^[3] The booting sequence typically unfolds in several distinct phases. First, the power-on self-test (POST) runs to verify the integrity of core hardware like the processor, memory, and peripherals, often indicated by beeps or LED signals if issues arise.^[2] Next, the firmware—traditionally the Basic Input/Output System (BIOS) or its modern successor, the Unified Extensible Firmware Interface (UEFI)—initializes the hardware, checks the boot order of devices (such as hard drives, SSDs, or USB drives), and locates a bootable medium.^[3] The bootloader, a small program stored on the boot device, then loads the operating system files into random access memory (RAM), transferring control to the kernel, which completes the initialization of drivers and system services.^[4] This multi-stage handover ensures reliability, with UEFI offering advantages over legacy BIOS, including faster startup times, support for larger storage devices, and enhanced security features like digital signature verification.^[2] Modern booting processes incorporate security mechanisms to protect against malware and unauthorized modifications. Secure Boot, for instance, verifies the cryptographic signatures of the bootloader, kernel, and drivers before loading them, preventing rootkits or bootkits from compromising the system at startup. Additionally, optimizations such as fast boot modes—common in Windows and other OSes—reduce initialization time by resuming from a pre-saved hibernation state rather than performing a full cold boot.^[4] Booting can occur as a cold boot (full startup from a powered-off state) or warm boot (restart without cutting power), each tailored to different scenarios like troubleshooting or routine reboots.^[3] These elements collectively define booting as a critical, layered procedure that underpins all computing operations.

Fundamentals

Definition and Basic Process

Booting is the process by which a computing device transitions from a powered-off or reset state to a fully operational condition capable of executing user applications, achieved through the sequential loading and initialization of firmware and the operating system into memory.^[5] This bootstrapping mechanism, often referred to as "booting" due to the metaphorical idea of the system lifting itself up, ensures that essential hardware and software components are properly configured before control is passed to higher-level programs.^[6] The process differs between a cold boot, which starts from a complete power-off state and involves full hardware reinitialization including power-on self-test (POST), and a warm boot, which is a software-initiated restart (such as via a reset command) that skips some hardware checks to enable faster recovery without interrupting power.^[7] In a cold boot, all circuits are reset, and the system performs comprehensive diagnostics, whereas a warm boot retains certain initialized states for efficiency.^[8] The basic steps of booting begin with the central processing unit (CPU) receiving a reset signal, prompting it to load the reset vector—a predefined memory address containing the initial instruction for firmware execution.^[9] Firmware then runs the POST to verify and initialize hardware components, followed by the invocation of a boot loader, which serves as an intermediary to locate and load the operating system kernel into memory.^[5] Finally, the kernel takes control, completing hardware setup such as memory mapping and handing off execution to the operating system, enabling user applications to run.^[5] Hardware initialization plays a critical role in this sequence, with the CPU's reset vector directing the processor to firmware code that establishes initial memory mappings, configures interrupts, and prepares peripherals for operation.^[9] This ensures a stable environment for subsequent OS loading, preventing undefined states that could lead to system instability.^[5]

Key Components Involved

Firmware serves as the initial software layer executed upon system power-on, stored in non-volatile memory such as ROM, EEPROM, or flash to ensure persistence across power cycles.^[10] It performs essential hardware initialization, including configuring basic input/output devices, memory controllers, and interrupt systems, before transferring control to subsequent boot stages.^[11] This non-volatile code is critical for establishing a minimal execution environment, often handling power-on self-test (POST) routines to verify hardware integrity in a single pass.^[10] The boot device refers to the storage medium containing the boot loader and operating system files, such as hard disk drives (HDDs), solid-state drives (SSDs), or USB drives, from which the system loads initial software during startup.^[12] Firmware scans predefined boot devices in a priority sequence to locate a valid boot sector, ensuring the system can access the necessary code for OS initialization regardless of the storage technology employed.^[13] A boot loader is a compact program, typically residing in the boot sector of the boot device, designed to locate, load, and execute the operating system kernel into main memory.^[14] It operates with limited resources, often in real mode on x86 architectures, and may perform basic hardware probing or parameter passing to the kernel before relinquishing control.^[15] The kernel, as the core of the operating system, assumes control immediately after the boot loader, managing hardware resources through initialization of device drivers, memory allocation, and process scheduling.^[16] Once loaded into memory, it expands the system's capabilities by establishing protected execution modes, interrupt handling, and user-space interfaces, transitioning the machine from a bare-metal state to a fully operational environment.^[17] Interrupt vectors and reset mechanisms form the foundational CPU architecture elements that trigger the booting sequence. Upon reset—initiated by power-on or a hardware signal—the processor jumps to a predefined reset vector address, such as 0xFFFFFFF0h on x86 systems, where the first instruction of firmware resides.^[9] Interrupt vectors, stored in a dedicated table, enable the CPU to respond to hardware events by redirecting execution to specific handlers. The reset is a special asynchronous exception with the highest priority, ensuring reliable startup across diverse architectures.^[18]

Historical Evolution

Pre-Integrated Circuit Examples

In the 1940s and early 1950s, early electronic computers like the ENIAC relied on manual configuration for initial setup, as they lacked stored programs or automatic loading mechanisms. Programming and initialization involved physically wiring plugboards to connect accumulators, function tables, and constant transmitters, while hundreds of switches on the control panels were set to define operations and data paths. This process, which could take days for complex problems, effectively served as the "booting" by establishing the machine's configuration before computation could begin.^[19] Similarly, the Manchester Mark 1, developed in 1949, used a paper tape reader for loading initial programs into its Williams-Kilburn tube memory after manual setup of the control unit. Operators would feed punched paper tape containing the bootstrap code or application instructions through the reader at speeds up to 250 characters per second, with the machine executing the loaded code to initialize further operations. This electromechanical input method marked an early step toward automated loading from external media. First commercial computers in the 1950s, such as the UNIVAC I delivered in 1951, required significant operator intervention for startup. The process began with powering on the system and manually setting console switches to load a short bootstrap routine from magnetic tape, after which the operator would mount magnetic tapes containing the operating system or application. This manual entry ensured the mercury delay-line memory was cleared and ready for the initial program load, often involving verification steps to prevent errors in the storage.^[20] By the 1960s, the IBM System/360 introduced more structured initial program loading (IPL) using core rope memory in some configurations for fixed bootstrap code, combined with card readers for variable loads. Operators selected the IPL device via console switches, and the system read the first 24 bytes of code from cards or tape into core memory, executing it to load the full operating system like OS/360. Core rope memory, a woven wire technique providing read-only storage, held invariant parts of the loader, reducing manual entry while card readers enabled flexibility for different environments.^[21] Minicomputers of the 1960s and 1970s, exemplified by the PDP-8 introduced in 1965, typically featured front-panel toggle switches for entering a minimal bootstrap loader directly into core memory. Once toggled in—often a 20- to 40-word routine—the switches initiated the loader, which then read a binary program from paper tape via a high-speed reader, transferring it to memory for execution. This hybrid manual-electromechanical approach allowed the compact PDP-8 to boot without dedicated ROM, relying on operator precision to set addresses and data bits.^[22] The first microcomputers in the mid-1970s, such as the Altair 8800 released in 1975, extended this ROM-less design to hobbyist systems, where users entered the bootstrap loader byte-by-byte using the front panel's sense switches and deposit/examine controls. After manual entry of about 10 to 20 bytes to enable cassette or teletype input, the loader would fetch and verify the full program, such as 4K BASIC, from audio cassette tape. This labor-intensive process highlighted the transition from professional operator intervention to user-driven initialization in personal computing.^[23]

Integrated Circuit Read-Only Memory Era

The advent of integrated circuit read-only memory (ROM) in the late 1960s revolutionized booting in minicomputers by enabling permanent, non-volatile storage of essential startup code directly on the system board. Mask-programmed ROM chips, which were fabricated with the boot instructions hardcoded during manufacturing, replaced earlier manual methods and allowed for automated execution of diagnostics and loaders upon power-on. In Digital Equipment Corporation's PDP-11 series, introduced in 1970, modules like the M9301 incorporated such ROM containing diagnostic routines to verify hardware operation and multiple bootstrap loader programs to initiate system startup from various peripherals, such as tapes or disks. This integration streamlined the boot process, making minicomputers more reliable for scientific and engineering applications in the 1970s.^[24]^[25] The 1970s saw microprocessors incorporate single-chip boot ROMs, further miniaturizing and simplifying booting for early microcomputers. The Intel 8080, released in 1974, powered systems like the IMSAI 8080, where optional EPROM-based ROM monitors provided a basic command interface for loading programs from cassettes or disks, bypassing the need for tedious front-panel switch programming common in precursors like the Altair 8800. These ROMs typically included rudimentary I/O initialization to set up serial ports and memory mapping, enabling the system to communicate with external storage devices immediately after reset. This era's boot ROMs, often 2KB or smaller, marked the transition to self-contained firmware that could autonomously begin the operating system load. By the late 1970s and into the 1980s, microcomputers adopted erasable programmable ROM (EPROM) and one-time programmable (OTP) ROM for flexible, self-contained booting tailored to consumer needs. The Apple II, launched in 1977, featured a 12KB ROM monitor that executed on startup, performing memory tests, initializing the video display, and presenting a prompt for loading Integer BASIC or disk operating systems like DOS 3.3, which automated further boot stages. Similarly, the Commodore 64, introduced in 1982, used an 8KB KERNAL ROM for core boot functions, including vector table setup in RAM, screen initialization, and keyboard scanning to support immediate program loading from cartridges or disks. These advancements shifted booting from discrete logic assemblies—requiring wired panels or external programmers—to compact integrated firmware, drastically reducing user intervention and error rates.^[26] Key innovations during this period included self-relocating loaders embedded in ROM, which dynamically adjusted code addresses to fit available memory, and standardized I/O initialization sequences that configured peripherals like displays and storage controllers before OS handover. For instance, PDP-11 boot ROMs employed position-independent code to relocate loaders as needed during execution, while Apple II and Commodore ROMs integrated similar techniques to support variable memory configurations. This firmware evolution not only accelerated boot times to seconds but also laid the groundwork for scalable computing in education, business, and home use, contrasting the labor-intensive startups of pre-IC eras.

Boot Loaders

First- and Second-Stage Loaders

The first-stage boot loader is a minimal program residing in firmware or the initial boot sector of the storage device, executed immediately after the system's firmware, such as BIOS, completes its power-on self-test and identifies a boot device. Its primary role is to perform basic hardware initialization, access the boot medium (e.g., parsing the master boot record or volume boot record for disk geometry and partition information), and load the second-stage boot loader into memory before transferring control to it.^[27] Due to severe size constraints—typically limited to 446 bytes of executable code within the 512-byte master boot record sector—it contains only essential routines for device access and lacks advanced features like user interfaces or filesystem support.^[28] The second-stage boot loader, in contrast, is a larger, more capable program loaded by the first stage from a designated location on the boot device, such as the root directory of the active partition or post-MBR sectors. It handles higher-level tasks, including presenting a boot menu for operating system selection, configuring boot parameters, and loading the selected kernel and initial ramdisk into memory to initiate the OS handover.^[29] This stage often includes drivers for various filesystems and devices, enabling it to read configuration files and support multi-boot environments.^[27] Key differences between the stages stem from their design priorities: the first-stage loader emphasizes compactness and reliability under hardware constraints, focusing solely on transitioning to the next phase without error recovery or configuration options, while the second-stage loader prioritizes flexibility and user interaction, operating in protected mode with access to more memory and peripherals.^[28] For instance, the first stage may halt on errors like invalid disk geometry, whereas the second stage can provide diagnostic messages or fallback options. These distinctions ensure efficient bootstrapping, with the first stage bridging firmware and the richer environment of the second.^[29] Representative examples include the Linux Loader (LILO), where the first-stage loader occupies the MBR and loads the second-stage from the boot partition's initial sectors or /boot directory, verifying map files and displaying progress indicators like "LILO" during execution.^[28] Similarly, in pre-UEFI Windows systems, the NT Loader (NTLDR) serves as the second-stage boot loader; the first-stage code in the volume boot sector loads NTLDR from the root of the system partition, after which NTLDR reads boot.ini for OS options and loads ntoskrnl.exe.^[30] Another example is the legacy GRUB bootloader for Linux, with its Stage 1 as the first-stage loader in the MBR that chains to Stage 1.5 (a filesystem-capable intermediary) and then Stage 2 for menu-driven kernel loading.^[29] The chainloading mechanism operates sequentially: upon execution, the first-stage loader reads the second-stage binary from a predefined offset or partition, copies it to a safe memory address (often above 0x7C00), verifies basic integrity if possible, and executes a far jump to its entry point, passing any necessary parameters like disk identifiers via CPU registers.^[27] This handover ensures uninterrupted control flow, with the second stage assuming responsibility for subsequent initialization and OS invocation.^[29]

Multi-Stage and Embedded Loaders

Multi-stage boot loaders extend the architecture beyond two phases by incorporating three or more sequential stages, enabling greater modularity in initializing hardware and loading the operating system, particularly in resource-constrained embedded environments.^[31] These loaders divide the boot process into distinct phases, where each stage handles specific tasks such as basic hardware setup, memory configuration, and advanced device support, allowing for progressive complexity without overwhelming limited onboard resources.^[32] In typical multi-stage implementations, stage 0 resides in read-only memory (ROM) and performs minimal initialization to enable loading the next stage from non-volatile storage like flash. Stage 1, often called the Secondary Program Loader (SPL), initializes essential components such as synchronous dynamic random-access memory (SDRAM) and basic peripherals, then hands off to stage 2 or higher for more sophisticated operations like loading device drivers or network protocols.^[31] Subsequent stages, such as the full boot loader, manage operating system handover, supporting features like file system access and configuration prompts. This phased approach is exemplified in Das U-Boot, an open-source loader widely used for ARM-based embedded systems, where the Tertiary Program Loader (TPL) may precede SPL for even earlier initialization in systems with severe memory limitations.^[33] Similarly, Coreboot employs a staged process—stage 0 for core hardware init, stage 1 for device configuration, and stage 2 for payload execution—optimizing for low-resource devices by replacing proprietary firmware with a lightweight, customizable payload that can include boot loaders like U-Boot.^[34] Embedded loaders further adapt multi-stage designs for specialized, low-overhead environments, prioritizing efficiency in microcontrollers and system-on-chips. Coreboot's payload system, for instance, acts as an embedded loader by initializing hardware directly and executing a modular payload, such as a minimal OS kernel or secondary loader, thereby avoiding bloated proprietary code and enabling faster boots in constrained memory setups.^[34] Tianocore EDK II provides an extensible firmware framework compliant with UEFI Platform Initialization (PI) specifications, supporting multi-stage boot through modular drivers and initialization phases tailored for embedded platforms, allowing developers to build custom loaders with incremental hardware support.^[35] The primary advantages of these architectures include enhanced fault isolation, where failures in later stages do not compromise earlier, immutable ones, improving overall system reliability in embedded deployments.^[36] They also facilitate updatability by isolating updateable components in higher stages, permitting firmware enhancements or bug fixes without risking core initialization code, which is crucial for long-term maintenance in memory-limited devices.^[36] This modularity supports scalability, as additional stages can incorporate advanced features like secure partitioning without redesigning the entire loader.

Booting in Personal Computers

Boot Devices and Sequence

In personal computers, boot devices encompass various hardware media capable of storing the initial boot code and operating system files. Traditional boot devices include floppy disk drives, optical drives (such as CD-ROMs or DVDs), hard disk drives (HDDs), and network interfaces for remote booting via protocols like PXE.^[37] Modern systems expand this to solid-state drives (SSDs), USB flash drives, and high-speed NVMe SSDs connected via PCIe interfaces, reflecting advancements in storage technology and portability.^[38] The hierarchy of these devices is configurable in the firmware settings, typically prioritizing removable media for installation or recovery purposes before fixed internal storage.^[39] The boot sequence in personal computers follows a structured progression from hardware initialization to operating system loading. Upon power-on, the system's firmware activates and performs a power-on self-test (POST) to verify basic hardware functionality.^[40] Firmware then enumerates connected devices, scanning for bootable media according to the predefined priority order, such as USB devices first, followed by optical drives, internal HDDs/SSDs, and finally network options.^[39] Once a boot device is selected, the firmware reads the boot sector—either the master boot record (MBR) or equivalent—from the device's initial sector, loads the boot loader into memory, executes it to initialize further drivers and configurations, and hands off control to the operating system kernel, completing the boot process.^[41] Boot priority determines the order in which devices are attempted during startup, with fallback mechanisms ensuring continuity if the primary device fails. For instance, if the first-priority device (e.g., a USB drive) lacks valid boot code, the firmware proceeds to the next in sequence, such as an internal SSD, preventing complete boot failure.^[42] Users can override the default priority temporarily by pressing a designated key—commonly F12, F10, or Esc during POST—to access a one-time boot menu, allowing manual selection of a device like a recovery USB without altering permanent settings.^[43] This mechanism supports flexible troubleshooting, such as booting from external media for OS repairs. Partition tables play a crucial role in locating boot code on storage devices. The Master Boot Record (MBR) scheme, used in legacy BIOS environments, embeds a 512-byte boot sector at the disk's beginning, containing executable boot code alongside a partition table limited to four primary partitions and support for drives up to 2 TB.^[44] In contrast, the GUID Partition Table (GPT), standard for UEFI systems, stores the partition table across multiple reserved sectors for redundancy and places boot code in a dedicated EFI System Partition (ESP), enabling support for larger drives exceeding 2 TB and up to 128 partitions without size limitations.^[45] Firmware reads the appropriate table to identify and access the active boot partition during device enumeration. Error handling addresses scenarios where no valid boot device is detected, often manifesting as messages like "No bootable device" or "An operating system wasn't found." Common causes include disconnected or faulty storage hardware, incorrect boot priority settings, or corrupted boot sectors on the target device. Resolution typically involves verifying physical connections, entering firmware settings to readjust the boot order or enable legacy/UEFI modes, or booting from external recovery media to repair the master boot record using tools like those in Windows installation environments.^[46] If hardware failure is suspected, diagnostic tests via firmware utilities or replacement of the drive may be necessary to restore bootability.^[47]

BIOS Implementation

The BIOS, or Basic Input/Output System, is a 16-bit firmware embedded in the read-only memory (ROM) of the motherboard in IBM-compatible personal computers, providing low-level hardware initialization and interfacing services as defined in the IBM PC standard established in 1981. This firmware executes upon power-on, performing essential setup tasks before transferring control to the operating system loader.^[48] The boot process begins with the Power-On Self-Test (POST), a diagnostic routine that verifies the integrity of critical hardware components such as the CPU, memory, and basic peripherals.^[49] Upon successful completion of POST, the BIOS invokes interrupt 19h (INT 19h), its primary boot handler, which scans boot devices in a predefined sequence—typically starting with floppy drives, then hard disks, optical drives, and network interfaces if supported.^[50] For a hard disk boot, INT 19h uses the INT 13h disk services to read the Master Boot Record (MBR) from the first sector (sector 0, cylinder 0, head 0) of the device, loading its 446-byte bootstrap code into memory at physical address 0x7C00, followed by execution of that code after setting up the segment registers and stack.^[49] The MBR code then typically loads the volume boot record from the active partition to continue the chainloading process.^[51] BIOS operates exclusively in 16-bit real mode, imposing significant limitations on modern hardware support, including a maximum addressable disk size of 2 terabytes due to the 32-bit Logical Block Addressing (LBA) in its INT 13h extensions and the 512-byte sector assumption in the MBR partitioning scheme.^[52] It lacks native support for GUID Partition Table (GPT) structures, which exceed these constraints, requiring legacy BIOS systems to rely on compatibility modes or hybrid MBR setups for larger drives.^[53] To accommodate add-on hardware, BIOS supports Option ROMs—firmware modules stored on expansion cards (e.g., SCSI controllers or network adapters) that extend the core BIOS services by scanning for and executing their initialization code during POST in the memory range 0xC0000 to 0xF0000.^[54] The Plug and Play (PnP) BIOS extension, introduced in 1993, further enhances this by providing standardized interfaces for dynamic resource allocation to these ROMs and peripherals, reducing manual configuration needs through INT 0xF0 calls for enumeration and setup.^[55] Due to these architectural constraints, legacy BIOS has been progressively deprecated in favor of the Unified Extensible Firmware Interface (UEFI) in systems introduced after 2005, which offers 64-bit addressing, modular drivers, and broader hardware compatibility.^[56]

UEFI Implementation

The Unified Extensible Firmware Interface (UEFI) represents a modern firmware architecture for personal computers, succeeding the legacy BIOS by offering a modular, extensible interface between the operating system and platform hardware. Initially developed by Intel as the Extensible Firmware Interface (EFI) starting in the late 1990s for the Itanium processor family, the specification reached version 1.10 before Intel transferred stewardship to the UEFI Forum in 2005, an industry consortium including Microsoft, AMD, Apple, and others to promote cross-platform adoption.^[56]^[57] UEFI operates primarily in a 64-bit mode, supports larger address spaces than the 16-bit BIOS, and includes an interactive shell environment for diagnostics and scripting during boot, enabling more sophisticated pre-OS operations. The UEFI boot process unfolds in phases, with the Driver Execution Environment (DXE) phase being central to implementation on PCs, where firmware drivers initialize the processor, chipset, memory, and peripherals while establishing software abstractions for system services.^[58] Following hardware readiness, the Boot Manager—a firmware policy engine—enumerates boot options stored in NVRAM variables and presents a menu to the user, then loads EFI applications (typically bootloaders) as executable .efi files from the EFI System Partition (ESP), a dedicated FAT32-formatted partition marked with the GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.^[59]^[60] This modular approach allows drivers and applications to be loaded dynamically, contrasting the rigid, monolithic structure of BIOS. The process culminates in the operating system loader invoking ExitBootServices(), which notifies the firmware to cease boot-time resource management and transition control, committing memory allocations and preserving only runtime services.^[61] UEFI incorporates key features enhancing PC booting flexibility, including native support for the GUID Partition Table (GPT) to handle disks beyond the 2.2 TB limit of the Master Boot Record (MBR) scheme used in BIOS systems, enabling partitioning for modern storage capacities. It integrates Secure Boot as a verification mechanism using cryptographic signatures to ensure only trusted boot components execute, though detailed protocols are defined separately. Network booting is enabled through EFI protocols like the Simple Network Protocol (SNP) and PXE Base Code Protocol, allowing remote image loading over TCP/IP without local media. UEFI distinguishes boot-time APIs—such as memory allocation, event handling, and device path protocols available only until ExitBootServices()—from runtime APIs, which persist post-boot for tasks like variable storage, time synchronization, and ACPI table access, ensuring ongoing firmware-OS interaction.^[62] For backward compatibility with legacy BIOS-based operating systems and bootloaders, many UEFI implementations include the Compatibility Support Module (CSM), an optional component that emulates a 16-bit BIOS environment during boot, intercepting INT 13h disk calls and legacy option ROMs to facilitate hybrid operation.^[63] This module can be enabled or disabled in firmware settings, allowing seamless transition for systems requiring pre-UEFI support while prioritizing native UEFI mode for optimal performance and security.^[59]

Booting in Specialized Systems

System-on-Chips and Embedded Devices

System-on-chips (SoCs) integrate processors, memory controllers, and peripherals into a single chip, commonly used in embedded systems such as smartphones, IoT devices, and single-board computers like the Raspberry Pi, which employs an ARM-based Broadcom SoC. The booting process in these SoCs typically begins with an on-chip BootROM that executes immutable code upon power-up, initializing basic hardware and loading subsequent stages from external non-volatile memory like eMMC or NAND flash. This initial stage configures the memory controller and clock systems before handing off to a first-stage bootloader (BL1), often stored in secure on-chip ROM to prevent tampering. In ARM-based SoCs, such as those from Qualcomm Snapdragon series, the BootROM verifies and loads the primary boot loader (PBL), which handles further authentication and initialization of the system bus and security features.^[64]^[65] Secure booting is a critical aspect in SoCs, particularly those supporting ARM TrustZone, which partitions the system into secure and non-secure worlds to protect sensitive operations. The process starts in the secure world with BL1 authenticating BL2 (second-stage loader) using cryptographic signatures, ensuring only trusted firmware executes; this chain extends to loading the trusted OS or hypervisor before transitioning to the normal world for the main OS. Hardware accelerators, such as GPUs and neural processing units in Snapdragon SoCs, are initialized during these early stages to enable efficient multimedia and AI tasks post-boot. Constraints in SoCs include stringent power management, where boot code must minimize energy draw during initialization to comply with battery-limited designs, and real-time requirements that demand low-latency handoffs without user intervention.^[66]^[65]^[67] In resource-constrained embedded devices, booting often involves either bare-metal initialization or a real-time operating system (RTOS) like FreeRTOS, where the bootloader directly sets up peripherals, interrupt controllers, and timers without an underlying OS kernel. For instance, IoT sensors may boot via serial loaders or JTAG interfaces for initial programming, followed by autonomous execution from flash memory, prioritizing minimal footprint and deterministic timing. Automotive electronic control units (ECUs) exemplify this, using flash bootloaders to verify and update firmware over CAN bus, ensuring rapid startup to meet safety standards like ISO 26262, with no provision for manual recovery. In Android devices powered by SoCs, bootloader unlocking allows developers to modify the boot chain for custom ROMs, but this disables verified boot, potentially compromising security features like dm-verity. Multi-stage loaders, adapted for these environments, facilitate modular updates while maintaining integrity through hash chains.^[68]^[69]^[70]^[71]

Microcontrollers and FPGAs

Microcontrollers, such as those in the AVR and ARM-based families, typically initiate booting from internal flash memory upon power-on reset or external reset signals. The process begins with the hardware automatically fetching the initial instruction from a predefined address in the flash, often the reset vector, which points to either a built-in bootloader or the start of the user application code. In AVR microcontrollers, fuse bits—non-volatile configuration registers—allow selection of the boot loader section size and enable or disable the bootloader, determining whether the device jumps directly to the application code or enters a bootloader mode for in-system programming (ISP) updates via protocols like UART or SPI. For ARM Cortex-M based microcontrollers like the STM32 series, the boot process involves remapping the vector table, a data structure containing interrupt vectors and the initial stack pointer, from the default flash start address to support flexible code placement and optional bootloader execution for firmware updates over USB or other interfaces. This boot sequence in microcontrollers is designed for minimalism, often resulting in a direct jump to the application code without an operating system, enabling bare-metal execution where the firmware handles all hardware interactions. Optional bootloaders facilitate over-the-air or serial updates but can be bypassed for faster startup in production environments. Tools like OpenOCD provide debugging support by interfacing with JTAG or SWD ports to halt execution at the boot entry point, inspect memory, and program flash during development. In contrast, field-programmable gate arrays (FPGAs) undergo a configuration phase that defines their hardware logic before any software booting occurs, distinguishing them from microcontrollers' fixed firmware approach. Booting in FPGAs involves loading a bitstream—a serialized configuration file—into the device's configuration memory via interfaces such as JTAG, SPI, or serial PROMs. For Xilinx (now AMD) FPGAs, like those in the Artix or Spartan series, the configuration typically starts from an external SPI flash or PROM upon power-up, where the FPGA's startup circuitry reads the bitstream to instantiate logic cells, interconnects, and I/O blocks, followed by optional partial reconfiguration to update specific regions without full reload. This hardware definition phase precedes any microcontroller or processor soft-boot within the FPGA fabric, if present, emphasizing FPGAs' role in customizable, reconfigurable systems rather than static code execution. The key differences lie in their boot paradigms: microcontrollers focus on loading and executing fixed firmware directly from integrated memory for efficient, low-power operation in embedded applications, while FPGAs prioritize hardware synthesis through bitstream configuration, enabling dynamic logic adaptation but requiring more initialization time. Both often operate in OS-less environments, but FPGAs may integrate microcontroller cores (e.g., MicroBlaze) that then follow a secondary software boot similar to embedded loaders.

Security Considerations

Protective Measures

Protective measures in the boot process are designed to establish and maintain a chain of trust, preventing unauthorized modifications to firmware, bootloaders, and operating systems that could introduce malware or vulnerabilities. These techniques leverage hardware roots of trust, cryptographic verification, and secure storage to ensure only authenticated components execute during boot, thereby mitigating risks such as rootkits or supply chain attacks. By integrating protections at the hardware and firmware levels, systems can detect tampering early and halt execution if integrity is compromised. However, vulnerabilities such as CVE-2024-7344 (discovered in January 2025), which allows unsigned code execution in UEFI Secure Boot systems, and CVE-2025-3052 (June 2025), enabling bootkit malware by bypassing signature checks, highlight ongoing challenges; these have prompted updates to revocation databases like dbx and firmware patches from vendors including Microsoft and Intel.^[72]^[73] Secure Boot implements a cryptographic chain of trust starting from immutable read-only memory (ROM) and extending to the operating system loader. In UEFI Secure Boot, the platform firmware verifies digital signatures of boot components using a hierarchy of keys: the Platform Key (PK) as the root, which authenticates Key Exchange Keys (KEKs); KEKs in turn validate signatures in the allowed database (db); and the forbidden signatures database (dbx) revokes compromised or outdated components. This process ensures that only signed and trusted executables, such as bootloaders and drivers, are loaded, blocking unsigned or malicious code from executing. For example, Microsoft Windows requires Secure Boot for certain features, enforcing signature checks on the Windows Boot Manager and kernel. Measured Boot complements verification by creating a verifiable record of the boot process for remote attestation, using hardware modules like the Trusted Platform Module (TPM) to log measurements (hashes) of boot components into protected registers. These measurements capture the state of firmware, bootloaders, and the OS kernel, allowing a remote verifier to confirm that the system booted with approved software. Intel Trusted Execution Technology (TXT) employs a Dynamic Root of Trust for Measurement (DRTM) via the GETSEC[SENTER] instruction, which clears dynamic state and measures the environment before launching into a trusted mode, storing values in the TPM's Platform Configuration Registers (PCRs). Similarly, AMD's Secure Virtual Machine (SVM) uses the SKINIT instruction to initialize a late-launch environment, extending measurements to the TPM for attestation of the measured launch environment, including the secure kernel loader. Boot Guard provides a hardware-enforced root of trust specifically for firmware verification, integrated into Intel processors and chipsets to protect against attacks on the initial boot block (IBB). It establishes a Static Root of Trust for Verification (RTV) using fused keys in the processor, which cryptographically authenticate the firmware image before execution passes to the CPU. This prevents modification of the UEFI firmware or Option ROMs, ensuring the chain of trust begins immutably at the silicon level; for instance, in 12th-generation Intel Core processors, Boot Guard verifies the integrity of the firmware partition during the pre-boot phase. Encryption of boot partitions and full disks safeguards data at rest during the boot sequence, requiring authentication before decryption to prevent offline attacks. Microsoft's BitLocker employs full-volume encryption with AES algorithms, protecting the system partition and requiring pre-boot authentication via TPM or user PIN to unlock the Volume Master Key (VMK), which derives the Full Volume Encryption Key (FVEK). On Linux systems, LUKS (Linux Unified Key Setup) formats encrypted block devices, prompting for a passphrase in the initramfs during boot to decrypt the master key and access the root filesystem, often combined with TPM for automated unsealing if PCR values match expected boot measurements. Anti-rollback mechanisms prevent downgrade attacks by enforcing monotonic version increases for boot components, ensuring that once a security update is applied, older vulnerable versions cannot be reinstalled. In Secure Boot implementations, this is achieved through versioned signatures and the dbx database, which permanently revokes signatures of deprecated firmware or drivers, blocking their execution even if physically present. Hardware support, such as eFuses or monotonic counters in TPMs, stores the minimum acceptable version, halting boot if a rollback is detected; for example, in Trusted Firmware-M, anti-rollback checks the security version against OTP (one-time programmable) memory to prohibit execution of pre-patch images.

Bootloop Detection and Recovery

A bootloop occurs when a computing device repeatedly fails to complete the boot process, resulting in the system hanging or restarting indefinitely without user intervention, often due to corrupted firmware, faulty software updates, or hardware issues. This condition can trap the device in a cycle where the bootloader or kernel initialization repeatedly errors out, preventing normal operation. Detection of bootloops typically involves hardware and firmware mechanisms designed to monitor boot progress and identify failures. Watchdog timers, which are hardware circuits that reset the system if not periodically serviced by software, play a key role by triggering a reboot after a timeout during the boot sequence if the process stalls. In UEFI-based systems, firmware or bootloaders may use NVRAM variables to track boot attempts and detect repeated failures, depending on the implementation. Firmware health checks, such as integrity verifications during the boot stages, further aid detection by logging anomalies like checksum mismatches in boot images. Once a bootloop is detected, recovery mechanisms aim to restore functionality without requiring advanced user expertise. Common strategies include entering a safe mode that loads minimal drivers and services to diagnose issues, or initiating a factory reset through hardware key combinations like holding power and volume buttons on mobile devices. Rollback to a last known good state is another approach, where firmware or the operating system reverts to a previously verified boot configuration stored in secure partitions. Policies for handling bootloops often incorporate thresholds to balance automatic recovery with user intervention, such as exponential backoff delays between retry attempts to prevent excessive power drain or wear. In Android systems, verified boot with dm-verity enforces these policies by marking boot attempts as successful or failed, triggering recovery modes after repeated failures, depending on device configuration, to avoid infinite loops from tampered updates. Examples of bootloop recovery abound across platforms. Apple's iOS uses recovery mode, accessible via specific button sequences on iDevices, to restore firmware over USB from a connected computer if bootloops arise from update errors. Microsoft's Windows Automatic Repair feature, part of the Windows Recovery Environment, automatically scans for boot issues after detecting repeated failures and attempts repairs like restoring system files or resetting configurations. In embedded systems, watchdog resets provide a simple recovery by forcing a hardware reboot, often combined with firmware that clears volatile error states to break the loop. Secure Boot failures can occasionally trigger such detection as an entry point for these recovery processes.

References

[1]
What is a Boot And How Does The Boot Process Work? | Lenovo US
### Definition of Booting
[2]
Booting a Computer: Definition & Process - Lesson - Study.com
Jan 14, 2024 · Booting a computer refers to the process of powering on the computer and starting the operating system. The operating system is the program that ...What Is Booting a Computer? · Boot Process · Troubleshooting<|control11|><|separator|>
[3]
What is a Boot Sequence? - GeeksforGeeks
Jul 23, 2025 · A boot sequence, also known as boot process or booting, refers to the sequence of steps that a computer system goes through when it is powered on or restarted.
[4]
[PDF] Boot
✓Booting the system is done by loading the kernel into main memory, and starting its execution. ✓The CPU is given a reset event, and the instruction register ...
[5]
Operating Systems
The process of loading the operating system into memory is called bootstrapping, or booting the system. The word booting is used because, figuratively speaking, ...Missing: definition | Show results with:definition
[6]
[PDF] Unit 2
Cold Boot vs. Warm Boot. Page 39. 39. Cold Boot. RESET. POWER. OR. Page 40. 40. During Cold Boot: • All circuits are reset. • The computer performs the. Power ...
[7]
Princeton COS 318 : Course description - cs.princeton.edu
... cold boot or warm boot. Cold boot means you power down and power up the machine by pressing the power button of a PC. Warm boot means that you press <ctrl> ...
[8]
Introduction to Key Usage in Integrated Firmware Images - Intel
Oct 11, 2023 · The CPU processes the FIT before executing the first BIOS instruction located at the reset vector (address 0FFFFFFF0h). If a microcode ...
[9]
[PDF] ECE 531 – Advanced Operating Systems Lecture 4
Sep 10, 2025 · Often in ROM/EEPROM/FLASH • Boot firmware initializes system. Init RAM? Set it up (often over i2c), clear out random or old contents (if a soft ...
[10]
[PDF] Boot Loader Choices for Small and Fast System Initialization ... - Intel
This article provides an overview of the Intel architecture system initialization solutions, which include custom boot loaders and Basic Input/Output System ( ...
[11]
https://www.intel.com/content/dam/www/public/us/en/documents/articles/boot-loader-choices-small-fast-requirements-article.pdf
[12]
What Is a Boot Device? - Computer Hope
Jul 9, 2025 · A boot device is any piece of hardware containing the files required for a computer to start. For example, a hard drive, floppy disk drive, CD-ROM (compact ...Creating a bootable disc or drive · No boot devices available
[13]
What is a Boot Loader (Boot Manager)? - TechTarget
Jul 9, 2024 · A boot loader (boot manager) is a small program that places the operating system (OS) of a computer into memory.
[14]
Lab 1: Boot loader - Texas Computer Science
Its job is to load the operating system in memory and start it executing. The code you will write in this lab will be used for the remainder of the semester.
[15]
[PDF] What is an operating system?
The operating system kernel assumes control of the computer at boot time and remains in command as the system runs. The kernel periodically relinquishes control ...
[16]
2.3. Kernel Mechanics — Computer Systems Fundamentals
The kernel is a program that runs with full access privileges to the entire computer. The kernel controls access to all shared system resources.Missing: definition | Show results with:definition
[17]
[PDF] From last lecture Today's topics Today s topics Terminology
Jump to “reset vector” address ... Interrupt & reset. PROCESSOR. CORE. RESET. INTERRUPT ... ▫ Interrupt mechanism allows efficient use of CPU cycles by.
[18]
A Logical Coding System Applied to the ENIAC
The procedure for instructing the ENIAC in its routine, then, consists, in local programming, of setting program switches on the units so that, when stimulated ...Missing: initialization | Show results with:initialization
[19]
Univac I Computer System, Part 1
It contains technical information of how UNIVAC I really worked. This includes the mercury delay line main-memory and the computational and control circuits.
[20]
[PDF] Systems Reference Library IBM System/360 System Summary
This publication provides basic information about the IBM System/360; its objective is to help readers achieve a general understanding of this.
[21]
[PDF] PDP-8 Family Paper Tape System User's Guide
The first section explains the use of switches and indicators on the computer, Teletype, high-speed paper tape reader/punch, and DECtape transport consoles, and ...
[22]
Bootstrapping The Old Fashioned Way - Hackaday
Sep 9, 2022 · You had to toggle in the bootstrap loader, so the program of interest could be loaded from paper tape. Most commonly for us that was FOCAL – an ...
[23]
[PDF] PDP-11/34 system user's manual - Your.Org
The ROM in the M9301 contains diagnostic routines for verifying computer operation, several boot- strap loader programs for starting up the system, and the ...
[24]
http://ftpmirror.your.org/pub/misc/bitsavers/www.computer.museum.uq.edu.au/pdf/EK-11034-UG-001%2520PDP-11-34%2520System%2520User%2527s%2520Manual.pdf
[25]
[PDF] Apple II 00-S Use~ Manual ------- ---
The Monitor program reads DOS into memory and then lets DOS control communication. The Startup Process. When you turn on your Apple computer, several electrical ...
[26]
3.4: Reading- Booting - Workforce LibreTexts
Nov 13, 2021 · Also, a boot ROM is often able to load a boot loader or diagnostic program via serial interfaces like UART, SPI, USB and so on. This feature ...
[27]
From Power Up To Bash Prompt: Lilo
When the computer loads a boot sector on a normal Linux system, what it loads is actually a part of lilo, called the ``first stage boot loader''. This is a tiny ...
[28]
lilo(8): install boot loader - Linux man page
When the second stage loader has received control from the first stage, it prints the letter "L", and when it has initialized itself, including verifying the " ...
[29]
GNU GRUB Manual 0.97
Briefly, a boot loader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to an operating ...
[30]
troubleshoot "NTLDR Is Missing" error - Windows - Microsoft Learn
Jan 15, 2025 · This step-by-step article describes methods that you can use to troubleshoot the "NTLDR Is Missing" error message that you may receive when you try to start ...Missing: XP | Show results with:XP
[31]
Booting from TPL/SPL — Das U-Boot unknown version documentation
TPL (Tertiary Program Loader) loads SPL (Secondary Program Loader) which sets up SDRAM and loads U-Boot. TPL is very early init. SPL loads U-Boot proper.
[32]
3.1. U-Boot — Processor SDK Linux Documentation
The SPL is the first stage of U-Boot, and must be loaded from one of the boot sources into internal RAM. The SPL has very limited configuration or user ...
[33]
U-Boot overview - stm32mpu - ST wiki
Das U-Boot ("the Universal Boot Loader" or U-Boot) is an open-source bootloader that can be used on STMicroelectronics boards to initialize the platform and ...U-Boot overview · U-Boot configuration · U-Boot command line interface...
[34]
coreboot
coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems.Coreboot Releases · Coreboot · The coreboot documentation · For End UsersMissing: payload | Show results with:payload
[35]
What is TianoCore?
EDK II is a modern, feature-rich, cross-platform firmware development environment for the UEFI and UEFI Platform Initialization (PI) specifications. We hope ...Getting Started · Latest News · Documentation · How to ContributeMissing: process | Show results with:process
[36]
Bootloaders in embedded system: Architecture and Features
While single-stage bootloaders are straightforward and suitable for simple systems, multi-stage bootloaders provide enhanced flexibility, security, and ...Bootloader With Dfu · Bootloader Features · Popular Bootloaders In...
[37]
2. Overview — UEFI Specification 2.10 documentation
The PC-AT-class systems today are restricted to boot from the first floppy, hard drive, CD-ROM, USB keys, or network card attached to the system.
[38]
[Motherboard] How to set the boot device priorities on the motherboard
May 9, 2024 · Through the BIOS setting function, we can adjust the priority of boot devices, including M.2 SSD, SATA SSD, USB and other storage devices.
[39]
correct or recommended boot order. - Microsoft Q&A
Dec 10, 2023 · OS Boot Manager · Internal CD/DVD ROM drive · USB flash drive /USB hard drive · USB CD/DVD ROM drive · Network adapter.
[40]
[PDF] BIOS Boot Specification - Stanford Secure Computer Systems Group
Jan 11, 1996 · This boot order is similar to the common feature of boot A: then C: or vice versa, but supports additional IPL devices.
[41]
The BIOS/MBR Boot Process - NeoSmart Technologies
Overview of the BIOS/MBR Boot Process. In the diagram below, the boot sequence for all standard computers and operating systems is shown: MBR Boot Sequence.
[42]
How to Change Between UEFI and Legacy Boot Options on Intel ...
Power on system. Press F2 when prompted to enter BIOS menu. Navigate to Boot -> Boot Order. Select the desired mode: UEFI or Legacy (if available).
[43]
Hot keys for BootMenu / BIOS Settings - Active@ Disk Image
You may get your Boot Menu How or your BIOS settings by using special keys. Below is a list of PC brands with their corresponding hot-keys.
[44]
Windows Setup: Installing using the MBR or GPT partition style
Dec 15, 2021 · The GPT drive format lets you set up drives that are larger than 4 terabytes (TB), and lets you easily set up as many partitions as you need.
[45]
Windows and GPT FAQ - Microsoft Learn
GPT provides a more flexible mechanism for partitioning disks than the older Master Boot Record (MBR) partitioning scheme that was common to PCs. A partition ...
[46]
Resolve No Bootable Device Found Error in Legacy Mode on Dell ...
The No boot device Found error appears when the Boot sequence is set to Legacy mode or the operating system is installed under Legacy mode.
[47]
Surface turns on and shows "Couldn't find a bootable operating ...
When you turn on your Surface, it displays the following message: Couldn't find a bootable operating System. Check the Boot Configuration to try to fix this.
[48]
[PDF] System BIOS for IBM® PCI)(TrMIAT® Computers and Compatibles
Page 1. Page 2. Technical Reference Series. System BIOS for. IBM® PCI)(TrMIAT ... INT 1Oh Video Service Data Definitions ...
[49]
[PDF] in IBM's PS/2 and PC BIOS Interface Technical Reference
This technical reference provides Basic Input/Output System (BIOS) and Advanced BIOS (ABIOS) interface information. It is intended for developers who provide ...
[50]
Programmer's Technical Reference for MSDOS and the IBM PC
If no floppy drive or option ROM is found, the BIOS calls int 19h (ROM BASIC if it is an IBM) or displays an error message. If a bootable disk is found, the ...
[51]
Understanding MBR/BIOS and GPT/UEFI | Macrium Software
Jan 19, 2022 · The 2TB limit is due to the MBR having 32-bits to address sectors on the storage media, with a standard sector size of 512 bytes, the maximum ...
[52]
Support for Disk Drives Beyond 2.2 TeraBytes (TB) and 4K ...
Windows systems with Legacy BIOS and MBR boot drives are limited to 2.2TB partitions; Windows XP does not support GPT; Windows XP sees a 3TB drive as 800GB on ...
[53]
[PDF] Boot Mode Considerations: BIOS vs UEFI - Dell
This paper helps system administrators understand the implications of each boot mode. First, the paper explains the limitations of the traditional BIOS that ...
[54]
[PDF] BIOS Boot Specification - Stanford Secure Computer Systems Group
Jan 11, 1996 · If a Legacy IPL device traps INT 19h it takes control of the boot process. This is acceptable because it is consistent with what. Legacy systems ...
[55]
[PDF] Plug and Play BIOS Specification v1.0a - OSDever.net
May 5, 1994 · This new interface will help couple the system BIOS closely with the Plug and Play option ROM to assist the system BIOS in completing the POST ...
[56]
Unified Extensible Firmware Interface - Intel
Sep 6, 2019 · Modules cover the boot phases of UEFI and Platform Initialization (PI) from power-on to booting an OS, with the objective of aiding ...
[57]
Specifications | Unified Extensible Firmware Interface Forum
Access to the UEFI Specifications. The UEFI Specifications identified below are available for downloading and to read only.
[58]
2.1. Driver Execution Environment (DXE) Phase - UEFI Forum
The DXE phase and Boot Device Selection (BDS) phases work together to establish consoles and attempt the booting of operating systems. The DXE phase is ...Missing: sequence | Show results with:sequence
[59]
3. Boot Manager — UEFI Specification 2.10 documentation
The UEFI boot manager is a firmware policy engine that can be configured by modifying architecturally defined global NVRAM variables.
[60]
UEFI firmware requirements
### Summary of Boot Devices, Priority, and Sequence in Windows PCs
[61]
7. Services — Boot Services — UEFI Specification 2.9A documentation
In principle, the ExitBootServices() call is intended for use by the operating system to indicate that its loader is ready to assume control of the platform ...
[62]
Runtime Services — UEFI Specification 2.10 documentation
In principle, the ExitBootServices() call is intended for use by the operating system to indicate that its loader is ready to assume control of the platform and ...
[63]
UEFI requirements for Windows editions on SoC platforms
Mar 23, 2023 · This article describes UEFI requirements that apply to Windows 10 for desktop editions (Home, Pro, Enterprise, and Education).
[64]
How does ARM boot? - FEDEVEL
Step 1: Internal bootloader. Based on bootstrap resistors (or/and eFuses) an internal bootloader (stored in CPU ROM) determines what peripheral will be used ...<|control11|><|separator|>
[65]
Analysis of Qualcomm Secure Boot Chains - Quarkslab's blog
Oct 24, 2019 · Qualcomm's secure boot chain includes bootROM (PBL), SBL (XBL), Secure Monitor (QTEE), and aboot (ABL), where each stage loads, authenticates, ...
[66]
Secure boot - Arm Developer
This document provides an overview of the ARM TrustZone technology and how this can provide a practical level of security through careful System-on-a-Chip ...
[67]
Booting a secure system - Arm Developer
This document provides an overview of the ARM TrustZone technology and how this can provide a practical level of security through careful System-on-a-Chip ...
[68]
Boot Sequence for an ARM based embedded system - DM
Jan 16, 2012 · This post is going to explore the boot sequence for a Boot ROM based embedded system. It is based on my experiences with an ARM processor based embedded system.Missing: Chip | Show results with:Chip
[69]
Development on Bare Metal vs. RTOS - SYSGO
Apr 5, 2022 · In contrast to bare-metal programming, RTOS-based embedded systems ... An RTOS will usually require seconds for the boot process.
[70]
Understanding What is Flash Bootloader | ECU Reprogramming
May 27, 2019 · A flash bootloader is a software algorithm executed during system boot-up, that facilitates ECU software updates and automates flash ...
[71]
Lock and unlock the bootloader | Android Open Source Project
Oct 9, 2025 · To unlock the bootloader and enable partitions to be reflashed, run the fastboot flashing unlock command on the device.