[PATCH] imx: distinguish POR from POR+WDOG reset cause for first wd

Flavio Suligoi f.suligoi at asem.it
Mon Jan 27 14:49:48 CET 2020


Hi Peng,

> -----Original Message-----
> From: Peng Fan <peng.fan at nxp.com>
> Sent: lunedì 27 gennaio 2020 13:50
> To: Flavio Suligoi <f.suligoi at asem.it>; Fabio Estevam <festevam at gmail.com>
> Cc: Stefano Babic <sbabic at denx.de>; dl-uboot-imx <uboot-imx at nxp.com>; U-
> Boot-Denx <u-boot at lists.denx.de>
> Subject: RE: [PATCH] imx: distinguish POR from POR+WDOG reset cause for
> first wd
> 
> 
> 
> > Subject: RE: [PATCH] imx: distinguish POR from POR+WDOG reset cause for
> > first wd
> >
> > Hi Fabio,
> >
> > >
> > > Hi Flavio,
> > >
> > > On Wed, Jan 22, 2020 at 11:18 AM Flavio Suligoi <f.suligoi at asem.it>
> wrote:
> > > >
> > > > In some application the possibility to check if the reset is caused
> > > > by a watchdog is essential, even if it occurs simultaneously with
> > > > POR.
> > > >
> > > > Signed-off-by: Flavio Suligoi <f.suligoi at asem.it>
> > > > ---
> > > >  arch/arm/mach-imx/cpu.c | 7 ++++++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c index
> > > > bfa85c6..ce0c663 100644
> > > > --- a/arch/arm/mach-imx/cpu.c
> > > > +++ b/arch/arm/mach-imx/cpu.c
> > > > @@ -47,7 +47,6 @@ static char *get_reset_cause(void)  {
> > > >         switch (get_imx_reset_cause()) {
> > > >         case 0x00001:
> > > > -       case 0x00011:
> > > >                 return "POR";
> > > >         case 0x00004:
> > > >                 return "CSU";
> > > > @@ -59,6 +58,12 @@ static char *get_reset_cause(void)  #else
> > > >                 return "WDOG";
> > > >  #endif
> > > > +       case 0x00011:
> > > > +#ifdef CONFIG_MX7
> > > > +               return "POR + WDOG1"; #else
> > > > +               return "POR + WDOG"; #endif
> > > >         case 0x00020:
> > > >                 return "JTAG HIGH-Z";
> > > >         case 0x00040:
> > >
> > > If I understand this correctly your board has a WDOG_B pin connected
> > > to the PMIC and when WDOG_B is asserted the PMIC is power cycled and
> > > the system resets via POR.
> > >
> > > Is this correct? If not, please describe exactly your setup and what
> > > you are trying to achieve.
> > >
> > > It seems that the current behavior is correct for me.
> > >
> > > Thanks
> >
> > I'm currently use the imx8mm_evk board, with the PMIC Rohom
> > BD71847AMWV.
> > After a:
> >
> > - power-on
> > - push-button reset
> > - a watchdog using the WDOG_B
> >
> > the i.MX8MMini register SRC_SRSR (address 0x3039005C) is:
> > SRC_SRSR = 0x00000001 --> POR
> >
> > but after a soft reset, from u-boot, using the WDOG1_WCR (address
> > 0x30280000):
> >
> > mw.w 30280000 053C
> 
> This will trigger a wdog timeout wdog_b assert to pmic, so it should be
> POR.
> 
> >
> > we have:
> > SRC_SRSR = 0x00000011  --> POR + WDOG
> 
> If bit4 is set, that means you are not really doing POR. Have you tried
> clear
> Bit 3 and 5 when set WCR?
> 
> If you wanna soft reset, using wdog_b to trigger pmic is not correct. You
> need use SRS.

My goal is to use the wd to have an hw reset, using the WDOG_B
connected to the PMIC, but, in the same time, at reboot, I want
to distinguish a real POR (a real power-on, for example) from a reset
caused by the wd-->WDOG_B.

In our future mx8mm board we want to use the new PCA9450, using its
capability to generate a cold reset, recycling all the 
voltage regulators except LDO1/2 (see cap.7.4 PMIC Reset,
register 0x08 RESET_CTRL).
In this way the SNVS_LP power should maintain the values inside the
SRC Reset Status Register (SRC_SRSR) of the mx8mm. Is it correct?

Thanks and regards,

Flavio

> 
> Regards,
> Peng.
> 
> >
> > and in this case is important for me to distinguish the two different
> situation.
> >
> > Thanks,
> >
> > Flavio



More information about the U-Boot mailing list