In-tree Python tools (patman, buildman, binman, etc.)

[Neha Malcom Francis]

On 16/05/26 03:24, Greg Malysa wrote:
> 
> I'm not sure if this is the place for this discussion, but I don't
> really understand the placement of binman. It seems like a meta build
> tool that combines multiple build artifacts into one, but integrating
> it as a build step in uboot is strange, since we might rely on TFA or
> even a kernel image that is built externally (which is what we tried
> to do originally for the ADI SoCs when we thought binman was a
> necessary part of getting the boards into mainline).
> 
> My ideal usage would be something like: in my yocto recipes I maintain
> configuration settings that are passed to uboot for any hardcoded
> addresses or offset, and I also fill in an image layout dts with those
> details (both happen programmatically from the single config), then I
> use binman instead of wic to create an image for my entire boot
> device, or just a FIT image for kernel+initramfs, and ideally I can
> integrate code signing or dm-verity immediately at this point, rather
> than some of the hacks I've had for it in the past. We tried to link
> some of the offsets and image details to Kconfigs at first to
> propagate from a single point of configuration, but binman is not
> selectable as part of a defconfig normally (I think?), so having
> dependencies and configuring the details in a normal way didn't really
> work and our result was pretty messy (and is being removed for that
> reason).
> 
> If my understanding is correct then it is a kind of competitor for the
> wic tool we use in our yocto builds. To be frank I don't like the wic
> input format and a device tree-based solution, especially with more
> options, would be a great alternative, but I think binman would need
> to be outside the tree for this to be the most useful. I don't know
> what buildroot uses by default but surely it could benefit from this
> kind of a tool for image assembly as well, especially if it emerges
> with the most robust set of capabilities.

I agree with binman having use cases that is not limited to U-Boot and
we are gatekeeping the tool by keeping it within U-Boot. There is
considerable signing use cases with HSMs [0] that can be extended to
non-U-Boot firmware packaging. But considering a huge chunk of U-Boot
currently depend on the in-tree tool for the build, this may be a longer
effort but I do think it should happen eventually.

[0]
https://osselcna2026.sched.com/event/2JQrn/leveraging-u-boot-binman-with-hardware-security-modules-hsm-for-secure-boot-riya-aysola-judith-mendez-texas-instruments

-- 
Thanking You
Neha Malcom Francis