intro.adoc

Introduction

The RISC-V Boot and Runtime Services Specification (BRS) defines a standardized set of software capabilities, that portable system software, such as operating systems and hypervisors, can rely on being present in an implementation to utilize in acts of device discovery, OS boot and hand-off, system management, and other operations.

The BRS specification is targeting systems that implement S/U privilege modes, and optionally the HS privilege mode. This is the expected deployment for OSVs and system vendors in a typical ecosystem covering client systems up through server systems where software is provided by different vendors than the system vendor.

This specification standardizes the requires for software interfaces and capabilities by building on top of relevant industry and ratified RISC-V standards.

Releases

It is expected that the BRS will periodically release a new specification. The determination of a new release will be based on the evaluation of significant changes to its underlying dependencies.

Approach to Solutions

The BRS focuses on two solutions in the form of what is deemed a recipe. Each recipe contains the requirements needed to fulfill each solution. The requirements of each recipe will be marked accordingly with an unique identifier. The recipes are BRS-I (Interoperable) and BRS-B (Bespoke).

Testing and Conformance

To be compliant with this specification, an implementation MUST support all mandatory requirements and MUST support the listed versions of the specifications. This standard set of capabilities MAY be extended by a specific implemenation with additional standard on custom capabilities, including compatible later versions of listed standard specifications. Portable system software MUST support the specified mandatory capabilities to the compliant with this specification.

The requirements in this specification use the following format:

ID#	Rule
CAT_NNN	The CAT is a category prefix that logically groups the requirements and is followed by 3 digits - NNN - assigning a numeric ID to the requirement. The requirements use the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" that are to be interpreted as described in RFC 2119 cite:[RFC_2119] when, and only when, they appear in all capitals, as shown here. When these words are not capitalized, they have their normal English meanings.
A requirement or a group of requirements may be followed by non-normative text providing context or justification for the requirement. The non-normative text may also be used to reference sources that are the origin of the requirement.

Glossary

Most terminology has the standard RISC-V meaning. This table captures other terms used in the document. Terms in the document prefixed by PCIe have the meaning defined in the PCI Express Base Specification cite:[PCI] (even if they are not in this table).

Table 1. Terms and definitions

Term	Definition
ACPI	Advanced Configuration and Power Interface Specification cite:[ACPI].
BRS	RISC-V Boot and Runtime Services Specification. This document.
BRS-I	Boot and Runtime Services recipe targeting interoperation across different software suppliers.
BRS-B	Boot and Runtime Services recipe using a bespoke solution.
DT	DeviceTree cite:[DT].
EBBR	Embedded Base Boot Requirements Specification cite:[EBBR].
OSV	Operating System Vendor.
OS	Operating System or Hypervisor.
Profile	RISC-V Profile cite:[Profile].
RVI	RISC-V International.
SBI	RISC-V Supervisor Binary Interface Specification cite:[SBI].
SMBIOS	System Management BIOS (SMBIOS) Reference Specification cite:[SMBIOS].
SoC	System on a chip, a combination of processor and supporting chipset logic in single package.
UEFI	Unified Extensible Firmware Interface Specification cite:[UEFI].