Binman with Qualcomm

[Simon Glass]

Hi Casey,

On Mon, 8 Jun 2026 at 12:06, Casey Connolly <casey.connolly at linaro.org> wrote:
>
> Hi Simon,
>
> On 08/06/2026 19:13, Simon Glass wrote:
> > Hi,
> >
> > I want to start a new thread to work through the issues which result
> > in later versions of [1] moving to custom build rules instead of
> > Binman.
> >
> > From what I understand there are some things unique to Qualcomm here,
> > as well as some general comments [2]
> >
> > Let's first get a list of the problems and then we can look at
> > possible solutions.
>
> I wrote a whole big reply here but then I realised it was not likely to
> be productive, so I'll keep it short and sweet.
>
> For binman to make any sense to me, it would be a very simple frontend
> and library for vendor/board specific image processing. Configuration
> would be static and defined in the Python scripts, dynamic configuration
> is huge scope creep.
>
> If that's all binman was, and it was co-maintained and used by other
> custodians then I would definitely see the value in using it to avoid
> dealing with makefile fragments and other nonsense.
>
> Instead, it is a massive and overbearing "feature" that does stupid
> stuff like pollute your boards DTB and ADD ADDITIONAL CODE TO U-BOOT
> (which crashed for me btw). The moment I try to use a tool for
> post-processing and it changes U-Boots runtime behaviour like this I am
> fully out. Choosing to design and implement something as overbearing as
> binman is just absurd, it prescribes a lot of functionality that I do
> not want or need. I'm just not willing to invest so much time figuring
> out how it works so I can fix it if it breaks something for my boards.
>
> As-is it seems much more appropriate to stay within my means and ensure
> that I feel confident that I can maintain whatever Qualcomm-specific
> tooling we have. Vendoring a Python tool and making a tiny wrapper for
> it is just the plainly obvious solution, I know exactly how it works, I
> can fix it if it breaks, and it doesn't fuck with my U-Boot image or dtb.
>
> That you are so clouded by your own perspective that you feel the need
> to email me on the list to ask about problems with binman as if I
> haven't already expressed myself clearly both in my mkmbn series and on
> irc (and as if comparing my patches doesn't reveal the issues) makes it
> quite clear that I'm much better off keeping CONFIG_BINMAN=n

Thanks for the candid response - I'd genuinely rather have the blunt
version than a polite one that leaves the real objections unsaid.

Starting a fresh thread wasn't meant to suggest you haven't already
explained yourself; it was to give the topic enough focus to actually
resolve it, rather than have it scattered across review comments and
IRC. I've read the mkmbn series and I want to make sure I've
understood the concerns correctly, so let me write them back to you as
a problem list and you can tell me where I've got it wrong:

1. Binman is too large and prescriptive - what you want is a thin
frontend/library, with configuration defined statically in Python
rather than driven dynamically from the DT.
2. It modifies the board DTB, which you don't want it touching.
3. It adds code to the U-Boot image that changes runtime behaviour -
and it crashed for you.
4. The maintenance cost is unacceptable: you can't be confident you
can fix it yourself when it breaks one of your boards.
5. A vendored Python script with a small wrapper gives you full
understanding and control, which a shared tool doesn't.

The runtime crash is the one I most want details on. Binman's runtime
support (reading its tables from the FDT) is optional and shouldn't be
pulled in for a board that doesn't ask for it - if it was, that's a
bug I want to find. Are you sure you have CONFIG_BINMAN_FDT disabled?

Perhaps Qualcomm's images are so simple that it isn't worth using
Binman. That was the view I took when I saw that you were just
creating an extra binary. But then I see Sam's series and I wonder
whether there is more to this?

There is considerable value in having all boards use the same
image-creation framework. The data-driver approach is much easier to
configure and understand. See [3] for a talk on why Binman helps.

I would be happy to take a look at this to see if I can figure out
these issues. Most SoCs that have moved to Binman have needed at least
some additions and changes in the tool and I don't mind digging into
the issues you have and coming up with proposals / solutions.

Regards,
Simon

> > [1] https://patchwork.ozlabs.org/project/uboot/patch/20250722-b4-qcom-tooling-improvements-v5-2-df143f1247fc@linaro.org/
> > [2] https://patchwork.ozlabs.org/project/uboot/cover/20250612-b4-qcom-tooling-improvements-v3-0-76f34cf216e2@linaro.org/

[3] https://www.youtube.com/watch?v=L84ujgUXBOQ