linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
@ 2025-03-13 14:41 Michael Walle
  2025-03-28 16:12 ` Kumar, Udit
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2025-03-13 14:41 UTC (permalink / raw)
  To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: linux-arm-kernel, devicetree, linux-kernel, Michael Walle

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



^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-03-13 14:41 [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node Michael Walle
@ 2025-03-28 16:12 ` Kumar, Udit
  2025-03-31 10:58   ` Michael Walle
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar, Udit @ 2025-03-28 16:12 UTC (permalink / raw)
  To: Michael Walle, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: linux-arm-kernel, devicetree, linux-kernel, u-kumar1

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 {


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-03-28 16:12 ` Kumar, Udit
@ 2025-03-31 10:58   ` Michael Walle
  2025-03-31 17:12     ` Kumar, Udit
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2025-03-31 10:58 UTC (permalink / raw)
  To: Kumar, Udit, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: linux-arm-kernel, devicetree, linux-kernel

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

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-03-31 10:58   ` Michael Walle
@ 2025-03-31 17:12     ` Kumar, Udit
  2025-04-01  6:20       ` Michael Walle
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar, Udit @ 2025-03-31 17:12 UTC (permalink / raw)
  To: Michael Walle, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: linux-arm-kernel, devicetree, linux-kernel, u-kumar1

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-03-31 17:12     ` Kumar, Udit
@ 2025-04-01  6:20       ` Michael Walle
  2025-04-01 10:02         ` Kumar, Udit
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2025-04-01  6:20 UTC (permalink / raw)
  To: Kumar, Udit, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: linux-arm-kernel, devicetree, linux-kernel

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

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-04-01  6:20       ` Michael Walle
@ 2025-04-01 10:02         ` Kumar, Udit
  2025-04-01 11:09           ` Michael Walle
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar, Udit @ 2025-04-01 10:02 UTC (permalink / raw)
  To: Michael Walle, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, u-kumar1
  Cc: linux-arm-kernel, devicetree, linux-kernel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-04-01 10:02         ` Kumar, Udit
@ 2025-04-01 11:09           ` Michael Walle
  2025-04-09 10:33             ` Manorit Chawdhry
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2025-04-01 11:09 UTC (permalink / raw)
  To: Kumar, Udit
  Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
	linux-kernel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-04-01 11:09           ` Michael Walle
@ 2025-04-09 10:33             ` Manorit Chawdhry
  2025-04-10 11:26               ` Michael Walle
  0 siblings, 1 reply; 10+ messages in thread
From: Manorit Chawdhry @ 2025-04-09 10:33 UTC (permalink / raw)
  To: Michael Walle
  Cc: Kumar, Udit, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
	devicetree, linux-kernel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-04-09 10:33             ` Manorit Chawdhry
@ 2025-04-10 11:26               ` Michael Walle
  2025-04-10 13:20                 ` Kumar, Udit
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2025-04-10 11:26 UTC (permalink / raw)
  To: Manorit Chawdhry
  Cc: Kumar, Udit, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
	devicetree, linux-kernel

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

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node
  2025-04-10 11:26               ` Michael Walle
@ 2025-04-10 13:20                 ` Kumar, Udit
  0 siblings, 0 replies; 10+ messages in thread
From: Kumar, Udit @ 2025-04-10 13:20 UTC (permalink / raw)
  To: Michael Walle, Manorit Chawdhry
  Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
	linux-kernel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2025-04-10 13:22 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-13 14:41 [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node Michael Walle
2025-03-28 16:12 ` Kumar, Udit
2025-03-31 10:58   ` Michael Walle
2025-03-31 17:12     ` Kumar, Udit
2025-04-01  6:20       ` Michael Walle
2025-04-01 10:02         ` Kumar, Udit
2025-04-01 11:09           ` Michael Walle
2025-04-09 10:33             ` Manorit Chawdhry
2025-04-10 11:26               ` Michael Walle
2025-04-10 13:20                 ` Kumar, Udit

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).