Am Samstag, dem 09.08.2025 um 10:08 +0800 schrieb Aristo Chen: > Yannic Moog <y.m...@phytec.de> 於 2025年7月31日 週四 下午7:43寫道: > > > > Am Dienstag, dem 29.07.2025 um 12:48 +0000 schrieb Aristo Chen: > > > This patch adds a validation step in mkimage to detect memory region > > > overlaps between images specified in the same configuration of a > > > FIT image. If any overlaps are found, the tool prints an error and > > > aborts the build. > > > > > > This helps prevent runtime memory corruption caused by conflicting > > > load addresses between images. > > > > > > Signed-off-by: Aristo Chen <aristo.c...@canonical.com> > > > --- > > > tools/fit_image.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++ > > > tools/mkimage.c | 3 +- > > > 2 files changed, 80 insertions(+), 1 deletion(-) > > > > > > diff --git a/tools/fit_image.c b/tools/fit_image.c > > > index 331be5ae71d..d0061adf051 100644 > > > --- a/tools/fit_image.c > > > +++ b/tools/fit_image.c > > > @@ -22,6 +22,22 @@ > > > #include <version.h> > > > #include <u-boot/crc.h> > > > > > > +#define MAX_IMAGES_PER_CONFIG 16 > > > > How did you get this number? > > > > If this is arbitrary, add to the error message below that if someone needs > > more > > images, they can increase the size. > Yes, it is an arbitrary number, I am planning to dynamically allocate > the memory to solve this concern. Otherwise, > we may need to add a new variable to allow the user to modify the > value of the variable? >
Dynamic allocation sounds fine, then.