Hi Simon, On 09/06/2026 01:31, Simon Glass wrote: > Hi Casey, > > On Mon, 8 Jun 2026 at 12:06, Casey Connolly <[email protected]> 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-df143f124...@linaro.org/ >>> [2] >>> https://patchwork.ozlabs.org/project/uboot/cover/20250612-b4-qcom-tooling-improvements-v3-0-76f34cf21...@linaro.org/ > > [3] https://www.youtube.com/watch?v=L84ujgUXBOQ -- // Casey (she/her)
