I had to hunt down a difference between the FIT after running mkimage once and after running it twice. The use-case is typically U-Boot generating an unsigned FIT and then calling mkimage manually to sign it outside any build system.
The issue can be reproduced with the following make CROSS_COMPILE=aarch64-linux-gnu- BUILD_TAG= SOURCE_DATE_EPOCH=0 O=build/ringneck ringneck-px30_defconfig make CROSS_COMPILE=aarch64-linux-gnu- BUILD_TAG= SOURCE_DATE_EPOCH=0 O=build/ringneck -j`nproc` cd build/ringneck cp ./simple-bin.fit.itb ./simple-bin.foo.fit cp ./simple-bin.fit.itb ./simple-bin.foo2.fit BUILD_TAG= SOURCE_DATE_EPOCH=0 ./tools/mkimage -E -t -B 200 -F ./simple-bin.foo.fit BUILD_TAG= SOURCE_DATE_EPOCH=0 ./tools/mkimage -E -t -B 200 -F ./simple-bin.foo2.fit BUILD_TAG= SOURCE_DATE_EPOCH=0 ./tools/mkimage -E -t -B 200 -F ./simple-bin.foo2.fit then compare the output of dtc -I dtb -O dts simple-bin.foo.fit dtc -I dtb -O dts simple-bin.foo2.fit data-size and data-offset properties are swapped. While going through the code, I identified a few theoretical issues possibly triggered by not checking the return code of fdt_setprop so those are added. Not tested outside of building. Signed-off-by: Quentin Schulz <[email protected]> --- Quentin Schulz (3): mkimage: fit: do not overwrite fdt_setprop return value mkimage: fit: do not ignore fdt_setprop return code mkimage: fit: erase data-size property when importing data tools/fit_image.c | 40 +++++++++++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 7 deletions(-) --- base-commit: df4c18067fe04d42c9929d6c3565f8ec002b41f2 change-id: 20250923-mkimage-2-runs-data-size-c0c95705421c Best regards, -- Quentin Schulz <[email protected]>
