Hi Dan,

On Thu, Aug 27, 2020 at 8:31 PM Dan Handley via TF-A tf-a@lists.trustedfirmware.org wrote:

Hi Sandeep

Arm development platforms that have an SBSA secure watchdog like N1SDP do not register an interrupt handler for the WS0 signal. They simply wait for the WS1 signal, which is fed to a higher agent (in this case the System Control Processor), which resets the platform. There is no explicit watchdog interrupt handling functionality in TF-A.

what happens to non secure sbsa WS1 ?

That is the case for Secure sbsa WS1. NS WS0 ----> EL1 X (optional) but linux already implements it . NS WS1 ----> EL3 X TF-A Do not handle it. Hence the patch. Not handling it altogether is not an option I guess.

S WS0 -------> EL3 X (optional) . Platform might want to log this condition. S WS1 ----------------------------------------> handled by a higher agent.

If your platform does not have a higher agent that handles WS1 then I guess you could add a handler in TF-A as you suggest in your code snippet, though I'm not sure if the maintainers would want this in generic SBSA code. Also, I don't see why you need both callback(s) and the explicit call to psci_systrem_reset2(), when presumably the callback(s) would do the latter.

Platform callback can optionally do more things like some logging. Ultimately 'system_reset2' seems to be the thing everyone would like to do as part of action. Then to reduce duplicate code we can have at one place.

...

Q1- What happens if core is stuck and interrupts are not taken.

It's rare for EL3 interrupts not to be taken when the core is stuck, unless an EL3 exception handler itself is stuck, in which case I'm not sure there's much you can do. That's why it's good to have a higher agent.

The rare lockup of core where it's not able to respond (not the software ones) requires some other agent to detect and reset/recover the system. Linux watchdog (ns sbsa WS1) will go unnoticed in such cases. ie. even if the watchdog hardware detected the lockup and indicated by WS0 then WS1 .. both were not acted upon. If it were the secure watchdog then no issues.

...

Or it has to be registered as a RAS priority exception.

I don't think that would help, unless the system was flooded with higher priority exceptions that prevented the watchdog handler from running.

Regards

Dan.

From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Sandeep Tripathy via TF-A Sent: 27 August 2020 12:14 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

Hi,

Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware.

I have some query on how TF-A plans to implement this.

Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en

3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE.

Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding.

   If WS1 were to another subsystem (eg: SCP) then it would take action.

   In current scheme is it the secure sbsa wdg expected to detect such hang ?

Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception.

diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c

index 79c6f26..9683ef8 100644

--- a/drivers/arm/sbsa/sbsa.c

+++ b/drivers/arm/sbsa/sbsa.c

@@ -40,3 +40,26 @@

+#define weak plat_sbsa_nt_wdog_ws1_handle

+#define weak plat_sbsa_t_wdog_ws0_handle

+void sbsa_wdog_handler(int id)

+{

•   if (id == SBSA_NT_WDG_WS1_INT) {
  
  

•           /* PUBLISH_EVENT */
  
  

•           plat_sbsa_nt_wdog_ws1_handle();
  
  

•   } else if (id == SBSA_T_WDG_WS0_INT) {
  
  

•           /* PUBLISH_EVENT */
  
  

•           plat_sbsa_t_wdog_ws0_handle();
  
  

•   }
  
  

•   /* EOI and reset , log  what else */
  
  

•   psci_systrem_reset2();
  
  

+}

+void sbsa_wdog_hander_init(void)

+{

+#if EXCEPTION_HANDLING_FRAMEWORK

•   ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler);
  
  

+#endif

+}

Thanks

Sandeep

-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

Thanks Sandeep