arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 1 + arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 + arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 8 ++++++++ arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 8 ++++++++ arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 3 ++- arch/arm64/boot/dts/ti/k3-am62p-j722s-common-mcu.dtsi | 4 ++-- arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 3 ++- arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 3 ++- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++++ arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 8 ++++++++ 10 files changed, 42 insertions(+), 5 deletions(-)
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. Changes since v1: - Remove watchdog patch - Add am64x patch 5/6 - Add am65x patch 6/6 - Add missing bootph flag Judith Mendez (5): arm64: dts: ti: k3-am62a: Add ESM nodes arm64: dts: ti: k3-am62p: Fix ESM interrupt sources arm64: dts: ti: k3-am62: Add comments to ESM nodes arm64: dts: ti: k3-am64: Add more ESM interrupt sources arm64: dts: ti: k3-am65: Add ESM nodes Santhosh Kumar K (1): arm64: dts: ti: k3-am62p: Remove 'reserved' status for ESM arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 1 + arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 + arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 8 ++++++++ arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 8 ++++++++ arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 3 ++- arch/arm64/boot/dts/ti/k3-am62p-j722s-common-mcu.dtsi | 4 ++-- arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 3 ++- arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 3 ++- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++++ arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 8 ++++++++ 10 files changed, 42 insertions(+), 5 deletions(-) base-commit: e3cce1229c34b5c28f103361c4d6b3ef17302d5d -- 2.46.0
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? Jan > > Changes since v1: > - Remove watchdog patch > - Add am64x patch 5/6 > - Add am65x patch 6/6 > - Add missing bootph flag > > Judith Mendez (5): > arm64: dts: ti: k3-am62a: Add ESM nodes > arm64: dts: ti: k3-am62p: Fix ESM interrupt sources > arm64: dts: ti: k3-am62: Add comments to ESM nodes > arm64: dts: ti: k3-am64: Add more ESM interrupt sources > arm64: dts: ti: k3-am65: Add ESM nodes > > Santhosh Kumar K (1): > arm64: dts: ti: k3-am62p: Remove 'reserved' status for ESM > > arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 1 + > arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 + > arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 8 ++++++++ > arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 8 ++++++++ > arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 3 ++- > arch/arm64/boot/dts/ti/k3-am62p-j722s-common-mcu.dtsi | 4 ++-- > arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 3 ++- > arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 3 ++- > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++++ > arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 8 ++++++++ > 10 files changed, 42 insertions(+), 5 deletions(-) > > > base-commit: e3cce1229c34b5c28f103361c4d6b3ef17302d5d -- Siemens AG, Technology Linux Expert Center
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. ~ Judith > > Jan > >> >> Changes since v1: >> - Remove watchdog patch >> - Add am64x patch 5/6 >> - Add am65x patch 6/6 >> - Add missing bootph flag >> >> Judith Mendez (5): >> arm64: dts: ti: k3-am62a: Add ESM nodes >> arm64: dts: ti: k3-am62p: Fix ESM interrupt sources >> arm64: dts: ti: k3-am62: Add comments to ESM nodes >> arm64: dts: ti: k3-am64: Add more ESM interrupt sources >> arm64: dts: ti: k3-am65: Add ESM nodes >> >> Santhosh Kumar K (1): >> arm64: dts: ti: k3-am62p: Remove 'reserved' status for ESM >> >> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 1 + >> arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 + >> arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 8 ++++++++ >> arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 8 ++++++++ >> arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 3 ++- >> arch/arm64/boot/dts/ti/k3-am62p-j722s-common-mcu.dtsi | 4 ++-- >> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 3 ++- >> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 3 ++- >> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++++ >> arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 8 ++++++++ >> 10 files changed, 42 insertions(+), 5 deletions(-) >> >> >> base-commit: e3cce1229c34b5c28f103361c4d6b3ef17302d5d >
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. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Hi Nishanth, On 8/15/24 7:29 AM, 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. > Sure, I can send v3 with another commit message fixup. ~ Judith
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
© 2016 - 2025 Red Hat, Inc.