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)
