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

[Casey Connolly]

On 5/22/25 21:51, Tom Rini wrote:
> On Thu, May 22, 2025 at 10:39:38PM +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 introduce a "u-boot.mbn" target in the
>> Makefile, this can be invoked to build a Qualcomm signed ELF image for
>> supported targets.
>>
>> 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 additionally
>> testing for other platforms would be super useful.
>>
>> [1]: https://github.com/msm8916-mainline/qtestsign
> 
> How much did you look in to having binman be what invokes a tool to
> do the signing? Thanks.

To be honest, I know very little about binman. I've done some reading 
now and on the surface it seems like it wants to solve the problem we 
have here, but I'm not sure it would make things here much cleaner.

As I understand it, I would remove the additions to 
mach-snapdragon/Makefile and instead have binman wrap mkmbn?

I can do this if it's preferred, but the abstraction feels a bit 
redundant in this case imo. Especially if it requires adding some 
"binman DTB" to tell binman which tool to use, we already know which 
tool to use because it's encoded in the make target ("u-boot.mbn").

>
-- 
Casey (she/they)