Typical-Bootup-Sequence

Bootloader

The bootloader is the very first piece of software that runs when a system powers on. Its primary job is to perform initial hardware setup and then load the main operating system. It does the following:

  • Initializes critical hardware: It sets up the CPU clocks, memory controller, and RAM
  • Loads the OS: It finds the operating system kernel (or a bare-metal application) in storage (like Flash memory or an eMMC) and copies it into the main system memory (RAM).
  • Hands over control: Once the OS is in RAM, the bootloader jumps to the OS’s starting address and gives it control of the CPU.

U-Boot is the most popular bootloader for embedded Linux systems. It’s powerful, configurable, and supports a vast range of hardware. Barebox is a modern alternative to U-Boot. Many simple microcontrollers come with a small, built-in proprietary bootloader from the manufacturer.

Board Support Package (BSP)

A BSP is the bridge between the hardware and the software (like a bootloader or OS). An OS like Linux is designed to be general-purpose, but the hardware it runs on (the “board”) is very specific. The BSP contains all the specific code needed to make the generic OS work on that particular board. The BSP is what makes an OS portable. To run Linux on a new board, you don’t rewrite Linux; you write a new BSP for that board.

It contains the following:

  • Device Drivers: Code that controls the specific peripherals on the board (e.g., UART for serial communication, I2C for sensors, Ethernet, etc.).
  • Initialization Code: Functions to configure the specific System-on-Chip (SoC) and its components.
  • Memory Map: A definition of how memory is laid out for this specific board.
  • Toolchain and Configuration: Scripts and files needed to build the software for the target hardware.

Operating System (OS)

The Operating System is the master software, loaded by the bootloader, that manages all the system’s resources. It schedules tasks, manages memory, and provides an API for the main application to run. In embedded systems, the choice of OS is critical and depends entirely on the application’s requirements. Broadly there are two types of OS:

b) General-Purpose Operating System (GPOS)

A GPOS is designed for fairness and high throughput. Its main goal is to provide resources to many applications and users in a balanced way, maximizing overall system performance. Performance and resource management are the key features. It ensures no single task starves the others, but it makes no guarantees about when a specific task will finish. Examples: Embedded Linux (built with Yocto or Buildroot), Android.

a) Real-Time Operating System (RTOS)

An RTOS is designed for determinism and predictability. Its main goal is not speed, but guaranteeing that tasks are completed within a strict, predefined time deadline. In RTOS, missing a deadline is considered a system failure. Examples of RTOS are: FreeRTOS, Zephyr, VxWorks. Few Use Cases where RTOS is required are Car braking systems, medical devices, factory robots, flight controllers.

Bare-Metal (No OS)

For very simple devices, you might not use an OS at all. In this case, your application code runs directly on the hardware in a single loop (while(1)). The bootloader would load this application directly.

Here is the typical boot-up sequence showing how the above relate:

  1. Power On: The CPU starts executing code from a fixed location.
  2. Bootloader Runs: This is the code at that fixed location. It uses basic drivers from the BSP to initialize RAM.
  3. Bootloader Loads OS: It copies the OS (e.g., a Linux kernel or a FreeRTOS application) from Flash memory into RAM.
  4. Bootloader Hands Off Control: It jumps to the start of the OS code.
  5. OS Initializes: The OS takes over, initializes the rest of the system, and loads all its drivers from the BSP to manage all the board-specific hardware.
  6. Application Runs: The OS starts the main application code.