Hello,
For our customer, we need to check the starting conditions of the AM62 module before booting the OS.
U-Boot is the perfect place to check for this. By reading the CFG0_RST_SRC registers (register 0x04318178, or its shadow 0x43018178) as described in section 14.2.1.1.1.475.1 of the AM625x manual.
According to this thread on the TI forum, the AM625x is capable of keeping track of its reset cause. https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1310226/am625-how-do-i-determine-what-caused-a-reset
However, in the newer version of U-Boot ‘U-Boot 2023.04-28144’ for the AM62 module, the registers 0x04318178 and 0x43018178 always read zero.
What is the reason why the reset source registers (0x04318178 and 0x43018178) read as zero?
Regards,
Remco van den Heuvel
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Remco van den Heuvel,
The issue you’re encountering with the CFG0_RST_SRC registers (0x04318178 and 0x43018178) reading as zero in U-Boot for the AM62 module could be due to several factors. Here are some potential reasons and troubleshooting steps:
-
U-Boot Version Compatibility: Ensure that the U-Boot version you’re using is fully compatible with the AM62 module. Although you mentioned using U-Boot 2023.04-28144, it’s crucial to verify that this version supports all features of the AM62, including reset source tracking.
-
Register Access Timing: The timing of when you’re trying to read the registers in U-Boot could affect the results. It’s possible that the registers are cleared or not yet populated with the reset source information at the point in the boot process when you’re attempting to read them. Consider checking these registers at different points in the U-Boot initialization sequence to see if the timing of the read operation matters.
-
Hardware Initialization: Some SoCs require specific initialization sequences to properly track and report reset sources. Review the AM62 module and SoC documentation to ensure that all necessary initialization steps are being performed in U-Boot before attempting to read the reset source registers.
-
Documentation and Errata: Check for any errata or documentation updates related to the AM62 module and the specific U-Boot version you’re using. It’s possible that there are known issues or revisions to the method for reading reset sources on this module.
-
U-Boot Configuration: Review your U-Boot configuration to ensure that it’s correctly set up to interact with the AM62 module’s hardware, including any specific configurations needed to access system registers.
-
Silicon Revision Differences: Verify the silicon revision of your AM62 module. In some cases, differences between silicon revisions can affect how certain features work, including reset source tracking.
If after going through these steps the registers still read as zero, it might indicate a deeper issue with the U-Boot implementation or a potential hardware limitation. In such cases, further investigation with a focus on U-Boot source code modifications or consulting with the SoC manufacturer’s technical resources might be necessary.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Reset State of the i.MX 8/8X SoC Pins | Toradex Developer Center.
Hello @RemcoSeascape,
I will look into this topic and check what may be causing this behavior.
Best Regards,
Bruno
Hello @RemcoSeascape,
I can confirm that I see the same value for registers 0x43018178
and 0x04318178
.
It is still unclear why this is the case, but we will investigate this topic.
Best Regards,
Bruno
Hello @RemcoSeascape,
Thanks for your patience! I had a chance to take this topic up internally and discuss it. Currently, the PMIC on our Verdin AM62 module is configured to do a cold reset whenever a soft/hard reset happens. This means it restarts the system by cycling the power and thereby clearing the register values. This is why the reset source registers always read as zero.
May I ask why you are trying to read the reset source registers? Is this a hard requirement for your use case?