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.likely@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::