1. Patchew
  2. linux
  3. View series

[PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node

Michael Walle posted 1 patch 9 months, 1 week ago
There is a newer version of this series
arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
[PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Michael Walle 9 months, 1 week ago 
Add the node for the random number generator inside the crypto module.

Signed-off-by: Michael Walle <mwalle@kernel.org>
---
This was tested on a J722S/AM67A. Also, according to the TRM this is the
MCU instance of the SA3UL. But it's defined in -main.dtsi. Is this
correct?
---
 arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 8 ++++++++
 1 file changed, 8 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 6e3beb5c2e01..e868e006318e 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
@@ -227,9 +227,17 @@ crypto: crypto@40900000 {
 		reg = <0x00 0x40900000 0x00 0x1200>;
 		#address-cells = <2>;
 		#size-cells = <2>;
+		ranges = <0x00 0x40900000 0x00 0x40900000 0x00 0x30000>;
+
 		dmas = <&main_pktdma 0xf501 0>, <&main_pktdma 0x7506 0>,
 		       <&main_pktdma 0x7507 0>;
 		dma-names = "tx", "rx1", "rx2";
+
+		rng: rng@40910000 {
+			compatible = "inside-secure,safexcel-eip76";
+			reg = <0x00 0x40910000 0x0 0x7d>;
+			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+		};
 	};
 
 	secure_proxy_sa3: mailbox@43600000 {
-- 
2.39.5
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Kumar, Udit 8 months, 3 weeks ago 
Hello Michael

Thanks for patch

On 3/13/2025 8:11 PM, Michael Walle wrote:
> Add the node for the random number generator inside the crypto module.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> This was tested on a J722S/AM67A. Also, according to the TRM this is the

Could you re-confirm please , after adding this node.  you selected trng 
offered by Linux


> MCU instance of the SA3UL. But it's defined in -main.dtsi. Is this
> correct?

Yes this is correct,

please refer

https://www.ti.com/lit/zip/sprujb3  SPRUJB3A.pdf

table 2.1 Main Memory map, this node falls under main domain

> ---
>   arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 8 ++++++++
>   1 file changed, 8 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 6e3beb5c2e01..e868e006318e 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
> @@ -227,9 +227,17 @@ crypto: crypto@40900000 {
>   		reg = <0x00 0x40900000 0x00 0x1200>;
>   		#address-cells = <2>;
>   		#size-cells = <2>;
> +		ranges = <0x00 0x40900000 0x00 0x40900000 0x00 0x30000>;
> +
>   		dmas = <&main_pktdma 0xf501 0>, <&main_pktdma 0x7506 0>,
>   		       <&main_pktdma 0x7507 0>;
>   		dma-names = "tx", "rx1", "rx2";
> +
> +		rng: rng@40910000 {
> +			compatible = "inside-secure,safexcel-eip76";
> +			reg = <0x00 0x40910000 0x0 0x7d>;
> +			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;

For completeness , this is ok to add this node but should be kept disabled

similar to

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




> +		};
>   	};
>   
>   	secure_proxy_sa3: mailbox@43600000 {
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Michael Walle 8 months, 3 weeks ago 
Hi Udit,

> > Add the node for the random number generator inside the crypto module.
> >
> > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > ---
> > This was tested on a J722S/AM67A. Also, according to the TRM this is the
>
> Could you re-confirm please , after adding this node.  you selected trng 
> offered by Linux

# cat /sys/devices/virtual/misc/hw_random/rng_current
40910000.rng
# cat /sys/devices/virtual/misc/hw_random/rng_available
40910000.rng
# dd if=/dev/hwrng bs=16 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  92 f5 44 09 fd 86 6b a2  39 d6 ad f3 e6 ec 03 4a  |..D...k.9......J|
00000010
# dd if=/dev/hwrng bs=16 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  a3 73 da d2 5b 94 83 2a  75 11 ca b3 99 d3 87 88  |.s..[..*u.......|
00000010

> > MCU instance of the SA3UL. But it's defined in -main.dtsi. Is this
> > correct?
>
> Yes this is correct,
>
> please refer
>
> https://www.ti.com/lit/zip/sprujb3  SPRUJB3A.pdf
>
> table 2.1 Main Memory map, this node falls under main domain

Ok. Not sure, how I came to the conclusion that this is an MCU
instance.

> > ---
> >   arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 8 ++++++++
> >   1 file changed, 8 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 6e3beb5c2e01..e868e006318e 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
> > @@ -227,9 +227,17 @@ crypto: crypto@40900000 {
> >   		reg = <0x00 0x40900000 0x00 0x1200>;
> >   		#address-cells = <2>;
> >   		#size-cells = <2>;
> > +		ranges = <0x00 0x40900000 0x00 0x40900000 0x00 0x30000>;
> > +
> >   		dmas = <&main_pktdma 0xf501 0>, <&main_pktdma 0x7506 0>,
> >   		       <&main_pktdma 0x7507 0>;
> >   		dma-names = "tx", "rx1", "rx2";
> > +
> > +		rng: rng@40910000 {
> > +			compatible = "inside-secure,safexcel-eip76";
> > +			reg = <0x00 0x40910000 0x0 0x7d>;
> > +			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
>
> For completeness , this is ok to add this node but should be kept disabled

Shouldn't it be "reserved" then, see [1].

> similar to
>
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662 

j784s4, j721e and j721s2 have them enabled. What is the rule here?

You also disable the hwrng in optee in your evm according to [2]:
CFG_WITH_SOFTWARE_PRNG=y

-michael

[1] https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html?highlight=reservered#status
[2] https://docs.u-boot.org/en/latest/board/ti/j722s_evm.html
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Kumar, Udit 8 months, 3 weeks ago 
Thanks Michael,

On 3/31/2025 4:28 PM, Michael Walle wrote:
> Hi Udit,
>
>>> Add the node for the random number generator inside the crypto module.
>>>
>>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>>> ---
>>> This was tested on a J722S/AM67A. Also, according to the TRM this is the
>> Could you re-confirm please , after adding this node.  you selected trng
>> offered by Linux
> # cat /sys/devices/virtual/misc/hw_random/rng_current
> 40910000.rng
> # cat /sys/devices/virtual/misc/hw_random/rng_available
> 40910000.rng
> # dd if=/dev/hwrng bs=16 count=1 | hexdump -C
> 1+0 records in
> 1+0 records out
> 00000000  92 f5 44 09 fd 86 6b a2  39 d6 ad f3 e6 ec 03 4a  |..D...k.9......J|
> 00000010
> # dd if=/dev/hwrng bs=16 count=1 | hexdump -C
> 1+0 records in
> 1+0 records out
> 00000000  a3 73 da d2 5b 94 83 2a  75 11 ca b3 99 d3 87 88  |.s..[..*u.......|
> 00000010

Thanks for checking this


>
>>> MCU instance of the SA3UL. But it's defined in -main.dtsi. Is this
>>> correct?
>> Yes this is correct,
>>
>> please refer
>>
>> https://www.ti.com/lit/zip/sprujb3  SPRUJB3A.pdf
>>
>> table 2.1 Main Memory map, this node falls under main domain
> Ok. Not sure, how I came to the conclusion that this is an MCU
> instance.
>
>>> ---
>>>    arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 8 ++++++++
>>>    1 file changed, 8 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 6e3beb5c2e01..e868e006318e 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>> [..]
>> For completeness , this is ok to add this node but should be kept disabled
> Shouldn't it be "reserved" then, see [1].

yes, should be reserved.

With marking status as reserved.

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


>
>> similar to
>>
>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
> j784s4, j721e and j721s2 have them enabled. What is the rule here?

J784s4, j721e and j721s2 SOCs has two TRNG blocks,

example for j721e, one is used by kernel [0] and another by optee [1].


>
> You also disable the hwrng in optee in your evm according to [2]:
> CFG_WITH_SOFTWARE_PRNG=y

We are planning to use this hardware block by secure firmware.

Therefore request not to use by optee as well


>
> -michael

[0] 
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi#L531 


[1] 
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-k3/platform_config.h#L67 



> [1] https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html?highlight=reservered#status
> [2] https://docs.u-boot.org/en/latest/board/ti/j722s_evm.html
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Michael Walle 8 months, 3 weeks ago 
Hi Udit,

> >>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> >>> [..]
> >> For completeness , this is ok to add this node but should be kept disabled
> > Shouldn't it be "reserved" then, see [1].
>
> yes, should be reserved.
>
> With marking status as reserved.
>
> Please use Reviewed-by: Udit Kumar <u-kumar1@ti.com>

Thanks.

> >> similar to
> >>
> >> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
> > j784s4, j721e and j721s2 have them enabled. What is the rule here?
>
> J784s4, j721e and j721s2 SOCs has two TRNG blocks,
>
> example for j721e, one is used by kernel [0] and another by optee [1].
>
>
> >
> > You also disable the hwrng in optee in your evm according to [2]:
> > CFG_WITH_SOFTWARE_PRNG=y
>
> We are planning to use this hardware block by secure firmware.
>
> Therefore request not to use by optee as well

How will you be able to access the RNG from linux and u-boot? I'm
asking because I'll need it in u-boot for the lwip stack and the
HTTPS protocol.

-michael
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Kumar, Udit 8 months, 3 weeks ago 
Hi Michael

On 4/1/2025 11:50 AM, Michael Walle wrote:
> Hi Udit,
>
>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>> [..]
>>>> For completeness , this is ok to add this node but should be kept disabled
>>> Shouldn't it be "reserved" then, see [1].
>> yes, should be reserved.
>>
>> With marking status as reserved.
>>
>> Please use Reviewed-by: Udit Kumar <u-kumar1@ti.com>
> Thanks.
>
>>>> similar to
>>>>
>>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
>>> j784s4, j721e and j721s2 have them enabled. What is the rule here?
>> J784s4, j721e and j721s2 SOCs has two TRNG blocks,
>>
>> example for j721e, one is used by kernel [0] and another by optee [1].
>>
>>
>>> You also disable the hwrng in optee in your evm according to [2]:
>>> CFG_WITH_SOFTWARE_PRNG=y
>> We are planning to use this hardware block by secure firmware.
>>
>> Therefore request not to use by optee as well
> How will you be able to access the RNG from linux and u-boot? I'm
> asking because I'll need it in u-boot for the lwip stack and the
> HTTPS protocol.

For now,  If you need TRNG then I can suggest to use optee TRNG (ie 
build optee with HW TRNG).


>
> -michael
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Michael Walle 8 months, 3 weeks ago 
Hi Udit,

>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>>> [..]
>>>>> For completeness , this is ok to add this node but should be kept 
>>>>> disabled
>>>> Shouldn't it be "reserved" then, see [1].
>>> yes, should be reserved.
>>> 
>>> With marking status as reserved.
>>> 
>>> Please use Reviewed-by: Udit Kumar <u-kumar1@ti.com>
>> Thanks.
>> 
>>>>> similar to
>>>>> 
>>>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
>>>> j784s4, j721e and j721s2 have them enabled. What is the rule here?
>>> J784s4, j721e and j721s2 SOCs has two TRNG blocks,
>>> 
>>> example for j721e, one is used by kernel [0] and another by optee 
>>> [1].
>>> 
>>> 
>>>> You also disable the hwrng in optee in your evm according to [2]:
>>>> CFG_WITH_SOFTWARE_PRNG=y
>>> We are planning to use this hardware block by secure firmware.
>>> 
>>> Therefore request not to use by optee as well
>> How will you be able to access the RNG from linux and u-boot? I'm
>> asking because I'll need it in u-boot for the lwip stack and the
>> HTTPS protocol.
> 
> For now,  If you need TRNG then I can suggest to use optee TRNG (ie 
> build
> optee with HW TRNG).

I'll be using an uboot TRNG driver. But how will that work in
the future if the RNG is used by the secure firmware?

-michael
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Manorit Chawdhry 8 months, 2 weeks ago 
Hi Michael,

On 13:09-20250401, Michael Walle wrote:
> Hi Udit,
> 
> > > > > > > --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> > > > > > > [..]
> > > > > > For completeness , this is ok to add this node but
> > > > > > should be kept disabled
> > > > > Shouldn't it be "reserved" then, see [1].
> > > > yes, should be reserved.
> > > > 
> > > > With marking status as reserved.
> > > > 
> > > > Please use Reviewed-by: Udit Kumar <u-kumar1@ti.com>
> > > Thanks.
> > > 
> > > > > > similar to
> > > > > > 
> > > > > > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
> > > > > j784s4, j721e and j721s2 have them enabled. What is the rule here?
> > > > J784s4, j721e and j721s2 SOCs has two TRNG blocks,
> > > > 
> > > > example for j721e, one is used by kernel [0] and another by
> > > > optee [1].
> > > > 
> > > > 
> > > > > You also disable the hwrng in optee in your evm according to [2]:
> > > > > CFG_WITH_SOFTWARE_PRNG=y
> > > > We are planning to use this hardware block by secure firmware.
> > > > 
> > > > Therefore request not to use by optee as well
> > > How will you be able to access the RNG from linux and u-boot? I'm
> > > asking because I'll need it in u-boot for the lwip stack and the
> > > HTTPS protocol.
> > 
> > For now,  If you need TRNG then I can suggest to use optee TRNG (ie
> > build
> > optee with HW TRNG).
> 
> I'll be using an uboot TRNG driver. But how will that work in
> the future if the RNG is used by the secure firmware?

Wondering if this would be of interest to you [0]. I think since this
device only has one TRNG, there has to be a master around and we can
mitigate that from OP-TEE as of now, incase anything changes in future
then the communication channel between OP-TEE and the secure firmware
can be established but currently it's still at work. I think the best
way to go forward is to get the numbers from OP-TEE atm IMHO.

[0]: https://github.com/u-boot/u-boot/blob/master/drivers/rng/optee_rng.c

Regards,
Manorit

> 
> -michael
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Michael Walle 8 months, 1 week ago 
Hi Manorit,

> > > > > > > > --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> > > > > > > > [..]
> > > > > > > For completeness , this is ok to add this node but
> > > > > > > should be kept disabled
> > > > > > Shouldn't it be "reserved" then, see [1].
> > > > > yes, should be reserved.
> > > > > 
> > > > > With marking status as reserved.
> > > > > 
> > > > > Please use Reviewed-by: Udit Kumar <u-kumar1@ti.com>
> > > > Thanks.
> > > > 
> > > > > > > similar to
> > > > > > > 
> > > > > > > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
> > > > > > j784s4, j721e and j721s2 have them enabled. What is the rule here?
> > > > > J784s4, j721e and j721s2 SOCs has two TRNG blocks,
> > > > > 
> > > > > example for j721e, one is used by kernel [0] and another by
> > > > > optee [1].
> > > > > 
> > > > > 
> > > > > > You also disable the hwrng in optee in your evm according to [2]:
> > > > > > CFG_WITH_SOFTWARE_PRNG=y
> > > > > We are planning to use this hardware block by secure firmware.
> > > > > 
> > > > > Therefore request not to use by optee as well
> > > > How will you be able to access the RNG from linux and u-boot? I'm
> > > > asking because I'll need it in u-boot for the lwip stack and the
> > > > HTTPS protocol.
> > > 
> > > For now,  If you need TRNG then I can suggest to use optee TRNG (ie
> > > build
> > > optee with HW TRNG).
> > 
> > I'll be using an uboot TRNG driver. But how will that work in
> > the future if the RNG is used by the secure firmware?
>
> Wondering if this would be of interest to you [0]. I think since this
> device only has one TRNG, there has to be a master around and we can
> mitigate that from OP-TEE as of now, incase anything changes in future
> then the communication channel between OP-TEE and the secure firmware
> can be established but currently it's still at work. I think the best
> way to go forward is to get the numbers from OP-TEE atm IMHO.

I saw the optee rng. But as of now, the instructions are to use a
software PRNG for optee. Thus, if someone compiles optee by
following the instructions, it's unlikely to work.

Would TI willing to agree to change the building docs and enable the
TRNG in optee and then work on moving the TRNG into the secure
firmware and build a channel between optee and that firmware? Right
now, the TRNG seems pretty useless as we cannot use it neither from
u-boot or linux (and being future proof).

-michael
Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
Posted by Kumar, Udit 8 months, 1 week ago 
Hi Michael,

On 4/10/2025 4:56 PM, Michael Walle wrote:
> Hi Manorit,
>
>>>>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>>>>>> [..]
>>>>>>>> For completeness , this is ok to add this node but
>>>>>>>> should be kept disabled
>>>>>>> Shouldn't it be "reserved" then, see [1].
>>>>>> yes, should be reserved.
>>>>>>
>>>>>> With marking status as reserved.
>>>>>>
>>>>>> Please use Reviewed-by: Udit Kumar <u-kumar1@ti.com>
>>>>> Thanks.
>>>>>
>>>>>>>> similar to
>>>>>>>>
>>>>>>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
>>>>>>> j784s4, j721e and j721s2 have them enabled. What is the rule here?
>>>>>> J784s4, j721e and j721s2 SOCs has two TRNG blocks,
>>>>>>
>>>>>> example for j721e, one is used by kernel [0] and another by
>>>>>> optee [1].
>>>>>>
>>>>>>
>>>>>>> You also disable the hwrng in optee in your evm according to [2]:
>>>>>>> CFG_WITH_SOFTWARE_PRNG=y
>>>>>> We are planning to use this hardware block by secure firmware.
>>>>>>
>>>>>> Therefore request not to use by optee as well
>>>>> How will you be able to access the RNG from linux and u-boot? I'm
>>>>> asking because I'll need it in u-boot for the lwip stack and the
>>>>> HTTPS protocol.
>>>> For now,  If you need TRNG then I can suggest to use optee TRNG (ie
>>>> build
>>>> optee with HW TRNG).
>>> I'll be using an uboot TRNG driver. But how will that work in
>>> the future if the RNG is used by the secure firmware?
>> Wondering if this would be of interest to you [0]. I think since this
>> device only has one TRNG, there has to be a master around and we can
>> mitigate that from OP-TEE as of now, incase anything changes in future
>> then the communication channel between OP-TEE and the secure firmware
>> can be established but currently it's still at work. I think the best
>> way to go forward is to get the numbers from OP-TEE atm IMHO.
> I saw the optee rng. But as of now, the instructions are to use a
> software PRNG for optee. Thus, if someone compiles optee by
> following the instructions, it's unlikely to work.
>
> Would TI willing to agree to change the building docs and enable the
> TRNG in optee and then work on moving the TRNG into the secure
> firmware and build a channel between optee and that firmware? Right
> now, the TRNG seems pretty useless as we cannot use it neither from
> u-boot or linux (and being future proof).

Thanks for note,

I agree to update doc two times

1) with current state ie use optee based trng

2) When fw based trng is available,


>
> -michael

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.