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

["Kumar, Udit" <u-kumar1@ti.com>]

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