Watchdog restart cause detection

[attila-hannibal]

Dear Siemens / Jan

We would like to have a possibility that after any kind of restart (power on restart, SW initiated restart, watchdog initiated restart, etc...) determine if the restart was caused by the watchdog or not.

Currently it seems the TI AM6548 type of SoC does not offer any register that could be used for this purpose. Even more we use this k3-rti-wdt firmware that executes a remote system-reset from FW side, that means from SoC point of view this is a kind of "user initiated reset".

In case there isn't any built-in possibility within the TI SoC we would like to extend this k3-rti-wdt firmware to set some magic value at a defined, unused RAM address before executing the system reset.
A driver later can use this dedicated RAM address to identify the restart cause:

• in case the driver reads the magic value at the address -> then the restart was initiated by watchdog
• otherwise the restart was not asked by watchdog

Thank you!

[jan-kiszka]

Thanks for the request and suggestions. I'm trying to confirm that we really have no other way get this information. If that is true, we need to think about how to define and protect the magic RAM location - and how to make it available to watchdog drivers (device tree binding?). Or if we should rather use some SRAM location.

[jan-kiszka]

Yes, forgotten: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1170166/am6548-obtaining-a-reset-reason-after-rti-wdt-watchdog-expiry/4406451#4406451

Seem we now need to think about how to make such a software interface official.

[jan-kiszka]

PS: You man not want to use email replies here if you have no control over your email footers.

[attila-hannibal]

Basically, we are open to any proposal.
What will be your preference, that is easy for you to implement it?

[jan-kiszka]

No concrete plan yet, but here are some todos IMHO:

• Should be use RAM or SRAM for the reset cause virtual register?
• Define a device tree binding for that so that both kernel and u-boot driver know where to look at
• Come up with a prototype patch for one of those two, and for this firmware (likely by defining the address at build-time)
• Discuss DT binding with the community

[attila-hannibal]

Maybe I did in a wrong way but tried to save the magic-value at an SRAM address (0x300) and the value was initialized back to 0 after the watchdog restart. The magic-value remained persistent when I used RAM address (0x87000000)

[jan-kiszka]

No, that actually fits into what a TI engineer told me: SRAM may not work as there is some self-test running during boot-up.

[jan-kiszka]

@attila-hannibal Did you make any steps in defining an official interface meanwhile?

[attila-hannibal]

Dear @jan-kiszka !

No, unfortunately not.
To be honest at the moment we are fine using hardcoded values/defines during compilation time.

[jan-kiszka]

Addressed by #3.