Hi Rasmus,
On 2026-07-10T12:36:12, Rasmus Villemoes <[email protected]> wrote:
> k3-binman.dtsi: add keyfile_template node
>
> Currently, it is somewhat tedious for downstream/custom boards to
> override the keyfile used for signing all the various artifacts
> involved in booting on K3 devices to point at their own key (or
> pkcs#11 uri for that matter). One has to have overrides in one's .dtsi
> for each and every ti-secure / ti-secure-rom node, and a lot of those
> do not even have dts labels, so one has to use their full
> /binman/... path.
>
> Add a small dedicated template that only contains the keyfile
> property. In a subsequent patch, we will change nodes that contain an
> explicit 'keyfile = 'custMpk.pem'' to instead have this template
> inserted. This way, the downstream board's .dtsi file only needs to
> contain something like
>
> &keyfile_template {
> keyfile = '/path/to/own/key.pem';
> };
>
> [...]
>
> arch/arm/dts/k3-binman.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
> @@ -25,6 +25,10 @@
> +
> + keyfile_template: template-keyfile {
> + keyfile = 'custMpk.pem';
> + };
This looks good: since merge_props() only copies properties missing
from the target node, an explicit keyfile in a ti-secure node still
takes precedence, as your cover letter says.
Since the whole point is discoverability, please can you also mention
this in doc/board/ti/k3.rst, which already discusses signing with
custMpk? A short note showing the
&keyfile_template {
keyfile = "/path/to/own/key.pem";
};
override would help people find it without reading the dtsi.
Reviewed-by: Simon Glass <[email protected]>
Regards,
Simon
