cancel
Showing results for 
Search instead for 
Did you mean: 

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

SLivi.1
Associate II

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

 

 

4 REPLIES 4
dkal
Associate III

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

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
Associate III

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

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.