* [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2026-01-02 14:47 ` Tom Rini
2025-12-31 17:36 ` [PATCH v3 02/11] arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is missing Beleswar Padhi
` (10 subsequent siblings)
11 siblings, 1 reply; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot, Simon Glass
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent
2025-12-31 17:36 ` [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent Beleswar Padhi
@ 2026-01-02 14:47 ` Tom Rini
2026-01-02 14:55 ` Tom Rini
0 siblings, 1 reply; 23+ messages in thread
From: Tom Rini @ 2026-01-02 14:47 UTC (permalink / raw)
To: Beleswar Padhi
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot,
Simon Glass
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent
2026-01-02 14:47 ` Tom Rini
@ 2026-01-02 14:55 ` Tom Rini
2026-01-05 7:17 ` Padhi, Beleswar
0 siblings, 1 reply; 23+ messages in thread
From: Tom Rini @ 2026-01-02 14:55 UTC (permalink / raw)
To: Beleswar Padhi
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot,
Simon Glass
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent
2026-01-02 14:55 ` Tom Rini
@ 2026-01-05 7:17 ` Padhi, Beleswar
0 siblings, 0 replies; 23+ messages in thread
From: Padhi, Beleswar @ 2026-01-05 7:17 UTC (permalink / raw)
To: Tom Rini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot,
Simon Glass
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.
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v3 02/11] arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is missing
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers Beleswar Padhi
` (9 subsequent siblings)
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 02/11] arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is missing Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2026-01-05 16:53 ` Andrew Davis
2025-12-31 17:36 ` [PATCH v3 04/11] arm: mach-k3: Add config option for packaging HSM firmware Beleswar Padhi
` (8 subsequent siblings)
11 siblings, 1 reply; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers
2025-12-31 17:36 ` [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers Beleswar Padhi
@ 2026-01-05 16:53 ` Andrew Davis
0 siblings, 0 replies; 23+ messages in thread
From: Andrew Davis @ 2026-01-05 16:53 UTC (permalink / raw)
To: Beleswar Padhi, trini
Cc: bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot
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 &&
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v3 04/11] arm: mach-k3: Add config option for packaging HSM firmware
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (2 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 05/11] arm: dts: k3-binman: Add template for packing " Beleswar Padhi
` (7 subsequent siblings)
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 05/11] arm: dts: k3-binman: Add template for packing HSM firmware
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (3 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 04/11] arm: mach-k3: Add config option for packaging HSM firmware Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 06/11] arm: dts: k3-{j721s2/j722s/j784s4}-binman: Pack HSM firmware inside tispl.bin Beleswar Padhi
` (6 subsequent siblings)
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 06/11] arm: dts: k3-{j721s2/j722s/j784s4}-binman: Pack HSM firmware inside tispl.bin
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (4 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 05/11] arm: dts: k3-binman: Add template for packing " Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert Beleswar Padhi
` (5 subsequent siblings)
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (5 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 06/11] arm: dts: k3-{j721s2/j722s/j784s4}-binman: Pack HSM firmware inside tispl.bin Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2026-01-05 23:30 ` Simon Glass
2025-12-31 17:36 ` [PATCH v3 08/11] arm: dts: k3-{j721s2/j722s/j784s4}-r5.dtsi: Enable HSM core Beleswar Padhi
` (4 subsequent siblings)
11 siblings, 1 reply; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert
2025-12-31 17:36 ` [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert Beleswar Padhi
@ 2026-01-05 23:30 ` Simon Glass
2026-01-06 10:52 ` Beleswar Prasad Padhi
0 siblings, 1 reply; 23+ messages in thread
From: Simon Glass @ 2026-01-05 23:30 UTC (permalink / raw)
To: Beleswar Padhi
Cc: trini, afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1,
u-boot
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
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert
2026-01-05 23:30 ` Simon Glass
@ 2026-01-06 10:52 ` Beleswar Prasad Padhi
0 siblings, 0 replies; 23+ messages in thread
From: Beleswar Prasad Padhi @ 2026-01-06 10:52 UTC (permalink / raw)
To: Simon Glass
Cc: trini, afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1,
u-boot
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v3 08/11] arm: dts: k3-{j721s2/j722s/j784s4}-r5.dtsi: Enable HSM core
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (6 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 09/11] remoteproc: k3-hsm: Introduce a remoteproc driver for K3 " Beleswar Padhi
` (3 subsequent siblings)
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 09/11] remoteproc: k3-hsm: Introduce a remoteproc driver for K3 HSM core
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (7 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 08/11] arm: dts: k3-{j721s2/j722s/j784s4}-r5.dtsi: Enable HSM core Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 10/11] arm: mach-k3: r5: common: Invoke boot of HSM M4 core Beleswar Padhi
` (2 subsequent siblings)
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 10/11] arm: mach-k3: r5: common: Invoke boot of HSM M4 core
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (8 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 09/11] remoteproc: k3-hsm: Introduce a remoteproc driver for K3 " Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot Beleswar Padhi
2026-01-02 14:43 ` [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Tom Rini
11 siblings, 0 replies; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (9 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 10/11] arm: mach-k3: r5: common: Invoke boot of HSM M4 core Beleswar Padhi
@ 2025-12-31 17:36 ` Beleswar Padhi
2026-01-05 14:11 ` Bryan Brattlof
2026-01-02 14:43 ` [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Tom Rini
11 siblings, 1 reply; 23+ messages in thread
From: Beleswar Padhi @ 2025-12-31 17:36 UTC (permalink / raw)
To: trini
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, b-padhi,
u-boot
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
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot
2025-12-31 17:36 ` [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot Beleswar Padhi
@ 2026-01-05 14:11 ` Bryan Brattlof
2026-01-05 17:19 ` Andrew Davis
0 siblings, 1 reply; 23+ messages in thread
From: Bryan Brattlof @ 2026-01-05 14:11 UTC (permalink / raw)
To: Beleswar Padhi
Cc: trini, afd, anshuld, hnagalla, jm, nm, n-francis, u-kumar1,
u-boot
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot
2026-01-05 14:11 ` Bryan Brattlof
@ 2026-01-05 17:19 ` Andrew Davis
2026-01-06 10:37 ` Beleswar Prasad Padhi
0 siblings, 1 reply; 23+ messages in thread
From: Andrew Davis @ 2026-01-05 17:19 UTC (permalink / raw)
To: Bryan Brattlof, Beleswar Padhi
Cc: trini, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot
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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot
2026-01-05 17:19 ` Andrew Davis
@ 2026-01-06 10:37 ` Beleswar Prasad Padhi
2026-01-06 13:59 ` Tom Rini
0 siblings, 1 reply; 23+ messages in thread
From: Beleswar Prasad Padhi @ 2026-01-06 10:37 UTC (permalink / raw)
To: Andrew Davis, Bryan Brattlof
Cc: trini, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot
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
>>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot
2026-01-06 10:37 ` Beleswar Prasad Padhi
@ 2026-01-06 13:59 ` Tom Rini
0 siblings, 0 replies; 23+ messages in thread
From: Tom Rini @ 2026-01-06 13:59 UTC (permalink / raw)
To: Beleswar Prasad Padhi
Cc: Andrew Davis, Bryan Brattlof, anshuld, hnagalla, jm, nm,
n-francis, u-kumar1, u-boot
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
` (10 preceding siblings ...)
2025-12-31 17:36 ` [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot Beleswar Padhi
@ 2026-01-02 14:43 ` Tom Rini
11 siblings, 0 replies; 23+ messages in thread
From: Tom Rini @ 2026-01-02 14:43 UTC (permalink / raw)
To: Beleswar Padhi
Cc: afd, bb, anshuld, hnagalla, jm, nm, n-francis, u-kumar1, u-boot
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread