On 15.08.24 14:29, Nishanth Menon wrote: > On 08:59-20240814, Judith Mendez wrote: >> Hi Jan, >> >> On 8/13/24 11:04 PM, Jan Kiszka wrote: >>> On 14.08.24 01:03, Judith Mendez wrote: >>>> The following patch adds ESM nodes and fixes ESM source >>>> interrupts for Sitara K3 platforms. Currently watchdog cannot >>>> reset the CPU because of misconfiguration or missing ESM node >>>> in DT. >>>> >>>> ESM node was added for am62ax and am65x. For am62px ESM source >>>> interrupts are fixed. Comments were also added for clarity on what >>>> source interrupts are routed to ESM based on device TRM. >>>> >>>> ESM nodes like MCU ESM for am65x are added for device completion, >>>> currently, some ESM0 events are not routed to MCU ESM, so watchdog >>>> cannot reset the CPU using the current implementation. >>> >>> Yes, that's why there is https://github.com/siemens/k3-rti-wdt and >>> probably similar bits in other R5 firmware. I was always told that is >>> the only way to reset the /system/ (CPU alone would not help). That >>> information is still correct? >> >> If you look at 9.4.14 MCU_ESM0 Interrupt Map, ESM0_ESM_INT_CFG_LVL_0, >> ESM0_ESM_INT_HI_LVL_0, and ESM0_ESM_INT_LOW_LVL_0 are not routed to >> MCU_ESM0. So the current implementation to route events from ESM0 to >> MCU_ESM0 to reset the CPU will not work for AM65x, this is the >> implementation on other K3 Sitara platforms and how watchdog can reset >> the cpu. >> >> I did find MAIN_ESM_ERROR_INT which should be SOC_SAFETY_ERRORn, look >> at Figure 12-3690. Perhaps the ESMs could be configured to use >> SOC_SAFETY_ERRORn instead, not sure. >> >> The above should apply to both SR1 and SR2 devices according to the TRM. > > Thanks for clarifying - you should add that in the commit message. > So the short answer to my question is "yes". Jan -- Siemens AG, Technology Linux Expert Center
