Hi Aristo, On 2026-07-21T15:21:05, Aristo Chen <[email protected]> wrote: > tools: mkimage: detect overlapping load regions in FIT configurations > > Add a validation step to mkimage that checks, for every configuration > of a FIT image, whether the images referenced by that configuration > declare overlapping load regions. Images that are loaded together must > not share memory, and such conflicts currently go unnoticed until the > resulting image corrupts memory at runtime. > > The check is strictly per configuration. Images that share a load > address while being referenced by different configurations are not > reported, because only one configuration is selected at boot. This > matches the layout used by the TI K3 tispl images since commit > c85bf61b14f9 ("arm: k3: select tifsstub via board_fit_config_name_match"), > where the mutually exclusive tifsstub variants moved into per security > state configurations precisely so that static tooling can reason about > each configuration on its own. > > Images without a load address or without data are skipped, since > nothing is copied anywhere for them. Compared to the previously > reverted version of this check, the missing load address case no > [...] > > tools/fit_image.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > tools/mkimage.c | 3 +- > 2 files changed, 101 insertions(+), 1 deletion(-)
> diff --git a/tools/fit_image.c b/tools/fit_image.c > @@ -1031,10 +1051,88 @@ static int fit_import_data(struct image_tool_params > *params, const char *fname) > + img_data = fdt_getprop(fdt, img, FIT_DATA_PROP, > + &img_size); > + if (!img_data || img_size <= 0) > + continue; Just to check: img_size here is the stored data size, which for a compression = 'gzip' image is the compressed blob, not the runtime footprint. So two images whose compressed data does not overlap but whose decompressed regions do would not be flagged. For the K3 and phyCORE loadables this series targets the images are uncompressed, so it does not bite in practice, but it is a real limitation. Keeping the static data size is fine - there is no reliable uncompressed size to use - but it might be worth a line in the patch 7 docs noting that the check reasons about the packaged data size and so assumes uncompressed images. What do you think? In any case: Reviewed-by: Simon Glass <[email protected]> Regards, Simon
