Hi Quentin, On 06/02/26 17:01, Quentin Schulz wrote: > Hi T, > > On 2/6/26 12:04 PM, T Pratham wrote: >> >> This series adds support to use a custom key provided via Make during >> build for signing the bootloader binaries, and updates the k3-binman to >> use it. >> > > Can't you use the same mechanism we have for adding the pubkey to the > SPL DTB (see tools/binman/etype/u_boot_spl_pubkey_dtb.py)? > > We use key-name-hint property which is a key filename without the .crt > extension, you don't necessarily need to reuse this (but I think it > makes sense) but sharing the logic for finding the key seems more > interesting to me. > > We try to find the key with tools.get_input_filename(self._key_name_hint > + ".crt"). The paths that are traversed can be specified with > BINMAN_INDIRS. This should help with not having to add yet another > variable. Set allow_missing to True and if it returns None, then use the > key listed in the filename property?
Thanks for this insight. Re-using the key finding mechanism from u_boot_spl_pubkey_dtb.py looks promising as well as clean. I'll look into this. > > Also, is there really a need for separate binman image just for keys? > Can't you have ti-secure/ti-secure-rom use key-name-hint directly to > avoid yet another binman entry? I have very little clue why our binman dtsi is creating a separate image for key. It existed since much before I touched U-Boot. ;-; The bigger picture in our use case is automating our internal Yocto builds with different signing algorithms (RSA, ECDSA) for the same SoC. This was the quicker and easier way to achieve this. I'll try some tinkering using BINMAN_INDIRS + key-name-hint mechanism by modifying ti-secure/ti-secure-rom. -- Regards T Pratham <[email protected]>
