On Wed, 2021-04-21 at 14:38 +0800, Abner 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.

I think the confusion is valid because of the current naming scheme
which is just a place holder. Just to clarify the embedded2022 is meant
for microcontroller type of hardware where some RTOS or baremetal
programs are expected to run.

The Linux 2022(a generic name will be adopted) platform is the the one
that is meant for rich operating systems like Linux/FreeBSD/Windows.
The expected hardware platform ranges from small dev boards(beagleV) to
servers.


> 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?
>

The base specification contains the minimum set similar to EBBR. Thus,
FPGA platforms/dev boards can claim compliance to it. The server
extension will introduce additional features on top of the base so that
server platforms can comply with it.

> 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.
>
>
> 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
> > +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

--
Regards,
Atish