On 06.05.21 09:06, Atish Patra wrote: > This patch adds all the required content to make RISC-V EBBR compatible. > The additional content is not a lot given that we just need to update the > architecture specific sections for RISC-V. Rest of the document is ISA > agnostic > anyways. > > Signed-off-by: Atish Patra <atish.pa...@wdc.com> > --- > source/chapter1-about.rst | 83 ++++++++++++++++++++++++++------- > source/chapter2-uefi.rst | 14 +++--- > source/chapter3-secureworld.rst | 12 +++++ > source/index.rst | 3 ++ > source/references.rst | 4 ++ > 5 files changed, 92 insertions(+), 24 deletions(-) > > diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst > index 52e61e80b7f9..feb3e7b59431 100644 > --- a/source/chapter1-about.rst > +++ b/source/chapter1-about.rst > @@ -158,6 +158,8 @@ easily meet the stricter BBR requirements. > By definition, all BBR compliant systems are also EBBR compliant, but the > converse is not true. > > +This specification is also referenced by RISC-V platform specification > [RVPLTSPEC]_. > + > Conventions Used in this Document > ================================= > > @@ -181,14 +183,12 @@ This document uses the following terms and > abbreviations. > > .. glossary:: > > +AARCH64
This heading could simply be called ARM as the list comprises both 32 and 64bit terms. > +------- > A64 > 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. > - Under the heading ARM we can keep this here. > 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 > @@ -197,10 +197,6 @@ This document uses the following terms and abbreviations. > AArch64 > Execution state provides a single instruction set, A64. > > - EFI Loaded Image > - An executable image to be run under the UEFI environment, > - and which uses boot time services. > - > EL0 > The lowest Exception level on AArch64. The Exception level that is > used to execute > user applications, in Non-secure state. > @@ -218,17 +214,56 @@ This document uses the following terms and > abbreviations. > execute Secure Monitor code, which handles the transitions between > Non-secure and Secure states. EL3 is always in Secure state. > > - Logical Unit (LU) > - A logical unit (LU) is an externally addressable, independent entity > - within a device. In the context of storage, a single device may use > - logical units to provide multiple independent storage areas. > +ARM > +--- > + AArch32 > + Arm 32-bit architectures. AArch32 is a roll up term referring to all > + 32-bit versions of the Arm architecture starting at ARMv4. Just leave AArch32 where it is. > > - OEM > - Original Equipment Manufacturer. In this document, the final device > - manufacturer. > +RISC-V > +------ > + HART > + Hardware thread in RISC-V. This is the hardware execution context that > contains > + all the state mandated by the ISA. > > - SiP > - Silicon Partner. In this document, the silicon manufacturer. > + HSM > + Hart State Management (HSM) is an SBI extension that enables the > supervisor > + mode software to implement ordered booting. > + > + HS Mode > + Hypervisor-extended-supervisor mode which virtualizes the supervisor > mode. > + > + M Mode > + Machine mode is the most secure and privileged mode in RISC-V. > + > + RISC-V > + An open standard Instruction Set Architecture (ISA) based on > + Reduced Instruction Set Architecture (RISC). > + > + RV32 > + 32 bit execution mode in RISC-V. > + > + RV64 > + 64 bit execution mode in RISC-V. > + > + RISC-V Supervisor Binary Interface (SBI) > + Supervisor Binary Interface. This is an interface between SEE and > supervisor > + mode in RISC-V. > + > + SEE > + Supervisor Execution Environment in RISC-V. This can be M mode or HS > mode. > + > + S Mode > + Supervisor mode is the next privilege mode after M mode where virtual > memory is enabled. I am missing VS mode here. > + > + U Mode > + User mode is the least privilege mode where user-space application is > expected to run. > + > +UEFI > +---- > + EFI Loaded Image > + An executable image to be run under the UEFI environment, > + and which uses boot time services. > > UEFI > Unified Extensible Firmware Interface. > @@ -240,3 +275,17 @@ This document uses the following terms and abbreviations. > UEFI Runtime Services > Functionality that is provided to an Operating System after the > ExitBootServices() call. > + > +Miscellaneous > +------------- > + Logical Unit (LU) > + A logical unit (LU) is an externally addressable, independent entity > + within a device. In the context of storage, a single device may use > + logical units to provide multiple independent storage areas. > + > + OEM > + Original Equipment Manufacturer. In this document, the final device > + manufacturer. > + > + SiP > + Silicon Partner. In this document, the silicon manufacturer. > diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst > index 53c962ab5c25..4810096a7fd5 100644 > --- a/source/chapter2-uefi.rst > +++ b/source/chapter2-uefi.rst > @@ -209,24 +209,24 @@ Resident UEFI firmware might target a specific > privilege level. > In contrast, UEFI Loaded Images, such as third-party drivers and boot > applications, must not contain any built-in assumptions that they are to be > loaded at a given privilege level during boot time since they can, for > example, > -legitimately be loaded into either EL1 or EL2 on AArch64. > +legitimately be loaded into either EL1 or EL2 on AArch64 and HS or S mode on > RISC-V. > > -AArch64 Exception Levels > +Exception Levels > ------------------------ > > -On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, > +UEFI shall execute as 64-bit code at either EL1 or EL2 (on AArch64) and at > HS mode or S mode (on RISC-V), > depending on whether or not virtualization is available at OS load time. > > -UEFI Boot at EL2 > +UEFI Boot at EL2/HS mode > ^^^^^^^^^^^^^^^^ 'make html' produces a warning: source/chapter2-uefi.rst:221: WARNING: Title underline too short. The hypervisor extension is still draft? I could not find anything newer than https://github.com/riscv/riscv-isa-manual/blob/master/src/hypervisor.tex. > > -Most systems are expected to boot UEFI at EL2, to allow for the installation > of > +Most systems are expected to boot UEFI at EL2/HS mode, to allow for the > installation of > a hypervisor or a virtualization aware Operating System. > > -UEFI Boot at EL1 > +UEFI Boot at EL1/S Mode > ^^^^^^^^^^^^^^^^ source/chapter2-uefi.rst:227: WARNING: Title underline too short. According to the 0.6.1 draft of the hypervisor extension the guest is running in VS-mode. S-mode is used by systems without hypervisor extension. The following image would be helpful here: https://raw.githubusercontent.com/riscv/riscv-sbi-doc/master/riscv-sbi-intro2.png The image is licensed under CC-BY 4.0. So it should be allowable to add it to the EBBR. @Grant: Is there a free version of https://documentation-service.arm.com/static/602a712462b3ab66934ed42f?token= or can ARM release the image under the CC-BY 4.0 license? Best regards Heinrich > > -Booting of UEFI at EL1 is most likely employed within a hypervisor hosted > Guest > +Booting of UEFI at EL1/S mode is most likely employed within a hypervisor > hosted Guest > Operating System environment, to allow the subsequent booting of a > UEFI-compliant Operating System. > In this instance, the UEFI boot-time environment can be provided, as a > diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst > index 9c51bca24f33..d6bfbd322837 100644 > --- a/source/chapter3-secureworld.rst > +++ b/source/chapter3-secureworld.rst > @@ -27,3 +27,15 @@ Platforms without EL3 must implement one of: > However, the spin table protocol is strongly discouraged. > Future versions of this specification will only allow PSCI, and PSCI should > be implemented in all new designs. > + > +RISC-V Multiprocessor Startup Protocol > +====================================== > +The resident firmware in M mode or hypervisor running in HS mode must > implement > +and conform to at least SBI [RVSBISPEC]_ v0.2 with HART > +State Management(HSM) extension for both RV32 and RV64. In addition to that, > the > +firmware must ensure the following condition before jumping to the UEFI > +application. > + > +The device tree must contain a property named **boot-hartid** under the > */chosen* > +node. This property must indicate the id of the booting hart. The > corresponding entry > +in the ACPI tables has not been defined yet as ACPI support in RISC-V is > under progress. > diff --git a/source/index.rst b/source/index.rst > index 48318757f717..acd214d25323 100644 > --- a/source/index.rst > +++ b/source/index.rst > @@ -1,5 +1,6 @@ > .. EBBR Source Document > Copyright Arm Limited, 2017-2019 > + Copyright Western Digital Corporation or its affiliates, 2021 > SPDX-License-Identifier: CC-BY-SA-4.0 > > #################################################### > @@ -8,6 +9,8 @@ Embedded Base Boot Requirements (EBBR) Specification > > Copyright © 2017-2019 Arm Limited and Contributors. > > +Copyright © 2021 Western Digital Corporation or its affiliates. > + > This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 > International License. To view a copy of this license, visit > http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to > diff --git a/source/references.rst b/source/references.rst > index 6d09d3c0aaa7..6d35d909c8fe 100644 > --- a/source/references.rst > +++ b/source/references.rst > @@ -29,3 +29,7 @@ > .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, > February 2020, `UEFI Forum <http://www.uefi.org>`_ > + > +.. [RVPLTSPEC] `RISC-V Platform specification > <https://github.com/riscv/riscv-platform-specs>`_ > + > +.. [RVSBISPEC] `RISC-V Supervisor Binary Interface specification > <https://github.com/riscv/riscv-sbi-doc>`_ > _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
