Hello, On Monday, 8 June 2026 at 12:48 AM, Casey Connolly <[email protected]> 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 > > <[email protected]> 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-df143f124...@linaro.org/ > >> > >> [2]: > >> https://lore.kernel.org/u-boot/20260511-b4-qcom-tooling-improvements-v7-0-0c06346e7...@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 <[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, > >> > >> > >
