On Wed, Oct 21, 2020 at 3:21 AM Grant Likely <grant.lik...@arm.com> wrote: > > Hi Atish, > > Thanks for this. Comments below. > > On 16/10/2020 02:10, 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 > > This hunk is a no-op change to the content and should be dropped from > the patch, but it's a good opportunity to bring up a writing(coding) > style comment. :-D As much as possible the EBBR source files should use > "semantic linefeeds" with one sentence per line because when changes are > made it eliminate diff hunks due to paragraph reflow. Here's how Brian > Kernighan described it: > > Hints for Preparing Documents > > Most documents go through several versions (always more than you > expected) before they are finally finished. > Accordingly, you should do whatever possible to make the job of > changing them easy. > > First, when you do the purely mechanical operations of typing, > type so subsequent editing will be easy. > Start each sentence on a new line. > Make lines short, and break lines at natural places, > such as after commas and semicolons, rather than randomly. > Since most people change documents by rewriting phrases and adding, > deleting and rearranging sentences, > these precautions simplify any editing you have to do later. > > Brian W. Kernighan, 1974 > > Source : http://rhodesmill.org/brandon/2012/one-sentence-per-line/ >
Got it. I will update it. > I'll propose a patch adding this guidance to the EBBR repo. > > > > 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 section is primarily commentary about the purpose of EBBR and how > it compares with other specifications. Rather than defining where EBBR > isn't aligned with SBBR, I'd rather rework the paragraph to state that > EBBR is aligned with SBBR on AArch64 platforms. How about this for new text? > > --- > This specification was inspired by the Server Base Boot Requirements > specification [SBBR]_ used by the Arm AArch64 architecture. > SBBR is targeted at the server ecosystem, > > and places strict requirements on the firmware interfaces presented to > OSes > to ensure cross vendor interoperability. > > Similarly, EBBR provides requirements on firmware interfaces > using many of the same technologies, > but provides more flexibility to support embedded designs > > which do not align with server platform requirements. > > > > EBBR strives to remain aligned with SBBR by requiring the same > interfaces where > possible, and ensuring EBBR requirements are not mutually exclusive to SBBR. > For example, SBBR requires an ACPI system description, > > but EBBR allows either ACPI or a Devicetree. > If ACPI support was added to an EBBR platform, > it would still retain EBBR compliance. > By definition, this means that all Arm SBBR compliant systems > > are also EBBR compliant, but the converse is not true. > --- > > I won't be committing this as-is because I still need to do a bit more > rework to transition from SBBR to BBR as part of Arm SystemReady. There > is a bunch of AArch64 text that will get pulled out of EBBR because > things like exception level handling are detailed properly in the BBR now. > But there can be a RISC-V specific privilege section in EBBR. Correct ? > Details here: > > https://developer.arm.com/architectures/system-architectures/arm-systemready > https://developer.arm.com/documentation/den0044/latest > I see the BBR also specifies the subset of UEFI boot time services & runtime services. Will those sections continue to exist in both places EBBR & BBR ? > > > > 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. > > Nit: "M Mode" here, but in the spec text "M-Mode" is used. Should be > identical. > Will do. > > + > > + 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. > + > > I disagree with Daniel. I think all the RISC-V specific terms should be > collected into a sub header, and the same should be done for ARM and > AArch64. Mixing architecture specific terms together seems confusing to me. > I will put them into a RISC-V specific sub header. > > 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..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 > > +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 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. There is > > no support > > + for ACPI in RISC-V yet. That's why, passing of the boot hart id via ACPI > > tables > > + has not been defined yet. > > 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) > > Should be `RISC-V Supervisor Binary Interface (SBI)` > Sure. Thanks for the review. > > + <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc>`_ > > + 11 October 2020, `RISC-V International <https://riscv.org/>`_ > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > 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
