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.patra@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.

On Fri, Oct 16, 2020 at 12:33:07PM -0700, Atish Patra wrote:

On Fri, Oct 16, 2020 at 4:29 AM Daniel Thompson daniel.thompson@linaro.org wrote:

...

On Thu, Oct 15, 2020 at 06:10:32PM -0700, Atish Patra wrote:

...

• 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

I'd prefer not to split up simply because much easier to look up unfamiliar terminology in one glossary than in four.

Of three options considered so far I like the (scope in brackets) approach best. It's a weakly held preference however.

...

...

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.

In the Arm world we can talk about "the likely reason" because hardware that do not implement EL2 are rare. You can dispense with the likely reasons if you like.

The more important statement is that: Most systems are expected to boot UEFI at EL2, to allow for the installation of a hypervisor or a virtualization aware Operating System.

Wouldn't this apply equally to RV systems that implement the hypervisor extensions? The default expectation is that they handover to the OS in HS mode.

Daniel.

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.patra@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/

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.

Details here:

https://developer.arm.com/architectures/system-architectures/arm-systemready https://developer.arm.com/documentation/den0044/latest

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.

• 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.

 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)`

•  <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.

On Wed, Oct 21, 2020 at 3:21 AM Grant Likely grant.likely@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.patra@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

We didn't meet this week due to a conflict with another meeting. There hasn't been any discussion aside from this thread.

g.

On 08/11/2020 23:40, Atish Patra wrote:

On Thu, Oct 22, 2020 at 4:19 PM Atish Patra atishp@atishpatra.org wrote:

...

On Wed, Oct 21, 2020 at 3:21 AM Grant Likely grant.likely@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.patra@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