2417258_en-US

[#1]

Known issues with i.MX9 ELE

According to this discussion from 2025 there was an issue on i.MX 9 when both the secure and non-secure world were using their MUs at the same time to communicate with the ELE. In the discussion it was said that a fix was planned for Q3 2025. Has this fix been released? Is the fix implemented in the ELE firmware or did it need modifications to the Cortex A55 code? If it was implemented in the ELE firmware, which firmware version was the first one to contain the fix?

According to the i.MX Linux Release Notes (RN00210) there is a known ELE problem with voltage changes. What is the impact of this problem? Will the voltage glitch detector trigger even if ELE_VOLT_CHANGE_START_REQ was sent? Or will the voltage change impact the random number generator? RN00210 mentions the problem only for i.MX 93. Is the very similar i.MX 91 affected as well?

Background: We need reliable access to the ELE from within OP-TEE and can't trust Linux to behave nicely.

SecurityRe: Known issues with i.MX9 ELE

Hello,

Are you looking for an specific i.MX9?
This impact different processors in the familly, for example on the i.MX91/93 OPTEE uses a dedicated Trusted MU for the communication so this processors are no impacted.

Regarding ELE voltage change issue, the issue is a command-sequencing problem, not corruption of random data. After ELE_VOLT_CHANGE_START_REQ is accepted, ELE temporarily disables its voltage-glitch sensors and expects ELE_VOLT_CHANGE_FINISH_REQ immediately. A concurrent HRNG request can therefore fail or hang; if the finish request is delayed beyond the timeout, ELE may abort the sequence and reset the SoC.

And finally no, i.MX 91 normally switches only between nominal and low-drive voltage, with an approximately 50 mV difference that is not expected to trigger GDET, so it is not considered affected by this same issue.

Best regards/Saludos,
Aldo.

Re: Known issues with i.MX9 ELE

The discussion I linked in my initial question sounds like there were problems with concurrent ELE requests although the secure world has its own MU. To quote from the discussion:

>>>>>> I'm aware that the
>>>>>> i.MX93 has two MUs one for the secure and one for the non-secure
>>>>>> world. But I'm really concerned about the fact that both MUs can't
>>>>>> be used at the same time from both world:
>>>>>
>>>>> Yes, you are correct.
>>>>>
>>>>> Fix is still work in progress.

Marco Felsch linked to this comment from an NXP engineer on Github:

Problem comes when doing simultaneous request to ELE from Kernel and OP-TEE not specific to RNG, and we are working on the solution, which will be available soon.

So, has this solution been made available?

Resetting the SoC when the non-secure world abuses ELE_VOLT_CHANGE_START_REQ to stop random number generation in the secure world sounds acceptable.