Binman creates a single image 4 times

[Simon Glass]

Hi Quentin,

On Fri, 7 Nov 2025 at 16:07, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi all,
>
> I'm signing U-Boot FIT images with binman and that takes some time. If I
> build twice in a row without any change, the build process takes about
> 15 seconds, most of it spent in pselect6() according to strace. I have
> yet to discover if it's related to the engine or mkimage or even OpenSSL
> itself. Anyway, nobody likes waiting and it differed from my pre-binman
> U-Boot enough that I "dug" a bit.
>
> Even when not signing, with
> https://elixir.bootlin.com/u-boot/v2025.10/source/tools/binman/bintool.py#L294
> used to report all calls to bintools made by Binman while building the
> image, the expected bintool calls are all unexpectedly (to me) made 4 times:
>
> bintool: mkimage -d
> ./mkimage-in-simple-bin.mkimage-u-boot-tpl:./mkimage-in-simple-bin.mkimage-section
> -n px30 -T rksd ./idbloader.img
> bintool: mkimage -E -B 200 -t -F ./simple-bin.fit.fit
> bintool: mkimage -d
> ./mkimage-in-simple-bin.mkimage-u-boot-tpl:./mkimage-in-simple-bin.mkimage-section
> -n px30 -T rksd ./idbloader.img
> bintool: mkimage -E -B 200 -t -F ./simple-bin.fit.fit
> bintool: mkimage -E -B 200 -t -F ./simple-bin.fit.fit
> bintool: mkimage -d
> ./mkimage-in-simple-bin.mkimage-u-boot-tpl:./mkimage-in-simple-bin.mkimage-section
> -n px30 -T rksd ./idbloader.img
> bintool: mkimage -d
> ./mkimage-in-simple-bin.mkimage-u-boot-tpl:./mkimage-in-simple-bin.mkimage-section
> -n px30 -T rksd ./idbloader.img
> bintool: mkimage -E -B 200 -t -F ./simple-bin.fit.fit
>
> (in that order).
>
> Printing the stack, it seems like:
> - 2 calls are made from
> https://elixir.bootlin.com/u-boot/v2025.10/source/tools/binman/control.py#L789
> - 1 call from
> https://elixir.bootlin.com/u-boot/v2025.10/source/tools/binman/control.py#L802
> - 1 call from
> https://elixir.bootlin.com/u-boot/v2025.10/source/tools/binman/control.py#L813
>
> Is that intended/expected?
>
> Can be easily reproduced by building ringneck-px30_defconfig for example.

This isn't good, but I was sort-of aware of it. We actually don't have
tests for the number of passes needed to produce an image.

Certainly the contents of a section don't need to be regenerated
unless something changed. To a certain extent some changes are
tracked, but I think the original intent has been lost over time. If
you'd like to give it a try, the first thing might be a way to track
calls to BuildSectionData() and then adding a check that the count is
1 (or whatever) in a few tests in ftest.py

Regards,
Simon