On Thu, Oct 22, 2020 at 4:19 PM Atish Patra <ati...@atishpatra.org> wrote: > > 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 ? >
Apologies if these things were discussed in the EBBR meeting. I am unable to attend it because of RISC-V platform specification meetings. Any comments on this ? > > 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 ? > Any comments on this ? > > > > > > 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 -- Regards, Atish _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
