[PATCH 00/13] Generate Android boot images with binman

[Simon Glass]

Hi Tom,

On Mon, 8 Jun 2026 at 08:26, Tom Rini <trini at konsulko.com> 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 <casey.connolly at linaro.org> 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 <casey.connolly at linaro.org> 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