Motivation

In this blog, we’ll explore how to add a custom section in the linker script to store image information, such as the firmware version, checksum, and build details. We’ll also discuss how to access this information from both the bootloader and the main application, ensuring effective validation and diagnostics.

Why Image Information Matters in Embedded Systems

When working with embedded systems, particularly in scenarios involving firmware updates or bootloader applications, having metadata about the image is crucial. This metadata can include:

• Version Information: To track updates and ensure compatibility.
• Checksum: To verify the integrity of the image and detect corruption.
• Build Date/Time: Useful for identifying when the firmware was built, aiding in debugging or compliance tracking.
• Image Size: To check if the correct size of the firmware has been loaded and manage memory effectively.

Storing this information in a dedicated section of memory makes it easily accessible for both the bootloader and the main application.

Understanding ELF Sections: .text, .data, and .bss

In the context of ELF files, different sections serve specific purposes:

• .text Section: This section contains the executable code of the program. It is typically loaded into memory as read-only, preventing any modifications during execution. The .text section is where the actual instructions that the CPU executes reside.

• .data Section: This section holds initialized global and static variables. The data in this section is loaded into RAM when the program starts. Unlike the .text section, the .data section is writable, allowing the program to modify its variables.

• .bss Section: The BSS (Block Started by Symbol) section contains uninitialized global and static variables. This section is not loaded with any data but reserves space in memory for these variables. When the program starts, the OS initializes this section to zero.

we will try to add a custom section to store image information to make it accessible to both the bootloader and the main application.

Step 1: Defining the Image Information Struct

Using a structured data type (struct) in C is the best way to represent this metadata:

1
2
3
4
5
6
7

typedef struct {
    uint32_t version;      // Firmware version
    uint32_t image_size;   // Size of the firmware image in bytes
    uint32_t checksum;     // Checksum for image integrity validation
    char build_date[12];   // Build date as a string (e.g., "Sep 22 2024")
    char build_time[9];    // Build time as a string (e.g., "14:55:22")
} image_info_t;

This struct encapsulates all necessary metadata. Here’s how you can initialize and place this data in a custom section in C:

1
2
3
4
5
6
7
8

__attribute__((section(".image_info")))
const image_info_t image_info = {
    .version = 0x24,   // Example version
    .image_size = 0x40000, // Example size (256KB)
    .checksum = 0xDEADBEEF,   // Placeholder checksum
    .build_date = __DATE__,
    .build_time = __TIME__
};

Explanation:

• __attribute__((section(".image_info"))): Directs the linker to place the image_info variable in the .image_info section.
• __DATE__ and __TIME__: These macros insert the build date and time.

Step 2: Modifying the Linker Script to Include a Custom Section

The linker script defines how the binary is laid out in memory. Here’s how to modify it to include the .image_info section:

This is our memory layout after adding the custom section:

Linker Script After Modification:

1
2
3
4

/* Custom section for image metadata */
.image_info : {
    KEEP(*(.image_info))   /* Ensure the section is not discarded */
} > FLASH

Explanation:

• KEEP(*(.image_info)): Ensures the section is retained in the final binary.

Step 3: Accessing the Image Information in Another Program

To access the metadata from the main application, declare an external reference to the image_info struct:

1
2
3
4
5
6
7
8
9

extern const image_info_t image_info;

void print_image_info(void) {
    printf("Firmware Version: 0x%08X\n", image_info.version);
    printf("Image Size: %d bytes\n", image_info.image_size);
    printf("Checksum: 0x%08X\n", image_info.checksum);
    printf("Build Date: %s\n", image_info.build_date);
    printf("Build Time: %s\n", image_info.build_time);
}

Linker Script for the Application:

Ensure the application’s linker script includes the .image_info section:

1
2
3
4

/* Reference the bootloader's image info section */
.image_info (NOLOAD) : {
    *(.image_info)
} > FLASH

Explanation:

• NOLOAD: Indicates that this section will not be loaded by the linker because it already exists in FLASH.

Step 4: Verifying the Section Placement

To verify the placement of the .image_info section, use tools like objdump:

1

arm-none-eabi-objdump -h bootloader.elf

Real-World Use Cases

Firmware Updates:

The bootloader can compare the version and checksum of a new firmware image before allowing it to overwrite the existing one.

Diagnostics:

The bootloader can transmit metadata for diagnostics, providing details about the current firmware version and build information.

Conclusion

By adding a custom section in the linker script for image information, you provide a reliable and accessible way to store important metadata about the firmware image. This approach enhances validation, version control, and diagnostics, making embedded systems more robust and maintainable.