On 24/09/2018 16:22, Ard Biesheuvel wrote:
On Mon, 24 Sep 2018 at 15:54, Grant Likely <grant.lik...@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.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.
privilege
Fixed
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.
I was definitely writing out of ignorance here, and just matching what
was done in the AArch32 blurb. Can you recommend some different text? I
can also simply drop the blurb.
g.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
