topic Re: i.MX8MM: wdog: sw reset doesn't work in i.MX Processors

i.MX8MM: wdog: sw reset doesn't work

flaviosuligoi — Mon, 07 Sep 2020 15:28:08 GMT

Hi all,

with the mx8mm-evk, I need to use two wdogs with an important requirement: the possibility to distinguish which wdog causes the reboot.

I've choosen wdog1 and wdog3, since the wdog2 is used for TZ.

So I decided to use wdog1 with hw-reset and wdog3 with sw-reset.

All is ok in u-boot: the sw-reset with wdog3 works. For example I tested it with:

mw.w 302a0000 64

But in Linux it doesn't work; I added the wdog3 in the DT, without the "ext-reset-output", in order to use the sw reset only, but, with the same command as in u-boot, the system hangs, but doesn't reset:

memtool -16 302a0000=64

To reset the board I have to wait the wdog1 timeout (60s) or I have to press the mx8mm-evk reset button.

Any idea about how to enable the sw-reset wdog3 in Linux?

Thanks,

Flavio

Re: i.MX8MM: wdog: sw reset doesn't work

igorpadykov — Tue, 08 Sep 2020 00:50:54 GMT

Hi flaviosuligoi

one can check with oscilloscope if there is toggling signal on GPIO1_IO02,

on SPF-31399 schematic ("CPU WDOG_B Reset for PMIC") it toggles PMIC.

Also there are some wdog configs in General Purpose Register 5 (IOMUXC_GPR_GPR5).

i.MX 8M Mini Evaluation Kit LPDDR4 Design Files

Best regards
igor

Re: i.MX8MM: wdog: sw reset doesn't work

flaviosuligoi — Tue, 08 Sep 2020 07:10:31 GMT

Hi Igor,

thanks for your quick answer, but my problem is not how to reset the board with wdog and hw-reset.

My problem is how to reset the board using the wdog3 and a sw-reset, without any use of WDOG_B pin.

At the moment all is ok with u-boot but not in Linux; in Linux, after the wdog3 timeout, the sw-reset starts but it doesn't work and the system hangs, without any reboot. Ok, after 60 seconds the system resets because of the action of wdog1, with its hw-resets using the WDOG_B signal, but this is not what I want.

I ask this because, after a boot, I need to distinguish between the action of the two POR/hwreset/wdog1 and wdog3 (sw reset).

I hope I have been clearer now.

Thanks,

Flavio

Re: i.MX8MM: wdog: sw reset doesn't work

igorpadykov — Tue, 08 Sep 2020 07:53:29 GMT

Hi Flavio

>how to reset the board using the wdog3 and a sw-reset, without any use of WDOG_B pin.

sorry, I am afraid this is not feasible.

Best regards
igor

Re: i.MX8MM: wdog: sw reset doesn't work

terry_lv — Tue, 08 Sep 2020 08:45:23 GMT

Hi,

I tried and it seems WDOG1 reset it OK, but WDOG3 reset failed..

root@imx8mmevk:~# /unit_tests/memtool -16 0x30280000=0x74
Writing 16-bit value 0x74 to address 0x30280000
root@imx8mmevk:~#
U-Boot SPL 2018.03 (May 29 2020 - 16:00:02 +0800)
power_bd71837_init
DDRINFO: start lpddr4 ddr init
DRAM PHY training for 3000MTS
check ddr4_pmu_train_imem code
check ddr4_pmu_train_imem code pass

From ./arch/arm64/boot/dts/freescale/imx8mm-evk.dts, it seems only wdog1 is enabled. wdog3 is disabled by default.

&wdog1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_wdog>;
fsl,ext-reset-output;
status = "okay";
};

Could you enable wdog3 in dts and have a try?

Thanks!

Regards

Terry

Re: i.MX8MM: wdog: sw reset doesn't work

flaviosuligoi — Tue, 08 Sep 2020 09:22:40 GMT

Hi Igor,

but the sw-reset (without WDOG_B) with wdog3, in u-boot, works good. After the reset, in u-boot, as "reset cause", I read:

Reset cause: WDOG3

Why does it not work in Linux?

Flavio

Re: i.MX8MM: wdog: sw reset doesn't work

flaviosuligoi — Tue, 08 Sep 2020 09:27:48 GMT

Hi Terry,

I have already enabled the wdog3 with the sw-reset, both in u-boot and in Linux kernel).

With u-boot, when the wdog3 timeout expires, the sw-reset works works good.

The problem is that it doesn't work in Linux: with wdog3 (programmed for sw-reset, without using WDOG_B pin), when the wdog3 timeout expires, the system hang immediately, no reset occurs.

Flavio

Re: i.MX8MM: wdog: sw reset doesn't work

igorpadykov — Tue, 08 Sep 2020 13:21:43 GMT

Hi Flavio

yes it may work (like in uboot) and may not work (as in linux).

Reason is that when reset is used with all board power-off/on sequence

all processor modules and external components are placed in predetermined

known state (as in first board power-up). When reset is used without all board reset,

some external components (like emmc, spi-nor e.t.c.) are left in random state.

In some cases if the memory was trying to read memory back to the processor when the SDCLK
was removed, the memory may try to finish the read cycle when the SDCLK is first restored.

So processor can not proceed normally as it expects all modules to be in

some known predefined state (as in first board power-up).

You can try to analyze which peripheral (it may be processor module or external

component) is left in "wrong" state, for example dump all processor registers

and compare it with "good" case.

Best regards
igor