On Fri, Oct 16, 2020 at 4:29 AM Daniel Thompson <[email protected]> wrote: > > 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 <[email protected]> > > --- > > 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. >
Sure. Looks good to me. I will update. > > > > > 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. > Sure. Will do that. > > + > > + 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... > Should we just create separate sections ? Generic UEFI ARM or split that into AArch32 & AArch64 RISC-V > > + > > + 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...". > That is probably true for the next couple of years as hypervisor extension is not yet ratified. However, HS mode may be very common in 5 years from now. That's why I did not want to make any assumption about which mode is more likely to boot UEFI. > > > > 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. > I will fix that in the next version. Thanks for the review. > > Daniel. > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
