Table of Contents
Advertisement
Watchdog Daemon Test
The Watchdog daemon reset behavior can be tested on the SMARC board using the below sequence of commands
Stop the Watchdog service using the below commands
=> systemctl stop watchdog
=> systemctl status watchdog
Active: inactive (dead) since Fri 2019-11-08 08:55:45 UTC; 7s ago
Edit the watchdog conf file in location /etc/watchdog.conf
Enable ping to an IP which doesn't exist in the board's network (uncomment the below line in the file)
ping 10.1.x.x
Restart the watchdog service using the below commands
=> systemctl start watchdog
=> systemctl status watchdog
watchdog.service - watchdog daemon
Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; vendor preset>
Active: active (running) since Fri 2019-11-08 08:52:49 UTC; 1min 39s ago
In approximately 60secs the watchdog daemon will trigger a system reset due to failure of the ping command
Alternatively SMARC sAMX8 BSP also includes two example user space applications to demonstrate the device reset
behaviour and the dual stage watchdog behaviour upon a watchdog pretimeout and timeout event. To run these
sample applications on the sAMX8 target requires the user to stop the watchdog deamon service so that the
/dev/watchdog is released by the service and acquired by the user applications given in the below directory
Watchdog Reset Test
The sample user space application is located in the file system path given below. The sample application uses the
IOCTL calls to set the Watchdog timeout using the
Note: It is important to make sure the watchdog service is inactive before trying to perform watchdog reset test. When
you perform watchdog reset test and the watchdog service is active already then you get and error message " device
busy error " There are two possible scenarios, each one is explained below.
Scenario 1 – Running the test applications before the watchdog service starts
1.
This scenario is applicable in SMARC SAMX8 BSP case before 1 minute of FS mounting and OS services
start when the watchdog daemon has still not started
2.
Enter the below command and ensure that the watchdog service is inactive
# systemctl status watchdog
Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; vendor preset>
Active: inactive (dead)
3.
Now run the watchdog tests as below and confirm that you are not getting device busy error and device
resets as expected
# cd /unit_tests/Watchdog
# ./wdt_driver_test.out 5 10 0 &
Note: Here timeout=5 secs, Refresh Rate=10secs, 0-signifies IOCTL call
# cd /unit_tests/kontron/watchdog/
# ./wdt_pretimeout_test.out 5 2 10 0
Note: Here timeout=5 secs, Pre-timeout =2secs, Refresh Rate=10secs, 0-signifies IOCTL call
Scenario 2 – Running the test applications after the watchdog service starts
1.
This scenario is applicable if you want to run the watchdog application tests after the watchdog service
has started. This is approx. after a minute of system booting
www.kontron.com
WDIOC_SETTIMEOUT
(or)
Kontron SMARC-sAMX8 - Rev. 1.2
parameter
// 64
Advertisement
Table of Contents
