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

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

[Flavio Suligoi]

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@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:
-- 
2.7.4

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

[Fabio Estevam]

Hi Flavio,

On Wed, Jan 22, 2020 at 11:18 AM Flavio Suligoi <f.suligoi@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@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

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

[Flavio Suligoi]

Hi Fabio,

> 
> Hi Flavio,
> 
> On Wed, Jan 22, 2020 at 11:18 AM Flavio Suligoi <f.suligoi@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@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

we have:
SRC_SRSR = 0x00000011  --> POR + WDOG

and in this case is important for me to distinguish the two
different situation.

Thanks,

Flavio

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

[Peng Fan]

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

Regards,
Peng.

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

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

[Flavio Suligoi]

Hi Peng,

> -----Original Message-----
> From: Peng Fan <peng.fan@nxp.com>
> Sent: lunedì 27 gennaio 2020 13:50
> To: Flavio Suligoi <f.suligoi@asem.it>; Fabio Estevam <festevam@gmail.com>
> Cc: Stefano Babic <sbabic@denx.de>; dl-uboot-imx <uboot-imx@nxp.com>; U-
> Boot-Denx <u-boot@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@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@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