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

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

[Simon Glass]

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.

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.

Regards,
Simon

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On Mon, May 04, 2026 at 06:16:58AM -0600, Simon Glass 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.
> 
> 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.

Given that as a project we've been encouraging people to switch to using
"b4" as it's now widely used and covers many of the problems patman was
designed to solve, I think that's an easy one to say that you should
move to your own personal hosting somewhere and it be untied from the
project. The rest of the tools are something we as a community can
figure out how to address once some of our general infrastructure issues
are unblocked and moving forward.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Mattijs Korpershoek]

Hi Simon,

On Mon, May 04, 2026 at 10:06, Tom Rini <trini@konsulko.com> wrote:

> On Mon, May 04, 2026 at 06:16:58AM -0600, Simon Glass 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.
>> 
>> 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.

First, thanks for maintaining those tools. I'm not an user of all of
them but I think they are great. Especially binman and buildman.

>
> Given that as a project we've been encouraging people to switch to using
> "b4" as it's now widely used and covers many of the problems patman was
> designed to solve, I think that's an easy one to say that you should
> move to your own personal hosting somewhere and it be untied from the
> project. The rest of the tools are something we as a community can
> figure out how to address once some of our general infrastructure issues
> are unblocked and moving forward.

I agree with Tom here. I think that moving patman out of the U-Boot tree
is a good choice. Personally, I'm a happy b4 user so I've never tried
patman.
Let's start ("small") with moving patman and see how things go from there?

>
> -- 
> Tom

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

[Quentin Schulz]

Hi Simon,

On 5/4/26 2:16 PM, Simon Glass 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.
> 

Even before b4 got released, I've never used patman, so I don't know 
what I'm missing out on but b4 has fixed all the gripes I had with 
git-format-patch+git-send-email so far.

What I can say though is that I cannot install the requirements for 
running tests on Fedora, for a few releases already, because patman is 
using an old pygit2 which doesn't compile with newer versions of libgit2.

Building wheels for collected packages: pygit2
   Building wheel for pygit2 (pyproject.toml) ... error
   error: subprocess-exited-with-error

   × Building wheel for pygit2 (pyproject.toml) did not run successfully.
   │ exit code: 1
   ╰─> [75 lines of output]
       running bdist_wheel
       running build
       running build_py
       creating build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/utils.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/submodules.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/settings.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/repository.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/remotes.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/refspec.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/references.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/packbuilder.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/legacyenums.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/index.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/filter.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/ffi.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/errors.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/enums.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/credentials.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/config.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/callbacks.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/branches.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/blob.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/blame.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/_run.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/_build.py -> build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/__init__.py -> 
build/lib.linux-x86_64-cpython-314/pygit2
       copying pygit2/_pygit2.pyi -> 
build/lib.linux-x86_64-cpython-314/pygit2
       creating build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/types.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/transport.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/submodule.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/strarray.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/stash.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/revert.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/repository.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/remote.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/refspec.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/proxy.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/pack.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/oid.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/net.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/merge.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/indexer.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/index.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/graph.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/errors.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/diff.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/describe.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/config.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/common.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/commit.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/clone.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/checkout.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/callbacks.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/buffer.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/blame.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       copying pygit2/decl/attr.h -> 
build/lib.linux-x86_64-cpython-314/pygit2/decl
       running build_ext
       generating cffi module 
'build/temp.linux-x86_64-cpython-314/pygit2._libgit2.c'
       creating build/temp.linux-x86_64-cpython-314
       building 'pygit2._pygit2' extension
       creating 
build/temp.linux-x86_64-cpython-314/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src
       gcc -fno-strict-overflow -Wsign-compare 
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions -fcf-protection 
-fexceptions -fcf-protection -fexceptions -fcf-protection -O3 -fPIC 
-I/usr/local/include -I/home/qschulz/work/upstream/u-boot/venv/include 
-I/usr/include/python3.14 -c 
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c 
-o 
build/temp.linux-x86_64-cpython-314/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.o
       In file included from 
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/diff.h:34,
                        from 
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c:31:
  
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/types.h:37:2: 
error: #error You need a compatible libgit2 version (1.7.x)
          37 | #error You need a compatible libgit2 version (1.7.x)
             |  ^~~~~
  
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c: 
In function ‘blob_filter_stream_write’:
  
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c:171:13: 
error: implicit declaration of function ‘git_error_set’; did you mean 
‘git_error_last’? [-Wimplicit-function-declaration]
         171 |             git_error_set(GIT_ERROR_OS, "failed to put 
chunk to queue");
             |             ^~~~~~~~~~~~~
             |             git_error_last
       error: command '/usr/lib64/ccache/gcc' failed with exit code 1
       [end of output]

   note: This error originates from a subprocess, and is likely not a 
problem with pip.
   ERROR: Failed building wheel for pygit2
Failed to build pygit2

and this essentially has requested I run the tests within the CI 
container, which I would prefer not to do if possible (I somehow managed 
to break my U-Boot local git repo once doing that).

> 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?
> 

I've only started to use buildman when I did tree-wide refactoring and 
needed to make sure I didn't break anything. It's however essential in 
CI. I don't think it's actively being developed at the moment (at least 
publicly in U-Boot ML) so maybe that's good enough?

Considering the changes made in your fork are as far as I could tell 
mostly developed by/with LLMs and that Tom has been pretty vocal against 
it, moving it outside of the U-Boot umbrella and thus lose "control" of 
what can or cannot be merged while still making use of it in U-Boot 
seems like something we may not want to do.

> 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.
> 

Is Binman actually currently used outside of U-Boot? It's one thing to 
support building other projects but if those projects aren't actually 
using it, I'm not sure it's a strong argument (though, the fact it's in 
U-Boot tree could be a major obstacle for other projects to easily 
incorporate it in their process).

Considering binman is an essential piece of SW for some architectures 
(e.g. Rockchip), I don't know if it makes sense to separate it right 
now. At least I don't see an immediate need for splitting it.

> 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.
> 

I think qconfig is used every now and then by Tom and it was helpful to 
me when doing refactoring and symbol renaming. It's lacking a feature 
for me but saw your article on qconfig being rewritten in your fork so 
was wondering whether to look at it now or if it would make it to the 
U-Boot ML at some point.

The feature I've found myself really wanting is to filter configs based 
on a symbol and then print the value of some symbols.

E.g. I've wanted in 
https://lore.kernel.org/u-boot/20260507-sys_rx_eth_buffer-no-net-v2-0-cd7ef934bf42@cherry.de/ 
to know what was the value of CONFIG_SYS_RX_ETH_BUFFER when 
CONFIG_FSL_ENETC is enabled. Same for CONFIG_TI_K3_NAVSS_UDMA and 
CONFIG_SYS_RX_ETH_BUFFER.

I don't think qconfig is an essential tool for U-Boot and could probably 
live outside of U-Boot. I believe the feature of this tool would be 
useful for any project using Kconfig (Linux kernel, Zephyr, U-Boot, 
Barebox, etc...). It however depends on buildman and u-boot pylib today, 
so maybe it's unnecessary complexity to move it out of U-Boot for now 
(and also makes it unusable for other projects?). I don't think there's 
a hurry moving this one to a different place, it's not really bothering 
me to have it in-tree.

> What do people think? Of all of these, patman would be the easiest to
> move, with the least impact on existing workflows.
> 

I think starting with patman would be nice :)

Cheers,
Quentin

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

[Simon Glass]

Hi,

On Mon, 4 May 2026 at 06:16, Simon Glass <sjg@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.
>
> 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 :-)

Barring any other comments, I'm going to try to set up a new project
on Github. Re u_boot_pylib, the easiest thing is to duplicate it,
particularly as the newer version includes claude libraries not useful
for mainline.

Regards,
Simon

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

[Greg Malysa]

Hi Simon,

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

Re: 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

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

[Simon Glass]

Hi,

On Mon, 4 May 2026 at 07:16, Simon Glass <sjg@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.
>
> 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.

Thank you to those who have commented on this thread.

Quentin, I think there is a mailing-list patch for the pygit2 problem. For
qconfig, your feature should be easy enough to implement. If you suggest a
syntax I could take a look.

I am considering moving all the major tools I wrote out of U-Boot, each
into its own project. As Neha points out, Binman is useful as a general
tool. Patman clearly is too. This leaves Buildman which is U-Boot-specific
in many ways, but it hardly seems sensible to keep just that one in-tree,
plus I have a substantial code-refactor and new feature to figure out how
to upstream. With some adjustments it could be used in other projects. The
qconfig tool is in a similar boat, particularly now that it can rebuild the
database in two seconds instead of a minute.

I also have some other tools I have written recently, both of which might
have generic application:
- pickman, an AI-powered cherry picker which could be applied to other
projects such as Linux (but it currently is tied to gitlab)
- codman, a simple source-code analyser which tells you what files and code
lines are actually built for a board

If I do take this path, I will need to figure out a way to make it easy to
install the tools for use with U-Boot. This could involve using 'pip
install, cloning a repo, or some other mechanism. I could use a PR workflow
rather than the mailing list, if that is easier.

Please do continue to send your thoughts on this. I cannot attend the call
next week but hope to join the next one.

Regards,
Simon

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

On Wed, May 20, 2026 at 07:38:17PM -0500, Simon Glass wrote:
> Hi,
> 
> On Mon, 4 May 2026 at 07:16, Simon Glass <sjg@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.
> >
> > 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.
> 
> Thank you to those who have commented on this thread.
> 
> Quentin, I think there is a mailing-list patch for the pygit2 problem. For
> qconfig, your feature should be easy enough to implement. If you suggest a
> syntax I could take a look.
> 
> I am considering moving all the major tools I wrote out of U-Boot, each
> into its own project. As Neha points out, Binman is useful as a general
> tool. Patman clearly is too. This leaves Buildman which is U-Boot-specific
> in many ways, but it hardly seems sensible to keep just that one in-tree,
> plus I have a substantial code-refactor and new feature to figure out how
> to upstream. With some adjustments it could be used in other projects. The
> qconfig tool is in a similar boat, particularly now that it can rebuild the
> database in two seconds instead of a minute.
> 
> I also have some other tools I have written recently, both of which might
> have generic application:
> - pickman, an AI-powered cherry picker which could be applied to other
> projects such as Linux (but it currently is tied to gitlab)
> - codman, a simple source-code analyser which tells you what files and code
> lines are actually built for a board
> 
> If I do take this path, I will need to figure out a way to make it easy to
> install the tools for use with U-Boot. This could involve using 'pip
> install, cloning a repo, or some other mechanism. I could use a PR workflow
> rather than the mailing list, if that is easier.
> 
> Please do continue to send your thoughts on this. I cannot attend the call
> next week but hope to join the next one.

You should plan to take care of patman outside of the project as we have
been working towards just using b4. The rest of the tooling that's
currently in tree will continue to be managed by the community at large,
and some of the suggestions I've made before will be looked at harder
again, but not likely until after we've migrated our Gitlab server to
OSU OSL hosting.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]