On 06.05.21 15:32, Atish Patra wrote: > 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
The principal design with exception levels M, HS, VS, VU is not under discussion for the H-extension. So I am fine with referencing these in EBBR. We should add a reference to the draft specification and mention that it is draft. > >>> >>> -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. There we could mention systems with and without H-extension. Best regards Heinrich > >> 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 > > > _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
