Reset cause register for Allwinner H3/R16 SOC's

[Suniel Mahesh]

Hi Andre,

On Mon, Jun 14, 2021 at 3:44 AM Andre Przywara <andre.przywara at arm.com> wrote:
>
> On Sat, 12 Jun 2021 10:17:08 +0530
> Suniel Mahesh <sunil at amarulasolutions.com> wrote:
>
> > Hi All,
> >
> > I am working on an Allwinner R16 and H3 based targets and I am implementing
> > system update.
> >
> > Is there any way(or a register) on Allwinner R16/H3 which can tell
> > what is the cause
> > of the reset(whether the reset is triggered by a watchdog or thermal
> > or reset or a POR).
>
> I don't think anybody found such an explicit gadget in Allwinner
> chips before.
> Besides, what would be the difference between watchdog, thermal and
> reset? AFAIK those are all the same watchdog triggered reset, in the
> last two cases deliberately triggered.
> If you want to convey information across a reset, you can use the RTC
> data registers: they survive a reset. So you can explicitly write some
> reset cause indicator value into one of the registers, then read that
> back after the reset.

Thanks for the insight.

My basic use case is the update mechanism on the target. The update mechanism
is implemented as follows:

1.
Assigned bootcounter to RTC GPR register. Boot count limit is 3.
If for some reason the device doesn't boot, then the WDOG waits for
specific period of time and triggers a reset.
For every WDOG reset bootcounter increments and if exceeds 3,
altbootcmd is triggered and the device boots recovery mode.

2.
The problem I am facing now is, I need to differentiate WDOG reset and a
normal reset.
If the user does a normal reset the bootcounter value should not be incremented
(as of now bootcounter value is incrementing for both WDOG reset and a
normal reset
which is obvious).
This is where I got stuck.

any more insight would be appreciated.
Suniel

 > For power-on-reset there might be some heuristics to tell it apart from
> a mere reset (temperature, PMIC state, DRAM content?), but in
> general the RTC register method should also work here.
> So if you are happy to hack some board specifics into your firmware, it
> should be doable, but there does not seem to be a generic mechanism
> implemented into the SoC.
>
> Cheers,
> Andre
>
>
>
>