Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra <atish.pa...@wdc.com>: >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 | 13 ++++++++++ > source/references.rst | 4 ++++ > 4 files changed, 66 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. > >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. >+ >+ 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. >+ >+ 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. >+ > UEFI Boot Services > ================== > >diff --git a/source/chapter3-secureworld.rst >b/source/chapter3-secureworld.rst >index 9c51bca24f33..1551aa90c349 100644 >--- a/source/chapter3-secureworld.rst >+++ b/source/chapter3-secureworld.rst >@@ -27,3 +27,16 @@ 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 >+and conform to at least Supervisor Binary Specification [SBI]_ v0.2 >with HART >+State Management(HSM) extension for both RV32 and RV64. In addition to >that, the >+firmware must ensure the following conditions before jumping to the >UEFI >+application. >+ - a0 must always contain the hart id of the booting hart. >+ - a1 must always contain the memory address of the device tree.
I think this is only true for the non-EFI entry-point of Linux. The EFI entry point expects the system table and the image handle as only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table. >+ - The device tree must contain a property named **boot-hartid** >under */chosen* node. %/under/under the/ How is this modelled when using an ACPI table and not a device tree? Best regards Heinrich >+ This property must indicate the id of the booting hart. >diff --git a/source/references.rst b/source/references.rst >index 1eb05090647e..9c96cb977c7e 100644 >--- a/source/references.rst >+++ b/source/references.rst >@@ -23,3 +23,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>`_ >+ >+.. [SBI] `Supervisor Binary Interface (SBI) >+ ><https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc>`_ >+ 11 October 2020, `RISC-V International <https://riscv.org/>`_ >-- >2.28.0 > >_______________________________________________ >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
