On Mon, 24 Sep 2018 at 15:54, Grant Likely grant.likely@arm.com wrote:

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.

privilege

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.

Unfortunately, the UEFI spec currently does not permit booting in HYP mode, and since it also mandates short descriptors, this needs a bit of discussion (and a fair amount of EDK2 code) to support.

+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

---

Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com