[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[vb]

Gentlemen,

I am trying to enable hardware watchdog in version 1.1.6 on an 85xx
based platform.

I added CONFIG_HW_WATCHDOG definition to include/configs/<platform>.h
and provided the hw_watchdog_reset() function. The image compiled and
linked nicely, but once I run it in u-boot CLI (monitor) mode - it
gets killed by the watchdog in no time.

My examination of the source code has shown that there is no watchdog
interactions in the tight loop in drivers/ns16550.c:NS16550_getc(). So
the HW watchdog is in fact not being kicked in the tight loop if the
system enters the u-boot CLI mode, so it is getting reset for a
reason.

Is this expected behavior and the HW watchdog is required to be
disabled when in u-boot CLI mode?

TIA,
cheers,
vadim

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[Wolfgang Denk]

In message <f608b67d0703191743id58c79cjb0ff4d2fdf1975b7@mail.gmail.com> you wrote:
> 
> My examination of the source code has shown that there is no watchdog
> interactions in the tight loop in drivers/ns16550.c:NS16550_getc(). So
> the HW watchdog is in fact not being kicked in the tight loop if the
> system enters the u-boot CLI mode, so it is getting reset for a
> reason.

Seems you are the first to use this serial driver with a watchdog
turned on...

> Is this expected behavior and the HW watchdog is required to be
> disabled when in u-boot CLI mode?

No, this is not expected behavior.

Watchdig trigger points are  missing  and  should  be  added  to  the
driver. I'm looking forward to seeing your patch...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a man had a child who'd gone  anti-social,  killed  perhaps,  he'd
still tend to protect that child.
	-- McCoy, "The Ultimate Computer", stardate 4731.3

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[Daniel Hobi]

On 20.03.2007 01:43, vb wrote:
> I am trying to enable hardware watchdog in version 1.1.6 on an 85xx
> based platform.
> 
> I added CONFIG_HW_WATCHDOG definition to include/configs/<platform>.h
> and provided the hw_watchdog_reset() function. The image compiled and
> linked nicely, but once I run it in u-boot CLI (monitor) mode - it
> gets killed by the watchdog in no time.

The 85xx seems to support a timer interrupt based hardware watchdog 
model by enabling CONFIG_WATCHDOG (note the difference to your define). 
Have a look at these functions:

cpu/mpc85xx/interrupts.c: timer_interrupt
cpu/mpc85xx/cpu.c: reset_85xx_watchdog

Maybe these fit your need?

Best Regards,
Daniel

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[Daniel Hobi]

On 20.03.2007 02:36, Wolfgang Denk wrote:
> In message <f608b67d0703191743id58c79cjb0ff4d2fdf1975b7@mail.gmail.com> you wrote:
>> My examination of the source code has shown that there is no watchdog
>> interactions in the tight loop in drivers/ns16550.c:NS16550_getc().
> 
> Seems you are the first to use this serial driver with a watchdog
> turned on...

At least the first one using a watchdog model which does not rely on a 
timer interrupt triggering the (hardware) watchdog.

> Watchdig trigger points are  missing  and  should  be  added  to  the
> driver. I'm looking forward to seeing your patch...

What's the preferred policy to trigger the watchdog in U-Boot? Trigger 
using a timer interrupt (as in lib_ppc/interrupts.c) or add calls to 
WATCHDOG_RESET() to every function which may take longer than some 
fraction of the minimal watchdog period (which is?)?

I know there are functions which disable interrupts and thus have to 
trigger the watchdog themself (like do_bootm).

Best Regards,
Daniel

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[Wolfgang Denk]

In message <45FFA1BC.2040809@gmx.net> you wrote:
>
> What's the preferred policy to trigger the watchdog in U-Boot? Trigger 
> using a timer interrupt (as in lib_ppc/interrupts.c) or add calls to 
> WATCHDOG_RESET() to every function which may take longer than some 
> fraction of the minimal watchdog period (which is?)?

The minimal watchdog period we've seen in real systems so far  is  80
milliseconds, including some tolerance of +/- 20%, so we need to keep
it < 50 millisec.

Normally, we trigger the WD in the timer tick  (i.  e.  every  milli-
second);  additionally,  we  have  a  WD  trigger in udelay(), so any
(possibly long) delays based on this are automatically safe.

This should reduce the number of places where a manual WATCHDOG_RESET
is needed to very few.

> I know there are functions which disable interrupts and thus have to 
> trigger the watchdog themself (like do_bootm).

I think most of these places are already safe.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Include the success of others in your dreams for your own success.

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[vb]

Well, the utility of watchdog kicking from within timer interrupt is
somewhat limited - what if a background program enters an endless loop
for whatever reason with interrupts enabled - we'd rather get reset by
a watchdog in this situation than sit there indefinitely.

cheers,
/vb


On 3/20/07, Daniel Hobi <dhobi@gmx.net> wrote:
> On 20.03.2007 01:43, vb wrote:
> > I am trying to enable hardware watchdog in version 1.1.6 on an 85xx
> > based platform.
> >
> > I added CONFIG_HW_WATCHDOG definition to include/configs/<platform>.h
> > and provided the hw_watchdog_reset() function. The image compiled and
> > linked nicely, but once I run it in u-boot CLI (monitor) mode - it
> > gets killed by the watchdog in no time.
>
> The 85xx seems to support a timer interrupt based hardware watchdog
> model by enabling CONFIG_WATCHDOG (note the difference to your define).
> Have a look at these functions:
>
> cpu/mpc85xx/interrupts.c: timer_interrupt
> cpu/mpc85xx/cpu.c: reset_85xx_watchdog
>
> Maybe these fit your need?
>
> Best Regards,
> Daniel
>

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[Wolfgang Denk]

In message <f608b67d0703200823g1ad8177cla544ec2b7f564b7a@mail.gmail.com> you wrote:
> Well, the utility of watchdog kicking from within timer interrupt is
> somewhat limited - what if a background program enters an endless loop
> for whatever reason with interrupts enabled - we'd rather get reset by
> a watchdog in this situation than sit there indefinitely.

Background? Program?

This is U-Boot. We're running strictly single-threaded.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A day without sunshine is like night.

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[vb]

On 3/19/07, Wolfgang Denk <wd@denx.de> wrote:

> Seems you are the first to use this serial driver with a watchdog
> turned on...
>
> > Is this expected behavior and the HW watchdog is required to be
> > disabled when in u-boot CLI mode?
>
> No, this is not expected behavior.
>
> Watchdig trigger points are  missing  and  should  be  added  to  the
> driver. I'm looking forward to seeing your patch...
>

well, it does not look like many of the console drivers in the
./drivers directory have watchdog trigger points (in 1.1.6):

es-o: ~/projects/uboot-bcm/uboot/drivers 33 > grep -l WATCH *
cfb_console.c
serial_max3100.c
es-o: ~/projects/uboot-bcm/uboot/drivers 34 >


so, it seems like a system wide issue - I guess people don't worry
about watchdog too much when u-boot is in monitor mode...

cheers,
/v

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[Wolfgang Denk]

In message <f608b67d0703201500i47f86f07uac1f0d3a3e7ffe5f@mail.gmail.com> you wrote:
>
> well, it does not look like many of the console drivers in the
> ./drivers directory have watchdog trigger points (in 1.1.6):
> 
> es-o: ~/projects/uboot-bcm/uboot/drivers 33 > grep -l WATCH *
> cfb_console.c
> serial_max3100.c

This may be misleading.

> so, it seems like a system wide issue - I guess people don't worry
> about watchdog too much when u-boot is in monitor mode...

As mentioned before, udelay() alsi implicitely triggers the WD, and
see here:

-> grep -l udelay drivers/*
drivers/3c589.c
drivers/ahci.c
drivers/bcm570x.c
drivers/bcm570x_mm.h
drivers/cfi_flash.c
drivers/cs8900.c
drivers/ct69000.c
drivers/dc2114x.c
drivers/dm9000x.c
drivers/ds1722.c
drivers/e1000.c
drivers/eepro100.c
drivers/fsl_i2c.c
drivers/i8042.c
drivers/i82365.c
drivers/inca-ip_sw.c
drivers/ks8695eth.c
drivers/lan91c96.c
drivers/mw_eeprom.c
drivers/natsemi.c
drivers/ne2000.c
drivers/ne2000.h
drivers/netarm_eth.c
drivers/ns7520_eth.c
drivers/ns8382x.c
drivers/ns9750_eth.c
drivers/omap1510_i2c.c
drivers/omap24xx_i2c.c
drivers/pc_keyb.c
drivers/pci.c
drivers/pcnet.c
drivers/ps2mult.c
drivers/pxa_pcmcia.c
drivers/rtl8019.c
drivers/rtl8139.c
drivers/rtl8169.c
drivers/serial_max3100.c
drivers/sl811_usb.c
drivers/sm501.c
drivers/smc91111.c
drivers/smiLynxEM.c
drivers/sym53c8xx.c
drivers/systemace.c
drivers/ti_pci1410a.c
drivers/tigon3.c
drivers/tqm8xx_pcmcia.c
drivers/tsec.c
drivers/usbdcore_omap1510.c
drivers/w83c553f.c


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
      - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>

[U-Boot-Users] CONFIG_HW_WATCHDOG in 1.1.6

[vb]

On 3/20/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <f608b67d0703201500i47f86f07uac1f0d3a3e7ffe5f@mail.gmail.com> you wrote:
> >
> > well, it does not look like many of the console drivers in the
> > ./drivers directory have watchdog trigger points (in 1.1.6):
> >
> > es-o: ~/projects/uboot-bcm/uboot/drivers 33 > grep -l WATCH *
> > cfb_console.c
> > serial_max3100.c
>
> This may be misleading.
>
> > so, it seems like a system wide issue - I guess people don't worry
> > about watchdog too much when u-boot is in monitor mode...
>
> As mentioned before, udelay() alsi implicitely triggers the WD, and
> see here:
>
Got it, thank you for pointing it out!

cheers,
/vb
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> As usual, this being a 1.3.x release, I haven't  even  compiled  this
> kernel yet. So if it works, you should be doubly impressed.
>       - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>
>