[PATCH 00/13] Generate Android boot images with binman
Casey Connolly
casey.connolly at linaro.org
Sun Jun 7 16:48:05 CEST 2026
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.
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