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.
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'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...
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.
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-df143f124...@linaro.org/
[2]:
https://lore.kernel.org/u-boot/20260511-b4-qcom-tooling-improvements-v7-0-0c06346e7...@linaro.org/
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 <[email protected]>
---
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,
