Binman with Qualcomm

[Casey Connolly]

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?

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

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