Hi Andre, On Mon, Jun 14, 2021 at 3:44 AM Andre Przywara <[email protected]> wrote: > > On Sat, 12 Jun 2021 10:17:08 +0530 > Suniel Mahesh <[email protected]> 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 > > > >
