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
