* Reset cause register for Allwinner H3/R16 SOC's @ 2021-06-12 4:47 Suniel Mahesh 2021-06-13 22:14 ` Andre Przywara 0 siblings, 1 reply; 4+ messages in thread From: Suniel Mahesh @ 2021-06-12 4:47 UTC (permalink / raw) To: U-Boot-Denx; +Cc: Andre Przywara 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reset cause register for Allwinner H3/R16 SOC's 2021-06-12 4:47 Reset cause register for Allwinner H3/R16 SOC's Suniel Mahesh @ 2021-06-13 22:14 ` Andre Przywara 2021-06-14 4:37 ` Suniel Mahesh 0 siblings, 1 reply; 4+ messages in thread From: Andre Przywara @ 2021-06-13 22:14 UTC (permalink / raw) To: Suniel Mahesh; +Cc: U-Boot-Denx 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reset cause register for Allwinner H3/R16 SOC's 2021-06-13 22:14 ` Andre Przywara @ 2021-06-14 4:37 ` Suniel Mahesh 2021-06-14 5:37 ` Samuel Holland 0 siblings, 1 reply; 4+ messages in thread From: Suniel Mahesh @ 2021-06-14 4:37 UTC (permalink / raw) To: Andre Przywara; +Cc: U-Boot-Denx, Michael Nazzareno Trimarchi, Jagan Teki 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 > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reset cause register for Allwinner H3/R16 SOC's 2021-06-14 4:37 ` Suniel Mahesh @ 2021-06-14 5:37 ` Samuel Holland 0 siblings, 0 replies; 4+ messages in thread From: Samuel Holland @ 2021-06-14 5:37 UTC (permalink / raw) To: Suniel Mahesh, Andre Przywara Cc: linux-sunxi, U-Boot-Denx, Michael Nazzareno Trimarchi, Jagan Teki 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 >> >> >> >> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-06-14 5:38 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-12 4:47 Reset cause register for Allwinner H3/R16 SOC's Suniel Mahesh 2021-06-13 22:14 ` Andre Przywara 2021-06-14 4:37 ` Suniel Mahesh 2021-06-14 5:37 ` Samuel Holland
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.