My reviews are inline below which is apart from the below recommendations if you don't think that is better.
We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me.
Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to
EBBR in Embede2022. Is this clear than the current layout of spec?
For example,
+===== Firmware
....
Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms
- EFI_SYSTEM_TABLE
- EFI_BOOT_SERVICES
- EFI_ RUNTIME_SERVICES
- Required EFI protocols for the base specification.
- Required EFI protocols for the platform.
Refer to Embedded2022 for the detailed implementations of the above requirements.
Refer to Server2022 for the detailed implementations of the above requirements.
In Embedded2022 section, put links to refer to EBBR.
In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support.
This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform.
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes
can be done tailored for RISC-V.
This is the main patch, there are minor changes in the contributors file
and the changelog which are not relevant for now so I am not sending those.
Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 125 ++++++++++++++++++++++++++++++++++++---
1 file changed, 118 insertions(+), 7 deletions(-)
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 5d3b9c3..601fb61 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,36 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform
+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|link:[Platform Policy] | TBD
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +87,95 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers
-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the
+operating system suitable for the RISC-V platforms with rich operating
+systems.
+- These requirements specifies the required boot and runtime services, device
+discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader
+implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements
+from the RVA22 profile must be implemented.
+- The base runtime specification depends on the RISC-V SBI specification and
+all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply
+with the base specification. Hypervisor Extension is optional.
+_**Will be defined in this spec if the RVA22 spec does not mention it.**_
+- For the generic mandatory requirements this base specification will refer to
+the EBBR Specification. Any deviation from the EBBR will be explicitly
+mentioned in the requirements.
+- Specifications followed are mentioned in the
+<<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform
+Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions,
+ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI
+specification.
+- For compliance with base specification platform must implement
+link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements],
+link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements]
+and support the following
+link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image.
+- Firmware must implement the support for GPT Partitioning and meet the
+requirements as per the
+link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR.
Can we add the below sentence,
Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3.
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions
+marked as EFI_BOOT_SERVICES.
+
+====== Startup Protocol
+- UEFI firmware could be executed in either Machine mode or Supervisor mode
+during the entire POST, according to the hart capability and the platform
+design. For firmware privilege mode requirements, mode switch and the handover
+of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
+- Before yielding control to S-Mode stage, firmware must configure the M-Mode
+state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements
+for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements]
+to comply with this base specification. Also refer Devicetree tables section
+in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI
+specification.
Could we add something regarding to SMBIOS?
"If platform requires SMBIOS on UEFI system, the SMBIOS table must be installed to EFI Configuration Table according to 4.6 EFI Configuration Table & Properties Table of UEFI
specification."
Abner
-==== Runtime services
-* SBI
-* UEFI
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the
+RISC-V SBI Specification.
+- Wherever applicable firmware must implement UEFI interfaces over similar
+interfaces and services present in the SBI specification. For example, UEFI
+runtime services must implement ResetSystem() via SBI Reset extension.
+- Legacy Extensions from the SBI Specification are deprecated and must not be
+implemented.
+
+====== UEFI
+- Firmware must conform to the
+link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for
+link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings]
+to avoid conflict between the firmware and OS when accessing the mapped
+devices.
+- Compliant UEFI runtime environment must meet the requirements for the
+link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements
+link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface]
+if RTC is present in the system.
// Server extension for Linux-2022 Platform
=== Server Extension
--
2.25.1
