| Message ID | 1579702656-20667-1-git-send-email-f.suligoi@asem.it |
|---|---|
| State | New |
| Headers | show |
| Series | imx: distinguish POR from POR+WDOG reset cause for first wd | expand |
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
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 we have: SRC_SRSR = 0x00000011 --> POR + WDOG and in this case is important for me to distinguish the two different situation. Thanks, Flavio
> 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. Regards, Peng. > > and in this case is important for me to distinguish the two different situation. > > Thanks, > > Flavio
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
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:
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(-)