[PATCH v3 0/7] Qualcomm: teach the build system to emit signed ELF images

[Casey Connolly]

On 6/12/25 19:18, Tom Rini wrote:
> On Thu, Jun 12, 2025 at 04:16:36PM +0200, Casey Connolly wrote:
> 
>> With several new Qualcomm platforms appearing on the mailing list, all
>> of which build U-Boot as an ELF, sign it, and then flash it to some
>> partition on the board, we're getting a lot of defconfigs which just
>> contain a debug UART and a TEXT_BASE address. This leads to needless
>> rebuilds in CI of effectively the same image, and needless duplication
>> of build instructions.
>>
>> To address this, let's introduce a new tool "mkmbn.py", this is based
>> on the existing qtestsign[1] tool but is (currently) hardcoded to
>> only handle the Dragonwing and IPQ boards which use MBN header v6.
>> Additionally, the tool contains a lookup table that maps from a boards
>> DT compatible property to the load address it needs. Since it's highly
>> unusual for different boards using the same SoC to have different load
>> addresses, generic platform matching is also done (e.g. "qcom,qcm6490").
>>
>> With this tool in place, we teach binman to use it and introduce
>> a qcom-binman.dts file to describe the image. The tool will emit a
>> u-boot.mbn file for supported platforms, for unsupported platforms the
>> u-boot MBN etype in binman will print a notice explaining that no mbn
>> file is built and to look at tools/qcom/mkmbn/mkmbn.py
>>
>> Finally, the defconfigs are cleaned up by moving the debug UART
>> definitions to config fragments (since it doesn't make sense to have
>> them enabled by default anyway) and remove CONFIG_REMAKE_ELF. Notably,
>> the qcs9100_defconfig is removed entirely since the same binary can
>> be created with just make arguments. This platform entirely lacked
>> documentation to begin with, which should be addressed by future
>> patches.
>>
>> The Qualcomm documentation is also cleaned up, a new "signing" page
>> is added to briefly cover the what and why of MBN signing, and board
>> specific pages are updated to explain the new build process.
>>
>> These patches have been tested on the RB3 Gen 2, but additional
>> testing for other platforms would be super useful.
>>
>> [1]: https://github.com/msm8916-mainline/qtestsign
> 
> Thanks for switching this all over to binman. My big question is, is
> there binman documentation that you wished was clearer, or that should
> be written to make this easier for the next SoC / architecture that
> needs to come along and add to binman?

I think the goal of binman overall is good, having a single framework 
for building complicated firmware images is awesome and I appreciate the 
goal of cleaning up the makefiles.

That said, I think for our case at least, if the U-Boot build system had 
a nice way for us to write some rules in 
arch/arm/mach-snapdragon/Makefile to do everything (in a self-contained 
way) it would be a much clearer and simpler solution, not requiring 
folks to go and learn how this huge and quite complicated python tool 
works in order to debug or add features to mkmbn.py.

I also think using devicetree for configuration is a really strange 
choice. YAML would have been much better, faster, cleaner, and more 
readable. It's also entirely possible (trivial?) to convert DT to YAML 
and vice versa, so whatever needs there are to pass this config into 
U-Boot at runtime could be met this way instead (though I firmly believe 
that having the entire binman config be available at runtime is a huge 
layering violation, and we should have a better approach to make 
available whatever /specific/ properties need to be passed in, but 
that's just my opinion having not looked at this in detail).

Practically speaking, I'm not sure what I'd suggest here, it's easy to 
advocate for doing something entirely new and I think I'd need to have a 
deeper understanding of binman to make any concrete suggestions.

Kind regards,

-- 
Casey (she/they)