Primary Bootloader (PBL) in Two-Stage Bootloader

Mastering Primary Bootloader (PBL) in Two-Stage Bootloader

A bootloader is a piece of software that runs before the main application code and performs some initialization tasks, such as setting up the clock, memory, and peripherals and loadin

g the application code from a non-volatile memory (such as flash) to a volatile memory (such as RAM). A bootloader can also provide some features such as firmware update, recovery mode, diagnostics, and security.

Introduction to Primary Bootloader (PBL) in Two-Stage Bootloader

In embedded systems, where resources are limited and performance is critical, a bootloader is often split into two stages: a primary bootloader (PBL) and a secondary bootloader (SBL). The PBL is the first code that runs after the system is powered on or reset. It is usually stored in a read-only memory (ROM) or a one-time programmable memory (OTP) that is embedded in the microcontroller or processor.

The PBL has minimal functionality and its main purpose is to initialize the minimum hardware required to load and execute the SBL from an external memory (such as flash or SD card). The SBL is more complex and feature-rich than the PBL. It can perform additional hardware initialization, verify the integrity and authenticity of the application code, decrypt or decompress it if needed, and transfer control to it. This is also called PBL SBL Bootloader.

What is Primary Bootloader (PBL)?

Primary Bootloader (PBL) is a small program that runs when a device is powered on. Its main function is to initialize the hardware and load the secondary bootloader (SBL) from a specific memory location. The PBL is usually stored in a read-only memory (ROM) or a one-time programmable (OTP) memory so that it cannot be modified or corrupted easily. The PBL is also responsible for verifying the integrity and authenticity of the SBL before executing it.

The architecture of a Primary Bootloader (PBL) in Two-Stage Bootloader

The architecture of the PBL depends on the specific hardware and software requirements of the device. However, a typical PBL consists of the following components:

  • A reset vector that points to the start address of the PBL code.
  • A minimal initialization code that sets up the stack pointer, the clock frequency, and the memory map.
  • A hardware abstraction layer (HAL) provides low-level access to the device peripherals, such as GPIO, UART, SPI, I2C, etc.
  • A device driver layer that implements high-level functions for reading and writing data from/to the non-volatile memory that contains the SBL.
  • A boot protocol layer that defines the format and location of the SBL image in the non-volatile memory, and verifies its integrity and authenticity using checksums or cryptographic signatures.
  • A boot loader layer that copies the SBL image from the non-volatile memory to a volatile memory, such as RAM or cache, and transfers control to it.

How does Primary Bootloader (PBL) work in Two-Stage Bootloader

The following are the steps involved in the operation of a primary bootloader:

  1. Initialization: The PBL initializes the clock, GPIO, and flash memory of the microcontroller. This ensures that the microcontroller is set up properly and ready to execute the next steps.
  2. Flash Memory Validation: The PBL validates the flash memory to ensure that it is in a healthy state. This step helps to prevent any data corruption or loss in the flash memory.
  3. Programming Request Check: The PBL checks for any programming requests from the host. This is usually done by checking a specific register or pin on the microcontroller.
  4. Download and Write to Flash: If a programming request is detected, the PBL downloads the new application code from the host and writes it to the specified memory address in the flash memory.
  5. Jump to Secondary Bootloader: After completing the previous steps, the PBL gives control to the secondary bootloader. The secondary bootloader then takes over and performs the actual application programming.
Primary Bootloader (PBL)

Below is an example of a two-stage bootloader code for an automotive application using the microcontroller NXP S32K144. The first stage bootloader is executed by the microcontroller on power-on and is responsible for initializing the system and loading the second stage bootloader from external flash memory into the internal RAM. The second stage bootloader then takes over and performs the actual application programming.

/******************************************************************************
 * First Stage Bootloader for NXP S32K144
 *
 * Description: This bootloader initializes the system and loads the second stage
 * bootloader from external flash memory into the internal RAM.
 *
 * 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 load_second_stage_bootloader(void)
{
    /* Load the second stage bootloader from external flash memory into the internal RAM */
    /* ... */
}

void jump_to_second_stage_bootloader(void)
{
    /* Jump to the second stage bootloader in the internal RAM */
    /* ... */
}

int main(void)
{
    init_clock();
    init_gpio();
    init_flash();
    load_second_stage_bootloader();
    jump_to_second_stage_bootloader();

    return 0;
}

Advantages of Primary Bootloader (PBL) in Two-Stage Bootloader

The Primary Bootloader (PBL) is a key component in a two-stage bootloader system. It serves as the first stage of the bootloader and plays a crucial role in the boot process of embedded systems. Here are some advantages of having a Primary Bootloader in a two-stage bootloader system:

  1. Boot Mode Selection: The PBL provides a mechanism to select the boot mode based on specific conditions. This allows the system to boot from different sources, such as internal flash memory, external memory devices, or communication interfaces. The PBL can detect the boot mode based on hardware pins, boot configuration settings, or other criteria, providing flexibility and adaptability to the boot process.
  2. Reduced System Startup Time: By having a two-stage bootloader system with a dedicated PBL, the overall system startup time can be reduced. The PBL focuses on essential initialization tasks, such as setting up clocks, memory controllers, and basic hardware configurations. It allows the system to boot quickly and transfer control to the main application firmware or a Secondary Bootloader (SBL) for further processing, thus improving the system’s responsiveness.
  3. Firmware Authentication and Security: The PBL can incorporate firmware authentication mechanisms to ensure the integrity and authenticity of the main application firmware. It can verify cryptographic signatures or checksums to validate the firmware image before executing it. This helps prevent the execution of unauthorized or tampered firmware, enhancing the overall security of the system.
  4. Error Handling and Recovery: The PBL can handle various error scenarios that may occur during the boot process. It includes error detection mechanisms, recovery procedures, and fallback options to handle situations such as incomplete firmware updates, corrupted firmware images, or communication errors. This enables the system to recover from errors and provides robustness in the boot process.
  5. Easy Firmware Update and Maintenance: Having a two-stage bootloader system with a separate PBL simplifies the process of firmware updates and maintenance. The PBL can be designed to support firmware updates via different communication interfaces, such as UART, USB, or Ethernet. This allows for easier and more flexible firmware updates, enabling new features, bug fixes, and enhancements to be delivered to the system without requiring complex bootloader modifications.
  6. Hardware Compatibility: The PBL can handle hardware-specific initialization tasks and ensure compatibility with different hardware configurations. It sets up the necessary hardware resources and initializes peripheral interfaces based on the specific hardware platform. This allows the main application firmware or SBL to be hardware-agnostic, as the PBL takes care of the hardware-specific initialization.

Disadvantages of Primary Bootloader (PBL) in Two-Stage Bootloader

While the Primary Bootloader (PBL) in a two-stage bootloader system offers several advantages, there are also some potential disadvantages to consider. Here are a few disadvantages of having a Primary Bootloader:

  1. Increased Boot Time: The presence of an additional boot stage with the PBL can potentially increase the overall boot time of the system. The PBL performs its own initialization tasks before transferring control to the Secondary Bootloader (SBL) or the main application firmware. This extra step adds some overhead to the boot process, which may be noticeable in certain real-time or time-critical systems.
  2. Complexity and Development Effort: Implementing and maintaining a two-stage bootloader system with a PBL requires additional development effort and complexity. It involves designing and debugging the PBL code, ensuring its compatibility with different hardware platforms, and coordinating its operation with the SBL and the main application firmware. The development and maintenance of a reliable PBL can be more challenging compared to a single-stage bootloader system.
  3. Increased Code and Memory Footprint: With the inclusion of a PBL, the overall code and memory footprint of the bootloader system may increase. The PBL requires its own code and data space, adding to the size of the firmware image. This can be a concern in resource-constrained embedded systems where memory usage is critical.
  4. Limited Flexibility: The presence of a PBL in the boot process may impose certain limitations on system flexibility. For example, if the PBL is designed to boot only from specific sources or has limited boot mode options, it may restrict the system’s ability to adapt to different requirements or use cases. Modifications or updates to the boot process may require changes in the PBL, making it less flexible compared to a more customizable bootloader solution.
  5. Firmware Update Challenges: In some cases, updating the PBL itself can be more challenging compared to updating the SBL or the main application firmware. Modifying or updating the PBL typically requires careful consideration and validation due to its critical role in the boot process. Updating the PBL may involve additional steps such as bootloader chaining or a specialized update mechanism, which can add complexity and potential risks.

Future Development and Enhancement of Primary Bootloader (PBL) in Two-Stage Bootloader


The future development and enhancement of the Primary Bootloader (PBL) in a two-stage bootloader system can focus on several areas to improve its functionality, performance, and usability. Here are some potential directions for future development:

  1. Boot Time Optimization: Efforts can be made to optimize the boot time of the system by optimizing the PBL code execution and initialization processes. Techniques such as parallel initialization of hardware resources, optimizing memory access, and reducing unnecessary delays can be explored to minimize the time taken by the PBL in the boot process.
  2. Secure Boot and Authentication: With the increasing concern for firmware security, future PBL enhancements can focus on strengthening secure boot mechanisms. Additional features can be implemented to support secure boot protocols, cryptographic algorithms, and secure key management. This ensures the authenticity and integrity of the firmware being loaded by the PBL.
  3. Over-the-Air (OTA) Updates: Enabling OTA firmware updates directly through the PBL can enhance the system’s flexibility and updateability. This involves incorporating wireless communication protocols and mechanisms to receive firmware updates securely and efficiently. OTA updates can help deploy bug fixes, feature enhancements, and security patches without requiring physical access to the embedded system.
  4. Modularity and Customizability: Future PBL development can focus on making it more modular and customizable to accommodate various hardware configurations and system requirements. This includes designing the PBL in a way that allows for easy configuration, customization, and adaptation to different platforms and use cases.
  5. Robust Error Handling and Recovery: Enhancements can be made to the error handling and recovery mechanisms of the PBL. This involves detecting and handling various error scenarios gracefully, providing detailed error information, and offering recovery options such as fallback to a known good firmware version or initiating a firmware update process.
  6. Hardware Abstraction and Portability: Developing a hardware abstraction layer within the PBL can make it more portable across different hardware platforms. This allows the PBL code to be reused or easily adapted to new hardware configurations without significant modifications, reducing development effort and improving code maintainability.
  7. Diagnostic and Debugging Support: Adding diagnostic and debugging capabilities to the PBL can aid in troubleshooting boot-related issues. This includes incorporating features such as logging, error reporting, and integration with development tools or interfaces for debugging purposes during the boot process.
  8. Power Management and Low-Power Boot: Future PBL enhancements can focus on power management features and support for low-power boot modes. This involves optimizing power consumption during the boot process and enabling the system to boot efficiently in low-power or energy-constrained scenarios.

Scroll to Top