1. Patchew
  2. linux
  3. [PATCH v3 0/2] Add TI K3 HSM M4F nodes in device-tree
  4. View patch

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

Beleswar Padhi posted 2 patches 3 weeks, 5 days ago
[PATCH v3 2/2] arm64: dts: ti: k3-am62p-j722s-common-main: Add HSM M4F node
Posted by Beleswar Padhi 3 weeks, 5 days ago 
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
Posted by Kumar, Udit 3 weeks, 4 days ago 
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
Posted by Padhi, Beleswar 3 weeks, 4 days ago 
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
Posted by Kumar, Udit 3 weeks, 4 days ago 
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
Posted by Padhi, Beleswar 3 weeks, 4 days ago 
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
Posted by Kumar, Udit 3 weeks, 4 days ago 
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 */
>>>>> [..]

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.