1. Overview of MCUboot

MCUboot is an open-source, secure bootloader designed specifically for microcontrollers (MCUs). It was originally part of the Mynewt project and has since become the standard bootloader for RTOS such as Apache NuttX and Zephyr. MCUboot provides a secure firmware update mechanism and supports multiple boot modes, ensuring that the system can start and update securely and reliably.

2. Main Boot Modes of MCUboot

MCUboot supports several key boot modes, each suitable for different application scenarios and requirements.

2.1 Normal Boot Mode

Working Principle:

• This is the most basic boot mode, where MCUboot verifies the integrity and authenticity of the application image.
• If verification passes, it jumps to execute the application.
• If verification fails, it remains in the bootloader or enters recovery mode.

Features:

• Uses cryptographic signatures to verify images (typically supports RSA, ECDSA, or Ed25519).
• Supports image rollback protection (to prevent downgrade attacks).
• Fast boot speed, suitable for production environments.

Typical Application Scenarios:

• Used during normal operation of the product.
• Applicable in scenarios requiring quick startup.

**Code Example (Verification Process)**:

int boot_verify_image(struct image_header *hdr, const struct flash_area *fap)
{
    // Verify image signature
    if (bootutil_img_validate(hdr, fap, NULL, 0, NULL)) {
        return -1;
    }
    
    // Verify image version (anti-rollback)
    if (bootutil_check_img_ver(hdr) < 0) {
        return -1;
    }
    
    return 0;
}

2.2 Recovery Mode (DFU Mode)

Working Principle:

• Enters when specific conditions are detected (such as key combinations, GPIO states, or application requests).
• Waits to receive new firmware through specific interfaces (such as UART, USB, or BLE).
• After receiving, it verifies the new firmware and writes it to flash memory.

Features:

• Supports multiple transport protocols (serial, USB DFU, network, etc.).
• Provides a secure firmware update mechanism.
• Typically requires user interaction or explicit instructions to trigger.

Typical Application Scenarios:

• Device firmware updates.
• System recovery.
• Development and debugging phases.

Trigger Method Example:

bool enter_recovery_mode(void)
{
    // Check recovery pin status
    if (gpio_read(RECOVERY_PIN) == 0) {
        return true;
    }
    
    // Check image validity
    if (!boot_verify_image(&current_img_hdr, current_img_area)) {
        return true;
    }
    
    // Check application request
    if (boot_check_application_request()) {
        return true;
    }
    
    return false;
}

2.3 Swap Mode

Working Principle:

• Uses two image slots: primary and secondary.
• During updates, new firmware is first written to the secondary slot.
• On the next boot, the contents of the two slots are swapped.
• If the new firmware fails to boot, it can roll back to the old version.

Features:

• Provides atomic updates – either completely succeed or completely fail.
• Requires double the application storage space.
• Supports testing confirmation mechanisms.

Types of Swap Algorithms:

1. Traditional Swap: Swap the contents of the two slots block by block.
2. In-Place Swap: Achieved by modifying pointers, reducing erase cycles.
3. Extended Swap: Combines the advantages of the first two.

Code Structure Example:

struct image_slot {
    uint8_t slot;           // Slot number
    uint32_t address;       // Starting address
    uint32_t size;          // Size
    struct image_header hdr; // Image header
};

struct image_slot slots[2] = {
    {0, PRIMARY_SLOT_ADDR, PRIMARY_SLOT_SIZE, {0}},
    {1, SECONDARY_SLOT_ADDR, SECONDARY_SLOT_SIZE, {0}}
};

2.4 Overwrite Mode

Working Principle:

• Directly writes new firmware to the primary slot.
• No need for a secondary slot or swap operations.
• Update failures may lead to the system being unable to boot.

Features:

• Conserves storage space (no need for dual slots).
• Higher risk, requires ensuring the reliability of the update process.
• Typically requires additional recovery mechanisms as a safeguard.

Applicable Scenarios:

• Devices with very limited storage space.
• Systems with reliable recovery mechanisms (such as external recovery modes).

2.5 Direct Execute-in-Place Mode

Working Principle:

• Directly executes new firmware from the secondary slot (without swapping).
• Confirms that the new firmware works correctly before deciding whether to make it primary.
• Also known as “Trial Run” mode.

Features:

• Reduces flash erase cycles.
• Requires MCU support for XIP execution from multiple addresses.
• Confirmation mechanism is crucial.

Process Example:

1. Write new firmware to the secondary slot.
2. Directly start execution from the secondary slot.
3. Application confirms it is running correctly and notifies the bootloader.
4. Bootloader marks the secondary as primary.

3. Mode Selection and Configuration

The boot modes of MCUboot can be selected through a combination of compile-time configuration and runtime policies:

3.1 Compile-Time Configuration

Defined in <span>mcuboot_config.h</span> or project configuration files:

/* Select upgrade mode */
#define MCUBOOT_OVERWRITE_ONLY   0   // Overwrite mode
#define MCUBOOT_SWAP_USING_MOVE  1   // Swap mode (in-place)
#define MCUBOOT_SWAP_USING_SCRATCH 0 // Swap mode (using scratch)

/* Enable Direct XIP */
#define MCUBOOT_DIRECT_XIP       0

/* Enable Recovery Mode */
#define MCUBOOT_SERIAL_RECOVERY  1

3.2 Policy Configuration

Controlled through flags in the image header and TLV (tag-length-value) area:

Image Header:
+-------------------+---------------------+
|  Magic Number     |  Load Address       |
+-------------------+---------------------+
|  Image Size       |  Flags              | <-- Controls boot behavior
+-------------------+---------------------+
|  Version          |  ...                |
+-------------------+---------------------+

TLV Area:
+-------------------+---------------------+
|  Tag (e.g. SHA256)|  Length             |
+-------------------+---------------------+
|  Value (hash/sig) |  ...                |
+-------------------+---------------------+

4. Security Considerations

Regardless of the chosen boot mode, MCUboot provides the following security features:

1. Image Verification: Uses cryptographic signatures to ensure image integrity and authenticity.
2. Version Control: Prevents rollback to older versions (anti-downgrade attacks).
3. Secure Boot: Integrates with the chip’s secure boot features.
4. Encryption Support: Optional image encryption (e.g., AES-256).
5. Hardware Binding: Can be integrated with HSM or secure elements.

5. Practical Application Recommendations

1. Resource-Rich Devices: Recommended to use swap mode, providing the most reliable update mechanism.
2. Space-Constrained Devices: Consider overwrite mode or direct XIP mode.
3. Critical Applications: Combine recovery mode and swap mode for dual protection.
4. Development Phase: Enable all debugging features and recovery mode.
5. Production Environment: Lock the bootloader according to security requirements and disable debugging interfaces.

6. Conclusion

The various boot modes of MCUboot provide flexible solutions for different application scenarios. Understanding how these modes work and their applicable scenarios is crucial for designing reliable embedded systems. In practical projects, the appropriate mode or combination of modes should be selected based on device resources, security requirements, and maintenance needs.