Find device is boot up by watchdog timer!

Software summary

Bootloader: U-Boot
Kernel version: 5.4.193-5.7.1-devel+git.1895b0052289 (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP PREEMPT Mon Sep 25 08:49:04 UTC 2023
Kernel command line: root=PARTUUID=900ce727-02 ro rootwait console=tty1 console=ttymxc2,115200 consoleblank=0 earlycon
Distro name: Not known
Distro version: Not known
Hostname: verdin-imx8mp-tf3-controller-07011727

Hardware info

HW model: Toradex Verdin iMX8MP Q 4GB WB IT
Toradex version: V1.0C
BSP version 5.7.2
Processor arch: Arm

I am working on watchdog timer in verdin iMX8MP Q 4GB WB IT and trying to find if device is rebooted by watchdog timer or not.

I referred document provided by tordex on watchdog timer.

Using above reference document, I tried to find boot reason on every re-boot.

Here is the sample code block which I am using to check for re-boot reason.

  watchdog_fd = open("/dev/watchdog", O_RDWR);

  if (watchdog_fd < 0){
     debug_printf(DP_MAIN, DP_ERROR, "%s() Failed to open watchdog.\r\n", __func__);

  ret = 0;
  ret = ioctl(watchdog_fd, WDIOC_GETBOOTSTATUS, &flags);

when I read re-boot reason flags on boot-up then the flag always shows zero 0 value which means power-on reset even. But device is getting reset by watchdog timer and no other reason.

So, My question,
Is there any other API which I am supposed to use or point me to any other reference document to get actual boot up reason for verdin iMX8MP Q 4GB WB IT?

Thank you.

The reset source is displayed by U-Boot as follows:

CPU: i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 56C
Reset cause: POR

You can pass this information to Linux using the method described here.

Hi Team,

We attempted to enable the watchdog at the U-boot level, as shown in the shared link.

However, we get the same reset cause as 0x01 for all types of resets rather than WDT reset (0x10). To confirm behavior, we explored a few different ways, as shown below.

(1) We tried to disable WDT driver in uboot. So that SRSR doesn’t get reset on intialization.
(2) Also we tried to read the reset cause register in SPL stage of U-boot and still we see 0x1 as output.
reset_cause = readl(0x3039005C);
(3) We tried different method to trigger watchdong reset like kernel penic.
echo c > /proc/sysrq-trigger

Is it possible that another event occurred in between the SOC reset, or do we need to verify anything on the hardware side?

Please let us know if you come across a similar issue.

Hi @santosh,
We are looking into the issue. Allow us some time

Hi @santosh ,
Are you using a custom-built image or one of the pre-built ones? Could you also specify the U-Boot version?

Update on this thread.

We thought of the following possibilities and observations.

  1. We discovered that an iMX8MP CPU can activate gpio GPIO1_IO02__WDOG1_WDOG_B when the watchdog is reset.
    The GPIO1_IO02__WDOG1_WDOG_B pin may be linked to the PMIC reset pin. When WDT is engaged, it also toggles GPIO1_IO02__WDOG1_WDOG_B, causing PMIC reset.
    We are unable to confirm this possibility due to limited information regarding the verdin SOM architecture.

  2. We tried to disable the external gpio trigger capabilities in the DTS file as below. However, no changes to reset cause, remained the same POR.

&wdog1 {
/* fsl,ext-reset-output; /
pinctrl-names = “default”; /
pinctrl-0 = <&pinctrl_wdog>; */
status = “okay”;

pinctrl_wdog: wdoggrp {
fsl,pins = <

  1. We found an older open community post with the same issue on Colibri iMX6ULL.
    Colibri iMX6ULL: Watchdog not showing as reset cause.

Was a solution identified in this previous case?

Hello @alex.tx,

We are using custom reference yocto image. Below are the details of setup and BSP versions.

U-boot: U-Boot SPL 2020.04-5.7.5+git.1a13a90766f7
Yocto image: TDX Wayland with XWayland 5.7.1-devel-20240216113226+build.0
Toradex SOM: Verdin iMX8M Plus Quad 4GB Wi-Fi / Bluetooth IT(Rev 1.1).
Carrier board: Dahila carrier board(Rev 1.1).

We also tried with the Pre-build image from toradex and observation was same.

Please let me know if more details required.


Hi @santosh,
You have opened multiple post for the same query.
We have added comments on this post

Could you please specify which exact pre-built image from Toradex you have tried and describe the behavior you observed?

Hello @alex.tx,

We flashed pre-bult image using toradex easy installer. Here are details of flashed image from device console.

Toradex custom yocto Image: Verdin-iMX8MP_Reference-Multimedia-Image TDX Wayland with XWayland 5.7.5+build.27 (dunfell)

We are using below command to trigger watchdog.
echo 1 > /dev/watchdog

Device reset after 1 min due to watchdog reset and we got reset cause as POR on next successive boot.

echo 1 > /dev/watchdog
[  221.428699] watchdog: watchdog0: watchdog did not stop!
=========== Next Boot logs ===============
U-Boot SPL 2020.04-5.7.5+git.1a13a90766f7 (Jan 31 2024 - 17:53:31 +0000)
DDRINFO: start DRAM init
Training FAILED
Dual rank failed, attempting single rank configuration.
DDRINFO: start DRAM init
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from BOOTROM
Find FIT header 0x4803a600, size 969
Need continue download 1024
Download 841216, total fit 842480
NOTICE:  BL31: v2.2(release):toradex_imx_5.4.70_2.3.0-g2fa8c6349e
NOTICE:  BL31: Built : 12:30:42, May 17 2022
U-Boot 2020.04-5.7.5+git.1a13a90766f7 (Jan 31 2024 - 17:53:31 +0000)
CPU:   i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 58C
Reset cause: POR
DRAM:  4 GiB
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial

You’re correct; the watchdog reset is performed by toggling the GPIO1_IO02 line, which is connected to the WDOG_B input of the on-module PCA9540 PMIC, handling system resets. This results in both cold boot and WD reset scenarios causing the SOC’s SRSR register to report the same reset cause, which is Power-On Reset (POR).To identify a WD reset, I recommend reading the PWRON_STAT register of the PCA9540 PMIC.

This PMIC, sharing the same I2C bus with onboard EEPROM, RTC, and ADC, and connected to the I2C1_SCL/SDA balls of the iMX8MP SOC, with an I2C address of 0x25.

@alex.tx Thank you for response. I will try as you mentioned and let you know about findings.

Hi @alex.tx

Thank you for sharing the information. As per your recommendation, I read the PMIC register via I2C and got a value of 0x40 in the event of a watchdog reset. However, we have to forcefully read this register with the command (i2cget -f 0 0x25 5).

root@verdin-imx8mp:~# i2cget -f 0 0x25 5
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x25, data address
0x05, using read byte data.
Continue? [Y/n] y

When using standard system calls to open/read from the application layer, we get the following error: Device or resource busy in i2c_dev_open() detected. As the PMIC controller using this slave.

So, is it recommended to read registers using other API calls? Or can we unload a specific kernel module to accomplish this?

Hi @santosh,

The i2cget is always print that warning considering that " I2C and SMBus are designed in such a way that an SMBus read transaction can be seen as a write transaction by certain chips. This is particularly true if setting mode to cp (write byte/read byte with PEC)."

Could you please clarify which exactly “standard system calls” you are using ? The i2cget is also using the standard system calls , does it generate same error meassges?

You can try to use the same API as i2cget or modify the PCA9450 driver to read and report required data.

Hi @alex.tx
I am using open(), read() system call to open and read the value using i2c.
Yes, it generate a same warning when normal i2cget command run.

root@verdin-imx8mp-:~# i2cget 0 0x25 5
Error: Could not set address to 0x25: Device or resource busy.

But when forcefully read (i2cget -f 0 0x25 5) the value then it gives a value.

root@verdin-imx8mp:~# i2cget -f 0 0x25 5
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x25, data address
0x05, using read byte data.
Continue? [Y/n] y

For modifying PCA9450 driver point, I will check and let you know if find something.
Thank you.

It sounds strange. The open() function shouldn’t return an error if you are using the correct file name. Actually, i2cget uses the same open() function, and if it fails, you should see an error message. The error message you’re referring to, 'Device or resource busy,’ appears later when i2cget tries to set a device address, and the system reports that the address is already bound to some device. Then, it can use the ‘I2C_SLAVE_FORCE’ flag to set a slave address, even if it’s bonded. To read data, you should use i2c_smbus_read_byte(). I’d recommend inspecting the i2cget source code for more details. You can also look at a simpler example.

Hi @alex.tx

As per your input I try to read value using I2C_SLAVE_FORCE flag in ioctl command But it gives random value. So I tried to read register value with different approach.
Approach: I read the PMIC register file (/sys/class/i2c-dev/i2c-0/device/0-0025/pca9450-pmic/registers) and get the value of 0x05 register. After watchdog reset when I read 0x05 register value from file it gives a 0x40 which is watchdog reset. However when I try to reset the device using software using command line (using reboot cmd) then also it gives a 0x40 value. So why same value when doing software reset and watchdog reset?
Thank you.

Because software resets are done the same way as a watchdog reset.