Mastering Secondary Bootloader (SBL) in Two-Stage Bootloader

In this blog post, we will explore the role and functionality of the secondary bootloader (SBL) in embedded systems. The SBL is a piece of software that runs after the primary bootloa

der (PBL) and before the main application. The SBL is responsible for initializing the hardware peripherals, loading the application image from a non-volatile memory device (such as Flash or eMMC), and transferring control to the application.

The SBL is typically written in C or assembly language and compiled into a binary file that can be executed by the processor. The SBL may also include some configuration data, such as Memory map, device tree, or boot parameters. The SBL binary file is usually stored in a reserved partition or sector of the non-volatile memory (NVM) device.

Introduction to Secondary Bootloader (SBL)

The secondary bootloader (SBL) is a piece of software that runs on embedded devices after the primary bootloader (PBL) and before the operating system (OS). The SBL is responsible for initializing the hardware components, loading the OS image from a storage device, and passing control to the OS. This is also called by some Embedded Engineers as PBL SBL Bootloader

What Secondary Bootloader (SBL) can do?

The SBL is usually stored in a flash memory or a read-only memory (ROM) chip on the device. The PBL, which is typically stored in a ROM or a one-time programmable (OTP) memory, locates and verifies the SBL image and then executes it. The PBL is usually very simple and has limited functionality due to its size constraints.

The SBL can perform various tasks depending on the device requirements and design choices. Some of these tasks are:

Initializing the clock, power, memory, and peripheral devices
Setting up security features such as encryption, authentication, and secure boot
Performing self-tests and diagnostics
Updating firmware or software components
Loading drivers or modules for specific hardware components
Decompressing or decrypting the OS image
Verifying the integrity and signature of the OS image
Passing parameters or information to the OS
Jumping to the entry point of the OS

The Architecture of a Secondary Bootloader (SBL)

The architecture of a Secondary Bootloader (SBL) in a two-stage bootloader system can vary depending on the specific requirements and design choices of the embedded system. However, here is a generalized architecture that is commonly used:

Boot ROM/Flash Memory: The SBL resides in a dedicated section of the boot ROM or flash memory, similar to the Primary Bootloader (PBL). This memory region contains the SBL code, data structures, and any necessary configuration parameters.
Initialization and Configuration: Upon system startup, the SBL initializes the necessary hardware resources, such as clocks, memory controllers, and peripheral interfaces, to set up the basic system environment. It configures the necessary registers and sets up interrupt vectors for subsequent operations.
Communication and Protocol Support: The SBL includes communication protocols, such as UART, SPI, I2C, Ethernet, or USB, to establish a connection with external devices or host systems. These protocols allow the SBL to receive firmware updates, bootloader commands, or configuration parameters from an external source.
Boot Mode Selection: The SBL provides mechanisms to select the boot mode based on specific conditions, similar to the PBL. This can be done through hardware pins, boot configuration settings, or by checking the status of specific peripherals. The boot mode determines whether the SBL loads the main application firmware, a secondary firmware image, or transfers control to another stage of the bootloader.
Device Initialization and Validation: Before loading the main application firmware or a secondary firmware image, the SBL performs device-specific initialization tasks. This may include configuring external memory, and peripheral devices, or performing checks and validation on the firmware image’s integrity, compatibility, or security.
Firmware Loading and Execution: Once the device is initialized, the SBL proceeds with loading the main application firmware or a secondary firmware image into the appropriate memory location. This process involves reading the firmware image from an external source (e.g., storage device, network) and writing it to the target device’s memory. After the firmware is loaded, the SBL transfers control to the loaded firmware for execution.
Error Handling and Recovery: The SBL incorporates error handling and recovery mechanisms to handle various failure scenarios that may occur during the boot process. It includes error detection, error reporting, and recovery options such as retrying firmware loading, fallback to a backup firmware version, or triggering error notifications to the user or host system.

Different Types of Secondary Bootloaders (SBL)

The SBL can be implemented in different ways depending on the device architecture and platform. Some common types of SBL are:

U-Boot: A widely used open-source bootloader for Linux-based systems that supports various architectures such as ARM, x86, MIPS, PowerPC, etc. U-boot can load Linux kernel images from various sources such as NAND flash, SD card, USB drive, network boot (TFTP), etc. U-boot also provides an interactive shell that allows users to configure settings or run commands before booting into Linux.
Little Kernel (LK): A small and fast bootloader for Android-based systems that runs on ARM processors. LK can load Android boot images from eMMC flash or SD card. LK also provides a minimal console that allows users to view logs or enter commands before booting into Android.
EDK II: A modular and extensible bootloader framework based on Unified Extensible Firmware Interface (UEFI) specifications that runs on x86 processors. EDK II can load Windows or Linux images from various sources such as SATA disk, NVMe SSD, USB drive, network boot (PXE), etc. EDK II also provides a graphical user interface that allows users to configure settings or run applications before booting into Windows or Linux.

The SBL plays an important role in ensuring the functionality and security of embedded devices. By understanding how it works and what it does, developers can optimize their device performance and reliability.

How Does Secondary Bootloader (SBL) Work?

The PBL is a small and simple program that runs immediately after a power-on reset. The PBL is usually stored in a read-only memory (ROM) or a one-time programmable (OTP) memory inside the processor chip. The PBL performs some basic initialization tasks, such as setting up the clock and power domains, enabling the watchdog timer, and configuring the pins for boot mode selection. The PBL then reads the boot mode pins or registers to determine where to load the SBL from.

Depending on the processor architecture and platform design, there may be different boot modes supported by the PBL. For example, some processors can boot from SPI flash, SD card, USB device, UART port, Ethernet network, or JTAG interface. The PBL selects one of these boot modes based on some predefined priority order or user input. The PBL then communicates with the corresponding device driver to read the SBL binary file from the selected source and copy it to a temporary location in RAM.

After loading the SBL into RAM, the PBL verifies its integrity using some checksum or signature algorithm. If verification fails, the PBL may try another boot mode or report an error condition using some LED indicators or serial console output. If verification succeeds, the PBL jumps to execute
the SBL code at its entry point address.

Secondary Bootloader (SBL) in Two-Stage Bootloader

The SBL takes over from where the PBL left off and performs more advanced initialization tasks that are specific to
the platform and application requirements. For example,
the SBL may:

Initialize external memories such as DDR RAM, NOR flash, or NAND flash
Configure system clocks, voltage regulators, and power management
Set up interrupt controller, timer, and watchdog modules
Enable security features such as secure boot, trust zone, or encryption
Detect hardware revisions, board variants, or sensor types
Load device drivers for peripheral devices such as LCD display, touch screen, camera, audio codec, Wi-Fi module, or Bluetooth chip
Parse configuration data such as memory map, device tree, or boot parameters
Load application image from non-volatile memory device into RAM
Verify application integrity using checksum or signature algorithm

After completing all these tasks, the SBL transfers control to the application by jumping to its entry point address. The application then starts running and provides the main functionality of the embedded system. The SBL plays an important role in ensuring the smooth and secure operation of the embedded system. It acts as a bridge between the low-level hardware initialization done by the PBL and the high-level software execution done by the application. It also provides a flexible mechanism for updating the application firmware Over-The-Air (OTA) or via other methods. By understanding how the SBL works, we can better design, develop, debug, and optimize our embedded systems.

Example of Secondary Bootloader code

/******************************************************************************
 * Primary Bootloader for NXP S32K144
 *
 * Description: This bootloader validates the flash memory, checks for programming
 * requests, and downloads and writes the data to the specified memory address.
 * It then gives control to the secondary bootloader.
 *
 * Author: John Doe
 * Date: 20xx-xx-xx
 *
 * Copyright (c) 20xx John Doe. All rights reserved.
 *
 * This software is furnished under a license and may be used and copied only
 * in accordance with the terms of such license and with the inclusion of the
 * above copyright notice. This software or any other copies thereof may not be
 * provided or otherwise made available to any other person. No title to and
 * ownership of the software is hereby transferred.
 *
 * The information in this software is subject to change without notice and
 * should not be construed as a commitment by John Doe.
 *
 * Technical support is not available for this software.
 *
 * This software is provided "as is" with no warranty of any kind.
 *
 * The author is not responsible for any damage resulting from the use of this software.
 *
 * This code is a starting point and may not be complete or fully functional.
 * It is provided as-is and is intended to be used as a guide.
 *
 * Modification and customization is encouraged for specific applications.
 *
 *****************************************************************************/

#include "S32K144.h"

#define SECOND_STAGE_BOOTLOADER_START_ADDRESS 0x8000

void init_clock(void)
{
    /* Initialize the clock configuration */
    /* ... */
}

void init_gpio(void)
{
    /* Initialize the GPIO configuration */
    /* ... */
}

void init_flash(void)
{
    /* Initialize the flash configuration */
    /* ... */
}

void validate_flash_memory(void)
{
    /* Validate the flash memory */
    /* ... */
}

void check_programming_request(void)
{
    /* Check for programming request */
    /* ... */
}

void download_and_write_to_flash(void)
{
    /* Download the data and write it to the specified memory address */
    /* ... */
}

void jump_to_secondary_bootloader(void)
{
    /* Jump to the secondary bootloader */
    /* ... */
}

int main(void)
{
    init_clock();
    init_gpio();
    init_flash();
    validate_flash_memory();
    check_programming_request();
    download_and_write_to_flash();
    jump_to_secondary_bootloader();

    return 0;
}

Advantages of Secondary Bootloader (SBL) in Two-Stage Bootloader

Modularity and Firmware Updateability: The SBL provides a modular approach to the bootloader system, separating the main application firmware from the primary bootloader. This modularity allows for independent updates of the SBL and the main firmware, enabling easier maintenance and future enhancements. It allows for targeted updates and bug fixes without requiring the entire bootloader system to be updated.
Flexibility in Boot Mode Selection: The SBL allows for flexible boot mode selection. It can support multiple boot modes, enabling the system to boot from different sources, such as internal flash memory, external memory devices, or communication interfaces. This flexibility is useful in various scenarios, including firmware updates, recovery procedures, or alternate boot configurations.
Boot Time Optimization: By offloading certain initialization tasks to the SBL, the overall boot time can be optimized. The SBL focuses on essential initialization and configuration processes, allowing the system to reach the main firmware execution stage more quickly. This results in reduced startup time and improved system responsiveness.
Firmware Validation and Security: The SBL can incorporate mechanisms for validating the integrity and authenticity of the main firmware image. It can perform cryptographic checks, checksum verifications, or digital signature validations before loading the firmware. This enhances the security of the system by ensuring that only valid and authorized firmware is executed.
Error Handling and Recovery: The SBL includes error handling and recovery mechanisms to handle various error scenarios that may occur during the boot process. It can detect and recover from issues such as incomplete firmware updates, corrupted firmware images, or communication errors. The SBL provides fallback options, retry mechanisms, or error notifications to ensure system robustness and reliability.
Hardware Abstraction and Portability: The SBL can abstract the hardware-specific initialization and configuration processes, providing a hardware-independent interface for the main firmware. This abstraction allows the main firmware to be more portable across different hardware platforms. It simplifies the development process and enables the main firmware to be easily ported to new hardware configurations.
Enhanced System Security: The SBL can enhance system security by incorporating additional security measures such as secure boot protocols, secure key management, or encryption techniques. These measures protect the boot process from unauthorized access, tampering, or malicious firmware injection, ensuring the system’s integrity and preventing unauthorized execution.

Disadvantages of Secondary Bootloader (SBL) in Two-Stage Bootloader

While secondary bootloaders (SBLs) in two-stage bootloaders offer certain advantages, they also come with a few potential disadvantages. Here are some common disadvantages associated with the use of a secondary bootloader:

Increased Boot Time: The presence of a secondary bootloader adds an additional step in the boot process, which can result in increased boot time compared to a single-stage bootloader. This can be a concern in time-critical applications where fast boot times are essential.
Increased Complexity: Two-stage bootloaders, including secondary bootloaders, introduce additional complexity to the system design and development process. Managing the interaction between the primary and secondary bootloaders, ensuring proper handover of control, and addressing potential compatibility issues between the two stages require careful consideration and testing.
Memory Footprint: A secondary bootloader consumes additional memory resources in the microcontroller. This can limit the available memory for the main application code, especially if the microcontroller has limited overall memory capacity. It requires careful memory management to ensure that both the bootloader and the application code fit within the available memory space.
Reduced Flash Storage Capacity: In two-stage bootloaders, the primary bootloader resides in a dedicated portion of the microcontroller’s flash memory, and the secondary bootloader requires its own separate portion of flash memory. This reduces the overall flash storage capacity available for the main application code.
Limited Upgradeability: The primary bootloader and the secondary bootloader are typically tightly coupled and designed to work together. This tight coupling can make it challenging to upgrade or modify the secondary bootloader independently. Any changes to the secondary bootloader may require modifications to the primary bootloader as well, which can be more complex and time-consuming.
Vendor Dependencies: The primary and secondary bootloaders are often provided by the microcontroller’s manufacturer or vendor. This can create a dependency on the vendor for bootloader-related support, updates, or customization. If the vendor does not provide adequate support or discontinues support for the device, it may impact the ability to maintain or update the bootloader in the long term.
Potential Compatibility Issues: Introducing a secondary bootloader may introduce compatibility issues with existing software or firmware. It is crucial to ensure that the secondary bootloader is compatible with the microcontroller, other system components, and any existing software or firmware that will be loaded by the bootloader.

Future Development and Enhancement of Secondary Bootloader (SBL) in Two-Stage Bootloader

The future development and enhancement of secondary bootloaders (SBLs) in two-stage bootloader architectures are likely to focus on addressing existing challenges and incorporating new features to meet evolving needs. Here are some potential areas of future development:

Boot Time Optimization: Future SBLs may aim to minimize boot time by implementing efficient boot algorithms, optimizing handover processes between the primary and secondary bootloaders, and reducing the overall boot sequence complexity. This can be particularly important in time-critical applications where fast boot times are essential.
Increased Compatibility and Interoperability: SBLs may strive for improved compatibility and interoperability with different microcontroller architectures, vendors, and system configurations. This can involve developing standardized interfaces and protocols to facilitate seamless integration with various hardware platforms and simplify the migration of firmware across different systems.
Enhanced Security Features: As security concerns continue to grow, future SBLs may incorporate advanced security features. This can include secure communication protocols, encryption algorithms, secure boot mechanisms, and authentication mechanisms to protect against unauthorized access, tampering, or the execution of malicious code during the boot process.
Over-the-Air (OTA) Updates: SBLs may be enhanced to support over-the-air (OTA) updates, enabling remote and wireless firmware updates. This can involve implementing robust and secure OTA update mechanisms, efficient data transfer protocols, and error handling mechanisms to ensure reliable and secure firmware updates in the field.
Advanced Diagnostics and Debugging: Future SBLs may offer enhanced diagnostic and debugging features to simplify troubleshooting and maintenance processes. This can include improved logging capabilities, real-time debugging interfaces, remote debugging support, and the ability to capture and analyze system data during the boot sequence.
Customization and Configuration Options: SBLs may provide more extensive customization and configuration options to cater to diverse system requirements. This can involve flexible bootloader interfaces that allow users to customize settings, enable/disable specific features, or dynamically load additional firmware components based on system requirements.
Flash Management and Optimization: SBLs may focus on efficient flash memory management techniques to optimize flash utilization and maximize available storage for the main application code. This can include implementing advanced compression algorithms, intelligent memory allocation strategies, and support for external storage devices for firmware updates.
Standardization and Vendor-Agnostic Solutions: To promote interoperability and simplify development processes, future SBLs may strive for standardized interfaces, protocols, and APIs. This would enable the use of vendor-agnostic solutions, allowing developers to work with multiple microcontroller architectures and switch between different hardware vendors while utilizing a standardized SBL framework.