[PATCH 00/13] Generate Android boot images with binman
Sam Day
me at samcday.com
Sun Jun 7 01:05:07 CEST 2026
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.
>
> 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?
>
> 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.
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
>
> 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