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 | 125 ++++++++++++++++++++++++++++++++++++---
1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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
+|link:[Platform Policy] | TBD
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI specification and
+all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply
+with the base specification. Hypervisor Extension is optional.
+_**Will be defined in this spec if the RVA22 spec does not mention it.**_
+- 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 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.
+
+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch and the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- 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.
+- 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
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the
+RISC-V SBI Specification.
+- Wherever applicable firmware must implement UEFI interfaces over similar
+interfaces and services present in the SBI specification. For example, UEFI
+runtime services must implement ResetSystem() via SBI Reset extension.
+- 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 when accessing the mapped
+devices.
+- 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.

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

On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@...> wrote:

My reviews are inline below which is apart from the below recommendations if you don't think that is better.


We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me.
Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to EBBR in Embede2022. Is this clear than the current layout of spec?

Linux2022 name is going to change and its just a placeholder for now.
The platform specs builds upon the ISA level profiles A and M.
Linux2022 corresponds to A profile (RVA2022) where we are asking
RV32/64 with M,S,U modes and H as optional. UEFI as the firmware
interface is only considered for the Linux2022(Base + Server).
Embedded2022 is a separate set of requirements which are dependent on
the RVM22 ISA profile.
We may make more changes later once the these profiles specs RVA22 and
RVM22 will be available and it will clear things.
Does this provides clarity?

For example,
+===== Firmware
....
....
+- For compliance with base specification platform must implement
+link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements],
Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms
- EFI_SYSTEM_TABLE
- EFI_BOOT_SERVICES
- EFI_ RUNTIME_SERVICES
- Required EFI protocols for the base specification.
- Required EFI protocols for the platform.
Refer to Embedded2022 for the detailed implementations of the above requirements.
Refer to Server2022 for the detailed implementations of the above requirements.

In Embedded2022 section, put links to refer to EBBR.
In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support.

This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform.

Embedded2022 spec is different from Linux2022 and it considers
different league of RISC-V implementation which will be clear when
RVM22 will be out.
UEFI is only considered for Linux2022 (Base + Server). Though base
sets the guidelines for the minimum requirements for compliance only.
There is no separate Server2022, Server is an extension under Linux2022.

Rahul Pathak <rpathak@...> 於 2021年4月20日 週二 下午8:23寫道：

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 | 125 ++++++++++++++++++++++++++++++++++++---
1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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
+|link:[Platform Policy] | TBD
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI specification and
+all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply
+with the base specification. Hypervisor Extension is optional.
+_**Will be defined in this spec if the RVA22 spec does not mention it.**_
+- 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 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

Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image.

Sure, will change this.

+- 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].

This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR.
Can we add the below sentence,
Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3.

Sure, will add this.

+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions
+marked as EFI_BOOT_SERVICES.
+
+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch and the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- 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.
+- 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.

Could we add something regarding to SMBIOS?
"If platform requires SMBIOS on UEFI system, the SMBIOS table must be installed to EFI Configuration Table according to 4.6 EFI Configuration Table & Properties Table of UEFI
specification."

The initial guidelines set for the Base (Linux2022) spec was to have
the Devicetree and its mandatory for base compliance. SMBIOS is
considered for the server extension.
Is there any instance where both DT and SMBIOS exists together on ARM?

Thanks
Rahul

Abner

-==== Runtime services
-* SBI
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the
+RISC-V SBI Specification.
+- Wherever applicable firmware must implement UEFI interfaces over similar
+interfaces and services present in the SBI specification. For example, UEFI
+runtime services must implement ResetSystem() via SBI Reset extension.
+- 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 when accessing the mapped
+devices.
+- 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.

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

On Wed, 2021-04-21 at 14:38 +0800, Abner Chang wrote:

My reviews are inline below which is apart from the
below recommendations if you don't think that is better.


We have Linux2022 as the base feature set for all kinds of platform,
however, there are many external references to EBBR in this section
and EBBR is in the reduced UEFI scope and the base requirement is
mainly for the embedded platform  We also have Embedded2022 section
specifically to embedded system and there is a Base sub-section for
it. The above confuses me.

I think the confusion is valid because of the current naming scheme
which is just a place holder. Just to clarify the embedded2022 is meant
for microcontroller type of hardware where some RTOS or baremetal
programs are expected to run.

The Linux 2022(a generic name will be adopted) platform is the the one
that is meant for rich operating systems like Linux/FreeBSD/Windows.
The expected hardware platform ranges from small dev boards(beagleV) to
servers.

Could we just have a simple and generic description in Linux2022 that
replaces all of EBBR references, then point to Embede2022 in
Linux2022 for the detailed implementation of the embedded platform?
Also, have the references to EBBR in Embede2022. Is this clear than
the current layout of spec?

The base specification contains the minimum set similar to EBBR. Thus,
FPGA platforms/dev boards can claim compliance to it. The server
extension will introduce additional features on top of the base so that
server platforms can comply with it.

For example, 
+===== Firmware
....
....
+- For compliance with base specification platform must implement
+link:https://arm-software.github.io/ebbr/#required-elements[EBBR -
UEFI Required Elements],
Below would be implemented for UEFI firmware system for the
compliance with base specification, just some implementations may be
omitted based on the requirements of different RISC-V platforms
- EFI_SYSTEM_TABLE
- EFI_BOOT_SERVICES
- EFI_ RUNTIME_SERVICES
- Required EFI protocols for the base specification.
- Required EFI protocols for the platform.
Refer to Embedded2022 for the detailed implementations of the above
requirements.
Refer to Server2022 for the detailed implementations of the above
requirements.

In Embedded2022 section, put links to refer to EBBR.
In Server section, we can just refer to UEFI spec if the
requirement needs full UEFI scope support.

This reduces the confusion and increases the readability to the
audience. Otherwise, it would be hard to read for the Server platform
because Server2022 would base on Linux2022 plus the extensions. And
some of the requirements that refer to EBBR would be
overridden because of the deviations for the server platform.


Rahul Pathak <rpathak@...> 於 2021年4月20日 週二 下午8:23寫道：

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 | 125
++++++++++++++++++++++++++++++++++++---
 1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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
+|link:[Platform Policy]                                           
                                           | TBD
+|===
+
 // Base feature set for Linux-2022 Platform
 === Base
 ==== Architecture
@@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI
specification and
+all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV64GC system with Machine, Supervisor and User
Mode can comply
+with the base specification. Hypervisor Extension is optional.
+_**Will be defined in this spec if the RVA22 spec does not mention
it.**_
+- 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 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

Better to name it as  "Firmware Block Device Partition Format"
becasue the link to EBBR is specifically talks about how to store
firmware image.

+- 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].

This is what I said it may confuse audiences becasue UEFI PI spec
volume3 also defines the format of firmware image which is used by
edk2 and which is very different than the one defined in EBBR.
Can we add the below sentence,
Firmware must implement the require EFI protocols if the firmware
image is stored in the format which complaint with section 2
"Firmware Storage Design Discussion" in UEFI PI specification
volume3.

+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI
functions
+marked as EFI_BOOT_SERVICES.
+
+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch and
the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- 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.
+- 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.

 Could we add something regarding to SMBIOS?
"If platform requires SMBIOS on UEFI system, the SMBIOS table must be
installed to EFI Configuration Table according to 4.6 EFI
Configuration Table & Properties Table of UEFI
specification."

Abner

-==== Runtime services
-* SBI
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions
specified by the
+RISC-V SBI Specification.
+- Wherever applicable firmware must implement UEFI interfaces over
similar
+interfaces and services present in the SBI specification. For
example, UEFI
+runtime services must implement ResetSystem() via SBI Reset
extension.
+- 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 when accessing the
mapped
+devices.
+- 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.

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

--
Regards,
Atish

On Tue, 2021-04-20 at 17:51 +0530, 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 | 125 ++++++++++++++++++++++++++++++++++++-
--
 1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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
+|link:[Platform
Policy]                                                              
                         | TBD
+|===
+
 // Base feature set for Linux-2022 Platform
 === Base
 ==== Architecture
@@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI
specification and
+all requirements from the SBI spec must be implemented.

This statement is bit ambiguous given that individual SBI section says
legacy ones must not be implemented.

+- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode
can comply
+with the base specification. 

Should we reword something like this,

Any platform seeking compliance with the base specification, must
implement all three privilege modes i.e. M/S/U mode.

Hypervisor Extension is optional.

Do we need to state this explicitly? I am just trying see if we can
avoid any statements with optional word as per previous discussions.

Any platform implementing M/S/U complies with base. If they implement H
extension on top of that but not aimed for server extension compliance,
they are still compliant with base specification.

+_**Will be defined in this spec if the RVA22 spec does not mention
it.**_
+- 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.

Just for clarification, RISC-V specific content in EBBR is not merged
yet. The last version of the patch can be found here.

https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg01545.html

I will try to revise/rebase it on the latest EBBR specification.

+- 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 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 Firm
ware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI
functions
+marked as EFI_BOOT_SERVICES.
+

Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can
reworded similar to what EBBR has done.

All functions defined as boot services must exist. Methods for
unsupported or unimplemented behavior must return an appropriate error
code.

+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch and
the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- Before yielding control to S-Mode stage, firmware must configure
the M-Mode
+state. Refer the RISC-V SBI specification for details.

Are we talking about only CSR configuration or all other implmentation
expectations from M-mode such as interrupt/exception delegation,
misaligned/missing CSR emulation, PMP configuration ?

+- 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].
+

In addition to this, should we standardize a start address (i.e.
0x80000000)

+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system
description.
+- 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
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified
by the
+RISC-V SBI Specification.

I think we can just mandate SBI v0.3. The base specification may not
have to implement all the SBI extensions in future.

+- Wherever applicable firmware must implement UEFI interfaces over
similar
+interfaces and services present in the SBI specification. For
example, UEFI
+runtime services must implement ResetSystem() via SBI Reset
extension.
+- 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 when accessing the
mapped
+devices.
+- 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.
 
 // Server extension for Linux-2022 Platform
 === Server Extension

--
Regards,
Atish

On Fri, 2021-04-23 at 08:36 +0800, Abner Chang wrote:

Atish Patra <atish.patra@...> 於 2021年4月23日 週五 上午7:34寫道：

On Tue, 2021-04-20 at 17:51 +0530, 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 | 125

++++++++++++++++++++++++++++++++++++-

--
 1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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
+|link:[Platform

Policy]                                                            
  

                         | TBD
+|===
+
 // Base feature set for Linux-2022 Platform
 === Base
 ==== Architecture
@@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI
specification and
+all requirements from the SBI spec must be implemented.

This statement is bit ambiguous given that individual SBI section
says
legacy ones must not be implemented.

+- Any RV32GC or RV64GC system with Machine, Supervisor and User

Mode

can comply
+with the base specification. 

Should we reword something like this,

Any platform seeking compliance with the base specification, must
implement all three privilege modes i.e. M/S/U mode.

Hypervisor Extension is optional.

Do we need to state this explicitly? I am just trying see if we can
avoid any statements with optional word as per previous
discussions.   

Any platform implementing M/S/U complies with base. If they
implement H
extension on top of that but not aimed for server extension
compliance,
they are still compliant with base specification.

+_**Will be defined in this spec if the RVA22 spec does not

mention

it.**_
+- 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.

Just for clarification, RISC-V specific content in EBBR is not
merged
yet. The last version of the patch can be found here.

https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg01545.html

This may fix my concern in the previous reply.
Atish, do you mean we will have RISC-V elements in EBBR spec. That is
EBBR would be a spec for embedded systems on different archs?

Yes. Additional clarification for everybody: EBBR is meant for embedded
systems as in embedded Linux. The embedded 2022 in RISC-V platform spec
is aimed towards the bare metal/micro-controller platforms.

I think we need to fix the naming sooner than we thought :)

If the above is true, then I have no problem with referring to EBBR
in this spec.

Abner
 

I will try to revise/rebase it on the latest EBBR specification.

+- 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 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 Fi
rm

ware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI
functions
+marked as EFI_BOOT_SERVICES.
+

Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can
reworded similar to what EBBR has done.

All functions defined as boot services must exist. Methods for
unsupported or unimplemented behavior must return an appropriate
error
code.

+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch

and

the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- Before yielding control to S-Mode stage, firmware must

configure

the M-Mode
+state. Refer the RISC-V SBI specification for details.

Are we talking about only CSR configuration or all other
implmentation
expectations from M-mode such as interrupt/exception delegation,
misaligned/missing CSR emulation, PMP configuration ?

+- 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].
+

In addition to this, should we standardize a start address (i.e.
0x80000000)

+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for

system

description.
+- 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
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions

specified

by the
+RISC-V SBI Specification.

I think we can just mandate SBI v0.3. The base specification may
not
have to implement all the SBI extensions in future.

+- Wherever applicable firmware must implement UEFI interfaces

over

similar
+interfaces and services present in the SBI specification. For
example, UEFI
+runtime services must implement ResetSystem() via SBI Reset
extension.
+- 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 when accessing the
mapped
+devices.
+- 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.
 
 // Server extension for Linux-2022 Platform
 === Server Extension

--
Regards,
Atish

On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> wrote:

On Tue, 2021-04-20 at 17:51 +0530, 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 | 125 ++++++++++++++++++++++++++++++++++++-
--
1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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
+|link:[Platform
Policy]
| TBD
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI
specification and
+all requirements from the SBI spec must be implemented.

This statement is bit ambiguous given that individual SBI section says
legacy ones must not be implemented.

Ok, What I thought while mentioning this that, if SBI spec mentions that Legacy
interfaces should not be implemented" then this statement is also a requirement
just "to not implement".
But I think lets change the wording to this - "SBI Specification
compliance is must for conformation with the Base Specification"
BTW I have explicitly mentioned to not implement Legacy Extension from
SBI in the
Runtime Section below

+- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode
can comply
+with the base specification.

Should we reword something like this,

Any platform seeking compliance with the base specification, must
implement all three privilege modes i.e. M/S/U mode.

Should we not mandate the minimum ISA required to support the rich os.

Hypervisor Extension is optional.

Do we need to state this explicitly? I am just trying see if we can
avoid any statements with optional word as per previous discussions.

Any platform implementing M/S/U complies with base. If they implement H
extension on top of that but not aimed for server extension compliance,
they are still compliant with base specification.

Agree

+_**Will be defined in this spec if the RVA22 spec does not mention
it.**_
+- 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.

Just for clarification, RISC-V specific content in EBBR is not merged
yet. The last version of the patch can be found here.

https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg01545.html

I will try to revise/rebase it on the latest EBBR specification.

Sure, actually for the above argument on H extension, we should mention
what would be the privilege level if H extension is implemented because.
If this patch gets into the EBBR, we can just point to that then.
I will connect with you to change this before sending the next version
of the patch.

+- 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 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 Firm
ware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI
functions
+marked as EFI_BOOT_SERVICES.
+

Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can
reworded similar to what EBBR has done.

All functions defined as boot services must exist. Methods for
unsupported or unimplemented behavior must return an appropriate error
code.

Agree

+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch and
the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- Before yielding control to S-Mode stage, firmware must configure
the M-Mode
+state. Refer the RISC-V SBI specification for details.

Are we talking about only CSR configuration or all other implmentation
expectations from M-mode such as interrupt/exception delegation,
misaligned/missing CSR emulation, PMP configuration ?

All which an SEE should do, Do we need to really define what it has to do?
Is that what you are asking

+- 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].
+

In addition to this, should we standardize a start address (i.e.
0x80000000)

We should discuss this

+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system
description.
+- 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
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified
by the
+RISC-V SBI Specification.

I think we can just mandate SBI v0.3. The base specification may not
have to implement all the SBI extensions in future.

But then shall we not revise the base spec and mention what not to
implement from SBI spec here, Just like EBBR makes some things deprecated
and optional from UEFI and other specs?

+- Wherever applicable firmware must implement UEFI interfaces over
similar
+interfaces and services present in the SBI specification. For
example, UEFI
+runtime services must implement ResetSystem() via SBI Reset
extension.
+- 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 when accessing the
mapped
+devices.
+- 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.

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

--
Regards,
Atish

On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote:

-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Rahul Pathak
Sent: 24 April 2021 07:41
To: Atish Patra <Atish.Patra@...>
Cc: tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot
and
runtime requirements - initial commit

On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...>
wrote:

On Tue, 2021-04-20 at 17:51 +0530, 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 | 125
++++++++++++++++++++++++++++++++++++-
--
 1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-
spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ 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.p
df[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[AC
PI

 Specification]              | v6.4
+|link:

https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3
.4.0.pdf[SMBIOS

 Specification]    | v3.4.0
+|link:[Platform
Policy]
                         | TBD
+|===
+
 // Base feature set for Linux-2022 Platform  === Base  ====
Architecture @@ -57,14 +87,95 @@ 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.
+- 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.
+- The base runtime specification depends on the RISC-V SBI
specification and
+all requirements from the SBI spec must be implemented.

This statement is bit ambiguous given that individual SBI section
says
legacy ones must not be implemented.

Ok, What I thought while mentioning this that, if SBI spec mentions
that
Legacy interfaces should not be implemented" then this statement is
also a
requirement just "to not implement".
But I think lets change the wording to this - "SBI Specification
compliance is
must for conformation with the Base Specification"
BTW I have explicitly mentioned to not implement Legacy Extension
from SBI
in the Runtime Section below

+- Any RV32GC or RV64GC system with Machine, Supervisor and
User
+Mode
can comply
+with the base specification.

Should we reword something like this,

Any platform seeking compliance with the base specification, must
implement all three privilege modes i.e. M/S/U mode.

Should we not mandate the minimum ISA required to support the rich
os.

The minimum ISA required is specified by RVA22 profile. I think
platform spec should only specify any ISA requirements if any required
ISA extensions are not specified by the profile.

Hypervisor Extension is optional.

Do we need to state this explicitly? I am just trying see if we
can
avoid any statements with optional word as per previous
discussions.

Any platform implementing M/S/U complies with base. If they
implement
H extension on top of that but not aimed for server extension
compliance, they are still compliant with base specification.

Agree

+_**Will be defined in this spec if the RVA22 spec does not
mention
it.**_
+- 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.

Just for clarification, RISC-V specific content in EBBR is not
merged
yet. The last version of the patch can be found here.


https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg015
45.html

I will try to revise/rebase it on the latest EBBR specification.

Sure, actually for the above argument on H extension, we should
mention
what would be the privilege level if H extension is implemented
because.
If this patch gets into the EBBR, we can just point to that then.
I will connect with you to change this before sending the next
version of the
patch.

It does not matter whether H-extension is implemented or not.

The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or
VS-mode).

The VS-mode is same as S-mode whereas HS-mode is S-mode with
additional hypervisor capabilities.

Pasting the relevant snippet from the the EBBR patch


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

+- 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 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-elem
ents[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
+Firm
ware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all
UEFI
functions
+marked as EFI_BOOT_SERVICES.
+

Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can
reworded similar to what EBBR has done.

All functions defined as boot services must exist. Methods for
unsupported or unimplemented behavior must return an appropriate
error
code.

Agree

+====== Startup Protocol
+- 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. For firmware privilege mode requirements, mode switch
and
the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V
Platforms.
+- Before yielding control to S-Mode stage, firmware must
configure
the M-Mode
+state. Refer the RISC-V SBI specification for details.

Are we talking about only CSR configuration or all other
implmentation
expectations from M-mode such as interrupt/exception delegation,
misaligned/missing CSR emulation, PMP configuration ?

All which an SEE should do, Do we need to really define what it has
to do?
Is that what you are asking

Yes. Depending on the content of the profile RVA22, we may need to
specify the minimum required actions of SEE. We need to discuss this in
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].
+

In addition to this, should we standardize a start address (i.e.
0x80000000)

We should discuss this

Yep.

+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for
system
description.
+- 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
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions
specified
by the
+RISC-V SBI Specification.

I think we can just mandate SBI v0.3. The base specification may
not
have to implement all the SBI extensions in future.

But then shall we not revise the base spec and mention what not to
implement from SBI spec here, Just like EBBR makes some things
deprecated
and optional from UEFI and other specs?

We cannot have just one blindly point to SBI specification. All SBI
extensions
are defined as optional but certain SBI extensions become mandatory
if hardware
lacks capabilities.

Here are few examples,

1) If "stimecmp" CSRs are available then SBI TIME extension is
optional
     otherwise SBI TIME extension is mandatory
2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not
have
     AIA IMSIC then SBI IPI extension and SBI RFENCE extension is
mandatory

I am still not convinced if platform spec should allow APLIC + CLINT
combination.

Why doses a platform want to implement only a part of AIA and leave out
IMSIC ?

3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI
RFENCE
     extension is mandatory

The BASE profile should "stimecmp" CSR and AIA iMSIC is optional
whereas
these HW features will be mandatory for SERVER profile.

List of BASE profile SBI extensions:
1) SBI spec version should be at least 0.3
2) SBI TIME extension is mandatory if "stimecmp" CSR not available
3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC +
CLINT
4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC
+ CLINT
5) SBI HSM extension is mandatory
6) SBI SRST extension is mandatory
7) SBI PMU extension is mandatory

The above list gets simplified for SERVER profile assuming "stimecmp"
and
AIA IMSIC are mandatory for SERVER profile. Here's the list:
1) SBI spec version should be at least 0.3
2) SBI HSM extension is mandatory
3) SBI SRST extension is mandatory
4) SBI PMU extension is mandatory

Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER
profile for older kernels (and other OSes or hypervisors)

To summarize, the mandatory set of SBI extensions is decided by the
underlying HW features.

Agreed.

+- Wherever applicable firmware must implement UEFI interfaces
over
similar
+interfaces and services present in the SBI specification. For
example, UEFI
+runtime services must implement ResetSystem() via SBI Reset
extension.
+- 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[EBB
+R
 - 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 when accessing
the
mapped
+devices.
+- 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.

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

--
Regards,
Atish

Regards,
Anup

--
Regards,
Atish