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

[Greg Malysa]

Hi Simon,

On Fri, May 15, 2026 at 4:58 PM Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Mon, 4 May 2026 at 06:16, Simon Glass <sjg at chromium.org> 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