When a device boots slowly, an application does not start, a driver does not load, or a network service fails, people often jump straight to application logs.
But the application is only the last part of the boot chain. After power-on, the CPU does not directly jump to business logic. It starts from a fixed entry, initializes the minimal hardware environment, finds the next-stage image, loads an OS or RTOS, initializes memory, devices, and scheduling, and only then reaches the application.
The safest first model is this: boot is not one function call. It is a staged handoff chain. Each stage brings the system to a state where the next stage can run.
power-on/reset
-> ROM or reset vector
-> early startup code
-> bootloader
-> kernel or RTOS
-> root filesystem / task initialization
-> init / service manager
-> application starts
Platform details vary, but the “each stage prepares the next stage” line is stable.
Where the CPU Starts After Reset
After power-on or reset, the CPU does not randomly search for code. It starts at the reset entry defined by the architecture and chip.
That entry may be:
- internal chip ROM
- flash at a fixed address
- reset handler in a vector table
- boot media selected by Boot ROM based on pins or fuses
The earliest code can rely on very little. The memory controller may not be initialized, stack may not be ready, clocks may still be at default rate, and peripherals are not configured.
Early startup code usually does minimal work:
- set up stack
- initialize clocks
- initialize SRAM or DRAM
- disable or configure watchdog
- set interrupt vector table
- clear BSS section
- prepare C runtime
- jump to the next stage
That is why early boot problems are hard to debug. Debug tools, serial logs, and even memory may not be ready yet.
What the Bootloader Solves
The bootloader’s job is not to run business logic. It brings the system to a state where it can load the operating system or main firmware.
It commonly handles:
- DRAM initialization
- storage controller initialization
- loading images from flash, eMMC, SD, network, or USB
- image integrity checks
- boot partition selection
- update rollback
- boot arguments or next-stage entry information
- jump to kernel or application entry
In complex systems, the bootloader may load a kernel, board description, and filesystem-related information. In MCU/RTOS systems, it may only handle firmware update, verification, and jump to the application.
So the bootloader is a handoff stage. It must understand both the hardware boot media and what the next stage needs.
What the Operating System Does After Handoff
After the bootloader jumps to the next stage, that stage has to build the real runtime environment. In Linux-like systems, the kernel initializes memory, interrupts, the scheduler, the driver model, and the user-space entry. In RTOS systems, the kernel initializes the scheduler, timers, interrupts, task control blocks, queues, heap, and static tasks, then starts scheduling.
The details differ, but the shared requirement is stable: before the application can run, the system must prepare CPU execution state, memory management, clocks and interrupts, basic devices, and task scheduling.
If the system is stuck here, the application often has not executed yet. Check serial logs, exception evidence, boot-stage output, whether the scheduler started, whether tasks were created, and whether critical peripherals initialized before changing application logic.
What the Application Depends On Before It Can Run
“Application start” means different things on different systems.
In RTOS or bare-metal systems, business tasks are often part of the firmware. After startup code completes, the system creates tasks, starts the scheduler, and those tasks begin running.
In Linux systems, applications usually wait for the kernel to finish initialization, mount rootfs, start init or a service manager, and then launch services by dependency. Device nodes, data partitions, network, permissions, and configuration can all decide whether the application is actually usable.
So a boot failure should not only be phrased as “why did the application not start.” A better question is whether the system conditions the application depends on were ready.
Why Update and Rollback Belong to Boot
Devices do not only boot once. They often support OTA, dual partitions, rollback, and secure boot.
That adds decisions to the boot chain:
- boot A partition or B partition
- whether the new image passes verification
- whether the previous boot was marked successful
- whether failure count exceeded threshold
- whether to roll back to old version
- whether signature or hash is trusted
These decisions usually happen in the bootloader or early user space.
If this layer is not robust, the device may:
- fail to boot after update
- flip between old and new versions
- brick after boot marker corruption
- bypass security verification
- get stuck in a half-updated state after power loss
Boot is not only “run the system.” It decides which version to run and whether there is a recovery path.
Debug Boot Problems by Locating the Stage
The worst way to debug boot is to modify the application first.
First locate the stage:
- no logs at all: power, reset, clock, boot media, early ROM, or serial setup
- bootloader logs exist: image loading, verification, partition choice, and boot arguments
- operating system starts printing: memory, exceptions, interrupts, clocks, and critical device initialization
- scheduler or user-space entry started: tasks, services, dependencies, permissions, and configuration
- application started but business unavailable: network, peripherals, database, config, application logs
Each stage has different observation points. Once the stage is known, the problem scope shrinks quickly.
What to Remember in Practice
From power-on to application start, the device does not jump straight to business code. It runs through a handoff chain.
Early startup prepares the minimal runtime environment. The bootloader loads and selects the next stage. The operating system establishes scheduling, memory, interrupts, and device models. The application becomes usable only after its system dependencies are ready.
For boot problems, ask:
- did the CPU reach the reset entry
- did the bootloader load the correct image
- are boot arguments and the next-stage entry correct
- did the operating system finish critical initialization
- did the scheduler, tasks, or user-space entry start
- are application dependencies satisfied
Splitting the boot chain by stages turns “the device did not start” into a path that can be verified step by step.