-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Rahul Pathak
Sent: 24 April 2021 07:41
To: Atish Patra <Atish.Patra@...>
Cc: tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and
runtime requirements - initial commit
On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> wrote:
On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more
details/changes can be done tailored for RISC-V.
This is the main patch, there are minor changes in the contributors
file and the changelog which are not relevant for now so I am not
sending those.
Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 125
++++++++++++++++++++++++++++++++++++-
--
1 file changed, 118 insertions(+), 7 deletions(-)
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform
== Linux-2022 Platform
+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as
RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as
RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p
df[UEFI
Specification] | v2.9
+|link:
https://github.com/devicetree-org/devicetree-specification/releases/
tag/v0.3[Devicetree
Specification] | v0.3
+|link:
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI
Specification] | v0.3-rc0
+|link:[RVA22
Specification]
| TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification]
| v2.0.0-pre1
+|link:
https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC
PI
Specification] | v6.4
+|link:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3
.4.0.pdf[SMBIOS
Specification] | v3.4.0
+|link:[Platform
Policy]
| TBD
+|===
+
// Base feature set for Linux-2022 Platform === Base ====
Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware
and the
+operating system suitable for the RISC-V platforms with rich
operating
+systems.
+- These requirements specifies the required boot and runtime
services, device
+discovery mechanism, etc.
+- The requirements are operating system agnostic, specific
firmware/bootloader
+implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all
requirements
+from the RVA22 profile must be implemented.
+- The base runtime specification depends on the RISC-V SBI
specification and
+all requirements from the SBI spec must be implemented.
This statement is bit ambiguous given that individual SBI section says
legacy ones must not be implemented.
Ok, What I thought while mentioning this that, if SBI spec mentions that
Legacy interfaces should not be implemented" then this statement is also a
requirement just "to not implement".
But I think lets change the wording to this - "SBI Specification compliance is
must for conformation with the Base Specification"
BTW I have explicitly mentioned to not implement Legacy Extension from SBI
in the Runtime Section below
+- Any RV32GC or RV64GC system with Machine, Supervisor and User
+Mode
can comply
+with the base specification.
Should we reword something like this,
Any platform seeking compliance with the base specification, must
implement all three privilege modes i.e. M/S/U mode.
Should we not mandate the minimum ISA required to support the rich os.
Hypervisor Extension is optional.
Do we need to state this explicitly? I am just trying see if we can
avoid any statements with optional word as per previous discussions.
Any platform implementing M/S/U complies with base. If they implement
H extension on top of that but not aimed for server extension
compliance, they are still compliant with base specification.
Agree
+_**Will be defined in this spec if the RVA22 spec does not mention
it.**_
+- For the generic mandatory requirements this base specification
will refer to
+the EBBR Specification. Any deviation from the EBBR will be
explicitly
+mentioned in the requirements.
Just for clarification, RISC-V specific content in EBBR is not merged
yet. The last version of the patch can be found here.
https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg015
45.html
I will try to revise/rebase it on the latest EBBR specification.
Sure, actually for the above argument on H extension, we should mention
what would be the privilege level if H extension is implemented because.
If this patch gets into the EBBR, we can just point to that then.
I will connect with you to change this before sending the next version of the
patch.
It does not matter whether H-extension is implemented or not.
The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or
VS-mode).
The VS-mode is same as S-mode whereas HS-mode is S-mode with
additional hypervisor capabilities.
+- Specifications followed are mentioned in the
+<<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY
refer
Platform
+Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling
conventions,
+ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V
Platforms of UEFI
+specification.
+- For compliance with base specification platform must implement
+link:https://arm-software.github.io/ebbr/#required-elements[EBBR -
UEFI Required Elements],
+link:
https://arm-software.github.io/ebbr/#required-platform-specific-elem
ents[EBBR
- UEFI Platform Specific Elements]
+and support the following
+link:
https://arm-software.github.io/ebbr/#required-global-variables[EBBR
- Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet
the
+requirements as per the
+link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR
+Firm
ware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI
functions
+marked as EFI_BOOT_SERVICES.
+
Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can
reworded similar to what EBBR has done.
All functions defined as boot services must exist. Methods for
unsupported or unimplemented behavior must return an appropriate error
code.
Agree
+====== Startup Protocol
+- UEFI firmware could be executed in either Machine mode or
Supervisor mode
+during the entire POST, according to the hart capability and the
platform
+design. For firmware privilege mode requirements, mode switch and
the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- Before yielding control to S-Mode stage, firmware must configure
the M-Mode
+state. Refer the RISC-V SBI specification for details.
Are we talking about only CSR configuration or all other implmentation
expectations from M-mode such as interrupt/exception delegation,
misaligned/missing CSR emulation, PMP configuration ?
All which an SEE should do, Do we need to really define what it has to do?
Is that what you are asking
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the
requirements
+for link:https://arm-software.github.io/ebbr/#memory-map[EBBR -
Memory Map].
+
In addition to this, should we standardize a start address (i.e.
0x80000000)
We should discuss this
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system
description.
+- System must meet link:
https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree
requirements]
+to comply with this base specification. Also refer Devicetree
+tables
section
+in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI
+specification.
-==== Runtime services
-* SBI
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified
by the
+RISC-V SBI Specification.
I think we can just mandate SBI v0.3. The base specification may not
have to implement all the SBI extensions in future.
But then shall we not revise the base spec and mention what not to
implement from SBI spec here, Just like EBBR makes some things deprecated
and optional from UEFI and other specs?
We cannot have just one blindly point to SBI specification. All SBI extensions
are defined as optional but certain SBI extensions become mandatory if hardware
lacks capabilities.
Here are few examples,
1) If "stimecmp" CSRs are available then SBI TIME extension is optional
otherwise SBI TIME extension is mandatory
2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not have
AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory
3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI RFENCE
extension is mandatory
The BASE profile should "stimecmp" CSR and AIA iMSIC is optional whereas
these HW features will be mandatory for SERVER profile.
List of BASE profile SBI extensions:
1) SBI spec version should be at least 0.3
2) SBI TIME extension is mandatory if "stimecmp" CSR not available
3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT
4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT
5) SBI HSM extension is mandatory
6) SBI SRST extension is mandatory
7) SBI PMU extension is mandatory
The above list gets simplified for SERVER profile assuming "stimecmp" and
AIA IMSIC are mandatory for SERVER profile. Here's the list:
1) SBI spec version should be at least 0.3
2) SBI HSM extension is mandatory
3) SBI SRST extension is mandatory
4) SBI PMU extension is mandatory
Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER
profile for older kernels (and other OSes or hypervisors)
To summarize, the mandatory set of SBI extensions is decided by the
underlying HW features.
+- Wherever applicable firmware must implement UEFI interfaces over
similar
+interfaces and services present in the SBI specification. For
example, UEFI
+runtime services must implement ResetSystem() via SBI Reset
extension.
+- Legacy Extensions from the SBI Specification are deprecated and
must not be
+implemented.
+
+====== UEFI
+- Firmware must conform to the
+link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB
+R
- UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for
+link:
https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR -
Runtime Device Mappings]
+to avoid conflict between the firmware and OS when accessing the
mapped
+devices.
+- Compliant UEFI runtime environment must meet the requirements for
the
+link:
https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR -
Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock
+requirements
+link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR
+-
UEFI RTC interface]
+if RTC is present in the system.
// Server extension for Linux-2022 Platform === Server Extension
--
Regards,
Atish
Regards,
Anup
