Hi Tom, On Mon, 8 Jun 2026 at 08:26, Tom Rini <[email protected]> wrote: > > On Mon, Jun 08, 2026 at 07:00:23AM -0600, Simon Glass wrote: > > Hi Casey, > > > > On Sun, 7 Jun 2026 at 08:48, Casey Connolly <[email protected]> > > wrote: > > > > > > Hi Sam, > > > > > > On 6/7/26 01:05, Sam Day wrote: > > > > Salutations Casey, > > > > > > > > On Saturday, 6 June 2026 at 10:03 PM, Casey Connolly > > > > <[email protected]> wrote: > > > > > > > >> Hi Sam, > > > >> > > > >> On 6/6/26 02:52, Sam Day via B4 Relay wrote: > > > >>> U-Boot is seeing increasing adoption on pocket computers, many of > > > >>> which > > > >>> (sadly) have fused bootloader chains. Many of these bootloaders have a > > > >>> very rigid definition of what a "valid" downstream payload looks like. > > > >>> Sometimes it's just a boring old v0/v2 Android boot image. Sometimes > > > >>> it's something decidedly more grotesque. > > > >>> > > > >>> To date, this last-mile packaging step has been trapped in downstream > > > >>> CI > > > >>> pipelines, blogposts, documentation, etc. This patch series aims to > > > >>> gather up all that esoterica and institutional knowledge and codify it > > > >>> in U-Boot's build system, using binman. > > > >> > > > >> Awesome!!! :D > > > >> > > > >> So happy to see this being worked on, it's a huge benefit to have this > > > >> here in the build system. > > > >> > > > >> That said, I think we need a bit of discussion around binman, I > > > >> previously worked on using it for teaching the build system to emit > > > >> .mbn > > > >> files (see [1]), in the end getting binman to co-operate was a bunch of > > > >> really annoying work and I wound up with a sub-par result. > > > > > > > > Yes, I saw that series. I tried to engage you on Matrix about it a few > > > > days ago > > > > to get a sense for why you felt that binman was unsalvageable. I should > > > > have > > > > engaged you properly here on the list, that's my bad. > > > > > > > >> > > > >> The new approach which made a whole lot more sense is to use a vendor > > > >> Makefile fragment to add a custom build target, skip dealing with > > > >> binman > > > >> and just have the necessary info in Python (since adding a table entry > > > >> to a Python script is really no different to adding a binman DTB node). > > > >> That's in [2]. > > > > > > > > I would prefer to use binman. It's already well documented. It's > > > > already in > > > > use by countless other boards in U-Boot. I prefer maintaining DTSI's > > > > for the > > > > configuration DSL than some Python dicts. Also, at some point once > > > > enough > > > > devices have their native Android boot artifact described, there will be > > > > clear patterns that can be neatly tucked away into shared DTSI > > > > fragments. > > > > > > From my side, binman is a no-go for a bunch of reasons, polluting the > > > device dtb being a big one, the ability to debug and maintain it is also > > > not something i feel particularly confident about. Hence having a > > > standalone tool would be the appropriate way to go for this, I really > > > want to avoid having to learn this bespoke overly complex build tooling > > > when it's selling points aren't things that have much value for Qualcomm. > > > > Binman is the usual U-Boot way to build images. We should not be > > inventing new, custom ways of doing things, least of all more scripts. > > We should should be describing the image, not coding it. > > > > > > > > > > > > >> > > > >> I'm really not in favour of adding a binman node to the DTB that U-Boot > > > >> uses, and I think it's kinda dumb that this is the only sensible way to > > > >> configure binman today... > > > > > > > > I see nothing wrong with that. Can you expand on your concerns a little > > > > more? > > > > > > It really just goes against the goal of using upstream DT. Previously I > > > managed to get binman to parse its config from a separate DTB but that > > > was hellish to integrate the tooling for. > > > > > > Having this random node at runtime for completely unnecessary arbitrary > > > reasons feels just wrong to me. > > > > On some boards (e.g. x86) it is used at runtime to locate things. In > > any case it provides a clear indication of what is where, in data > > rather than code. We don't need to make it use a separate DT, so far > > as I can tell. > > > > > > > > > > > > >> > > > >> The way that mkmbn works is it just has all the device-specific config > > > >> in a dictionary where the key is the compatible string, it finds the > > > >> DTB > > > >> in the U-Boot image and gets the appropriate mbn config from there. > > > >> > > > >> I see you've clearly put a lot of effort into this, and I hate to ask > > > >> you to do a lot more, but I'd really like to avoid using binman, would > > > >> you be willing to rework this to put the config in Python and just have > > > >> a custom make target like in the mkmbn patches? You can probably base > > > >> it > > > >> on top. > > > > > > > > I'm definitely not interested in doing that. I would, however, be very > > > > willing > > > > to address any specific concerns you have with binman. > > > > > > That's a shame to hear> > > > > At any rate, if you want to NAK any binman usage in the qualcomm side, > > > > that's > > > > fair enough. Please let me know if you see absolutely no path forward, > > > > and I'll > > > > split the series to just focus on the binman etype impls and their > > > > usage on > > > > the Exynos side. That would be a bummer, but I'm intending to maintain a > > > > long-lived close-to-mainline downstream anyway, so I would continue > > > > widening > > > > the support there and hope that your opinion on binman changes in > > > > future :D > > > > > > I don't feel comfortable depending on binman for Qualcomm, so we'll > > > leave it there. > > > > I'd like to figure this out, particularly as Qualcomm is ramping up > > its U-Boot efforts. > > I believe the problems with binman and Qualcomm platforms have been well > enough documented and discussed in the thread where Casey attempted to > make it all work with binman and found how ill-suited it seemed to be, > unfortunately.
I found a few links so I'll start a new thread. Regards, Simon
