In this context, a recipe is a collection of firmware specification requirements that hardware, firmware, and software providers can implement to increase the likelihood that software written to the recipe will run predictably on all conforming devices.
The BRS specification defines three recipes: BRS-I (for "Interoperable"), BRS-B (for "Bespoke") and BRS-M (for "Minimal").
The BRS-I recipe aims to simplify end-user experiences, software compatibility and OS distribution, by defining a common specification for boot and runtime interfaces. BRS-I is expected to be used by general-purpose compute devices such as servers, desktops, laptops and other devices with industry expectations on silicon vendor, OS and software ecosystem interoperability. BRS-I enables operating system providers to build a single generic operating system image that can be successfully booted on compliant systems. Generic means not requiring system-specific customizations - only an implementation of BRS-I requirements. Successfully boot means basic system configuration, sufficient for detecting the need for system-specific drivers and loading such drivers.
It is understood that systems will deliver features beyond those covered by BRS-I. However, software written against a specific version of BRS-I must run, unaltered, without anomalous and unexpected behavior on systems that include such features and that are compliant to that specific version of BRS-I. Such behavior, caused by factors entirely unknown to a generic OS, is hard to diagnose and always results in a terrible user experience that negatively affects the value of the whole RISC-V standards-based ecosystem. Anomalous and unexpected behavior is taken to mean system instability and worst-case behavior for non-specialized workloads, but does not include suboptimal/unoptimized behavior or missing I/O or accelerator drivers.
A key tenet of BRS-I is constraining behavior outside the scope of BRS-I. Features violating the principle of least surprise and causing anomalous and unexpected behavior in a generic OS must be configured by firmware as opt-in. See additional guidance.
| Profile | UEFI | ACPI | DT | SBI | SMBIOS |
|---|---|---|---|---|---|
>= RVA20 |
>= 2.10 |
>= 6.6 |
N/A |
>= 2.0 |
>= 3.7.0 |
BRS-B is intended for cases where only a minimal level of firmware interaction is mandated, focusing primarily on the boot process. The BRS-B recipe is the simpler of the two BRS recipes. It is expected to be used by software that is tailored to specific devices. Examples include many types of mobile devices, devices with real time response requirements, or embedded devices running rich operating systems with custom distributions.
| Profile | UEFI | ACPI | DT | SBI | SMBIOS |
|---|---|---|---|---|---|
>= RVA20 |
EBBR cite:[EBBR] |
optional, >= 6.6 |
optional, >= v0.3 |
>= 2.0 |
optional, >= 3.7.0 |
BRS-M is used for cases that do not require UEFI. BRS-M is the smallest recipe. This recipe does not require UEFI boot and runtime service implementations. In some boot scenarios, non-UEFI firmware can also support boot, they only focus on the boot process and support the necessary interaction interfaces. See additional guidance.
| Profile | ACPI | DT | SBI | SMBIOS |
|---|---|---|---|---|
>= RVA20 |
optional, >= 6.6 |
optional, >= v0.3 |
>= 2.0 |
optional, >= 3.6.0 |