2023-09-06 01:27 PM - edited 2023-09-06 01:28 PM
We're using the ST v5.0 eco-system and v.6.9 of STM32CubeMX.
Per RNG internal peripheral - stm32mpu, the RNG1 peripheral should be a single choice assignment. When I click on A7S (OP-TEE), the tool warns me that it cannot be removed from the A7S context because it is required for this peripheral. But I can still select the A7NS checkbox. We had the A7NS selected from our previous ioc file (working without OP-TEE in eco-system 4.1).
This generates code that assigns the RNG1 to the A7NS in etzpc:
DECPROT(STM32MP1_ETZPC_RNG1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
and includes nodes in the u-boot and kernel dts:
&rng1{
status = "okay";
/* USER CODE BEGIN rng1 */
/* USER CODE END rng1 */
};
This resulted in errors generated when booting Linux due to both op-tee and stm32 rng drivers being probed and the op-tee driver failing:
[ 0.203070] (NULL device *): TA_CMD_GET_ENTROPY invoke err: ffff000a
[ 0.203158] optee-rng optee-ta-ab7a617c-b8e7-4d8f-8301-d09b61036b64: TA_CMD_GET_ENTROPY invoke err: ffff000a
2024-02-14 12:50 PM
Did you ever figure this out? I have the same issue.
2024-02-14 01:05 PM
As far as I remember, using the 5.0 ecosystem requires OP-TEE, and the rng1 peripheral must be assigned to A7S for op-tee.
As far as using the rng1 from user space, I don't believe we had a problem with that. My post was more for information to ST to fix the CubeMX tool to resolve this when migrating an older ioc file.
2024-02-14 01:19 PM
Thanks for replying so quickly. I guess you checked the "activated" box too?
2024-02-14 01:59 PM
Thanks, mine was generated wrong as well and now that I fixed it, I don't have that message every couple seconds which is nice.