Unexpected CSU-Reset on i.MX 93

cstoidner

Hello,

we are using the i.MX93, mounted on our own custom specific base-board. Everything is working fine, but on some boards we have unexpected reboots, as described below:

   - when powering up the board, everything boots (u-boot -> kernel -> systemd)
   - shortly before the boot process is finished (some milliseconds before the linux user-login appears),
      the system reboots
   - the reboot occurs directly without any delay (seems not to be the watchdog)
   - during this unexpected reboot the u-boot shows "Reset cause: CSU (0x200)" and continues
   - after u-boot the kernel and systemd boot successfully and the system is running fine

That unexpected reboot happens exactly once after exactly each power-up.
After that unexpected reboot the system seems to be healed and works fine and stable.
Also a software reboot ("reboot" command on the linux bash) works as expected.

As I can see in the i.MX 93 reference manual, CSU means "Central Security Unit". And "Reset cause: CSU" shown by u-boot comes from the SoC's SRSR register. And for the SRSR register and it's CSU-bit the reference manual states: "Indicates whether the reset was the result of the csu_reset_b input.".

However, I cannot find more information about that "csu_reset_b input".

So my question is: What can lead to that kind of reset? What is that "csu_reset_b input"?

Just for note: We are using NXP BSP "Linux 6.1.55_2.2.0".

Thanks in advance for any help or information!

Regards,
Christoph

AldoG

Hello,

It is as specified in the reference manual as you have already read, csu_reset_b asserts when security violation happens.

It is named as an input but it just a way to say that it is triggered internally by a flag that it turns on when a security violation happens. Also, please note that CSU_TRIG_MODE=1, then the System resets once, even if the reset source remains asserted.

Best regards/Saludos,
Aldo.

cstoidner

Hi Aldo,

thanks for your fast response!

That "CSU_TRIG_MODE=1" explains the behavior we see.

However it is not clear to me what kind of "security violation" could lead to the "csu_reset_b". I mean, for usual software violations (e.g. accessing illegal memory regions) I expect an exception on kernel-level that kills just the according process. Or similar illegal access inside the kernel code would lead to a kernel panic.

Do you have some more hints or Information to make us able to identify what the reason for the "security violation" might be?

Thanks and regards,

Christoph

AldoG

Hello,

This violations are handled usually by the secure system, i.e. ELE owned TRDCs are protected and owned by ELE and any access to them will trigger security violation.

Please refer to the security reference manual.

Best regards/Saludos,
Aldo.