Binman with Qualcomm

[Casey Connolly]

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

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

-- 
// Casey (she/her)