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 > 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-disc...@arm.com _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
