Hi Casey, On Tuesday, 9 June 2026 at 10:10 PM, Casey Connolly <[email protected]> wrote:
> 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? 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? Thanks, -Sam > > > > > 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) > >
