Hi Quentin, On Fri, 7 Nov 2025 at 16:07, Quentin Schulz <[email protected]> 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
