Binman with Qualcomm

[Simon Glass]

Hi Casey,

On Tue, 9 Jun 2026 at 06:10, Casey Connolly <casey.connolly at linaro.org> wrote:
>
> Hi Simon,
>
> On 09/06/2026 01:31, Simon Glass wrote:
> > 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.
>
> Did you really just put my email through an LLM?

I copied my full reply (including your context) into Claude along with
some patchwork threads to make sure I had not missed any points you
raised in patchwork. It gave various suggestions which I think helped
avoid my bias creeping in and to improve the tone. I don't mind
avoiding that with your emails in future.

I suspect Gmail also highlighted various sections and I accepted some
of those changes too...in fact there are four suggestions in these two
paragraphs right now.

>
> >
> > 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.
>
> Well this is what it all comes down to I suppose. I have nothing against
> having a common framework, it just shouldn't be so opinionated on things
> that really aren't related to image processing.

Do you have any thoughts about improving / resolving the points above?
For example, you mentioned at one point that it should use yaml rather
than device tree. Perhaps we can discuss it on one of the calls, if
that is easier?

- Simon

>
> >
> > 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
>
> --
> // Casey (she/her)
>