Re: [U-Boot] Watchdog support.
Hi Wolfgang,
Thank you to share your experience.
Anyway, I'm not sure that the common infrastructure covers all scenarios. For example in /common/main.c we have the code:
... int readline_into_buffer (const char *const prompt, char * buffer) { ... for (;;) { #ifdef CONFIG_BOOT_RETRY_TIME while (!tstc()) { /* while no incoming data */ if (retry_time >= 0 && get_ticks() > endtime) return (-2); /* timed out */ } #endif WATCHDOG_RESET(); /* Trigger watchdog, if needed */
#ifdef CONFIG_SHOW_ACTIVITY while (!tstc()) { extern void show_activity(int arg); show_activity(0); } #endif ...
if I enable CONFIG_BOOT_RETRY_TIME or CONFIG_SHOW_ACTIVITY the while loops iterate a call to tstc() to check the presence of a char in the input buffer. If tstc doesn't reset the watchdog (like ns16550 driver in my case) we could have a watchdog timeout.
Ok I patched the serial line driver in order to call the WATCHDOG_RESET function... but I will not cover all code flows.
From these considerations, I ask myself if the watchdog infrastructure is really robust or if we need to improve something (like patch policy : we accept only patch "WATCHDOG"-aware or demand the watchdog to a "simple" scheduler).
Of course... these are my2cents but I'm interested to community opinions.
thanks and best regards,
luigi
Il domenica 14 settembre 2008 12:28:54 hai scritto:
Dear "Luigi 'Comio' Mantellini",
In message 200809140859.33792.luigi.mantellini.ml@gmail.com you wrote:
I'm working on a mips based SoC with an external watchdog. The watchdog should be touched every 5 seconds in order to avoid the system reboot.
That shgould be no problem. We have a couple of boards that have watchdogs enabled, some with really strict requirements (like triggering the watchdow every 80 milliseconds).
I tried to define macros like CONFIG_HW_WATCHDOG / CONFIG_WATCHDOG, but I'm not happy for the result. For example, the serial port driver (ns16550 in my case) don't touch the watchdog during the status polling, as well as a lot of commands (copy in flash, tftp, ...).
I can't speak for MIPS in general, but the common infeastructure should work just fine.
I don't understand if u-boot supports or not watchdogs in a "structural" manner.
Yes, it does.
Kindly, if you have experience on Watchdog under u-boot, tell my any comments or suggestion.... in my application the watchdog is mandatory (i cannot stop the _watchdog_).
It's a standard feature being used actively on several boards, some of them in mass production.
Best regards,
Wolfgang Denk
Dear "Luigi 'Comio' Mantellini",
In message 200809141313.51807.luigi.mantellini@idf-hit.com you wrote:
Anyway, I'm not sure that the common infrastructure covers all scenarios. For example in /common/main.c we have the code:
As menrioned before, I'm not so sure about the MIPS implementation, but this is in proiduction use in several PowerPC boards.
int readline_into_buffer (const char *const prompt, char * buffer) { ...
if I enable CONFIG_BOOT_RETRY_TIME or CONFIG_SHOW_ACTIVITY the while loops iterate a call to tstc() to check the presence of a char in the input buffer. If tstc doesn't reset the watchdog (like ns16550 driver in my case) we could have a watchdog timeout.
He. I see what you mean. Well, U-Boot makes no attempts (yet) to implement actual watchdog checking for the U-Boot code itself. We just make sure that the watchdog gets triggered. This is done in the timer interrupt; see "lib_ppc/interrupts.c":
116 void timer_interrupt (struct pt_regs *regs) 117 { ... 126 #if defined(CONFIG_WATCHDOG) || defined (CONFIG_HW_WATCHDOG) 127 if ((timestamp % (CFG_WATCHDOG_FREQ)) == 0) 128 WATCHDOG_RESET (); 129 #endif /* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
So specific watchdog triggering is only necessary for those parts of the code that have to be run with interrupts switched off.
Ok I patched the serial line driver in order to call the WATCHDOG_RESET function... but I will not cover all code flows.
That should not be necessary.
Best regards,
Wolfgang Denk
Hi Wolfgang,
from this discussion, I have understood that the problem is that mips code lacks the support interrupts in iv mode. I will try to do something (support of IV modality... for example).
Thanks again,
luigi
Il domenica 14 settembre 2008 17:59:46 Wolfgang Denk ha scritto:
Dear "Luigi 'Comio' Mantellini",
In message 200809141313.51807.luigi.mantellini@idf-hit.com you wrote:
Anyway, I'm not sure that the common infrastructure covers all scenarios. For example in /common/main.c we have the code:
As menrioned before, I'm not so sure about the MIPS implementation, but this is in proiduction use in several PowerPC boards.
int readline_into_buffer (const char *const prompt, char * buffer) { ...
if I enable CONFIG_BOOT_RETRY_TIME or CONFIG_SHOW_ACTIVITY the while loops iterate a call to tstc() to check the presence of a char in the input buffer. If tstc doesn't reset the watchdog (like ns16550 driver in my case) we could have a watchdog timeout.
He. I see what you mean. Well, U-Boot makes no attempts (yet) to implement actual watchdog checking for the U-Boot code itself. We just make sure that the watchdog gets triggered. This is done in the timer interrupt; see "lib_ppc/interrupts.c":
116 void timer_interrupt (struct pt_regs *regs) 117 { ... 126 #if defined(CONFIG_WATCHDOG) || defined (CONFIG_HW_WATCHDOG) 127 if ((timestamp % (CFG_WATCHDOG_FREQ)) == 0) 128 WATCHDOG_RESET (); 129 #endif /* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
So specific watchdog triggering is only necessary for those parts of the code that have to be run with interrupts switched off.
Ok I patched the serial line driver in order to call the WATCHDOG_RESET function... but I will not cover all code flows.
That should not be necessary.
Best regards,
Wolfgang Denk
participants (3)
-
Luigi 'Comio' Mantellini -
Luigi 'Comio' Mantellini -
Wolfgang Denk