Reset Source in U-Boot of the Verdin AM62

Technical Support
, ,
1

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

2

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?

:+1: :-1:

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

3

Hello @RemcoSeascape,

I will look into this topic and check what may be causing this behavior.

Best Regards,
Bruno

4

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

6

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?

7

Hello @rudhi.tx ,

this topic is interesting for me, since we are executing some HW tests on our carrier board that mounts the same SoM (Verdin AM62 1.2) and we also need to read the real reset cause, to be sure if it was determined by software or hardware power fault.

Looking at the PMIC TPS65219 datahseet, there is the register POWER_UP_STATUS_REG Register (Offset = 35h) that may help on detecting if we are coming from a hot or cold reset.

But basing on your sentence:

the PMIC on our Verdin AM62 module is configured to do a cold reset whenever a soft/hard reset happens

I’m worried if this operation will always make to report the cold reset reason.

Are my assumptions true?

Experimentally, I tried to read the PMIC register in the U-Boot console after sending a “reboot” command from linux console:

Verdin AM62 # i2c md 0x30 0x35 1
0035: 38 8

0x38, basing on datasheet (TPS65219 Power Management IC (PMIC) with 3 BUCKs and 4 LDOs for Industrial Applications datasheet (Rev. C)) Table 7-62 corresponds to status ACTIVE and COLD RESET.

So even this solution seems not feasible.

Any comments / suggestions?

Thanks for the support,

Andrea

8

Hello @dm-andreapedica,

Your conclusions are correct.
As stated by Rudhi, the power down logic of the SoM will always lead to the PMIC recognizing a cold reset.

A possible alternative would be to write a byte to an EEPROM before a soft restart or shutdown in a system service.
Resetting it at system boot.
This would need to be developed, but should not be too complicated.

If you want to further discuss this topic, please open another thread here on the community referencing this existing one.

Best Regards,
Bruno

1 Like