Fill out the requirements for AArch32 systems. Not much needs to be
specified here other than the different privilege modes defined by
ARMv7 and below.
Resolves: #15
Signed-off-by: Grant Likely <grant.lik...@arm.com>
---
source/chapter1-about.rst | 19 +++++++++++--------
source/chapter2-uefi.rst | 32 ++++++++++++++++++++------------
source/chapter3-secureworld.rst | 18 ++++++++++++++----
source/index.rst | 1 +
4 files changed, 46 insertions(+), 24 deletions(-)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index d1c6d1d..4d70b2a 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -107,9 +107,8 @@ The following guiding principles are used while developing
the EBBR specificatio
- Support multiple architectures
Any architecture can implement the EBBR requirements.
-
- .. note::
- At the time of writing this document only addresses AArch64, but AArch32
and others architectures are expected.
+ Architecture specific requirements will clearly marked as to which
+ architecture(s) they apply.
- Design for common embedded hardware
@@ -139,7 +138,7 @@ The following guiding principles are used while developing
the EBBR specificatio
Scope
=====
This document defines the boot and runtime services that are expected by an
-Operating System or hypervisor, for an Arm embedded device, which follows the
+Operating System or hypervisor, for a device which follows the
UEFI specification [UEFI]_.
This specification defines the boot and runtime services for a physical system,
@@ -180,6 +179,10 @@ This document uses the following terms and abbreviations.
The 64-bit Arm instruction set used in AArch64 state.
All A64 instructions are 32 bits.
+ AArch32
+ Arm 32-bit architectures. AArch32 is a roll up term referring to all
+ 32-bit versions of the Arm architecture starting at ARMv4.
+
AArch64 state
The Arm 64-bit Execution state that uses 64-bit general purpose
registers, and a 64-bit program counter (PC), Stack Pointer (SP), and
@@ -193,19 +196,19 @@ This document uses the following terms and abbreviations.
and which uses boot time services.
EL0
- The lowest Exception level. The Exception level that is used to execute
+ The lowest Exception level on AArch64. The Exception level that is used
to execute
user applications, in Non-secure state.
EL1
- Privileged Exception level. The Exception level that is used to execute
+ Privileged Exception level on AArch64. The Exception level that is used
to execute
Operating Systems, in Non-secure state.
EL2
- Hypervisor Exception level. The Exception level that is used to execute
+ Hypervisor Exception level on AArch64. The Exception level that is used
to execute
hypervisor code. EL2 is always in Non-secure state.
EL3
- Secure Monitor Exception level. The Exception level that is used to
+ Secure Monitor Exception level on AArch64. The Exception level that is
used to
execute Secure Monitor code, which handles the transitions between
Non-secure and Secure states. EL3 is always in Secure state.
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index f89ac04..7fd8aa6 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -29,19 +29,27 @@ The system firmware must implement support for MBR, GPT and
El Torito partitioni
UEFI System Environment and Configuration
=========================================
-AArch64 Exception Levels
-------------------------
-
-The resident AArch64 UEFI boot-time environment is specified to "Use the
-highest 64-bit Non-secure privilege level available".
-This level is either EL1 or EL2, depending on whether or not virtualization is
-used or supported.
+The resident UEFI boot-time environment shall use the highest non-secure
+privilege level available.
+The exact meaning of this is architecture dependant, as detailed below.
-Resident UEFI firmware might target a specific Exception level.
+Resident UEFI firmware might target a specific priviledge level.
In contrast, UEFI Loaded Images, such as thirdparty drivers and boot
applications, must not contain any built-in assumptions that they are to be
-loaded at a given Exception level during boot time, since they can legitimately
-be loaded into EL1 or EL2.
+loaded at a given priviledge level during boot time since they can, for
example,
+legitimately be loaded into either EL1 or EL2 on AArch64.
+
+AArch32 Priviledge Levels
+-------------------------
+
+UEFI shall execute at either PL1 (svc) or PL2 (hyp),
+depending on whether or not virtualization is used and supported.
+
+AArch64 Exception Levels
+------------------------
+
+UEFI shall execute as 64-bit code in AArch64 model at either EL1 or EL2,
+depending on whether or not virtualization is used or supported.
UEFI Boot at EL2
^^^^^^^^^^^^^^^^
@@ -112,8 +120,8 @@ must be provided.
Runtime Exception Level
-----------------------
-UEFI 2.7 enables runtime services to be supported at either EL1 or EL2, with
-appropriate virtual address mappings.
+On AArch64, UEFI 2.7 enables runtime services to be supported at either
+EL1 or EL2, with appropriate virtual address mappings.
When called, subsequent runtime service calls must be from the same Exception
level.
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst
index 25d24f5..4e9fa61 100644
--- a/source/chapter3-secureworld.rst
+++ b/source/chapter3-secureworld.rst
@@ -4,10 +4,20 @@
Priviledged or Secure Firmware
******************************
-Multiprocessor Startup Protocol
-===============================
-Firmware resident in Trustzone EL3 must implement and conform to the
-Power State Coordination Interface specification [PSCI]_.
+AArch32 Multiprocessor Startup Protocol
+=======================================
+There is no standard multiprocessor startup or CPU power management mechanism
+for ARMv7 and earlier platforms.
+The OS is expected to use platform specific drivers for CPU power management.
+Firmware must advertize the CPU power management mechanism in the Devicetree
+system description or the ACPI tables so that the OS can enable the correct
+driver.
+At ExitBootServices() time, all secondary CPUs must be parked or powered off.
+
+AArch64 Multiprocessor Startup Protocol
+=======================================
+On AArch64 platforms, Firmware resident in Trustzone EL3 must implement and
+conform to the Power State Coordination Interface specification [PSCI]_.
Platforms without EL3 must implement one of:
diff --git a/source/index.rst b/source/index.rst
index 7dc9e40..db47ce6 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -36,6 +36,7 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
12 July 2018 0.6 - Response to comments on v0.6-pre1
- Add large note on implementation of runtime
modification of non-volatile variables
+ TBD TBD - Add AArch32 details
================= ========= =============================================
.. toctree::
--
2.13.0
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
