AM623: Reset reason not available in SDK

Leonardo Dutra

Part Number: AM623

Tool/software:

Hello,

I'm currently working with a AM623 based board running the processor sdk Linux RT version 11.00.09.04. I need to have access to the information of when the last reset was caused by watchdog and, in my research, I found this feature that the rti_wdt driver provides, which is the bootstatus, but it seems it is not available in my OS. I would like to know that should I do to have it enabled so I can have access to the reset reason via Linux.

4 months ago

0 Nick Saulnier 4 months ago

TI__Guru** 101410 points

Hello Leonardo,

Apologies for the delayed response here. I will set aside some time on Thursday to look into this.

Regards,

Nick

0 Leonardo Dutra 4 months ago in reply to Nick Saulnier

Prodigy 40 points

Hello, Nick. No problem! Also, if you could provide me an image of the processor linux sdk (RT) containing this feature enabled so I can test it with my development kit, I would appreciate it.

0 Nick Saulnier 4 months ago in reply to Leonardo Dutra

TI__Guru** 101410 points

Hello Leonardo,

Watchdog driver code

I assume you are referring to this part of the rti_wdt_probe function:

        node = of_parse_phandle(pdev->dev.of_node, "memory-region", 0);
        if (node) {
...
                /*
                 * If reserved memory is defined for watchdog reset cause.
                 * Readout the Power-on(PON) reason and pass to bootstatus.
                 */
                paddr = res.start;
                reserved_mem_size = resource_size(&res);
...
                vaddr = memremap(paddr, reserved_mem_size, MEMREMAP_WB);
                if (!vaddr) {
                        dev_err(dev, "Failed to map memory-region.\n");
                        ret = -ENOMEM;
                        goto err_iomap;
                }

                if (vaddr[0] == PON_REASON_SOF_NUM &&
                    vaddr[1] == PON_REASON_MAGIC_NUM &&
                    vaddr[2] == PON_REASON_EOF_NUM) {
                        wdd->bootstatus |= WDIOF_CARDRESET;
                }
                memset(vaddr, 0, reserved_mem_size);
                memunmap(vaddr);

and the memory-region defined in the bindings documentation:
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml?h=ti-linux-6.12.y#n37

So... This is going to take a bit of time to look into. At a glance, I do not actually see how this arbitrary memory allocation in DDR would work.

First off, in the probe function we can see that the driver is only looking for 12 specific bytes that are supposed to indicate a watchdog reset. bootstatus is not updated if there are any other values in the memory region. So it would only be able to say if a watchdog reset occurred, not any other reset source.

But some other driver code would need to know that the user allocated that specific DDR region to hold a reset value, and then write the 12 magic bytes to the DDR region during a watchdog reset event. I do not see that memory region getting used anywhere, so I do not know how those 12 bytes would even get written to DDR in the first place.

I could be missing something. I am reaching out to some other team members for ideas.

Other options for seeing reset reason

Does this section from the TRM describe the functionality you are looking for?

"Reset Source Status Registers"
register CTRLMMR_MCU_RST_SRC

Regards,

Nick

0 Leonardo Dutra 4 months ago in reply to Nick Saulnier

Prodigy 40 points

Hello Nick,

Regarding the CTRLMMR_MCU_RST_SRC register, I've read about it in some AM62x docs, but its configuration is not clear to me. Could you explain how it can be configured in a custom u-boot and kernel environment to indicate a watchdog reset?

0 Nick Saulnier 4 months ago in reply to Leonardo Dutra

TI__Guru** 101410 points

Hello Leonardo,

I am going to start by posting screenshots of the associated registers, since the registers have different names in different places in the TRM, and they are not easy to find. I have filed a bug against the TRM to see if there is a way we can improve this structure.

0 Nick Saulnier 4 months ago in reply to Nick Saulnier

TI__Guru** 101410 points

Hello Leonardo,

No configuration of the register is required for the register to record the reboot reason. However, every time a warm reset happens, the new reset source is simply added to the register (instead of erasing the previous reset reason, and THEN putting the new reset reason into the register). So it is suggested to manually clear the register after you read it.

Test 1: Do the bits in the 2 registers match?

yes

Test 2: Do the bits update after a warm reset? What happens after a 2nd warm reset?

Yes, the bits update after a warm reset. If there is a 2nd warm reset, then the 2nd reset source is simply added to the previous reset source (i.e., the registers are not "cleared" and then re-set every warm reset).

root@am62xx-evm:~# uname -a
Linux am62xx-evm 6.6.58-rt45-ti-rt-01780-gc79d7ef3a56f-dirty #1 SMP PREEMPT_RT Wed Nov 27 14:15:26 UTC 2024 aarch64 GNU/Linux

// Let's check the register value after a cold boot (should be 0)
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffffa1fe9000.
Read at address  0x04518178 (0xffffa1fe9178): 0x00000000

// now let's do a software reboot and see what happens
root@am62xx-evm:~# reboot
...
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffffa3b2c000.
Read at address  0x04518178 (0xffffa3b2c178): 0x00010000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffb0bf1000.
Read at address  0x43018178 (0xffffb0bf1178): 0x00010000

// now let's do a watchdog reset
root@am62xx-evm:~# echo 1 > /dev/watchdog
[  482.720093] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[  482.720138] watchdog: watchdog0: watchdog did not stop!
root@am62xx-evm:~#
U-Boot SPL 2024.04-ti-g29d0c23d67ee (Nov 29 2024 - 11:41:54 +0000)
...
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffffad4c5000.
Read at address  0x04518178 (0xffffad4c5178): 0xC0010000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffff82422000.
Read at address  0x43018178 (0xffff82422178): 0xC0010000

Test 3: Can we clear the bits during runtime?

Yes. The TRM register definitions tell us that

CTRLMMR_RST_SRC is read-only, while
CTRLMMR_MCU_RST_SRC will clear a bit if you write a 1 to that bit.

And we can see that here:

// writing to CTRLMMR_RST_SRC does not change the bits
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffff9fe7d000.
Read at address  0x43018178 (0xffff9fe7d178): 0xC0010000
root@am62xx-evm:~# devmem2 0x43018178 w 0x00000000
/dev/mem opened.
Memory mapped at address 0xffff8cb4b000.
Read at address  0x43018178 (0xffff8cb4b178): 0xC0010000
Write at address 0x43018178 (0xffff8cb4b178): 0x00000000, readback 0x00000000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffa0ac5000.
Read at address  0x43018178 (0xffffa0ac5178): 0xC0010000
root@am62xx-evm:~# devmem2 0x43018178 w 0xFFFFFFFF
/dev/mem opened.
Memory mapped at address 0xffffab81a000.
Read at address  0x43018178 (0xffffab81a178): 0xC0010000
Write at address 0x43018178 (0xffffab81a178): 0xFFFFFFFF, readback 0xFFFFFFFF
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffabb8b000.
Read at address  0x43018178 (0xffffabb8b178): 0xC0010000

// writing 1s to CTRLMMR_MCU_RST_SRC will clear the bits
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffff81fdb000.
Read at address  0x04518178 (0xffff81fdb178): 0xC0010000
root@am62xx-evm:~# devmem2 0x4518178 w 0xFFFFFFFF
/dev/mem opened.
Memory mapped at address 0xffffb356a000.
Read at address  0x04518178 (0xffffb356a178): 0xC0010000
Write at address 0x04518178 (0xffffb356a178): 0xFFFFFFFF, readback 0xFFFFFFFF
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffff8e00f000.
Read at address  0x04518178 (0xffff8e00f178): 0x00000000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffafeb0000.
Read at address  0x43018178 (0xffffafeb0178): 0x00000000

Regards,

Nick

0 Nick Saulnier 4 months ago in reply to Nick Saulnier

TI__Guru** 101410 points

Some additional information that might be interesting for you is here:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1507829/am62a7-q1-is-the-am62a-sdk-set-up-to-use-the-power-on-memory-region-referenced-in-the-watchdog-driver/5827256#5827256

0 Leonardo Dutra 4 months ago in reply to Nick Saulnier

Prodigy 40 points

Hello Nick,

Thank you for this research. I could reproduce this behavior in my development kit. The thing is that I also tested it in my custom board based on the AM623 processor and the 0x4518178 register stays the same even after a software reset and a watchdog reset. This board runs u-boot version 2023.10 and linux kernel version 6.1.69-rt21. Perhaps there's a configuration or driver that is not properly set?

Regards

0 Nick Saulnier 4 months ago in reply to Leonardo Dutra

TI__Guru** 101410 points

Hello Leonardo,

Can you please show me what you mean by "the 0x4518178 register stays the same even after a software reset and a watchdog reset"?

Regards,

Nick

0 Leonardo Dutra 4 months ago in reply to Nick Saulnier

Prodigy 40 points

Hello, Nick

Sorry if I wasn't clear. What I mean is that the MCU_MMR0_RST_SRC register, located at address 0x04518178, does not update its value when I perform the same test you did (software reset and watchdog reset), but in my custom board with the firmware mentioned above.

Regards

0 Nick Saulnier 4 months ago in reply to Leonardo Dutra

TI__Guru** 101410 points

Hello Leonardo,

If you can show me the exact tests that you ran, and the exact terminal output when reading the address, that is a lot more helpful than verbally describing it. I have seen a lot of these issues that went on for weeks longer than they should have because someone didn't just share the terminal output.

Obviously no need to show your entire boot log, but please share at least your terminal inputs and the specific register reads and writes before and afterwards.

Thanks,

Nick

0 Leonardo Dutra 4 months ago in reply to Nick Saulnier

Prodigy 40 points

Hello, Nick

Of course. The only difference in my tests is that I ran it using devmem, not devmem2. But they should behave in the exact same way. The tests are as below:

// After a cold boot:
device:~# uname -a
Linux device 6.1.69-rt21 #3 SMP PREEMPT_RT Tue May 20 08:56:29 -03 2025 aarch64 GNU/Linux

device:~# devmem 0x4518178
0x00000000

device:~# reboot
...

// After a warm reset:
device:~# devmem 0x4518178
0x00000000

device:~# devmem 0x43018178
0x00000000

device:~# echo 1 > /dev/watchdog
device:~# [   53.989131] watchdog: watchdog0: watchdog did not stop!

U-Boot SPL 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)
...

// After a watchdog reset:
device:~# devmem 0x4518178
0x00000000

device:~# devmem 0x43018178
0x00000000

Regards

0 Leonardo Dutra 3 months ago in reply to Leonardo Dutra

Prodigy 40 points

Hello, Nick

Replying again just to know if you got any progress regarding this situation

Regards

0 Mukul Bhatnagar 3 months ago in reply to Leonardo Dutra

TI__Guru* 83965 points

Hello Leanardo

We regret the delay on responding to this. Nick is currently on international travel this week and will be back in office next week.

We may see some additional delays in responses, but we will prioritize getting back to you early next week.

Regards

Mukul

0 Leonardo Dutra 3 months ago in reply to Mukul Bhatnagar

Prodigy 40 points

Hello, Mukul

Alright, no problem. I'll be waiting for the next reply. Thank you.

Regards,

Leonardo

0 Hong Guan64 3 months ago in reply to Leonardo Dutra

TI__Guru 68760 points

Hello Leanardo,
Let me add my input while Nick is out of office.
I'm attaching a sample log I captured previously with Linux SDK 8.6 on AM62-SK board.
Can we run similar test @u-boot on your board?
1/. cmds @u-boot to fire off RTI_WDT RTI0 to count-down (~1s timeout)
=> mw.l 0xe0000a4 0xa 1
=> mw.l 0xe000090 0xA98559DA 1
2/. CTRLMMR registers on RST_CTRL/RST_STAT/RST_SRC for main & mcu domain are captured in the attached log => which shows "RTI_WDT timeout => MCU ESM error => WarmReset" works @u-boot level.

Best,
-Hong

Fullscreen am62_8.6_rti_wdt_1s_FS.log Download

�
U-Boot SPL 2021.01-g2ee8efd654 (Feb 24 2023 - 05:59:23 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Loading Environment from MMC... *** Warning - No MMC card found, using default environment

Starting ATF on ARM64 core...

NOTICE:  BL31: v2.8(release):v2.8-226-g2fcd408bb3-dirty
NOTICE:  BL31: Built : 05:06:58, Feb 24 2023

U-Boot SPL 2021.01-g2ee8efd654 (Feb 24 2023 - 05:29:33 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
Trying to boot from MMC2
Authentication passed
Authentication passed


U-Boot 2021.01-g2ee8efd654 (Feb 24 2023 - 05:29:33 +0000)

SoC:   AM62X SR1.0 HS-FS
Model: Texas Instruments AM625 SK
EEPROM not available at 0x50, trying to read at 0x51
Board: AM62-SKEVM rev E1
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  2  0 
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000             ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000             ..@.........
=> mw.l 0xe0000a4 0xa 1
=> mw.l 0xe000090 0xA98559DA 1
=> 
U-Boot SPL 2021.01-g2ee8efd654 (Feb 24 2023 - 05:59:23 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Loading Environment from MMC... *** Warning - No MMC card found, using default environment

Starting ATF on ARM64 core...

NOTICE:  BL31: v2.8(release):v2.8-226-g2fcd408bb3-dirty
NOTICE:  BL31: Built : 05:06:58, Feb 24 2023

U-Boot SPL 2021.01-g2ee8efd654 (Feb 24 2023 - 05:29:33 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
Trying to boot from MMC2
Authentication passed
Authentication passed


U-Boot 2021.01-g2ee8efd654 (Feb 24 2023 - 05:29:33 +0000)

SoC:   AM62X SR1.0 HS-FS
Model: Texas Instruments AM625 SK
EEPROM not available at 0x50, trying to read at 0x51
Board: AM62-SKEVM rev E1
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  2  0 
=> md.l 0x43018170 3
43018170: 000200ff 00000000 c0000000             ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 c0000000             ..@.........
=>

0 Swargam Anil 3 months ago in reply to Hong Guan64

TI__Mastermind 46756 points

Hello Leanardo,

The WDT SOC Reset can be done through the ESM module.

If the reset is through ESM then it will be indicated in mcu_esm_err_rst or main_esm_err_rst.

If you control the MAIN Domain ESM bits to Reset the SOC, then monitor the MAIN ESM Error bits (30th bit position ) and if you control the MCU Domain ESM bits to Reset the SOC, then monitor the MCU MMR Error bits (31th bit position ) .

Regards,

Anil.

0 Leonardo Dutra 3 months ago in reply to Hong Guan64

Prodigy 40 points

Hello Hong,

I'm attaching the logs capture both in a development kit running the processor sdk Linux RT version 11.00.09.04 (first attached) and in my custom board running U-boot 2023.10 and Linux kernel 6.1.69 rt 21 (last attached)

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)')
Changed A53 CPU frequency to 1250000000Hz (T grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.08-1-gb11beb2b6-dirty
NOTICE:  BL31: Built : 12:35:58, Mar 24 2025

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: 1952 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device


U-Boot 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
DRAM:  2 GiB
Core:  83 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@8000000port@1

Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000           ..@.........
=> mw.l 0xe0000a4 0xa 1
=> mw.l 0xe000090 0xA98559DA 1
=>
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)')
Changed A53 CPU frequency to 1250000000Hz (T grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.08-1-gb11beb2b6-dirty
NOTICE:  BL31: Built : 12:35:58, Mar 24 2025

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: 1952 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device


U-Boot 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
DRAM:  2 GiB
Core:  83 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@8000000port@1

Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 c0000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 c0000000           ..@.........
=>

U-Boot SPL 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 1792 bytes
Trying to boot from MMC1
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted


U-Boot 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)

SoC:   AM62X SR1.0 GP
Model: XF325
DRAM:  2 GiB
Core:  78 devices, 24 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... OK
In:    serial@2830000
Out:   serial@2830000
Err:   serial@2830000
Net:   eth0: ethernet@8000000port@1, eth1: ethernet@8000000port@2
Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000           ..@.........
=> mw.l 0xe0000a4 0xa 1
=> mw.l 0xe000090 0xA98559DA 1
=>
U-Boot SPL 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 1792 bytes
Trying to boot from MMC1
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted


U-Boot 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)

SoC:   AM62X SR1.0 GP
Model: XF325
DRAM:  2 GiB
Core:  78 devices, 24 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... OK
In:    serial@2830000
Out:   serial@2830000
Err:   serial@2830000
Net:   eth0: ethernet@8000000port@1, eth1: ethernet@8000000port@2
Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000           ..@.........
=>

If you could help me interpret these register values and what could be wrong, I'd appreciate it.

Regards,

Leonardo

0 Leonardo Dutra 3 months ago in reply to Swargam Anil

Prodigy 40 points

Hello Swargam,

Is there any particular configuration I'd have to perform in my custom board in order to make the ESM module route to the RTI_WDT? Because I've already monitored the bits of the register and could not see any indication that the ESM was triggered. Perhaps some U-boot configuration or device tree should be adjusted?

Regards,

Leonardo

0 Hong Guan64 3 months ago in reply to Leonardo Dutra

TI__Guru 68760 points

Hello Leonardo,
From the u-boot log on your board, WARMRESET from RTI_WDT timeout (~1s) happened, is my understand correct?

The reference log
=> md.l 0x43018170 3
43018170: 000200ff 00000000 c0000000 ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 c0000000 ..@.........

But the log on your board
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000 ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000 ..@.........

RST_SRC[31:30] @0x43018178 & @0x0x04518178 are not SET or cleared somehow?

This is how ESM is configured in R5-SPL
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/arch/arm/mach-k3/am625_init.c?h=09.01.00.008&id=169582025adc8892ec0813f52f6d643055b3e9dc
I'd recommend cross-check the u-boot porting you customized for your board.

Best,
-Hong

0 Leonardo Dutra 3 months ago in reply to Hong Guan64

Prodigy 40 points

Hello Hong,

You're correct that the board does reboot after enabling the watchdog, which suggests some reset or interrupt reaction is indeed happening. However, the RST_SRC[31:30] values at 0x43018178 and 0x04518178 remain 0x00000000, unlike the reference case (0xC0000000).

Additionally, I've confirmed that the R5 SPL on my board did not have the CONFIG_ESM_K3 enabled. However, the commit you attached and the code itself mention an expected device tree node for enabling the ESM module, which appears to be missing in my source code. What is expected to be defined in this node? Is there any documentation or example available that I could use as a reference?

Regards,

Leonardo

0 Hong Guan64 3 months ago in reply to Leonardo Dutra

TI__Guru 68760 points

Hello Leonardo,
Here're the ESM reference on *defconfig and dts for AM62x-SK board
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/configs/am62x_evm_r5_defconfig?h=09.01.00.008&id=25c7b65d176715d911ebb4b2029606b678d6d56a
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/arch/arm/dts/k3-am625-r5-sk.dts?h=09.01.00.008&id=3128c890f2715f5e73300d67edff2bd26865740d
Best,
-Hong

0 Leonardo Dutra 3 months ago in reply to Hong Guan64

Prodigy 40 points

Hello Hong,

Thank you for your support so far. Sorry for the late response. I've applied these configurations for enabling the ESM module, but I realized my custom board is not booting anymore due to the recent compilations of the tiboot3.bin. Apparently there's nothing wrong in my u-boot repository, but the board refuses to boot and does not print anything to the uart console when it is loaded with the new tiboot3.bin. I have access to older versions of this binary file that work fine, but not its source code. Could you point me what are some steps I should take to debug this situation? Perhaps you could provide me a compiled R5F bootloader (tiboot3.bin) with the proper ESM configurations applied?

Also, I've already followed the guide described in this page

Regards,

Leonardo

0 Hong Guan64 3 months ago in reply to Leonardo Dutra

TI__Guru 68760 points

Hello Leonardo,
The boot log on your board looks indicatiung it is AM62x GP on your board.
Please refer to this link on how to use the matching "tiboot3.bin" for the device type variant (GP/HS-FS/HS-SE)
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components_Migration_Guide.html
Best,
-Hong

0 Leonardo Dutra 3 months ago in reply to Hong Guan64

Prodigy 40 points

Hello Hong,

I figured out what was the problem with the tiboot3.bin and was able to fix it to make my custom board boot again. However, I executed the tests in the u-boot environment again with the proper configurations in the defconfig and device tree, as described in the commits you sent me, and it was not effective. The results are the same as before.

Regards,

Leonardo

0 Hong Guan64 3 months ago in reply to Leonardo Dutra

TI__Guru 68760 points

Hello Leonardo,
I'm not sure what might be missing on your setup. The default SDK works on TI reference board.
1/. Which SDK version is used in your setup?
2/. Have we checked the u-boot binary running on your board is what you built with the u-boot ESM configurations?
Best,
-Hong

0 Leonardo Dutra 3 months ago in reply to Hong Guan64

Prodigy 40 points

Hello, Hong,

Actually I do use the SDK 11.00.09.04 for the tests running on the development kit, but my custom board, which ESM module does not work properly, uses custom firmware. The used bootloader is ti-u-boot-2023.10, kernel is linux 6.1.69 and the firmware image is built using buildroot-2023.08. bootloader and kernel were downloaded from TI open source git repositories.

Regards,

Leonardo

0 Hong Guan64 3 months ago in reply to Leonardo Dutra

TI__Guru 68760 points

Hello Leonardo,
Is it possible to build u-boot from the Linux SDK instead of buildroot, and run it on your HW?
Best,
-Hong

Processors

Processors forum

AM623: Reset reason not available in SDK