On Fri, May 23, 2025 at 12:07:06AM +0200, Casey Connolly wrote: > > > 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").
So, binman is the canonical tooling these days for doing this stuff, yes. Can you see what it would look like to integrate this that way instead for a comparison point? Thanks. -- Tom
signature.asc
Description: PGP signature
