Hi Simon, On Fri, May 15, 2026 at 4:58 PM Simon Glass <[email protected]> wrote: > > Hi, > > On Mon, 4 May 2026 at 06:16, Simon Glass <[email protected]> wrote: > > > > Hi, > > > > As you know, I maintain several tools which are part of the U-Boot tree. > > > > Tom has previously suggested that it would be better to move patman > > out of the U-Boot tree, e.g. to its own Github project. It is a > > general tool which can be used with Linux and other > > mailing-list/patchwork-based projects. I have never been keen on > > taking on the extra effort required, but I've recently added more > > features and am wondering whether now might be a good time to do this. > > > > Buildman is quite obviously designed specifically for U-Boot. I have > > made some improvements recently (a large code refactor and distributed > > builds). I would like to push those changes to mainline. Do people > > think it should be in a separate tree somewhere? > > > > Binman was written with U-Boot in mind but supports other projects > > (such as Zephyr). It is generic enough that it could be separated. The > > impact would be harder code review.
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. > > > > We also have smaller things like qconfig (which I have substantially > > rewritten to make it fast) and dtoc, which is very tailored to U-Boot. > > > > What do people think? Of all of these, patman would be the easiest to > > move, with the least impact on existing workflows. > > Are there any actualy patman users on the list who have an opinion? So > far the replies are from people who don't actually use it :-) I've been using patman to submit all of the ADI patches I've sent and the results have mostly looked good, and I have encouraged the team at Analog to do the same, although I know they are using/have tried to use b4 (with some misfires we've been working on along the way). b4 seems to be a bit more complicated to configure properly in exchange for more powerful features for subsystem maintainers especially, but I have not tried it so I cannot speak to a real comparison. Patman being present in the tree has made it very easy to use, but I see the value of maintaining it separately, as it doesn't really affect any part of the uboot source itself. However, newcomers who do not yet use b4 may find it simpler to work with, so in my opinion it is desirable to keep it accessible in some way. I'm very unfamiliar with the python ecosystem, but is there a way to provide some kind of reference list where I might be able to clone the uboot repository and then with one command install suggested python tools that live externally, perhaps under the tools directory still? If it is too far removed or requires too many commands to make available, nobody will use it. Thanks, Greg
