RNG1 probe error: Configuration incorrectly allows both A7S and A7NS to be selected simultaneously

[SLivi.1]

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

 

 

[dkal]

Did you ever figure this out? I have the same issue.

[SLivi.1]

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.

[dkal]

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.

[dkal]

Thanks for replying so quickly. I guess you checked the "activated" box too?