4.11.1.1.Introduction

EA’s and Error interrupts corresponding to NS nodes are handled first in firmware

• Errors signaled back to NS world via suitable mechanism

• Kernel is prohibited from accessing the RAS error records directly

• Firmware creates CPER records for kernel to navigate and process

• Firmware signals error back to Kernel via SDEI

4.11.1.2.Overview

FFH works in conjunction withException Handling Framework. Exceptions resulting fromerrors in Non-secure world are routed to and handled in EL3. Said errors are SynchronousExternal Abort (SEA), Asynchronous External Abort (signalled as SErrors), Fault Handlingand Error Recovery interrupts.RAS Framework in TF-A allows the platform to define an external abort handler and toregister RAS nodes and interrupts. It also provideshelpers for accessing StandardError Records as introduced by the RAS extensions

4.11.2.1.Introduction

EA’s originating/attributed to NS world are handled first in NS and Kernel navigatesthe std error records directly.

• KFH is the default handling mode if platform does not explicitly enable FFH mode.

• KFH mode does not need any EL3 involvement except for the reflection of errors backto lower EL. This happens when there is an error (EA) in the system which is not yetsignaled to PE while executing at lower EL. During entry into EL3 the errors (EA) aresynchronized causing async EA to pend at EL3.

4.11.6.1.Platform APIs

The RAS framework allows the platform to define handlers for External Abort,Uncontainable Errors, Double Fault, and errors rising from EL3 execution. Pleaserefer toRAS Porting Guide.

4.11.6.2.Registering RAS error records

RAS nodes are components in the system capable of signalling errors to PEsthrough one one of the notification mechanisms—SEAs, SErrors, or interrupts. RASnodes contain one or more error records, which are registers through which thenodes advertise various properties of the signalled error. Arm recommends thaterror records are implemented in the Standard Error Record format. The RASarchitecture allows for error records to be accessible via system ormemory-mapped registers.

The platform should enumerate the error records providing for each of them:

• A handler to probe error records for errors;

• When the probing identifies an error, a handler to handle it;

• For memory-mapped error record, its base address and size in KB; for a systemregister-accessed record, the start index of the record and number ofcontinuous records from that index;

• Any node-specific auxiliary data.

With this information supplied, when the run time firmware receives one of thenotification mechanisms, the RAS framework can iterate through and probe errorrecords for error, and invoke the appropriate handler to handle it.

The RAS framework provides the macros to populate error record information. Themacros are versioned, and the latest version as of this writing is 1. Thesemacros create a structure of typestructerr_record_info from its arguments,which are later passed to probe and error handlers.

For memory-mapped error records:

ERR_RECORD_MEMMAP_V1(base_addr,size_num_k,probe,handler,aux)

And, for system register ones:

ERR_RECORD_SYSREG_V1(idx_start,num_idx,probe,handler,aux)

The probe handler must have the following prototype:

typedefint(*err_record_probe_t)(conststructerr_record_info*info,int*probe_data);

The probe handler must return a non-zero value if an error was detected, or 0otherwise. Theprobe_data output parameter can be used to pass any usefulinformation resulting from probe to the error handler (seebelow). Forexample, it could return the index of the record.

The error handler must have the following prototype:

typedefint(*err_record_handler_t)(conststructerr_record_info*info,intprobe_data,conststructerr_handler_data*constdata);

Thedata constant parameter describes the various properties of the error,including the reason for the error, exception syndrome, and alsoflags,cookie, andhandle parameters from thetop-level exception handler.

The platform is expected populate an array using the macros above, and registerthe it with the RAS framework using the macroREGISTER_ERR_RECORD_INFO(),passing it the name of the array describing the records. Note that the macromust be used in the same file where the array is defined.

intras_err_ser_probe_memmap(conststructerr_record_info*info,int*probe_data);intras_err_ser_probe_sysreg(conststructerr_record_info*info,int*probe_data);

4.11.6.3.Registering RAS interrupts

RAS nodes can signal errors to the PE by raising Fault Handling and/or ErrorRecovery interrupts. For the firmware-first handling paradigm for interrupts towork, the platform must setup and register withEHF. SeeInteraction withException Handling Framework.

For each RAS interrupt, the platform has to provide structure of typestructras_interrupt:

• Interrupt number;

• The associated error record information (pointer to the correspondingstructerr_record_info);

• Optionally, a cookie.

The platform is expected to define an array ofstructras_interrupt, andregister it with the RAS framework using the macroREGISTER_RAS_INTERRUPTS(), passing it the name of the array. Note that themacro must be used in the same file where the array is defined.

The array ofstructras_interrupt must be sorted in the increasing order ofinterrupt number. This allows for fast look of handlers in order to service RASinterrupts.

4.11.6.4.Double-fault handling

A Double Fault condition arises when an error is signalled to the PE whilehandling of a previously signalled error is still underway. When a Double Faultcondition arises, the Arm RAS extensions only require for handler to performorderly shutdown of the system, as recovery may be impossible.

The RAS extensions part of Armv8.4 introduced new architectural features to dealwith Double Fault conditions, specifically, the introduction ofNMEA andEASE bits toSCR_EL3 register. These were introduced to assist EL3software which runs part of its entry/exit routines with exceptions momentarilymasked—meaning, in such systems, External Aborts/SErrors are not immediatelyhandled when they occur, but only after the exceptions are unmasked again.

TF-A, for legacy reasons, executes entire EL3 with all exceptions unmasked.This means that all exceptions routed to EL3 are handled immediately.TF-Athus is able to detect a Double Fault conditions in software, without needingthe intended advantages of Armv8.4 Double Fault architecture extensions.

Double faults are fatal, and terminate at the platform double fault handler, anddoesn’t return.

4.11.6.5.Engaging the RAS framework

Enabling RAS support is a platform choice

The RAS support inTF-A introduces a default implementation ofplat_ea_handler, the External Abort handler in EL3. WhenENABLE_FEAT_RASis set to1, it’ll first callras_ea_handler() function, which is thetop-level RAS exception handler.ras_ea_handler is responsible for iteratingto through platform-supplied error records, probe them, and when an error isidentified, look up and invoke the corresponding error handler.

Note that, if the platform chooses to override theplat_ea_handler functionand intend to use the RAS framework, it must explicitly callras_ea_handler() from within.

Similarly, for RAS interrupts, the framework definesras_interrupt_handler(). The RAS framework arranges for it to be invokedwhen a RAS interrupt taken at EL3. The function bisects the platform-suppliedsorted array of interrupts to look up the error record information associatedwith the interrupt number. That error handler for that record is then invoked tohandle the error.

4.11.6.6.Interaction with Exception Handling Framework

As mentioned in earlier sections, RAS framework interacts with theEHF toarbitrate handling of RAS exceptions with others that are routed to EL3. Thismeans that the platform must partition apriority level for handling RAS exceptions. The platform must then definethe macroPLAT_RAS_PRI to the priority level used for RAS exceptions.Platforms would typically want to allocate the highest secure priority forRAS handling.

Handling of bothinterrupt andnon-interrupt exceptions follow the sequences outlined in theEHFdocumentation. I.e., for interrupts, the priority management is implicit; butfor non-interrupt exceptions, they’re explicit usingEHF APIs.

Copyright (c) 2018-2023, Arm Limited and Contributors. All rights reserved.