On Tue, 25 Sep 2018 at 16:45, Grant Likely <grant.lik...@arm.com> wrote: > > 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
Here's another one btw ^^^ > >> +------------------------- > >> + > >> +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. But that leaves the question whether we should push for a UEFI spec update to permit HYP mode and thus long descriptors. Is anyone interested in using that, e.g., for partitioning on industrial/automotive? _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
