public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Flavio Suligoi <f.suligoi@asem.it>
To: u-boot@lists.denx.de
Subject: [PATCH] imx: distinguish POR from POR+WDOG reset cause for first wd
Date: Mon, 27 Jan 2020 13:49:48 +0000	[thread overview]
Message-ID: <adeb88e62b714a71ada4bdbda8236954@asem.it> (raw)
In-Reply-To: <AM0PR04MB4481D39F26CDF85C7E35689C880B0@AM0PR04MB4481.eurprd04.prod.outlook.com>

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

      reply	other threads:[~2020-01-27 13:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22 14:17 [PATCH] imx: distinguish POR from POR+WDOG reset cause for first wd Flavio Suligoi
2020-01-22 17:46 ` Fabio Estevam
2020-01-23  8:22   ` Flavio Suligoi
2020-01-27 12:49     ` Peng Fan
2020-01-27 13:49       ` Flavio Suligoi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adeb88e62b714a71ada4bdbda8236954@asem.it \
    --to=f.suligoi@asem.it \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox