Binman with Qualcomm

[Tom Rini]

On Tue, Jun 09, 2026 at 12:33:50PM +0000, Sam Day wrote:
> Hi Casey,
> 
> On Tuesday, 9 June 2026 at 10:10 PM, 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?
> 
> Why are you jumping to this conclusion? I read Simon's response and didn't get
> LLM vibes from it...
> 
> Also, FWIW, point 5 seems like it has grammatical errors (though I am no
> English lit major!). Dunno if a machine would generate such a sentence.
> 
> But anyway, more importantly, what parts of Simon's summary, LLM-generated or no,
> do you agree or disagree with?
> 
> I read Simon's distillation of your feedback to date, and found it to be
> quite succinct and reasonable.
> 
> Whether you agree with the existence and/or usage of LLMs isn't really relevant
> here, is it? Simon began this thread attempting to solicit your concerns with
> binman so that we can connect that to tangible follow-up actions. Could we
> please focus on that?

I would find using an LLM to respond to this extremely rude, at minimum.
It says that someone can't be bothered to work on or engage with the
problem at hand. And I await Simon's answer, rather than further
speculating.


-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260609/3fa5eb86/attachment.sig>