[U-Boot] Watchdog support for ppc4xx

[U-Boot] Watchdog support for ppc4xx

[Mark Maestas]

Hi,

 

I have a question about watchdog support for PPC_4xx.  When I define
CONFIG_WATCHDOG in canyonlands.h, I get an error when building
cpu_init.c.  The error code reads:

 

{standard input}: Assembler messages:

{standard input}:133: Error: unsupported relocation against tcr

{standard input}:141: Error: unsupported relocation against tcr

{standard input}:146: Error: unsupported relocation against tsr

{standard input}:154: Error: unsupported relocation against tsr

make[1]: *** [cpu_init.o] Error 1

 

 

Shouldn't this work?  Also I would like to determine in u-boot if a
reset was caused by the watchdog timer using the TSR WRS field.  If it
was reset by the watchdog we will boot into a failsafe partition to
protect against system update errors.  

 

Has anyone done something like this?

 

Thanks

 

Mark Maestas

AP Labs

[U-Boot] Watchdog support for ppc4xx

[Stefan Roese]

Hi Mark,

On Thursday 20 May 2010 00:27:50 Mark Maestas wrote:
> I have a question about watchdog support for PPC_4xx.  When I define
> CONFIG_WATCHDOG in canyonlands.h, I get an error when building
> cpu_init.c.  The error code reads:
> 
> {standard input}: Assembler messages:
> {standard input}:133: Error: unsupported relocation against tcr
> {standard input}:141: Error: unsupported relocation against tcr
> {standard input}:146: Error: unsupported relocation against tsr
> {standard input}:154: Error: unsupported relocation against tsr
> make[1]: *** [cpu_init.o] Error 1
> 
> Shouldn't this work?

It *should*. But unfortunately it doesn't. I just checked this here myself. I 
get the same error. Seems that the "tcr/tsr" defines need to be converted to 
upper-case. It would be great if you could send a patch for this.

> Also I would like to determine in u-boot if a
> reset was caused by the watchdog timer using the TSR WRS field.  If it
> was reset by the watchdog we will boot into a failsafe partition to
> protect against system update errors.
> 
> Has anyone done something like this?

Such a detection is not implemented for PPC4xx. Not sure if it's implemented 
for any other architecture.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] Watchdog support for ppc4xx

[Mark Maestas]

Thanks Stefan, 

I actually determined that after the git repository build did the same
thing.  I changed it to use the SPRN_TCR and SPRN_TSR values but I did
see in processor.h where TSR and TCR are defined so I will modify it
based on those values.  The watchdog reset notification is very useful
and we have done that with red boot on a different project so I will
make an attempt to implement the same functionality.  Basically you need
to detect if the watchdog did force a reset and ideally how long the
system was running before it reset to determine which partition to boot
in a dual partition setup.  

Thanks for the quick response.  I will work to create a patch for this
functionality according to the u-boot standards.

Mark


-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Thursday, May 20, 2010 4:55 AM
To: u-boot at lists.denx.de
Cc: Mark Maestas
Subject: Re: [U-Boot] Watchdog support for ppc4xx

Hi Mark,

On Thursday 20 May 2010 00:27:50 Mark Maestas wrote:
> I have a question about watchdog support for PPC_4xx.  When I define
> CONFIG_WATCHDOG in canyonlands.h, I get an error when building
> cpu_init.c.  The error code reads:
> 
> {standard input}: Assembler messages:
> {standard input}:133: Error: unsupported relocation against tcr
> {standard input}:141: Error: unsupported relocation against tcr
> {standard input}:146: Error: unsupported relocation against tsr
> {standard input}:154: Error: unsupported relocation against tsr
> make[1]: *** [cpu_init.o] Error 1
> 
> Shouldn't this work?

It *should*. But unfortunately it doesn't. I just checked this here
myself. I 
get the same error. Seems that the "tcr/tsr" defines need to be
converted to 
upper-case. It would be great if you could send a patch for this.

> Also I would like to determine in u-boot if a
> reset was caused by the watchdog timer using the TSR WRS field.  If it
> was reset by the watchdog we will boot into a failsafe partition to
> protect against system update errors.
> 
> Has anyone done something like this?

Such a detection is not implemented for PPC4xx. Not sure if it's
implemented 
for any other architecture.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] Watchdog support for ppc4xx

[Wolfgang Denk]

Dear Stefan Roese,

In message <201005201355.01964.sr@denx.de> you wrote:
> 
> > Also I would like to determine in u-boot if a
> > reset was caused by the watchdog timer using the TSR WRS field.  If it
> > was reset by the watchdog we will boot into a failsafe partition to
> > protect against system update errors.
> > 
> > Has anyone done something like this?
> 
> Such a detection is not implemented for PPC4xx. Not sure if it's implemented 
> for any other architecture.

I think lwmon5 performs such checking; eventually this is buryied
somewhere in the POST code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It ain't so much the things we don't know that get  us  in  trouble.
It's  the  things  we know that ain't so." - Artemus Ward aka Charles
Farrar Brown

[U-Boot] Watchdog support for ppc4xx

[Detlev Zundel]

Hi Wolfgang,

> Dear Stefan Roese,
>
> In message <201005201355.01964.sr@denx.de> you wrote:
>> 
>> > Also I would like to determine in u-boot if a
>> > reset was caused by the watchdog timer using the TSR WRS field.  If it
>> > was reset by the watchdog we will boot into a failsafe partition to
>> > protect against system update errors.
>> > 
>> > Has anyone done something like this?
>> 
>> Such a detection is not implemented for PPC4xx. Not sure if it's implemented 
>> for any other architecture.
>
> I think lwmon5 performs such checking; eventually this is buryied
> somewhere in the POST code.

Well, at least I know that for mpc5121 we read the reser status register
at boot and copy it to global data
(arch/powerpc/cpu/mpc512x/cpu_init.c:64).  The value is also output in
the U-Boot prompt (arch/powerpc/cpu/mpc512x/cpu.c:68) which is a nice
thing IMHO.

Checking a "git grep reset_status" one can see that something similar is
done for other PowerPC cpus as well, so I'd suggest reusing this method
for ppc4xx and providing a mechanism to access this information from a
script.

Cheers
  Detlev

-- 
Wenn ein Kopf und ein Buch zusammenstossen und es klingt hohl; ist
denn das allemal im Buche?
                               - Lichtenberg
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Watchdog support for ppc4xx

[Mark Maestas]

Hi All,

I am not having luck with watchdog enabled on the ppc4xx target.  The
board is doing a reset before Linux gets a chance to load.  I have added
more WATCHDOG_RESET commands in the image file just to see if that helps
and it does not seem to.  Even though the reset function gets called it
is still getting reset.  According to the ppc 440 documentation the
TSR[WIS] bit should get cleared to reset the timer and the code is doing
that.  I don't understand why the board keeps resetting.  

Does anyone have experience with this?

Thanks

Mark Maestas

-----Original Message-----
From: Detlev Zundel [mailto:dzu at denx.de] 
Sent: Friday, May 21, 2010 2:06 AM
To: Wolfgang Denk
Cc: Stefan Roese; u-boot at lists.denx.de; Mark Maestas
Subject: Re: [U-Boot] Watchdog support for ppc4xx

Hi Wolfgang,

> Dear Stefan Roese,
>
> In message <201005201355.01964.sr@denx.de> you wrote:
>> 
>> > Also I would like to determine in u-boot if a
>> > reset was caused by the watchdog timer using the TSR WRS field.  If
it
>> > was reset by the watchdog we will boot into a failsafe partition to
>> > protect against system update errors.
>> > 
>> > Has anyone done something like this?
>> 
>> Such a detection is not implemented for PPC4xx. Not sure if it's
implemented 
>> for any other architecture.
>
> I think lwmon5 performs such checking; eventually this is buryied
> somewhere in the POST code.

Well, at least I know that for mpc5121 we read the reser status register
at boot and copy it to global data
(arch/powerpc/cpu/mpc512x/cpu_init.c:64).  The value is also output in
the U-Boot prompt (arch/powerpc/cpu/mpc512x/cpu.c:68) which is a nice
thing IMHO.

Checking a "git grep reset_status" one can see that something similar is
done for other PowerPC cpus as well, so I'd suggest reusing this method
for ppc4xx and providing a mechanism to access this information from a
script.

Cheers
  Detlev

-- 
Wenn ein Kopf und ein Buch zusammenstossen und es klingt hohl; ist
denn das allemal im Buche?
                               - Lichtenberg
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Watchdog support for ppc4xx

[Wolfgang Denk]

Dear "Mark Maestas",

In message <B02FCC6065C3164C8228CF04AB049EAC0114CCDA@srv-01.aplabs.com> you wrote:
> 
> I am not having luck with watchdog enabled on the ppc4xx target.  The
> board is doing a reset before Linux gets a chance to load.  I have added

Please define exactly what you mean by "before Linux gets a chance to
load" - is it resetting in U-Boot, or after passsing control to the
Linux kernel?

> more WATCHDOG_RESET commands in the image file just to see if that helps

What does "in the image file" mean?

> and it does not seem to.  Even though the reset function gets called it
> is still getting reset.  According to the ppc 440 documentation the

By "reset function" you actually mean the code that is supposed to
trigger the watchdog? Otherwise - the reset function is supposed to
reset the system, so everthing would be OK then.

> TSR[WIS] bit should get cleared to reset the timer and the code is doing
> that.  I don't understand why the board keeps resetting.  

This depends on the hardware, and obviously on the code doing this
(keep in mind that using I/O accessors is mandatory these days).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I haven't lost my mind -- it's backed up on tape somewhere.

[U-Boot] Watchdog support for ppc4xx

[Mark Maestas]

Thanks Wolfgang,

The board is resetting within u-boot before Linux starts to load.  I
added the WATCHDOG_RESET call in common/image.c before and after it is
loading the device tree which is where it gets reset.  I figured that if
I reset the watchdog before that process it will give me more time so
that Linux can load and take over.  It seems like code was already there
to handle the reset in memmove_wd but it does not seem to be working.
The Linux watchdog code is working great.  If I remove watchdog from
u-boot and just do it in Linux it works just fine.  I enable BookE
driver in Linux and that works.  The other thing that is difficult is
creating a /dev/watchdog node in the blob.  Currently I need to do that
in a startup script.  I would like to have that in the blob.

The watchdog_reset function is trying to prevent the interrupt from
happening.  It does seem to do the correct thing based on the PPC440 UG.

Thanks for the help.

Mark

-----Original Message-----
From: Wolfgang Denk [mailto:wd at denx.de] 
Sent: Friday, June 04, 2010 12:47 PM
To: Mark Maestas
Cc: Detlev Zundel; Stefan Roese; u-boot at lists.denx.de
Subject: Re: [U-Boot] Watchdog support for ppc4xx

Dear "Mark Maestas",

In message <B02FCC6065C3164C8228CF04AB049EAC0114CCDA@srv-01.aplabs.com>
you wrote:
> 
> I am not having luck with watchdog enabled on the ppc4xx target.  The
> board is doing a reset before Linux gets a chance to load.  I have
added

Please define exactly what you mean by "before Linux gets a chance to
load" - is it resetting in U-Boot, or after passsing control to the
Linux kernel?

> more WATCHDOG_RESET commands in the image file just to see if that
helps

What does "in the image file" mean?

> and it does not seem to.  Even though the reset function gets called
it
> is still getting reset.  According to the ppc 440 documentation the

By "reset function" you actually mean the code that is supposed to
trigger the watchdog? Otherwise - the reset function is supposed to
reset the system, so everthing would be OK then.

> TSR[WIS] bit should get cleared to reset the timer and the code is
doing
> that.  I don't understand why the board keeps resetting.  

This depends on the hardware, and obviously on the code doing this
(keep in mind that using I/O accessors is mandatory these days).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I haven't lost my mind -- it's backed up on tape somewhere.

[U-Boot] Watchdog support for ppc4xx

[Chen Wen]

u-boot reset watchdog everywhere in u-boot code.
But linux reset watchdog only when you reset /dev/watchdog by ioctl.

You can try to  put "mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);" in kernel main.c to
keep alive the watchdog.

On Sat, Jun 5, 2010 at 4:14 AM, Mark Maestas <maestas@aplabs.com> wrote:

> Thanks Wolfgang,
>
> The board is resetting within u-boot before Linux starts to load.  I
> added the WATCHDOG_RESET call in common/image.c before and after it is
> loading the device tree which is where it gets reset.  I figured that if
> I reset the watchdog before that process it will give me more time so
> that Linux can load and take over.  It seems like code was already there
> to handle the reset in memmove_wd but it does not seem to be working.
> The Linux watchdog code is working great.  If I remove watchdog from
> u-boot and just do it in Linux it works just fine.  I enable BookE
> driver in Linux and that works.  The other thing that is difficult is
> creating a /dev/watchdog node in the blob.  Currently I need to do that
> in a startup script.  I would like to have that in the blob.
>
> The watchdog_reset function is trying to prevent the interrupt from
> happening.  It does seem to do the correct thing based on the PPC440 UG.
>
> Thanks for the help.
>
> Mark
>
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Friday, June 04, 2010 12:47 PM
> To: Mark Maestas
> Cc: Detlev Zundel; Stefan Roese; u-boot at lists.denx.de
> Subject: Re: [U-Boot] Watchdog support for ppc4xx
>
> Dear "Mark Maestas",
>
> In message <B02FCC6065C3164C8228CF04AB049EAC0114CCDA@srv-01.aplabs.com>
> you wrote:
> >
> > I am not having luck with watchdog enabled on the ppc4xx target.  The
> > board is doing a reset before Linux gets a chance to load.  I have
> added
>
> Please define exactly what you mean by "before Linux gets a chance to
> load" - is it resetting in U-Boot, or after passsing control to the
> Linux kernel?
>
> > more WATCHDOG_RESET commands in the image file just to see if that
> helps
>
> What does "in the image file" mean?
>
> > and it does not seem to.  Even though the reset function gets called
> it
> > is still getting reset.  According to the ppc 440 documentation the
>
> By "reset function" you actually mean the code that is supposed to
> trigger the watchdog? Otherwise - the reset function is supposed to
> reset the system, so everthing would be OK then.
>
> > TSR[WIS] bit should get cleared to reset the timer and the code is
> doing
> > that.  I don't understand why the board keeps resetting.
>
> This depends on the hardware, and obviously on the code doing this
> (keep in mind that using I/O accessors is mandatory these days).
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> I haven't lost my mind -- it's backed up on tape somewhere.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>