In the last blog, we discussed different ways or methods of updating applications in electronic devices and the potential losses for product owners in case of failure. Today, right from low-end microcontroller-based devices such as instrument clusters to high-end processors such as mobile phones, firmware upgrades are essential. Designing a robust and fail-safe bootloader architecture is therefore crucial. Normally DFU (Device firmware upgrade) features are part of bootloaders in embedded system designs. There are plenty of bootloaders available in the market such as U-boot, Barebox, BURG, Clover, Coreboot, GNUGRUB, LILO, RedBoot, rEFInd, Smart BootManager, Syslinux, systemd-boot, Tianocore EDK2, U-Boot, UEFI EDK2, xOSL, Yaboot etc. to support DFU. In this blog, we will cover bootloader architecture, stages, bootloader features, and bootloader security for ready-to-use solutions available in the market. Embien's edge computing services include bootloader architecture design for resource-constrained and safety-critical embedded systems.
Bootloader architecture
The booting sequence of an electronic product has the following 5 stages:
- Reset: Device powered on or reset. System initializes internal circuits.
- Read Boot Pins: The device reads the boot pins to determine the boot source.
- Load Bootloader: Based on the boot source, the MCU/MPU loads the bootloader into RAM. This might involve reading from internal flash, external memory, or another source.
- Bootloader Execution: The bootloader initializes hardware, verifies firmware integrity (possibly using OTP-stored keys), and then loads the main application firmware.
- Main Application: The main application firmware is executed, which takes over control of the device operations.
The above sequence has mainly below 3 components:
- ROM Bootloader
- Bootloader with DFU
- Application
Let's see each component of the bootloader architecture in detail.
ROM Bootloaders in embedded system
A ROM bootloader is a piece of code programmed into the read-only memory of an embedded device by chip manufacturers. That code is the very first software executed after the chip is powered. One of the main functionalities of this code is to detect the boot source by reading boot pins or OTP (One Time Programmable) memory and proceed with loading the next software. This is a fixed component of any bootloader architecture — it cannot be modified after production.
Boot Source Configuration – Boot PinsUsually, there are specific BOOT pins in the chip dedicated for boot source selection. A specific combination of high (1) and low (0) levels on these pins at reset or power-on determines the boot source. For example:
BOOT0 = 0, BOOT1 = 0: Boot from internal flash.
BOOT0 = 1, BOOT1 = 0: Boot from external flash.
BOOT0 = 0, BOOT1 = 1: Boot from USB.
BOOT0 = 1, BOOT1 = 1: Boot from SD Card.
This configuration allows developers to select different boot options for development, testing, or production without changing the firmware.
Boot Source Configuration - OTP FlashIn some processors, OTP (One-Time Programmable) Flash is used to configure the boot medium. These settings are configured in OTP to prevent unauthorized modifications of the boot medium post-production. As the code is in read-only memory, it is programmed into the chip once during production. Developers cannot modify this program.
The above 2 configurations mostly go together. If OTP is not flashed, the device takes the BOOT pins configuration. Otherwise, the device boots with the configured boot medium in OTP.
Bootloader with DFU
This is the second software executed after powering on the electronic product following the ROM Bootloader. Its main responsibility is to initialize basic hardware peripherals, run diagnostics, load the application to RAM, and launch the application. The bootloader architecture at this stage defines how the system handles firmware integrity, rollback, and update.
There are 2 types of bootloader architecture designs:
- Single Stage Bootloader
- Multistage Bootloader
A single-stage bootloader is used mainly for a system where sufficient memory is available and there is no need for complex initialization. It's a straightforward bootloader architecture where the bootloader performs all necessary initializations and directly loads the main application firmware from non-volatile memory (such as flash memory) into RAM for execution or execute in place (XIP). This type of bootloader is typically small and simpler in design.
Single Stage Bootloader
Multistage Bootloader
This Multistage bootloader architecture is used in products where memory is constrained or where complex initializations such as partition tamper validation, application decryption, and custom DFU implementation are needed.
Multi Stage Bootloader
There are mostly 2 stages in this bootloader architecture:
- In the first stage, the system initializes basic chip peripherals, external peripherals such as EEPROM, RTC, CAN etc., flash and DRAM required for the second stage bootloader. It then loads the second bootloader firmware onto DRAM and executes it. This is typically small (less than a few KB) and fits into on-chip SRAM.
- The second stage bootloader is equipped with many bootloader features such as hardware peripheral tests, validating the integrity of the application, and selecting the right application based on boot configuration. The second stage bootloader is scalable, allowing for future expansion and updates without significant architecture changes. It can load applications from other media types as well.
Bootloader Features
Modern bootloaders are equipped with bootloader features such as secure booting, encryption/decryption, tamper detection, secure storage, file system support, boot logo, DFU, Network boot, CLI, and Built-in Self-test. Bootloader development for embedded systems involves selecting and implementing the right combination of these bootloader features based on product requirements. We will see a few of them below.
File system supportThis bootloader feature enables the bootloader to interpret file systems such as FATFS, NTFS, EXT4, JFFS to locate and load firmware or other necessary files during the boot process. It is useful in systems where firmware or configuration data is stored on external storage devices like SD cards or USB devices.
Boot logoThis bootloader feature provides feedback to users on current boot progress by displaying an image or animation on the screen and product branding. It improves the user experience as devices seem responsive as soon as they are switched on.
Device Firmware UpdateThis bootloader feature is responsible for upgrading the application for bug fixes and adding new features. Multiple modes are used as per hardware interfaces available: USB DFU, Network DFU, Serial DFU. This feature takes care of receiving the new application, verifying it, and flashing the same on device memory.
Network BootThis involves loading and running an operating system or software over a network connection using protocols such as TFTP. This is very helpful for development purposes as it typically loads the software to RAM directly without updating the firmware permanently stored in flash.
Command Line InterfaceCLI is a powerful bootloader feature for interacting with and controlling the bootloader environment. This interface allows developers and advanced users to perform tasks such as configuring boot parameters, debugging, and performing system updates.
Secure bootBootloader security through secure boot ensures that only trusted applications are loaded during the boot process. This procedure involves verifying the digital signature of the application against a manufacturer-configured certificate. In case of verification failure, the system halts, preventing execution of potentially malicious code. Bootloader security is increasingly important for connected embedded products.
Tamper DetectionThis bootloader security feature alerts the system whether the firmware has been altered. Bootloader security at this level is achieved by using checksums, hash functions, or more advanced integrity verification techniques leveraging hardware security engines. Robust bootloader security through tamper detection is a key requirement in automotive and industrial bootloader architecture designs.
Popular Bootloaders in embedded system
Below are a few open source and commercial bootloaders available in market. Bootloader development for embedded systems often starts with one of these proven platforms before customizing for product-specific bootloader features and bootloader security requirements. RapidSea is Embien's commercial bootloader with small footprint, boot logo, security validation, and DFU — purpose-built for resource-constrained environments with UI.
| Name | Description | Features | License |
|---|---|---|---|
| U-Boot | This is a widely used open-source bootloader that supports many processor architectures including ARM, x86, MIPS, and PowerPC. | Advanced bootloader features such as network booting, USB support, file system are supported | GPL |
| Coreboot | Formerly known as LinuxBIOS, it is a software project aimed at replacing proprietary firmware found in most computers with a lightweight firmware. | Minimalistic and fast boot times | GPLV2 |
| GRUB (Grand Unified Bootloader) | A bootloader package from the GNU Project primarily designed to boot multiple operating systems and support various file systems. | Highly configurable, supports scripting, and can boot various operating systems. | GPL (GNU General Public License) |
| Barebox | A versatile and flexible bootloader, not only for booting embedded Linux systems, but also for initial hardware bring up and development. | Device tree support, scripting capabilities, network boot, and USB support | GPL-2.0 |
| Redboot | Uses the eCos real-time operating system Hardware Abstraction Layer to provide bootstrap firmware for embedded systems. | It allows download and execution of embedded applications via serial or Ethernet | GPL-2.0-or-later |
| RAPIDSEA | Part of the extensive Software defined system stack, it is a bootloader with small footprint applicable for resource constrained environments with UI. | Boot logo, bootloader security validation and DFU | Commercial |
Conclusion
Bootloader architecture is vital for initializing hardware, loading firmware, and ensuring secure transitions to the main application in embedded systems. While single-stage bootloader architecture is straightforward and suitable for simple systems, multistage bootloader architecture provides enhanced flexibility, bootloader security, and scalability for more complex needs. By understanding the different bootloader architecture types, their bootloader features, and bootloader security best practices, developers can design robust, efficient, and secure boot loading processes tailored to their specific requirements. Bootloader development for embedded systems benefits from both open-source foundations and commercial solutions like RAPIDSEA, which bundle essential bootloader features including bootloader security, DFU, and boot logo out of the box. With our 2+ decades of experience, we deliver a secure solution with a feature set that matches your needs.