This specifies mandatory requirements for server class platforms in
addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...>

Changes in V2:
- Aligned to 80 characters.
- Removed protocols related to graphics support.
- Referred to SMBIOS conformance guidelines.
---
changelog.adoc | 4 +
licensing.adoc | 1 +
riscv-platform-spec.adoc | 187 +++++++++++++++++++++++++++++++++++++--
3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
[preface]
## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
### version 0.2-rc0
* 2021-03-16:
** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform Specification (P2S) is
(C) 2017 Andrew Waterman <andrew@...>
(C) 2020 Al Stone <ahs3@...>
(C) 2021 Kumar Sankaran <ksankaran@...>
+(C) 2021 Sunil V L <sunilvl@...>

The P2S is licensed under the Creative Commons Attribution 4.0 International
License (CC-BY 4.0). The full license text is available at
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
= RISC-V Platform Specification
:author: RISC-V Platform Specification Task Group
:email: tech-unixplatformspec@...
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
:doctype: book
:sectnums:
+:sectnumlevels: 5
:toc: macro
+:toclevels: 5

// table of contents
toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

// Server extension for Linux-2022 Platform
=== Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional requirements apart from base
+requirements for RV64I based server class platforms. Support for RV128I
+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must implement
+
+- Advanced Platform-Level Interrupt Controller (APLIC). [*Dependency:
+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec should be
+ratified*]
+- PCIe.
+
+- RISC-V Hypervisor-level Instruction-Set Extensions. [*Dependency:
+Spec should be ratified*]
+- Incoming MSI Controller (IMSIC) with at least 1 guest interrupt
+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ?? (*TBD*)
+
+==== Boot and Runtime Requirements
+===== Firmware
+The boot and system firmware for the RV64I server platforms must be
+based on UEFI as per the base specification with some additional
+requirements as mentioned below.
+
+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and *EFI_PCI_IO_PROTOCOL*
+must be implemented.
+
+====== UEFI configuration tables
+The platform which is complaint with server extension must provide following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is at version 6.4+ or
+newer with HW-Reduced ACPI model.
+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to version 3.4 or later.
+
+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in addition to the base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
+|EFI_DECOMPRESS_PROTOCOL | 19.5 |
+|===
+
+===== Boot-Loader
+*TBD*
+
+===== Discovery Mechanisms (ACPI)
+For RV64I server platforms, it is mandatory to have ACPI tables passed via UEFI
+to the operating system for the purpose of discovery and the configuration of
+the hardware. This section defines mandatory ACPI tables and objects. All other
+ACPI tables for RISC-V can be implemented as required adhering to the ACPI spec
+version 6.4+(RISC-V support when added).
+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table |ACPI 6.4+ $|Note
+|Root System Description Pointer (RSDP) |5.2.5 |
+|Extended System Description Table (XSDT) |5.2.8 |
+|Fixed ACPI Description Table (FADT) |5.2.9 |
+|Differentiated System Description Table (DSDT)|5.2.11.1 |
+|Multiple APIC Description Table (MADT) |5.2.12 |*TBD*: Need ECR
+ to add
+ APLIC & IMSIC
+ (AIA) to MADT
+|RISC-V Timer Description Table |New |*TBD*: _DSD to
+ communicate
+ timebase-frequency?
+|Processor Properties Topology Table (PPTT) |5.2.29 |CPU/Cache topology
+ information
+|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG |Required for PCIe
+ support
+|Debug Port Table 2 (DBG2) |Microsoft |*TBD*: 16550D?
+|Serial Port Console Redirection (SPCR) |Microsoft |*TBD*: 16550D?
+|System Resource Affinity Table (SRAT) |5.2.16 |Required if the
+ platform supports NUMA
+|System Locality Information Table (SLIT) |5.2.17 |Required if the
+ platform supports NUMA
+|IOMMU Information Table | |*TBD*: New IOMMU
+ table need to be
+ defined (like IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI |*TBD*: New table
+ and SBI extension
+ also may be required
+|PMU event mapping table? |New |*TBD*: New table
+ required
+|===
+
+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB) name space.
+- Below list of Device Objects and Methods must be implemented for each device
+ definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI | 5.6.5.2 | Required for GPIO-signalled events.
+|_EVT | 5.6.5.3 | Required for interrupt-signalled events.
+|_ADR | 6.1.1 | Required for PCI
+|_HID | 6.1.5 |
+|_UID | 6.1.12 |
+|_CRS | 6.2.2 |
+|_CCA | 6.2.17 | Required for DMA capable devices
+|_STA | 6.3.7/7.2.4 | Device status
+|===
+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services listed below.
+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service | UEFI 2.9 $ | Note
+|GetVariable | 8.2 |
+|GetNextVariableName | 8.2 |
+|SetVariable | 8.2 | A dedicated storage for firmware
+ should be available so that there
+ is no conflict in access by both
+ firmware and the OS.
+|QueryVariableInfo | 8.2 |
+|GetTime | 8.3 | RTC Access by the OS
+|SetTime | 8.3 | If it is not possible to set the RTC,
+ the SetTime() can return an error.
+|GetWakeupTime | 8.3 | Interface must be implemented but it
+ can return EFI_UNSUPPORTED.
+|SetWakeupTime | 8.3 | Interface must be implemented but it
+ can return EFI_UNSUPPORTED.
+|SetVirtualAddressMap | 8.4 |
+|ConvertPointer | 8.4 |
+|GetNextHighMonotonicCount | 8.5 |
+|ResetSystem | 8.5 | If SBI SRST implementation is also
+ available, the OS should not use the
+ SBI interface directly but use this
+ UEFI interface.
+|UpdateCapsule | 8.5 | Interface must be implemented but it
+ can return EFI_UNSUPPORTED.
+|QueryCapsuleCapabilities | 8.5 | Interface must be implemented but it
+ can return EFI_UNSUPPORTED.
+|===
+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for the platform
+complaint to server extension. The SMBIOS table is identified using
+*SMBIOS3_TABLE_GUID* in UEFI configuration table. EfiRuntimeServicesData must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in ANNEX A / 6.2 of the
+SMBIOS specification 3.4.0, below additional structures are mandatory.
+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type | SMBIOS 3.4.0 $ | Note
+|Management Controller Host Interface (Type 42) | 7.43 | *TBD*:
+ Redfish
+ support
+ mandatory?
+|Processor Additional Information (Type 44) | 7.45 |
+|===

==== System Peripherals
* PCI-E
--
2.25.1

Hi Abner,

On Wed, Apr 14, 2021 at 04:19:05PM +0800, Abner Chang wrote:

Hi Sunil,
Thanks for initial this.
I would like to suggest limiting the scope of Server Extension spec for
RISC-V server platform and only list the items which are RISC-V related.
I think the RISC-V platform spec is aimed at what should be implemented on
RISC-V platform and also follow the industrial standards. That says only
define the necessary spec for RISC-V platform-specific H/W features is
sufficient. Forgive me if I am wrong.

Thanks a lot for your review. I agree that we should try to limit the
scope of the platform spec to RISC-V. However, the platform spec is not
only defining RISC-V specific things. It is defining overall
requirements for base RISC-V platform and server class RISC-V platform
compliance. Industry standards specifications can have many things as
optional. But platform spec tries to define minimum features that need
to be implemented.

The platform policy document which is getting defined would bring more
clarity in this aspect.

My comments in below,

Sunil V L <sunilvl@...> 於 2021年4月12日 週一 下午6:40寫道：

This specifies mandatory requirements for server class platforms in
addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...>

Changes in V2:
- Aligned to 80 characters.
- Removed protocols related to graphics support.
- Referred to SMBIOS conformance guidelines.
---
changelog.adoc | 4 +
licensing.adoc | 1 +
riscv-platform-spec.adoc | 187 +++++++++++++++++++++++++++++++++++++--
3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
[preface]
## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
### version 0.2-rc0
* 2021-03-16:
** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform Specification (P2S) is
(C) 2017 Andrew Waterman <andrew@...>
(C) 2020 Al Stone <ahs3@...>
(C) 2021 Kumar Sankaran <ksankaran@...>
+(C) 2021 Sunil V L <sunilvl@...>

The P2S is licensed under the Creative Commons Attribution 4.0
International
License (CC-BY 4.0). The full license text is available at
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
= RISC-V Platform Specification
:author: RISC-V Platform Specification Task Group
:email: tech-unixplatformspec@...
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
:doctype: book
:sectnums:
+:sectnumlevels: 5
:toc: macro
+:toclevels: 5

// table of contents
toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

// Server extension for Linux-2022 Platform
=== Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional requirements apart from base
+requirements for RV64I based server class platforms. Support for RV128I
+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must implement
+
+- Advanced Platform-Level Interrupt Controller (APLIC). [*Dependency:
+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec should be
+ratified*]
+- PCIe.

+

+- RISC-V Hypervisor-level Instruction-Set Extensions. [*Dependency:
+Spec should be ratified*]

Is this the extension only for the server platform? Could be an extension
for all platforms, right?

For the base spec, it is not mandatory to have this extension. But for
servers, it doesn't make sense without Virtualization support.

+- Incoming MSI Controller (IMSIC) with at least 1 guest interrupt

+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ?? (*TBD*)

+

+==== Boot and Runtime Requirements
+===== Firmware
+The boot and system firmware for the RV64I server platforms must be
+based on UEFI as per the base specification with some additional

"must be" seems to me a little bit strong. The system firmware could be
LinuxBoot, uboot, or other solutions which do not have or only support the
minimum requirements of UEFI protocols
and I think it would be better to change this section from " Firmware" to
"UEFI Based System Firmware" under Server Extension section.

The server extension requirements are driven mainly from the server OSs
and additional capabilities required by a server class platform. The
delivery schedule of OS support and the platform/firmware release
can be totally independent if we adhere to the standards. UEFI is
mandatory standard from the server OS support perspective.

+requirements as mentioned below.

+

+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and *EFI_PCI_IO_PROTOCOL*
+must be implemented.

Not sure why we have to mention PCIe here for the server platform. This
seems to me regardless of RISC-V platform. Other buses such as CXL or Gen-Z
could be supported as well. This is more like the part of the system
firmware spec.

If we want to mention this, I would say *if* PCIe devices are supported on
the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be installed for
the UEFI firmware solution.

It is a good point that there can be other interconnect technologies.
The idea was to differentiate server class platforms with normal in
terms of the IO capability. There is a chapter in the spec
regarding PCIe which is TBD. For now, I will mention here as you
suggested.

We don't have to mention protocol function
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and EFI_PCI_IO_PROTOCOL,
those should be handled by UEFI implementation, such as the UEFI/EDK2 PCI
BUS driver

Sure. Thanks. I will just point to chapter 14 of UEFI spec.

+
+====== UEFI configuration tables
+The platform which is complaint with server extension must provide
following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is at version
6.4+ or
+newer with HW-Reduced ACPI model.

ACPI table is general for all ACPI-aware OS. This seems not necessary to
be in the scope of RISC-V platform spec,

+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to version 3.4 or
later.

uboot doesn't have SMBIOS at least for the RISC-V platform. Devicetree
table UEFI configuration table is needed as well for the non-SMBIOS-aware
OS.
So we can rephrase this to * *SMBIOS3_TABLE_GUID* SMBIOS table which
conforms to version 3.4 or later if the platform support SMBIOS-aware
pre-OS applications and OS.
Also add another similar section for the device tree use case, which
is EFI_DTB_TABLE_GUID for the platform which supports DT-aware pre-OS
application or OS.
And the reason to have these configuration tables is either SMBIOS or DT
carries the information of RISC-V HW features.

We are mandating SMBIOS and ACPI for the server extension. The base
specification will allow implementations with DT and without SMBIOS
support. Like I said earlier, the requirements for the server class are
driven by the OS support and additional capabilities required.

+

+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in addition to the
base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
+|EFI_DECOMPRESS_PROTOCOL | 19.5 |
+|===
+

What UEFI protocols must be implemented is platform design specific. We may
have a long list of UEFI protocols for the large system (for example if it
supports any kind of boot methods). Therefore I don't think we need this
section.

True. But these are mandatory on top of base platform specification. The
platforms can support further additional protocols which are not
mentioned in base spec or server extension.

+===== Boot-Loader

+*TBD*
+
+===== Discovery Mechanisms (ACPI)

First of all, I don't quite understand what exactly the Discovery
Mechanisms mean? for the hardware feature discovery?

If so, SMBIOS and DeviceTree is also part of this section, not only ACPI

Like mentioned below, it is for the purpose of discovery and
configuration of the HW. Device tree is not supported in server class
platforms. As per my understanding, SMBIOS is mainly for management
applications not for basic HW configuration. Hence, only ACPI mentioned
here. Please correct me if I am wrong.

+For RV64I server platforms, it is mandatory to have ACPI tables passed
via UEFI
+to the operating system for the purpose of discovery and the
configuration of
+the hardware. This section defines mandatory ACPI tables and objects. All
other
+ACPI tables for RISC-V can be implemented as required adhering to the
ACPI spec
+version 6.4+(RISC-V support when added).

+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table |ACPI 6.4+ $|Note
+|Root System Description Pointer (RSDP) |5.2.5 |
+|Extended System Description Table (XSDT) |5.2.8 |
+|Fixed ACPI Description Table (FADT) |5.2.9 |
+|Differentiated System Description Table (DSDT)|5.2.11.1 |
+|Multiple APIC Description Table (MADT) |5.2.12 |*TBD*: Need
ECR
+ to add
+ APLIC & IMSIC
+ (AIA) to MADT
+|RISC-V Timer Description Table |New |*TBD*: _DSD to
+ communicate
+
timebase-frequency?
+|Processor Properties Topology Table (PPTT) |5.2.29 |CPU/Cache
topology
+ information
+|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG |Required for
PCIe
+ support
+|Debug Port Table 2 (DBG2) |Microsoft |*TBD*: 16550D?
+|Serial Port Console Redirection (SPCR) |Microsoft |*TBD*: 16550D?
+|System Resource Affinity Table (SRAT) |5.2.16 |Required if
the
+ platform
supports NUMA
+|System Locality Information Table (SLIT) |5.2.17 |Required if
the
+ platform
supports NUMA
+|IOMMU Information Table | |*TBD*: New
IOMMU
+ table need to
be
+ defined (like
IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI |*TBD*: New
table
+ and SBI
extension
+ also may be
required
+|PMU event mapping table? |New |*TBD*: New
table
+ required
+|===
+

Most of the above tables are generic and not RISC-V specific for the server
platform. Perhaps only keep MADT, SDEI, and others which are marked as
"New". However, I don't know if those "New" tables have been discussing in
UEFI ASWG or those are just the proposal.

ACPI defines many tables and not all of them are mandatory. Here, we are
defining what is the minimum set of those tables needed to be
implemented.

These are starting points to enable ACPI for RISC-V. There is no ECRs
sent yet to ASWG. We need to gather more details before starting
discussion in ASWG. For ex: Need IOMMU spec before we can send ECR.

+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB) name space.
+- Below list of Device Objects and Methods must be implemented for each
device
+ definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI | 5.6.5.2 | Required for GPIO-signalled events.
+|_EVT | 5.6.5.3 | Required for interrupt-signalled events.
+|_ADR | 6.1.1 | Required for PCI
+|_HID | 6.1.5 |
+|_UID | 6.1.12 |
+|_CRS | 6.2.2 |
+|_CCA | 6.2.17 | Required for DMA capable devices
+|_STA | 6.3.7/7.2.4 | Device status
+|===

Also, this seems to me not specific to RISC-V platform.

Not specific to RISC-V but mandatory minimum requirements to adhere to
server class out of many things in ACPI spec.

+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services listed below.
+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service | UEFI 2.9 $ | Note
+|GetVariable | 8.2 |
+|GetNextVariableName | 8.2 |
+|SetVariable | 8.2 | A dedicated storage for firmware
+ should be available so that
there
+ is no conflict in access by both
+ firmware and the OS.
+|QueryVariableInfo | 8.2 |
+|GetTime | 8.3 | RTC Access by the OS
+|SetTime | 8.3 | If it is not possible to set
the RTC,
+ the SetTime() can return an
error.
+|GetWakeupTime | 8.3 | Interface must be implemented
but it
+ can return EFI_UNSUPPORTED.
+|SetWakeupTime | 8.3 | Interface must be implemented
but it
+ can return EFI_UNSUPPORTED.
+|SetVirtualAddressMap | 8.4 |
+|ConvertPointer | 8.4 |
+|GetNextHighMonotonicCount | 8.5 |
+|ResetSystem | 8.5 | If SBI SRST implementation is
also
+ available, the OS should not
use the
+ SBI interface directly but use
this
+ UEFI interface.
+|UpdateCapsule | 8.5 | Interface must be implemented
but it
+ can return EFI_UNSUPPORTED.
+|QueryCapsuleCapabilities | 8.5 | Interface must be implemented
but it
+ can return EFI_UNSUPPORTED.
+|===

Not sure if we really need above section.

The way platform spec is structured is base + extension. The base spec
keeps most of these as optional at run time. But we are mandating them to
be supported in server class. Hence mentioned here explicitly.

+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for the platform
+complaint to server extension. The SMBIOS table is identified using
+*SMBIOS3_TABLE_GUID* in UEFI configuration table. EfiRuntimeServicesData
must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in ANNEX A / 6.2
of the
+SMBIOS specification 3.4.0, below additional structures are mandatory.
+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type | SMBIOS 3.4.0 $ | Note
+|Management Controller Host Interface (Type 42) | 7.43 | *TBD*:
+ Redfish
+ support
+
mandatory?

Not mandatory if no remote management for the system firmware platform
configurations.

OK Thanks.

Abner

+|Processor Additional Information (Type 44) | 7.45 |

+|===

==== System Peripherals
* PCI-E
--
2.25.1

On 14.04.21 10:19, Abner Chang wrote:

Hi Sunil,
Thanks for initial this.
I would like to suggest limiting the scope of Server Extension spec for
RISC-V server platform and only list the items which are RISC-V related. 
I think the RISC-V platform spec is aimed at what should be implemented
on RISC-V platform and also follow the industrial standards. That says
only define the necessary spec for RISC-V platform-specific H/W features
is sufficient. Forgive me if I am wrong.

My comments in below,

Sunil V L <sunilvl@... <mailto:sunilvl@...>>
於 2021年4月12日 週一 下午6:40寫道：

This specifies mandatory requirements for server class platforms in
addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

Changes in V2:
 - Aligned to 80 characters.
 - Removed protocols related to graphics support.
 - Referred to SMBIOS conformance guidelines.
---
 changelog.adoc           |   4 +
 licensing.adoc           |   1 +
 riscv-platform-spec.adoc | 187 +++++++++++++++++++++++++++++++++++++--
 3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
 [preface]
 ## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
 ### version 0.2-rc0
 * 2021-03-16:
 ** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform Specification
(P2S) is
 (C) 2017 Andrew Waterman <andrew@... <mailto:andrew@...>>
 (C) 2020 Al Stone <ahs3@... <mailto:ahs3@...>>
 (C) 2021 Kumar Sankaran <ksankaran@...
<mailto:ksankaran@...>>
+(C) 2021 Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

 The P2S is licensed under the Creative Commons Attribution 4.0
International
 License (CC-BY 4.0).  The full license text is available at
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
 = RISC-V Platform Specification
 :author: RISC-V Platform Specification Task Group
 :email: tech-unixplatformspec@...
<mailto:tech-unixplatformspec@...>
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
 :doctype: book
 :sectnums:
+:sectnumlevels: 5
 :toc: macro
+:toclevels: 5

 // table of contents
 toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

 // Server extension for Linux-2022 Platform
 === Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional  requirements apart from base
+requirements for RV64I based server class platforms. Support for RV128I
+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must implement
+
+- Advanced Platform-Level Interrupt Controller (APLIC). [*Dependency:
+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec should be
+ratified*]
+- PCIe.

+
+- RISC-V Hypervisor-level Instruction-Set Extensions. [*Dependency:
+Spec should be ratified*]

Is this the extension only for the server platform? Could be an
extension for all platforms, right?

+- Incoming MSI Controller (IMSIC) with at least 1 guest interrupt
+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ?? (*TBD*)

+
+==== Boot and Runtime Requirements
+=====  Firmware
+The boot and system firmware for the RV64I server platforms must be
+based on UEFI as per the base specification with some additional

"must be" seems to me a little bit strong. The system firmware could be
LinuxBoot, uboot, or other solutions which do not have or only support
the minimum requirements of UEFI protocols
and I think it would be better to change this section from " Firmware"
to "UEFI Based System Firmware"  under Server Extension section.

If you look at the ARM landscape there you have:

EBBR: sub-set of UEFI required, fulfilled by U-Boot
SBBR: more UEFI required, fulfilled by EDK II
LBBR: LinuxBoot required

The RISC-V Linux platform requirements matches EBBR.
My understanding was that this chapter is meant to match SBBR.
Maybe we need an extra chapter on LinuxBoot requirements.

+requirements as mentioned below.

+
+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and
*EFI_PCI_IO_PROTOCOL*
+must be implemented.

Not sure why we have to mention PCIe here for the server platform. This
seems to me regardless of RISC-V platform. Other buses such as CXL or
Gen-Z could be supported as well.  This is more like the part of the
system firmware spec.
If we want to mention this, I would say *if* PCIe devices are supported
on the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be
installed for the UEFI firmware solution.

We don't have to mention protocol function
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and  EFI_PCI_IO_PROTOCOL,
those should be handled by UEFI implementation, such as the UEFI/EDK2
PCI BUS driver

+
+====== UEFI configuration tables
+The platform which is complaint with server extension must provide
following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is at
version 6.4+ or
+newer with HW-Reduced ACPI model.

ACPI table is general for all ACPI-aware OS.  This seems not necessary
to be in the scope of RISC-V platform spec,  

+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to version 3.4
or later.

uboot doesn't have SMBIOS at least for the RISC-V platform. Devicetree
table UEFI configuration table is needed as well for the
non-SMBIOS-aware OS.

U-Boot creates an SMBIOS table with some information for ARM. This could
easily be extended to RISC-V.

So we can rephrase this to  * *SMBIOS3_TABLE_GUID* SMBIOS table which
conforms to version 3.4 or later if the platform support SMBIOS-aware
pre-OS applications and OS.
Also add another similar section for the device tree use case, which
is EFI_DTB_TABLE_GUID for the platform which supports  DT-aware pre-OS
application or OS.

The device-tree use case is described in the EBBR which is referenced in
the Linux platform chapter. Why should this be repeated here?

And the reason to have these configuration tables is either SMBIOS or DT
carries the information of RISC-V HW features.

The information in SMBIOS and DT is independent. SMBIOS will carry
information that does not exist in the device-tree.

Best regards

Heinrich

+
+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in addition to
the base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol                              | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL               | 13.2       |
+|EFI_DECOMPRESS_PROTOCOL               | 19.5       |
+|===
+

What UEFI protocols must be implemented is platform design specific. We
may have a long list of UEFI protocols for the large system (for example
if it supports any kind of boot methods). Therefore I don't think we
need this section.

+===== Boot-Loader
+*TBD*
+
+===== Discovery Mechanisms (ACPI)

First of all, I don't quite understand what exactly the  Discovery
Mechanisms mean? for the hardware feature discovery?

If so, SMBIOS and DeviceTree is also part of this section, not only ACPI

+For RV64I server platforms, it is mandatory to have ACPI tables
passed via UEFI
+to the operating system for the purpose of discovery and the
configuration of
+the hardware. This section defines mandatory ACPI tables and
objects. All other
+ACPI tables for RISC-V can be implemented as required adhering to
the ACPI spec
+version 6.4+(RISC-V support when added).

 

+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table                                    |ACPI 6.4+ $|Note
+|Root System Description Pointer (RSDP)        |5.2.5      |
+|Extended System Description Table (XSDT)      |5.2.8      |
+|Fixed ACPI Description Table (FADT)           |5.2.9      |
+|Differentiated System Description Table (DSDT)|5.2.11.1   |
+|Multiple APIC Description Table (MADT)        |5.2.12     |*TBD*:
Need ECR
+                                                            to add
+                                                            APLIC &
IMSIC
+                                                            (AIA)
to MADT
+|RISC-V Timer Description Table                |New        |*TBD*:
_DSD to
+                                                            communicate
+                                                           
timebase-frequency?
+|Processor Properties Topology Table (PPTT)    |5.2.29   
 |CPU/Cache topology
+                                                            information
+|Memory-mapped ConFiGuration space (MCFG)      |PCI-SIG   
|Required for PCIe
+                                                            support
+|Debug Port Table 2 (DBG2)                     |Microsoft  |*TBD*:
16550D?
+|Serial Port Console Redirection (SPCR)        |Microsoft  |*TBD*:
16550D?
+|System Resource Affinity Table (SRAT)         |5.2.16   
 |Required if the
+                                                           
platform supports NUMA
+|System Locality Information Table (SLIT)      |5.2.17   
 |Required if the
+                                                           
platform supports NUMA
+|IOMMU Information Table                       |           |*TBD*:
New IOMMU
+                                                            table
need to be
+                                                            defined
(like IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI       |*TBD*:
New table
+                                                            and SBI
extension
+                                                            also
may be required
+|PMU event mapping table?                      |New        |*TBD*:
New table
+                                                            required
+|===
+

Most of the above tables are generic and not RISC-V specific for the
server platform. Perhaps only keep MADT, SDEI, and others which are
marked as "New". However, I don't know if those "New" tables have been
discussing in UEFI ASWG or those are just the proposal.
 

+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB) name space.
+- Below list of Device Objects and Methods must be implemented for
each device
+  definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI          | 5.6.5.2     | Required for GPIO-signalled events.
+|_EVT          | 5.6.5.3     | Required for interrupt-signalled events.
+|_ADR          | 6.1.1       | Required for PCI
+|_HID          | 6.1.5       |
+|_UID          | 6.1.12      |
+|_CRS          | 6.2.2       |
+|_CCA          | 6.2.17      | Required for DMA capable devices
+|_STA          | 6.3.7/7.2.4 | Device status
+|===

Also, this seems to me not specific to RISC-V platform.

+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services listed below.
+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service                   | UEFI 2.9 $ | Note
+|GetVariable               | 8.2        |
+|GetNextVariableName       | 8.2        |
+|SetVariable               | 8.2        | A dedicated storage for
firmware
+                                          should be available so
that there
+                                          is no conflict in access
by both
+                                          firmware and the OS.
+|QueryVariableInfo         | 8.2        |
+|GetTime                   | 8.3        | RTC Access by the OS
+|SetTime                   | 8.3        | If it is not possible to
set the RTC,
+                                          the SetTime() can return
an error.
+|GetWakeupTime             | 8.3        | Interface must be
implemented but it
+                                          can return EFI_UNSUPPORTED.
+|SetWakeupTime             | 8.3        | Interface must be
implemented but it
+                                          can return EFI_UNSUPPORTED.
+|SetVirtualAddressMap      | 8.4        |
+|ConvertPointer            | 8.4        |
+|GetNextHighMonotonicCount | 8.5        |
+|ResetSystem               | 8.5        | If SBI SRST
implementation is also
+                                          available, the OS should
not use the
+                                          SBI interface directly
but use this
+                                          UEFI interface.
+|UpdateCapsule             | 8.5        | Interface must be
implemented but it
+                                          can return EFI_UNSUPPORTED.
+|QueryCapsuleCapabilities  | 8.5        | Interface must be
implemented but it
+                                          can return EFI_UNSUPPORTED.
+|===

Not sure if we really need above section. 

+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for the platform
+complaint to server extension. The SMBIOS table is identified using
+*SMBIOS3_TABLE_GUID* in UEFI configuration table.
EfiRuntimeServicesData must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in ANNEX A /
6.2 of the
+SMBIOS specification 3.4.0, below additional structures are mandatory.
+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type                                 | SMBIOS 3.4.0 $ | Note
+|Management Controller Host Interface (Type 42) | 7.43           |
*TBD*:
+                                                                 
 Redfish
+                                                                 
 support
+                                                                 
 mandatory?

Not mandatory if no remote management for the system firmware platform
configurations.

Abner

+|Processor Additional Information (Type 44)     | 7.45           |
+|===

 ==== System Peripherals
 * PCI-E
--
2.25.1

Hi Abner,

On Thu, Apr 15, 2021 at 09:44:00PM +0800, Abner Chang wrote:

Heinrich Schuchardt <xypron.glpk@...> 於 2021年4月14日 週三 下午9:19寫道：

On 14.04.21 10:19, Abner Chang wrote:

Hi Sunil,
Thanks for initial this.
I would like to suggest limiting the scope of Server Extension spec for
RISC-V server platform and only list the items which are RISC-V related.
I think the RISC-V platform spec is aimed at what should be implemented
on RISC-V platform and also follow the industrial standards. That says
only define the necessary spec for RISC-V platform-specific H/W features
is sufficient. Forgive me if I am wrong.

My comments in below,

Sunil V L <sunilvl@... <mailto:sunilvl@...>>
於 2021年4月12日 週一 下午6:40寫道：

This specifies mandatory requirements for server class platforms in
addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

Changes in V2:
- Aligned to 80 characters.
- Removed protocols related to graphics support.
- Referred to SMBIOS conformance guidelines.
---
changelog.adoc | 4 +
licensing.adoc | 1 +
riscv-platform-spec.adoc | 187

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

3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
[preface]
## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
### version 0.2-rc0
* 2021-03-16:
** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform Specification
(P2S) is
(C) 2017 Andrew Waterman <andrew@... <mailto:

andrew@...>>

(C) 2020 Al Stone <ahs3@... <mailto:ahs3@...>>
(C) 2021 Kumar Sankaran <ksankaran@...
<mailto:ksankaran@...>>
+(C) 2021 Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

The P2S is licensed under the Creative Commons Attribution 4.0
International
License (CC-BY 4.0). The full license text is available at
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
= RISC-V Platform Specification
:author: RISC-V Platform Specification Task Group
:email: tech-unixplatformspec@...
<mailto:tech-unixplatformspec@...>
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
:doctype: book
:sectnums:
+:sectnumlevels: 5
:toc: macro
+:toclevels: 5

// table of contents
toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

// Server extension for Linux-2022 Platform
=== Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional requirements apart from

base

+requirements for RV64I based server class platforms. Support for

RV128I

+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must implement
+
+- Advanced Platform-Level Interrupt Controller (APLIC).

[*Dependency:

+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec should be
+ratified*]
+- PCIe.

+
+- RISC-V Hypervisor-level Instruction-Set Extensions. [*Dependency:
+Spec should be ratified*]

Is this the extension only for the server platform? Could be an
extension for all platforms, right?

+- Incoming MSI Controller (IMSIC) with at least 1 guest interrupt
+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ?? (*TBD*)

+
+==== Boot and Runtime Requirements
+===== Firmware
+The boot and system firmware for the RV64I server platforms must be
+based on UEFI as per the base specification with some additional

"must be" seems to me a little bit strong. The system firmware could be
LinuxBoot, uboot, or other solutions which do not have or only support
the minimum requirements of UEFI protocols
and I think it would be better to change this section from " Firmware"
to "UEFI Based System Firmware" under Server Extension section.

If you look at the ARM landscape there you have:

EBBR: sub-set of UEFI required, fulfilled by U-Boot
SBBR: more UEFI required, fulfilled by EDK II
LBBR: LinuxBoot required

The RISC-V Linux platform requirements matches EBBR.
My understanding was that this chapter is meant to match SBBR.
Maybe we need an extra chapter on LinuxBoot requirements.

Exactly. If use Linuxboot as the firmware solution (this has been
discussing and investigating for a while although it is not mature yet) for
the server platform and launched after EDK2 PEI phase, then who cares about
UEFI?
I suggest we have two sections, one for UEFI based system another is not.

It is correct that server extension chapter is similar to SBBR.

We are not specifying any implementations here. U-Boot/EDK2/Linuxboot all are
different types of firmware implementations in my opinion. All we are
mandating here is the set of requirements server class platforms should
have. Why do we need to have separate chapter for Linuxboot?

+requirements as mentioned below.

+
+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and
*EFI_PCI_IO_PROTOCOL*
+must be implemented.

Not sure why we have to mention PCIe here for the server platform. This
seems to me regardless of RISC-V platform. Other buses such as CXL or
Gen-Z could be supported as well. This is more like the part of the
system firmware spec.
If we want to mention this, I would say *if* PCIe devices are supported
on the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be
installed for the UEFI firmware solution.

We don't have to mention protocol function
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and EFI_PCI_IO_PROTOCOL,
those should be handled by UEFI implementation, such as the UEFI/EDK2
PCI BUS driver

+
+====== UEFI configuration tables
+The platform which is complaint with server extension must provide
following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is at
version 6.4+ or
+newer with HW-Reduced ACPI model.

ACPI table is general for all ACPI-aware OS. This seems not necessary
to be in the scope of RISC-V platform spec,

+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to version 3.4
or later.

uboot doesn't have SMBIOS at least for the RISC-V platform. Devicetree
table UEFI configuration table is needed as well for the
non-SMBIOS-aware OS.

U-Boot creates an SMBIOS table with some information for ARM. This could
easily be extended to RISC-V.

So we can rephrase this to * *SMBIOS3_TABLE_GUID* SMBIOS table which
conforms to version 3.4 or later if the platform support SMBIOS-aware
pre-OS applications and OS.
Also add another similar section for the device tree use case, which
is EFI_DTB_TABLE_GUID for the platform which supports DT-aware pre-OS
application or OS.

The device-tree use case is described in the EBBR which is referenced in
the Linux platform chapter. Why should this be repeated here?

We would like to have a link here to point to ARM EBBR? I don't think that
is a good idea for RISC-V platform spec.
As I know EFI_DTB_GUID which defined in EBBR will be removed because
EFI_DTB_TABLE_GUID is standardized and pushed to UEFI 2.9 for any
architectures which require DT. SBBR will just use EFI_DTB_TABLE_GUID as
well because this GUID is proposed by SBBR people. RISC-V should also use
EFI_DTB_TABLE_GUID instead of using FDT_TABLE_GUID.

I assume EBBR also will get updated in that case. Isn't it?

And the reason to have these configuration tables is either SMBIOS or DT
carries the information of RISC-V HW features.

The information in SMBIOS and DT is independent.

Yes, those two are independent.

SMBIOS will carry
information that does not exist in the device-tree.

SMBIOS will also carry the information even that exists in DT for the
non-DT-aware OS such as Windows-based system.
The server is able to boot to either Windows or Linux-based OS, these two
data structures should be mentioned separately.

Regards,
Abner

Best regards

Heinrich

+
+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in addition to
the base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
+|EFI_DECOMPRESS_PROTOCOL | 19.5 |
+|===
+

What UEFI protocols must be implemented is platform design specific. We
may have a long list of UEFI protocols for the large system (for example
if it supports any kind of boot methods). Therefore I don't think we
need this section.

+===== Boot-Loader
+*TBD*
+
+===== Discovery Mechanisms (ACPI)

First of all, I don't quite understand what exactly the Discovery
Mechanisms mean? for the hardware feature discovery?

If so, SMBIOS and DeviceTree is also part of this section, not only ACPI

+For RV64I server platforms, it is mandatory to have ACPI tables
passed via UEFI
+to the operating system for the purpose of discovery and the
configuration of
+the hardware. This section defines mandatory ACPI tables and
objects. All other
+ACPI tables for RISC-V can be implemented as required adhering to
the ACPI spec
+version 6.4+(RISC-V support when added).



+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table |ACPI 6.4+ $|Note
+|Root System Description Pointer (RSDP) |5.2.5 |
+|Extended System Description Table (XSDT) |5.2.8 |
+|Fixed ACPI Description Table (FADT) |5.2.9 |
+|Differentiated System Description Table (DSDT)|5.2.11.1 |
+|Multiple APIC Description Table (MADT) |5.2.12 |*TBD*:
Need ECR
+ to add
+ APLIC &
IMSIC
+ (AIA)
to MADT
+|RISC-V Timer Description Table |New |*TBD*:
_DSD to
+

communicate

+
timebase-frequency?
+|Processor Properties Topology Table (PPTT) |5.2.29
|CPU/Cache topology
+

information

+|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG
|Required for PCIe
+ support
+|Debug Port Table 2 (DBG2) |Microsoft |*TBD*:
16550D?
+|Serial Port Console Redirection (SPCR) |Microsoft |*TBD*:
16550D?
+|System Resource Affinity Table (SRAT) |5.2.16
|Required if the
+
platform supports NUMA
+|System Locality Information Table (SLIT) |5.2.17
|Required if the
+
platform supports NUMA
+|IOMMU Information Table | |*TBD*:
New IOMMU
+ table
need to be
+ defined
(like IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI |*TBD*:
New table
+ and SBI
extension
+ also
may be required
+|PMU event mapping table? |New |*TBD*:
New table
+ required
+|===
+

Most of the above tables are generic and not RISC-V specific for the
server platform. Perhaps only keep MADT, SDEI, and others which are
marked as "New". However, I don't know if those "New" tables have been
discussing in UEFI ASWG or those are just the proposal.


+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB) name space.
+- Below list of Device Objects and Methods must be implemented for
each device
+ definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI | 5.6.5.2 | Required for GPIO-signalled events.
+|_EVT | 5.6.5.3 | Required for interrupt-signalled

events.

+|_ADR | 6.1.1 | Required for PCI
+|_HID | 6.1.5 |
+|_UID | 6.1.12 |
+|_CRS | 6.2.2 |
+|_CCA | 6.2.17 | Required for DMA capable devices
+|_STA | 6.3.7/7.2.4 | Device status
+|===

Also, this seems to me not specific to RISC-V platform.

+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services listed

below.

+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service | UEFI 2.9 $ | Note
+|GetVariable | 8.2 |
+|GetNextVariableName | 8.2 |
+|SetVariable | 8.2 | A dedicated storage for
firmware
+ should be available so
that there
+ is no conflict in access
by both
+ firmware and the OS.
+|QueryVariableInfo | 8.2 |
+|GetTime | 8.3 | RTC Access by the OS
+|SetTime | 8.3 | If it is not possible to
set the RTC,
+ the SetTime() can return
an error.
+|GetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetVirtualAddressMap | 8.4 |
+|ConvertPointer | 8.4 |
+|GetNextHighMonotonicCount | 8.5 |
+|ResetSystem | 8.5 | If SBI SRST
implementation is also
+ available, the OS should
not use the
+ SBI interface directly
but use this
+ UEFI interface.
+|UpdateCapsule | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|QueryCapsuleCapabilities | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|===

Not sure if we really need above section.

+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for the

platform

+complaint to server extension. The SMBIOS table is identified using
+*SMBIOS3_TABLE_GUID* in UEFI configuration table.
EfiRuntimeServicesData must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in ANNEX A /
6.2 of the
+SMBIOS specification 3.4.0, below additional structures are

mandatory.

+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type | SMBIOS 3.4.0 $ |

Note

+|Management Controller Host Interface (Type 42) | 7.43 |
*TBD*:
+
Redfish
+
support
+
mandatory?

Not mandatory if no remote management for the system firmware platform
configurations.

Abner

+|Processor Additional Information (Type 44) | 7.45 |
+|===

==== System Peripherals
* PCI-E
--
2.25.1

Am 15. April 2021 16:56:02 MESZ schrieb Sunil V L <sunilvl@...>:

Hi Abner,

On Thu, Apr 15, 2021 at 09:44:00PM +0800, Abner Chang wrote:

Heinrich Schuchardt <xypron.glpk@...> 於 2021年4月14日 週三 下午9:19寫道：

On 14.04.21 10:19, Abner Chang wrote:

Hi Sunil,
Thanks for initial this.
I would like to suggest limiting the scope of Server Extension

spec for

RISC-V server platform and only list the items which are RISC-V

related.

I think the RISC-V platform spec is aimed at what should be

implemented

on RISC-V platform and also follow the industrial standards. That

says

only define the necessary spec for RISC-V platform-specific H/W

features

is sufficient. Forgive me if I am wrong.

My comments in below,

Sunil V L <sunilvl@...

<mailto:sunilvl@...>>

於 2021年4月12日 週一 下午6:40寫道：

This specifies mandatory requirements for server class

platforms in

addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

Changes in V2:
- Aligned to 80 characters.
- Removed protocols related to graphics support.
- Referred to SMBIOS conformance guidelines.
---
changelog.adoc | 4 +
licensing.adoc | 1 +
riscv-platform-spec.adoc | 187

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

3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
[preface]
## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
### version 0.2-rc0
* 2021-03-16:
** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform

Specification

(P2S) is
(C) 2017 Andrew Waterman <andrew@... <mailto:

andrew@...>>

(C) 2020 Al Stone <ahs3@... <mailto:ahs3@...>>
(C) 2021 Kumar Sankaran <ksankaran@...
<mailto:ksankaran@...>>
+(C) 2021 Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

The P2S is licensed under the Creative Commons Attribution

4.0

International
License (CC-BY 4.0). The full license text is available at
diff --git a/riscv-platform-spec.adoc

b/riscv-platform-spec.adoc

index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
= RISC-V Platform Specification
:author: RISC-V Platform Specification Task Group
:email: tech-unixplatformspec@...
<mailto:tech-unixplatformspec@...>
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
:doctype: book
:sectnums:
+:sectnumlevels: 5
:toc: macro
+:toclevels: 5

// table of contents
toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

// Server extension for Linux-2022 Platform
=== Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional requirements

apart from

base

+requirements for RV64I based server class platforms. Support

for

RV128I

+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must

implement

+
+- Advanced Platform-Level Interrupt Controller (APLIC).

[*Dependency:

+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec

should be

+ratified*]
+- PCIe.

+
+- RISC-V Hypervisor-level Instruction-Set Extensions.

[*Dependency:

+Spec should be ratified*]

Is this the extension only for the server platform? Could be an
extension for all platforms, right?

+- Incoming MSI Controller (IMSIC) with at least 1 guest

interrupt

+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ??

(*TBD*)

+
+==== Boot and Runtime Requirements
+===== Firmware
+The boot and system firmware for the RV64I server platforms

must be

+based on UEFI as per the base specification with some

additional

"must be" seems to me a little bit strong. The system firmware

could be

LinuxBoot, uboot, or other solutions which do not have or only

support

the minimum requirements of UEFI protocols
and I think it would be better to change this section from "

Firmware"

to "UEFI Based System Firmware" under Server Extension section.

If you look at the ARM landscape there you have:

EBBR: sub-set of UEFI required, fulfilled by U-Boot
SBBR: more UEFI required, fulfilled by EDK II
LBBR: LinuxBoot required

The RISC-V Linux platform requirements matches EBBR.
My understanding was that this chapter is meant to match SBBR.
Maybe we need an extra chapter on LinuxBoot requirements.

Exactly. If use Linuxboot as the firmware solution (this has been
discussing and investigating for a while although it is not mature

yet) for

the server platform and launched after EDK2 PEI phase, then who cares

about

UEFI?
I suggest we have two sections, one for UEFI based system another is

not.

It is correct that server extension chapter is similar to SBBR.

We are not specifying any implementations here. U-Boot/EDK2/Linuxboot
all are
different types of firmware implementations in my opinion. All we are
mandating here is the set of requirements server class platforms should
have. Why do we need to have separate chapter for Linuxboot?

LinuxBoot is really special. It is not UEFI compliant but uses kexec which cannot boot non-Linux OSes.

+requirements as mentioned below.

+
+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and
*EFI_PCI_IO_PROTOCOL*
+must be implemented.

Not sure why we have to mention PCIe here for the server

platform. This

seems to me regardless of RISC-V platform. Other buses such as

CXL or

Gen-Z could be supported as well. This is more like the part of

the

system firmware spec.
If we want to mention this, I would say *if* PCIe devices are

supported

on the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be
installed for the UEFI firmware solution.

We don't have to mention protocol function
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and

EFI_PCI_IO_PROTOCOL,

those should be handled by UEFI implementation, such as the

UEFI/EDK2

PCI BUS driver

+
+====== UEFI configuration tables
+The platform which is complaint with server extension must

provide

following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is

at

version 6.4+ or
+newer with HW-Reduced ACPI model.

ACPI table is general for all ACPI-aware OS. This seems not

necessary

to be in the scope of RISC-V platform spec,

+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to

version 3.4

or later.

uboot doesn't have SMBIOS at least for the RISC-V platform.

Devicetree

table UEFI configuration table is needed as well for the
non-SMBIOS-aware OS.

U-Boot creates an SMBIOS table with some information for ARM. This

could

easily be extended to RISC-V.

So we can rephrase this to * *SMBIOS3_TABLE_GUID* SMBIOS table

which

conforms to version 3.4 or later if the platform support

SMBIOS-aware

pre-OS applications and OS.
Also add another similar section for the device tree use case,

which

is EFI_DTB_TABLE_GUID for the platform which supports DT-aware

pre-OS

application or OS.

The device-tree use case is described in the EBBR which is

referenced in

the Linux platform chapter. Why should this be repeated here?

We would like to have a link here to point to ARM EBBR? I don't think

that

is a good idea for RISC-V platform spec.
As I know EFI_DTB_GUID which defined in EBBR will be removed because
EFI_DTB_TABLE_GUID is standardized and pushed to UEFI 2.9 for any
architectures which require DT. SBBR will just use EFI_DTB_TABLE_GUID

as

well because this GUID is proposed by SBBR people. RISC-V should also

use

EFI_DTB_TABLE_GUID instead of using FDT_TABLE_GUID.

I assume EBBR also will get updated in that case. Isn't it?

And the reason to have these configuration tables is either

SMBIOS or DT

carries the information of RISC-V HW features.

The information in SMBIOS and DT is independent.

Yes, those two are independent.

SMBIOS will carry
information that does not exist in the device-tree.

SMBIOS will also carry the information even that exists in DT for the
non-DT-aware OS such as Windows-based system.
The server is able to boot to either Windows or Linux-based OS, these

two

data structures should be mentioned separately.

Regards,
Abner

Best regards

Heinrich

+
+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in

addition to

the base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
+|EFI_DECOMPRESS_PROTOCOL | 19.5 |
+|===
+

What UEFI protocols must be implemented is platform design

specific. We

may have a long list of UEFI protocols for the large system (for

example

if it supports any kind of boot methods). Therefore I don't think

we

need this section.

+===== Boot-Loader
+*TBD*
+
+===== Discovery Mechanisms (ACPI)

First of all, I don't quite understand what exactly the

Discovery

Mechanisms mean? for the hardware feature discovery?

If so, SMBIOS and DeviceTree is also part of this section, not

only ACPI

+For RV64I server platforms, it is mandatory to have ACPI

tables

passed via UEFI
+to the operating system for the purpose of discovery and the
configuration of
+the hardware. This section defines mandatory ACPI tables and
objects. All other
+ACPI tables for RISC-V can be implemented as required

adhering to

the ACPI spec
+version 6.4+(RISC-V support when added).



+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table |ACPI 6.4+

$|Note

+|Root System Description Pointer (RSDP) |5.2.5 |
+|Extended System Description Table (XSDT) |5.2.8 |
+|Fixed ACPI Description Table (FADT) |5.2.9 |
+|Differentiated System Description Table (DSDT)|5.2.11.1 |
+|Multiple APIC Description Table (MADT) |5.2.12

|*TBD*:

Need ECR
+

to add

+

APLIC &

IMSIC
+

(AIA)

to MADT
+|RISC-V Timer Description Table |New

|*TBD*:

_DSD to
+

communicate

+
timebase-frequency?
+|Processor Properties Topology Table (PPTT) |5.2.29
|CPU/Cache topology
+

information

+|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG
|Required for PCIe
+

support

+|Debug Port Table 2 (DBG2) |Microsoft

|*TBD*:

16550D?
+|Serial Port Console Redirection (SPCR) |Microsoft

|*TBD*:

16550D?
+|System Resource Affinity Table (SRAT) |5.2.16
|Required if the
+
platform supports NUMA
+|System Locality Information Table (SLIT) |5.2.17
|Required if the
+
platform supports NUMA
+|IOMMU Information Table |

|*TBD*:

New IOMMU
+

table

need to be
+

defined

(like IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI

|*TBD*:

New table
+

and SBI

extension
+

also

may be required
+|PMU event mapping table? |New

|*TBD*:

New table
+

required

+|===
+

Most of the above tables are generic and not RISC-V specific for

the

server platform. Perhaps only keep MADT, SDEI, and others which

are

marked as "New". However, I don't know if those "New" tables have

been

discussing in UEFI ASWG or those are just the proposal.


+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB)

name space.

+- Below list of Device Objects and Methods must be

implemented for

each device
+ definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI | 5.6.5.2 | Required for GPIO-signalled

events.

+|_EVT | 5.6.5.3 | Required for

interrupt-signalled

events.

+|_ADR | 6.1.1 | Required for PCI
+|_HID | 6.1.5 |
+|_UID | 6.1.12 |
+|_CRS | 6.2.2 |
+|_CCA | 6.2.17 | Required for DMA capable

devices

+|_STA | 6.3.7/7.2.4 | Device status
+|===

Also, this seems to me not specific to RISC-V platform.

+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services

listed

below.

+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service | UEFI 2.9 $ | Note
+|GetVariable | 8.2 |
+|GetNextVariableName | 8.2 |
+|SetVariable | 8.2 | A dedicated

storage for

firmware
+ should be

available so

that there
+ is no conflict in

access

by both
+ firmware and the

OS.

+|QueryVariableInfo | 8.2 |
+|GetTime | 8.3 | RTC Access by the

OS

+|SetTime | 8.3 | If it is not

possible to

set the RTC,
+ the SetTime() can

return

an error.
+|GetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetVirtualAddressMap | 8.4 |
+|ConvertPointer | 8.4 |
+|GetNextHighMonotonicCount | 8.5 |
+|ResetSystem | 8.5 | If SBI SRST
implementation is also
+ available, the OS

should

not use the
+ SBI interface

directly

but use this
+ UEFI interface.
+|UpdateCapsule | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|QueryCapsuleCapabilities | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|===

Not sure if we really need above section.

+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for

the

platform

+complaint to server extension. The SMBIOS table is

identified using

+*SMBIOS3_TABLE_GUID* in UEFI configuration table.
EfiRuntimeServicesData must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in

ANNEX A /

6.2 of the
+SMBIOS specification 3.4.0, below additional structures are

mandatory.

+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type | SMBIOS

3.4.0 $ |

Note

+|Management Controller Host Interface (Type 42) | 7.43

|

*TBD*:
+
Redfish
+
support
+
mandatory?

Not mandatory if no remote management for the system firmware

platform

configurations.

Abner

+|Processor Additional Information (Type 44) | 7.45

|

+|===

==== System Peripherals
* PCI-E
--
2.25.1

On Thu, Apr 15, 2021 at 05:04:47PM +0200, Heinrich Schuchardt wrote:

Am 15. April 2021 16:56:02 MESZ schrieb Sunil V L <sunilvl@...>:

Hi Abner,

On Thu, Apr 15, 2021 at 09:44:00PM +0800, Abner Chang wrote:

Heinrich Schuchardt <xypron.glpk@...> 於 2021年4月14日 週三 下午9:19寫道：

On 14.04.21 10:19, Abner Chang wrote:

Hi Sunil,
Thanks for initial this.
I would like to suggest limiting the scope of Server Extension

spec for

RISC-V server platform and only list the items which are RISC-V

related.

I think the RISC-V platform spec is aimed at what should be

implemented

on RISC-V platform and also follow the industrial standards. That

says

only define the necessary spec for RISC-V platform-specific H/W

features

is sufficient. Forgive me if I am wrong.

My comments in below,

Sunil V L <sunilvl@...

<mailto:sunilvl@...>>

於 2021年4月12日 週一 下午6:40寫道：

This specifies mandatory requirements for server class

platforms in

addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

Changes in V2:
- Aligned to 80 characters.
- Removed protocols related to graphics support.
- Referred to SMBIOS conformance guidelines.
---
changelog.adoc | 4 +
licensing.adoc | 1 +
riscv-platform-spec.adoc | 187

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

3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
[preface]
## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
### version 0.2-rc0
* 2021-03-16:
** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform

Specification

(P2S) is
(C) 2017 Andrew Waterman <andrew@... <mailto:

andrew@...>>

(C) 2020 Al Stone <ahs3@... <mailto:ahs3@...>>
(C) 2021 Kumar Sankaran <ksankaran@...
<mailto:ksankaran@...>>
+(C) 2021 Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

The P2S is licensed under the Creative Commons Attribution

4.0

International
License (CC-BY 4.0). The full license text is available at
diff --git a/riscv-platform-spec.adoc

b/riscv-platform-spec.adoc

index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
= RISC-V Platform Specification
:author: RISC-V Platform Specification Task Group
:email: tech-unixplatformspec@...
<mailto:tech-unixplatformspec@...>
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
:doctype: book
:sectnums:
+:sectnumlevels: 5
:toc: macro
+:toclevels: 5

// table of contents
toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

// Server extension for Linux-2022 Platform
=== Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional requirements

apart from

base

+requirements for RV64I based server class platforms. Support

for

RV128I

+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must

implement

+
+- Advanced Platform-Level Interrupt Controller (APLIC).

[*Dependency:

+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec

should be

+ratified*]
+- PCIe.

+
+- RISC-V Hypervisor-level Instruction-Set Extensions.

[*Dependency:

+Spec should be ratified*]

Is this the extension only for the server platform? Could be an
extension for all platforms, right?

+- Incoming MSI Controller (IMSIC) with at least 1 guest

interrupt

+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ??

(*TBD*)

+
+==== Boot and Runtime Requirements
+===== Firmware
+The boot and system firmware for the RV64I server platforms

must be

+based on UEFI as per the base specification with some

additional

"must be" seems to me a little bit strong. The system firmware

could be

LinuxBoot, uboot, or other solutions which do not have or only

support

the minimum requirements of UEFI protocols
and I think it would be better to change this section from "

Firmware"

to "UEFI Based System Firmware" under Server Extension section.

If you look at the ARM landscape there you have:

EBBR: sub-set of UEFI required, fulfilled by U-Boot
SBBR: more UEFI required, fulfilled by EDK II
LBBR: LinuxBoot required

The RISC-V Linux platform requirements matches EBBR.
My understanding was that this chapter is meant to match SBBR.
Maybe we need an extra chapter on LinuxBoot requirements.

Exactly. If use Linuxboot as the firmware solution (this has been
discussing and investigating for a while although it is not mature

yet) for

the server platform and launched after EDK2 PEI phase, then who cares

about

UEFI?
I suggest we have two sections, one for UEFI based system another is

not.

It is correct that server extension chapter is similar to SBBR.

We are not specifying any implementations here. U-Boot/EDK2/Linuxboot
all are
different types of firmware implementations in my opinion. All we are
mandating here is the set of requirements server class platforms should
have. Why do we need to have separate chapter for Linuxboot?

LinuxBoot is really special. It is not UEFI compliant but uses kexec which cannot boot non-Linux OSes.

One criteria for server spec is to support different OSs including
windows. As per
https://www.phoronix.com/scan.php?page=news_item&px=LinuxBoot-Can-Boot-Windows
Linuxboot booted windows supporting UEFI boot and runtime services
(may be not a perfect implementation yet).

From server platform perspective, any new firmware implementation need
to satisfy the requirements from the OS. I really can't see how
Linuxboot can be so different and introduce whole set of new requirements
on multiple OSs. As per my understanding it is mainly trying to replace
EDK2 DXE phase with well tested Linux drivers. But the environment what
OS like windows will see should be kept intact.

+requirements as mentioned below.

+
+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and
*EFI_PCI_IO_PROTOCOL*
+must be implemented.

Not sure why we have to mention PCIe here for the server

platform. This

seems to me regardless of RISC-V platform. Other buses such as

CXL or

Gen-Z could be supported as well. This is more like the part of

the

system firmware spec.
If we want to mention this, I would say *if* PCIe devices are

supported

on the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be
installed for the UEFI firmware solution.

We don't have to mention protocol function
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and

EFI_PCI_IO_PROTOCOL,

those should be handled by UEFI implementation, such as the

UEFI/EDK2

PCI BUS driver

+
+====== UEFI configuration tables
+The platform which is complaint with server extension must

provide

following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is

at

version 6.4+ or
+newer with HW-Reduced ACPI model.

ACPI table is general for all ACPI-aware OS. This seems not

necessary

to be in the scope of RISC-V platform spec,

+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to

version 3.4

or later.

uboot doesn't have SMBIOS at least for the RISC-V platform.

Devicetree

table UEFI configuration table is needed as well for the
non-SMBIOS-aware OS.

U-Boot creates an SMBIOS table with some information for ARM. This

could

easily be extended to RISC-V.

So we can rephrase this to * *SMBIOS3_TABLE_GUID* SMBIOS table

which

conforms to version 3.4 or later if the platform support

SMBIOS-aware

pre-OS applications and OS.
Also add another similar section for the device tree use case,

which

is EFI_DTB_TABLE_GUID for the platform which supports DT-aware

pre-OS

application or OS.

The device-tree use case is described in the EBBR which is

referenced in

the Linux platform chapter. Why should this be repeated here?

We would like to have a link here to point to ARM EBBR? I don't think

that

is a good idea for RISC-V platform spec.
As I know EFI_DTB_GUID which defined in EBBR will be removed because
EFI_DTB_TABLE_GUID is standardized and pushed to UEFI 2.9 for any
architectures which require DT. SBBR will just use EFI_DTB_TABLE_GUID

as

well because this GUID is proposed by SBBR people. RISC-V should also

use

EFI_DTB_TABLE_GUID instead of using FDT_TABLE_GUID.

I assume EBBR also will get updated in that case. Isn't it?

And the reason to have these configuration tables is either

SMBIOS or DT

carries the information of RISC-V HW features.

The information in SMBIOS and DT is independent.

Yes, those two are independent.

SMBIOS will carry
information that does not exist in the device-tree.

SMBIOS will also carry the information even that exists in DT for the
non-DT-aware OS such as Windows-based system.
The server is able to boot to either Windows or Linux-based OS, these

two

data structures should be mentioned separately.

Regards,
Abner

Best regards

Heinrich

+
+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in

addition to

the base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
+|EFI_DECOMPRESS_PROTOCOL | 19.5 |
+|===
+

What UEFI protocols must be implemented is platform design

specific. We

may have a long list of UEFI protocols for the large system (for

example

if it supports any kind of boot methods). Therefore I don't think

we

need this section.

+===== Boot-Loader
+*TBD*
+
+===== Discovery Mechanisms (ACPI)

First of all, I don't quite understand what exactly the

Discovery

Mechanisms mean? for the hardware feature discovery?

If so, SMBIOS and DeviceTree is also part of this section, not

only ACPI

+For RV64I server platforms, it is mandatory to have ACPI

tables

passed via UEFI
+to the operating system for the purpose of discovery and the
configuration of
+the hardware. This section defines mandatory ACPI tables and
objects. All other
+ACPI tables for RISC-V can be implemented as required

adhering to

the ACPI spec
+version 6.4+(RISC-V support when added).



+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table |ACPI 6.4+

$|Note

+|Root System Description Pointer (RSDP) |5.2.5 |
+|Extended System Description Table (XSDT) |5.2.8 |
+|Fixed ACPI Description Table (FADT) |5.2.9 |
+|Differentiated System Description Table (DSDT)|5.2.11.1 |
+|Multiple APIC Description Table (MADT) |5.2.12

|*TBD*:

Need ECR
+

to add

+

APLIC &

IMSIC
+

(AIA)

to MADT
+|RISC-V Timer Description Table |New

|*TBD*:

_DSD to
+

communicate

+
timebase-frequency?
+|Processor Properties Topology Table (PPTT) |5.2.29
|CPU/Cache topology
+

information

+|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG
|Required for PCIe
+

support

+|Debug Port Table 2 (DBG2) |Microsoft

|*TBD*:

16550D?
+|Serial Port Console Redirection (SPCR) |Microsoft

|*TBD*:

16550D?
+|System Resource Affinity Table (SRAT) |5.2.16
|Required if the
+
platform supports NUMA
+|System Locality Information Table (SLIT) |5.2.17
|Required if the
+
platform supports NUMA
+|IOMMU Information Table |

|*TBD*:

New IOMMU
+

table

need to be
+

defined

(like IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI

|*TBD*:

New table
+

and SBI

extension
+

also

may be required
+|PMU event mapping table? |New

|*TBD*:

New table
+

required

+|===
+

Most of the above tables are generic and not RISC-V specific for

the

server platform. Perhaps only keep MADT, SDEI, and others which

are

marked as "New". However, I don't know if those "New" tables have

been

discussing in UEFI ASWG or those are just the proposal.


+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB)

name space.

+- Below list of Device Objects and Methods must be

implemented for

each device
+ definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI | 5.6.5.2 | Required for GPIO-signalled

events.

+|_EVT | 5.6.5.3 | Required for

interrupt-signalled

events.

+|_ADR | 6.1.1 | Required for PCI
+|_HID | 6.1.5 |
+|_UID | 6.1.12 |
+|_CRS | 6.2.2 |
+|_CCA | 6.2.17 | Required for DMA capable

devices

+|_STA | 6.3.7/7.2.4 | Device status
+|===

Also, this seems to me not specific to RISC-V platform.

+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services

listed

below.

+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service | UEFI 2.9 $ | Note
+|GetVariable | 8.2 |
+|GetNextVariableName | 8.2 |
+|SetVariable | 8.2 | A dedicated

storage for

firmware
+ should be

available so

that there
+ is no conflict in

access

by both
+ firmware and the

OS.

+|QueryVariableInfo | 8.2 |
+|GetTime | 8.3 | RTC Access by the

OS

+|SetTime | 8.3 | If it is not

possible to

set the RTC,
+ the SetTime() can

return

an error.
+|GetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetVirtualAddressMap | 8.4 |
+|ConvertPointer | 8.4 |
+|GetNextHighMonotonicCount | 8.5 |
+|ResetSystem | 8.5 | If SBI SRST
implementation is also
+ available, the OS

should

not use the
+ SBI interface

directly

but use this
+ UEFI interface.
+|UpdateCapsule | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|QueryCapsuleCapabilities | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|===

Not sure if we really need above section.

+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for

the

platform

+complaint to server extension. The SMBIOS table is

identified using

+*SMBIOS3_TABLE_GUID* in UEFI configuration table.
EfiRuntimeServicesData must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in

ANNEX A /

6.2 of the
+SMBIOS specification 3.4.0, below additional structures are

mandatory.

+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type | SMBIOS

3.4.0 $ |

Note

+|Management Controller Host Interface (Type 42) | 7.43

|

*TBD*:
+
Redfish
+
support
+
mandatory?

Not mandatory if no remote management for the system firmware

platform

configurations.

Abner

+|Processor Additional Information (Type 44) | 7.45

|

+|===

==== System Peripherals
* PCI-E
--
2.25.1

On 15.04.21 17:22, Sunil V L wrote:

On Thu, Apr 15, 2021 at 05:04:47PM +0200, Heinrich Schuchardt wrote:

Am 15. April 2021 16:56:02 MESZ schrieb Sunil V L <sunilvl@...>:

Hi Abner,

On Thu, Apr 15, 2021 at 09:44:00PM +0800, Abner Chang wrote:

Heinrich Schuchardt <xypron.glpk@...> 於 2021年4月14日 週三 下午9:19寫道：

On 14.04.21 10:19, Abner Chang wrote:

Hi Sunil,
Thanks for initial this.
I would like to suggest limiting the scope of Server Extension

spec for

RISC-V server platform and only list the items which are RISC-V

related.

I think the RISC-V platform spec is aimed at what should be

implemented

on RISC-V platform and also follow the industrial standards. That

says

only define the necessary spec for RISC-V platform-specific H/W

features

is sufficient. Forgive me if I am wrong.

My comments in below,

Sunil V L <sunilvl@...

<mailto:sunilvl@...>>

於 2021年4月12日 週一 下午6:40寫道：

This specifies mandatory requirements for server class

platforms in

addition to the requirements in base specification.

Signed-off-by: Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

Changes in V2:
- Aligned to 80 characters.
- Removed protocols related to graphics support.
- Referred to SMBIOS conformance guidelines.
---
changelog.adoc | 4 +
licensing.adoc | 1 +
riscv-platform-spec.adoc | 187

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

3 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/changelog.adoc b/changelog.adoc
index 466b2ef..b7577be 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -7,6 +7,10 @@
[preface]
## Change Log

+### version 0.3-rc0
+* 2021-04-08:
+** Initial commit of server firmware requirements
+
### version 0.2-rc0
* 2021-03-16:
** Added 2022 platforms
diff --git a/licensing.adoc b/licensing.adoc
index 6a9cdd6..89bd6ee 100644
--- a/licensing.adoc
+++ b/licensing.adoc
@@ -15,6 +15,7 @@ This RISC-V Profile and Platform

Specification

(P2S) is
(C) 2017 Andrew Waterman <andrew@... <mailto:

andrew@...>>

(C) 2020 Al Stone <ahs3@... <mailto:ahs3@...>>
(C) 2021 Kumar Sankaran <ksankaran@...
<mailto:ksankaran@...>>
+(C) 2021 Sunil V L <sunilvl@...
<mailto:sunilvl@...>>

The P2S is licensed under the Creative Commons Attribution

4.0

International
License (CC-BY 4.0). The full license text is available at
diff --git a/riscv-platform-spec.adoc

b/riscv-platform-spec.adoc

index 9d860f8..62009fb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -8,11 +8,13 @@
= RISC-V Platform Specification
:author: RISC-V Platform Specification Task Group
:email: tech-unixplatformspec@...
<mailto:tech-unixplatformspec@...>
-:revnumber: 0.2-rc0
-:revdate: Mar 2021
+:revnumber: 0.3-rc0
+:revdate: Apr 2021
:doctype: book
:sectnums:
+:sectnumlevels: 5
:toc: macro
+:toclevels: 5

// table of contents
toc::[]
@@ -68,14 +70,181 @@ include::profiles.adoc[]

// Server extension for Linux-2022 Platform
=== Server Extension
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+The server extension specifies additional requirements

apart from

base

+requirements for RV64I based server class platforms. Support

for

RV128I

+based platforms will be in future when available.

-==== Runtime services
-* SBI
-* UEFI
+The platforms which conform to server extension must

implement

+
+- Advanced Platform-Level Interrupt Controller (APLIC).

[*Dependency:

+ AIA spec should be ratified*]
+- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec

should be

+ratified*]
+- PCIe.

+
+- RISC-V Hypervisor-level Instruction-Set Extensions.

[*Dependency:

+Spec should be ratified*]

Is this the extension only for the server platform? Could be an
extension for all platforms, right?

+- Incoming MSI Controller (IMSIC) with at least 1 guest

interrupt

+file for each HART ?? (*TBD*)
+- IOMMU with support for memory resident interrupt files ??

(*TBD*)

+
+==== Boot and Runtime Requirements
+===== Firmware
+The boot and system firmware for the RV64I server platforms

must be

+based on UEFI as per the base specification with some

additional

"must be" seems to me a little bit strong. The system firmware

could be

LinuxBoot, uboot, or other solutions which do not have or only

support

the minimum requirements of UEFI protocols
and I think it would be better to change this section from "

Firmware"

to "UEFI Based System Firmware" under Server Extension section.

If you look at the ARM landscape there you have:

EBBR: sub-set of UEFI required, fulfilled by U-Boot
SBBR: more UEFI required, fulfilled by EDK II
LBBR: LinuxBoot required

The RISC-V Linux platform requirements matches EBBR.
My understanding was that this chapter is meant to match SBBR.
Maybe we need an extra chapter on LinuxBoot requirements.

Exactly. If use Linuxboot as the firmware solution (this has been
discussing and investigating for a while although it is not mature

yet) for

the server platform and launched after EDK2 PEI phase, then who cares

about

UEFI?
I suggest we have two sections, one for UEFI based system another is

not.

It is correct that server extension chapter is similar to SBBR.

We are not specifying any implementations here. U-Boot/EDK2/Linuxboot
all are
different types of firmware implementations in my opinion. All we are
mandating here is the set of requirements server class platforms should
have. Why do we need to have separate chapter for Linuxboot?

LinuxBoot is really special. It is not UEFI compliant but uses kexec which cannot boot non-Linux OSes.

One criteria for server spec is to support different OSs including
windows. As per
https://www.phoronix.com/scan.php?page=news_item&px=LinuxBoot-Can-Boot-Windows
Linuxboot booted windows supporting UEFI boot and runtime services
(may be not a perfect implementation yet).

From server platform perspective, any new firmware implementation need

to satisfy the requirements from the OS. I really can't see how
Linuxboot can be so different and introduce whole set of new requirements
on multiple OSs. As per my understanding it is mainly trying to replace
EDK2 DXE phase with well tested Linux drivers. But the environment what
OS like windows will see should be kept intact.

UEFI is the standardized way to start OSes. This is what the Linux EFI
stub uses. Besides this Linux has a legacy entry point which is used by
LinuxBoot to launch another kernel via kexec.

In 2019 there was a proof at concept that LinuxBoot could provide a UEFI
implementation. Was it ever merged?

If we are talking of a compliant UEFI implementation provided by
LinuxBoot, it fits into this chapter. When we talk about booting via
kexec this will have a different set of requirements.

Best regards

Heinrich

+requirements as mentioned below.

+
+====== PCIe support
+PCIe is mandatory for server compliance. Hence,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
+*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and
*EFI_PCI_IO_PROTOCOL*
+must be implemented.

Not sure why we have to mention PCIe here for the server

platform. This

seems to me regardless of RISC-V platform. Other buses such as

CXL or

Gen-Z could be supported as well. This is more like the part of

the

system firmware spec.
If we want to mention this, I would say *if* PCIe devices are

supported

on the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be
installed for the UEFI firmware solution.

We don't have to mention protocol function
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and

EFI_PCI_IO_PROTOCOL,

those should be handled by UEFI implementation, such as the

UEFI/EDK2

PCI BUS driver

+
+====== UEFI configuration tables
+The platform which is complaint with server extension must

provide

following
+tables.
+
+* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is

at

version 6.4+ or
+newer with HW-Reduced ACPI model.

ACPI table is general for all ACPI-aware OS. This seems not

necessary

to be in the scope of RISC-V platform spec,

+* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to

version 3.4

or later.

uboot doesn't have SMBIOS at least for the RISC-V platform.

Devicetree

table UEFI configuration table is needed as well for the
non-SMBIOS-aware OS.

U-Boot creates an SMBIOS table with some information for ARM. This

could

easily be extended to RISC-V.

So we can rephrase this to * *SMBIOS3_TABLE_GUID* SMBIOS table

which

conforms to version 3.4 or later if the platform support

SMBIOS-aware

pre-OS applications and OS.
Also add another similar section for the device tree use case,

which

is EFI_DTB_TABLE_GUID for the platform which supports DT-aware

pre-OS

application or OS.

The device-tree use case is described in the EBBR which is

referenced in

the Linux platform chapter. Why should this be repeated here?

We would like to have a link here to point to ARM EBBR? I don't think

that

is a good idea for RISC-V platform spec.
As I know EFI_DTB_GUID which defined in EBBR will be removed because
EFI_DTB_TABLE_GUID is standardized and pushed to UEFI 2.9 for any
architectures which require DT. SBBR will just use EFI_DTB_TABLE_GUID

as

well because this GUID is proposed by SBBR people. RISC-V should also

use

EFI_DTB_TABLE_GUID instead of using FDT_TABLE_GUID.

I assume EBBR also will get updated in that case. Isn't it?

And the reason to have these configuration tables is either

SMBIOS or DT

carries the information of RISC-V HW features.

The information in SMBIOS and DT is independent.

Yes, those two are independent.

SMBIOS will carry
information that does not exist in the device-tree.

SMBIOS will also carry the information even that exists in DT for the
non-DT-aware OS such as Windows-based system.
The server is able to boot to either Windows or Linux-based OS, these

two

data structures should be mentioned separately.

Regards,
Abner

Best regards

Heinrich

+
+====== UEFI Protocol support
+The UEFI protocols listed below must be implemented in

addition to

the base
+spec requirements.
+
+.Mandatory UEFI Protocols
+[cols="3,1,1", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI 2.9 $ | Note
+|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
+|EFI_DECOMPRESS_PROTOCOL | 19.5 |
+|===
+

What UEFI protocols must be implemented is platform design

specific. We

may have a long list of UEFI protocols for the large system (for

example

if it supports any kind of boot methods). Therefore I don't think

we

need this section.

+===== Boot-Loader
+*TBD*
+
+===== Discovery Mechanisms (ACPI)

First of all, I don't quite understand what exactly the

Discovery

Mechanisms mean? for the hardware feature discovery?

If so, SMBIOS and DeviceTree is also part of this section, not

only ACPI

+For RV64I server platforms, it is mandatory to have ACPI

tables

passed via UEFI
+to the operating system for the purpose of discovery and the
configuration of
+the hardware. This section defines mandatory ACPI tables and
objects. All other
+ACPI tables for RISC-V can be implemented as required

adhering to

the ACPI spec
+version 6.4+(RISC-V support when added).



+
+====== ACPI System Description Tables
+
+
+.Mandatory ACPI tables
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|ACPI Table |ACPI 6.4+

$|Note

+|Root System Description Pointer (RSDP) |5.2.5 |
+|Extended System Description Table (XSDT) |5.2.8 |
+|Fixed ACPI Description Table (FADT) |5.2.9 |
+|Differentiated System Description Table (DSDT)|5.2.11.1 |
+|Multiple APIC Description Table (MADT) |5.2.12

|*TBD*:

Need ECR
+

to add

+

APLIC &

IMSIC
+

(AIA)

to MADT
+|RISC-V Timer Description Table |New

|*TBD*:

_DSD to
+

communicate

+
timebase-frequency?
+|Processor Properties Topology Table (PPTT) |5.2.29
|CPU/Cache topology
+

information

+|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG
|Required for PCIe
+

support

+|Debug Port Table 2 (DBG2) |Microsoft

|*TBD*:

16550D?
+|Serial Port Console Redirection (SPCR) |Microsoft

|*TBD*:

16550D?
+|System Resource Affinity Table (SRAT) |5.2.16
|Required if the
+
platform supports NUMA
+|System Locality Information Table (SLIT) |5.2.17
|Required if the
+
platform supports NUMA
+|IOMMU Information Table |

|*TBD*:

New IOMMU
+

table

need to be
+

defined

(like IVRS)
+|Software Delegated Exception Interface (SDEI) |SDEI

|*TBD*:

New table
+

and SBI

extension
+

also

may be required
+|PMU event mapping table? |New

|*TBD*:

New table
+

required

+|===
+

Most of the above tables are generic and not RISC-V specific for

the

server platform. Perhaps only keep MADT, SDEI, and others which

are

marked as "New". However, I don't know if those "New" tables have

been

discussing in UEFI ASWG or those are just the proposal.


+====== ACPI Namespace
+
+- Processors must be defined under the System Bus (\_SB)

name space.

+- Below list of Device Objects and Methods must be

implemented for

each device
+ definition in the DSDT.
+
+.Mandatory Device Objects and Methods
+[cols="1,2,3", width=95%, align="center", options="header"]
+|===
+|Object/Method | ACPI 6.4+ $ | Note
+|_AEI | 5.6.5.2 | Required for GPIO-signalled

events.

+|_EVT | 5.6.5.3 | Required for

interrupt-signalled

events.

+|_ADR | 6.1.1 | Required for PCI
+|_HID | 6.1.5 |
+|_UID | 6.1.12 |
+|_CRS | 6.2.2 |
+|_CCA | 6.2.17 | Required for DMA capable

devices

+|_STA | 6.3.7/7.2.4 | Device status
+|===

Also, this seems to me not specific to RISC-V platform.

+
+===== Runtime services
+====== SBI
+*TBD*
+
+====== UEFI
+It is mandatory to implement the UEFI run time services

listed

below.

+
+.Mandatory UEFI Runtime Services
+[cols="3,1,3", width=95%, align="center", options="header"]
+|===
+|Service | UEFI 2.9 $ | Note
+|GetVariable | 8.2 |
+|GetNextVariableName | 8.2 |
+|SetVariable | 8.2 | A dedicated

storage for

firmware
+ should be

available so

that there
+ is no conflict in

access

by both
+ firmware and the

OS.

+|QueryVariableInfo | 8.2 |
+|GetTime | 8.3 | RTC Access by the

OS

+|SetTime | 8.3 | If it is not

possible to

set the RTC,
+ the SetTime() can

return

an error.
+|GetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetWakeupTime | 8.3 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|SetVirtualAddressMap | 8.4 |
+|ConvertPointer | 8.4 |
+|GetNextHighMonotonicCount | 8.5 |
+|ResetSystem | 8.5 | If SBI SRST
implementation is also
+ available, the OS

should

not use the
+ SBI interface

directly

but use this
+ UEFI interface.
+|UpdateCapsule | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|QueryCapsuleCapabilities | 8.5 | Interface must be
implemented but it
+ can return

EFI_UNSUPPORTED.

+|===

Not sure if we really need above section.

+
+====== SMBIOS
+The System Management BIOS (SMBIOS) table is mandatory for

the

platform

+complaint to server extension. The SMBIOS table is

identified using

+*SMBIOS3_TABLE_GUID* in UEFI configuration table.
EfiRuntimeServicesData must
+be the memory type used for the SMBIOS table.
+
+In addition to the conformance guidelines as mentioned in

ANNEX A /

6.2 of the
+SMBIOS specification 3.4.0, below additional structures are

mandatory.

+
+.Mandatory SMBIOS structures
+[cols="4,1,2", width=95%, align="center", options="header"]
+|===
+|Structure Type | SMBIOS

3.4.0 $ |

Note

+|Management Controller Host Interface (Type 42) | 7.43

|

*TBD*:
+
Redfish
+
support
+
mandatory?

Not mandatory if no remote management for the system firmware

platform

configurations.

Abner

+|Processor Additional Information (Type 44) | 7.45

|

+|===

==== System Peripherals
* PCI-E
--
2.25.1