On Thu, Oct 15, 2020 at 06:10:32PM -0700, Atish Patra wrote:
> This patch adds all minimum mandatory requirements to make RISC-V compatible
> with EBBR.
>
> Signed-off-by: Atish Patra <atish.pa...@wdc.com>
> ---
> source/chapter1-about.rst | 42 +++++++++++++++++++++++++++++++--
> source/chapter2-uefi.rst | 10 +++++++-
> source/chapter3-secureworld.rst | 14 +++++++++++
> source/references.rst | 4 ++++
> 4 files changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
> index 3db3f3280448..6927c87a125f 100644
> --- a/source/chapter1-about.rst
> +++ b/source/chapter1-about.rst
> @@ -152,9 +152,10 @@ operating system.
> SBBR is targeted at the server ecosystem and places strict requirements on
> the
> platform to ensure cross vendor interoperability.
> EBBR on the other hand allows more flexibility to support embedded designs
> -which do not fit within the SBBR model.
> -For example, a platform that isn't SBBR compliant because the SoC is only
> +which do not fit within the SBBR model. For example, a platform that isn't
> SBBR compliant because the SoC is only
> supported using Devicetree could be EBBR compliant, but not SBBR compliant.
> +EBBR also supports multiple architectures such as AArch64 & RISC-V. However,
> RISC-V
> +is not compatible with SBBR. Thus, a EBBR compliant RISC-V platform would
> not be SBBR compliant.
This doesn't really flow well into the next paragraph and the examples
are a bit odd (everything written about RISC-V here also applies to the
other not-an-AArch64 architectures).
How about:
For example, a platform that support only Devicetree, or that
implements an instruction set to which SBBR does not apply,
could be EBBR compliant, but not SBBR compliant.
>
> By definition, all SBBR compliant systems are also EBBR compliant, but the
> converse is not true.
> @@ -228,6 +229,43 @@ This document uses the following terms and abbreviations.
> Original Equipment Manufacturer. In this document, the final device
> manufacturer.
>
> + RISC-V
> + An open standard Instruction Set Architecture (ISA) based on Reduced
> Instruction
> + Set Architecture (RISC).
> +
> + HART
> + Hardware thread in RISC-V. This is the hardware execution context that
> contains
> + all the state mandated by the ISA.
These need to be alphabetized.
> +
> + M Mode
> + Machine mode is the most secure and privileged mode in RISC-V.
> +
> + S Mode
> + Supervisor mode is the next secure mode where virtual memory is
> enabled.
Once alphabetized we probably need a way to call out architecture
dependanct jargon. It would be spelled out in the definition or,
alternatively, we could adopt a convention like:
EL3 (Armv8+ only)
Definition...
S Mode (RISC-V only)
Definition...
> +
> + HS Mode
> + Hypervisor-extended-supervisor mode which virtualizes the supervisor
> mode.
> +
> + U Mode
> + User mode where userspace application is expected to run.
> +
> + HSM
> + Hart State Management (HSM) is an SBI extension that enables the
> supervisor
> + mode software to implement ordered booting.
> +
> + SEE
> + Supervisor Execution Environment in RISC-V. This can be M mode or HS
> mode.
> +
> + SBI
> + Supervisor Binary Interface. This is an interface between SEE and
> supervisor
> + mode in RISC-V.
> +
> + RV32
> + 32 bit execution mode in RISC-V.
> +
> + RV64
> + 64 bit execution mode in RISC-V.
> +
> SiP
> Silicon Partner. In this document, the silicon manufacturer.
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index 74ef70e29784..ad9d9543555e 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -36,7 +36,7 @@ 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 in
> RISC-V.
>
> AArch64 Exception Levels
> ------------------------
> @@ -59,6 +59,14 @@ UEFI-compliant Operating System.
> In this instance, the UEFI boot-time environment can be provided, as a
> virtualized service, by the hypervisor and not as part of the host firmware.
>
> +RISC-V privilege levels
> +-----------------------
> +
> +UEFI shall execute in RV32/RV64 mode either in S or HS mode depending on
> whether
> +or not virtualization is supported in hardware and available at OS load time.
> +If the UEFI firmware is running in HS mode, the hypervisor is responsible for
> +providing the virtualized boot-time/runtime services.
> +
Why doesn't this follow the pattern used to describe for AArch64? I
would expect the preference for firmware to adopt HS mode apply to
RISC-V also (e.g. if the platform supports virtualization then we want
to hand over to the payload (Linux, Xen, etc) in HS mode.
Naturally if silicon that does not implement HS mode is common then
the equivalent of "Booting of UEFI at EL1 is most like within a
hypervisor..." would perhaps become "Booting of UEFI in S mode is likel
to be either because...".
> UEFI Boot Services
> ==================
>
> diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst
> index 9c51bca24f33..ad5c8fc17e40 100644
> --- a/source/chapter3-secureworld.rst
> +++ b/source/chapter3-secureworld.rst
> @@ -27,3 +27,17 @@ 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 firmware resident in M-mode or hypervisor running in HS mode must
> implement
Nitpicking but hyphenating M-mode is inconsistant with other uses.
Daniel.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
