AM62P: AM62P

Hello,

Our expert is out of office this week, please ping this thread if you don't hear a response by next week.

-Daolin

Good morning, 

I can also add that even creating a .restart function in the rti_wdt_ops , then it doesn't start at all.

Setting WATCHDOG_SYSFS and checking the timeleft under the proper watchdogX/timeleft, I can verify that when the the timeleft reach 0, then the myrestart function doesn't start at all.

Thanks and Regards

Lorenzo

Hello Lorenzo,

Thank you for your patience. I am back from vacation.

Good debug. So to verify:

1) you can see the time counting down under watchdogX/timeleft (i.e., nonzero values)

2) can you pet the watchdog and see the countdown timer reset?

Additional debug tests

3) I would be curious to see the devmem2 values on your EVM for the watchdog status register CFG_WDSTATUS, and the Digital Watchdog Down Counter CFG_DWDCNTR (i.e., what is the status of the peripheral, and can you even see the counter value changing over time?)

If the watchdog counter is not counting down, or counting down at a rate different from 32kHz, that could tell us something useful.

Please note that we just fixed a separate bug with the watchdog driver, where the watchdog could not be pet (with that bug, the processor was FORCED to restart after the timeout, kind of the opposite of your issue). Please apply that patch to the driver.

Patch at: https://lore.kernel.org/lkml/20240417205700.3947408-1-jm@ti.com/

Now run the watchdog-simple application as discussed at: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1338070/am625-how-to-control-the-watchdog

4) Are you able to pet the watchdog now?

5) What is the behavior if you change the pet interval to be larger than the timeout value? Does the processor reset, or not?

Regards,

Nick

Good morning Nick, 

and thanks a lot for all your suggestions.

I reply by now one by one, then I have other question.

N: 1) you can see the time counting down under watchdogX/timeleft (i.e., nonzero values)

L: Yes, I see it decreasing in /sys/devices/platform/bus@f0000/e000000.watchdog/watchdog/watchdog0/timeleft , strating from 60 (or whatever value I choice for starting) to 0

N: 2) can you pet the watchdog and see the countdown timer reset?

L: I ping the watchdog , and if I ping it in the correct window, it correctly restarts again form 60 (or whatever value I choice to start).

N: 3) I would be curious to see the devmem2 values on your EVM for the watchdog status register CFG_WDSTATUS, and the Digital Watchdog Down Counter CFG_DWDCNTR (i.e., what is the status of the peripheral, and can you even see the counter value changing over time?)

If the watchdog counter is not counting down, or counting down at a rate different from 32kHz, that could tell us something useful.

L: This seems to be interesting, I have checked the CFG_WDSTATUS (by reading the RTIWDSTATUS) and ot decrease step by step.

But I have not read yet the CFG_DWDCNTR (I mean: I should read the CFG_DWDCNTR register at 0xa0 ? )

Anyway, I just noticed that the timeleft value decrease quite slow compared with the real time. Even applying the mentioned patches, it decrease just 11 seconds every 30 real.

N: Now run the watchdog-simple application as discussed at: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1338070/am625-how-to-control-the-watchdog

L: Yes, I tried the simple app, compiled through Yocto building system; the result is the same as using "echo 1 > /dev/watchdog "

N: 4) Are you able to pet the watchdog now?

L: I ping the watchdog, and it restarts from the default value (60 or other of my choice) of pinged in the correct window

N: 5) What is the behavior if you change the pet interval to be larger than the timeout value? Does the processor reset, or not?

L: How can I achieve this? I read that the pet interval can be maximum 50% of timeout value.

Also, I understood that the pet interval is the interval in which I can ping the watchdog; is my understandng correct ? 

Other 3 questions:

1. I read somewhere that writing in the RTI_WDKEY register a sequence different from  the sequence E51Ah followed by A35Ch, then it should restart.

I have tried, but even in this case I cannot see any restart; also, it then doesn't come back again to the original value of 60.

I understand that it doesn't work again (same as reaching 0), but I cannot see anyway any restart.

2. I never see the watchdog_restart_notifier starting (in wachdog_core.c), with its " wdd->ops->restart(wdd, action, data); "  restarting.

I even added a " .restart = my_restart, " in the  rti_wdt_ops , in the rti_wdt.c, with some  debugging print, but  I have never see it restarted.

3. I see a RTIWWDRX_NMI written in the control register, that afaik should start an interrupt at the end of the timeout, when it reaches 0 (zero).

Where does this interrupt go?

Do we should set the R5F device manager in some proper way?

Just a further note: tomorrow I will try to read the CFG_DWDCNTR, meantime I have anyway seen that the counter is decreasing quite slow compared  to real world (decrease 11 in just 30 seconds)

Thanks in advance for your answers and Best Regards,

Lorenzo

Hello Lorenzo,

Thank you for your good debug! It's after business hours at this point, so I'll have to chat with the developer tomorrow.

Assuming DWDCNTR is sourced by a 32,768Hz clock, you should be able to divide the counter value by that to see how many seconds are remaining. I would be curious to see if the counter value matches your programmed timeout value at the beginning, and what happens to it after the watchdog expires.

How to intentionally let the watchdog expire? 

In the watchdog-simple application, just set the pet interval to be larger than the timeout value. That should cause the watchdog to time out, since it does not get pet in time.

It would be good to see the register values for  CFG_WDSTATUS and CFG_DWDCNTR before the timeout occurs, and then again after the timeout occurs (and the processor has failed to reset).

I'm going to link you to another e2e thread where we are working on the same issue, just in case it helps us move forward:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1368655/am62a7-enabling-the-watchdog-and-testing

Regards,

Nick

Hello Nick,

I am here for my daily debug report!

I answer to your question one by one, than I have myself few other questions too.

1. I have let the watchdog expire and reading the 2 registers. I let it expires by modifying the pet value in the simple application, or doing an "echo 1 > /dev/watchdog" and then avoiding to do another one before time expiration: in both cases the result is the same.

CFG_WDSTATUS:

Without pinging after timer starting:

This register  is 0 after starting the watchdog,  50 (0x32 after watchdog time expiration), 58 (0x3a) i I try to ping again

In case I ping while while being in the correct window:

the status switch from 0 to 40 (0x28); in the end after timeout expiration, it goes to 58 (0x3a) too.

CFG_DWDCNTR:

This is in line with the timeleft, I means : the limeleft, being showed in /sys/devices/platform/bus@f0000/e000000.watchdog/watchdog/watchdog0/timeleft ,

is exactly the module of : | CFG_DWDCNTR / 32768 | (that's the frequency come out from the "wdt->freq = clk_get_rate(clk);" in the driver.

Anyway, I see here a problem. The rate at which the timeout decrease, is not in line with the effective time.

I mean: the timeout decrease by 1 every around 2.8 real seconds. So when the timeout reaches 0, the counter is still at around 32.000 , and more than 2 seconds (near 3) have still to pass before it reaches 0.

I don't understand why the timeout decrease so slowly compared to real time and I don't now if this could be a problem.

Then, I still have the previous questions:

A. Even writing in the RTI_WDKEY register a sequence different from  the sequence E51Ah followed by A35Ch, then it doesn't restart, but I have read somewhere that it should restart in such a case. Does this behavior could be related ? Probably yes.

B. I never see the watchdog_restart_notifier starting (in wachdog_core.c), trying to catch it with some printk, Why?

3. Where does the  RTIWWDRX_NMI  (written in the control register) goes at the end of the timeout?, I think it should start an interrupt at the end of the timeout, when it reaches 0 (zero).

Where does this interrupt go?

Do we should set the R5F device manager in some proper way?

I will then read more carefully the link that you fwded me about a similar issue, trying to see if I could find some helpful things

Thanks in advance and regards,

Lorenzo

Putting this summary here for my own reference, will reply back with more later:

CFG_WDSTATUS

DWWD - This bit denotes whether the time-window defined by the windowed watchdog configuration has been violated, or if a wrong key or key sequence was written to service the watchdog
0 = no time-window violation has occurred
1 = a time window violation has occurred. The watchdog will generate either a system reset or a non-maskable interrupt to the CPU in this case

END - This bit denotes whether the end-time defined by the windowed watchdog configuration has been violated
0 = no end-time window violation has occurred
1 = the end-time defined by the windowed watchdog configuration has been violated

START - This bit denotes whether the start-time defined by the windowed watchdog configuration has been violated.
0 = no start-time window violation has occurred
1 = the start-time defined by the windowed watchdog configuration has been violated

KEYST - This bit denotes a reset generated by a wrong key or a wrong keysequence written to the RTIWDKEY register
0 = no wrong key or key-sequence written
1 = wrong key or key-sequence written to RTIWDKEY register

DWDST
0 = DWD timeout period not expired
1 = DWD timeout period has expired

AWDST
0 = AWD pin 0 > 1 threshold not exceeded
1 = AWD pin 0 > 1 threshold exceeded

So for the different states:

After starting the watchdog: 0x0 = 0b00_0000

After petting the watchdog: 0x28 = 0b10_1000
DWWD 1 = a time window violation has occurred
START 1 = the start-time defined by the windowed watchdog configuration has been violated
(shouldn't the driver block this from happening?)

After letting watchdog expire, NO pets: 0x32 = 0b11_0010
DWWD 1 = a time window violation has occurred
END 1 = the end-time defined by the windowed watchdog configuration has been violated
DWDST 1 = DWD timeout period has expired

Pet watchdog & after watchdog expires: 0x3a = 0b11_1010
DWWD 1 = a time window violation has occurred
END 1 = the end-time defined by the windowed watchdog configuration has been violated
START 1 = the start-time defined by the windowed watchdog configuration has been violated
DWDST 1 = DWD timeout period has expired

Hello Nick,

That's correct, thanks!

I would add another bit of news.

Trying to writing a wrong sequence (by example 0xe53c as WDKEY_SEQ0, instead of 0xe41a, just inserting this option in the rti_wdt_ping function in the rti_wdt.c driver, just to see what happens), then the status switch from 0x00 to 0x2C : 0010 1100 .

I have read somewhere that writing a wrong sequence, the watchdog should restart soon by default.

Nevertheless, even in this case, nothing happens: the board doesn't restart, the added ".restart" function (added in the rti_wdt_ops just for test, with some print debug) doesn't start too, despite the fact that the status register change it's value.

In any case, even after writing a wrong sequence, the timeout still continue to decrease, and at at the expiration of the timeout, the register become 0x3a as usual. Or rather, the register become 0x3a at the end of the counter (just more than 2 seconds after the timeout reaches 0, because the timeout doesn't decrease at a real time: it goes down at a rate of 1 in around 2.8 seconds.... even if the clock rate is exactly 32,768 , I don't know why).

I still wonder if we have to config something dedicated to the R5F , maybe in some dtsi. Or about the final detination of the NMI (as per "writel_relaxed(RTIWWDRX_NMI, wdt->base + RTIWWDRXCTRL);" in the rti_wdt.c driver).

Ok NIck, waiting for more news, 

Thanks and Best Regards,

Lorenzo

Hello again Nick,

Other 2 doubts (even if they could be considered an extension of the previous):

1. I read that the RTI_WWD_INT would go in the ESM (Error Signalling Module), but it is not clear to me how I can check it

Looking into the k3-am620-main.dtsi , included in the final dts, I see that something about esm is already set:  main_esm: esm@420000 {..}.

Do I still do something else?

2. At this link  https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1315788/processor-sdk-am62p-how-to-configure-the-esm-interrupt-for-triggering-the-wdg-reset  , I see a way to set the watcgdog interrupt, but this has tp be compled with the proper mcu.  I have an image build with Yocto system. I wonder if I should do something specific for he R5F.

Waiting for more comments,

Regards

Lorenzo

Hello Lorenzo,

Apologies for the delayed response - was able to chat with the developer Friday evening, then didn't have time to respond back.

The "start" error when you try to pet the watchdog is interesting.

I think it is caused by the clock to the hardware watchdog not actually incrementing at 32,768 Hz. Normally, the Linux driver would block any attempts to pet the watchdog until AFTER the watchdog opens the window to allow for petting. But if the watchdog is running more than 2% slower than 32,678kHz (I think that's the value we programmed into the kernel patch I pointed you to), then the Linux version of the time and the watchdog's version of time would be different enough that the Linux driver would allow a pet, even though the hardware watchdog timer hasn't opened the window yet.

So that's the first thing to fix - trace the clock source & frequency, and make sure that an actual 32kHz clock source is being used for the hardware watchdog.

I'll need some additional time to look into the other comments and run tests myself - it's 10pm my time, so I've gotta sign off for today.

Regards,

Nick

Thanks Nick for your effort!

Meantime, I still wonder about the interrupt that seems not to be caught by anyone.

And I still wonder about ESM Error signalling module, that should receive this interrupt (at least I have understood so), maybe there is something missing...

I have found internet these patch: 

https://patches.linaro.org/project/u-boot/patch/20200214091820.28877-3-t-kristo@ti.com/

related tp k3-esm-pins,  but they are not integrated in my building system. 

What are the purpose of these patches? They seem to have a relation to my problem, but anyway I don't see them integrated, so I could have badly understood.

Regards,

Lorenzo 

Hello Nick,

I have just tried a new EVM, SK-AM62P-LP.

The timeout decrease correctly, is no longer slowly compared tor real time.

Nevertheless, the interrupt never start (or never is caught by someone).

I also see the pretimeout message ( by example: watchdog0: pretimeout event), but the board doesn't reboot.

The image has been built with Yocto building Tool , following all the instructions that I have found, and adding the sysfs files for better debugging.

Do I have to set something else in the ESM or R5F ?

I mean: I have to add/check something in some dtsi , or add some recipe that manage the R5F communication?

Thanks for your effort and Regards,

Lorenzo 

Hi Nick,

Few other inputs, regarding status register during various phases while testing my new (Yocto) building, in the EVM, SK-AM62P-LP mentioned yesterday.

I repeat, in this new building the timeout decrease correctly (nevertheless, it doesn't reboot at the end, even if I see the pretimeout message.

The status register starts at 0x0, it remains 0x0 after a correct ping, and it goes at ox32 when the timeout reaches the 0 value and there are no more seconds remaining.

This happens in boh cases, with the original rti_wdt.c driver , and with the mentioned patches at https://lore.kernel.org/lkml/20240417205700.3947408-1-jm@ti.com/. The patches have no influence.

Also, by myself, I have tried to:

. Add more interrupts main at_" esm: esm@420000 { " in the  k3-am62p-main.dtsi ,  based on what I see in the "am62px Sitara Technivcal reference Manual", where I see in the ESM0_Interrupt_Map at around pag. 741-742

. Try ro write in hhe regoster CFG_SETINT (base + 0x80), that is 0 by defaylt and I read in the TRM that 0 means interrupt disabled, 1 enabled

. Add ti-dm-fw and ti-rtos-firmware recipe in the final yocto builded image.

None of the above attempts have been succesful.

Pls provide us a feedback, we need to go in production soon and the watchdog has to be reliable.

After having seen the timeout decreasing at a correct rate, this is definitively a question of interrupt non starting or not caught by the correct reciver.

Regards,

Lorenzo

Hello Lorenzo,

U-boot ESM code 

Hmm. When I check the AM62Px SDK 9.2, I do see the ESM defined for AM62Px:

ti-processor-sdk-linux-am62pxx-evm-09.02.01.09/board-support/ti-u-boot-2023.04+gitAUTOINC+f9b966c674$ grep -r 'esm'
grep: .git/index: binary file matches
...
drivers/misc/k3_esm.c:static void esm_pin_enable(void __iomem *base, int pin)
drivers/misc/k3_esm.c:static void esm_intr_enable(void __iomem *base, int pin)
...
arch/arm/mach-k3/am62p5_init.c:static __maybe_unused void enable_mcu_esm_reset(void)
arch/arm/mach-k3/am62p5_init.c:         ret = uclass_get_device_by_name(UCLASS_MISC, "esm@420000", &dev);
...
arch/arm/dts/k3-am62p-main.dtsi:        main_esm: esm@420000 {
arch/arm/dts/k3-am62p-main.dtsi:                compatible = "ti,j721e-esm";
...
arch/arm/dts/k3-am62p-mcu.dtsi: mcu_esm: esm@4100000 {
arch/arm/dts/k3-am62p-mcu.dtsi:         compatible = "ti,j721e-esm";

When I check against mainline u-boot, I see the uboot driver, but NOT the arch/arm/dts/k3-am62p-main.dtsi file:
https://source.denx.de/u-boot/u-boot/-/tree/master/arch/arm/dts?ref_type=heads 

In general TI is striving towards upstreaming all of our code for both Linux and u-boot, but there is some code that has not been upstreamed yet. My guess is that the AM62Px code hasn't been upstreamed at this point - but I do not have a bunch of u-boot experience myself.

QUESTION: Does u-boot built from a downloaded SDK behave differently for you?

Different behavior on different EVMs? 

If I understand, you are getting different behavior on 2 different AM62Px EVM boards. Is that correct? (with the understanding that this is a difference in clocking behavior, not a difference in watchdog's ability to reset the part)

What differences are there between the boards?

1) any HW modifications?

2) any SW differences? (i.e., is Linux devicetree, kernel configs, uboot files, R5F file built into uboot binaries, etc all the same?)

First, I want to rule out a hardware error (i.e., is one of the EVMs failing in a weird way?)

If the two EVMs can be made to behave the same way with the exact same code, I would like us to see if we can identify exactly what code causes the behavior to change.

Is behavior different with and without the latest patches? 

Good to know you are not seeing differences in behavior there.

Need to resolve issue soon 

Understood. I will be working on your thread and this other thread on AM62x with elevated priority for the next couple of days:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1377565/re-am623-watchdog-will-not-reset-processor

Hopefully we can figure out what is going on and get both of you over the finish line soon.

What code base are you testing? 

Are you able to see this behavior with unmodified AM62Px EVM & out-of-the-box filesystem, or ONLY with your modified code?

I will not have time to run hardware tests tonight - I'll see if I can replicate behavior on either AM62Px or AM62x tomorrow. But any information you can give me to help me see what you are seeing will be helpful.

Regards,

Nick

One final note: 

as discussed on the AM62x thread, the only place so far I see the ESM getting set is in
arch/arm/mach-k3/am62p5_init.c

So my current hypothesis is that if the uboot devicetree file does not define the ESM, then that uboot init function fails to set up the ESM properly, and the watchdog's timeouts during runtime are not handled by the ESM. I am following up with some team members who know more about uboot and ESM to see if there is any code I am missing.

Regards,

Nick

Hello Nick and thanks for your effort.

I have finally seen the watchdog for the 1st time, after modification of the  "main_esm: esm@420000 {..} in the k3-am62p-main.dtsi in u-boot.

Looking into the "ESM0_Interrupt_MAP" of the TRM  , around pag. 737-741, it seems that I had to add few esm-pins in the interrupt sequence, compare to the original line.

Pls don't close anyway the bug, I could have anyway to ask something more specific.

We are close to a solution, but it's important to better understand the complete mechanism.

Thanks and regards,

Lorenzo

Hello Lorenzo,

Glad to hear that it sounds like we are on the right track!

Please keep me updated - I will create 2 separate FAQs for watchdog issues, 1 for the "watchdog cannot be pet" issue from earlier this year, and 1 for the "watchdog is not resetting the processor" issue. I'll also drive dev team actions based on your feedback.

It would be great if it turns out that the code in the TI version of uboot works, and you were just using the upstreamed version of uboot instead. In that case, I just need to get the team to upstream the ESM code for AM62x / AM62Px. On the other hand, if additional changes are needed, we need to know about that as well.

QUESTION 1: What source are you using for uboot?

QUESTION 2: What is your clock source settings for the watchdog timer? (please share your devicetree snippet)

I'll look more into watchdog clocking today. Keep in mind that during runtime we want to use an actual oscillator as our clock source, and NOT the 32kHz RC clock. RC clocks can have a HUGE error (apparently up to 50% of the frequency or more!), and are only used when you just need a clock, regardless of the exact frequency.

From skimming the TRM, it looks like DEVICE_CLKOUT_32K is probably sourced by the RC clock, so we should NOT use that as the clock source.

Regards,

Nick

I spent some more time looking through clocking on the AM62x today (ran out of time before I could get to AM62P). Details here:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1377565/re-am623-watchdog-will-not-reset-processor/5265382#5265382

Regards,

Nick

Hello NIck,

It seems we are now to the right way.

My previous slowly timeout was probably due to a certain customization, even if we have not yet understood why. Timeout speed decreasing is something anyway to investigate, we have to understand why it happens after a certain customization (not related anyway to original EVM).

It is verified that the real point of the original am62p EVM board , that blocked the watchdog , was in the esm-pins, with intrp not caught.

The modified file in my SDK is the <u-boot-ti>/arch/arm/dts/k3-am62p-main.dtsi.

In that file , in main_esm: esm@420000 {... } , I have added some esm-pins interrupt, based on what I have understood from  "ESM0_Interrupt_MAP" of the TRM , around pag. 737-741.

It was necessary modifying that file, adding a few pins related to. RTIx_INTR_WWD0 .

(pins: 224, 225, 227, 241, 242, not sure about all of them anyway , maybe the wkup 227 is not needed,  still to verify).

I also don't understand the original esm-pins: 160-163 and 177 , that I even don't find in the mentioned ESM0-Interrupt-Map: 

Q1: could you pls explain what are these esm-pins? 

(I mean: 160 to 163, 177).

I have also modified accordingly the same dts in <KERNEL>/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi.

I am not sure that has to be modified too.

Surely the one in u-boot is mandatory (<u-boot-ti>/arch/arm/dts/k3-am62p-main.dtsi.), because I have verified that the ESM starts even before the u-boot, setting properly the esm-pins for further usage, based on k3_esm.c and dts.

So,  Q2: is the correspondent dts in kernel  ( <KERNEL>/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi. ) , has to be modified too ?

(in the same way as the one in u-boot I men)

I think yes, because otherwise I am afraid there could be later some side effects that I cannot know, but I prefer to ask.

Still continue  info/question on Monday  (now it's Saturday, vacation day ...)

Best Regards,

Lorenzo

Hello Nick,

I just confirm 227 was not needed and dts in kernel not needed too. Just the <u-boot-ti>/arch/arm/dts/k3-am62p-main.dtsi has to be modified, adding 224, 225,  241, 242

Could you pls confirm or give me a feedback anyway?

Aother question: what about watchdog4 ? I have not found a correspondent RTIx_INTR_WWD in the ESM0_Onterrupt_MAP.

Regards,

Lorenzo

Hello Lorenzo,

I think you are on the right track. This looks like a bug. I suspect that esm-pins was probably copy-pasted from AM62x:
When I check TRM section Module integration > timer modules > Real Time Interrupt (RTI) > RTI Hardware Requests,

AM62x:
RTI0 --> RTI0_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_160
RTI1 --> RTI1_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_161
RTI15 --> RTI15_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_162
WKUP_RTI0 --> WKUP_RTI0_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_163
WKUP_RTI0 --> goes to WKUP_ESM0 85
RTI2 --> RTI2_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_177
RTI3 --> RTI3_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_178

AM62Px:
RTI0 --> RTI0_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_224
RTI1 --> RTI1_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_225
RTI15 --> RTI15_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_248
WKUP_RTI0 --> WKUP_RTI0_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_227
WKUP_RTI0 --> goes to WKUP_ESM0 85
RTI2 --> RTI2_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_241
RTI3 --> RTI3_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_242
MCU_RTI0 --> not routed to ESM0, but routed to WKUP_ESM0 86

AM62Ax:
RTI0 --> RTI0_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_192
RTI1 --> RTI1_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_193
WKUP_RTI0 --> WKUP_RTI0_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_195
WKUP_RTI0 --> does NOT go to the WKUP_ESM0 ???
RTI2 --> RTI2_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_209
RTI3 --> RTI3_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_210
RTI4 --> RTI4_intr_wwd_0 --> goes to ESM0_esm_pls_event2_IN_204
MCU_RTI0 --> not routed to ESM0, but routed to WKUP_ESM0 85 (double check this, WKUP_RTI0 was input 85 for other devices)

AM64x - looks like only MCU domain RTI? Need more time to investigate

Yes, please make the same changes to both Linux & uboot 

I'll try to spend a bit more time looking at the uboot & Linux code before going to bed, that will be in a separate reply.

Regards,

Nick

Hello Lorenzo,

Yes, the uboot & Linux devicetree files definitely need to be updated for both AM62Px & AM62Ax (for future readers, AM62Ax was added for SDK 10.0 on uboot 2024.4 & Linux kernel 6.6, so you will not see it in SDK 9.2 or earlier). I have filed a high priority ticket to get this fixed for SDK 10.0.

Could I get you to share your patches for Linux and uboot once you have everything working? The developer is in all-day training for the rest of this week, but once they are back I'll ask them to refer to this e2e thread.

Regards,

Nick

Hello Lorenzo,

Also, I wanted to say thank you.

This week and last week have been very busy (It's 10:15pm as I'm writing this, and there is more work to do!), and your creativity and curiosity has had a really positive impact on my life. You are even helping us fix a pretty major watchdog bug on multiple devices before our next big SDK release, which is huge!

If you hadn't done any testing and was just waiting on me to work through stuff, I would have figured it out eventually. But it would have taken me many more hours. And I'm on vacation the first two weeks of July, so probably not until the 3rd or 4th week of July, and by then it would be too late to fix for SDK 10.0.

So thanks again! I appreciate you.

Regards,

Nick

Hello Nick,

Thanks a lot for your words,

Regards,

Lorenzo

Hello Lorenzo,

I hope things are going well on your end! Are there any updates we should be aware of, or anything else we should chat about?

Regards,

Nick

Hi Nick,
That's ok by now. I then noticed that in my case, the reason of the slow clock was due to the: writel(MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL, MCU_CTRL_DEVICE_CLKOUT_32K_CTRL) in the board_rtc_init of u-boot, where it goes to write in the mentioned register for setting it to the oscillator, that we don't have. Writing 0 instead of MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL, the clock is Ok and evertythings seems by now to works perfect.

Hello Lorenzo,

Glad to hear, and thank you for sharing your solution with us!

If anything else pops up, feel free to create a new thread and we can chat there.

Regards,

Nick

Hello Nick,

That's good to hear!

Regards,

Lorenzo