i.MX8MP Reset Cause: POR

[GrzesiakLu]

Hi again!
My edm-g-imx8mp board is exhibiting weird behavior where after each reset using RESET button, the board stops loading the kernel after approx. 5s and restarts itself to start the booting process anew. This behaviour is shown below:

[  OK  ] Mounted Temporary Directory (/tmp).
[  OK  ] Started Load Kernel Modules.
[  OK  ] Started Remount Root and Kernel File Systems.
         Mounting Kernel Configuration File System...
         Starting Flush Journal to Persistent Storage...
[    4.801514] systemd-journald[249]: Received client request to flush runtime journal.
         Starting Apply Kernel Variables...
         Starting Create Static Device Nodes in /dev...
[  OK  ] Mounted Kernel Configuration File System
U-Boot SPL 2020.04-235350493ba888d2340e29b6ec942314f2792761+g235350493b (Jun 11 2021 - 07:21:49 +0000)
dram_init: LPDDR4 4GB
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from BOOTROM
image offset 0x0, pagesize 0x200, ivt offset 0x0
NOTICE:  BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
NOTICE:  BL31: Built : 14:13:40, Apr  7 2021


U-Boot 2020.04-235350493ba888d2340e29b6ec942314f2792761+g235350493b (Jun 11 2021 - 07:21:49 +0000)

CPU:   i.MX8MP[8] rev1.1 1800 MHz (running at 1200 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 42C
Reset cause: POR
Model: TechNexion EDM-G-IMX8MP
DRAM:  4 GiB
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
Can't find cec device id=0x3c
[*]-Video Link 1probe video device failed, ret -2

This also happens when issuing command "reboot" from Linux terminal or command "boot" or "bootm" from U-boot command line.The cause for the reset is always reported as POR as shown below:

U-Boot 2020.04-235350493ba888d2340e29b6ec942314f2792761+g235350493b (Jun 11 2021 - 07:21:49 +0000)

CPU:   i.MX8MP[8] rev1.1 1800 MHz (running at 1200 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 42C
Reset cause: POR
Model: TechNexion EDM-G-IMX8MP

 It seems to me that some sort of watchdog can be a possible source of the error, but I am unable to specify exactly why this behavior is happening.

Is there some sort of register I can read at boot-up to determine the cause of the reset?
Should I look for answer in U-boot source repository or somewhere else?

Thanks in advance!

[igorpadykov]

Hi Lukasz

reason for such behaviour is that reset on i.MX8M Plus EVK board is implemented

with  GPIO1_IO02, # CPU WDOG_B Reset U6C (pmic PCA9450CHN) on SPF-46368 schematic

i.MX 8M Plus LPDDR4 EVK Compute Module Design Files

so pmic resets whole board.

Best regards
igor

[GrzesiakLu]

How can I then disable the WATCHDOG and is it recommended? I found in the compilation log for the do_compile() task of the recipe that make is being invoked on /git/drivers/watchdog directory. I have however limited experience with make and am unable to determine which .c source files are being compiled and later linked.

I found the imx_watchdog.c file where the watchdog reset can be disabled via

#if !defined(CONFIG_IMX_WATCHDOG) || \
    (defined(CONFIG_IMX_WATCHDOG) && !CONFIG_IS_ENABLED(WDT))
void __attribute__((weak)) reset_cpu(ulong addr)
{
	struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;

	imx_watchdog_expire_now(wdog, true);
}
#endif

#if defined(CONFIG_IMX_WATCHDOG)
static void imx_watchdog_reset(struct watchdog_regs *wdog)
{
#ifndef CONFIG_WATCHDOG_RESET_DISABLE
	writew(0x5555, &wdog->wsr);
	writew(0xaaaa, &wdog->wsr);
#endif /* CONFIG_WATCHDOG_RESET_DISABLE*/
}

However when inspecting the edm-g-imx8mp_defconfig file I am unable to find either of the two symbols.

I attach the exert from output of Yocto do_compile() task.

make -f /home/lg/edm_yocto2/build-xwayland-edm-g-imx8mp/tmp/work/edm_g_imx8mp-poky-linux/u-boot-tn-imx/2020.04-r0/git/scripts/Makefile.build obj=fs/fat
make -f /home/lg/edm_yocto2/build-xwayland-edm-g-imx8mp/tmp/work/edm_g_imx8mp-poky-linux/u-boot-tn-imx/2020.04-r0/git/scripts/Makefile.build obj=drivers/video

make -f /home/lg/edm_yocto2/build-xwayland-edm-g-imx8mp/tmp/work/edm_g_imx8mp-poky-linux/u-boot-tn-imx/2020.04-r0/git/scripts/Makefile.build obj=drivers/video
make -f /home/lg/edm_yocto2/build-xwayland-edm-g-imx8mp/tmp/work/edm_g_imx8mp-poky-linux/u-boot-tn-imx/2020.04-r0/git/scripts/Makefile.build obj=drivers/watchdog

make -f /home/lg/edm_yocto2/build-xwayland-edm-g-imx8mp/tmp/work/edm_g_imx8mp-poky-linux/u-boot-tn-imx/2020.04-r0/git/scripts/Makefile.build obj=drivers/watchdog
.
.
.
aarch64-poky-linux-ld.bfd     -r -o drivers/built-in.o drivers/clk/built-in.o drivers/core/built-in.o drivers/sysreset/built-in.o drivers/firmware/built-in.o drivers/input/built-in.o drivers/led/built-in.o drivers/mtd/built-in.o drivers/pinctrl/built-in.o drivers/adc/built-in.o drivers/ata/built-in.o drivers/block/built-in.o drivers/cache/built-in.o drivers/crypto/built-in.o drivers/fastboot/built-in.o drivers/misc/built-in.o drivers/mmc/built-in.o drivers/dfu/built-in.o drivers/phy/allwinner/built-in.o drivers/phy/marvell/built-in.o drivers/rtc/built-in.o drivers/scsi/built-in.o drivers/sound/built-in.o drivers/spmi/built-in.o drivers/video/built-in.o drivers/watchdog/built-in.o drivers/mailbox/built-in.o drivers/memory/built-in.o drivers/pwm/built-in.o drivers/reset/built-in.o drivers/smem/built-in.o drivers/soc/built-in.o drivers/thermal/built-in.o drivers/axi/built-in.o drivers/ufs/built-in.o 

[igorpadykov]

>How can I then disable the WATCHDOG and is it recommended?..

sorry it is not recommended, as other reset options are not reliable.

Best regards
igor

[GrzesiakLu]

Since it isn't recommended to disable the watchdog as the last resort I have attempted to add
CONFIG_WATCHDOG_RESET_DISABLE=y as the last line to the /git/configs/edm-g-imx8mp_defconfig file. This seemed to not have the desired effect i.e no Reset after 5s on boot-up.

However adding
#define CONFIG_WATCHDOG_RESET_DISABLE

to the /git/drivers/watchdog/imx-watchdog.c seemed to solve the issue as I am able to reset the device from Linux terminal via reboot, U-boot command line via boot and using Reset button without the second reset happening after approx. 5s.

Can you provide me with an explanation as to why this seems to have "fixed" the issue?

[igorpadykov]

>Can you provide me with an explanation as to why this seems to have "fixed" the issue?

this may work in some cases and not work in another or other uboot/linux versions.

Most reliable option - reset all board as it is done in EVK design.

Best regards
igor

[GrzesiakLu · Accepted solution]

After some time-off from the apparent "issue" I was experiencing I noticed that the "issue" where the watchdog triggers another reset isn't an issue at all, but works like intended.

Issuing "reboot" command int the Linux command line causes the board to immediately reset. This in turn triggers the watchdog causing it to trigger second reset of the whole board as is intended. This can be observed in the snippet below.

[  372.141092] watchdog: watchdog0: watchdog did not stop!
[  372.152508] printk: systemd-shutdow: 29 output lines suppressed due to ratelimiting
[  372.169224] systemd-shutdown[1]: Syncing filesystems and block devices.
[  372.176077] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[  372.191116] systemd-journald[250]: Received SIGTERM from PID 1 (systemd-shutdow).
[  372.250942] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[  372.264988] systemd-shutdown[1]: Hardware watchdog 'imx2+ watchdog', version 0
[  372.274288] systemd-shutdown[1]: Unmounting file systems.
[  372.281637] [446]: Remounting '/' read-only in with options '(null)'.
[  372.301065] EXT4-fs (mmcblk2p3): re-mounted. Opts: (null)
[  372.314362] systemd-shutdown[1]: All filesystems unmounted.
[  372.320057] systemd-shutdown[1]: Deactivating swaps.
[  372.325157] systemd-shutdown[1]: All swaps deactivated.
[  372.330393] systemd-shutdown[1]: Detaching loop devices.
[  372.338004] systemd-shutdown[1]: All loop devices detached.
[  372.349374] kvm: exiting hardware virtualization
[  372.430904] imx2-wdt 30280000.watchdog: Device shutdown: Expect reboot!
[  372.438176] reboot: Restarting system

 Issuing the command " shutdown now" in the command line does not trigger the watchdog. This is shown below.

        Unmounting /boot...
         Unmounting Temporary Directory (/tmp)...
         Unmounting /var/volatile...
[  OK  ] Unmounted /boot.
[  OK  ] Unmounted Temporary Directory (/tmp).
[  OK  ] Unmounted /var/volatile.
[  OK  ] Stopped target Local File Systems (Pre).
[  OK  ] Stopped target Swap.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Reached target Shutdown.
[  OK  ] Reached target Final Step.
[  OK  ] Started Power-Off.
[  OK  ] Reached target Power-Off.
[ 2027.563379] printk: systemd-shutdow: 30 output lines suppressed due to ratelimiting
[ 2027.581936] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 2027.596956] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[ 2027.612047] systemd-journald[252]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 2027.674852] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[ 2027.692219] systemd-shutdown[1]: Unmounting file systems.
[ 2027.698994] [512]: Remounting '/' read-only in with options '(null)'.
[ 2027.718658] EXT4-fs (mmcblk2p3): re-mounted. Opts: (null)
[ 2027.742516] systemd-shutdown[1]: All filesystems unmounted.
[ 2027.748113] systemd-shutdown[1]: Deactivating swaps.
[ 2027.753208] systemd-shutdown[1]: All swaps deactivated.
[ 2027.758446] systemd-shutdown[1]: Detaching loop devices.
[ 2027.765848] systemd-shutdown[1]: All loop devices detached.
[ 2027.771466] systemd-shutdown[1]: Detaching DM devices.
[ 2027.787393] kvm: exiting hardware virtualization
[ 2027.861154] reboot: Power down

In other words it was my oversight that was the root of my issues. No changes need to be done to the imx_watchdog.c file of /drivers/watchdog/ directory and CONFIG_IMX_WATCHDOG and CONFIG_WATCHDOG_RESET_DISABLE aren't necessary.

Hope this clears up some confusion.