FIT Image Memory Overlap Detection and Handling

[AristoChen]

Summary

Discussion about adding memory overlap detection for FIT images and how to handle cases where images intentionally share memory addresses but are loaded selectively at runtime.

Background

While working on U-Boot FIT image overlap detection (U-Boot mailing list discussion), we encountered different scenarios where FIT images may have overlapping load addresses:

1. Genuine overlaps (bugs): Multiple images loaded simultaneously with conflicting memory regions
2. Intentional overlaps (platform-specific): Images that share addresses but are mutually exclusive at runtime

Current Challenges

Case 1: Genuine Memory Overlap

Scenario:

• firmwareA: loads at 0x40000000, size 0x200010 bytes → ends at 0x40200010
• firmwareB: loads at 0x40200000
• Problem: 16 bytes overlap where both need to be in memory simultaneously

FIT Configuration:

configurations {
    conf-1 {
        firmware = "firmwareA";
        loadables = "firmwareB";
        fdt = "fdt-1";
    };
}

Case 2: Mutually Exclusive Images (Some TI Platforms)

Scenario: firmware stubs that share the same load address but only one is loaded based on runtime detection.

tifsstub-hs {
        description = "TIFSSTUB";
        type = "firmware";
        arch = "arm32";
        compression = "none"; 
        os = "tifsstub-hs";
        load = <0x9dc00000>;
        entry = <0x9dc00000>;
        blob-ext {
                filename = "tifsstub.bin_hs";
        };      
};

tifsstub-fs {
        description = "TIFSSTUB";
        type = "firmware";
        arch = "arm32";
        compression = "none"; 
        os = "tifsstub-fs";
        load = <0x9dc00000>;
        entry = <0x9dc00000>;
        blob-ext {
                filename = "tifsstub.bin_fs";
        };      
};

tifsstub-gp {
        description = "TIFSSTUB";
        type = "firmware";
        arch = "arm32";
        compression = "none"; 
        os = "tifsstub-gp";
        load = <0x9dc00000>;
        entry = <0x9dc00000>;
        blob-ext {
                filename = "tifsstub.bin_gp";
        };      
};

FIT Configuration:

configurations {
    conf-1 {
        firmware = "atf";
        loadables = "tee", "tifsstub-hs", "tifsstub-fs", "tifsstub-gp";
        fdt = "fdt-1";
    };
}

Runtime behavior: Platform code (board_fit_image_post_process() in arch/arm/mach-k3/r5/common.c) handles non-matching stubs:

if ((device_type == K3_DEVICE_TYPE_HS_SE &&
     strcmp(os, "tifsstub-hs")) ||
   (device_type == K3_DEVICE_TYPE_HS_FS &&
     strcmp(os, "tifsstub-fs")) ||
   (device_type == K3_DEVICE_TYPE_GP &&
     strcmp(os, "tifsstub-gp"))) {
	*p_size = 0;
}

Proposed Solutions Under Discussion

Some platforms load only one image from a group at runtime. In the device tree, we may have something like this

tifsstub-hs {
    load = <0x9dc00000>;
    entry = <0x9dc00000>;
    mutually-exclusive-group = "tifsstub";
};
tifsstub-fs {
    load = <0x9dc00000>;  // Same address OK - mutually exclusive
    entry = <0x9dc00000>;
    mutually-exclusive-group = "tifsstub";
};

The overlap checker would then skip validation between images in the same mutually-exclusive-group, while still catching genuine overlaps

Please let me know if you have any suggestions or concerns, thanks!

[a3f]

Your proposal is omitting who would parse these extra nodes. Is it only mkimage or do you expect FIT consumers to use that information for anything? What's happening right now in the conflict scenario? Does U-Boot just overwrite the overlapping firmware?

1. I think the hardcoding of addresses in FIT is a misfeature that needs to buried. Even if you avoid conflicts between images inside the FIT, you can still conflict with bootloader memory at runtime. kernel_noload allows U-Boot to dynamically allocate memory and that logic is what you want whereever you have a position independent image. barebox already determines the location of images dynamically if the load and entry addresses are missing and that's what I suggest you do as well. For the remainder of images that aren't position-independent, you'll want the bootloader to catch it at runtime anyway.

2. Did you consider having multiple configurations and selecting between them at runtime instead of having a single intentionally conflicting configuration and then working around it?