This patch series adds RISC-V compatibility content to EBBR. 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. I am not sure about the copyrights though. There are two places where copyrights are present. I have added Western Digital copyright for the index.rst but I have not added it for conf.py as it goes into the first page of the EBBR specification.
Should we add multiple lines of copyrights or just keep copyrights at one place ? I am open to any other suggestions as well.
The series is also available in my github repo.
https://github.com/atishp04/ebbr/tree/riscv_update
Atish Patra (2): Add Western Digital copyright Add RISC-V support content to the EBBR specification
source/chapter1-about.rst | 42 +++++++++++++++++++++++++++++++-- source/chapter2-uefi.rst | 10 +++++++- source/chapter3-secureworld.rst | 13 ++++++++++ source/index.rst | 3 +++ source/references.rst | 4 ++++ 5 files changed, 69 insertions(+), 3 deletions(-)
-- 2.28.0
Signed-off-by: Atish Patra atish.patra@wdc.com --- source/index.rst | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/source/index.rst b/source/index.rst index bf2dadf3be47..6758994c5bbf 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, 2020 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 © Western Digital Corporation or its affiliates, 2020. + 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
On 13/10/2020 19:39, Atish Patra wrote:
Signed-off-by: Atish Patra atish.patra@wdc.com
No need for this to be a separate patch. Squash into patch 2 please where the additional copyright text is actually added.
source/index.rst | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/source/index.rst b/source/index.rst index bf2dadf3be47..6758994c5bbf 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, 2020
These copyright statements should be specific. Just "Western Digital Corporation" please. Affiliates can provide their own copyright lines if they care.
The "and Contributors" bit from the Arm line is historical from when the document was forked from SBBR. I'll look to clean that up.
g.
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 © Western Digital Corporation or its affiliates, 2020.
- 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
On 21.10.20 14:41, Grant Likely wrote:
On 13/10/2020 19:39, Atish Patra wrote:
Signed-off-by: Atish Patra atish.patra@wdc.com
No need for this to be a separate patch. Squash into patch 2 please where the additional copyright text is actually added.
source/index.rst | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/source/index.rst b/source/index.rst index bf2dadf3be47..6758994c5bbf 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, 2020
These copyright statements should be specific. Just "Western Digital Corporation" please. Affiliates can provide their own copyright lines if they care.
The "and Contributors" bit from the Arm line is historical from when the document was forked from SBBR. I'll look to clean that up.
I think "and Contributors" makes sense to comprise all those contributors that are not affiliated to ARM or WDC. Some are mentioned in the git log. Others contributed in the numerous discussion rounds or via mail.
Best regards
Heinrich
g.
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 © Western Digital Corporation or its affiliates, 2020.
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
On Wed, Oct 21, 2020 at 5:42 AM Grant Likely grant.likely@arm.com wrote:
On 13/10/2020 19:39, Atish Patra wrote:
Signed-off-by: Atish Patra atish.patra@wdc.com
No need for this to be a separate patch. Squash into patch 2 please where the additional copyright text is actually added.
Sure. I will do that.
source/index.rst | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/source/index.rst b/source/index.rst index bf2dadf3be47..6758994c5bbf 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, 2020
These copyright statements should be specific. Just "Western Digital Corporation" please. Affiliates can provide their own copyright lines if they care.
I think Affiliates here means any subsidiaries of Western Digital. IIRC, this is what our legal has approved for the copyrights. I will check with legal and update this if required.
The "and Contributors" bit from the Arm line is historical from when the document was forked from SBBR. I'll look to clean that up.
g.
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 © Western Digital Corporation or its affiliates, 2020.
- 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
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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. + + 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. + 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..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to the UEFI +application. + - a0 must always contain the hart id of the booting hart. + - a1 must always contain the memory address of the device tree. + - The device tree must contain a property named **boot-hartid** under */chosen* node. + This property must indicate the id of the booting hart. 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) + https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_ + 11 October 2020, `RISC-V International https://riscv.org/`_
Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra atish.patra@wdc.com:
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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 onReduced Instruction
Set Architecture (RISC).- HART
Hardware thread in RISC-V. This is the hardware executioncontext that contains
all the state mandated by the ISA.- 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 isenabled.
- HS Mode
Hypervisor-extended-supervisor mode which virtualizes thesupervisor mode.
- U Mode
User mode where userspace application is expected to run.- HSM
Hart State Management (HSM) is an SBI extension that enables thesupervisor
mode software to implement ordered booting.- SEE
Supervisor Execution Environment in RISC-V. This can be M modeor HS mode.
- SBI
Supervisor Binary Interface. This is an interface between SEEand 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.
UEFI Boot Services
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to the UEFI +application.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
I think this is only true for the non-EFI entry-point of Linux.
The EFI entry point expects the system table and the image handle as only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table.
- The device tree must contain a property named **boot-hartid**
under */chosen* node.
%/under/under the/
How is this modelled when using an ACPI table and not a device tree?
Best regards
Heinrich
This property must indicate the id of the booting hart.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)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_
11 October 2020, `RISC-V International <https://riscv.org/>`_-- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra atish.patra@wdc.com:
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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 onReduced Instruction
Set Architecture (RISC).- HART
Hardware thread in RISC-V. This is the hardware executioncontext that contains
all the state mandated by the ISA.- 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 isenabled.
- HS Mode
Hypervisor-extended-supervisor mode which virtualizes thesupervisor mode.
- U Mode
User mode where userspace application is expected to run.- HSM
Hart State Management (HSM) is an SBI extension that enables thesupervisor
mode software to implement ordered booting.- SEE
Supervisor Execution Environment in RISC-V. This can be M modeor HS mode.
- SBI
Supervisor Binary Interface. This is an interface between SEEand 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.
UEFI Boot Services
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to the UEFI +application.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
I think this is only true for the non-EFI entry-point of Linux.
Sorry. I should have been more verbose here. The first two conditions should be set by the uefi application before jumping to OS. In the Linux case, EFI stub should set these values before jumping to real Linux.
How about this:
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 */chosen* node. This property must indicate the id of the booting hart. The firmware application must ensure the following condition before jumping to the operating system. - a0 must always contain the hart id of the booting hart. - a1 must always contain the memory address of the device tree.
The EFI entry point expects the system table and the image handle as only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table.
Yes. EFI entry point arguments are defined by UEFI specification. So we don't need to specify that.
- The device tree must contain a property named **boot-hartid**
under */chosen* node.
%/under/under the/
Thanks. I will fix that.
How is this modelled when using an ACPI table and not a device tree?
Currently, there is no ACPI design for RISC-V. I guess we need to revisit this when we define ACPI for RISC-V.
Best regards
Heinrich
This property must indicate the id of the booting hart.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)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_
11 October 2020, `RISC-V International <https://riscv.org/>`_-- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra atishp@atishpatra.org:
On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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 onReduced Instruction
Set Architecture (RISC).- HART
Hardware thread in RISC-V. This is the hardware executioncontext that contains
all the state mandated by the ISA.- M Mode
Machine mode is the most secure and privileged mode inRISC-V.
- S Mode
Supervisor mode is the next secure mode where virtual memoryis
enabled.
- HS Mode
Hypervisor-extended-supervisor mode which virtualizes thesupervisor mode.
- U Mode
User mode where userspace application is expected to run.- HSM
Hart State Management (HSM) is an SBI extension that enablesthe
supervisor
mode software to implement ordered booting.- SEE
Supervisor Execution Environment in RISC-V. This can be Mmode
or HS mode.
- SBI
Supervisor Binary Interface. This is an interface between SEEand 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.
UEFI Boot Services
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to the UEFI +application.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
I think this is only true for the non-EFI entry-point of Linux.
Sorry. I should have been more verbose here. The first two conditions should be set by the uefi application before jumping to OS. In the Linux case, EFI stub should set these values before jumping to real Linux.
How about this:
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 */chosen* node. This property must indicate the id of the booting hart. The firmware application must ensure the following condition before jumping to the operating system.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
The OS entry point is where the system table and the image handle are passed.
Yes, currently the Linux EFI stub calls some legacy entry point with a0, a1 in the way you describe. But if they tomorrow pass the information on the stack or via a fixed memory location or whatever it is fine too. It is just a hidden implementation detail in the depth of the application "Linux" that makes no difference to the UEFI world.
I see no need to mention this Linux specific and internal stuff in the EBBR spec.
The EFI entry point expects the system table and the image handle as
only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table.
Yes. EFI entry point arguments are defined by UEFI specification. So we don't need to specify that.
- The device tree must contain a property named **boot-hartid**
under */chosen* node.
%/under/under the/
Thanks. I will fix that.
How is this modelled when using an ACPI table and not a device tree?
Currently, there is no ACPI design for RISC-V. I guess we need to revisit this when we define ACPI for RISC-V.
Maybe mention it as a TODO, e.g.
"Passing of the boot hart id via ACPI tables has not been defined yet."
Best regards
Heinrich
This property must indicate the id of the booting hart.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)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_
11 October 2020, `RISC-V International <https://riscv.org/>`_-- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra atishp@atishpatra.org:
On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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 onReduced Instruction
Set Architecture (RISC).- HART
Hardware thread in RISC-V. This is the hardware executioncontext that contains
all the state mandated by the ISA.- M Mode
Machine mode is the most secure and privileged mode inRISC-V.
- S Mode
Supervisor mode is the next secure mode where virtual memoryis
enabled.
- HS Mode
Hypervisor-extended-supervisor mode which virtualizes thesupervisor mode.
- U Mode
User mode where userspace application is expected to run.- HSM
Hart State Management (HSM) is an SBI extension that enablesthe
supervisor
mode software to implement ordered booting.- SEE
Supervisor Execution Environment in RISC-V. This can be Mmode
or HS mode.
- SBI
Supervisor Binary Interface. This is an interface between SEEand 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.
UEFI Boot Services
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to the UEFI +application.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
I think this is only true for the non-EFI entry-point of Linux.
Sorry. I should have been more verbose here. The first two conditions should be set by the uefi application before jumping to OS. In the Linux case, EFI stub should set these values before jumping to real Linux.
How about this:
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 */chosen* node. This property must indicate the id of the booting hart. The firmware application must ensure the following condition before jumping to the operating system.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
The OS entry point is where the system table and the image handle are passed.
Yes, currently the Linux EFI stub calls some legacy entry point with a0, a1 in the way you describe. But if they tomorrow pass the information on the stack or via a fixed memory location or whatever it is fine too. It is just a hidden implementation detail in the depth of the application "Linux" that makes no difference to the UEFI world.
I see no need to mention this Linux specific and internal stuff in the EBBR spec.
ok. Do we need to specify this under a linux specific section in that case ? Because the boot-hartid entry is also how EFI stub chooses to pass the hartid to proper Linux. Any other OS may choose to do it differently or Can we mandate that every UEFI application (either similar to linux efistub or any other UEFI application) must parse this device tree node to retrieve the hartid.
The EFI entry point expects the system table and the image handle as
only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table.
Yes. EFI entry point arguments are defined by UEFI specification. So we don't need to specify that.
- The device tree must contain a property named **boot-hartid**
under */chosen* node.
%/under/under the/
Thanks. I will fix that.
How is this modelled when using an ACPI table and not a device tree?
Currently, there is no ACPI design for RISC-V. I guess we need to revisit this when we define ACPI for RISC-V.
Maybe mention it as a TODO, e.g.
"Passing of the boot hart id via ACPI tables has not been defined yet."
Sure. I will add that.
Best regards
Heinrich
This property must indicate the id of the booting hart.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)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_
11 October 2020, `RISC-V International <https://riscv.org/>`_-- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Am 14. Oktober 2020 02:13:41 MESZ schrieb Atish Patra atishp@atishpatra.org:
On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra
On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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) basedon
Reduced Instruction
Set Architecture (RISC).- HART
Hardware thread in RISC-V. This is the hardware executioncontext that contains
all the state mandated by the ISA.- M Mode
Machine mode is the most secure and privileged mode inRISC-V.
- S Mode
Supervisor mode is the next secure mode where virtualmemory
is
enabled.
- HS Mode
Hypervisor-extended-supervisor mode which virtualizes thesupervisor mode.
- U Mode
User mode where userspace application is expected to run.- HSM
Hart State Management (HSM) is an SBI extension thatenables
the
supervisor
mode software to implement ordered booting.- SEE
Supervisor Execution Environment in RISC-V. This can be Mmode
or HS mode.
- SBI
Supervisor Binary Interface. This is an interface betweenSEE
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.
UEFI Boot Services
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to
the
UEFI +application.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device
tree.
I think this is only true for the non-EFI entry-point of Linux.
Sorry. I should have been more verbose here. The first two
conditions
should be set by the uefi application before jumping to OS. In the Linux case, EFI stub should set these values before jumping to real Linux.
How about this:
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 */chosen* node. This property must indicate the id of the booting hart. The firmware application must ensure the following condition before jumping to the operating system.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
The OS entry point is where the system table and the image handle are
passed.
Yes, currently the Linux EFI stub calls some legacy entry point with
a0, a1 in the way you describe. But if they tomorrow pass the information on the stack or via a fixed memory location or whatever it is fine too. It is just a hidden implementation detail in the depth of the application "Linux" that makes no difference to the UEFI world.
I see no need to mention this Linux specific and internal stuff in
the EBBR spec.
ok. Do we need to specify this under a linux specific section in that case ? Because the boot-hartid entry is also how EFI stub chooses to pass the hartid to proper Linux. Any other OS may choose to do it differently or Can we mandate that every UEFI application (either similar to linux efistub or any other UEFI application) must parse this device tree node to retrieve the hartid.
It would not make any difference in the context of the EBBR if the boot hart id inside Linux were represented by an Egyptian hieroglyph in register x14 or a Maya glyph in x27.
The firmware passes the boot hart id as device node. It is the only clue that the OS will get. If the information is relevant for the OS it has to parse it. Be it BSD, Haiku, Windows or Linux.
The EBBR spec should avoid being OS specific.
Best regards
Heinrich
The EFI entry point expects the system table and the image handle
as
only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table.
Yes. EFI entry point arguments are defined by UEFI specification. So we don't need to specify that.
- The device tree must contain a property named
**boot-hartid**
under */chosen* node.
%/under/under the/
Thanks. I will fix that.
How is this modelled when using an ACPI table and not a device
tree?
Currently, there is no ACPI design for RISC-V. I guess we need to revisit this when we define ACPI for RISC-V.
Maybe mention it as a TODO, e.g.
"Passing of the boot hart id via ACPI tables has not been defined
yet."
Sure. I will add that.
Best regards
Heinrich
This property must indicate the id of the booting hart.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)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_
11 October 2020, `RISC-V International-- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Regards, Atish _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Tue, Oct 13, 2020 at 5:55 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 14. Oktober 2020 02:13:41 MESZ schrieb Atish Patra atishp@atishpatra.org:
On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra
On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra
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 | 13 ++++++++++ source/references.rst | 4 ++++ 4 files changed, 66 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.
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) basedon
Reduced Instruction
Set Architecture (RISC).- HART
Hardware thread in RISC-V. This is the hardware executioncontext that contains
all the state mandated by the ISA.- M Mode
Machine mode is the most secure and privileged mode inRISC-V.
- S Mode
Supervisor mode is the next secure mode where virtualmemory
is
enabled.
- HS Mode
Hypervisor-extended-supervisor mode which virtualizes thesupervisor mode.
- U Mode
User mode where userspace application is expected to run.- HSM
Hart State Management (HSM) is an SBI extension thatenables
the
supervisor
mode software to implement ordered booting.- SEE
Supervisor Execution Environment in RISC-V. This can be Mmode
or HS mode.
- SBI
Supervisor Binary Interface. This is an interface betweenSEE
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.
UEFI Boot Services
diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 9c51bca24f33..1551aa90c349 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -27,3 +27,16 @@ 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 conditions before jumping to
the
UEFI +application.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device
tree.
I think this is only true for the non-EFI entry-point of Linux.
Sorry. I should have been more verbose here. The first two
conditions
should be set by the uefi application before jumping to OS. In the Linux case, EFI stub should set these values before jumping to real Linux.
How about this:
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 */chosen* node. This property must indicate the id of the booting hart. The firmware application must ensure the following condition before jumping to the operating system.
- a0 must always contain the hart id of the booting hart.
- a1 must always contain the memory address of the device tree.
The OS entry point is where the system table and the image handle are
passed.
Yes, currently the Linux EFI stub calls some legacy entry point with
a0, a1 in the way you describe. But if they tomorrow pass the information on the stack or via a fixed memory location or whatever it is fine too. It is just a hidden implementation detail in the depth of the application "Linux" that makes no difference to the UEFI world.
I see no need to mention this Linux specific and internal stuff in
the EBBR spec.
ok. Do we need to specify this under a linux specific section in that case ? Because the boot-hartid entry is also how EFI stub chooses to pass the hartid to proper Linux. Any other OS may choose to do it differently or Can we mandate that every UEFI application (either similar to linux efistub or any other UEFI application) must parse this device tree node to retrieve the hartid.
It would not make any difference in the context of the EBBR if the boot hart id inside Linux were represented by an Egyptian hieroglyph in register x14 or a Maya glyph in x27.
The firmware passes the boot hart id as device node. It is the only clue that the OS will get. If the information is relevant for the OS it has to parse it. Be it BSD, Haiku, Windows or Linux.
The EBBR spec should avoid being OS specific.
Fair enough. I will update the patch as per the discussion.
Best regards
Heinrich
The EFI entry point expects the system table and the image handle
as
only arguments. That is why you put the boot hart id into the device-tree which is a configuration table pointed to by the system table.
Yes. EFI entry point arguments are defined by UEFI specification. So we don't need to specify that.
- The device tree must contain a property named
**boot-hartid**
under */chosen* node.
%/under/under the/
Thanks. I will fix that.
How is this modelled when using an ACPI table and not a device
tree?
Currently, there is no ACPI design for RISC-V. I guess we need to revisit this when we define ACPI for RISC-V.
Maybe mention it as a TODO, e.g.
"Passing of the boot hart id via ACPI tables has not been defined
yet."
Sure. I will add that.
Best regards
Heinrich
This property must indicate the id of the booting hart.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)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc`_
11 October 2020, `RISC-V International-- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Regards, Atish _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture@lists.linaro.org
-
Atish Patra -
Atish Patra -
Grant Likely -
Heinrich Schuchardt