[PATCH 0/6] k3-binman ergonomics

[PATCH 0/6] k3-binman ergonomics

[Rasmus Villemoes]

When trying to hook up use of a customer's own signing infrastructure
for some am62x devices, I found it was more difficult than it should
be to point at the right key(s). One has to patch in the keyfile=
property in way too many places, and if you miss just one, the build
succeeds using the generic custMpk.pem for the one you missed, but of
course the resulting artifacts are unbootable.

Use the template mechanism that binman already has to allow one to
only set the keyfile= in a single place. I cannot really imagine any
case where one would not want to use the same key for signing all
artifacts across the r5/a53 cores, but that is of course still
possible, just as any downstreams that have explicit

&{/binman/tiboot3-am62x-hs-evm.bin/ti-secure-rom} {
    keyfile = "foobar.pem";
};

&{/binman/tiboot3-am62x-hs-fs-evm.bin/ti-secure-rom} {
    keyfile = "foobar.pem";
};

will continue to work.

Rasmus Villemoes (6):
  binman: openssl: refactor creation of Distinguished Name section from
    dict
  binman: x509_cert: allow and parse distinguished-name subnode
  binman: x509: fix CN emitted for basic x509 certificates
  k3-binman.dtsi: add keyfile_template node
  k3-binman.dtsi: add empty distinguished_name_template
  k3-binman.dtsi: insert keyfile and distinguished name templates in all
    ti-secure(-rom) nodes

 arch/arm/dts/k3-binman.dtsi              | 34 +++++++++++-----
 tools/binman/btool/openssl.py            | 51 ++++++++----------------
 tools/binman/etype/ti_secure.py          |  3 +-
 tools/binman/etype/ti_secure_rom.py      |  3 +-
 tools/binman/etype/x509_cert.py          |  8 +++-
 tools/binman/test/security/x509_cert.dts |  5 ++-
 6 files changed, 55 insertions(+), 49 deletions(-)

-- 
2.55.0

[PATCH 1/6] binman: openssl: refactor creation of Distinguished Name section from dict

[Rasmus Villemoes]

Instead of manually expanding the req_dist_name_dict, create a helper
function for creating a config section from any dict. That will also
automatically allow other fields to be emitted.

Eventually, we could allow the values to not necesssarily be a single
string, but a list of strings, e.g. "OU" -> ["First OU", "Secound OU"],
and encode that in the config file using

  1.OU = First OU
  2.OU = Second OU

as documented in 'man 5 config'.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 tools/binman/btool/openssl.py | 44 +++++++++++------------------------
 1 file changed, 14 insertions(+), 30 deletions(-)

diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index b26f087c447..370760ccaa5 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -36,6 +36,14 @@ class Bintoolopenssl(bintool.Bintool):
             name, 'openssl cryptography toolkit',
             version_regex=r'OpenSSL (.*) \(', version_args='version')
 
+    def dict_to_config_section(self, section_name, d):
+        if not d:
+            return ''
+        s = f'[ {section_name} ]\n'
+        for field, value in d.items():
+            s += f'{field:22s} = {value}\n'
+        return s
+
     def x509_cert(self, cert_fname, input_fname, key_fname, cn, revision,
                   config_fname):
         """Create a certificate
@@ -92,8 +100,7 @@ imageSize              = INTEGER:{len(indata)}
             sw_rev (int): Software revision
             config_fname (str): Filename to write fconfig into
             req_dist_name_dict (dict): Dictionary containing key-value pairs of
-            req_distinguished_name section extensions, must contain extensions for
-            C, ST, L, O, OU, CN and emailAddress
+            req_distinguished_name section extensions
             firewall_cert_data (dict):
               - auth_in_place (int): The Priv ID for copying as the
                 specific host in firewall protected region
@@ -114,14 +121,7 @@ x509_extensions        = v3_ca
 prompt                 = no
 dirstring_type         = nobmp
 
-[ req_distinguished_name ]
-C                      = {req_dist_name_dict['C']}
-ST                     = {req_dist_name_dict['ST']}
-L                      = {req_dist_name_dict['L']}
-O                      = {req_dist_name_dict['O']}
-OU                     = {req_dist_name_dict['OU']}
-CN                     = {req_dist_name_dict['CN']}
-emailAddress           = {req_dist_name_dict['emailAddress']}
+{self.dict_to_config_section('req_distinguished_name', req_dist_name_dict)}
 
 [ v3_ca ]
 basicConstraints       = CA:true
@@ -163,8 +163,7 @@ numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
             sw_rev (int): Software revision
             config_fname (str): Filename to write fconfig into
             req_dist_name_dict (dict): Dictionary containing key-value pairs of
-            req_distinguished_name section extensions, must contain extensions for
-            C, ST, L, O, OU, CN and emailAddress
+            req_distinguished_name section extensions
             cert_type (int): Certification type
             bootcore (int): Booting core
             bootcore_opts(int): Booting core option, lockstep (0) or split (2) mode
@@ -184,14 +183,7 @@ numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
  prompt                 = no
  dirstring_type         = nobmp
 
- [ req_distinguished_name ]
-C                      = {req_dist_name_dict['C']}
-ST                     = {req_dist_name_dict['ST']}
-L                      = {req_dist_name_dict['L']}
-O                      = {req_dist_name_dict['O']}
-OU                     = {req_dist_name_dict['OU']}
-CN                     = {req_dist_name_dict['CN']}
-emailAddress           = {req_dist_name_dict['emailAddress']}
+{self.dict_to_config_section('req_distinguished_name', req_dist_name_dict)}
 
  [ v3_ca ]
  basicConstraints = CA:true
@@ -252,8 +244,7 @@ emailAddress           = {req_dist_name_dict['emailAddress']}
             sw_rev (int): Software revision
             config_fname (str): Filename to write fconfig into
             req_dist_name_dict (dict): Dictionary containing key-value pairs of
-            req_distinguished_name section extensions, must contain extensions for
-            C, ST, L, O, OU, CN and emailAddress
+            req_distinguished_name section extensions
             cert_type (int): Certification type
             bootcore (int): Booting core
             load_addr (int): Load address of image
@@ -274,14 +265,7 @@ x509_extensions        = v3_ca
 prompt                 = no
 dirstring_type         = nobmp
 
-[ req_distinguished_name ]
-C                      = {req_dist_name_dict['C']}
-ST                     = {req_dist_name_dict['ST']}
-L                      = {req_dist_name_dict['L']}
-O                      = {req_dist_name_dict['O']}
-OU                     = {req_dist_name_dict['OU']}
-CN                     = {req_dist_name_dict['CN']}
-emailAddress           = {req_dist_name_dict['emailAddress']}
+{self.dict_to_config_section('req_distinguished_name', req_dist_name_dict)}
 
 [ v3_ca ]
 basicConstraints = CA:true
-- 
2.55.0

Re: [PATCH 1/6] binman: openssl: refactor creation of Distinguished Name section from dict

[Simon Glass]

Hi Rasmus,

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
> binman: openssl: refactor creation of Distinguished Name section from dict
>
> Instead of manually expanding the req_dist_name_dict, create a helper
> function for creating a config section from any dict. That will also
> automatically allow other fields to be emitted.
>
> Eventually, we could allow the values to not necesssarily be a single
> string, but a list of strings, e.g. 'OU' -> ["First OU", "Secound OU"],
> and encode that in the config file using
>
>   1.OU = First OU
>   2.OU = Second OU
>
> as documented in 'man 5 config'.
>
> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>
> tools/binman/btool/openssl.py | 44 ++++++++++++++-----------------------------
>  1 file changed, 14 insertions(+), 30 deletions(-)

> Eventually, we could allow the values to not necesssarily be a single
> string, but a list of strings, e.g. 'OU' -> ["First OU", "Secound OU"],

Two typos: 'necesssarily' and 'Secound'

> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> @@ -36,6 +36,14 @@ class Bintoolopenssl(bintool.Bintool):
> +    def dict_to_config_section(self, section_name, d):

Please can you add a docstring with Args and Returns, as with the
other methods in this file? Since the method does not use 'self' it
could be a @staticmethod, and a more descriptive name than 'd' would
help, e.g. data

> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> @@ -36,6 +36,14 @@ class Bintoolopenssl(bintool.Bintool):
> +        if not d:
> +            return ''

At this point in the series no caller can pass an empty dict, since
ti_secure and ti_secure_rom always set up the full dict, so this
branch is dead code here - for me it shows up as uncovered in
'binman test -T', which requires 100% coverage.

Regards,
Simon

Re: [PATCH 1/6] binman: openssl: refactor creation of Distinguished Name section from dict

[Neha Malcom Francis]

On Fri, 10 Jul 2026 14:36:13 +0200, Rasmus Villemoes <ravi@prevas.dk> wrote:
> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> index b26f087c447..370760ccaa5 100644
> --- a/tools/binman/btool/openssl.py
> +++ b/tools/binman/btool/openssl.py
> @@ -36,6 +36,14 @@ class Bintoolopenssl(bintool.Bintool):
>              name, 'openssl cryptography toolkit',
>              version_regex=r'OpenSSL (.*) \(', version_args='version')
>  
> +    def dict_to_config_section(self, section_name, d):
> +        if not d:
> +            return ''

Either remove this dead code or perhaps return a bare section header instead
of an empty string so that config is at least structurally correct.

-- 
Neha Malcom Francis <n-francis@ti.com>

[PATCH 2/6] binman: x509_cert: allow and parse distinguished-name subnode

[Rasmus Villemoes]

Currently, the ti-secure and ti-secure-rom types hardcode the contents
of the Distinguished Name section. Those values are not necessarily
appropriate for all boards that just happen to include a SOC produced
by TI.

Allow placing a distinguished-name subnode inside the binman node
representing the Entry_x509_cert (or derived classes), and if present,
use that information.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 tools/binman/etype/ti_secure.py     | 3 ++-
 tools/binman/etype/ti_secure_rom.py | 3 ++-
 tools/binman/etype/x509_cert.py     | 5 +++++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
index f6caa0286d9..0d8ade9b634 100644
--- a/tools/binman/etype/ti_secure.py
+++ b/tools/binman/etype/ti_secure.py
@@ -117,7 +117,8 @@ class Entry_ti_secure(Entry_x509_cert):
             self.firewall_cert_data['auth_in_place'] = auth_in_place
             self.ReadFirewallNode()
         self.sha = fdt_util.GetInt(self._node, 'sha', 512)
-        self.req_dist_name = {'C': 'US',
+        if self.req_dist_name is None:
+            self.req_dist_name = {'C': 'US',
                 'ST': 'TX',
                 'L': 'Dallas',
                 'O': 'Texas Instruments Incorporated',
diff --git a/tools/binman/etype/ti_secure_rom.py b/tools/binman/etype/ti_secure_rom.py
index 7e90c655940..ec49fa51739 100644
--- a/tools/binman/etype/ti_secure_rom.py
+++ b/tools/binman/etype/ti_secure_rom.py
@@ -80,7 +80,8 @@ class Entry_ti_secure_rom(Entry_x509_cert):
             self.dm_data = fdt_util.GetBool(self._node, 'dm-data', False)
             if self.dm_data:
                 self.load_addr_dm_data = fdt_util.GetInt(self._node, 'load-dm-data', 0x00000000)
-        self.req_dist_name = {'C': 'US',
+        if self.req_dist_name is None:
+            self.req_dist_name = {'C': 'US',
                     'ST': 'TX',
                     'L': 'Dallas',
                     'O': 'Texas Instruments Incorporated',
diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
index b6e8b0b4fb0..ee4c74db6f9 100644
--- a/tools/binman/etype/x509_cert.py
+++ b/tools/binman/etype/x509_cert.py
@@ -61,6 +61,11 @@ class Entry_x509_cert(Entry_collection):
         self.key_fname = self.GetEntryArgsOrProps([
             EntryArg('keyfile', str)], required=True)[0]
         self.sw_rev = fdt_util.GetInt(self._node, 'sw-rev', 1)
+        dist_name_node = self._node.FindNode('distinguished-name')
+        if dist_name_node:
+            self.req_dist_name = dict()
+            for pname, prop in dist_name_node.props.items():
+                self.req_dist_name[pname] = prop.value
 
     def GetCertificate(self, required, type='generic'):
         """Get the contents of this entry
-- 
2.55.0

Re: [PATCH 2/6] binman: x509_cert: allow and parse distinguished-name subnode

[Simon Glass]

Hi Rasmus,

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
> binman: x509_cert: allow and parse distinguished-name subnode
>
> Currently, the ti-secure and ti-secure-rom types hardcode the contents
> of the Distinguished Name section. Those values are not necessarily
> appropriate for all boards that just happen to include a SOC produced
> by TI.
>
> Allow placing a distinguished-name subnode inside the binman node
> representing the Entry_x509_cert (or derived classes), and if present,
> use that information.
>
> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>
> tools/binman/etype/ti_secure.py     | 3 ++-
>  tools/binman/etype/ti_secure_rom.py | 3 ++-
>  tools/binman/etype/x509_cert.py     | 5 +++++
>  3 files changed, 9 insertions(+), 2 deletions(-)

> diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
> @@ -61,6 +61,11 @@ class Entry_x509_cert(Entry_collection):
> +        dist_name_node = self._node.FindNode('distinguished-name')
> +        if dist_name_node:
> +            self.req_dist_name = dict()
> +            for pname, prop in dist_name_node.props.items():
> +                self.req_dist_name[pname] = prop.value

Please can you document the new distinguished-name subnode in the
class docstring, since the entry documentation is generated from
these docstrings?

The ti-secure and ti-secure-rom docstrings should mention it too,
along with a note that it overrides the default TI values.

Also, this iterates the raw props, so a property with no value (a
boolean) or one with multiple strings ends up formatted as 'True' or
as a Python list in the openssl config. I suspect it is worth
validating that each value is a single string and raising an error
otherwise, at least until the multi-value support mentioned in patch
1 is added. What do you think?

Regards,
Simon

[PATCH 3/6] binman: x509: fix CN emitted for basic x509 certificates

[Rasmus Villemoes]

I'm pretty sure it was never the intention to emit the output
filename (cert_fname) as the value of the CN distinguished name.

The cert-ca property was parsed from the dts node, stored in
._cert_ca, passed on as the cn argument to x509_cert(), but then not
used at all.

Now that we always read a distinguished-name subnode if present, use
that method instead.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 tools/binman/btool/openssl.py            | 7 +++----
 tools/binman/etype/x509_cert.py          | 3 +--
 tools/binman/test/security/x509_cert.dts | 5 ++++-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index 370760ccaa5..7ad1d7a1aaa 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -44,8 +44,8 @@ class Bintoolopenssl(bintool.Bintool):
             s += f'{field:22s} = {value}\n'
         return s
 
-    def x509_cert(self, cert_fname, input_fname, key_fname, cn, revision,
-                  config_fname):
+    def x509_cert(self, cert_fname, input_fname, key_fname, req_dist_name_dict,
+                  revision, config_fname):
         """Create a certificate
 
         Args:
@@ -68,8 +68,7 @@ x509_extensions        = v3_ca
 prompt                 = no
 dirstring_type         = nobmp
 
-[ req_distinguished_name ]
-CN                     = {cert_fname}
+{self.dict_to_config_section('req_distinguished_name', req_dist_name_dict)}
 
 [ v3_ca ]
 basicConstraints       = CA:true
diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
index ee4c74db6f9..e072414a714 100644
--- a/tools/binman/etype/x509_cert.py
+++ b/tools/binman/etype/x509_cert.py
@@ -56,7 +56,6 @@ class Entry_x509_cert(Entry_collection):
 
     def ReadNode(self):
         super().ReadNode()
-        self._cert_ca = fdt_util.GetString(self._node, 'cert-ca')
         self._cert_rev = fdt_util.GetInt(self._node, 'cert-revision-int', 0)
         self.key_fname = self.GetEntryArgsOrProps([
             EntryArg('keyfile', str)], required=True)[0]
@@ -96,7 +95,7 @@ class Entry_x509_cert(Entry_collection):
                 cert_fname=output_fname,
                 input_fname=input_fname,
                 key_fname=self.key_fname,
-                cn=self._cert_ca,
+                req_dist_name_dict=self.req_dist_name,
                 revision=self._cert_rev,
                 config_fname=config_fname)
         elif type == 'sysfw':
diff --git a/tools/binman/test/security/x509_cert.dts b/tools/binman/test/security/x509_cert.dts
index 71238172717..ded0c2013c2 100644
--- a/tools/binman/test/security/x509_cert.dts
+++ b/tools/binman/test/security/x509_cert.dts
@@ -8,9 +8,12 @@
 
 	binman {
 		x509-cert {
-			cert-ca = "IOT2050 Firmware Signature";
 			cert-revision-int = <0>;
 			content = <&u_boot>;
+
+			distinguished-name {
+				CN = "IOT2050 Firmware Signature";
+			};
 		};
 
 		u_boot: u-boot {
-- 
2.55.0

Re: [PATCH 3/6] binman: x509: fix CN emitted for basic x509 certificates

[Simon Glass]

Hi Rasmus,

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
> binman: x509: fix CN emitted for basic x509 certificates
>
> I'm pretty sure it was never the intention to emit the output
> filename (cert_fname) as the value of the CN distinguished name.
>
> The cert-ca property was parsed from the dts node, stored in
> ._cert_ca, passed on as the cn argument to x509_cert(), but then not
> used at all.
>
> Now that we always read a distinguished-name subnode if present, use
> that method instead.
>
> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>
> tools/binman/btool/openssl.py            | 7 +++----
>  tools/binman/etype/x509_cert.py          | 3 +--
>  tools/binman/test/security/x509_cert.dts | 5 ++++-
>  3 files changed, 8 insertions(+), 7 deletions(-)

> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> @@ -68,8 +68,7 @@ x509_extensions        = v3_ca
> -[ req_distinguished_name ]
> -CN                     = {cert_fname}
> +{self.dict_to_config_section('req_distinguished_name', req_dist_name_dict)}

If the entry has no distinguished-name subnode, req_dist_name_dict is
None here (the ti-secure types fall back to their hardcoded defaults,
but the plain x509-cert type has no fallback).
dict_to_config_section() then returns an empty string, so the config
still says 'distinguished_name = req_distinguished_name' but the
section does not exist. I tried this and openssl fails with:

    Unable to get 'req_distinguished_name' section
    Error making certificate request

So this patch silently makes the subnode mandatory for the generic
type, with a rather cryptic build failure for anyone using x509-cert
without it (previously it worked, emitting the filename as CN).
Please can you either keep a fallback (e.g. CN = cert_fname as
before), or raise a proper error from the etype when the subnode is
missing, so the user gets a helpful message pointing at the node? A
test for the missing-subnode case would cover the 'if not d' branch
added in patch 1 too.

> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> @@ -44,8 +44,8 @@ class Bintoolopenssl(bintool.Bintool):
> -    def x509_cert(self, cert_fname, input_fname, key_fname, cn, revision,
> -                  config_fname):
> +    def x509_cert(self, cert_fname, input_fname, key_fname, req_dist_name_dict,
> +                  revision, config_fname):

The Args docstring below still documents 'cn (str): Common name' but
the parameter is now req_dist_name_dict, so please can you update it
to match, as done for the other functions in patch 1?

Regards,
Simon

[PATCH 4/6] k3-binman.dtsi: add keyfile_template node

[Rasmus Villemoes]

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";
  };

and that will then automatically propagate to all the nodes.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 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
index ad127663d03..69214bb32fb 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -25,6 +25,10 @@
 			filename = "arch/arm/mach-k3/keys/ti-degenerate-key.pem";
 		};
 	};
+
+	keyfile_template: template-keyfile {
+		keyfile = "custMpk.pem";
+	};
 };
 
 #ifndef CONFIG_ARM64
-- 
2.55.0

Re: [PATCH 4/6] k3-binman.dtsi: add keyfile_template node

[Simon Glass]

Hi Rasmus,

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> 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 <sjg@chromium.org>

Regards,
Simon

[PATCH 5/6] k3-binman.dtsi: add empty distinguished_name_template

[Rasmus Villemoes]

With the previous commit, "binman: x509_cert: allow and parse
distinguished-name subnode", it is possible for downstream boards to
put more appropriate values in the req_distinguished_name section in
the certificate being generated than the hard-coded TI
values. However, that requires adding a distinguished-name section to
each and every ti-secure or ti-secure-rom binman node.

In order to avoid lots of repetition and make it easier to just add
the information in one place, add an empty template-dist-name template
which we can inject in every such binman node. That makes no
difference for existing boards, but makes it possible for downstream
boards to simply do

    &distinguished_name_template {
        distinguished-name {
            C = "DK";
            ...
        };
    };

in their -u-boot.dtsi.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 arch/arm/dts/k3-binman.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 69214bb32fb..2c9e5b619b7 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -29,6 +29,16 @@
 	keyfile_template: template-keyfile {
 		keyfile = "custMpk.pem";
 	};
+
+	distinguished_name_template: template-dist-name {
+		/*
+		 * Empty, but allows downstreams to inject a
+		 * distinguished-name subnode with appropriate
+		 * contents from their -u-boot.dtsi, which will
+		 * propagate to all ti-secure(-rom) nodes including
+		 * this template.
+		 */
+	};
 };
 
 #ifndef CONFIG_ARM64
-- 
2.55.0

Re: [PATCH 5/6] k3-binman.dtsi: add empty distinguished_name_template

[Simon Glass]

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
> k3-binman.dtsi: add empty distinguished_name_template
>
> With the previous commit, "binman: x509_cert: allow and parse
> distinguished-name subnode", it is possible for downstream boards to
> put more appropriate values in the req_distinguished_name section in
> the certificate being generated than the hard-coded TI
> values. However, that requires adding a distinguished-name section to
> each and every ti-secure or ti-secure-rom binman node.
>
> In order to avoid lots of repetition and make it easier to just add
> the information in one place, add an empty template-dist-name template
> which we can inject in every such binman node. That makes no
> difference for existing boards, but makes it possible for downstream
> boards to simply do
>
>     &distinguished_name_template {
>         distinguished-name {
>             C = 'DK';
>             ...
>         };
>     };
>
> in their -u-boot.dtsi.
>
> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>
> arch/arm/dts/k3-binman.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH 6/6] k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes

[Rasmus Villemoes]

This should not make any functional difference, and downstream boards
that already override the keyfile property via an explicit .dtsi
fragment for each node will continue to have precedence over the value
coming from the template. But this makes it much more ergonomic to
have the keyfile and distinguished-name have consistent values
throughout, because one only has to override the values in the
templates and not each and every individual node.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 arch/arm/dts/k3-binman.dtsi | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 2c9e5b619b7..aca243f72f2 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -150,8 +150,8 @@
 					arch = "arm";
 					compression = "none";
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&board_cfg>;
-						keyfile = "custMpk.pem";
 					};
 					board_cfg: board-cfg {
 						filename = "board-cfg.bin";
@@ -165,8 +165,8 @@
 					arch = "arm";
 					compression = "none";
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&pm_cfg>;
-						keyfile = "custMpk.pem";
 					};
 					pm_cfg: pm-cfg {
 						filename = "pm-cfg.bin";
@@ -179,8 +179,8 @@
 					arch = "arm";
 					compression = "none";
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&rm_cfg>;
-						keyfile = "custMpk.pem";
 					};
 					rm_cfg: rm-cfg {
 						filename = "rm-cfg.bin";
@@ -193,8 +193,8 @@
 					arch = "arm";
 					compression = "none";
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&sec_cfg>;
-						keyfile = "custMpk.pem";
 					};
 					sec_cfg: sec-cfg {
 						filename = "sec-cfg.bin";
@@ -287,8 +287,8 @@
 					load = <CONFIG_K3_ATF_LOAD_ADDR>;
 					entry = <CONFIG_K3_ATF_LOAD_ADDR>;
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&atf>;
-						keyfile = "custMpk.pem";
 					};
 					atf: atf-bl31 {
 					};
@@ -303,8 +303,8 @@
 					load = <CONFIG_K3_OPTEE_LOAD_ADDR>;
 					entry = <CONFIG_K3_OPTEE_LOAD_ADDR>;
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&tee>;
-						keyfile = "custMpk.pem";
 					};
 					tee: tee-os {
 						optional;
@@ -330,8 +330,8 @@
 					load = <CONFIG_SPL_TEXT_BASE>;
 					entry = <CONFIG_SPL_TEXT_BASE>;
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&u_boot_spl_nodtb>;
-						keyfile = "custMpk.pem";
 
 					};
 					u_boot_spl_nodtb: blob-ext {
@@ -419,8 +419,8 @@
 					compression = "none";
 					load = <CONFIG_TEXT_BASE>;
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&u_boot_nodtb>;
-						keyfile = "custMpk.pem";
 					};
 					u_boot_nodtb: u-boot-nodtb {
 					};
@@ -521,8 +521,8 @@
 					load = <CONFIG_K3_ATF_LOAD_ADDR>;
 					entry = <CONFIG_K3_ATF_LOAD_ADDR>;
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&atf_falcon>;
-						keyfile = "custMpk.pem";
 					};
 					atf_falcon: atf-bl31 {
 					};
@@ -536,8 +536,8 @@
 					load = <CONFIG_K3_OPTEE_LOAD_ADDR>;
 					entry = <CONFIG_K3_OPTEE_LOAD_ADDR>;
 					ti-secure {
+						insert-template = <&keyfile_template>, <&distinguished_name_template>;
 						content = <&tee_falcon>;
-						keyfile = "custMpk.pem";
 					};
 					tee_falcon: tee-os {
 						optional;
-- 
2.55.0

Re: [PATCH 6/6] k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes

[Simon Glass]

Hi Rasmus,

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
> k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes
>
> This should not make any functional difference, and downstream boards
> that already override the keyfile property via an explicit .dtsi
> fragment for each node will continue to have precedence over the value
> coming from the template. But this makes it much more ergonomic to
> have the keyfile and distinguished-name have consistent values
> throughout, because one only has to override the values in the
> templates and not each and every individual node.
>
> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>
> arch/arm/dts/k3-binman.dtsi | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)

> k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes

I still see lots of custMpk.pem in .dtsi files after this series so
I'm not sure of the exact mechanism for your claim in this series. I
was expecting it to remove all of those?

> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
> @@ -330,8 +330,8 @@
>                                       ti-secure {
> +                                             insert-template = <&keyfile_template>, <&distinguished_name_template>;
>                                               content = <&u_boot_spl_nodtb>;
> -                                             keyfile = 'custMpk.pem';
>
>                                       };

Removing the keyfile property leaves a stray blank line before the
closing brace. Please can you drop that while you are at it?

Reviewed-by: Simon Glass <sjg@chromium.org>

Regards,
Simon

Re: [PATCH 6/6] k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes

[Rasmus Villemoes]

On Mon, Jul 13 2026, "Simon Glass" <sjg@chromium.org> wrote:

> Hi Rasmus,
>
> On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
>> k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes
>>
>> This should not make any functional difference, and downstream boards
>> that already override the keyfile property via an explicit .dtsi
>> fragment for each node will continue to have precedence over the value
>> coming from the template. But this makes it much more ergonomic to
>> have the keyfile and distinguished-name have consistent values
>> throughout, because one only has to override the values in the
>> templates and not each and every individual node.
>>
>> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>>
>> arch/arm/dts/k3-binman.dtsi | 20 ++++++++++----------
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>
>> k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes
>
> I still see lots of custMpk.pem in .dtsi files after this series so
> I'm not sure of the exact mechanism for your claim in this series. I
> was expecting it to remove all of those?

Well, changing those are not needed for my immediate purpose, I only
need those in k3-binman.dtsi to be updated, as that is the only upstream
file I include. Yes, they should probably all be updated, but I didn't
want to pollute this series with tons of mechanical changes, that can be
done as a followup if and when this lands. 

>> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
>> @@ -330,8 +330,8 @@
>>                                       ti-secure {
>> +                                             insert-template = <&keyfile_template>, <&distinguished_name_template>;
>>                                               content = <&u_boot_spl_nodtb>;
>> -                                             keyfile = 'custMpk.pem';
>>
>>                                       };
>
> Removing the keyfile property leaves a stray blank line before the
> closing brace. Please can you drop that while you are at it?

Of course.

Rasmus

Re: [PATCH 6/6] k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes

[Simon Glass]

Hi Rasmus,

On Mon, 13 Jul 2026 at 08:53, Rasmus Villemoes <ravi@prevas.dk> wrote:
>
> On Mon, Jul 13 2026, "Simon Glass" <sjg@chromium.org> wrote:
>
> > Hi Rasmus,
> >
> > On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:
> >> k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes
> >>
> >> This should not make any functional difference, and downstream boards
> >> that already override the keyfile property via an explicit .dtsi
> >> fragment for each node will continue to have precedence over the value
> >> coming from the template. But this makes it much more ergonomic to
> >> have the keyfile and distinguished-name have consistent values
> >> throughout, because one only has to override the values in the
> >> templates and not each and every individual node.
> >>
> >> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
> >>
> >> arch/arm/dts/k3-binman.dtsi | 20 ++++++++++----------
> >>  1 file changed, 10 insertions(+), 10 deletions(-)
> >
> >> k3-binman.dtsi: insert keyfile and distinguished name templates in all ti-secure(-rom) nodes
> >
> > I still see lots of custMpk.pem in .dtsi files after this series so
> > I'm not sure of the exact mechanism for your claim in this series. I
> > was expecting it to remove all of those?
>
> Well, changing those are not needed for my immediate purpose, I only
> need those in k3-binman.dtsi to be updated, as that is the only upstream
> file I include. Yes, they should probably all be updated, but I didn't
> want to pollute this series with tons of mechanical changes, that can be
> done as a followup if and when this lands.

Fair enough, thanks.

>
> >> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
> >> @@ -330,8 +330,8 @@
> >>                                       ti-secure {
> >> +                                             insert-template = <&keyfile_template>, <&distinguished_name_template>;
> >>                                               content = <&u_boot_spl_nodtb>;
> >> -                                             keyfile = 'custMpk.pem';
> >>
> >>                                       };
> >
> > Removing the keyfile property leaves a stray blank line before the
> > closing brace. Please can you drop that while you are at it?
>
> Of course.
>

Regards,
Simon

> Rasmus

Re: [PATCH 0/6] k3-binman ergonomics

[Anshul Dalal]

On Fri Jul 10, 2026 at 6:06 PM IST, Rasmus Villemoes wrote:
> When trying to hook up use of a customer's own signing infrastructure
> for some am62x devices, I found it was more difficult than it should
> be to point at the right key(s). One has to patch in the keyfile=
> property in way too many places, and if you miss just one, the build
> succeeds using the generic custMpk.pem for the one you missed, but of
> course the resulting artifacts are unbootable.
>

The default value for keyfile i.e custMpk.pem is generated via binman
from the custMpk node in binman (defined in k3-binman.dtsi), modifying
the filepath to your custom key should work as a single line change as
is.

Perhaps this could be made more clear by the use of a macro instead of
hardcoding the string "custMpk.pem" in all the places to make it more
obvious.

Other than that, the addition of configurable distinguished-name could
be valuable addition, do you have any specific use case asides from
downstream boards? I wonder if it could be valuable for existing
upstream platforms from Toradex/Phytec.

CC+: Francesco, Wadim

> Use the template mechanism that binman already has to allow one to
> only set the keyfile= in a single place. I cannot really imagine any
> case where one would not want to use the same key for signing all
> artifacts across the r5/a53 cores, but that is of course still
> possible, just as any downstreams that have explicit
>
> &{/binman/tiboot3-am62x-hs-evm.bin/ti-secure-rom} {
>     keyfile = "foobar.pem";
> };
>
> &{/binman/tiboot3-am62x-hs-fs-evm.bin/ti-secure-rom} {
>     keyfile = "foobar.pem";
> };
>
> will continue to work.
>
> Rasmus Villemoes (6):
>   binman: openssl: refactor creation of Distinguished Name section from
>     dict
>   binman: x509_cert: allow and parse distinguished-name subnode
>   binman: x509: fix CN emitted for basic x509 certificates
>   k3-binman.dtsi: add keyfile_template node
>   k3-binman.dtsi: add empty distinguished_name_template
>   k3-binman.dtsi: insert keyfile and distinguished name templates in all
>     ti-secure(-rom) nodes
>
>  arch/arm/dts/k3-binman.dtsi              | 34 +++++++++++-----
>  tools/binman/btool/openssl.py            | 51 ++++++++----------------
>  tools/binman/etype/ti_secure.py          |  3 +-
>  tools/binman/etype/ti_secure_rom.py      |  3 +-
>  tools/binman/etype/x509_cert.py          |  8 +++-
>  tools/binman/test/security/x509_cert.dts |  5 ++-
>  6 files changed, 55 insertions(+), 49 deletions(-)

Re: [PATCH 0/6] k3-binman ergonomics

[Rasmus Villemoes]

On Mon, Jul 13 2026, "Anshul Dalal" <anshuld@ti.com> wrote:

> On Fri Jul 10, 2026 at 6:06 PM IST, Rasmus Villemoes wrote:
>> When trying to hook up use of a customer's own signing infrastructure
>> for some am62x devices, I found it was more difficult than it should
>> be to point at the right key(s). One has to patch in the keyfile=
>> property in way too many places, and if you miss just one, the build
>> succeeds using the generic custMpk.pem for the one you missed, but of
>> course the resulting artifacts are unbootable.
>>
>
> The default value for keyfile i.e custMpk.pem is generated via binman
> from the custMpk node in binman (defined in k3-binman.dtsi), modifying
> the filepath to your custom key should work as a single line change as
> is.
>

No, because I don't have and will not have the "key" as an actual
file. And nobody who really cares about security should expose their
signing keys to the build environment. So I cannot simply change how the
custMpk.pem key in the (top-level) build-directory gets generated from
the one in the source tree.

I'm using a pkcs11:object=... uri as the keyfile property - that
works just fine out-of-the-box with a suitable OPENSSL_CONF in the
environment, so that openssl picks up the right pkcs11 provider module
and gets a signature that way.

So I really need a way for having a single place to set keyfile =
"pkcs11:object=..." and have that be used in all relevant nodes. Yes, I
see that I should have emphasized that use case more in the commit log
for patch 4, using that as example instead of "/path/to/own/key.pem".

[In my concrete case, the signing is done by a remote service, but it
would really be the same issue if one were using a yubikey or some other
local HSM].

> Perhaps this could be made more clear by the use of a macro instead of
> hardcoding the string "custMpk.pem" in all the places to make it more
> obvious.

Sure, we could introduce a macro and do

#ifndef K3_KEYFILE
#define K3_KEYFILE "custMpk.pem"
#endif

at the top of k3-binman.dtsi, but since binman already has the template
mechanism, that seemed a lot more appropriate to use.

Rasmus

Re: [PATCH 0/6] k3-binman ergonomics

[Anshul Dalal]

On Mon Jul 13, 2026 at 6:24 PM IST, Rasmus Villemoes wrote:
> On Mon, Jul 13 2026, "Anshul Dalal" <anshuld@ti.com> wrote:
>
>> On Fri Jul 10, 2026 at 6:06 PM IST, Rasmus Villemoes wrote:
>>> When trying to hook up use of a customer's own signing infrastructure
>>> for some am62x devices, I found it was more difficult than it should
>>> be to point at the right key(s). One has to patch in the keyfile=
>>> property in way too many places, and if you miss just one, the build
>>> succeeds using the generic custMpk.pem for the one you missed, but of
>>> course the resulting artifacts are unbootable.
>>>
>>
>> The default value for keyfile i.e custMpk.pem is generated via binman
>> from the custMpk node in binman (defined in k3-binman.dtsi), modifying
>> the filepath to your custom key should work as a single line change as
>> is.
>>
>
> No, because I don't have and will not have the "key" as an actual
> file. And nobody who really cares about security should expose their
> signing keys to the build environment. So I cannot simply change how the
> custMpk.pem key in the (top-level) build-directory gets generated from
> the one in the source tree.
>
> I'm using a pkcs11:object=... uri as the keyfile property - that
> works just fine out-of-the-box with a suitable OPENSSL_CONF in the
> environment, so that openssl picks up the right pkcs11 provider module
> and gets a signature that way.
>
> So I really need a way for having a single place to set keyfile =
> "pkcs11:object=..." and have that be used in all relevant nodes. Yes, I
> see that I should have emphasized that use case more in the commit log
> for patch 4, using that as example instead of "/path/to/own/key.pem".
>
> [In my concrete case, the signing is done by a remote service, but it
> would really be the same issue if one were using a yubikey or some other
> local HSM].
>

I see the use case now, what we have here makes sense. To add to what
Simon said[1] a small section documenting the use of pkcss11:object
inside the node in the k3.rst doc would be good to see.

[1]: https://lore.kernel.org/u-boot/CAFLszTh=4fWg6L74vnaJz7O9kOxE68XP3BCJEWVnBvc1aopHJg@mail.gmail.com/

>> Perhaps this could be made more clear by the use of a macro instead of
>> hardcoding the string "custMpk.pem" in all the places to make it more
>> obvious.
>
> Sure, we could introduce a macro and do
>
> #ifndef K3_KEYFILE
> #define K3_KEYFILE "custMpk.pem"
> #endif
>
> at the top of k3-binman.dtsi, but since binman already has the template
> mechanism, that seemed a lot more appropriate to use.

That's fair, we wouldn't need a macro if we replace all instances of
custMpk with the template. I can take that up once this is merged.

Thanks for the patch,
Anshul

Re: [0/6] k3-binman ergonomics

[Simon Glass]

Hi Rasmus,

On 2026-07-10T12:36:12, Rasmus Villemoes <ravi@prevas.dk> wrote:

> Use the template mechanism that binman already has to allow one to
> only set the keyfile= in a single place.

Thanks for sorting this out - having to override the keyfile in every
node is definitely error-prone. I think this is a nice use of
templates. Do we need to explicitly document how to specify the key,
etc.? I don't see doc/ changes in this series.

Regards,
Simon