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

[Simon Glass]

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.

Regards,
Simon