BSP Watchdogs Was Re: [PATCH 36] LEON3: GPTIMER timer watchdog driver

[Gedare Bloom]

Moving this off the patch thread.

On Thu, Apr 19, 2012 at 6:32 AM, Daniel Hellstrom <daniel at gaisler.com> wrote:
> On 04/18/2012 06:35 PM, Joel Sherrill wrote:
>> On 04/18/2012 10:53 AM, Joel Sherrill wrote:
>>> + You are proposing new bsp_watchdog methods. I am
>>> not opposed to them but they shouldn't go in your bsp.h.
>
> ok, will add watchdog.h temporarily and resubmit patch. I agree a common API
> would benefit all, and I'm ready to convert the LEON3 watchdog code for the
> new API when it is available.
>
Good. Hopefully whoever takes up this cause can make use of your work.

>
>>> It would be better to add this as a possible API for all BSPs.
>>> This would have to be reconciled with the following existing
>>> code in the tree:
>>>
>>> ./cpukit/libcsupport/include/rtems/watchdogdrv.h
>>> ./c/src/lib/libcpu/powerpc/mpc55xx/include/watchdog.h
>>> ./c/src/lib/libbsp/powerpc/mpc55xxevb/startup/start-watchdog.c
>>>
>>> And I did some work on a prototype which never got the
>>> attention it deserved. Chris and I discussed this as a libchip
>>> framework where you could have multiple reset watchdogs
>>> for different pieces of hardware.
>>>
>>> I prototyped a simple one based upon a test fixture reset
>>> driver and a some code for the Intel ich4 chipset watchdog.
>>> Longer term, we envisioned a library of watchdog management
>>> code which helped the application. Say reset from timer or
>>> a special task.
>>
>> http://www.rtems.org/ftp/pub/rtems/people/joel/watchdog/
>>>
>>> I would like to take this as an opportunity to discuss this
>>> all again and get on the right path long term. Your
>>> "bsp_watchdog_xxx" could be the names for the
>>> main board reset and the framework could be
>>> layered on top of it.
>
>
> I have read your code, and I have detected some coding-style issues... ;)
> ... anyway, one thing that that came to my mind was that the watchdog
> functionality may be initialized early in the BSP already to detect a
> lock-up during boot, or perhaps we need to access the watchdog routines on
> shutdown after RTEMS has been closed down. But at that time the IO layer is
> perhaps not available, my point is that it is perhaps better to avoid depend
> on the IO layer? On the other hand, it may be the bootloader that sets up
> the watchdog the first time to detect a RTEMS boot hang.
>
I believe some targets (Leon might even be one?) require the hw
watchdog to be dealt with / initialized during boot otherwise they
never make progress due to watchdog resets. I haven't read either
approach yet but we definitely should avoid having dependencies at
least for the basic bsp_watchdog routines.

-Gedare

> The reboot returns to bootcard.c, then bsp_clean(), then to the BSP. In the
> LEON case the CPU is forced into a trap/debug-mode. It would perhaps be
> better to have to option to reset the system also instead of always stopping
> the CPU. That is something I need to think about.
>
> Daniel