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

This statement is bit ambiguous given that individual SBI section says
legacy ones must not be implemented.


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

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

> +_**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@.../msg01545.html

I will try to revise/rebase it on the latest EBBR specification.

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


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

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


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

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