Bootloader

When a device does not start, application logs are often the first place people look.

Some failures happen much earlier: there is no serial output, main() is never reached, a HardFault fires immediately after reset, a bootloader jumps to the kernel and nothing happens, or an exception handler is never reached at the expected address. These are usually not business-logic bugs. The CPU has not yet entered a stable software execution environment.

When an embedded Linux 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, enters the bootloader, loads the Linux kernel, Device Tree, and rootfs-related information, waits for the kernel to reach user space, and only then reaches the application.

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.