[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240815122928.4i2yob5aj5ssqhzw@reply>
Date: Thu, 15 Aug 2024 07:29:28 -0500
From: Nishanth Menon <nm@...com>
To: Judith Mendez <jm@...com>
CC: Jan Kiszka <jan.kiszka@...mens.com>, <devicetree@...r.kernel.org>,
Vignesh
Raghavendra <vigneshr@...com>, <linux-kernel@...r.kernel.org>,
Rob Herring
<robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Krzysztof Kozlowski
<krzk+dt@...nel.org>
Subject: Re: [PATCH v2 0/6] Add and fix ESM nodes
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
Powered by blists - more mailing lists