Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Watchdog
= Watchdog =
Typically, during application development , the watchdog device included in the embedded system is turned off. Before moving to the field, enabling the watchdog is often a mandatory choice(*). The use of this peripheral is a little bit tricky because it involves both U-Boot and Linux. The following sequence shows the typical scenario when the system is working on the field:
# Processor comes out of reset; internal watchdog is disabled
# U-Boot enables watchdog (timeout = 5 s); U-Boot main loop will take care of refreshing it
# Before giving control to Linux kernel, U-Boot will set up a long (e.g 180 seconds) timeout. This is required in order to allow the kernel to complete the boot stage and to run the application that will handle the watchdog refresh# Once the kernel boot process has completed, watchdog application will open the watchdog device file and will take care about of its refresh (timeout = 10 s)
To enable watchdog support in U-Boot, source code must be modified and the bootloadr bootloader must be recompiled. Usually , this means enabling CONFIG_WATCHDOG and CONFIG_xxx (where xxx is the name of the watchdog device).
Once Linux is started (and if the kernel is compiled with watchdog support), watchdog is refreshed by a simple application like the one shown below:
mknod /dev/watchdog c 10 130
</pre>
(*) Enabling the watchdog functionality has several system-level consequences as well. As such, system integrators need the freedom to decide whether to enable it or not. For instance, there are applications for which the system integrators do not want to enable the watchdog. They prefer that their final users are aware of software hangs and that the users reset the board manually. Of course, this approach might not make any sense in case of unattended devices.
= Startup sequence =
