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
+-------
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.
-
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.
- 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.
+
+ 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
^^^^^^^^^^^^^^^^
-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
^^^^^^^^^^^^^^^^
-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>`_
--
2.30.1
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
