[PATCH v4 6/6] Follow profile naming as-per latest RISC-V profiles spec


Anup Patel
 

We should follow profile naming as-per latest RISC-V profiles
specification. Also, we should avoid explicit mentions of
"RV32xxx" and "RV64xxx" ISA strings.

Signed-off-by: Anup Patel <anup.patel@...>
---
riscv-platform-spec.adoc | 37 ++++++++++++++++---------------------
1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index e4a8bdc..f5ba29c 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -35,8 +35,9 @@ toc::[]
|RVA22 | RISC-V Application 2022 <<spec_profiles>>
|EE | Execution Environment
|OSPM | Operating System Power Management
-|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
-|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|RVA22U64 | RISC-V 2022 user-mode profile <<spec_profiles>>
+|RVA22S64 | RISC-V 2022 supervisor-mode profile <<spec_profiles>>
+|RVA22M64 | RISC-V 2022 machine-mode profile <<spec_profiles>>
|RAS | Reliability, Availability, and Serviceability
|CLINT | Legacy Core-Local Interrupt Controller
|ACLINT | Advanced Core-Local Interrupt Controller <<spec_aclint>>
@@ -97,7 +98,8 @@ The M platform has the following extensions:
=== Base
==== Architecture
* ISA Requirements
-** The OS-A platform is required to comply with the RVA22 profile <<spec_profiles>>.
+** The OS-A platform harts are required to comply with the RVA22U64 and
+ RVA22S64 profiles <<spec_profiles>>.
** Within main-memory regions, aligned instruction fetch must be atomic, up to
the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
is stored with the `sw` instruction, then any processor attempts to execute
@@ -428,9 +430,6 @@ systems.
discovery mechanism, etc.
- The requirements are operating system agnostic, specific firmware/bootloader
implementation agnostic.
-- Any RV32GC or RV64GC platform seeking compatibility with the base
-specification is required to implement all three privilege modes i.e. M, S and
-U mode.
- For the generic mandatory requirements this base specification will refer to
the EBBR Specification. Any deviation from the EBBR will be explicitly
mentioned in the requirements.
@@ -478,14 +477,13 @@ mentioned in the requirements.

// Server extension for OS-A Platform
=== Server Extension
-The server extension specifies additional requirements for RV64I based server
-class platforms. The server extension includes all of the requirements for the
+The server extension specifies additional requirements for server class
+platforms. The server extension includes all of the requirements for the
base with the additional requirements as below.

==== Architecture
The platforms which conform to server extension are required to implement +

-* RV64 support
* The `time` CSR must be implemented in hardware
* The Sstc extension <<spec_priv_sstc>> must be implemented
* RISC-V ISA H-extension with following additional requirements:
@@ -545,9 +543,9 @@ additional requirements:

==== Boot and Runtime Requirements
===== Firmware
-The boot and system firmware for the RV64I server platforms required to be
-based on UEFI as per the base specification with some additional
-requirements as mentioned below.
+The boot and system firmware for the server platforms must support UEFI as
+defined in by the OS-A base platform with some additional requirements
+described in following sub-setions.

====== PCIe support
The platforms are required to implement *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* and other
@@ -576,10 +574,10 @@ the base spec requirements.

====== ACPI

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

In ACPI namespace, processors are required to be defined under the System Bus
@@ -963,11 +961,8 @@ although they do not have to in order to meet the specification.

=== Base
==== Architecture
-The M Platform specification depends on the RVM22 specification and all
-requirements from RVM22 must be met.
-
-Any RISC-V system that uses at least RV32/64G can meet the M Platform
-specification.
+The M Platform harts must comply with the RVM22M64 profile specification
+<<spec_profiles>>.

==== Interrupt Controller
Embedded systems are recommended to use a spec compliant PLIC <<spec_plic>>,
--
2.25.1


Alistair Francis
 

On Sat, 2021-08-07 at 11:43 +0530, Anup Patel wrote:
We should follow profile naming as-per latest RISC-V profiles
specification. Also, we should avoid explicit mentions of
"RV32xxx" and "RV64xxx" ISA strings.

Signed-off-by: Anup Patel <anup.patel@...>
---
 riscv-platform-spec.adoc | 37 ++++++++++++++++---------------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index e4a8bdc..f5ba29c 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -35,8 +35,9 @@ toc::[]
 |RVA22     | RISC-V Application 2022 <<spec_profiles>>
 |EE        | Execution Environment
 |OSPM      | Operating System Power Management
-|RV32GC    | RISC-V 32-bit general purpose ISA described as
RV32IMAFDC.
-|RV64GC    | RISC-V 64-bit general purpose ISA described as
RV64IMAFDC.
+|RVA22U64  | RISC-V 2022 user-mode profile <<spec_profiles>>
+|RVA22S64  | RISC-V 2022 supervisor-mode profile <<spec_profiles>>
+|RVA22M64  | RISC-V 2022 machine-mode profile <<spec_profiles>>
Why do these have 64 at the end?

Alistair

 |RAS       | Reliability, Availability, and Serviceability
 |CLINT     | Legacy Core-Local Interrupt Controller
 |ACLINT    | Advanced Core-Local Interrupt Controller
<<spec_aclint>>
@@ -97,7 +98,8 @@ The M platform has the following extensions:
 === Base
 ==== Architecture
 * ISA Requirements
-** The OS-A platform is required to comply with the RVA22 profile
<<spec_profiles>>.
+** The OS-A platform harts are required to comply with the RVA22U64
and
+   RVA22S64 profiles <<spec_profiles>>.
 ** Within main-memory regions, aligned instruction fetch must be
atomic, up to
   the smaller of ILEN and XLEN bits. In particular, if an aligned 4-
byte word
   is stored with the `sw` instruction, then any processor attempts
to execute
@@ -428,9 +430,6 @@ systems.
 discovery mechanism, etc.
 - The requirements are operating system agnostic, specific
firmware/bootloader
 implementation agnostic.
-- Any RV32GC or RV64GC platform seeking compatibility with the base
-specification is required to implement all three privilege modes
i.e. M, S and
-U mode.
 - For the generic mandatory requirements this base specification
will refer to
 the EBBR Specification. Any deviation from the EBBR will be
explicitly
 mentioned in the requirements.
@@ -478,14 +477,13 @@ mentioned in the requirements.
 
 // Server extension for OS-A Platform
 === Server Extension
-The server extension specifies additional requirements for RV64I
based server
-class platforms. The server extension includes all of the
requirements for the
+The server extension specifies additional requirements for server 
class
+platforms. The server extension includes all of the requirements for
the
 base with the additional requirements as below.
 
 ==== Architecture
 The platforms which conform to server extension are required to
implement +
 
-* RV64 support
 * The `time` CSR must be implemented in hardware
 * The Sstc extension <<spec_priv_sstc>> must be implemented
 * RISC-V ISA H-extension with following additional requirements:
@@ -545,9 +543,9 @@ additional requirements:
 
 ==== Boot and Runtime Requirements
 =====  Firmware
-The boot and system firmware for the RV64I server platforms required
to be
-based on UEFI as per the base specification with some additional
-requirements as mentioned below.
+The boot and system firmware for the server platforms must support
UEFI as
+defined in by the OS-A base platform with some additional
requirements
+described in following sub-setions.
 
 ====== PCIe support
 The platforms are required to implement
*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* and other
@@ -576,10 +574,10 @@ the base spec requirements.
 
 ====== ACPI
 
-For RV64I server platforms, ACPI tables are required to be passed
via UEFI
-to the operating system for the purpose of discovery and the
configuration of
-the hardware. This section defines the required ACPI tables and
objects. All
-other ACPI tables for RISC-V can be implemented as needed adhering
to the ACPI
+For server platforms, ACPI tables are required to be passed via UEFI
to the
+operating system for the purpose of discovery and the configuration
of the
+hardware. This section defines the required ACPI tables and objects.
All other
+ACPI tables for RISC-V can be implemented as needed adhering to the
ACPI
 spec version 6.4+(RISC-V support when added).
 
 In ACPI namespace, processors are required to be defined under the
System Bus
@@ -963,11 +961,8 @@ although they do not have to in order to meet
the specification.
 
 === Base
 ==== Architecture
-The M Platform specification depends on the RVM22 specification and
all
-requirements from RVM22 must be met.
-
-Any RISC-V system that uses at least RV32/64G can meet the M
Platform
-specification.
+The M Platform harts must comply with the RVM22M64 profile
specification
+<<spec_profiles>>.
 
 ==== Interrupt Controller
 Embedded systems are recommended to use a spec compliant PLIC
<<spec_plic>>,


atishp@...
 

On Sun, 2021-08-08 at 23:36 +0000, Alistair Francis wrote:
On Sat, 2021-08-07 at 11:43 +0530, Anup Patel wrote:
We should follow profile naming as-per latest RISC-V profiles
specification. Also, we should avoid explicit mentions of
"RV32xxx" and "RV64xxx" ISA strings.

Signed-off-by: Anup Patel <anup.patel@...>
---
 riscv-platform-spec.adoc | 37 ++++++++++++++++--------------------
-
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index e4a8bdc..f5ba29c 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -35,8 +35,9 @@ toc::[]
 |RVA22     | RISC-V Application 2022 <<spec_profiles>>
 |EE        | Execution Environment
 |OSPM      | Operating System Power Management
-|RV32GC    | RISC-V 32-bit general purpose ISA described as
RV32IMAFDC.
-|RV64GC    | RISC-V 64-bit general purpose ISA described as
RV64IMAFDC.
+|RVA22U64  | RISC-V 2022 user-mode profile <<spec_profiles>>
+|RVA22S64  | RISC-V 2022 supervisor-mode profile <<spec_profiles>>
+|RVA22M64  | RISC-V 2022 machine-mode profile <<spec_profiles>>
Why do these have 64 at the end?
Here are more details on profile naming convention
https://github.com/riscv/riscv-profiles/blob/master/profiles.adoc

However, the current draft profile spec doesn't event mention about
these terms (RVA22x64).

Should we defer this patch until we have something in the profile spec
?

I am afraid that we have to make changes again if the naming convention
is changed in the profile spec later.



Alistair

 |RAS       | Reliability, Availability, and Serviceability
 |CLINT     | Legacy Core-Local Interrupt Controller
 |ACLINT    | Advanced Core-Local Interrupt Controller
<<spec_aclint>>
@@ -97,7 +98,8 @@ The M platform has the following extensions:
 === Base
 ==== Architecture
 * ISA Requirements
-** The OS-A platform is required to comply with the RVA22 profile
<<spec_profiles>>.
+** The OS-A platform harts are required to comply with the RVA22U64
and
+   RVA22S64 profiles <<spec_profiles>>.
 ** Within main-memory regions, aligned instruction fetch must be
atomic, up to
   the smaller of ILEN and XLEN bits. In particular, if an aligned 4-
byte word
   is stored with the `sw` instruction, then any processor attempts
to execute
@@ -428,9 +430,6 @@ systems.
 discovery mechanism, etc.
 - The requirements are operating system agnostic, specific
firmware/bootloader
 implementation agnostic.
-- Any RV32GC or RV64GC platform seeking compatibility with the base
-specification is required to implement all three privilege modes
i.e. M, S and
-U mode.
 - For the generic mandatory requirements this base specification
will refer to
 the EBBR Specification. Any deviation from the EBBR will be
explicitly
 mentioned in the requirements.
@@ -478,14 +477,13 @@ mentioned in the requirements.
 
 // Server extension for OS-A Platform
 === Server Extension
-The server extension specifies additional requirements for RV64I
based server
-class platforms. The server extension includes all of the
requirements for the
+The server extension specifies additional requirements for server 
class
+platforms. The server extension includes all of the requirements for
the
 base with the additional requirements as below.
 
 ==== Architecture
 The platforms which conform to server extension are required to
implement +
 
-* RV64 support
 * The `time` CSR must be implemented in hardware
 * The Sstc extension <<spec_priv_sstc>> must be implemented
 * RISC-V ISA H-extension with following additional requirements:
@@ -545,9 +543,9 @@ additional requirements:
 
 ==== Boot and Runtime Requirements
 =====  Firmware
-The boot and system firmware for the RV64I server platforms required
to be
-based on UEFI as per the base specification with some additional
-requirements as mentioned below.
+The boot and system firmware for the server platforms must support
UEFI as
+defined in by the OS-A base platform with some additional
requirements
+described in following sub-setions.
 
 ====== PCIe support
 The platforms are required to implement
*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* and other
@@ -576,10 +574,10 @@ the base spec requirements.
 
 ====== ACPI
 
-For RV64I server platforms, ACPI tables are required to be passed
via UEFI
-to the operating system for the purpose of discovery and the
configuration of
-the hardware. This section defines the required ACPI tables and
objects. All
-other ACPI tables for RISC-V can be implemented as needed adhering
to the ACPI
+For server platforms, ACPI tables are required to be passed via UEFI
to the
+operating system for the purpose of discovery and the configuration
of the
+hardware. This section defines the required ACPI tables and objects.
All other
+ACPI tables for RISC-V can be implemented as needed adhering to the
ACPI
 spec version 6.4+(RISC-V support when added).
 
 In ACPI namespace, processors are required to be defined under the
System Bus
@@ -963,11 +961,8 @@ although they do not have to in order to meet
the specification.
 
 === Base
 ==== Architecture
-The M Platform specification depends on the RVM22 specification and
all
-requirements from RVM22 must be met.
-
-Any RISC-V system that uses at least RV32/64G can meet the M
Platform
-specification.
+The M Platform harts must comply with the RVM22M64 profile
specification
+<<spec_profiles>>.
 
 ==== Interrupt Controller
 Embedded systems are recommended to use a spec compliant PLIC
<<spec_plic>>,
--
Regards,
Atish


Greg Favor
 

On Mon, Aug 9, 2021 at 11:41 AM Atish Patra <atish.patra@...> wrote:
> Why do these have 64 at the end?

Here are more details on profile naming convention
https://github.com/riscv/riscv-profiles/blob/master/profiles.adoc

Should we defer this patch until we have something in the profile spec
?  I am afraid that we have to make changes again if the naming convention
is changed in the profile spec later.

The above adoc is very tentative and hasn't been reviewed at all.  Even Krste would acknowledge that the naming details will change.

So whatever we use in the platform specs is just a placeholder that almost for certain will need to be updated to match whatever final naming ends up in the profile specs.

To the extent that we, for now, match Krste's initial thought (as expressed in the adoc), the platform spec would actually use 'RVA22U' and 'RVA22S' since the adoc specifies that the default for RVA profiles is RV64 and a '32' suffix is needed only in the non-default RV32 case.  (This is the opposite default from what is specified for the RVM profiles.)

So I would suggest we go with these 'RVA22U' and 'RVA22S' names for now and allow for a final change later this year.  Even for public review (if Krste hasn't updated his initial naming thoughts), this naming should suffice.

Greg


Anup Patel
 

On 09/08/21, 5:06 AM, "Alistair Francis" <Alistair.Francis@...> wrote:

On Sat, 2021-08-07 at 11:43 +0530, Anup Patel wrote:
> We should follow profile naming as-per latest RISC-V profiles
> specification. Also, we should avoid explicit mentions of
> "RV32xxx" and "RV64xxx" ISA strings.
>
> Signed-off-by: Anup Patel <anup.patel@...>
> ---
> riscv-platform-spec.adoc | 37 ++++++++++++++++---------------------
> 1 file changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index e4a8bdc..f5ba29c 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -35,8 +35,9 @@ toc::[]
> |RVA22 | RISC-V Application 2022 <<spec_profiles>>
> |EE | Execution Environment
> |OSPM | Operating System Power Management
> -|RV32GC | RISC-V 32-bit general purpose ISA described as
> RV32IMAFDC.
> -|RV64GC | RISC-V 64-bit general purpose ISA described as
> RV64IMAFDC.
> +|RVA22U64 | RISC-V 2022 user-mode profile <<spec_profiles>>
> +|RVA22S64 | RISC-V 2022 supervisor-mode profile <<spec_profiles>>
> +|RVA22M64 | RISC-V 2022 machine-mode profile <<spec_profiles>>

Why do these have 64 at the end?

The "64" at the end means RV64.

Regards,
Anup

Alistair

> |RAS | Reliability, Availability, and Serviceability
> |CLINT | Legacy Core-Local Interrupt Controller
> |ACLINT | Advanced Core-Local Interrupt Controller
> <<spec_aclint>>
> @@ -97,7 +98,8 @@ The M platform has the following extensions:
> === Base
> ==== Architecture
> * ISA Requirements
> -** The OS-A platform is required to comply with the RVA22 profile
> <<spec_profiles>>.
> +** The OS-A platform harts are required to comply with the RVA22U64
> and
> + RVA22S64 profiles <<spec_profiles>>.
> ** Within main-memory regions, aligned instruction fetch must be
> atomic, up to
> the smaller of ILEN and XLEN bits. In particular, if an aligned 4-
> byte word
> is stored with the `sw` instruction, then any processor attempts
> to execute
> @@ -428,9 +430,6 @@ systems.
> discovery mechanism, etc.
> - The requirements are operating system agnostic, specific
> firmware/bootloader
> implementation agnostic.
> -- Any RV32GC or RV64GC platform seeking compatibility with the base
> -specification is required to implement all three privilege modes
> i.e. M, S and
> -U mode.
> - For the generic mandatory requirements this base specification
> will refer to
> the EBBR Specification. Any deviation from the EBBR will be
> explicitly
> mentioned in the requirements.
> @@ -478,14 +477,13 @@ mentioned in the requirements.
>
> // Server extension for OS-A Platform
> === Server Extension
> -The server extension specifies additional requirements for RV64I
> based server
> -class platforms. The server extension includes all of the
> requirements for the
> +The server extension specifies additional requirements for server
> class
> +platforms. The server extension includes all of the requirements for
> the
> base with the additional requirements as below.
>
> ==== Architecture
> The platforms which conform to server extension are required to
> implement +
>
> -* RV64 support
> * The `time` CSR must be implemented in hardware
> * The Sstc extension <<spec_priv_sstc>> must be implemented
> * RISC-V ISA H-extension with following additional requirements:
> @@ -545,9 +543,9 @@ additional requirements:
>
> ==== Boot and Runtime Requirements
> ===== Firmware
> -The boot and system firmware for the RV64I server platforms required
> to be
> -based on UEFI as per the base specification with some additional
> -requirements as mentioned below.
> +The boot and system firmware for the server platforms must support
> UEFI as
> +defined in by the OS-A base platform with some additional
> requirements
> +described in following sub-setions.
>
> ====== PCIe support
> The platforms are required to implement
> *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* and other
> @@ -576,10 +574,10 @@ the base spec requirements.
>
> ====== ACPI
>
> -For RV64I server platforms, ACPI tables are required to be passed
> via UEFI
> -to the operating system for the purpose of discovery and the
> configuration of
> -the hardware. This section defines the required ACPI tables and
> objects. All
> -other ACPI tables for RISC-V can be implemented as needed adhering
> to the ACPI
> +For server platforms, ACPI tables are required to be passed via UEFI
> to the
> +operating system for the purpose of discovery and the configuration
> of the
> +hardware. This section defines the required ACPI tables and objects.
> All other
> +ACPI tables for RISC-V can be implemented as needed adhering to the
> ACPI
> spec version 6.4+(RISC-V support when added).
>
> In ACPI namespace, processors are required to be defined under the
> System Bus
> @@ -963,11 +961,8 @@ although they do not have to in order to meet
> the specification.
>
> === Base
> ==== Architecture
> -The M Platform specification depends on the RVM22 specification and
> all
> -requirements from RVM22 must be met.
> -
> -Any RISC-V system that uses at least RV32/64G can meet the M
> Platform
> -specification.
> +The M Platform harts must comply with the RVM22M64 profile
> specification
> +<<spec_profiles>>.
>
> ==== Interrupt Controller
> Embedded systems are recommended to use a spec compliant PLIC
> <<spec_plic>>,


Anup Patel
 

On 10/08/21, 12:11 AM, "Atish Patra" <Atish.Patra@...> wrote:

On Sun, 2021-08-08 at 23:36 +0000, Alistair Francis wrote:
> On Sat, 2021-08-07 at 11:43 +0530, Anup Patel wrote:
> > We should follow profile naming as-per latest RISC-V profiles
> > specification. Also, we should avoid explicit mentions of
> > "RV32xxx" and "RV64xxx" ISA strings.
> >
> > Signed-off-by: Anup Patel <anup.patel@...>
> > ---
> > riscv-platform-spec.adoc | 37 ++++++++++++++++--------------------
> > -
> > 1 file changed, 16 insertions(+), 21 deletions(-)
> >
> > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > index e4a8bdc..f5ba29c 100644
> > --- a/riscv-platform-spec.adoc
> > +++ b/riscv-platform-spec.adoc
> > @@ -35,8 +35,9 @@ toc::[]
> > |RVA22 | RISC-V Application 2022 <<spec_profiles>>
> > |EE | Execution Environment
> > |OSPM | Operating System Power Management
> > -|RV32GC | RISC-V 32-bit general purpose ISA described as
> > RV32IMAFDC.
> > -|RV64GC | RISC-V 64-bit general purpose ISA described as
> > RV64IMAFDC.
> > +|RVA22U64 | RISC-V 2022 user-mode profile <<spec_profiles>>
> > +|RVA22S64 | RISC-V 2022 supervisor-mode profile <<spec_profiles>>
> > +|RVA22M64 | RISC-V 2022 machine-mode profile <<spec_profiles>>
>
> Why do these have 64 at the end?

Here are more details on profile naming convention
https://github.com/riscv/riscv-profiles/blob/master/profiles.adoc

However, the current draft profile spec doesn't event mention about
these terms (RVA22x64).

Should we defer this patch until we have something in the profile spec
?

I am afraid that we have to make changes again if the naming convention
is changed in the profile spec later.

Yes, I added it to have something aligned with current naming followed
by draft profile spec. I am sure we will have to keep changing it until
profile spec is in decent shape.

Regards,
Anup

>
> Alistair
>
> > |RAS | Reliability, Availability, and Serviceability
> > |CLINT | Legacy Core-Local Interrupt Controller
> > |ACLINT | Advanced Core-Local Interrupt Controller
> > <<spec_aclint>>
> > @@ -97,7 +98,8 @@ The M platform has the following extensions:
> > === Base
> > ==== Architecture
> > * ISA Requirements
> > -** The OS-A platform is required to comply with the RVA22 profile
> > <<spec_profiles>>.
> > +** The OS-A platform harts are required to comply with the RVA22U64
> > and
> > + RVA22S64 profiles <<spec_profiles>>.
> > ** Within main-memory regions, aligned instruction fetch must be
> > atomic, up to
> > the smaller of ILEN and XLEN bits. In particular, if an aligned 4-
> > byte word
> > is stored with the `sw` instruction, then any processor attempts
> > to execute
> > @@ -428,9 +430,6 @@ systems.
> > discovery mechanism, etc.
> > - The requirements are operating system agnostic, specific
> > firmware/bootloader
> > implementation agnostic.
> > -- Any RV32GC or RV64GC platform seeking compatibility with the base
> > -specification is required to implement all three privilege modes
> > i.e. M, S and
> > -U mode.
> > - For the generic mandatory requirements this base specification
> > will refer to
> > the EBBR Specification. Any deviation from the EBBR will be
> > explicitly
> > mentioned in the requirements.
> > @@ -478,14 +477,13 @@ mentioned in the requirements.
> >
> > // Server extension for OS-A Platform
> > === Server Extension
> > -The server extension specifies additional requirements for RV64I
> > based server
> > -class platforms. The server extension includes all of the
> > requirements for the
> > +The server extension specifies additional requirements for server
> > class
> > +platforms. The server extension includes all of the requirements for
> > the
> > base with the additional requirements as below.
> >
> > ==== Architecture
> > The platforms which conform to server extension are required to
> > implement +
> >
> > -* RV64 support
> > * The `time` CSR must be implemented in hardware
> > * The Sstc extension <<spec_priv_sstc>> must be implemented
> > * RISC-V ISA H-extension with following additional requirements:
> > @@ -545,9 +543,9 @@ additional requirements:
> >
> > ==== Boot and Runtime Requirements
> > ===== Firmware
> > -The boot and system firmware for the RV64I server platforms required
> > to be
> > -based on UEFI as per the base specification with some additional
> > -requirements as mentioned below.
> > +The boot and system firmware for the server platforms must support
> > UEFI as
> > +defined in by the OS-A base platform with some additional
> > requirements
> > +described in following sub-setions.
> >
> > ====== PCIe support
> > The platforms are required to implement
> > *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* and other
> > @@ -576,10 +574,10 @@ the base spec requirements.
> >
> > ====== ACPI
> >
> > -For RV64I server platforms, ACPI tables are required to be passed
> > via UEFI
> > -to the operating system for the purpose of discovery and the
> > configuration of
> > -the hardware. This section defines the required ACPI tables and
> > objects. All
> > -other ACPI tables for RISC-V can be implemented as needed adhering
> > to the ACPI
> > +For server platforms, ACPI tables are required to be passed via UEFI
> > to the
> > +operating system for the purpose of discovery and the configuration
> > of the
> > +hardware. This section defines the required ACPI tables and objects.
> > All other
> > +ACPI tables for RISC-V can be implemented as needed adhering to the
> > ACPI
> > spec version 6.4+(RISC-V support when added).
> >
> > In ACPI namespace, processors are required to be defined under the
> > System Bus
> > @@ -963,11 +961,8 @@ although they do not have to in order to meet
> > the specification.
> >
> > === Base
> > ==== Architecture
> > -The M Platform specification depends on the RVM22 specification and
> > all
> > -requirements from RVM22 must be met.
> > -
> > -Any RISC-V system that uses at least RV32/64G can meet the M
> > Platform
> > -specification.
> > +The M Platform harts must comply with the RVM22M64 profile
> > specification
> > +<<spec_profiles>>.
> >
> > ==== Interrupt Controller
> > Embedded systems are recommended to use a spec compliant PLIC
> > <<spec_plic>>,
>

--
Regards,
Atish