Date   

Re: [PATCH v1 2/2] Section 3.1.4 System Peripherals.

Jonathan Behrens <behrensj@...>
 



On Sun, Apr 11, 2021 at 11:46 AM Heinrich Schuchardt via lists.riscv.org <xypron.glpk=gmx.de@...> wrote:
On 4/11/21 5:02 PM, Mayuresh Chitale wrote:
> This patch is an initial draft for the section
> 3.1.4 - System Peripherals.
>
> Signed-off-by: Mayuresh Chitale <mchitale@...>
> ---
>   riscv-platform-spec.adoc | 31 +++++++++++++++++++++++++++----
>   1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 003181c..f164545 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -52,10 +52,33 @@ include::profiles.adoc[]
>   * Interrupt Assignments
>
>   ==== System Peripherals
> -* UART/Serial Console
> -* Clocks
> -* Timers
> -* Watchdog Timers
> +* *UART/Serial Console* +
> +In order to facilitate the bringup and debug of the low level initial platform
> +software(firmware, bootloaders, kernel etc), the platform shall implement a UART
> +port compatible with PC16550D.

Is software compatibility with PC16550D free of copyright restrictions?
(We should not disallow open hardware.)

Strict PC16550D compatibility would for instance preclude usage of lower
voltages. Is this really needed?

Isn't it enough to to have any UART that at least supports 115200,8N1?

For software, it very much matters that the register layout and behavior match some standard. Otherwise you would need to ship drivers for essentially every uart ever made (which might be acceptable to Linux because it already has them, but would be wasted effort for anyone else). 

That said, this spec shouldn’t be specifying the physical implementation of the uart. It should be allowed to use a real PC16550D, a lower voltage one, a uart tunneled over Ethernet, or even an entirely emulated uart (say for  a VM).

Jonathan


Re: [PATCH v1 2/2] Section 3.1.4 System Peripherals.

Heinrich Schuchardt
 

On 4/11/21 5:02 PM, Mayuresh Chitale wrote:
This patch is an initial draft for the section
3.1.4 - System Peripherals.

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
riscv-platform-spec.adoc | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..f164545 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -52,10 +52,33 @@ include::profiles.adoc[]
* Interrupt Assignments

==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+* *UART/Serial Console* +
+In order to facilitate the bringup and debug of the low level initial platform
+software(firmware, bootloaders, kernel etc), the platform shall implement a UART
+port compatible with PC16550D.
Is software compatibility with PC16550D free of copyright restrictions?
(We should not disallow open hardware.)

Strict PC16550D compatibility would for instance preclude usage of lower
voltages. Is this really needed?

Isn't it enough to to have any UART that at least supports 115200,8N1?

Best regards

Heinrich

+* *Clock and Timers* +
+** Platforms shall provide a 10ns resolution 64-bit counter with strictly monotonic updates.
+** The counter shall have a minimum update frequency of 10MHz.
+** Platforms shall implement the time CSR.
+** Platforms shall advertise the timebase to the operating systems via the
+`timebase-frequency` DT property.
+** Platforms shall implement the
+https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension.
+** Platforms shall delegate the supervisor timer interrupt to 'S' mode and if
+the 'H' extension is implemented, the virtual supervisor timer interrupt to 'VS' mode.
+
+* Watchdog Timers +
+** Platforms shall implement a two stage watchdog timer.
+** The software shall periodically update the watchdog stage 1 value to a
+future moment.
+** If the mtime/time increments past the watchdog stage 1 compare value then an
+interrupt shall be raised and routed to a RISC V hart and the watchdog stage 2
+shall be activated.
+** If the mtime/time increments past the watchdog stage 2 compare value an
+interrupt shall be raised and routed to an external hardware unit such as a
+BMC to affect a system reset. If the watchdog stage1 compare value was updated
+before such an event occurred then the watchdog stage 1 interrupt shall be
+deasserted and the watchdog stage 2 shall be deactivated.

==== Boot Process
* Firmware


[PATCH v1 2/2] Section 3.1.4 System Peripherals.

Mayuresh Chitale
 

This patch is an initial draft for the section
3.1.4 - System Peripherals.

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
riscv-platform-spec.adoc | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..f164545 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -52,10 +52,33 @@ include::profiles.adoc[]
* Interrupt Assignments

==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+* *UART/Serial Console* +
+In order to facilitate the bringup and debug of the low level initial platform
+software(firmware, bootloaders, kernel etc), the platform shall implement a UART
+port compatible with PC16550D.
+* *Clock and Timers* +
+** Platforms shall provide a 10ns resolution 64-bit counter with strictly monotonic updates.
+** The counter shall have a minimum update frequency of 10MHz.
+** Platforms shall implement the time CSR.
+** Platforms shall advertise the timebase to the operating systems via the
+`timebase-frequency` DT property.
+** Platforms shall implement the
+https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension.
+** Platforms shall delegate the supervisor timer interrupt to 'S' mode and if
+the 'H' extension is implemented, the virtual supervisor timer interrupt to 'VS' mode.
+
+* Watchdog Timers +
+** Platforms shall implement a two stage watchdog timer.
+** The software shall periodically update the watchdog stage 1 value to a
+future moment.
+** If the mtime/time increments past the watchdog stage 1 compare value then an
+interrupt shall be raised and routed to a RISC V hart and the watchdog stage 2
+shall be activated.
+** If the mtime/time increments past the watchdog stage 2 compare value an
+interrupt shall be raised and routed to an external hardware unit such as a
+BMC to affect a system reset. If the watchdog stage1 compare value was updated
+before such an event occurred then the watchdog stage 1 interrupt shall be
+deasserted and the watchdog stage 2 shall be deactivated.

==== Boot Process
* Firmware
--
2.17.1


[PATCH v1 1/2] Updating contributors

Mayuresh Chitale
 

Adding myself to list of contributors.

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index cb546dd..9781227 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -24,7 +24,8 @@ Arun Thomas,
Philipp Tomsich,
Paul Walmsley,
Andrew Waterman,
-Kumar Sankaran.
+Kumar Sankaran,
+Mayuresh Chitale.

If you have contributed and are not listed, do let us know. We haven't
forgotten you, but we may have forgotten to edit this list.
--
2.17.1


[PATCH v1 0/2] System peripheral requirements

Mayuresh Chitale
 

This is an initial patch which describes requirements for the
system peripherals like UART, clock and timers for the base Linux-2022 platform.

Mayuresh Chitale (2):
Updating contributors
Section 3.1.4 System Peripherals.

contributors.adoc | 3 ++-
riscv-platform-spec.adoc | 31 +++++++++++++++++++++++++++----
2 files changed, 29 insertions(+), 5 deletions(-)

--
2.17.1


Re: Proposal: SBI PMU Extension

Josh Scheid
 

On Thu, Apr 8, 2021 at 6:08 PM Greg Favor <gfavor@...> wrote:

Last year's virt-mem discussion about this I believe established a similar idea.  Both M-mode and S/HS-mode must access a logically "shared memory area" with the same attributes.  Which generally means that S/HS-mode should use the PMA attributes (and not override them).  (The ARMv8 equivalent would be that both EL3 and EL2 page tables should specify the same memory type for such shared addresses.)

 

When M-mode is accessing more general S/HS-mode areas of memory (using a VA passed to it), then it should use the MPRV mechanism to avoid manually dealing with potential MMU and PMP issues (and further issues when other new extensions, like pointer masking, also play games with virtual addresses in mode-specific manners).  Or, if using a PA passed to it, M-mode should manually perform the necessary PMP checks as if it was S-mode.

Implying that using PAs in SBI means that S-mode is restricted to setting any PMA controls it has (all future extensions) for those addresses to some setting that specifies no change from system or M-mode settings of attributes?  This may be a workable solution, but note that it may cause additional copies of data, as the data to be passed up or down may not naturally lie in an area that is or can be set up that way.

-Josh


Re: [PATCH v3 1/3] introduction: Fix a typo

Sunil V L
 

On Fri, Apr 09, 2021 at 12:26:01PM +0000, Alistair Francis wrote:
On Thu, 2021-04-08 at 20:33 +0530, Sunil V L wrote:
On Fri, Apr 02, 2021 at 04:12:10PM -0400, Alistair Francis wrote:
Signed-off-by: Alistair Francis <alistair.francis@...>
---
v3:
 - Change to platform policy

 introduction.adoc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/introduction.adoc b/introduction.adoc
index 26b59d3..f78dc55 100644
--- a/introduction.adoc
+++ b/introduction.adoc
@@ -11,4 +11,5 @@
 This document contains the RISC-V UNIX-class platform
specification.  This
 specification defines additional restrictions on implementations
in order to
 allow software to be compatible between these implementations.
-The scope and definitions used in this document are defined in the
plaform profiles specification.
+The scope and definitions used in this document are defined in the
platform
+policy specification.
I think this is a very generic statement and may not be correct to
point
to platform policy spec always. For ex: How about some definition
used
here which is defined by some other spec like profile spec? My
suggestion is to remove this generic statement  completely and point
to
appropriate spec individually wherever some scope/definition is used
in
the document.
I am just fixing a typo, I would like to leave the discussion about
this for a future patch.

It's probably best to re-write the introducution towards the end once
we have a good idea of what everything looks like.
Sure. Make sense. Thanks!


Alistair

--
2.31.0


Re: [PATCH] Base boot and runtime requirements - initial commit

Heinrich Schuchardt
 

On 09.04.21 15:21, Rahul Pathak wrote:
On Fri, Apr 9, 2021 at 11:11 AM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.
I didn't do that because unlike code here the adoc will get converted
into the html while rendering on github or any other editor which can
handle the text wrapping dynamically
as per the screen size. That's what I thought but if it's still
required then I will do that.
Other specifications like the SBI spec also use an 80 line limit. For
people working in the console short lines are preferable.



+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?
I think Greg answered this.


+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/
Will correct this.


+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.
We need to see how this can be represented here also since there is a
separate chapter on secure boot which should be dealing with
these scenarios, That's why I went with the simplest scenario for now.


Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.
Yeah, more scenarios need to be added like when H extension is implemented.



Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.
Again, should be covered in the secure boot chapter.
I will pass on these comments to the author of that chapter. There is
no one yet.



Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.
I don't think this is right. Since the UEFI implementation will be
implementing the SBI as runtime services. Currently EDK II integrates
OpenSBI as a library.
EDK's Platform/RISC-V/PlatformPkg/Readme.md says:

"The RISC-V OpenSBI library is built in SEC driver without any
modifications and provides the interfaces for supervisor mode execution
environment to execute privileged operations."

Looking at
https://edk2-docs.gitbook.io/edk-ii-build-specification/2_design_discussion/23_boot_sequence
this means that when passing from the SEC phase to the PEI phase you
switch from M-mode to S-mode.

You can find the switch in
Platform/RISC-V/PlatformPkg/Universal/Sec/SecMain.c, function
LaunchPeiCore(). It switches to S-mode if specified in
PcdPeiCorePrivilegeMode. That variable is set to true for
FreedomU500VC707Board and FreedomU500VC707Board.

So the boot sequence is:

SEC (M-mode) -> PEI (S-mode) -> DXE (S-mode) -> OS (S-mode)

U-Boot is similar. Currently we have the following sequences:

Kendryte K210:
OpenSBI (M-mode) -> U-Boot (S-mode)

Other platforms:
U-Boot SPL (M-mode) -> OpenSBI (M-Mode) -> U-Boot (S-mode).

The requirement in platform specification should be something like:

"After initializing the secure environment - which includes the SBI
implementation - the firmware switches to S-mode (or if a hypervisor
extension is available to HS-mode, or VS-mode). The PEI and DXE phases
of the UEFI implementation must not run in M-mode."

Best regards

Heinrich

The simplest boot flow I think should be "ZSBL/FSBL(M-Mode) -->
EDKII (M-Mode, OpenSBI Library for Runtime) --> Bootloader (S-Mode)
---> Linux (S-Mode).
Though EDKII can launch the linux directly but the requirements will
not be dealing with this level of details.


+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
This reference is already added in the "Specification" table at the
top. But I will also mention explicitly here to refer that table.

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.
Agree, EBBR has this optional for Runtime Services. We shall mandate
this to implement in this spec. I will update this.


+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/
Will correct this.


Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension
Thanks
Rahul Pathak


On Fri, Apr 9, 2021 at 11:11 AM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.

+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?

+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/

+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.

Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.

Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.

Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.

+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.

+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/

Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension




Re: [PATCH] Base boot and runtime requirements - initial commit

Rahul Pathak
 

On Fri, Apr 9, 2021 at 11:11 AM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.
I didn't do that because unlike code here the adoc will get converted
into the html while rendering on github or any other editor which can
handle the text wrapping dynamically
as per the screen size. That's what I thought but if it's still
required then I will do that.


+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?
I think Greg answered this.


+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/
Will correct this.


+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.
We need to see how this can be represented here also since there is a
separate chapter on secure boot which should be dealing with
these scenarios, That's why I went with the simplest scenario for now.


Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.
Yeah, more scenarios need to be added like when H extension is implemented.



Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.
Again, should be covered in the secure boot chapter.
I will pass on these comments to the author of that chapter. There is
no one yet.



Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.
I don't think this is right. Since the UEFI implementation will be
implementing the SBI as runtime services. Currently EDK II integrates
OpenSBI as a library.
The simplest boot flow I think should be "ZSBL/FSBL(M-Mode) -->
EDKII (M-Mode, OpenSBI Library for Runtime) --> Bootloader (S-Mode)
---> Linux (S-Mode).
Though EDKII can launch the linux directly but the requirements will
not be dealing with this level of details.


+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
This reference is already added in the "Specification" table at the
top. But I will also mention explicitly here to refer that table.

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.
Agree, EBBR has this optional for Runtime Services. We shall mandate
this to implement in this spec. I will update this.


+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/
Will correct this.


Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension
Thanks
Rahul Pathak


On Fri, Apr 9, 2021 at 11:11 AM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.

+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?

+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/

+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.

Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.

Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.

Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.

+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.

+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/

Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension


[PULL 3/3] contributors: Add myself as a contributor

Alistair Francis
 

Signed-off-by: Alistair Francis <alistair.francis@...>
Reviewed-by: Sunil V L <sunilvl@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index cb546dd..08a24d6 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -24,7 +24,8 @@ Arun Thomas,
Philipp Tomsich,
Paul Walmsley,
Andrew Waterman,
-Kumar Sankaran.
+Kumar Sankaran,
+Alistair Francis.

If you have contributed and are not listed, do let us know. We haven't
forgotten you, but we may have forgotten to edit this list.
--
2.31.0


[PULL 2/3] riscv-platform-spec: Initial commit of the Embedded-2022 spec

Alistair Francis
 

This is the initial attempt at writing an Embedded-2022 specification.
This includes some required and recommended components to ease software
development and porting while not being too burdensome on hardware
designs.

Signed-off-by: Alistair Francis <alistair.francis@...>
Reviewed-by: Sunil V L <sunilvl@...>
---
changelog.adoc | 2 +
riscv-platform-spec.adoc | 97 +++++++++++++++++++++++++++++++---------
2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 72d6047..ce5644b 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -8,6 +8,8 @@
## Change Log

### version 0.2-rc0
+* 2021-03-25:
+** Initial commit of Embedded-2022 specification
* 2021-03-16:
** Added 2022 platforms
** Added individual sections and sub-sections for the content
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..5d3b9c3 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -95,36 +95,91 @@ include::profiles.adoc[]
// Embedded-2022 Platform
== Embedded-2022

-// Base feature set for Embedded-2022 Platform
+=== Scope
+The Embedded-2022 specification aims to apply to a range of embedded platforms.
+In this case embedded platforms range from hand coded bare metal assembly
+all the way to to embedded operating systems such as
+https://www.zephyrproject.org[Zephyr] and embedded Linux.
+
+This specification has two competing interests. On one hand embedded software
+will be easier to write and port if all the embedded hardware is similar. On
+the other hand vendors want to differentiate their product and reuse existing
+IP and SoC designs.
+
+Due to this, the Embedded-2022 specification has both required and recommended
+components. All required components must be met in order to meet this
+specification.
+It's strongly encouraged that all recommended components are met as well,
+although they do not have to in order to meet the specification.
+
=== Base
==== Architecture
-* Profile - RVM22
-* Debug
+The Embedded-2022 specification depends on the RVM22 specification and all
+requirements from RVM22 must be met.

-==== Memory Map
-* Start Address
+Any RISC-V system that uses at least RV32/64G can meet the Embedded-2022
+specification.

==== Interrupt Controller
-* CLIC/PLIC
+Embedded systems are recommended to use a spec compliant
+https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
+https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+or both a CLIC and and PLIC.
+
+If using just a PLIC the system must continue to use the original basic
+`xsip`/`xtip`/`xeip` signals in the `xip` register to indicate pending
+interrupts.
+If using the CLIC then both the original basic and CLIC modes of interrupts
+must be supported.
+
+Embedded systems cannot use a non-compliant interrupt controller and still
+call it a PLIC or CLIC.
+
+==== Machine Timer
+The RISC-V machine timer (controlled via `mtime` and `mtimecmp`) must be
+implemented. The two registers must be memory mapped as required by the RISC-V
+specification.
+
+The Embedded-2022 specification requires that the registers be mapped
+adjacent to each other with the `mtime` region at the lower address.
+
+The starting address of this region can be located anywhere in
+memory, including inside other peripherals, as long as the start address is
+4 byte aligned.
+
+An example of the memory layout for a 32-bit system with a single hart is below
+
+-------------------------
+=========================
+| 0x00 | mtime low |
+| 0x04 | mtime high |
+| 0x08 | mtimecmp low |
+| 0x0C | mtimecmp high |
+=========================
+-------------------------
+
+and for a 64-bit system with 2 harts
+
+---------------------------
+===========================
+| 0x00 | mtime |
+| 0x08 | mtimecmp hart 1 |
+| 0x10 | mtimecmp hart 2 |
+===========================
+---------------------------

-==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Memory Map
+It is recommended that main memory and loadable code (not ROM) start at
+address `0x8000_0000`.

// PMP extension for Embedded-2022 Platform
-=== PMP Extension
-==== PMP Regions
+=== Physical Memory Protection (PMP) Extension
+It is recommended that any systems that implement more then just machine mode
+also implement PMP support.

-// RVM-SIS extension for Embedded-2022 Platform
-=== RVM-SIS Extension
-==== HAL
+When PMP is supported it is recommended to include at least 4 regions, although
+if possible more should be supported to allow more flexibility. Hardware
+implementations should aim for supporting at least 16 PMP regions.

// acknowledge all of the contributors
include::contributors.adoc[]
-
--
2.31.0


[PULL 1/3] introduction: Fix a typo

Alistair Francis
 

Signed-off-by: Alistair Francis <alistair.francis@...>
Reviewed-by: Bin Meng <bmeng.cn@...>
---
introduction.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/introduction.adoc b/introduction.adoc
index 26b59d3..f78dc55 100644
--- a/introduction.adoc
+++ b/introduction.adoc
@@ -11,4 +11,5 @@
This document contains the RISC-V UNIX-class platform specification. This
specification defines additional restrictions on implementations in order to
allow software to be compatible between these implementations.
-The scope and definitions used in this document are defined in the plaform profiles specification.
+The scope and definitions used in this document are defined in the platform
+policy specification.
--
2.31.0


[PULL 0/3] Initial PR for the Embedded-2022 spec

Alistair Francis
 

Alistair Francis (3):
introduction: Fix a typo
riscv-platform-spec: Initial commit of the Embedded-2022 spec
contributors: Add myself as a contributor

changelog.adoc | 2 +
contributors.adoc | 3 +-
introduction.adoc | 3 +-
riscv-platform-spec.adoc | 97 +++++++++++++++++++++++++++++++---------
4 files changed, 82 insertions(+), 23 deletions(-)

--
2.31.0

The following changes since commit c1a2acbf07331ab8503c26031c2c85d8366a6e2e:

Add platform spec chapters and subsections and updated license, contributors and changelog (2021-03-23 15:56:00 -0700)

are available in the Git repository at:

git@...:alistair23/qemu.git embedded-2022-20210409-3

for you to fetch changes up to 91258f9d65029a634fd7dca2af6426f04f4eeb3d:

contributors: Add myself as a contributor (2021-04-09 08:20:52 -0400)

----------------------------------------------------------------
Initial PR for the Embedded-2022 spec

----------------------------------------------------------------
Alistair Francis (3):
introduction: Fix a typo
riscv-platform-spec: Initial commit of the Embedded-2022 spec
contributors: Add myself as a contributor

changelog.adoc | 2 +
contributors.adoc | 3 +-
introduction.adoc | 3 +-
riscv-platform-spec.adoc | 97 +++++++++++++++++++++++++++++++++++++-----------
4 files changed, 82 insertions(+), 23 deletions(-)


Re: [PATCH v3 1/3] introduction: Fix a typo

Alistair Francis
 

On Thu, 2021-04-08 at 20:33 +0530, Sunil V L wrote:
On Fri, Apr 02, 2021 at 04:12:10PM -0400, Alistair Francis wrote:
Signed-off-by: Alistair Francis <alistair.francis@...>
---
v3:
 - Change to platform policy

 introduction.adoc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/introduction.adoc b/introduction.adoc
index 26b59d3..f78dc55 100644
--- a/introduction.adoc
+++ b/introduction.adoc
@@ -11,4 +11,5 @@
 This document contains the RISC-V UNIX-class platform
specification.  This
 specification defines additional restrictions on implementations
in order to
 allow software to be compatible between these implementations.
-The scope and definitions used in this document are defined in the
plaform profiles specification.
+The scope and definitions used in this document are defined in the
platform
+policy specification.
I think this is a very generic statement and may not be correct to
point
to platform policy spec always. For ex: How about some definition
used
here which is defined by some other spec like profile spec? My
suggestion is to remove this generic statement  completely and point
to
appropriate spec individually wherever some scope/definition is used
in
the document.
I am just fixing a typo, I would like to leave the discussion about
this for a future patch.

It's probably best to re-write the introducution towards the end once
we have a good idea of what everything looks like.

Alistair

--
2.31.0


Re: Proposal: SBI PMU Extension

Anup Patel
 

Yes, let me re-word this a bit.

 

There is no functional issue in the way MPRV/HLV/HSV (or unpriv accesses) works in a RISC-V system.

 

The rationale for avoiding direct S-mode (or VS-mode) memory address parameter in SBI calls is to:

  1. Make SBI call handling more predictable (without any traps)
  2. Achieve better isolation between SBI implementation (M-mode or HS-mode) and SBI client (HS-mode or VS-mode)

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Andrew Waterman
Sent: 09 April 2021 13:17
To: Anup Patel <Anup.Patel@...>
Cc: Greg Favor <gfavor@...>; Paul Donahue <pdonahue@...>; Jonathan Behrens <behrensj@...>; tech-unixplatformspec@...; Josh Scheid <jscheid@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal: SBI PMU Extension

 

 

 

On Thu, Apr 8, 2021 at 9:29 PM Anup Patel <Anup.Patel@...> wrote:

For SBI v0.1 calls, the OpenSBI will redirect trap back to S-mode if the trap happened while doing unpriv access. Functionally this works on real HW but there is a potential risk here because now S-mode page table programming can influence traps in M-mode software. On a loaded RISC-V system, the Linux page swapping will be triggered quite often and we typically see increase in trap redirection as well.

 

We should be clear that what you're describing is _not_ a functional problem in the ISA approach.  By design, it is OK for the M-mode software to experience an exception when running under MPRV, then redirect the trap to S-mode.  If this property is causing functional problems, there is a software bug.

 

 

In fact for hypervisor, the unpriv accesses will trap for SBI calls accessing guest memory based on physical address as well because the guest memory is regular

user-space memory for the KVM hypervisor so the Host Linux swapper can always swap in/out guest pages while the guest is running.

 

With SBI v0.2 onwards, we have avoided defining a SBI call which forces SBI implementation (M-mode or HS-mode) to directly access guest memory. This improves isolation between SBI implementation and SBI client (Linux).

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Andrew Waterman
Sent: 09 April 2021 06:16
To: Greg Favor <gfavor@...>
Cc: Anup Patel <Anup.Patel@...>; Paul Donahue <pdonahue@...>; Jonathan Behrens <behrensj@...>; tech-unixplatformspec@...; Josh Scheid <jscheid@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal: SBI PMU Extension

 

 

 

On Thu, Apr 8, 2021 at 5:39 PM Greg Favor <gfavor@...> wrote:

On Mon, Apr 5, 2021 at 6:02 PM Anup Patel <anup.patel@...> wrote:

Passing virtual address as parameter to SBI call is certainly not acceptable because we end-up doing unpriv access in both M-mode and HS-mode. Also, these unpriv access can potentially trap because supervisor-mode (HS-mode or VS-mode) operating system can swap-in/swap-out pages while the unpriv access is happening from SBI implementation (M-mode or HS-mode).

 

Anup,

 

What happens for M-mode accesses done using a VA and the MPRV mechanism?  I think (?) this was discussed at some point last year, but I forget how the possibility of the addressed page of memory being swapped would be handled.  That access will presumably result in a page fault, but to M-mode?  And then what?

 

Such exceptions should be delegated back to S-mode (in software), just as page faults that arise due to S-mode loads and stores are normally delegated to S-mode (in hardware).  OpenSBI might've already inherited this behavior from bbl.

 

I think the story is the same if the hypervisor extension is present, since only HS-mode should be performing SBI calls that are directly handled by M-mode.

 

 

Greg

 


Re: Proposal: SBI PMU Extension

Andrew Waterman
 



On Thu, Apr 8, 2021 at 9:29 PM Anup Patel <Anup.Patel@...> wrote:

For SBI v0.1 calls, the OpenSBI will redirect trap back to S-mode if the trap happened while doing unpriv access. Functionally this works on real HW but there is a potential risk here because now S-mode page table programming can influence traps in M-mode software. On a loaded RISC-V system, the Linux page swapping will be triggered quite often and we typically see increase in trap redirection as well.


We should be clear that what you're describing is _not_ a functional problem in the ISA approach.  By design, it is OK for the M-mode software to experience an exception when running under MPRV, then redirect the trap to S-mode.  If this property is causing functional problems, there is a software bug.

 

In fact for hypervisor, the unpriv accesses will trap for SBI calls accessing guest memory based on physical address as well because the guest memory is regular

user-space memory for the KVM hypervisor so the Host Linux swapper can always swap in/out guest pages while the guest is running.

 

With SBI v0.2 onwards, we have avoided defining a SBI call which forces SBI implementation (M-mode or HS-mode) to directly access guest memory. This improves isolation between SBI implementation and SBI client (Linux).

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Andrew Waterman
Sent: 09 April 2021 06:16
To: Greg Favor <gfavor@...>
Cc: Anup Patel <Anup.Patel@...>; Paul Donahue <pdonahue@...>; Jonathan Behrens <behrensj@...>; tech-unixplatformspec@...; Josh Scheid <jscheid@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal: SBI PMU Extension

 

 

 

On Thu, Apr 8, 2021 at 5:39 PM Greg Favor <gfavor@...> wrote:

On Mon, Apr 5, 2021 at 6:02 PM Anup Patel <anup.patel@...> wrote:

Passing virtual address as parameter to SBI call is certainly not acceptable because we end-up doing unpriv access in both M-mode and HS-mode. Also, these unpriv access can potentially trap because supervisor-mode (HS-mode or VS-mode) operating system can swap-in/swap-out pages while the unpriv access is happening from SBI implementation (M-mode or HS-mode).

 

Anup,

 

What happens for M-mode accesses done using a VA and the MPRV mechanism?  I think (?) this was discussed at some point last year, but I forget how the possibility of the addressed page of memory being swapped would be handled.  That access will presumably result in a page fault, but to M-mode?  And then what?

 

Such exceptions should be delegated back to S-mode (in software), just as page faults that arise due to S-mode loads and stores are normally delegated to S-mode (in hardware).  OpenSBI might've already inherited this behavior from bbl.

 

I think the story is the same if the hypervisor extension is present, since only HS-mode should be performing SBI calls that are directly handled by M-mode.

 

 

Greg

 


Re: [PATCH v3 2/3] riscv-platform-spec: Initial commit of the Embedded-2022 spec

Sunil V L
 

On Fri, Apr 02, 2021 at 04:12:11PM -0400, Alistair Francis wrote:
This is the initial attempt at writing an Embedded-2022 specification.
This includes some required and recommended components to ease software
development and porting while not being too burdensome on hardware
designs.

Signed-off-by: Alistair Francis <alistair.francis@...>
Looks good to me.

Reviewed-by: Sunil V L <sunilvl@...>

Thanks
Sunil

---
v2:
- Spell out PMP

changelog.adoc | 2 +
riscv-platform-spec.adoc | 97 +++++++++++++++++++++++++++++++---------
2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 72d6047..ce5644b 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -8,6 +8,8 @@
## Change Log

### version 0.2-rc0
+* 2021-03-25:
+** Initial commit of Embedded-2022 specification
* 2021-03-16:
** Added 2022 platforms
** Added individual sections and sub-sections for the content
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..5d3b9c3 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -95,36 +95,91 @@ include::profiles.adoc[]
// Embedded-2022 Platform
== Embedded-2022

-// Base feature set for Embedded-2022 Platform
+=== Scope
+The Embedded-2022 specification aims to apply to a range of embedded platforms.
+In this case embedded platforms range from hand coded bare metal assembly
+all the way to to embedded operating systems such as
+https://www.zephyrproject.org[Zephyr] and embedded Linux.
+
+This specification has two competing interests. On one hand embedded software
+will be easier to write and port if all the embedded hardware is similar. On
+the other hand vendors want to differentiate their product and reuse existing
+IP and SoC designs.
+
+Due to this, the Embedded-2022 specification has both required and recommended
+components. All required components must be met in order to meet this
+specification.
+It's strongly encouraged that all recommended components are met as well,
+although they do not have to in order to meet the specification.
+
=== Base
==== Architecture
-* Profile - RVM22
-* Debug
+The Embedded-2022 specification depends on the RVM22 specification and all
+requirements from RVM22 must be met.

-==== Memory Map
-* Start Address
+Any RISC-V system that uses at least RV32/64G can meet the Embedded-2022
+specification.

==== Interrupt Controller
-* CLIC/PLIC
+Embedded systems are recommended to use a spec compliant
+https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
+https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+or both a CLIC and and PLIC.
+
+If using just a PLIC the system must continue to use the original basic
+`xsip`/`xtip`/`xeip` signals in the `xip` register to indicate pending
+interrupts.
+If using the CLIC then both the original basic and CLIC modes of interrupts
+must be supported.
+
+Embedded systems cannot use a non-compliant interrupt controller and still
+call it a PLIC or CLIC.
+
+==== Machine Timer
+The RISC-V machine timer (controlled via `mtime` and `mtimecmp`) must be
+implemented. The two registers must be memory mapped as required by the RISC-V
+specification.
+
+The Embedded-2022 specification requires that the registers be mapped
+adjacent to each other with the `mtime` region at the lower address.
+
+The starting address of this region can be located anywhere in
+memory, including inside other peripherals, as long as the start address is
+4 byte aligned.
+
+An example of the memory layout for a 32-bit system with a single hart is below
+
+-------------------------
+=========================
+| 0x00 | mtime low |
+| 0x04 | mtime high |
+| 0x08 | mtimecmp low |
+| 0x0C | mtimecmp high |
+=========================
+-------------------------
+
+and for a 64-bit system with 2 harts
+
+---------------------------
+===========================
+| 0x00 | mtime |
+| 0x08 | mtimecmp hart 1 |
+| 0x10 | mtimecmp hart 2 |
+===========================
+---------------------------

-==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Memory Map
+It is recommended that main memory and loadable code (not ROM) start at
+address `0x8000_0000`.

// PMP extension for Embedded-2022 Platform
-=== PMP Extension
-==== PMP Regions
+=== Physical Memory Protection (PMP) Extension
+It is recommended that any systems that implement more then just machine mode
+also implement PMP support.

-// RVM-SIS extension for Embedded-2022 Platform
-=== RVM-SIS Extension
-==== HAL
+When PMP is supported it is recommended to include at least 4 regions, although
+if possible more should be supported to allow more flexibility. Hardware
+implementations should aim for supporting at least 16 PMP regions.

// acknowledge all of the contributors
include::contributors.adoc[]
-
--
2.31.0






Re: [PATCH v3 3/3] contributors: Add myself as a contributor

Sunil V L
 

On Fri, Apr 02, 2021 at 04:12:12PM -0400, Alistair Francis wrote:
Signed-off-by: Alistair Francis <alistair.francis@...>
Reviewed-by: Sunil V L <sunilvl@...>

---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index cb546dd..08a24d6 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -24,7 +24,8 @@ Arun Thomas,
Philipp Tomsich,
Paul Walmsley,
Andrew Waterman,
-Kumar Sankaran.
+Kumar Sankaran,
+Alistair Francis.

If you have contributed and are not listed, do let us know. We haven't
forgotten you, but we may have forgotten to edit this list.
--
2.31.0






Re: [PATCH] Base boot and runtime requirements - initial commit

Greg Favor
 

On Thu, Apr 8, 2021 at 10:41 PM Heinrich Schuchardt <xypron.glpk@...> wrote:
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?

The RV (RISC-V) 'A' and 'M' profile specs for 2022 are being created concurrent with the "Linux" and "Embedded" 2022 platform specs.  A profile spec is an ISA-level spec that specifies what ratified RISC-V ISA base and ISA extensions are 'required', 'optional', 'unsupported', and 'incompatible' for that profile.  Once there are draft profile specs by the end of Q2-ish, there will be broad review and the platform specs can fine tune what they say on top of what the profile specs say.

A platform spec then builds upon a profile spec, possibly requiring optional aspects of the profile spec, adds on firmware and software components and requirements, and adds on hardware system components and requirements.

The 2022 profile and platform specs will become official at the end of the year with the annual RISC-V Summit.  (At which point references to the profiles will be as widely known as references to the RV Unprivileged and Privilege architectures.)

Greg


Re: [PATCH] Base boot and runtime requirements - initial commit

Heinrich Schuchardt
 

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.

+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?

+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/

+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.

Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.

Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.

Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.

+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.

+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/

Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension

1141 - 1160 of 1847