[PATCH 00/13] Generate Android boot images with binman
Sam Day
me at samcday.com
Sun Jun 7 23:52:36 CEST 2026
Hello,
On Monday, 8 June 2026 at 12:48 AM, 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.
>
> >
> >>
> >> 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.
>
> >
> >>
> >> 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.
Acknowledged. I'll resend this series scoped to Exynos only and hope that
you're no longer a gatekeeper for Qualcomm in future.
-Sam
>
> Kind regards,
> // Casey>
> >>
> >> This way it avoids the need to add stuff to the dtb, you can just parse
> >> `u-boot.dtb` to determine the device and pick the right config.
> >>
> >> [1]:
> >> https://lore.kernel.org/u-boot/20250722-b4-qcom-tooling-improvements-v5-0-df143f1247fc@linaro.org/
> >>
> >> [2]:
> >> https://lore.kernel.org/u-boot/20260511-b4-qcom-tooling-improvements-v7-0-0c06346e79a9@linaro.org/
> >
> > I wonder if maybe the ELF wrangling in particular was cursed? I had absolutely
> > no issues using binman and getting it to produce native binaries for a
> > half-dozen disparate devices.
> >
> > Cheers,
> > -Sam
> >>
> >>>
> >>> Put differently: an overwhelming majority of these pocket computer
> >>> devices have a "canonical" payload format that U-Boot currently has no
> >>> support for. Let's fix that.
> >>>
> >>> The first patches in this series introduce an `android_boot` etype. To
> >>> begin with, this is a "typical" abootimg, as defined by canonical AOSP
> >>> sources and reference `fastboot`/`mkbootimg` implementation. There's
> >>> plenty of devices out there with a sane(-ish, nothing in Android-land is
> >>> ever truly sane) bootloader that will happily chain a U-Boot rolled into
> >>> the kernel section of an abootimg.
> >>>
> >>> With that out of the way, the cursed bootloaders are next to be
> >>> supported. Binman etypes for Qualcomm's "QCDT" and Samsung's "DTBH"
> >>> formats are implemented. These are non-standard vendor-specific
> >>> devicetree containers, which the previous bootloader uses to pick a FDT
> >>> to boot the downstream with.
> >>>
> >>> In both cases, these vendor-specific formats are tacked on to the end of
> >>> a v0 abootimg, with the header_version being hijacked to encode the
> >>> length of this following payload. Thus, the android_boot etype is
> >>> retrofitted to allow these shenanigans.
> >>>
> >>> Binman configs that produce flashable boot artifacts are introduced for
> >>> the following devices:
> >>>
> >>> * google-sargo (vanilla v2)
> >>> * oneplus-fajita (vanilla v2)
> >>> * samsung-a5u-eur (QCDT v0)
> >>> * samsung-gt510 (QCDT v0)
> >>> * samsung-j7xelte (DTBH v0)
> >>>
> >>> I also successfully tested a vanilla v0 on my samsung-expressltexx, in
> >>> conjunction with the qcom-armv7 series already on the list. However,
> >>> since that work is still in-flight and the expressltexx DTS is
> >>> downstream, I opted not to include it here.
> >>>
> >>> Signed-off-by: Sam Day <me at samcday.com>
> >>> ---
> >>> Sam Day (13):
> >>> binman: Android boot image support
> >>> .gitignore: ignore binman-generated blobs
> >>> arch: arm: qcom: google-sargo binman config
> >>> qcom: arch: arm: qcom: sdm845-fajita binman configs
> >>> mach-snapdragon: enable BINMAN
> >>> binman: android_boot: vendor-dt support
> >>> binman: Add QCDT support
> >>> binman: android_boot: SEANDROIDENFORCE support
> >>> arch: arm: qcom: samsung-a5u-eur binman config
> >>> arch: arm: qcom: samsung-gt510 binman config
> >>> binman: Add DTBH support
> >>> arch: arm: exynos: add j7xelte binman config
> >>> configs: exynos-mobile: pull in BINMAN
> >>>
> >>> .gitignore | 1 +
> >>> arch/arm/Kconfig | 1 +
> >>> arch/arm/dts/exynos-mobile.dtsi | 5 +
> >>> arch/arm/dts/exynos7870-j7xelte-u-boot.dtsi | 24 ++
> >>> arch/arm/dts/msm8916-samsung-a5u-eur-u-boot.dtsi | 39 ++
> >>> arch/arm/dts/msm8916-samsung-gt510-u-boot.dtsi | 39 ++
> >>> arch/arm/dts/qcom.dtsi | 5 +
> >>> arch/arm/dts/sdm670-google-sargo-u-boot.dtsi | 27 ++
> >>> arch/arm/dts/sdm845-oneplus-fajita-u-boot.dtsi | 25 ++
> >>> arch/arm/mach-exynos/Kconfig | 1 +
> >>> configs/exynos-mobile_defconfig | 1 +
> >>> configs/qcom_defconfig | 1 +
> >>> tools/binman/etype/android_boot.py | 408 +++++++++++++++++++++
> >>> tools/binman/etype/dtbh.py | 173 +++++++++
> >>> tools/binman/etype/qcdt.py | 160 ++++++++
> >>> tools/binman/ftest.py | 127 +++++++
> >>> .../test/vendor/android_boot_seandroidenforce.dts | 22 ++
> >>> tools/binman/test/vendor/android_boot_v0.dts | 29 ++
> >>> tools/binman/test/vendor/android_boot_v2.dts | 46 +++
> >>> .../binman/test/vendor/android_boot_vendor_dt.dts | 27 ++
> >>> tools/binman/test/vendor/dtbh.dts | 29 ++
> >>> tools/binman/test/vendor/dtbh_bad_model_info.dts | 19 +
> >>> tools/binman/test/vendor/qcdt.dts | 20 +
> >>> tools/binman/test/vendor/qcdt_bad_msm_id.dts | 17 +
> >>> 24 files changed, 1246 insertions(+)
> >>> ---
> >>> base-commit: a4c8728f225b0d7d591fb9199ce7efb72f48290e
> >>> change-id: 20260604-android-binman-ad7a43f4e99d
> >>>
> >>> Best regards,
> >>
> >>
>
>
More information about the U-Boot
mailing list