This patch adds all the required content to make RISC-V EBBR compatible. The additional content is not a lot given that we just need to update the architecture specific sections for RISC-V. Rest of the document is ISA agnostic anyways.
Signed-off-by: Atish Patra atish.patra@wdc.com --- source/chapter1-about.rst | 83 ++++++++++++++++++++++++++------- source/chapter2-uefi.rst | 14 +++--- source/chapter3-secureworld.rst | 12 +++++ source/index.rst | 3 ++ source/references.rst | 4 ++ 5 files changed, 92 insertions(+), 24 deletions(-)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 52e61e80b7f9..feb3e7b59431 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -158,6 +158,8 @@ easily meet the stricter BBR requirements. By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true.
+This specification is also referenced by RISC-V platform specification [RVPLTSPEC]_. + Conventions Used in this Document =================================
@@ -181,14 +183,12 @@ This document uses the following terms and abbreviations.
.. glossary::
+AARCH64 +------- A64 The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.
- AArch32 - Arm 32-bit architectures. AArch32 is a roll up term referring to all - 32-bit versions of the Arm architecture starting at ARMv4. - AArch64 state The Arm 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and @@ -197,10 +197,6 @@ This document uses the following terms and abbreviations. AArch64 Execution state provides a single instruction set, A64.
- EFI Loaded Image - An executable image to be run under the UEFI environment, - and which uses boot time services. - EL0 The lowest Exception level on AArch64. The Exception level that is used to execute user applications, in Non-secure state. @@ -218,17 +214,56 @@ This document uses the following terms and abbreviations. execute Secure Monitor code, which handles the transitions between Non-secure and Secure states. EL3 is always in Secure state.
- Logical Unit (LU) - A logical unit (LU) is an externally addressable, independent entity - within a device. In the context of storage, a single device may use - logical units to provide multiple independent storage areas. +ARM +--- + AArch32 + Arm 32-bit architectures. AArch32 is a roll up term referring to all + 32-bit versions of the Arm architecture starting at ARMv4.
- OEM - Original Equipment Manufacturer. In this document, the final device - manufacturer. +RISC-V +------ + HART + Hardware thread in RISC-V. This is the hardware execution context that contains + all the state mandated by the ISA.
- SiP - Silicon Partner. In this document, the silicon manufacturer. + HSM + Hart State Management (HSM) is an SBI extension that enables the supervisor + mode software to implement ordered booting. + + HS Mode + Hypervisor-extended-supervisor mode which virtualizes the supervisor mode. + + M Mode + Machine mode is the most secure and privileged mode in RISC-V. + + RISC-V + An open standard Instruction Set Architecture (ISA) based on + Reduced Instruction Set Architecture (RISC). + + RV32 + 32 bit execution mode in RISC-V. + + RV64 + 64 bit execution mode in RISC-V. + + RISC-V Supervisor Binary Interface (SBI) + Supervisor Binary Interface. This is an interface between SEE and supervisor + mode in RISC-V. + + SEE + Supervisor Execution Environment in RISC-V. This can be M mode or HS mode. + + S Mode + Supervisor mode is the next privilege mode after M mode where virtual memory is enabled. + + U Mode + User mode is the least privilege mode where user-space application is expected to run. + +UEFI +---- + EFI Loaded Image + An executable image to be run under the UEFI environment, + and which uses boot time services.
UEFI Unified Extensible Firmware Interface. @@ -240,3 +275,17 @@ This document uses the following terms and abbreviations. UEFI Runtime Services Functionality that is provided to an Operating System after the ExitBootServices() call. + +Miscellaneous +------------- + Logical Unit (LU) + A logical unit (LU) is an externally addressable, independent entity + within a device. In the context of storage, a single device may use + logical units to provide multiple independent storage areas. + + OEM + Original Equipment Manufacturer. In this document, the final device + manufacturer. + + SiP + Silicon Partner. In this document, the silicon manufacturer. diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 53c962ab5c25..4810096a7fd5 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -209,24 +209,24 @@ 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 on RISC-V.
-AArch64 Exception Levels +Exception Levels ------------------------
-On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, +UEFI shall execute as 64-bit code at either EL1 or EL2 (on AArch64) and at HS mode or S mode (on RISC-V), depending on whether or not virtualization is available at OS load time.
-UEFI Boot at EL2 +UEFI Boot at EL2/HS mode ^^^^^^^^^^^^^^^^
-Most systems are expected to boot UEFI at EL2, to allow for the installation of +Most systems are expected to boot UEFI at EL2/HS mode, to allow for the installation of a hypervisor or a virtualization aware Operating System.
-UEFI Boot at EL1 +UEFI Boot at EL1/S Mode ^^^^^^^^^^^^^^^^
-Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest +Booting of UEFI at EL1/S mode is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..d6bfbd322837 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,15 @@ 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 resident firmware in M mode or hypervisor running in HS mode must implement +and conform to at least SBI [RVSBISPEC]_ 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. The corresponding entry +in the ACPI tables has not been defined yet as ACPI support in RISC-V is under progress. diff --git a/source/index.rst b/source/index.rst index 48318757f717..acd214d25323 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,5 +1,6 @@ .. EBBR Source Document Copyright Arm Limited, 2017-2019 + Copyright Western Digital Corporation or its affiliates, 2021 SPDX-License-Identifier: CC-BY-SA-4.0
#################################################### @@ -8,6 +9,8 @@ Embedded Base Boot Requirements (EBBR) Specification
Copyright © 2017-2019 Arm Limited and Contributors.
+Copyright © 2021 Western Digital Corporation or its affiliates. + This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to diff --git a/source/references.rst b/source/references.rst index 6d09d3c0aaa7..6d35d909c8fe 100644 --- a/source/references.rst +++ b/source/references.rst @@ -29,3 +29,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`_ + +.. [RVPLTSPEC] `RISC-V Platform specification https://github.com/riscv/riscv-platform-specs`_ + +.. [RVSBISPEC] `RISC-V Supervisor Binary Interface specification https://github.com/riscv/riscv-sbi-doc`_
On 06.05.21 09:06, Atish Patra wrote:
This patch adds all the required content to make RISC-V EBBR compatible. The additional content is not a lot given that we just need to update the architecture specific sections for RISC-V. Rest of the document is ISA agnostic anyways.
Signed-off-by: Atish Patra atish.patra@wdc.com
source/chapter1-about.rst | 83 ++++++++++++++++++++++++++------- source/chapter2-uefi.rst | 14 +++--- source/chapter3-secureworld.rst | 12 +++++ source/index.rst | 3 ++ source/references.rst | 4 ++ 5 files changed, 92 insertions(+), 24 deletions(-)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 52e61e80b7f9..feb3e7b59431 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -158,6 +158,8 @@ easily meet the stricter BBR requirements. By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true.
+This specification is also referenced by RISC-V platform specification [RVPLTSPEC]_.
Conventions Used in this Document
@@ -181,14 +183,12 @@ This document uses the following terms and abbreviations.
.. glossary::
+AARCH64
This heading could simply be called ARM as the list comprises both 32 and 64bit terms.
+------- A64 The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.
- AArch32
Arm 32-bit architectures. AArch32 is a roll up term referring to all32-bit versions of the Arm architecture starting at ARMv4.
Under the heading ARM we can keep this here.
AArch64 state The Arm 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and@@ -197,10 +197,6 @@ This document uses the following terms and abbreviations. AArch64 Execution state provides a single instruction set, A64.
- EFI Loaded Image
An executable image to be run under the UEFI environment,and which uses boot time services.- EL0 The lowest Exception level on AArch64. The Exception level that is used to execute user applications, in Non-secure state.
@@ -218,17 +214,56 @@ This document uses the following terms and abbreviations. execute Secure Monitor code, which handles the transitions between Non-secure and Secure states. EL3 is always in Secure state.
- Logical Unit (LU)
A logical unit (LU) is an externally addressable, independent entitywithin a device. In the context of storage, a single device may uselogical units to provide multiple independent storage areas.+ARM +---
- AArch32
Arm 32-bit architectures. AArch32 is a roll up term referring to all32-bit versions of the Arm architecture starting at ARMv4.
Just leave AArch32 where it is.
- OEM
Original Equipment Manufacturer. In this document, the final devicemanufacturer.+RISC-V +------
- HART
Hardware thread in RISC-V. This is the hardware execution context that containsall the state mandated by the ISA.
- SiP
Silicon Partner. In this document, the silicon manufacturer.
- HSM
Hart State Management (HSM) is an SBI extension that enables the supervisormode software to implement ordered booting.- HS Mode
Hypervisor-extended-supervisor mode which virtualizes the supervisor mode.- M Mode
Machine mode is the most secure and privileged mode in RISC-V.- RISC-V
An open standard Instruction Set Architecture (ISA) based onReduced Instruction Set Architecture (RISC).- RV32
32 bit execution mode in RISC-V.- RV64
64 bit execution mode in RISC-V.- RISC-V Supervisor Binary Interface (SBI)
Supervisor Binary Interface. This is an interface between SEE and supervisormode in RISC-V.- SEE
Supervisor Execution Environment in RISC-V. This can be M mode or HS mode.- S Mode
Supervisor mode is the next privilege mode after M mode where virtual memory is enabled.
I am missing VS mode here.
- U Mode
User mode is the least privilege mode where user-space application is expected to run.+UEFI +----
EFI Loaded Image
An executable image to be run under the UEFI environment,and which uses boot time services.UEFI Unified Extensible Firmware Interface.
@@ -240,3 +275,17 @@ This document uses the following terms and abbreviations. UEFI Runtime Services Functionality that is provided to an Operating System after the ExitBootServices() call.
+Miscellaneous +-------------
- Logical Unit (LU)
A logical unit (LU) is an externally addressable, independent entitywithin a device. In the context of storage, a single device may uselogical units to provide multiple independent storage areas.- OEM
Original Equipment Manufacturer. In this document, the final devicemanufacturer.- SiP
Silicon Partner. In this document, the silicon manufacturer.diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 53c962ab5c25..4810096a7fd5 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -209,24 +209,24 @@ 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 on RISC-V.
-AArch64 Exception Levels
+Exception Levels
-On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, +UEFI shall execute as 64-bit code at either EL1 or EL2 (on AArch64) and at HS mode or S mode (on RISC-V), depending on whether or not virtualization is available at OS load time.
-UEFI Boot at EL2 +UEFI Boot at EL2/HS mode ^^^^^^^^^^^^^^^^
'make html' produces a warning: source/chapter2-uefi.rst:221: WARNING: Title underline too short.
The hypervisor extension is still draft? I could not find anything newer than https://github.com/riscv/riscv-isa-manual/blob/master/src/hypervisor.tex.
-Most systems are expected to boot UEFI at EL2, to allow for the installation of +Most systems are expected to boot UEFI at EL2/HS mode, to allow for the installation of a hypervisor or a virtualization aware Operating System.
-UEFI Boot at EL1 +UEFI Boot at EL1/S Mode ^^^^^^^^^^^^^^^^
source/chapter2-uefi.rst:227: WARNING: Title underline too short.
According to the 0.6.1 draft of the hypervisor extension the guest is running in VS-mode.
S-mode is used by systems without hypervisor extension.
The following image would be helpful here:
https://raw.githubusercontent.com/riscv/riscv-sbi-doc/master/riscv-sbi-intro...
The image is licensed under CC-BY 4.0. So it should be allowable to add it to the EBBR.
@Grant: Is there a free version of https://documentation-service.arm.com/static/602a712462b3ab66934ed42f?token= or can ARM release the image under the CC-BY 4.0 license?
Best regards
Heinrich
-Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest +Booting of UEFI at EL1/S mode is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..d6bfbd322837 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,15 @@ 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 resident firmware in M mode or hypervisor running in HS mode must implement +and conform to at least SBI [RVSBISPEC]_ 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. The corresponding entry +in the ACPI tables has not been defined yet as ACPI support in RISC-V is under progress. diff --git a/source/index.rst b/source/index.rst index 48318757f717..acd214d25323 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,5 +1,6 @@ .. EBBR Source Document Copyright Arm Limited, 2017-2019
- Copyright Western Digital Corporation or its affiliates, 2021 SPDX-License-Identifier: CC-BY-SA-4.0
#################################################### @@ -8,6 +9,8 @@ Embedded Base Boot Requirements (EBBR) Specification
Copyright © 2017-2019 Arm Limited and Contributors.
+Copyright © 2021 Western Digital Corporation or its affiliates.
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to diff --git a/source/references.rst b/source/references.rst index 6d09d3c0aaa7..6d35d909c8fe 100644 --- a/source/references.rst +++ b/source/references.rst @@ -29,3 +29,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`_
+.. [RVPLTSPEC] `RISC-V Platform specification https://github.com/riscv/riscv-platform-specs`_
+.. [RVSBISPEC] `RISC-V Supervisor Binary Interface specification https://github.com/riscv/riscv-sbi-doc`_
On Thu, May 6, 2021 at 2:24 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.21 09:06, Atish Patra wrote:
This patch adds all the required content to make RISC-V EBBR compatible. The additional content is not a lot given that we just need to update the architecture specific sections for RISC-V. Rest of the document is ISA agnostic anyways.
Signed-off-by: Atish Patra atish.patra@wdc.com
source/chapter1-about.rst | 83 ++++++++++++++++++++++++++------- source/chapter2-uefi.rst | 14 +++--- source/chapter3-secureworld.rst | 12 +++++ source/index.rst | 3 ++ source/references.rst | 4 ++ 5 files changed, 92 insertions(+), 24 deletions(-)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 52e61e80b7f9..feb3e7b59431 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -158,6 +158,8 @@ easily meet the stricter BBR requirements. By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true.
+This specification is also referenced by RISC-V platform specification [RVPLTSPEC]_.
Conventions Used in this Document
@@ -181,14 +183,12 @@ This document uses the following terms and abbreviations.
.. glossary::
+AARCH64
This heading could simply be called ARM as the list comprises both 32 and 64bit terms.
+------- A64 The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.
- AArch32
Arm 32-bit architectures. AArch32 is a roll up term referring to all32-bit versions of the Arm architecture starting at ARMv4.Under the heading ARM we can keep this here.
Grant had earlier suggested to use separate headers for ARM/AARCH64. I can keep them together if it is fine by him.
AArch64 state The Arm 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and@@ -197,10 +197,6 @@ This document uses the following terms and abbreviations. AArch64 Execution state provides a single instruction set, A64.
- EFI Loaded Image
An executable image to be run under the UEFI environment,and which uses boot time services.- EL0 The lowest Exception level on AArch64. The Exception level that is used to execute user applications, in Non-secure state.
@@ -218,17 +214,56 @@ This document uses the following terms and abbreviations. execute Secure Monitor code, which handles the transitions between Non-secure and Secure states. EL3 is always in Secure state.
- Logical Unit (LU)
A logical unit (LU) is an externally addressable, independent entitywithin a device. In the context of storage, a single device may uselogical units to provide multiple independent storage areas.+ARM +---
- AArch32
Arm 32-bit architectures. AArch32 is a roll up term referring to all32-bit versions of the Arm architecture starting at ARMv4.Just leave AArch32 where it is.
- OEM
Original Equipment Manufacturer. In this document, the final devicemanufacturer.+RISC-V +------
- HART
Hardware thread in RISC-V. This is the hardware execution context that containsall the state mandated by the ISA.
- SiP
Silicon Partner. In this document, the silicon manufacturer.
- HSM
Hart State Management (HSM) is an SBI extension that enables the supervisormode software to implement ordered booting.- HS Mode
Hypervisor-extended-supervisor mode which virtualizes the supervisor mode.- M Mode
Machine mode is the most secure and privileged mode in RISC-V.- RISC-V
An open standard Instruction Set Architecture (ISA) based onReduced Instruction Set Architecture (RISC).- RV32
32 bit execution mode in RISC-V.- RV64
64 bit execution mode in RISC-V.- RISC-V Supervisor Binary Interface (SBI)
Supervisor Binary Interface. This is an interface between SEE and supervisormode in RISC-V.- SEE
Supervisor Execution Environment in RISC-V. This can be M mode or HS mode.- S Mode
Supervisor mode is the next privilege mode after M mode where virtual memory is enabled.I am missing VS mode here.
Sure. I will add it.
- U Mode
User mode is the least privilege mode where user-space application is expected to run.+UEFI +----
EFI Loaded Image
An executable image to be run under the UEFI environment,and which uses boot time services.UEFI Unified Extensible Firmware Interface.
@@ -240,3 +275,17 @@ This document uses the following terms and abbreviations. UEFI Runtime Services Functionality that is provided to an Operating System after the ExitBootServices() call.
+Miscellaneous +-------------
- Logical Unit (LU)
A logical unit (LU) is an externally addressable, independent entitywithin a device. In the context of storage, a single device may uselogical units to provide multiple independent storage areas.- OEM
Original Equipment Manufacturer. In this document, the final devicemanufacturer.- SiP
Silicon Partner. In this document, the silicon manufacturer.diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 53c962ab5c25..4810096a7fd5 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -209,24 +209,24 @@ 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 on RISC-V.
-AArch64 Exception Levels
+Exception Levels
-On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, +UEFI shall execute as 64-bit code at either EL1 or EL2 (on AArch64) and at HS mode or S mode (on RISC-V), depending on whether or not virtualization is available at OS load time.
-UEFI Boot at EL2 +UEFI Boot at EL2/HS mode ^^^^^^^^^^^^^^^^
'make html' produces a warning: source/chapter2-uefi.rst:221: WARNING: Title underline too short.
The hypervisor extension is still draft? I could not find anything newer than https://github.com/riscv/riscv-isa-manual/blob/master/src/hypervisor.tex.
Unfortunately, yes. Nobody is happy about that but the spec is not frozen yet. http://lists.infradead.org/pipermail/linux-riscv/2021-April/005804.html
-Most systems are expected to boot UEFI at EL2, to allow for the installation of +Most systems are expected to boot UEFI at EL2/HS mode, to allow for the installation of a hypervisor or a virtualization aware Operating System.
-UEFI Boot at EL1 +UEFI Boot at EL1/S Mode ^^^^^^^^^^^^^^^^
source/chapter2-uefi.rst:227: WARNING: Title underline too short.
Thanks. I will fix that in the next version.
According to the 0.6.1 draft of the hypervisor extension the guest is running in VS-mode.
S-mode is used by systems without hypervisor extension.
Yes. I wanted to keep them in one section. Looking at again, I think we should create a new RISC-V specific section called "RISC-V privilege levels" to avoid confusion.
The following image would be helpful here:
https://raw.githubusercontent.com/riscv/riscv-sbi-doc/master/riscv-sbi-intro...
The image is licensed under CC-BY 4.0. So it should be allowable to add it to the EBBR.
Sure. I will add that.
@Grant: Is there a free version of https://documentation-service.arm.com/static/602a712462b3ab66934ed42f?token= or can ARM release the image under the CC-BY 4.0 license?
Best regards
Heinrich
-Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest +Booting of UEFI at EL1/S mode is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..d6bfbd322837 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,15 @@ 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 resident firmware in M mode or hypervisor running in HS mode must implement +and conform to at least SBI [RVSBISPEC]_ 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. The corresponding entry +in the ACPI tables has not been defined yet as ACPI support in RISC-V is under progress. diff --git a/source/index.rst b/source/index.rst index 48318757f717..acd214d25323 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,5 +1,6 @@ .. EBBR Source Document Copyright Arm Limited, 2017-2019
- Copyright Western Digital Corporation or its affiliates, 2021 SPDX-License-Identifier: CC-BY-SA-4.0
#################################################### @@ -8,6 +9,8 @@ Embedded Base Boot Requirements (EBBR) Specification
Copyright © 2017-2019 Arm Limited and Contributors.
+Copyright © 2021 Western Digital Corporation or its affiliates.
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to diff --git a/source/references.rst b/source/references.rst index 6d09d3c0aaa7..6d35d909c8fe 100644 --- a/source/references.rst +++ b/source/references.rst @@ -29,3 +29,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`_
+.. [RVPLTSPEC] `RISC-V Platform specification https://github.com/riscv/riscv-platform-specs`_
+.. [RVSBISPEC] `RISC-V Supervisor Binary Interface specification https://github.com/riscv/riscv-sbi-doc`_
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 06.05.21 15:32, Atish Patra wrote:
On Thu, May 6, 2021 at 2:24 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.21 09:06, Atish Patra wrote:
This patch adds all the required content to make RISC-V EBBR compatible. The additional content is not a lot given that we just need to update the architecture specific sections for RISC-V. Rest of the document is ISA agnostic anyways.
Signed-off-by: Atish Patra atish.patra@wdc.com
source/chapter1-about.rst | 83 ++++++++++++++++++++++++++------- source/chapter2-uefi.rst | 14 +++--- source/chapter3-secureworld.rst | 12 +++++ source/index.rst | 3 ++ source/references.rst | 4 ++ 5 files changed, 92 insertions(+), 24 deletions(-)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 52e61e80b7f9..feb3e7b59431 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -158,6 +158,8 @@ easily meet the stricter BBR requirements. By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true.
+This specification is also referenced by RISC-V platform specification [RVPLTSPEC]_.
Conventions Used in this Document
@@ -181,14 +183,12 @@ This document uses the following terms and abbreviations.
.. glossary::
+AARCH64
This heading could simply be called ARM as the list comprises both 32 and 64bit terms.
+------- A64 The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.
- AArch32
Arm 32-bit architectures. AArch32 is a roll up term referring to all32-bit versions of the Arm architecture starting at ARMv4.Under the heading ARM we can keep this here.
Grant had earlier suggested to use separate headers for ARM/AARCH64. I can keep them together if it is fine by him.
AArch64 state The Arm 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and@@ -197,10 +197,6 @@ This document uses the following terms and abbreviations. AArch64 Execution state provides a single instruction set, A64.
- EFI Loaded Image
An executable image to be run under the UEFI environment,and which uses boot time services.- EL0 The lowest Exception level on AArch64. The Exception level that is used to execute user applications, in Non-secure state.
@@ -218,17 +214,56 @@ This document uses the following terms and abbreviations. execute Secure Monitor code, which handles the transitions between Non-secure and Secure states. EL3 is always in Secure state.
- Logical Unit (LU)
A logical unit (LU) is an externally addressable, independent entitywithin a device. In the context of storage, a single device may uselogical units to provide multiple independent storage areas.+ARM +---
- AArch32
Arm 32-bit architectures. AArch32 is a roll up term referring to all32-bit versions of the Arm architecture starting at ARMv4.Just leave AArch32 where it is.
- OEM
Original Equipment Manufacturer. In this document, the final devicemanufacturer.+RISC-V +------
- HART
Hardware thread in RISC-V. This is the hardware execution context that containsall the state mandated by the ISA.
- SiP
Silicon Partner. In this document, the silicon manufacturer.
- HSM
Hart State Management (HSM) is an SBI extension that enables the supervisormode software to implement ordered booting.- HS Mode
Hypervisor-extended-supervisor mode which virtualizes the supervisor mode.- M Mode
Machine mode is the most secure and privileged mode in RISC-V.- RISC-V
An open standard Instruction Set Architecture (ISA) based onReduced Instruction Set Architecture (RISC).- RV32
32 bit execution mode in RISC-V.- RV64
64 bit execution mode in RISC-V.- RISC-V Supervisor Binary Interface (SBI)
Supervisor Binary Interface. This is an interface between SEE and supervisormode in RISC-V.- SEE
Supervisor Execution Environment in RISC-V. This can be M mode or HS mode.- S Mode
Supervisor mode is the next privilege mode after M mode where virtual memory is enabled.I am missing VS mode here.
Sure. I will add it.
- U Mode
User mode is the least privilege mode where user-space application is expected to run.+UEFI +----
EFI Loaded Image
An executable image to be run under the UEFI environment,and which uses boot time services.UEFI Unified Extensible Firmware Interface.
@@ -240,3 +275,17 @@ This document uses the following terms and abbreviations. UEFI Runtime Services Functionality that is provided to an Operating System after the ExitBootServices() call.
+Miscellaneous +-------------
- Logical Unit (LU)
A logical unit (LU) is an externally addressable, independent entitywithin a device. In the context of storage, a single device may uselogical units to provide multiple independent storage areas.- OEM
Original Equipment Manufacturer. In this document, the final devicemanufacturer.- SiP
Silicon Partner. In this document, the silicon manufacturer.diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 53c962ab5c25..4810096a7fd5 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -209,24 +209,24 @@ 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 on RISC-V.
-AArch64 Exception Levels
+Exception Levels
-On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, +UEFI shall execute as 64-bit code at either EL1 or EL2 (on AArch64) and at HS mode or S mode (on RISC-V), depending on whether or not virtualization is available at OS load time.
-UEFI Boot at EL2 +UEFI Boot at EL2/HS mode ^^^^^^^^^^^^^^^^
'make html' produces a warning: source/chapter2-uefi.rst:221: WARNING: Title underline too short.
The hypervisor extension is still draft? I could not find anything newer than https://github.com/riscv/riscv-isa-manual/blob/master/src/hypervisor.tex.
Unfortunately, yes. Nobody is happy about that but the spec is not frozen yet. http://lists.infradead.org/pipermail/linux-riscv/2021-April/005804.html
The principal design with exception levels M, HS, VS, VU is not under discussion for the H-extension. So I am fine with referencing these in EBBR.
We should add a reference to the draft specification and mention that it is draft.
-Most systems are expected to boot UEFI at EL2, to allow for the installation of +Most systems are expected to boot UEFI at EL2/HS mode, to allow for the installation of a hypervisor or a virtualization aware Operating System.
-UEFI Boot at EL1 +UEFI Boot at EL1/S Mode ^^^^^^^^^^^^^^^^
source/chapter2-uefi.rst:227: WARNING: Title underline too short.
Thanks. I will fix that in the next version.
According to the 0.6.1 draft of the hypervisor extension the guest is running in VS-mode.
S-mode is used by systems without hypervisor extension.
Yes. I wanted to keep them in one section. Looking at again, I think we should create a new RISC-V specific section called "RISC-V privilege levels" to avoid confusion.
There we could mention systems with and without H-extension.
Best regards
Heinrich
The following image would be helpful here:
https://raw.githubusercontent.com/riscv/riscv-sbi-doc/master/riscv-sbi-intro...
The image is licensed under CC-BY 4.0. So it should be allowable to add it to the EBBR.
Sure. I will add that.
@Grant: Is there a free version of https://documentation-service.arm.com/static/602a712462b3ab66934ed42f?token= or can ARM release the image under the CC-BY 4.0 license?
Best regards
Heinrich
-Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest +Booting of UEFI at EL1/S mode is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..d6bfbd322837 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,15 @@ 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 resident firmware in M mode or hypervisor running in HS mode must implement +and conform to at least SBI [RVSBISPEC]_ 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. The corresponding entry +in the ACPI tables has not been defined yet as ACPI support in RISC-V is under progress. diff --git a/source/index.rst b/source/index.rst index 48318757f717..acd214d25323 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,5 +1,6 @@ .. EBBR Source Document Copyright Arm Limited, 2017-2019
- Copyright Western Digital Corporation or its affiliates, 2021 SPDX-License-Identifier: CC-BY-SA-4.0
#################################################### @@ -8,6 +9,8 @@ Embedded Base Boot Requirements (EBBR) Specification
Copyright © 2017-2019 Arm Limited and Contributors.
+Copyright © 2021 Western Digital Corporation or its affiliates.
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to diff --git a/source/references.rst b/source/references.rst index 6d09d3c0aaa7..6d35d909c8fe 100644 --- a/source/references.rst +++ b/source/references.rst @@ -29,3 +29,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`_
+.. [RVPLTSPEC] `RISC-V Platform specification https://github.com/riscv/riscv-platform-specs`_
+.. [RVSBISPEC] `RISC-V Supervisor Binary Interface specification https://github.com/riscv/riscv-sbi-doc`_
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture@lists.linaro.org
-
Atish Patra -
Atish Patra -
Heinrich Schuchardt