On Thu, May 6, 2021 at 2:24 AM Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > 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. >
Grant had earlier suggested to use separate headers for ARM/AARCH64. I can keep them together if it is fine by him. > > 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. > Sure. I will add it. > > + > > + 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. > Unfortunately, yes. Nobody is happy about that but the spec is not frozen yet. http://lists.infradead.org/pipermail/linux-riscv/2021-April/005804.html > > > > -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. > Thanks. I will fix that in the next version. > 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. > Yes. I wanted to keep them in one section. Looking at again, I think we should create a new RISC-V specific section called "RISC-V privilege levels" to avoid confusion. > 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. > Sure. I will add that. > @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 -- Regards, Atish _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
