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__);
break;
}
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?
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.
We thought of the following possibilities and observations.
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.
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.
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
DDRINFO: DRAM rate 4000MTS
Training FAILED
Dual rank failed, attempting single rank configuration.
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
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
MMC: FSL_SDHC: 1, FSL_SDHC: 2
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.
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
0x40
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?
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
0x40
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.
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.
