Hi Bharat,

There are two parts in firmware first handling, handling it in Firmware and notifying it to NS world. Whether to notify it to NS or not is a platform choice.

The platform hook for handling external aborts/SErrors is plat_ea_handler(). If RAS extension is present then it iterates through platform registered handler, without RAS extension it may do platform specific handling or print error msg and panic.

Notifying to NS world is independent of RAS handling and if  a platform wants it can use any suitable mechanism (e.g. SDEI) to notify. I haven't seen any platform notifying NS world for non RAS SErrors.

Hope that helps

Thanks
From: Bharat Bhushan <bbhushan2@marvell.com>
Sent: 31 August 2023 11:27
To: Manish Pandey2 <Manish.Pandey2@arm.com>; tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Cc: Linu Cherian <lcherian@marvell.com>; Sunil Kovvuri Goutham <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com>
Subject: RE: External Abort and SError Handling with RAS enabled
 

Hi Manish,

 

Are you saying in general RAS will notify Linux ? My question is more specific about Asynchronous SError. Will firmware forward Asynchronous SError also to Linux via RAS.

 

Thanks

-Bharat

 

 

From: Manish Pandey2 <Manish.Pandey2@arm.com>
Sent: Thursday, August 31, 2023 3:39 PM
To: tf-a@lists.trustedfirmware.org; Bharat Bhushan <bbhushan2@marvell.com>
Cc: Linu Cherian <lcherian@marvell.com>; Sunil Kovvuri Goutham <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com>
Subject: [EXT] Re: External Abort and SError Handling with RAS enabled

 

External Email

Hi Bharat,

 

HANDLE_EA_EL3_FIRST_NS is used to set SCR_EL3.EA to 1 so that external aborts and SErrors are routed to EL3. This flag can be used for systems with or without RAS extension.

 

For systems with RAS extension, you need to enable RAS_FFH_SUPPORT to pull in necessary framework and platform hooks for handling RAS errors (refer to https://trustedfirmware-a.readthedocs.io/en/latest/components/ras.html )

 

In current TF-A implementation, firmware (EL3 or Secure partition) creates the CPER records.  NS host (Linux) is notified using SDEI so that it can navigate and process CPER records.

 

Thanks

Manish

 

From: Bharat Bhushan via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 31 August 2023 06:10
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Cc: Linu Cherian <lcherian@marvell.com>; Sunil Kovvuri Goutham <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com>
Subject: [TF-A] External Abort and SError Handling with RAS enabled

 

Hi All,

SCR_EL3.EA define whether to route External Abort and SError Interrupt to EL3 or EL2/1. ATF have a compile time flag to HANDLE_EA_EL3_FIRST_NS to program SCR_EL3.EA.

Below text from ATF documentation.
    -  ``HANDLE_EA_EL3_FIRST_NS``: When set to ``1``, External Aborts and SError
         Interrupts, resulting from errors in NS world, will be always trapped in
        EL3 i.e. in BL31 at runtime. When set to ``0`` (default), these exceptions
        will be trapped in the current exception level (or in EL1 if the current
        exception level is EL0).

Have question related to forwarding of these errors when External Abort and SError Interrupt are routed to EL3.
In this case will ATF forward Asynchronous SError Interrupt to Linux via RAS?

Thanks
-Bharat
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org