[PATCH v3 0/2] Add TI K3 HSM M4F nodes in device-tree

[PATCH v3 0/2] Add TI K3 HSM M4F nodes in device-tree

[Beleswar Padhi]

Some of the TI K3 family of SoCs (like J721S2, J784S4, J722S) have a
HSM (High Security Module) M4F core in the Wakeup Voltage Domain which
could be used to run secure services like Authentication. Add the device
device-tree node definitions for this HSM M4F core. The bindings for
this has already been merged[0].

The HSM M4 core is typically booted early from the bootloader and the
driver for the same is posted in U-Boot mailing list[1].

v3: Changelog:
[Nishanth]:
 1. Use generic node name 'remoteproc'
 2. Use label 'hsm' instead of 'hsm_m4fss'
 3. Add a comment for separate SRAMs
 4. Change firmware-name value to match existing naming convention
 5. Change status to 'reserved' and add a commment
 6. Re-order bootph-pre-ram property before vendor properties
 7. Update commit message to call out rationale for putting firmare-name
    in SoC level dtsi
 8. Dropped [PATCH v2 1/3] in v3 as it is already merged[0].

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

v2: Changelog:
[Krzysztof Kozlowski]:
 In [PATCH v2 1/3]
 1. Update commit msg to remove redundant "bindings".
 2. Update filename to match compatible.
 3. Remove "address-cells" & "size-cells" property. These belong to the
    device's parent node.
 4. Drop description from firmware-name property.
 5. Fix indentation for DT example.

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

[0]: https://lore.kernel.org/all/aV59SdFU15HpLHeO@p14s/
[1]: https://lore.kernel.org/all/20251231173621.1069988-1-b-padhi@ti.com/

Beleswar Padhi (2):
  arm64: dts: ti: k3-{j784s4-j742s2/j721s2}-mcu-wakeup: Add HSM M4F node
  arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

 .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 +++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
 .../arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 17 +++++++++++++++++
 arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
 arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
 .../arm64/boot/dts/ti/k3-j742s2-mcu-wakeup.dtsi |  4 ++++
 .../ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi  | 17 +++++++++++++++++
 7 files changed, 62 insertions(+)

-- 
2.34.1

[PATCH v3 1/2] arm64: dts: ti: k3-{j784s4-j742s2/j721s2}-mcu-wakeup: Add HSM M4F node

[Beleswar Padhi]

The TI K3 J721S2, J784S4 and J742S2 SoCs have a HSM (High Security
Module) M4F core in the Wakeup Voltage Domain which could be used to run
secure services like Authentication. Add Device Tree Node definitions
for the HSM core in the respective SoC wakeup dtsi files.

The HSM node is reserved to be loaded and booted by the early-stage
bootloader. The firmware-name property is defined at the SoC level
since the HSM is not a general-purpose remote core and boards are
unlikely to use separate firmware. If needed in exceptional cases,
board-specific device trees can override this property.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
[Nishanth]:
 1. Use generic node name 'remoteproc'
 2. Use label 'hsm' instead of 'hsm_m4fss'
 3. Add a comment for separate SRAMs
 4. Update firmware-name property to match existing naming conventions
 5. Change status to 'reserved' and add a commment
 6. Re-order bootph-pre-ram property before vendor properties
 7. Update commit msg adding rationale for firmware-name in SoC.dtsi

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

v2: Changelog:
1. None

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

 .../arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 17 +++++++++++++++++
 .../arm64/boot/dts/ti/k3-j742s2-mcu-wakeup.dtsi |  4 ++++
 .../ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi  | 17 +++++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
index fd01437726ab4..32ee8031cfcb6 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
@@ -766,4 +766,21 @@ mcu_watchdog1: watchdog@40610000 {
 		/* reserved for MCU_R5F0_1 */
 		status = "reserved";
 	};
+
+	hsm: remoteproc@43c00000 {
+		compatible = "ti,hsm-m4fss";
+		/* contiguous regions but instantiated separately in HW */
+		reg = <0x00 0x43c00000 0x00 0x20000>,
+		      <0x00 0x43c20000 0x00 0x10000>,
+		      <0x00 0x43c30000 0x00 0x10000>;
+		reg-names = "sram0_0", "sram0_1", "sram1";
+		resets = <&k3_reset 304 1>;
+		firmware-name = "j721s2-hsm-m4f-fw";
+		bootph-pre-ram;
+		ti,sci = <&sms>;
+		ti,sci-dev-id = <304>;
+		ti,sci-proc-ids = <0x80 0xff>;
+		/* reserved for early-stage bootloader */
+		status = "reserved";
+	};
 };
diff --git a/arch/arm64/boot/dts/ti/k3-j742s2-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j742s2-mcu-wakeup.dtsi
index 61db2348d6a47..2f40afcfa67c4 100644
--- a/arch/arm64/boot/dts/ti/k3-j742s2-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j742s2-mcu-wakeup.dtsi
@@ -15,3 +15,7 @@ &mcu_r5fss0_core0 {
 &mcu_r5fss0_core1 {
 	firmware-name = "j742s2-mcu-r5f0_1-fw";
 };
+
+&hsm {
+	firmware-name = "j742s2-hsm-m4f-fw";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi
index cc22bfb5f5996..df37902c963ff 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi
@@ -762,4 +762,21 @@ mcu_watchdog1: watchdog@40610000 {
 		/* reserved for MCU_R5F0_1 */
 		status = "reserved";
 	};
+
+	hsm: remoteproc@43c00000 {
+		compatible = "ti,hsm-m4fss";
+		/* contiguous regions but instantiated separately in HW */
+		reg = <0x00 0x43c00000 0x00 0x20000>,
+		      <0x00 0x43c20000 0x00 0x10000>,
+		      <0x00 0x43c30000 0x00 0x10000>;
+		reg-names = "sram0_0", "sram0_1", "sram1";
+		resets = <&k3_reset 371 1>;
+		firmware-name = "j784s4-hsm-m4f-fw";
+		bootph-pre-ram;
+		ti,sci = <&sms>;
+		ti,sci-dev-id = <371>;
+		ti,sci-proc-ids = <0x80 0xff>;
+		/* reserved for early-stage bootloader */
+		status = "reserved";
+	};
 };
-- 
2.34.1

[PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

[Beleswar Padhi]

The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
core in the MAIN Voltage Domain which could be used to run secure
services like Authentication. Add Device Tree Node definitions for the
HSM core in the respective SoC common main dtsi file.

The HSM node is reserved to be loaded and booted by the early-stage
bootloader. The firmware-name property is defined at the SoC level
since the HSM is not a general-purpose remote core and boards are
unlikely to use separate firmware. If needed in exceptional cases,
board-specific device trees can override this property.

The corresponding reg ranges of HSM node has also been added to its
parent node's (cbass_main bus) ranges property.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v3: Changelog:
[Nishanth]:
 1. Use generic node name 'remoteproc'
 2. Use label 'hsm' instead of 'hsm_m4fss'
 3. Add a comment for separate SRAMs
 4. Update firmware-name property to match existing naming conventions
 5. Change status to 'reserved' and add a commment
 6. Re-order bootph-pre-ram property before vendor properties
 7. Update commit msg adding rationale for firmware-name in SoC.dtsi

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

v2: Changelog:
1. None

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

 .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 +++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
 arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
 arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
 4 files changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
index 3cf7c2b3ce2dd..0e1af2a69ca2e 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
@@ -1117,4 +1117,21 @@ vpu: video-codec@30210000 {
 		clocks = <&k3_clks 204 2>;
 		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
 	};
+
+	hsm: remoteproc@43c00000 {
+		compatible = "ti,hsm-m4fss";
+		/* contiguous regions but instantiated separately in HW */
+		reg = <0x00 0x43c00000 0x00 0x20000>,
+		      <0x00 0x43c20000 0x00 0x10000>,
+		      <0x00 0x43c30000 0x00 0x10000>;
+		reg-names = "sram0_0", "sram0_1", "sram1";
+		resets = <&k3_reset 225 1>;
+		firmware-name = "am62p-hsm-m4f-fw";
+		bootph-pre-ram;
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <225>;
+		ti,sci-proc-ids = <0x80 0xff>;
+		/* reserved for early-stage bootloader */
+		status = "reserved";
+	};
 };
diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
index e2c01328eb298..9d6266d6ddb82 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
@@ -96,6 +96,7 @@ cbass_main: bus@f0000 {
 			 <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* USB1 DWC3 Core window */
 			 <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* SA3UL */
 			 <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* SA3 sproxy data */
+			 <0x00 0x43c00000 0x00 0x43c00000 0x00 0x00040000>, /* HSM SRAM ranges */
 			 <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
 			 <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* SA3 sproxy config */
 			 <0x00 0x48000000 0x00 0x48000000 0x00 0x06408000>, /* DMSS */
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 873415ec4fa37..9ee5d0c8ffd1e 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -429,6 +429,11 @@ &wkup_r5fss0_core0 {
 	firmware-name = "j722s-wkup-r5f0_0-fw";
 };
 
+/* MAIN domain overrides */
+&hsm {
+	firmware-name = "j722s-hsm-m4f-fw";
+};
+
 &main_conf {
 	serdes_ln_ctrl: mux-controller@4080 {
 		compatible = "reg-mux";
diff --git a/arch/arm64/boot/dts/ti/k3-j722s.dtsi b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
index c8b634c346779..059c65ece183f 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
@@ -173,6 +173,7 @@ cbass_main: bus@f0000 {
 			 <0x00 0x31200000 0x00 0x31200000 0x00 0x00040000>, /* USB1 DWC3 Core window */
 			 <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* SA3UL */
 			 <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* SA3 sproxy data */
+			 <0x00 0x43c00000 0x00 0x43c00000 0x00 0x00040000>, /* HSM SRAM ranges */
 			 <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
 			 <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* SA3 sproxy config */
 			 <0x00 0x48000000 0x00 0x48000000 0x00 0x06408000>, /* DMSS */
-- 
2.34.1

Re: [PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

[Kumar, Udit]

Hi Beleswar,

On 1/14/2026 11:05 PM, Beleswar Padhi wrote:
> The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
> core in the MAIN Voltage Domain which could be used to run secure
> services like Authentication. Add Device Tree Node definitions for the
> HSM core in the respective SoC common main dtsi file.
>
> The HSM node is reserved to be loaded and booted by the early-stage
> bootloader. The firmware-name property is defined at the SoC level
> since the HSM is not a general-purpose remote core and boards are
> unlikely to use separate firmware. If needed in exceptional cases,
> board-specific device trees can override this property.
>
> The corresponding reg ranges of HSM node has also been added to its
> parent node's (cbass_main bus) ranges property.
>
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> ---
> v3: Changelog:
> [Nishanth]:
>   1. Use generic node name 'remoteproc'
>   2. Use label 'hsm' instead of 'hsm_m4fss'
>   3. Add a comment for separate SRAMs
>   4. Update firmware-name property to match existing naming conventions
>   5. Change status to 'reserved' and add a commment
>   6. Re-order bootph-pre-ram property before vendor properties
>   7. Update commit msg adding rationale for firmware-name in SoC.dtsi
>
> Link to v2:
> https://lore.kernel.org/all/20260106104755.948086-4-b-padhi@ti.com/
>
> v2: Changelog:
> 1. None
>
> Link to v1:
> https://lore.kernel.org/all/20251231165102.950644-4-b-padhi@ti.com/
>
>   .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 +++++++++++++++++
>   arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
>   arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
>   arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
>   4 files changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> index 3cf7c2b3ce2dd..0e1af2a69ca2e 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> @@ -1117,4 +1117,21 @@ vpu: video-codec@30210000 {
>   		clocks = <&k3_clks 204 2>;
>   		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
>   	};
> +
> +	hsm: remoteproc@43c00000 {
> +		compatible = "ti,hsm-m4fss";
> +		/* contiguous regions but instantiated separately in HW */
> +		reg = <0x00 0x43c00000 0x00 0x20000>,
> +		      <0x00 0x43c20000 0x00 0x10000>,
> +		      <0x00 0x43c30000 0x00 0x10000>;
> +		reg-names = "sram0_0", "sram0_1", "sram1";
> +		resets = <&k3_reset 225 1>;
> +		firmware-name = "am62p-hsm-m4f-fw";

you don't need clock and power-domain for this ?


> +		bootph-pre-ram;
> +		ti,sci = <&dmsc>;
> +		ti,sci-dev-id = <225>;
> +		ti,sci-proc-ids = <0x80 0xff>;
> +		/* reserved for early-stage bootloader */
> +		status = "reserved";
> +	};
>   };
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
> index e2c01328eb298..9d6266d6ddb82 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
> @@ -96,6 +96,7 @@ cbass_main: bus@f0000 {
>   			 <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* USB1 DWC3 Core window */
>   			 <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* SA3UL */
> [..]

Re: [PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

[Padhi, Beleswar]

Hi Udit,

On 1/15/2026 10:06 AM, Kumar, Udit wrote:
> Hi Beleswar,
>
> On 1/14/2026 11:05 PM, Beleswar Padhi wrote:
>> The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
>> core in the MAIN Voltage Domain which could be used to run secure
>> services like Authentication. Add Device Tree Node definitions for the
>> HSM core in the respective SoC common main dtsi file.
>>
>> The HSM node is reserved to be loaded and booted by the early-stage
>> bootloader. The firmware-name property is defined at the SoC level
>> since the HSM is not a general-purpose remote core and boards are
>> unlikely to use separate firmware. If needed in exceptional cases,
>> board-specific device trees can override this property.
>>
>> The corresponding reg ranges of HSM node has also been added to its
>> parent node's (cbass_main bus) ranges property.
>>
>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>> ---
>> v3: Changelog:
>> [Nishanth]:
>>   1. Use generic node name 'remoteproc'
>>   2. Use label 'hsm' instead of 'hsm_m4fss'
>>   3. Add a comment for separate SRAMs
>>   4. Update firmware-name property to match existing naming conventions
>>   5. Change status to 'reserved' and add a commment
>>   6. Re-order bootph-pre-ram property before vendor properties
>>   7. Update commit msg adding rationale for firmware-name in SoC.dtsi
>>
>> Link to v2:
>> https://lore.kernel.org/all/20260106104755.948086-4-b-padhi@ti.com/
>>
>> v2: Changelog:
>> 1. None
>>
>> Link to v1:
>> https://lore.kernel.org/all/20251231165102.950644-4-b-padhi@ti.com/
>>
>>   .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 +++++++++++++++++
>>   arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
>>   arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
>>   arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
>>   4 files changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi 
>> b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>> index 3cf7c2b3ce2dd..0e1af2a69ca2e 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>> @@ -1117,4 +1117,21 @@ vpu: video-codec@30210000 {
>>           clocks = <&k3_clks 204 2>;
>>           power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
>>       };
>> +
>> +    hsm: remoteproc@43c00000 {
>> +        compatible = "ti,hsm-m4fss";
>> +        /* contiguous regions but instantiated separately in HW */
>> +        reg = <0x00 0x43c00000 0x00 0x20000>,
>> +              <0x00 0x43c20000 0x00 0x10000>,
>> +              <0x00 0x43c30000 0x00 0x10000>;
>> +        reg-names = "sram0_0", "sram0_1", "sram1";
>> +        resets = <&k3_reset 225 1>;
>> +        firmware-name = "am62p-hsm-m4f-fw";
>
> you don't need clock and power-domain for this ?


That info is abstracted out via ti-sci calls. ti_sci_cmd_get_device()
takes care of setting clocks and power domains for us.

Same for other rprocs:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi#L178

Thanks,
Beleswar

>
>
>> +        bootph-pre-ram;
>> +        ti,sci = <&dmsc>;
>> +        ti,sci-dev-id = <225>;
>> +        ti,sci-proc-ids = <0x80 0xff>;
>> +        /* reserved for early-stage bootloader */
>> +        status = "reserved";
>> +    };
>>   };
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi 
>> b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>> index e2c01328eb298..9d6266d6ddb82 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>> @@ -96,6 +96,7 @@ cbass_main: bus@f0000 {
>>                <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* 
>> USB1 DWC3 Core window */
>>                <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* 
>> SA3UL */
>> [..]

Re: [PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

[Kumar, Udit]

On 1/15/2026 11:11 AM, Padhi, Beleswar wrote:
> Hi Udit,
>
> On 1/15/2026 10:06 AM, Kumar, Udit wrote:
>> Hi Beleswar,
>>
>> On 1/14/2026 11:05 PM, Beleswar Padhi wrote:
>>> The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
>>> core in the MAIN Voltage Domain which could be used to run secure
>>> services like Authentication. Add Device Tree Node definitions for the
>>> HSM core in the respective SoC common main dtsi file.
>>>
>>> The HSM node is reserved to be loaded and booted by the early-stage
>>> bootloader. The firmware-name property is defined at the SoC level
>>> since the HSM is not a general-purpose remote core and boards are
>>> unlikely to use separate firmware. If needed in exceptional cases,
>>> board-specific device trees can override this property.
>>>
>>> The corresponding reg ranges of HSM node has also been added to its
>>> parent node's (cbass_main bus) ranges property.
>>>
>>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>>> ---
>>> v3: Changelog:
>>> [Nishanth]:
>>>   1. Use generic node name 'remoteproc'
>>>   2. Use label 'hsm' instead of 'hsm_m4fss'
>>>   3. Add a comment for separate SRAMs
>>>   4. Update firmware-name property to match existing naming conventions
>>>   5. Change status to 'reserved' and add a commment
>>>   6. Re-order bootph-pre-ram property before vendor properties
>>>   7. Update commit msg adding rationale for firmware-name in SoC.dtsi
>>>
>>> Link to v2:
>>> https://lore.kernel.org/all/20260106104755.948086-4-b-padhi@ti.com/
>>>
>>> v2: Changelog:
>>> 1. None
>>>
>>> Link to v1:
>>> https://lore.kernel.org/all/20251231165102.950644-4-b-padhi@ti.com/
>>>
>>>   .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 
>>> +++++++++++++++++
>>>   arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
>>>   arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
>>>   arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
>>>   4 files changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi 
>>> b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>> index 3cf7c2b3ce2dd..0e1af2a69ca2e 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>> @@ -1117,4 +1117,21 @@ vpu: video-codec@30210000 {
>>>           clocks = <&k3_clks 204 2>;
>>>           power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
>>>       };
>>> +
>>> +    hsm: remoteproc@43c00000 {
>>> +        compatible = "ti,hsm-m4fss";
>>> +        /* contiguous regions but instantiated separately in HW */
>>> +        reg = <0x00 0x43c00000 0x00 0x20000>,
>>> +              <0x00 0x43c20000 0x00 0x10000>,
>>> +              <0x00 0x43c30000 0x00 0x10000>;
>>> +        reg-names = "sram0_0", "sram0_1", "sram1";
>>> +        resets = <&k3_reset 225 1>;
>>> +        firmware-name = "am62p-hsm-m4f-fw";
>>
>> you don't need clock and power-domain for this ?
>
>
> That info is abstracted out via ti-sci calls. ti_sci_cmd_get_device()
> takes care of setting clocks and power domains for us.
>
> Same for other rprocs:
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi#L178 
>


Is this specific handling for m4 core ? , I see other rproc got power at 
cluster level

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi#L1518 



>
> Thanks,
> Beleswar
>
>>
>>
>>> +        bootph-pre-ram;
>>> +        ti,sci = <&dmsc>;
>>> +        ti,sci-dev-id = <225>;
>>> +        ti,sci-proc-ids = <0x80 0xff>;
>>> +        /* reserved for early-stage bootloader */
>>> +        status = "reserved";
>>> +    };
>>>   };
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi 
>>> b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>> index e2c01328eb298..9d6266d6ddb82 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>> @@ -96,6 +96,7 @@ cbass_main: bus@f0000 {
>>>                <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* 
>>> USB1 DWC3 Core window */
>>>                <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* 
>>> SA3UL */
>>> [..]

Re: [PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

[Padhi, Beleswar]

On 1/15/2026 11:16 AM, Kumar, Udit wrote:
>
> On 1/15/2026 11:11 AM, Padhi, Beleswar wrote:
>> Hi Udit,
>>
>> On 1/15/2026 10:06 AM, Kumar, Udit wrote:
>>> Hi Beleswar,
>>>
>>> On 1/14/2026 11:05 PM, Beleswar Padhi wrote:
>>>> The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
>>>> core in the MAIN Voltage Domain which could be used to run secure
>>>> services like Authentication. Add Device Tree Node definitions for the
>>>> HSM core in the respective SoC common main dtsi file.
>>>>
>>>> The HSM node is reserved to be loaded and booted by the early-stage
>>>> bootloader. The firmware-name property is defined at the SoC level
>>>> since the HSM is not a general-purpose remote core and boards are
>>>> unlikely to use separate firmware. If needed in exceptional cases,
>>>> board-specific device trees can override this property.
>>>>
>>>> The corresponding reg ranges of HSM node has also been added to its
>>>> parent node's (cbass_main bus) ranges property.
>>>>
>>>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>>>> ---
>>>> v3: Changelog:
>>>> [Nishanth]:
>>>>   1. Use generic node name 'remoteproc'
>>>>   2. Use label 'hsm' instead of 'hsm_m4fss'
>>>>   3. Add a comment for separate SRAMs
>>>>   4. Update firmware-name property to match existing naming 
>>>> conventions
>>>>   5. Change status to 'reserved' and add a commment
>>>>   6. Re-order bootph-pre-ram property before vendor properties
>>>>   7. Update commit msg adding rationale for firmware-name in SoC.dtsi
>>>>
>>>> Link to v2:
>>>> https://lore.kernel.org/all/20260106104755.948086-4-b-padhi@ti.com/
>>>>
>>>> v2: Changelog:
>>>> 1. None
>>>>
>>>> Link to v1:
>>>> https://lore.kernel.org/all/20251231165102.950644-4-b-padhi@ti.com/
>>>>
>>>>   .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 
>>>> +++++++++++++++++
>>>>   arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
>>>>   arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
>>>>   arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
>>>>   4 files changed, 24 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi 
>>>> b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>> index 3cf7c2b3ce2dd..0e1af2a69ca2e 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>> @@ -1117,4 +1117,21 @@ vpu: video-codec@30210000 {
>>>>           clocks = <&k3_clks 204 2>;
>>>>           power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
>>>>       };
>>>> +
>>>> +    hsm: remoteproc@43c00000 {
>>>> +        compatible = "ti,hsm-m4fss";
>>>> +        /* contiguous regions but instantiated separately in HW */
>>>> +        reg = <0x00 0x43c00000 0x00 0x20000>,
>>>> +              <0x00 0x43c20000 0x00 0x10000>,
>>>> +              <0x00 0x43c30000 0x00 0x10000>;
>>>> +        reg-names = "sram0_0", "sram0_1", "sram1";
>>>> +        resets = <&k3_reset 225 1>;
>>>> +        firmware-name = "am62p-hsm-m4f-fw";
>>>
>>> you don't need clock and power-domain for this ?
>>
>>
>> That info is abstracted out via ti-sci calls. ti_sci_cmd_get_device()
>> takes care of setting clocks and power domains for us.
>>
>> Same for other rprocs:
>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi#L178 
>>
>
>
> Is this specific handling for m4 core ? 


For all single cores like M4, DSP, R5F0_0/R5F0_1 etc.

> , I see other rproc got power at cluster level


We don't make any ti-sci calls for the cluster level, which is why we
need that info here in DT. Otherwise, ti-sci calls take care of the
individual cores for us. That's why R5F child cores don't have
power domain info in the DT:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi#L1521-L1535

Thanks,
Beleswar

>
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi#L1518 
>
>
>
>>
>> Thanks,
>> Beleswar
>>
>>>
>>>
>>>> +        bootph-pre-ram;
>>>> +        ti,sci = <&dmsc>;
>>>> +        ti,sci-dev-id = <225>;
>>>> +        ti,sci-proc-ids = <0x80 0xff>;
>>>> +        /* reserved for early-stage bootloader */
>>>> +        status = "reserved";
>>>> +    };
>>>>   };
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi 
>>>> b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>>> index e2c01328eb298..9d6266d6ddb82 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>>> @@ -96,6 +96,7 @@ cbass_main: bus@f0000 {
>>>>                <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, 
>>>> /* USB1 DWC3 Core window */
>>>>                <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, 
>>>> /* SA3UL */
>>>> [..]

Re: [PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node

[Kumar, Udit]

On 1/15/2026 11:23 AM, Padhi, Beleswar wrote:
>
> On 1/15/2026 11:16 AM, Kumar, Udit wrote:
>>
>> On 1/15/2026 11:11 AM, Padhi, Beleswar wrote:
>>> Hi Udit,
>>>
>>> On 1/15/2026 10:06 AM, Kumar, Udit wrote:
>>>> Hi Beleswar,
>>>>
>>>> On 1/14/2026 11:05 PM, Beleswar Padhi wrote:
>>>>> The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
>>>>> core in the MAIN Voltage Domain which could be used to run secure
>>>>> services like Authentication. Add Device Tree Node definitions for 
>>>>> the
>>>>> HSM core in the respective SoC common main dtsi file.
>>>>>
>>>>> The HSM node is reserved to be loaded and booted by the early-stage
>>>>> bootloader. The firmware-name property is defined at the SoC level
>>>>> since the HSM is not a general-purpose remote core and boards are
>>>>> unlikely to use separate firmware. If needed in exceptional cases,
>>>>> board-specific device trees can override this property.
>>>>>
>>>>> The corresponding reg ranges of HSM node has also been added to its
>>>>> parent node's (cbass_main bus) ranges property.
>>>>>
>>>>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>>>>> ---
>>>>> v3: Changelog:
>>>>> [Nishanth]:
>>>>>   1. Use generic node name 'remoteproc'
>>>>>   2. Use label 'hsm' instead of 'hsm_m4fss'
>>>>>   3. Add a comment for separate SRAMs
>>>>>   4. Update firmware-name property to match existing naming 
>>>>> conventions
>>>>>   5. Change status to 'reserved' and add a commment
>>>>>   6. Re-order bootph-pre-ram property before vendor properties
>>>>>   7. Update commit msg adding rationale for firmware-name in SoC.dtsi
>>>>>
>>>>> Link to v2:
>>>>> https://lore.kernel.org/all/20260106104755.948086-4-b-padhi@ti.com/
>>>>>
>>>>> v2: Changelog:
>>>>> 1. None
>>>>>
>>>>> Link to v1:
>>>>> https://lore.kernel.org/all/20251231165102.950644-4-b-padhi@ti.com/
>>>>>
>>>>>   .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 17 
>>>>> +++++++++++++++++
>>>>>   arch/arm64/boot/dts/ti/k3-am62p.dtsi            |  1 +
>>>>>   arch/arm64/boot/dts/ti/k3-j722s-main.dtsi       |  5 +++++
>>>>>   arch/arm64/boot/dts/ti/k3-j722s.dtsi            |  1 +
>>>>>   4 files changed, 24 insertions(+)
>>>>>
>>>>> diff --git 
>>>>> a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi 
>>>>> b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>> index 3cf7c2b3ce2dd..0e1af2a69ca2e 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>> @@ -1117,4 +1117,21 @@ vpu: video-codec@30210000 {
>>>>>           clocks = <&k3_clks 204 2>;
>>>>>           power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
>>>>>       };
>>>>> +
>>>>> +    hsm: remoteproc@43c00000 {
>>>>> +        compatible = "ti,hsm-m4fss";
>>>>> +        /* contiguous regions but instantiated separately in HW */
>>>>> +        reg = <0x00 0x43c00000 0x00 0x20000>,
>>>>> +              <0x00 0x43c20000 0x00 0x10000>,
>>>>> +              <0x00 0x43c30000 0x00 0x10000>;
>>>>> +        reg-names = "sram0_0", "sram0_1", "sram1";
>>>>> +        resets = <&k3_reset 225 1>;
>>>>> +        firmware-name = "am62p-hsm-m4f-fw";
>>>>
>>>> you don't need clock and power-domain for this ?
>>>
>>>
>>> That info is abstracted out via ti-sci calls. ti_sci_cmd_get_device()
>>> takes care of setting clocks and power domains for us.
>>>
>>> Same for other rprocs:
>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi#L178 
>>>
>>
>>
>> Is this specific handling for m4 core ? 
>
>
> For all single cores like M4, DSP, R5F0_0/R5F0_1 etc.

Ok


>
>> , I see other rproc got power at cluster level
>
>
> We don't make any ti-sci calls for the cluster level, which is why we
> need that info here in DT. Otherwise, ti-sci calls take care of the
> individual cores for us. That's why R5F child cores don't have
> power domain info in the DT:
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi#L1521-L1535 
>

R5 cores are inside cluster , it is be better to handle core and cluster 
in same way.

But this patch is not related to R5.

So

Reviewed-by: Udit Kumar <u-kumar1@ti.com>


>
> Thanks,
> Beleswar
>
>>
>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi#L1518 
>>
>>
>>
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>>
>>>>
>>>>> +        bootph-pre-ram;
>>>>> +        ti,sci = <&dmsc>;
>>>>> +        ti,sci-dev-id = <225>;
>>>>> +        ti,sci-proc-ids = <0x80 0xff>;
>>>>> +        /* reserved for early-stage bootloader */
>>>>> +        status = "reserved";
>>>>> +    };
>>>>>   };
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi 
>>>>> b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>>>> index e2c01328eb298..9d6266d6ddb82 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
>>>>> @@ -96,6 +96,7 @@ cbass_main: bus@f0000 {
>>>>>                <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, 
>>>>> /* USB1 DWC3 Core window */
>>>>>                <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, 
>>>>> /* SA3UL */
>>>>> [..]

Re: [PATCH v3 0/2] Add TI K3 HSM M4F nodes in device-tree

[Bryan Brattlof]

On January 14, 2026 thus sayeth Beleswar Padhi:
> Some of the TI K3 family of SoCs (like J721S2, J784S4, J722S) have a
> HSM (High Security Module) M4F core in the Wakeup Voltage Domain which
> could be used to run secure services like Authentication. Add the device
> device-tree node definitions for this HSM M4F core. The bindings for
> this has already been merged[0].
> 
> The HSM M4 core is typically booted early from the bootloader and the
> driver for the same is posted in U-Boot mailing list[1].
> 

Nice! Amazing job cleaning up the remote core drivers Beleswar! And 
defining them so well in DT for us.  For the series

Reviewed-by: Bryan Brattlof <bb@ti.com>

~Bryan

Re: [PATCH v3 0/2] Add TI K3 HSM M4F nodes in device-tree

[Nishanth Menon]

Hi Beleswar Padhi,

On Wed, 14 Jan 2026 23:05:49 +0530, Beleswar Padhi wrote:
> Some of the TI K3 family of SoCs (like J721S2, J784S4, J722S) have a
> HSM (High Security Module) M4F core in the Wakeup Voltage Domain which
> could be used to run secure services like Authentication. Add the device
> device-tree node definitions for this HSM M4F core. The bindings for
> this has already been merged[0].
> 
> The HSM M4 core is typically booted early from the bootloader and the
> driver for the same is posted in U-Boot mailing list[1].
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].

Thank you!

[1/2] arm64: dts: ti: k3-{j784s4-j742s2/j721s2}-mcu-wakeup: Add HSM M4F node
      commit: 474530ef050b77482365de8c595b491f1d4ba683
[2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node
      commit: ac838e45b46f33ae8ab7195892f4dcf1143a161b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
https://ti.com/opensource