On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@...> wrote:
> My reviews are inline below which is apart from the below recommendations if you don't think that is better.
> We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me.
> Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to EBBR in Embede2022. Is this clear than the current layout of spec?
Linux2022 name is going to change and its just a placeholder for now.
The platform specs builds upon the ISA level profiles A and M.
Linux2022 corresponds to A profile (RVA2022) where we are asking
RV32/64 with M,S,U modes and H as optional. UEFI as the firmware
interface is only considered for the Linux2022(Base + Server).
Embedded2022 is a separate set of requirements which are dependent on
the RVM22 ISA profile.
We may make more changes later once the these profiles specs RVA22 and
RVM22 will be available and it will clear things.
Does this provides clarity?
Ok. I have no problem with this.
Just argue that many links to EBBR which create the dependecies with these two specs. That makes sense to me if that UEFI section is separated from EBBR as the commonality spec for the platform that just requires the minimum UEFI implementation. Any changes made to that
spec has to be agreed by the adopters. Just my thought...thanks for clarifying this,
> For example,
> +===== Firmware
> +- For compliance with base specification platform must implement
> +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements],
> Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms
> - EFI_SYSTEM_TABLE
> - EFI_BOOT_SERVICES
> - EFI_ RUNTIME_SERVICES
> - Required EFI protocols for the base specification.
> - Required EFI protocols for the platform.
> Refer to Embedded2022 for the detailed implementations of the above requirements.
> Refer to Server2022 for the detailed implementations of the above requirements.
> In Embedded2022 section, put links to refer to EBBR.
> In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support.
> This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform.
Embedded2022 spec is different from Linux2022 and it considers
different league of RISC-V implementation which will be clear when
RVM22 will be out.
UEFI is only considered for Linux2022 (Base + Server). Though base
sets the guidelines for the minimum requirements for compliance only.
There is no separate Server2022, Server is an extension under Linux2022.
> Rahul Pathak <rpathak@...> 於 2021年4月20日 週二 下午8:23寫道：
>> Initial changes for the Base Boot & Runtime requirements.
>> The sections which are currently in-progress are marked as TBD.
>> These changes can serve as the starting point and more details/changes
>> can be done tailored for RISC-V.
>> This is the main patch, there are minor changes in the contributors file
>> and the changelog which are not relevant for now so I am not sending those.
>> Signed-off-by: Rahul Pathak <rpathak@...>
>> riscv-platform-spec.adoc | 125 ++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 118 insertions(+), 7 deletions(-)
>> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>> index 5d3b9c3..601fb61 100644
>> --- a/riscv-platform-spec.adoc
>> +++ b/riscv-platform-spec.adoc
>> @@ -32,6 +32,36 @@ include::profiles.adoc
>> // Linux-2022 Platform
>> == Linux-2022 Platform
>> +=== Terminology
>> +[cols="1,2", width=80%, align="left", options="header"]
>> +|TERM | DESCRIPTION
>> +|SBI | Supervisor Binary Interface
>> +|UEFI | Unified Extensible Firmware Interface
>> +|ACPI | Advanced Configuration and Power Interface
>> +|SMBIOS | System Management Basic I/O System
>> +|DTS | Devicetree source file
>> +|DTB | Devicetree binary
>> +|RVA22 | RISC-V Application 2022
>> +|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
>> +|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
>> +=== Specifications
>> +[cols="1,2", width=80%, align="left", options="header"]
>> +|SPECIFICATION | VERSION
>> +|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
>> +|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
>> +|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
>> +|link:[RVA22 Specification] | TBD
>> +|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
>> +|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
>> +|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
>> +|link:[Platform Policy] | TBD
>> // Base feature set for Linux-2022 Platform
>> === Base
>> ==== Architecture
>> @@ -57,14 +87,95 @@ include::profiles.adoc
>> * Timers
>> * Watchdog Timers
>> -==== Boot Process
>> -* Firmware
>> -* Boot-Loader
>> -* Discovery Mechanisms
>> +==== Boot and Runtime Requirements
>> +- The base specification defines the interface between the firmware and the
>> +operating system suitable for the RISC-V platforms with rich operating
>> +- 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
>> +- For compliance with base specification platform must implement
>> +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements],
>> +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements]
>> +and support the following
>> +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
>> +====== Block Device Partition Format
> Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image.
Sure, will change this.
>> +- Firmware must implement the support for GPT Partitioning and meet the
>> +requirements as per the
>> +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
> This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR.
> Can we add the below sentence,
> Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3.
Sure, will add this.
>> +===== Boot Services
>> +- Base specification compliant firmware must implement all UEFI functions
>> +marked as EFI_BOOT_SERVICES.
>> +====== Startup Protocol
>> +- UEFI firmware could be executed in either Machine mode or Supervisor mode
>> +during the entire POST, according to the hart capability and the platform
>> +design. For firmware privilege mode requirements, mode switch and the handover
>> +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms.
>> +- Before yielding control to S-Mode stage, firmware must configure the M-Mode
>> +state. Refer the RISC-V SBI specification for details.
>> +- If the Hypervisor Extension is implemented. **TBD**.
>> +====== Memory Map
>> +- UEFI environment must provide a system memory map and meet the requirements
>> +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
>> +===== Boot-Loader
>> +===== 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
> 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
The initial guidelines set for the Base (Linux2022) spec was to have
the Devicetree and its mandatory for base compliance. SMBIOS is
considered for the server extension.
Ok, this makes sense as for the Base
Is there any instance where both DT and SMBIOS exists together on ARM?
I don't think we have that on the ARM non-server system. However, UEFI edk2 RISC-V port has both (not the full set of SMBIOS records yet) to support both scenarios from the unified firmware image.
>> -==== 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
>> +====== 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
>> +- 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