AM62A7-Q1: Watchdog: board doesn't reset when using /dev/watchdog1

Hello Bas,

There are some modifications that you should make to the uboot code if you have not already.

When a watchdog times out, it generates an interrupt to the ESM. The ESM is then in charge of resetting the processor.

We intended to add support for watchdog resetting AM62Ax in SDK 10.0, but that required a fix to the ESM interrupt inputs, and the fix did not make it into either SDK 10.0, or SDK 10.1. Please find the fix here: https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/10_01_00/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Watchdog.html#fixes-for-10-0-sdk

Regards,

Nick

Hi Nick,

Those changes have already been made to my codebase. If I use /dev/watchdog0, it works correctly, but if I try to use /dev/watchdog1 it fails to restart the board. It counts down correctly, but the ESM doesn't trigger a reset like /dev/watchdog0 does.

Regards,

Bas

Another question, is the AM62A platform set up to use the Power-On reason memory region? I need the boot reason in my software, and this would fit the bill.

Regards,

Bas

Any update on this? Still not able to get the other watchdogs to reboot my board.

Hello Bas,

I would like us to check your ESM registers after the watchdog event triggers to see if anything has changed (and also beforehand to make sure the inputs are configured correctly), but off the top of my head I am not sure which registers to look at. Please ping the thread again if I do not respond tomorrow.

Can I get you to create another thread for the question about the power-on memory region? That way that discussion does not get lost in the watchdog thread.

Regards,

Nick

Nick Saulnier,

Pinging the thread, as requested.

Bas

Hello Bas,

ok, did some initial tests.

AM62x SDK 10.1 (sanity check): I was able to reset the board from all 5 watchdog0-watchdog4 instances:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1484145/processor-sdk-am62x-watchdog-issues-on-am62x-custom-board-based-on-am62x-sk-board/5799693#5799693

AM62Ax Linux SDK 11.x internal build (sanity check, should have patches that were not applied in SDK 10.0 & SDK 10.1):  I was able to reset the board from all 5 watchdog0-watchdog4 instances:

root@am62axx-evm:~# echo 1 > /dev/watchdog
watchdog   watchdog0  watchdog1  watchdog2  watchdog3
root@am62axx-evm:~# echo 1 > /dev/watchdog3
root@am62axx-evm:~# [   37.554134] watchdog: watchdog3: nowayout prevents watchdog being stopped!
[   37.554151] watchdog: watchdog3: watchdog did not stop!

root@am62axx-evm:~# uname -a
Linux am62axx-evm 6.12.17-ti-rt-00771-gc85877d40f8e #1 SMP PREEMPT_RT Tue Mar 25 12:45:29 UTC 2025 aarch64 GNU/Linux
root@am62axx-evm:~#
U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
SPL initial stack usage: 13568 bytes
Trying to boot from MMC2
Authentication passed

AM62Ax Linux SDK 10.1:

With zero modifications, I do not get a reset with any of the watchdog instances. 

root@am62axx-evm:/opt/edgeai-gst-apps# uname -a
Linux am62axx-evm 6.6.58-ti-01497-ga7758da17c28-dirty #1 SMP PREEMPT Wed Nov 27 13:23:15 UTC 2024 aarch64 GNU/Linux
root@am62axx-evm:/opt/edgeai-gst-apps# echo 1 > /dev/watchdog
watchdog   watchdog0  watchdog1  watchdog2  watchdog3
root@am62axx-evm:/opt/edgeai-gst-apps# echo 1 > /dev/watchdog3
[   78.373044] watchdog: watchdog3: nowayout prevents watchdog being stopped!
[   78.379936] watchdog: watchdog3: watchdog did not stop!

// watchdog3 does not time out the processor

root@am62axx-evm:/opt/edgeai-gst-apps# echo 1 > /dev/watchdog0
[  180.885081] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[  180.891976] watchdog: watchdog0: watchdog did not stop!

We should definitely be able to use the version of code on ti-linux-kernel and ti-u-boot that will be used for SDK 11.x as a reference, since the internal SDK 11.x build worked fine:
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-6.12.y-cicd
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/?h=ti-u-boot-2025.01 

Regards,

Nick

Hi Nick,

Does 10.1 on AM62A work with the changes to the ESM node from https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/10_01_00/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Watchdog.html#fixes-for-10-0-sdk?

I've just migrated to 10.1, and I'm not 100% sure when I'll get to go to 11.x. I've added the correct ESM irqs from the link above already.

Regards,

Bas

Hello Bas,

Did not have time to do a build and hardware test today.

I spent some time going through the TRM looking for where we can verify the ESM input interrupt configuration. Still figuring out which registers to check.

We have not come out with a public AM62Ax SDK 11 yet, the plan is to release AM62Ax SDK 11.1 in July / August.

Comparing SDK 10.1 & internal SDK 11

ti-u-boot-2025.01 is the version that will be in SDK 11. Off the top of my head, I did not see anything obvious related to ESM or watchdog that was in ti-u-boot-2025.01 and not in ti-u-boot-2024.04.

In ti-u-boot-2025.01 uboot moves shared Linux / uboot devicetree files to dts/upstream/src. So you can find the updated ESM node here:
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/dts/upstream/src/arm64/ti/k3-am62a-main.dtsi?h=ti-u-boot-2025.01#n287

When I search the commit messages for watchdog, ESM, rti I do not see any commits related to AM62* devices that are in 2025.01 but not 2024.04.

Regards,

Nick

The esm nodes I have are:

kernel:

        main_esm: esm@420000 {
                compatible = "ti,j721e-esm";
                reg = <0x0 0x420000 0x0 0x1000>;
                /* Interrupt sources: rti0, rti1, wrti0, rti4, rti2, rti3 */
                ti,esm-pins = <192>, <193>, <195>, <204>, <209>, <210>;
                bootph-pre-ram;
        };

u-boot:

        main_esm: esm@420000 {
                compatible = "ti,j721e-esm";
                reg = <0x0 0x420000 0x0 0x1000>;
                ti,esm-pins = <192>, <192>, <195>, <204>, <209>, <210>;
                bootph-pre-ram;
        };

Which is essentially the same as the node in the link you sent:

	main_esm: esm@420000 {
		compatible = "ti,j721e-esm";
		reg = <0x0 0x420000 0x0 0x1000>;
		bootph-pre-ram;
		/* Interrupt sources: rti0, rti1, wrti0, rti4, rti2, rti3 */
		ti,esm-pins = <192>, <193>, <195>, <204>, <209>, <210>;
	};

So that shouldn't be the problem.

Regards,

Bas Vermeulen

Hello Bas,

Ahh, that's always frustrating. But I am glad to hear that things are now working as expected for you! That frees up some time on my end to take a look at your other thread today or tomorrow. Please keep the pings coming if you don't see another response within a day or so.

Regards,

Nick

I'll be offline for the week, but I'll ping you next week tuesday if there's no response.

Bas