Re: [PATCH 2/2] Add RISC-V support content to the EBBR specification
On Tue, Oct 13, 2020 at 5:55 PM Heinrich Schuchardt wrote: > > Am 14. Oktober 2020 02:13:41 MESZ schrieb Atish Patra : > >On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt > > wrote: > >> > >> Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra > >: > >> >On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt > >> > 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 > >> >> >--- > >> >> > 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
Re: [PATCH 2/2] Add RISC-V support content to the EBBR specification
Am 14. Oktober 2020 02:13:41 MESZ schrieb Atish Patra : >On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt > wrote: >> >> Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra >: >> >On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt >> > 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 >> >> >--- >> >> > 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
Re: [PATCH 2/2] Add RISC-V support content to the EBBR specification
On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt wrote: > > Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra : > >On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt > > 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 > >> >--- > >> > 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
Re: [PATCH 2/2] Add RISC-V support content to the EBBR specification
Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra : >On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt > 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 >> >--- >> > 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
Re: [PATCH 2/2] Add RISC-V support content to the EBBR specification
On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt 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 > >--- > > 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 >
Re: [PATCH 2/2] Add RISC-V support content to the EBBR specification
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 >--- > 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
