[PATCH v3 00/11] Add support to boot TI K3 HSM M4 core

[PATCH v3 00/11] Add support to boot TI K3 HSM M4 core

[Beleswar Padhi]

Some TI K3 SoCs like J721S2, J784S4, and J722S have a HSM (High Security
Module) M4F core in the Wakeup Voltage Domain which could be used to
run secure services like Authentication. Boot flow for HSM M4 core is
different than the general purpose M4F cores, and is as below:

1. Request control of HSM M4F remote processor.
2. Assert Reset on the HSM M4F remote processor.
3. Request Secure Entity to Authenticate and Load HSM firmware into
   core's internal SRAM memory region. For GP device, load the firmware
   manually into core's SRAM region.
4. Deassert Reset on the HSM M4F remote processor.
5. Release control of HSM M4F remote processor.

This series adds support to boot HSM M4 core from R5 SPL stage. The HSM
firmware is packed inside the tispl.bin fit image. The firmware is
unpacked into a temporary DDR address which is then used to load HSM
core. The configs to boot HSM M4 core are disabled by default.

Note:
This series is dependent on the device-tree changes series posted to
Kernel mailing list:
https://lore.kernel.org/all/20251231165102.950644-1-b-padhi@ti.com/

v3: Changelog:
[Andrew]:
 1. Added dedicated remoteproc driver for booting HSM core.
 2. Added support for signing HSM firmware images in U-Boot. [Anshul]
General:
 1. Add support for booting HSM on J722S SoC as well.

Link to v2:
http://lore.kernel.org/all/20250506104202.16741-1-b-padhi@ti.com/

v2: Changelog:
[Andrew]:
 1. Added support in SPL to load FIT images with no 'load' property.
 2. Removed 'default = n' in CONFIG option.
 3. Used __maybe_unused to decrease preprocessing.
 4. Better error messages with error code. 
[Udit]:
 1. Added 'HSM' entries in enum at the last.
 2. Added error condition in if-elseif-else ladder.
 3. Hang System boot when HSM failed to boot properly.

Link to v1:
https://lore.kernel.org/all/20250422095430.363792-1-b-padhi@ti.com/

Testing done:
1. Tested HSM boot across GP, HS-FS, HS-SE device types for J721S2,
J784S4 and J722S SoCs.

Logs after enabling HSM boot configs:
https://gist.github.com/3V3RYONE/ad33683652c8c49e4fedab49f0493e79

Beleswar Padhi (11):
  spl: Use FIT data address as fallback when 'load' property is absent
  arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is
    missing
  arm: mach-k3: Explicitly identify TIFSSTUB images when discarding
    buffers
  arm: mach-k3: Add config option for packaging HSM firmware
  arm: dts: k3-binman: Add template for packing HSM firmware
  arm: dts: k3-{j721s2/j722s/j784s4}-binman: Pack HSM firmware inside
    tispl.bin
  binman: openssl: Add boot and load extensions to x509 cert
  arm: dts: k3-{j721s2/j722s/j784s4}-r5.dtsi: Enable HSM core
  remoteproc: k3-hsm: Introduce a remoteproc driver for K3 HSM core
  arm: mach-k3: r5: common: Invoke boot of HSM M4 core
  configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

 MAINTAINERS                            |   1 +
 arch/arm/dts/k3-binman.dtsi            |  20 ++
 arch/arm/dts/k3-j721s2-binman.dtsi     |  12 ++
 arch/arm/dts/k3-j721s2-r5.dtsi         |   5 +
 arch/arm/dts/k3-j722s-binman.dtsi      |  12 ++
 arch/arm/dts/k3-j722s-r5-evm.dts       |   5 +
 arch/arm/dts/k3-j784s4-binman.dtsi     |  14 ++
 arch/arm/dts/k3-j784s4-r5.dtsi         |   4 +
 arch/arm/mach-k3/Kconfig               |   7 +
 arch/arm/mach-k3/r5/common.c           |  43 ++++-
 common/spl/spl_fit.c                   |  16 +-
 configs/j722s_evm_r5_hsmboot_defconfig |  41 ++++
 drivers/remoteproc/Kconfig             |  10 +
 drivers/remoteproc/Makefile            |   1 +
 drivers/remoteproc/ti_k3_hsm_rproc.c   | 252 +++++++++++++++++++++++++
 tools/binman/btool/openssl.py          |  49 ++++-
 tools/binman/etype/ti_secure.py        |  18 ++
 tools/binman/etype/x509_cert.py        |   4 +-
 18 files changed, 505 insertions(+), 9 deletions(-)
 create mode 100644 configs/j722s_evm_r5_hsmboot_defconfig
 create mode 100644 drivers/remoteproc/ti_k3_hsm_rproc.c

-- 
2.34.1

[PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent

[Beleswar Padhi]

In cases where the 'load' property is not defined in a FIT image node,
fallback to using the data address returned by `fit_image_get_data()`.
This enables FIT images to omit the 'load' property during FIT creation.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
Cc: Simon Glass <sjg@chromium.org>

v3: Changelog:
1. None

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-3-b-padhi@ti.com/

v2: Changelog:
1. New patch. Add support to load images without 'load' property.

 common/spl/spl_fit.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a588d13eb40..c18c98b2959 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -803,6 +803,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 {
 	struct spl_image_info image_info;
 	struct spl_fit_info ctx;
+	const void *fit_image_loadaddr;
+	size_t fit_image_size;
 	int node = -1;
 	int ret;
 	int index = 0;
@@ -893,7 +895,19 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 		if (firmware_node == node)
 			continue;
 
-		image_info.load_addr = 0;
+		/*
+		 * If the 'load' property is not present in the image node,
+		 * use the FIT image's data address as the fallback load
+		 * address. This allows flexibility in omitting the load address
+		 * during FIT creation time.
+		 */
+		ret = fit_image_get_data(ctx.fit, node,
+					 &fit_image_loadaddr, &fit_image_size);
+		if (ret < 0)
+			panic("Error accessing node = %d in FIT (%d)\n", node,
+			      ret);
+
+		image_info.load_addr = (ulong)fit_image_loadaddr;
 		ret = load_simple_fit(info, offset, &ctx, node, &image_info);
 		if (ret < 0 && ret != -EBADSLT) {
 			printf("%s: can't load image loadables index %d (ret = %d)\n",
-- 
2.34.1

[PATCH v3 02/11] arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is missing

[Beleswar Padhi]

It is possible for FIT Images to skip mentioning the pre-defined 'load'
address property. In those cases, SPL uses the actual address of the FIT
Image data as the fallback load address. Use this FIT data address for
referencing the image when the 'load' property is missing.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. None

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-6-b-padhi@ti.com/

v2: Changelog:
1. New patch. Fetch FDT Data addr for accessing image if 'load' prop is
not present in node.

 arch/arm/mach-k3/r5/common.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index 03638366046..390e1324fb9 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -328,12 +328,15 @@ void board_fit_image_post_process(const void *fit, int node, void **p_image,
 				  size_t *p_size)
 {
 	int len;
-	int i;
+	int i, ret;
 	const char *os;
-	u32 addr;
+	u32 addr, load_addr;
+	const void *fit_image_loadaddr;
+	size_t fit_image_size;
 
 	os = fdt_getprop(fit, node, "os", &len);
 	addr = fdt_getprop_u32_default_node(fit, node, 0, "entry", -1);
+	load_addr = fdt_getprop_u32_default_node(fit, node, 0, "load", -1);
 
 	debug("%s: processing image: addr=%x, size=%d, os=%s\n", __func__,
 	      addr, *p_size, os);
@@ -342,6 +345,22 @@ void board_fit_image_post_process(const void *fit, int node, void **p_image,
 		if (!strcmp(os, image_os_match[i])) {
 			fit_image_info[i].image_start = addr;
 			fit_image_info[i].image_len = *p_size;
+			/*
+			 * If the 'load' property is missing in the FIT image,
+			 * fall back to using the actual in-memory address of
+			 * the FIT image data.
+			 */
+			if (load_addr == -1) {
+				ret = fit_image_get_data(fit, node,
+							 &fit_image_loadaddr,
+							 &fit_image_size);
+				if (ret < 0)
+					panic("Error accessing node os = %s in FIT (%d)\n",
+					      os, ret);
+				fit_image_info[i].load = (ulong)fit_image_loadaddr;
+			} else {
+				fit_image_info[i].load = load_addr;
+			}
 			debug("%s: matched image for ID %d\n", __func__, i);
 			break;
 		}
-- 
2.34.1

[PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers

[Beleswar Padhi]

The board_fit_image_post_process() function assumes that all TIFSSTUB
images appear at the end of the image_os_match[] array by using
the condition:

	i > IMAGE_ID_DM_FW

However, this assumption breaks when new image types are appended to the
enum and the array, causing unintended image types to match this
condition and having their buffer sizes incorrectly set to 0 with:

	*p_size = 0

To avoid this issue, replace the range-based check with an explicit
match for TIFSSTUB image IDs.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. None

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-7-b-padhi@ti.com/

v2: Changelog:
1. New patch. Fixes condition to allow new images to be added at the end
of the enum.

 arch/arm/mach-k3/r5/common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index 390e1324fb9..da1d1cb7230 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -366,7 +366,9 @@ void board_fit_image_post_process(const void *fit, int node, void **p_image,
 		}
 	}
 
-	if (i < IMAGE_AMT && i > IMAGE_ID_DM_FW) {
+	if (i < IMAGE_AMT &&
+	    (i == IMAGE_ID_TIFSSTUB_HS || i == IMAGE_ID_TIFSSTUB_FS ||
+	     i == IMAGE_ID_TIFSSTUB_GP)) {
 		int device_type = get_device_type();
 
 		if ((device_type == K3_DEVICE_TYPE_HS_SE &&
-- 
2.34.1

[PATCH v3 04/11] arm: mach-k3: Add config option for packaging HSM firmware

[Beleswar Padhi]

Some K3 SoCs like J721S2, and J784S4 have a HSM (High Security Module)
M4F core in the Wakeup Voltage Domain which could be used to run secure
services like Authentication. Add a config option which indicates that
the SoC has a HSM core and the firmware for the core is available.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. Updated description of config to match with functionality.

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-2-b-padhi@ti.com/

v2: Changelog:
1. Removed 'default = n' line from CONFIG.

Link to v1:
https://lore.kernel.org/all/20250422095430.363792-2-b-padhi@ti.com/

 arch/arm/mach-k3/Kconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 1b8c0b1eb96..33666c1e97f 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -181,6 +181,13 @@ config K3_REMOTEPROC_PRU
 	imply REMOTEPROC_TI_PRU
 	default y if (SOC_K3_AM642 || SOC_K3_AM654)
 
+config K3_HSM_FW
+	bool "Package firmware for HSM core"
+	help
+	  Enabling this will indicate that the system has a HSM (High Security
+	  Module) M4 Core and the firmware for the core is available. When
+	  enabled, the firmware for HSM core will be packaged inside tispl.bin.
+
 if CPU_V7R
 source "arch/arm/mach-k3/r5/Kconfig"
 endif
-- 
2.34.1

[PATCH v3 05/11] arm: dts: k3-binman: Add template for packing HSM firmware

[Beleswar Padhi]

The HSM M4 core needs to be booted at R5 SPL stage so that it can be
used for further Authentication and security services. Therefore, the
firmware for the HSM core needs to be packed in tispl.bin fit image so
that it can be used by R5 SPL to boot the HSM core.

Add a template for packing the HSM firmware in tispl.bin. The template
also contains necessary fields which will be populated in the boot
extension and load extension in the x509 certificate for HSM firmware.
This is required as the HSM firmware needs to be signed before invoking
TIFS to authenticate and load the blob to HSM core.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. Added ti-secure node for signing hsm firmware image in U-Boot.

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-4-b-padhi@ti.com/

v2: Changelog:
1. Got rid of 'load' and 'entry' properties. Rely on U-Boot to set it.

Link to v1:
https://lore.kernel.org/all/20250422095430.363792-3-b-padhi@ti.com/

 arch/arm/dts/k3-binman.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 761b1730464..de5f2aef30c 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -297,6 +297,26 @@
 					};
 				};
 
+#ifdef CONFIG_K3_HSM_FW
+				hsm {
+					description = "HSM binary";
+					type = "standalone";
+					compression = "none";
+					os = "hsm";
+
+					ti-secure {
+						content = <&hsm>;
+						keyfile = "custMpk.pem";
+						proc_id = <0x80>;
+						flags_set = <0x04>;
+						flags_clr = <0x00>;
+						reset_vector = <0x00>;
+						dest_addr = <0x43C00000>;
+						auth_type = <0xFD00>;
+					};
+				};
+#endif
+
 				dm {
 					description = "DM binary";
 					type = "firmware";
-- 
2.34.1

[PATCH v3 06/11] arm: dts: k3-{j721s2/j722s/j784s4}-binman: Pack HSM firmware inside tispl.bin

[Beleswar Padhi]

Pack the HSM firmware in tispl.bin fit image so that it can be unloaded
and used by R5 SPL to boot the HSM core. By default, point to the
firmware for HS-SE device type. This needs to be changed to point to
appropriate firmware when using a different device type.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. Pack firmware for J722S SoC as well.

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-5-b-padhi@ti.com/

v2: Changelog:
None to this patch.

Link to v1:
https://lore.kernel.org/all/20250422095430.363792-4-b-padhi@ti.com/

 arch/arm/dts/k3-j721s2-binman.dtsi | 12 ++++++++++++
 arch/arm/dts/k3-j722s-binman.dtsi  | 12 ++++++++++++
 arch/arm/dts/k3-j784s4-binman.dtsi | 14 ++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi b/arch/arm/dts/k3-j721s2-binman.dtsi
index f79b3e543ae..14ba9ba2c1d 100644
--- a/arch/arm/dts/k3-j721s2-binman.dtsi
+++ b/arch/arm/dts/k3-j721s2-binman.dtsi
@@ -268,6 +268,14 @@
 
 					};
 				};
+#ifdef CONFIG_K3_HSM_FW
+				hsm {
+					hsm: blob-ext {
+						filename = "ti-hsm/hsm-demo-firmware-j721s2-hs.bin";
+					};
+				};
+#endif
+
 				dm {
 					ti-secure {
 						content = <&dm>;
@@ -300,7 +308,11 @@
 				conf-0 {
 					description = "k3-j721s2-common-proc-board";
 					firmware = "atf";
+#ifdef CONFIG_K3_HSM_FW
+					loadables = "hsm", "tee", "dm", "spl";
+#else
 					loadables = "tee", "dm", "spl";
+#endif
 					fdt = "fdt-0";
 				};
 			};
diff --git a/arch/arm/dts/k3-j722s-binman.dtsi b/arch/arm/dts/k3-j722s-binman.dtsi
index 278b7bfac7f..cbae8a93759 100644
--- a/arch/arm/dts/k3-j722s-binman.dtsi
+++ b/arch/arm/dts/k3-j722s-binman.dtsi
@@ -117,6 +117,14 @@
 
 		fit {
 			images {
+#ifdef CONFIG_K3_HSM_FW
+				hsm {
+					hsm: blob-ext {
+						filename = "ti-hsm/hsm-demo-firmware-j722s-hs.bin";
+					};
+				};
+#endif
+
 				dm {
 					ti-secure {
 						content = <&dm>;
@@ -153,7 +161,11 @@
 				conf-0 {
 					description = "k3-j722s-evm";
 					firmware = "atf";
+#ifdef CONFIG_K3_HSM_FW
+					loadables = "hsm", "tee", "dm", "spl";
+#else
 					loadables = "tee", "dm", "spl";
+#endif
 					fdt = "fdt-0";
 				};
 			};
diff --git a/arch/arm/dts/k3-j784s4-binman.dtsi b/arch/arm/dts/k3-j784s4-binman.dtsi
index 34b2cc1e681..63d210dd883 100644
--- a/arch/arm/dts/k3-j784s4-binman.dtsi
+++ b/arch/arm/dts/k3-j784s4-binman.dtsi
@@ -154,6 +154,16 @@
 
 		fit {
 			images {
+
+#ifdef CONFIG_K3_HSM_FW
+				hsm {
+					hsm: blob-ext {
+						filename = "ti-hsm/hsm-demo-firmware-j784s4-hs.bin";
+					};
+				};
+
+#endif
+
 				dm {
 					ti-secure {
 						content = <&dm>;
@@ -188,7 +198,11 @@
 				conf-0 {
 					description = BOARD_DESCRIPTION;
 					firmware = "atf";
+#ifdef CONFIG_K3_HSM_FW
+					loadables = "hsm", "tee", "dm", "spl";
+#else
 					loadables = "tee", "dm", "spl";
+#endif
 					fdt = "fdt-0";
 				};
 			};
-- 
2.34.1

[PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert

[Beleswar Padhi]

The boot and load extensions in the x509 certificate are required for
requesting the secure entity (TIFS) to boot a core. These fields are
defined in the binman node for each core that must be booted by TIFS
and must be included when generating the signed certificate.

Add support to parse the boot and load extension properties from the
binman node and populate them into the certificate. If any of the
mandatory properties for an extension are missing, that respective
extension section is NOT added to the certificate.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. New patch. Add support to sign HSM firmware here in U-Boot.

 tools/binman/btool/openssl.py   | 49 ++++++++++++++++++++++++++++++---
 tools/binman/etype/ti_secure.py | 18 ++++++++++++
 tools/binman/etype/x509_cert.py |  4 ++-
 3 files changed, 66 insertions(+), 5 deletions(-)

diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index b26f087c447..35898aa488b 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -82,7 +82,8 @@ imageSize              = INTEGER:{len(indata)}
         return self.run_cmd(*args)
 
     def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
-                  config_fname, req_dist_name_dict, firewall_cert_data):
+                  config_fname, req_dist_name_dict, firewall_cert_data,
+                  boot_ext_data, load_ext_data):
         """Create a certificate to be booted by system firmware
 
         Args:
@@ -101,12 +102,52 @@ imageSize              = INTEGER:{len(indata)}
                 extended certificate
               - certificate (str): Extended firewall certificate with
                 the information for the firewall configurations.
+            boot_ext_data (dict):
+              - proc_id (int): The processor ID of core being booted
+              - flags_set (int): The config flags to set for core being booted
+              - flags_clr (int): The config flags to clear for core being booted
+              - reset_vector (int): The location of reset vector for core being
+                booted
+            load_ext_data (dict):
+              - dest_addr (int): The address to which image has to be copied
+              - auth_type (int): Contains the host ID for core being booted and
+                how the image is to be copied
 
         Returns:
             str: Tool output
         """
         indata = tools.read_file(input_fname)
         hashval = hashlib.sha512(indata).hexdigest()
+
+        if boot_ext_data is not None:
+            boot_ext = f'''
+[ sysfw_boot_seq ]
+bootCore = INTEGER:{boot_ext_data['proc_id']}
+bootCoreOpts_set = INTEGER:{boot_ext_data['flags_set']}
+bootCoreOpts_clr = INTEGER:{boot_ext_data['flags_clr']}
+resetVec = FORMAT:HEX,OCT:{boot_ext_data['reset_vector']:08x}
+# Reserved for future use
+flagsValid = FORMAT:HEX,OCT:00000000
+rsvd1 = INTEGER:0x00
+rsdv2 = INTEGER:0x00
+rsdv3 = INTEGER:0x00
+'''
+        else:
+            boot_ext = ""
+
+        if load_ext_data is not None:
+            load_ext = f'''
+[ sysfw_image_load ]
+destAddr = FORMAT:HEX,OCT:{load_ext_data['dest_addr']:08x}
+authInPlace = INTEGER:{load_ext_data['auth_type']}
+'''
+        else:
+            load_ext = f'''
+[ sysfw_image_load ]
+destAddr = FORMAT:HEX,OCT:00000000
+authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
+'''
+
         with open(config_fname, 'w', encoding='utf-8') as outf:
             print(f'''[ req ]
 distinguished_name     = req_distinguished_name
@@ -138,9 +179,9 @@ shaType                = OID:2.16.840.1.101.3.4.2.3
 shaValue               = FORMAT:HEX,OCT:{hashval}
 imageSize              = INTEGER:{len(indata)}
 
-[ sysfw_image_load ]
-destAddr = FORMAT:HEX,OCT:00000000
-authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
+{boot_ext}
+
+{load_ext}
 
 [ firewall ]
 numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
index f6caa0286d9..bc44b684892 100644
--- a/tools/binman/etype/ti_secure.py
+++ b/tools/binman/etype/ti_secure.py
@@ -116,6 +116,7 @@ class Entry_ti_secure(Entry_x509_cert):
         if auth_in_place:
             self.firewall_cert_data['auth_in_place'] = auth_in_place
             self.ReadFirewallNode()
+        self.ReadLoadableCoreNode()
         self.sha = fdt_util.GetInt(self._node, 'sha', 512)
         self.req_dist_name = {'C': 'US',
                 'ST': 'TX',
@@ -126,6 +127,23 @@ class Entry_ti_secure(Entry_x509_cert):
                 'emailAddress': 'support@ti.com'}
         self.debug = fdt_util.GetBool(self._node, 'debug', False)
 
+    def ReadLoadableCoreNode(self):
+        boot_ext_props = ['proc_id', 'flags_set', 'flags_clr', 'reset_vector']
+        load_ext_props = ['dest_addr', 'auth_type']
+
+        self.boot_ext = self.ReadDictFromList(boot_ext_props)
+        self.load_ext = self.ReadDictFromList(load_ext_props)
+
+    def ReadDictFromList(self, props):
+        props_dict = dict.fromkeys(props)
+        for prop in props:
+            val = fdt_util.GetInt(self._node, prop)
+            if val is None:
+                return None
+            else:
+                props_dict[prop] = val
+        return props_dict
+
     def ReadFirewallNode(self):
         self.firewall_cert_data['certificate'] = ""
         self.firewall_cert_data['num_firewalls'] = 0
diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
index b6e8b0b4fb0..b6028f6be84 100644
--- a/tools/binman/etype/x509_cert.py
+++ b/tools/binman/etype/x509_cert.py
@@ -102,7 +102,9 @@ class Entry_x509_cert(Entry_collection):
                 config_fname=config_fname,
                 sw_rev=self.sw_rev,
                 req_dist_name_dict=self.req_dist_name,
-                firewall_cert_data=self.firewall_cert_data)
+                firewall_cert_data=self.firewall_cert_data,
+                boot_ext_data=self.boot_ext,
+                load_ext_data=self.load_ext)
         elif type == 'rom':
             stdout = self.openssl.x509_cert_rom(
                 cert_fname=output_fname,
-- 
2.34.1

[PATCH v3 08/11] arm: dts: k3-{j721s2/j722s/j784s4}-r5.dtsi: Enable HSM core

[Beleswar Padhi]

The HSM M4F node is disabled by default in the device tree. Enable the
node here as we have to load and boot the core in R5 SPL stage. Assign
the alias of 'remoteproc2' to the hsm node. This assigns the sequence
number '2' to HSM core which can be used during rproc_load() and
rproc_start() calls.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. New patch. Enable HSM nodes from DT.

 arch/arm/dts/k3-j721s2-r5.dtsi   | 5 +++++
 arch/arm/dts/k3-j722s-r5-evm.dts | 5 +++++
 arch/arm/dts/k3-j784s4-r5.dtsi   | 4 ++++
 3 files changed, 14 insertions(+)

diff --git a/arch/arm/dts/k3-j721s2-r5.dtsi b/arch/arm/dts/k3-j721s2-r5.dtsi
index c1c12e217d2..141a748bc76 100644
--- a/arch/arm/dts/k3-j721s2-r5.dtsi
+++ b/arch/arm/dts/k3-j721s2-r5.dtsi
@@ -11,6 +11,7 @@
 	aliases {
 		remoteproc0 = &sysctrler;
 		remoteproc1 = &a72_0;
+		remoteproc2 = &hsm_m4fss;
 	};
 
 	a72_0: a72@0 {
@@ -97,3 +98,7 @@
 	ranges = <0x0 0x47000000 0x0 0x47000000 0x0 0x00068400>,
 			 <0x0 0x50000000 0x0 0x50000000 0x0 0x08000000>;
 };
+
+&hsm_m4fss {
+	status = "okay";
+};
diff --git a/arch/arm/dts/k3-j722s-r5-evm.dts b/arch/arm/dts/k3-j722s-r5-evm.dts
index 02a3494a877..3f3f17af83b 100644
--- a/arch/arm/dts/k3-j722s-r5-evm.dts
+++ b/arch/arm/dts/k3-j722s-r5-evm.dts
@@ -14,6 +14,7 @@
 	aliases {
 		remoteproc0 = &sysctrler;
 		remoteproc1 = &a53_0;
+		remoteproc2 = &hsm_m4fss;
 		serial0 = &wkup_uart0;
 		serial2 = &main_uart0;
 	};
@@ -102,3 +103,7 @@
 &main_pktdma {
 	ti,sci = <&dm_tifs>;
 };
+
+&hsm_m4fss {
+	status = "okay";
+};
diff --git a/arch/arm/dts/k3-j784s4-r5.dtsi b/arch/arm/dts/k3-j784s4-r5.dtsi
index 78444dc4e14..34fd2fc2fee 100644
--- a/arch/arm/dts/k3-j784s4-r5.dtsi
+++ b/arch/arm/dts/k3-j784s4-r5.dtsi
@@ -11,6 +11,7 @@
 	aliases {
 		remoteproc0 = &sysctrler;
 		remoteproc1 = &a72_0;
+		remoteproc2 = &hsm_m4fss;
 	};
 
 	a72_0: a72@0 {
@@ -113,3 +114,6 @@
 	vdd-supply-2 = <&tps62873a>;
 };
 
+&hsm_m4fss {
+	status = "okay";
+};
-- 
2.34.1

[PATCH v3 09/11] remoteproc: k3-hsm: Introduce a remoteproc driver for K3 HSM core

[Beleswar Padhi]

Some K3 SoCs like J721S2, J784S4, J722S, AM62X and AM62PX have a HSM
(High Security Module) M4F core in the Wakeup Voltage Domain which could
be used to run secure services like Authentication. Boot flow for HSM M4
core is different than the general purpose M4F cores, and is as below:

1. Request control of HSM M4F remote processor.
2. Assert Reset on the HSM M4F remote processor.
3. For HS devices, Request Secure Entity to Authenticate and Load HSM
   firmware into core's internal SRAM memory region. For GP devices,
   load the unsigned firmware manually.
4. Deassert Reset on the HSM M4F remote processor.
5. Release control of HSM M4F remote processor.

Add a new remoteproc driver to support this boot flow for HSM M4F core.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. New patch. Add a dedicated remoteproc driver to boot HSM core.

 MAINTAINERS                          |   1 +
 drivers/remoteproc/Kconfig           |  10 ++
 drivers/remoteproc/Makefile          |   1 +
 drivers/remoteproc/ti_k3_hsm_rproc.c | 252 +++++++++++++++++++++++++++
 4 files changed, 264 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_hsm_rproc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6ce0bbce13d..1a11b580a66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -802,6 +802,7 @@ F:	drivers/phy/ti-pipe3-phy.c
 F:	drivers/ram/k3*
 F:	drivers/ram/k3*/
 F:	drivers/remoteproc/ipu_rproc.c
+F:	drivers/remoteproc/ti_k3_hsm_rproc.c
 F:	drivers/remoteproc/k3_system_controller.c
 F:	drivers/remoteproc/pruc_rpoc.c
 F:	drivers/remoteproc/ti*
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 8056f210abc..5514f092615 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -99,6 +99,16 @@ config REMOTEPROC_TI_K3_M4F
 	  on various TI K3 family of SoCs through the remote processor
 	  framework.
 
+config REMOTEPROC_TI_K3_HSM_M4F
+	bool "TI K3 HSM M4F remoteproc support"
+	select REMOTEPROC
+	depends on ARCH_K3
+	depends on TI_SCI_PROTOCOL
+	help
+	  Say y here to support TI's HSM M4F remote processor subsystems
+	  on various TI K3 family of SoCs through the remote processor
+	  framework.
+
 config REMOTEPROC_TI_K3_R5F
 	bool "TI K3 R5F remoteproc support"
 	select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 7ea8023c50b..d29e1bf9db2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_M4F) += ti_k3_m4_rproc.o
+obj-$(CONFIG_REMOTEPROC_TI_K3_HSM_M4F) += ti_k3_hsm_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
 obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
diff --git a/drivers/remoteproc/ti_k3_hsm_rproc.c b/drivers/remoteproc/ti_k3_hsm_rproc.c
new file mode 100644
index 00000000000..4c05fef487a
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_hsm_rproc.c
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' K3 HSM M4 Remoteproc driver
+ *
+ * Copyright (C) 2025 Texas Instruments Incorporated - http://www.ti.com/
+ *	Beleswar Padhi <b-padhi@ti.com>
+ */
+
+#include <cpu_func.h>
+#include <dm.h>
+#include <log.h>
+#include <malloc.h>
+#include <remoteproc.h>
+#include <errno.h>
+#include <asm/io.h>
+#include <dm/device_compat.h>
+#include <linux/err.h>
+#include <linux/sizes.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+#include "ti_sci_proc.h"
+#include <mach/security.h>
+
+#define PROC_BOOT_CTRL_RESET_FLAG_HSM_M4 0x00000001
+
+/**
+ * struct k3_hsm_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from remoteproc view
+ * @size: Size of the memory region
+ */
+struct k3_hsm_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	phys_addr_t dev_addr;
+	size_t size;
+};
+
+/**
+ * struct k3_hsm_mem_data - memory definitions for hsm remote core
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_hsm_mem_data {
+	const char *name;
+	const u32 dev_addr;
+};
+
+/**
+ * struct k3_hsm_privdata - Structure representing Remote processor data.
+ * @tsp:	Pointer to TISCI proc control handle
+ * @mem:	Array of available memories
+ * @num_mems:	Number of available memories
+ */
+struct k3_hsm_privdata {
+	struct ti_sci_proc tsp;
+	struct k3_hsm_mem *mem;
+	int num_mems;
+};
+
+/**
+ * k3_hsm_load() - Load up the Remote processor image
+ * @dev:	rproc device pointer
+ * @addr:	Address at which image is available
+ * @size:	size of the image
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_hsm_load(struct udevice *dev, ulong addr, ulong size)
+{
+	struct k3_hsm_privdata *hsm = dev_get_priv(dev);
+	size_t image_size = size;
+	int ret;
+
+	ret = ti_sci_proc_request(&hsm->tsp);
+	if (ret)
+		return ret;
+
+	ret = ti_sci_proc_set_control(&hsm->tsp,
+				      PROC_BOOT_CTRL_RESET_FLAG_HSM_M4, 0);
+	if (ret)
+		goto proc_release;
+
+	ti_secure_image_post_process((void *)&addr, &image_size);
+
+	if (image_size == size) {
+		debug("Loading HSM GP binary into SRAM0_0\n");
+		memcpy((void *)hsm->mem[0].cpu_addr, (void *)(u32)addr, size);
+		flush_dcache_range((unsigned long)hsm->mem[0].cpu_addr,
+				   (unsigned long)(hsm->mem[0].cpu_addr + size));
+	}
+
+proc_release:
+	ti_sci_proc_release(&hsm->tsp);
+	return ret;
+}
+
+/**
+ * k3_hsm_start() - Start the remote processor
+ * @dev:	rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_hsm_start(struct udevice *dev)
+{
+	struct k3_hsm_privdata *hsm = dev_get_priv(dev);
+	int ret;
+
+	ret = ti_sci_proc_request(&hsm->tsp);
+	if (ret)
+		return ret;
+
+	ret = ti_sci_proc_set_control(&hsm->tsp, 0,
+				      PROC_BOOT_CTRL_RESET_FLAG_HSM_M4);
+
+	ti_sci_proc_release(&hsm->tsp);
+
+	return ret;
+}
+
+static int k3_hsm_stop(struct udevice *dev)
+{
+	struct k3_hsm_privdata *hsm = dev_get_priv(dev);
+	int ret;
+
+	ti_sci_proc_request(&hsm->tsp);
+
+	ret = ti_sci_proc_set_control(&hsm->tsp,
+				      PROC_BOOT_CTRL_RESET_FLAG_HSM_M4, 0);
+
+	ti_sci_proc_release(&hsm->tsp);
+
+	return ret;
+}
+
+static const struct dm_rproc_ops k3_hsm_ops = {
+	.load = k3_hsm_load,
+	.start = k3_hsm_start,
+	.stop = k3_hsm_stop,
+};
+
+static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
+{
+	u32 ids[2];
+	int ret;
+
+	tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
+	if (IS_ERR(tsp->sci)) {
+		dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
+		return PTR_ERR(tsp->sci);
+	}
+
+	ret = dev_read_u32_array(dev, "ti,sci-proc-ids", ids, 2);
+	if (ret) {
+		dev_err(dev, "Proc IDs not populated %d\n", ret);
+		return ret;
+	}
+
+	tsp->ops = &tsp->sci->ops.proc_ops;
+	tsp->proc_id = ids[0];
+	tsp->host_id = ids[1];
+	tsp->dev_id = dev_read_u32_default(dev, "ti,sci-dev-id",
+					   TI_SCI_RESOURCE_NULL);
+	if (tsp->dev_id == TI_SCI_RESOURCE_NULL) {
+		dev_err(dev, "Device ID not populated %d\n", ret);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static const struct k3_hsm_mem_data hsm_mems[] = {
+	{ .name = "sram0_0", .dev_addr = 0x0 },
+	{ .name = "sram0_1", .dev_addr = 0x20000 },
+	{ .name = "sram1",   .dev_addr = 0x30000 },
+};
+
+static int k3_hsm_of_get_memories(struct udevice *dev)
+{
+	struct k3_hsm_privdata *hsm = dev_get_priv(dev);
+	int i;
+
+	hsm->num_mems = ARRAY_SIZE(hsm_mems);
+	hsm->mem = calloc(hsm->num_mems, sizeof(*hsm->mem));
+	if (!hsm->mem)
+		return -ENOMEM;
+
+	for (i = 0; i < hsm->num_mems; i++) {
+		hsm->mem[i].bus_addr = dev_read_addr_size_name(dev,
+							       hsm_mems[i].name,
+							       (fdt_addr_t *)&hsm->mem[i].size);
+		if (hsm->mem[i].bus_addr == FDT_ADDR_T_NONE) {
+			dev_err(dev, "%s bus address not found\n",
+				hsm_mems[i].name);
+			return -EINVAL;
+		}
+		hsm->mem[i].cpu_addr = map_physmem(hsm->mem[i].bus_addr,
+						   hsm->mem[i].size,
+						   MAP_NOCACHE);
+		hsm->mem[i].dev_addr = hsm_mems[i].dev_addr;
+	}
+
+	return 0;
+}
+
+/**
+ * k3_hsm_probe() - Basic probe
+ * @dev:	corresponding k3 remote processor device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_hsm_probe(struct udevice *dev)
+{
+	struct k3_hsm_privdata *hsm;
+	int ret;
+
+	hsm = dev_get_priv(dev);
+
+	ret = ti_sci_proc_of_to_priv(dev, &hsm->tsp);
+	if (ret)
+		return ret;
+
+	ret = k3_hsm_of_get_memories(dev);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int k3_hsm_remove(struct udevice *dev)
+{
+	struct k3_hsm_privdata *hsm = dev_get_priv(dev);
+
+	free(hsm->mem);
+
+	return 0;
+}
+
+static const struct udevice_id k3_hsm_ids[] = {
+	{ .compatible = "ti,hsm-m4fss" },
+	{}
+};
+
+U_BOOT_DRIVER(k3_hsm) = {
+	.name = "k3_hsm",
+	.of_match = k3_hsm_ids,
+	.id = UCLASS_REMOTEPROC,
+	.ops = &k3_hsm_ops,
+	.probe = k3_hsm_probe,
+	.remove = k3_hsm_remove,
+	.priv_auto = sizeof(struct k3_hsm_privdata),
+};
-- 
2.34.1

[PATCH v3 10/11] arm: mach-k3: r5: common: Invoke boot of HSM M4 core

[Beleswar Padhi]

The tispl.bin fit image is packed with the HSM firmware image. Populate
the "os" info of the image so that it can be detected and used to load
the HSM core. Further, invoke the load and boot of HSM core at R5 SPL
stage using the remoteprocessor framework.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. Use remoteproc framework to boot HSM core.

Link to v2:
https://lore.kernel.org/all/20250506104202.16741-8-b-padhi@ti.com/

v2: Changelog:
1. Hang system boot if HSM firmware failed to boot.
2. __maybe_unused to decrease preprocessor usage.
3. Better error messages with return code.
4. Added Error case in if-elseif-else ladder.

Note:
#define PROC_ID_HSM_M4F seems to have extra tab in the diff/patch.
But when patch gets applied in file, all of them have consistent
tabs.

Link to v1:
https://lore.kernel.org/all/18e01808-499d-4690-995a-45ac5fd727d9@ti.com

 arch/arm/mach-k3/r5/common.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index da1d1cb7230..51476722b4c 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -28,6 +28,7 @@ enum {
 	IMAGE_ID_TIFSSTUB_HS,
 	IMAGE_ID_TIFSSTUB_FS,
 	IMAGE_ID_TIFSSTUB_GP,
+	IMAGE_ID_HSM,
 	IMAGE_AMT,
 };
 
@@ -40,6 +41,7 @@ static const char *image_os_match[IMAGE_AMT] = {
 	"tifsstub-hs",
 	"tifsstub-fs",
 	"tifsstub-gp",
+	"hsm",
 };
 #endif
 
@@ -158,6 +160,20 @@ void __noreturn jump_to_image(struct spl_image_info *spl_image)
 				     &loadaddr);
 	}
 
+	if (IS_ENABLED(CONFIG_REMOTEPROC_TI_K3_HSM_M4F)) {
+		ret = rproc_load(2, fit_image_info[IMAGE_ID_HSM].load,
+				 fit_image_info[IMAGE_ID_HSM].image_len);
+		if (ret) {
+			panic("Error while loading HSM firmware, ret = %d\n", ret);
+		} else {
+			ret = rproc_start(2);
+			if (ret)
+				panic("Error while starting HSM core\n");
+			else
+				printf("Successfully loaded and started HSM core\n");
+		}
+	}
+
 	/*
 	 * It is assumed that remoteproc device 1 is the corresponding
 	 * Cortex-A core which runs ATF. Make sure DT reflects the same.
-- 
2.34.1

[PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

[Beleswar Padhi]

Up until now, the R5 SPL in J722S platform was configured to start out
of the SMS0_HSM_SRAM0_0 (0x0043C00000, 512KB) memory region. However,
with the requirement of loading HSM M4F core with its own secure
firmware, R5 SPL can no longer utilize that memory to execute itself.

Therefore, utilize the MSRAM8KX256E0_RAM (0x0043C40000, 256KB) memory
region for loading and executing R5 SPL. Naturally, the SPL size has now
to be trimmed to be fit inside the smaller 256KB region.

As an example, create a new defconfig (j722s_evm_r5_hsmboot_defconfig)
which removes the SPI related configs to trim down the SPL size to
~175KB. The above defconfig demonstrates loading HSM core with SD, eMMC
and UART bootmodes.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
1. New patch. Show an example of booting HSM core on J722S SoC.

 configs/j722s_evm_r5_hsmboot_defconfig | 41 ++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 configs/j722s_evm_r5_hsmboot_defconfig

diff --git a/configs/j722s_evm_r5_hsmboot_defconfig b/configs/j722s_evm_r5_hsmboot_defconfig
new file mode 100644
index 00000000000..517cfd40018
--- /dev/null
+++ b/configs/j722s_evm_r5_hsmboot_defconfig
@@ -0,0 +1,41 @@
+#include<configs/j722s_evm_r5_defconfig>
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SOC_K3_J722S=y
+CONFIG_TARGET_J722S_R5_EVM=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-j722s-r5-evm"
+# Enable HSM loading
+CONFIG_REMOTEPROC_TI_K3_HSM_M4F=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43C78800
+CONFIG_SPL_TEXT_BASE=0x43c40000
+CONFIG_SPL_BSS_START_ADDR=0x43c7c290
+# Remove SPI configs to reduce SPL size
+CONFIG_SPL_GPIO=n
+CONFIG_DM_GPIO=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
+CONFIG_SPL_SPI=n
+CONFIG_OF_BOARD_SETUP=n
+CONFIG_SPL_MTD=n
+CONFIG_SPL_MTD_LOAD=n
+CONFIG_SPL_NAND_SPI_SUPPORT=n
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=n
+CONFIG_SPL_SPI_LOAD=n
+CONFIG_DA8XX_GPIO=n
+CONFIG_DM_PCA953X=n
+CONFIG_SPL_DM_PCA953X=n
+CONFIG_MTD=n
+CONFIG_DM_MTD=n
+CONFIG_MTD_SPI_NAND=n
+CONFIG_DM_SPI_FLASH=n
+CONFIG_SPI_FLASH_SFDP_SUPPORT=n
+CONFIG_SPI_FLASH_SOFT_RESET=n
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=n
+CONFIG_SPI_FLASH_SPANSION=n
+CONFIG_SPI_FLASH_S28HX_T=n
+CONFIG_SPI=n
+CONFIG_DM_SPI=n
+CONFIG_CADENCE_QSPI=n
+CONFIG_CADENCE_QSPI_PHY=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_DM_SPI=n
-- 
2.34.1

Re: [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Wed, Dec 31, 2025 at 11:06:10PM +0530, Beleswar Padhi wrote:
> Some TI K3 SoCs like J721S2, J784S4, and J722S have a HSM (High Security
> Module) M4F core in the Wakeup Voltage Domain which could be used to
> run secure services like Authentication. Boot flow for HSM M4 core is
> different than the general purpose M4F cores, and is as below:
> 
> 1. Request control of HSM M4F remote processor.
> 2. Assert Reset on the HSM M4F remote processor.
> 3. Request Secure Entity to Authenticate and Load HSM firmware into
>    core's internal SRAM memory region. For GP device, load the firmware
>    manually into core's SRAM region.
> 4. Deassert Reset on the HSM M4F remote processor.
> 5. Release control of HSM M4F remote processor.
> 
> This series adds support to boot HSM M4 core from R5 SPL stage. The HSM
> firmware is packed inside the tispl.bin fit image. The firmware is
> unpacked into a temporary DDR address which is then used to load HSM
> core. The configs to boot HSM M4 core are disabled by default.
> 
> Note:
> This series is dependent on the device-tree changes series posted to
> Kernel mailing list:
> https://lore.kernel.org/all/20251231165102.950644-1-b-padhi@ti.com/

I see there's already feedback there and I expect at least a v2, so I'm
going to mark this series as RFC. As I expect you'll have to change
this, please wait to do v4 until the dts portion is in linux-next. I'll
look over this series itself now for high level things, and leave it to
TI folks to poke at any specific details, thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On Wed, Dec 31, 2025 at 11:06:11PM +0530, Beleswar Padhi wrote:

> In cases where the 'load' property is not defined in a FIT image node,
> fallback to using the data address returned by `fit_image_get_data()`.
> This enables FIT images to omit the 'load' property during FIT creation.
> 
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> ---
> Cc: Simon Glass <sjg@chromium.org>
> 
> v3: Changelog:
> 1. None
> 
> Link to v2:
> https://lore.kernel.org/all/20250506104202.16741-3-b-padhi@ti.com/
> 
> v2: Changelog:
> 1. New patch. Add support to load images without 'load' property.
> 
>  common/spl/spl_fit.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index a588d13eb40..c18c98b2959 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -803,6 +803,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>  {
>  	struct spl_image_info image_info;
>  	struct spl_fit_info ctx;
> +	const void *fit_image_loadaddr;
> +	size_t fit_image_size;
>  	int node = -1;
>  	int ret;
>  	int index = 0;
> @@ -893,7 +895,19 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>  		if (firmware_node == node)
>  			continue;
>  
> -		image_info.load_addr = 0;
> +		/*
> +		 * If the 'load' property is not present in the image node,
> +		 * use the FIT image's data address as the fallback load
> +		 * address. This allows flexibility in omitting the load address
> +		 * during FIT creation time.
> +		 */
> +		ret = fit_image_get_data(ctx.fit, node,
> +					 &fit_image_loadaddr, &fit_image_size);
> +		if (ret < 0)
> +			panic("Error accessing node = %d in FIT (%d)\n", node,
> +			      ret);
> +
> +		image_info.load_addr = (ulong)fit_image_loadaddr;
>  		ret = load_simple_fit(info, offset, &ctx, node, &image_info);
>  		if (ret < 0 && ret != -EBADSLT) {
>  			printf("%s: can't load image loadables index %d (ret = %d)\n",

What's the IH_TYPE here? Saying to use something in-place is not always
safe.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

On Fri, Jan 02, 2026 at 08:47:10AM -0600, Tom Rini wrote:
> On Wed, Dec 31, 2025 at 11:06:11PM +0530, Beleswar Padhi wrote:
> 
> > In cases where the 'load' property is not defined in a FIT image node,
> > fallback to using the data address returned by `fit_image_get_data()`.
> > This enables FIT images to omit the 'load' property during FIT creation.
> > 
> > Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> > ---
> > Cc: Simon Glass <sjg@chromium.org>
> > 
> > v3: Changelog:
> > 1. None
> > 
> > Link to v2:
> > https://lore.kernel.org/all/20250506104202.16741-3-b-padhi@ti.com/
> > 
> > v2: Changelog:
> > 1. New patch. Add support to load images without 'load' property.
> > 
> >  common/spl/spl_fit.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index a588d13eb40..c18c98b2959 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -803,6 +803,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
> >  {
> >  	struct spl_image_info image_info;
> >  	struct spl_fit_info ctx;
> > +	const void *fit_image_loadaddr;
> > +	size_t fit_image_size;
> >  	int node = -1;
> >  	int ret;
> >  	int index = 0;
> > @@ -893,7 +895,19 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
> >  		if (firmware_node == node)
> >  			continue;
> >  
> > -		image_info.load_addr = 0;
> > +		/*
> > +		 * If the 'load' property is not present in the image node,
> > +		 * use the FIT image's data address as the fallback load
> > +		 * address. This allows flexibility in omitting the load address
> > +		 * during FIT creation time.
> > +		 */
> > +		ret = fit_image_get_data(ctx.fit, node,
> > +					 &fit_image_loadaddr, &fit_image_size);
> > +		if (ret < 0)
> > +			panic("Error accessing node = %d in FIT (%d)\n", node,
> > +			      ret);
> > +
> > +		image_info.load_addr = (ulong)fit_image_loadaddr;
> >  		ret = load_simple_fit(info, offset, &ctx, node, &image_info);
> >  		if (ret < 0 && ret != -EBADSLT) {
> >  			printf("%s: can't load image loadables index %d (ret = %d)\n",
> 
> What's the IH_TYPE here? Saying to use something in-place is not always
> safe.

Looking at the rest of the series, and then going back to v1 and:
https://lore.kernel.org/all/b6bc14fc-c823-4376-939f-2c0e6b120a2c@ti.com/
we're IH_TYPE_STANDALONE which *does* require a load address (see
boot/image-fit.c). You might need to look in to a new type or see if
another type is reasonable, that doesn't already expect a load address
set.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent

[Padhi, Beleswar]

Hi Tom,

On 1/2/2026 8:25 PM, Tom Rini wrote:
> On Fri, Jan 02, 2026 at 08:47:10AM -0600, Tom Rini wrote:
>> On Wed, Dec 31, 2025 at 11:06:11PM +0530, Beleswar Padhi wrote:
>>
>>> In cases where the 'load' property is not defined in a FIT image node,
>>> fallback to using the data address returned by `fit_image_get_data()`.
>>> This enables FIT images to omit the 'load' property during FIT creation.
>>>
>>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>>> ---
>>> Cc: Simon Glass <sjg@chromium.org>
>>>
>>> v3: Changelog:
>>> 1. None
>>>
>>> Link to v2:
>>> https://lore.kernel.org/all/20250506104202.16741-3-b-padhi@ti.com/
>>>
>>> v2: Changelog:
>>> 1. New patch. Add support to load images without 'load' property.
>>>
>>>   common/spl/spl_fit.c | 16 +++++++++++++++-
>>>   1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>>> index a588d13eb40..c18c98b2959 100644
>>> --- a/common/spl/spl_fit.c
>>> +++ b/common/spl/spl_fit.c
>>> @@ -803,6 +803,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>>>   {
>>>   	struct spl_image_info image_info;
>>>   	struct spl_fit_info ctx;
>>> +	const void *fit_image_loadaddr;
>>> +	size_t fit_image_size;
>>>   	int node = -1;
>>>   	int ret;
>>>   	int index = 0;
>>> @@ -893,7 +895,19 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>>>   		if (firmware_node == node)
>>>   			continue;
>>>   
>>> -		image_info.load_addr = 0;
>>> +		/*
>>> +		 * If the 'load' property is not present in the image node,
>>> +		 * use the FIT image's data address as the fallback load
>>> +		 * address. This allows flexibility in omitting the load address
>>> +		 * during FIT creation time.
>>> +		 */
>>> +		ret = fit_image_get_data(ctx.fit, node,
>>> +					 &fit_image_loadaddr, &fit_image_size);
>>> +		if (ret < 0)
>>> +			panic("Error accessing node = %d in FIT (%d)\n", node,
>>> +			      ret);
>>> +
>>> +		image_info.load_addr = (ulong)fit_image_loadaddr;
>>>   		ret = load_simple_fit(info, offset, &ctx, node, &image_info);
>>>   		if (ret < 0 && ret != -EBADSLT) {
>>>   			printf("%s: can't load image loadables index %d (ret = %d)\n",
>> What's the IH_TYPE here? Saying to use something in-place is not always
>> safe.
> Looking at the rest of the series, and then going back to v1 and:
> https://lore.kernel.org/all/b6bc14fc-c823-4376-939f-2c0e6b120a2c@ti.com/
> we're IH_TYPE_STANDALONE which *does* require a load address


Yes.. we are trying to change that: support fit images with optional
load addresses. Ideally, load_simple_fit[0] would grab the loadaddr from
the fitNode, and if it is absent, it would use the address that we
populate as fallback above.
https://source.denx.de/u-boot/u-boot/-/blob/master/common/spl/spl_fit.c#L261


Please feel free to let me know if you are seeing any issues with this flow.

>   (see boot/image-fit.c).


https://source.denx.de/u-boot/u-boot/-/blob/master/boot/image-fit.c?ref_type=heads#L545-554
Here, we are just printing unavailable and not failing anywhere based on 
IH_TYPE_STANDALONE...
Could you please point out if I am missing something..?

Thanks,
Beleswar

> You might need to look in to a new type or see if
> another type is reasonable, that doesn't already expect a load address
> set.
>

Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

[Bryan Brattlof]

On December 31, 2025 thus sayeth Beleswar Padhi:
> Up until now, the R5 SPL in J722S platform was configured to start out
> of the SMS0_HSM_SRAM0_0 (0x0043C00000, 512KB) memory region. However,
> with the requirement of loading HSM M4F core with its own secure
> firmware, R5 SPL can no longer utilize that memory to execute itself.
> 
> Therefore, utilize the MSRAM8KX256E0_RAM (0x0043C40000, 256KB) memory
> region for loading and executing R5 SPL. Naturally, the SPL size has now
> to be trimmed to be fit inside the smaller 256KB region.
> 
> As an example, create a new defconfig (j722s_evm_r5_hsmboot_defconfig)
> which removes the SPI related configs to trim down the SPL size to
> ~175KB. The above defconfig demonstrates loading HSM core with SD, eMMC
> and UART bootmodes.

I am worried we will need to find a better way to handle the defconfigs 
which are mainly here for testing things. I agree we should have a way 
to test this driver but if we go this route we will have too many 
defconfigs and build instructions for each evaluation board to get our 
code coverage to the levels we want.

And it really only confuses people who are getting started.

~Bryan

Re: [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers

[Andrew Davis]

On 12/31/25 11:36 AM, Beleswar Padhi wrote:
> The board_fit_image_post_process() function assumes that all TIFSSTUB
> images appear at the end of the image_os_match[] array by using
> the condition:
> 
> 	i > IMAGE_ID_DM_FW

The check is (i < IMAGE_AMT && i > IMAGE_ID_DM_FW) so I has to be both
larger than IMAGE_ID_DM_FW *AND* less than IMAGE_AMT, given the enum is:

...
IMAGE_ID_DM_FW,
IMAGE_ID_TIFSSTUB_HS,
IMAGE_ID_TIFSSTUB_FS,
IMAGE_ID_TIFSSTUB_GP,
IMAGE_AMT,
...

Then only types that match this should be the 3 TIFSSTUB_* items.

That said, explicit matching is so much nicer, so you should keep this
patch but re-word the commit message.

> 
> However, this assumption breaks when new image types are appended to the
> enum and the array, causing unintended image types to match this
> condition and having their buffer sizes incorrectly set to 0 with:
> 
> 	*p_size = 0
> 
> To avoid this issue, replace the range-based check with an explicit
> match for TIFSSTUB image IDs.
> 
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> ---
> v3: Changelog:
> 1. None
> 
> Link to v2:
> https://lore.kernel.org/all/20250506104202.16741-7-b-padhi@ti.com/
> 
> v2: Changelog:
> 1. New patch. Fixes condition to allow new images to be added at the end
> of the enum.
> 
>   arch/arm/mach-k3/r5/common.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
> index 390e1324fb9..da1d1cb7230 100644
> --- a/arch/arm/mach-k3/r5/common.c
> +++ b/arch/arm/mach-k3/r5/common.c
> @@ -366,7 +366,9 @@ void board_fit_image_post_process(const void *fit, int node, void **p_image,
>   		}
>   	}
>   
> -	if (i < IMAGE_AMT && i > IMAGE_ID_DM_FW) {
> +	if (i < IMAGE_AMT &&
> +	    (i == IMAGE_ID_TIFSSTUB_HS || i == IMAGE_ID_TIFSSTUB_FS ||
> +	     i == IMAGE_ID_TIFSSTUB_GP)) {

You can drop the (i < IMAGE_AMT) part of the check, it will always be true
if "i" is one of the TIFSSTUB_* values, so just:

if (i == IMAGE_ID_TIFSSTUB_HS ||
     i == IMAGE_ID_TIFSSTUB_FS ||
     i == IMAGE_ID_TIFSSTUB_GP) {

Andrew

>   		int device_type = get_device_type();
>   
>   		if ((device_type == K3_DEVICE_TYPE_HS_SE &&

Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

[Andrew Davis]

On 1/5/26 8:11 AM, Bryan Brattlof wrote:
> On December 31, 2025 thus sayeth Beleswar Padhi:
>> Up until now, the R5 SPL in J722S platform was configured to start out
>> of the SMS0_HSM_SRAM0_0 (0x0043C00000, 512KB) memory region. However,
>> with the requirement of loading HSM M4F core with its own secure
>> firmware, R5 SPL can no longer utilize that memory to execute itself.
>>
>> Therefore, utilize the MSRAM8KX256E0_RAM (0x0043C40000, 256KB) memory
>> region for loading and executing R5 SPL. Naturally, the SPL size has now
>> to be trimmed to be fit inside the smaller 256KB region.
>>
>> As an example, create a new defconfig (j722s_evm_r5_hsmboot_defconfig)
>> which removes the SPI related configs to trim down the SPL size to
>> ~175KB. The above defconfig demonstrates loading HSM core with SD, eMMC
>> and UART bootmodes.
> 
> I am worried we will need to find a better way to handle the defconfigs
> which are mainly here for testing things. I agree we should have a way
> to test this driver but if we go this route we will have too many
> defconfigs and build instructions for each evaluation board to get our
> code coverage to the levels we want.
> 
> And it really only confuses people who are getting started.
> 

+1

Using the SMS_HSM_SRAM for the R5 SPL was always a bit hacky, might be
better to move the default defconfig over to using MSRAM for R5 SPL. This
would of course mean we have to shrink it down a bit, but the Sitara
platforms get by with as much SRAM without much issue already.

How far is the current R5 SPL on J722S from fitting in MSRAM currently?

Andrew

> ~Bryan
> 

Re: [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert

[Simon Glass]

Hi Beleswar,

On Wed, 31 Dec 2025 at 10:37, Beleswar Padhi <b-padhi@ti.com> wrote:
>
> The boot and load extensions in the x509 certificate are required for
> requesting the secure entity (TIFS) to boot a core. These fields are
> defined in the binman node for each core that must be booted by TIFS
> and must be included when generating the signed certificate.
>
> Add support to parse the boot and load extension properties from the
> binman node and populate them into the certificate. If any of the
> mandatory properties for an extension are missing, that respective
> extension section is NOT added to the certificate.
>
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> ---
> v3: Changelog:
> 1. New patch. Add support to sign HSM firmware here in U-Boot.
>
>  tools/binman/btool/openssl.py   | 49 ++++++++++++++++++++++++++++++---
>  tools/binman/etype/ti_secure.py | 18 ++++++++++++
>  tools/binman/etype/x509_cert.py |  4 ++-
>  3 files changed, 66 insertions(+), 5 deletions(-)
>
> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> index b26f087c447..35898aa488b 100644
> --- a/tools/binman/btool/openssl.py
> +++ b/tools/binman/btool/openssl.py
> @@ -82,7 +82,8 @@ imageSize              = INTEGER:{len(indata)}
>          return self.run_cmd(*args)
>
>      def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
> -                  config_fname, req_dist_name_dict, firewall_cert_data):
> +                  config_fname, req_dist_name_dict, firewall_cert_data,
> +                  boot_ext_data, load_ext_data):
>          """Create a certificate to be booted by system firmware
>
>          Args:
> @@ -101,12 +102,52 @@ imageSize              = INTEGER:{len(indata)}
>                  extended certificate
>                - certificate (str): Extended firewall certificate with
>                  the information for the firewall configurations.
> +            boot_ext_data (dict):
> +              - proc_id (int): The processor ID of core being booted
> +              - flags_set (int): The config flags to set for core being booted
> +              - flags_clr (int): The config flags to clear for core being booted
> +              - reset_vector (int): The location of reset vector for core being
> +                booted
> +            load_ext_data (dict):
> +              - dest_addr (int): The address to which image has to be copied
> +              - auth_type (int): Contains the host ID for core being booted and
> +                how the image is to be copied
>
>          Returns:
>              str: Tool output
>          """
>          indata = tools.read_file(input_fname)
>          hashval = hashlib.sha512(indata).hexdigest()
> +
> +        if boot_ext_data is not None:
> +            boot_ext = f'''
> +[ sysfw_boot_seq ]
> +bootCore = INTEGER:{boot_ext_data['proc_id']}
> +bootCoreOpts_set = INTEGER:{boot_ext_data['flags_set']}
> +bootCoreOpts_clr = INTEGER:{boot_ext_data['flags_clr']}
> +resetVec = FORMAT:HEX,OCT:{boot_ext_data['reset_vector']:08x}
> +# Reserved for future use
> +flagsValid = FORMAT:HEX,OCT:00000000
> +rsvd1 = INTEGER:0x00
> +rsdv2 = INTEGER:0x00
> +rsdv3 = INTEGER:0x00
> +'''
> +        else:
> +            boot_ext = ""
> +
> +        if load_ext_data is not None:
> +            load_ext = f'''
> +[ sysfw_image_load ]
> +destAddr = FORMAT:HEX,OCT:{load_ext_data['dest_addr']:08x}
> +authInPlace = INTEGER:{load_ext_data['auth_type']}
> +'''
> +        else:
> +            load_ext = f'''
> +[ sysfw_image_load ]
> +destAddr = FORMAT:HEX,OCT:00000000
> +authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
> +'''
> +
>          with open(config_fname, 'w', encoding='utf-8') as outf:
>              print(f'''[ req ]
>  distinguished_name     = req_distinguished_name
> @@ -138,9 +179,9 @@ shaType                = OID:2.16.840.1.101.3.4.2.3
>  shaValue               = FORMAT:HEX,OCT:{hashval}
>  imageSize              = INTEGER:{len(indata)}
>
> -[ sysfw_image_load ]
> -destAddr = FORMAT:HEX,OCT:00000000
> -authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
> +{boot_ext}
> +
> +{load_ext}
>
>  [ firewall ]
>  numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
> diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
> index f6caa0286d9..bc44b684892 100644
> --- a/tools/binman/etype/ti_secure.py
> +++ b/tools/binman/etype/ti_secure.py
> @@ -116,6 +116,7 @@ class Entry_ti_secure(Entry_x509_cert):
>          if auth_in_place:
>              self.firewall_cert_data['auth_in_place'] = auth_in_place
>              self.ReadFirewallNode()
> +        self.ReadLoadableCoreNode()
>          self.sha = fdt_util.GetInt(self._node, 'sha', 512)
>          self.req_dist_name = {'C': 'US',
>                  'ST': 'TX',
> @@ -126,6 +127,23 @@ class Entry_ti_secure(Entry_x509_cert):
>                  'emailAddress': 'support@ti.com'}
>          self.debug = fdt_util.GetBool(self._node, 'debug', False)
>
> +    def ReadLoadableCoreNode(self):
> +        boot_ext_props = ['proc_id', 'flags_set', 'flags_clr', 'reset_vector']
> +        load_ext_props = ['dest_addr', 'auth_type']
> +
> +        self.boot_ext = self.ReadDictFromList(boot_ext_props)
> +        self.load_ext = self.ReadDictFromList(load_ext_props)
> +
> +    def ReadDictFromList(self, props):
> +        props_dict = dict.fromkeys(props)
> +        for prop in props:
> +            val = fdt_util.GetInt(self._node, prop)
> +            if val is None:
> +                return None
> +            else:
> +                props_dict[prop] = val
> +        return props_dict
> +

It looks like you are adding new code but without a test. Please can
you run 'binman test -T' and ensure you cover all lines.

>      def ReadFirewallNode(self):
>          self.firewall_cert_data['certificate'] = ""
>          self.firewall_cert_data['num_firewalls'] = 0
> diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
> index b6e8b0b4fb0..b6028f6be84 100644
> --- a/tools/binman/etype/x509_cert.py
> +++ b/tools/binman/etype/x509_cert.py
> @@ -102,7 +102,9 @@ class Entry_x509_cert(Entry_collection):
>                  config_fname=config_fname,
>                  sw_rev=self.sw_rev,
>                  req_dist_name_dict=self.req_dist_name,
> -                firewall_cert_data=self.firewall_cert_data)
> +                firewall_cert_data=self.firewall_cert_data,
> +                boot_ext_data=self.boot_ext,
> +                load_ext_data=self.load_ext)
>          elif type == 'rom':
>              stdout = self.openssl.x509_cert_rom(
>                  cert_fname=output_fname,
> --
> 2.34.1
>

Regards,
Simon

Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

[Beleswar Prasad Padhi]

Hi Bryan, Andrew

On 05/01/26 22:49, Andrew Davis wrote:
> On 1/5/26 8:11 AM, Bryan Brattlof wrote:
>> On December 31, 2025 thus sayeth Beleswar Padhi:
>>> Up until now, the R5 SPL in J722S platform was configured to start out
>>> of the SMS0_HSM_SRAM0_0 (0x0043C00000, 512KB) memory region. However,
>>> with the requirement of loading HSM M4F core with its own secure
>>> firmware, R5 SPL can no longer utilize that memory to execute itself.
>>>
>>> Therefore, utilize the MSRAM8KX256E0_RAM (0x0043C40000, 256KB) memory
>>> region for loading and executing R5 SPL. Naturally, the SPL size has now
>>> to be trimmed to be fit inside the smaller 256KB region.
>>>
>>> As an example, create a new defconfig (j722s_evm_r5_hsmboot_defconfig)
>>> which removes the SPI related configs to trim down the SPL size to
>>> ~175KB. The above defconfig demonstrates loading HSM core with SD, eMMC
>>> and UART bootmodes.
>>
>> I am worried we will need to find a better way to handle the defconfigs
>> which are mainly here for testing things. I agree we should have a way
>> to test this driver but if we go this route we will have too many
>> defconfigs and build instructions for each evaluation board to get our
>> code coverage to the levels we want.
>>
>> And it really only confuses people who are getting started.
>>
>

Agreed, not a fan of creating multiple defconfigs too, But...

> +1
>
> Using the SMS_HSM_SRAM for the R5 SPL was always a bit hacky, might be
> better to move the default defconfig over to using MSRAM for R5 SPL. 


...won't that effect backward compat if we disable some configs?

> This
> would of course mean we have to shrink it down a bit, but the Sitara
> platforms get by with as much SRAM without much issue already.
>
> How far is the current R5 SPL on J722S from fitting in MSRAM currently?


It's not just R5 SPL but also it's required stack, heap, BSS, global data
and Scratchpad area. Adding all those we get ~270KB bin. Whereas
our MSRAM is 256KB.

So a bloat of ~14KB.

Thanks,
Beleswar

>
> Andrew
>
>> ~Bryan
>>
>

Re: [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert

[Beleswar Prasad Padhi]

Hi Simon,

On 06/01/26 05:00, Simon Glass wrote:
> Hi Beleswar,
>
> On Wed, 31 Dec 2025 at 10:37, Beleswar Padhi <b-padhi@ti.com> wrote:
>> The boot and load extensions in the x509 certificate are required for
>> requesting the secure entity (TIFS) to boot a core. These fields are
>> defined in the binman node for each core that must be booted by TIFS
>> and must be included when generating the signed certificate.
>>
>> Add support to parse the boot and load extension properties from the
>> binman node and populate them into the certificate. If any of the
>> mandatory properties for an extension are missing, that respective
>> extension section is NOT added to the certificate.
>>
>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>> ---
>> v3: Changelog:
>> 1. New patch. Add support to sign HSM firmware here in U-Boot.
>>
>>  tools/binman/btool/openssl.py   | 49 ++++++++++++++++++++++++++++++---
>>  tools/binman/etype/ti_secure.py | 18 ++++++++++++
>>  tools/binman/etype/x509_cert.py |  4 ++-
>>  3 files changed, 66 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
>> index b26f087c447..35898aa488b 100644
>> --- a/tools/binman/btool/openssl.py
>> +++ b/tools/binman/btool/openssl.py
>> @@ -82,7 +82,8 @@ imageSize              = INTEGER:{len(indata)}
>>          return self.run_cmd(*args)
>>
>>      def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
>> -                  config_fname, req_dist_name_dict, firewall_cert_data):
>> +                  config_fname, req_dist_name_dict, firewall_cert_data,
>> +                  boot_ext_data, load_ext_data):
>>          """Create a certificate to be booted by system firmware
>>
>>          Args:
>> @@ -101,12 +102,52 @@ imageSize              = INTEGER:{len(indata)}
>>                  extended certificate
>>                - certificate (str): Extended firewall certificate with
>>                  the information for the firewall configurations.
>> +            boot_ext_data (dict):
>> +              - proc_id (int): The processor ID of core being booted
>> +              - flags_set (int): The config flags to set for core being booted
>> +              - flags_clr (int): The config flags to clear for core being booted
>> +              - reset_vector (int): The location of reset vector for core being
>> +                booted
>> +            load_ext_data (dict):
>> +              - dest_addr (int): The address to which image has to be copied
>> +              - auth_type (int): Contains the host ID for core being booted and
>> +                how the image is to be copied
>>
>>          Returns:
>>              str: Tool output
>>          """
>>          indata = tools.read_file(input_fname)
>>          hashval = hashlib.sha512(indata).hexdigest()
>> +
>> +        if boot_ext_data is not None:
>> +            boot_ext = f'''
>> +[ sysfw_boot_seq ]
>> +bootCore = INTEGER:{boot_ext_data['proc_id']}
>> +bootCoreOpts_set = INTEGER:{boot_ext_data['flags_set']}
>> +bootCoreOpts_clr = INTEGER:{boot_ext_data['flags_clr']}
>> +resetVec = FORMAT:HEX,OCT:{boot_ext_data['reset_vector']:08x}
>> +# Reserved for future use
>> +flagsValid = FORMAT:HEX,OCT:00000000
>> +rsvd1 = INTEGER:0x00
>> +rsdv2 = INTEGER:0x00
>> +rsdv3 = INTEGER:0x00
>> +'''
>> +        else:
>> +            boot_ext = ""
>> +
>> +        if load_ext_data is not None:
>> +            load_ext = f'''
>> +[ sysfw_image_load ]
>> +destAddr = FORMAT:HEX,OCT:{load_ext_data['dest_addr']:08x}
>> +authInPlace = INTEGER:{load_ext_data['auth_type']}
>> +'''
>> +        else:
>> +            load_ext = f'''
>> +[ sysfw_image_load ]
>> +destAddr = FORMAT:HEX,OCT:00000000
>> +authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
>> +'''
>> +
>>          with open(config_fname, 'w', encoding='utf-8') as outf:
>>              print(f'''[ req ]
>>  distinguished_name     = req_distinguished_name
>> @@ -138,9 +179,9 @@ shaType                = OID:2.16.840.1.101.3.4.2.3
>>  shaValue               = FORMAT:HEX,OCT:{hashval}
>>  imageSize              = INTEGER:{len(indata)}
>>
>> -[ sysfw_image_load ]
>> -destAddr = FORMAT:HEX,OCT:00000000
>> -authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
>> +{boot_ext}
>> +
>> +{load_ext}
>>
>>  [ firewall ]
>>  numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
>> diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
>> index f6caa0286d9..bc44b684892 100644
>> --- a/tools/binman/etype/ti_secure.py
>> +++ b/tools/binman/etype/ti_secure.py
>> @@ -116,6 +116,7 @@ class Entry_ti_secure(Entry_x509_cert):
>>          if auth_in_place:
>>              self.firewall_cert_data['auth_in_place'] = auth_in_place
>>              self.ReadFirewallNode()
>> +        self.ReadLoadableCoreNode()
>>          self.sha = fdt_util.GetInt(self._node, 'sha', 512)
>>          self.req_dist_name = {'C': 'US',
>>                  'ST': 'TX',
>> @@ -126,6 +127,23 @@ class Entry_ti_secure(Entry_x509_cert):
>>                  'emailAddress': 'support@ti.com'}
>>          self.debug = fdt_util.GetBool(self._node, 'debug', False)
>>
>> +    def ReadLoadableCoreNode(self):
>> +        boot_ext_props = ['proc_id', 'flags_set', 'flags_clr', 'reset_vector']
>> +        load_ext_props = ['dest_addr', 'auth_type']
>> +
>> +        self.boot_ext = self.ReadDictFromList(boot_ext_props)
>> +        self.load_ext = self.ReadDictFromList(load_ext_props)
>> +
>> +    def ReadDictFromList(self, props):
>> +        props_dict = dict.fromkeys(props)
>> +        for prop in props:
>> +            val = fdt_util.GetInt(self._node, prop)
>> +            if val is None:
>> +                return None
>> +            else:
>> +                props_dict[prop] = val
>> +        return props_dict
>> +
> It looks like you are adding new code but without a test. Please can
> you run 'binman test -T' and ensure you cover all lines.


Thanks for pointing out. I will add a test for the same in v4.

Thanks,
Beleswar

>
>>      def ReadFirewallNode(self):
>>          self.firewall_cert_data['certificate'] = ""
>>          self.firewall_cert_data['num_firewalls'] = 0
>> diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
>> index b6e8b0b4fb0..b6028f6be84 100644
>> --- a/tools/binman/etype/x509_cert.py
>> +++ b/tools/binman/etype/x509_cert.py
>> @@ -102,7 +102,9 @@ class Entry_x509_cert(Entry_collection):
>>                  config_fname=config_fname,
>>                  sw_rev=self.sw_rev,
>>                  req_dist_name_dict=self.req_dist_name,
>> -                firewall_cert_data=self.firewall_cert_data)
>> +                firewall_cert_data=self.firewall_cert_data,
>> +                boot_ext_data=self.boot_ext,
>> +                load_ext_data=self.load_ext)
>>          elif type == 'rom':
>>              stdout = self.openssl.x509_cert_rom(
>>                  cert_fname=output_fname,
>> --
>> 2.34.1
>>
> Regards,
> Simon

Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

On Tue, Jan 06, 2026 at 04:07:44PM +0530, Beleswar Prasad Padhi wrote:
> Hi Bryan, Andrew
> 
> On 05/01/26 22:49, Andrew Davis wrote:
> > On 1/5/26 8:11 AM, Bryan Brattlof wrote:
> >> On December 31, 2025 thus sayeth Beleswar Padhi:
> >>> Up until now, the R5 SPL in J722S platform was configured to start out
> >>> of the SMS0_HSM_SRAM0_0 (0x0043C00000, 512KB) memory region. However,
> >>> with the requirement of loading HSM M4F core with its own secure
> >>> firmware, R5 SPL can no longer utilize that memory to execute itself.
> >>>
> >>> Therefore, utilize the MSRAM8KX256E0_RAM (0x0043C40000, 256KB) memory
> >>> region for loading and executing R5 SPL. Naturally, the SPL size has now
> >>> to be trimmed to be fit inside the smaller 256KB region.
> >>>
> >>> As an example, create a new defconfig (j722s_evm_r5_hsmboot_defconfig)
> >>> which removes the SPI related configs to trim down the SPL size to
> >>> ~175KB. The above defconfig demonstrates loading HSM core with SD, eMMC
> >>> and UART bootmodes.
> >>
> >> I am worried we will need to find a better way to handle the defconfigs
> >> which are mainly here for testing things. I agree we should have a way
> >> to test this driver but if we go this route we will have too many
> >> defconfigs and build instructions for each evaluation board to get our
> >> code coverage to the levels we want.
> >>
> >> And it really only confuses people who are getting started.
> >>
> >
> 
> Agreed, not a fan of creating multiple defconfigs too, But...
> 
> > +1
> >
> > Using the SMS_HSM_SRAM for the R5 SPL was always a bit hacky, might be
> > better to move the default defconfig over to using MSRAM for R5 SPL. 
> 
> 
> ...won't that effect backward compat if we disable some configs?
> 
> > This
> > would of course mean we have to shrink it down a bit, but the Sitara
> > platforms get by with as much SRAM without much issue already.
> >
> > How far is the current R5 SPL on J722S from fitting in MSRAM currently?
> 
> 
> It's not just R5 SPL but also it's required stack, heap, BSS, global data
> and Scratchpad area. Adding all those we get ~270KB bin. Whereas
> our MSRAM is 256KB.
> 
> So a bloat of ~14KB.

Taking a quick peek, CONFIG_SPL_EFI_PARTITION=y can be dropped I bet and
maybe CONFIG_SPL_YMODEM_SUPPORT=y doesn't need to be in every build? It
might be worth sitting down and working out which boot use cases need to
be supported in the basic build for the platform and which ones it's OK
to have the user build, or build in your SDK or what-have-you. I'd
really hope we can still make something both useful and functional in
256KiB of memory.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]