Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-05-08 18:41:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

doc: Add minimal glossary

Browse source 
One of the current issues with the documentation is that terms and
abbreviations are frequently redefined. For example, we might have
a sentence like "... the SCP (System Control Processor) will ...".

These definitions might be repeated several times across pages, or
even within the same document. Equally, some of these abbreviations
are missed and are never expanded.

Sphinx provides a :term: keyword that takes some text and,
if that text is defined in a glossary document, links to its glossary
entry. Using this functionality will prevent repeated definitions
and will make the docs more maintainable by using a single
definition source.

The glossary added in this patch was created from a quick scrub of
the source code - there may be missing entries. The SDEI abbreviation
was used as an example.

Note that a global_substitutions file was created. This file contains
the RST 'replace' statements that convert plain text terms into linked
terms (by adding the ':term:' keyword to them). An example is:

.. |TF-A| replace:: :term:`TF-A`

The 'rst_prolog' variable in conf.py is used to inject this list of
replacements into each page. Terms must be surrounded with the pipe
character to be turned into links - this means that we can still
prevent certain terms from being linked if we don't want them to be.

Change-Id: I87010ed9cfa4a60011a9b4a431b98cb4bb7baa28
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
This commit is contained in:
Paul Beesley 2019-03-13 13:58:02 +00:00
parent 57354abb20
commit 8f62ca7b30
7 changed files with 273 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

21
docs/components/exception-handling.rst
View file

@ -1,9 +1,6 @@
Exception Handling Framework
============================
.. |EHF| replace:: Exception Handling Framework
.. |TF-A| replace:: Trusted Firmware-A
This document describes various aspects of handling exceptions by Runtime
Firmware (BL31) that are targeted at EL3, other than SMCs. The |EHF| takes care
of the following exceptions when targeted at EL3:
@ -48,11 +45,11 @@ exceptions are targeted at and handled in EL3. For instance:
- The Arm `SDEI specification`_ defines interfaces through which Normal world
interacts with the Runtime Firmware in order to request notification of
system events. The SDEI specification requires that these events are notified
even when the Normal world executes with the exceptions masked. This too
implies that firmware-first handling is required, where the events are first
received by the EL3 firmware, and then dispatched to Normal world through
purely software mechanism.
system events. The |SDEI| specification requires that these events are
notified even when the Normal world executes with the exceptions masked. This
too implies that firmware-first handling is required, where the events are
first received by the EL3 firmware, and then dispatched to Normal world
through purely software mechanism.
For |TF-A|, firmware-first handling means that asynchronous exceptions are
suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
@ -73,8 +70,8 @@ choose to:
processing of the error to dedicated software stack running at lower secure
ELs (as above); additionally, the Normal world may also be required to
participate in the handling, or be notified of such events (for example, as
an SDEI event). In this scheme, exception handling potentially and maximally
spans all ELs in both Secure and Normal worlds.
an |SDEI| event). In this scheme, exception handling potentially and
maximally spans all ELs in both Secure and Normal worlds.
On any given system, all of the above handling models may be employed
independently depending on platform choice and the nature of the exception
@ -603,8 +600,8 @@ should carefully consider the assignment of priorities to dispatchers integrated
into runtime firmware. The platform should sensibly delineate priority to
various dispatchers according to their nature. In particular, dispatchers of
critical nature (RAS, for example) should be assigned higher priority than
others (SDEI, for example); and within SDEI, Critical priority SDEI should be
assigned higher priority than Normal ones.
others (|SDEI|, for example); and within |SDEI|, Critical priority
|SDEI| should be assigned higher priority than Normal ones.
Limitations
-----------