On 25/09/2018 16:50, Ard Biesheuvel wrote:
On Tue, 25 Sep 2018 at 16:45, Grant Likely <[email protected]> wrote:
On 24/09/2018 16:22, Ard Biesheuvel wrote:
On Mon, 24 Sep 2018 at 15:54, Grant Likely <[email protected]> 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 <[email protected]>
---
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
Here's another one btw ^^^
Thanks. I'll proofread more carefully before sending out v2
+-------------------------
+
+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.
The UEFI spec is already very normative about the boot mode, so we can
just refer to that.
Okay, I'll simply drop the blurb
g.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
