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

[Samuel Holland <samuel@sholland.org>]

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