Reset cause register for Allwinner H3/R16 SOC's

Reset cause register for Allwinner H3/R16 SOC's

[Suniel Mahesh]

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

Thanks & Regards
-- 
Suniel Mahesh
Embedded Linux and Kernel Engineer
Amarula Solutions India

Re: Reset cause register for Allwinner H3/R16 SOC's

[Andre Przywara]

On Sat, 12 Jun 2021 10:17:08 +0530
Suniel Mahesh <sunil@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.
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

Re: 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@arm.com> wrote:
>
> On Sat, 12 Jun 2021 10:17:08 +0530
> Suniel Mahesh <sunil@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
>
>
>
>

Re: Reset cause register for Allwinner H3/R16 SOC's

[Samuel Holland]

On 6/13/21 11:37 PM, Suniel Mahesh wrote:
> Hi Andre,
> 
> On Mon, Jun 14, 2021 at 3:44 AM Andre Przywara <andre.przywara@arm.com> wrote:
>>
>> On Sat, 12 Jun 2021 10:17:08 +0530
>> Suniel Mahesh <sunil@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.

It sounds like you want to reset the boot counter to zero from either
the kernel or userspace once the device boots successfully. Then it will
be zero after the next reset. You can accomplish that by using this
patch[1] plus the nvmem-reboot-mode driver, or the nvmem sysfs.

Cheers,
Samuel

[1]:
https://lore.kernel.org/linux-sunxi/20210419014549.26900-1-samuel@sholland.org/

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