From aa7e3664f435c0a51f99b775dd338576a1168e62 Mon Sep 17 00:00:00 2001 From: Andrei Warkentin Date: Mon, 15 Apr 2024 19:45:38 -0500 Subject: [PATCH] Prettify. The point of this is to easily visually parse the spec. Use `` for identifiers (code identifiers, structure fields, register names, requirements within the spec) Use __ for spec names, chapter/section names (e.g. when referenced) Use ** for emphasis. Names of stuff (Processor Properties Table, UEFI, ACPI) are left as-is. Signed-off-by: Andrei Warkentin --- acpi-id.adoc | 18 ++++----- acpi-prop.adoc | 4 +- acpi.adoc | 58 ++++++++++++++--------------- hart.adoc | 2 +- intro.adoc | 26 ++++++------- non-normative/acpi.adoc | 37 +++++++++---------- non-normative/smbios.adoc | 2 +- non-normative/uefi.adoc | 12 +++--- recipes.adoc | 2 +- sbi.adoc | 14 +++---- smbios.adoc | 64 ++++++++++++++++---------------- uefi.adoc | 78 +++++++++++++++++++-------------------- 12 files changed, 157 insertions(+), 160 deletions(-) diff --git a/acpi-id.adoc b/acpi-id.adoc index 825abc1..5cda486 100644 --- a/acpi-id.adoc +++ b/acpi-id.adoc @@ -1,19 +1,19 @@ [[acpi-ids]] === RVI-specific ACPI IDs -ACPI ID is used in the _HID (Hardware ID), _CID (Compatibility ID) or -_SUB (Subsystem ID) objects as described in the ACPI Specification for +ACPI ID is used in the `_HID` (Hardware ID), `_CID` (Compatibility ID) or +`_SUB` (Subsystem ID) objects as described in the ACPI Specification for devices, that do not have a standard enumeration mechanism. The ACPI ID -consists of two parts: a Vendor ID followed by a product identifier. +consists of two parts: a vendor identifier followed by a product identifier. Vendor IDs consist of 4 characters, each character being either an -uppercase letter (A-Z) or a numeral (0-9). The Vendor ID SHOULD be +uppercase letter (A-Z) or a numeral (0-9). The vendor ID SHOULD be unique across the Industry and registered by the UEFI forum. For RVI -standard devices, `RSCV` is the Vendor ID registered. Vendor-specific -devices can use an appropriate Vendor ID registered for the manufacturer. +standard devices, `RSCV` is the vendor ID registered. Vendor-specific +devices can use an appropriate vendor ID registered for the manufacturer. -Product Identifiers are always four-character hexadecimal numbers (0-9 -and A-F). The Device Manufacturer is responsible for assigning this +Product IDs are always four-character hexadecimal numbers (0-9 +and A-F). The device manufacturer is responsible for assigning this identifier to each product model. This document contains the canonical list of ACPI IDs for the namespace @@ -27,6 +27,6 @@ ACPI ID for any new device. | ACPI ID ^| Device | `RSCV0001` | RISC-V Platform-Level Interrupt Controller (PLIC) | `RSCV0002` | RISC-V Advanced Platform-Level Interrupt Controller (APLIC) -| `RSCV0003` | NS16550-compatible UART compatible with a Type 0x12 SPCR definition +| `RSCV0003` | NS16650 UART compatible with an SPCR definition using `Interface Type` 0x12 2+| _Also see <>._ |=== diff --git a/acpi-prop.adoc b/acpi-prop.adoc index 6bc3e5c..ceffbca 100644 --- a/acpi-prop.adoc +++ b/acpi-prop.adoc @@ -1,7 +1,7 @@ [[acpi-props]] === RVI-specific ACPI Device Properties -This section defines the _DSD device properties cite:[DSD] in the `rscv-` namespace. +This section defines the `_DSD` device properties cite:[DSD] in the `rscv-` namespace. Where explicit values are provided in a property definition, only these values must be used. System behavior with any other values is undefined. @@ -20,6 +20,6 @@ to configure a disabled device._ | `reg-shift` | Integer | Quantity to shift the register offsets by. | `reg-io-width` | Integer | The size (in bytes) of the register accesses that should be performed on the device. 3+| _1, 2, 4 or 8._ -| `rx-fifo-size` | Integer | The RX FIFO size (in bytes). +| `rx-fifo-size` | Integer | The receive FIFO size (in bytes). |=== diff --git a/acpi.adoc b/acpi.adoc index c0ca341..dfbe3aa 100644 --- a/acpi.adoc +++ b/acpi.adoc @@ -1,12 +1,12 @@ [[acpi]] == BRS-I ACPI Requirements -The Advanced Configuration and Power Interface specification provides the OS-centric view of system configuration, various hardware resources, events and power management. +The _Advanced Configuration and Power Interface Specification_ provides the OS-centric view of system configuration, various hardware resources, events and power management. This section defines the BRS-I mandatory and optional ACPI requirements on top of existing cite:[ACPI] and cite:[UEFI] specification requirements. Additional non-normative guidance may be -found in the <> +found in the <> section. IMPORTANT: All content in this section is optional and recommended for BRS-B. @@ -15,27 +15,27 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. [%header, cols="5,25"] |=== | ID# ^| Requirement -| [[acpi-64bit-clean]]ACPI_010 a| Be 64-bits clean. +| [[acpi-64bit-clean]]`ACPI_010` a| Be 64-bits clean. - * RSDT MUST NOT be implemented, with RsdtAddress in RSDP set to 0. + * RSDT MUST NOT be implemented, with `RsdtAddress` in RSDP set to 0. * 32-bit address fields MUST be 0. 2+| _<>._ -| [[acpi-hw-reduced]]ACPI_020 a| Implement the HW-Reduced ACPI Mode (no FACS table). +| [[acpi-hw-reduced]]`ACPI_020` a| Implement the hardware-reduced ACPI mode (no FACS table). 2+| _<>._ -| [[acpi-pptt]]ACPI_030 | The Processor Properties Table (PPTT) MUST be implemented, even on systems with a simple hart topology. -| [[acpi-mcfg]]ACPI_040 | The PCI Memory-mapped Configuration Space (MCFG) table MUST NOT be present if it violates cite:[PCIFW]. +| [[acpi-pptt]]`ACPI_030` | The Processor Properties Table (PPTT) MUST be implemented, even on systems with a simple hart topology. +| [[acpi-mcfg]]`ACPI_040` | The PCI Memory-mapped Configuration Space (MCFG) table MUST NOT be present if it violates cite:[PCIFW]. 2+| _Only compatible PCIe segments, exposed via ECAM (Enhanced Configuration Access Mechanism), may be described in the MCFG. The MCFG MUST NOT require vendor-specific OS support. See PCI Services (cite:[ACPI], Section 4) for more ACPI requirements relating to PCIe support. <>._ -| ACPI_050 | A Serial Port Console Redirection Table cite:[SPCR] MUST be present on systems, where the graphics hardware is not present or not made -available to an OS loader via the standard UEFI EFI_GRAPHICS_OUTPUT_PROTOCOL interface. +| `ACPI_050` | A Serial Port Console Redirection Table cite:[SPCR] MUST be present on systems, where the graphics hardware is not present or not made +available to an OS loader via the standard `UEFI EFI_GRAPHICS_OUTPUT_PROTOCOL` interface. 2+|_In these cases, the table provides essential configuration for an early OS boot console._ -| [[acpi-spcr]]ACPI_060 a| An SPCR table, if present, MUST meet the following requirements: +| [[acpi-spcr]]`ACPI_060` a| An SPCR table, if present, MUST meet the following requirements: * Revision 4 or later of SPCR. * For NS16550-compatible UARTs: - ** Use Interface Type 0x12 (16550-compatible with parameters defined in Generic Address Structure). + ** Use `Interface Type` 0x12 (16550-compatible with parameters defined in Generic Address Structure). ** There MUST be a matching AML device object with compatible ID `RSCV0003`. 2+| _See <>_. -| [[acpi-namespace-dev]]ACPI_080 | Depending on the interrupt controller +| [[acpi-namespace-dev]]`ACPI_080` | Depending on the interrupt controller implemented by the system, PLIC or APLIC namespace devices MUST be present in the ACPI namespace along with MADT entries. <>. @@ -54,35 +54,35 @@ objects. [%header, cols="5,25"] |=== | ID# ^| Requirement -| AML_010 | The Cache Coherency Attribute (_CCA) device method MUST be implemented. +| `AML_010` | The Cache Coherency Attribute (`_CCA`) device method MUST be implemented. 2+| _This object provides information about whether a device has to manage cache coherency and about hardware support. This object is mandatory for all devices that can access CPU-visible memory. (cite:[ACPI] Section 6.2.17)._ -| AML_020 | The Current Resource Setting (_CRS) device method for a PCIe Root Complex SHOULD NOT contain resources of type DWordIO, QWordIO or ExtendedIO. -2+| _Legacy PCI I/O BARs are uncommon in modern PCIe devices and support for PCI I/O space may complicate configuration of PCIe RC hardware in a compliant manner._ -| AML_030 | The Possible Resource Settings (_PRS) and Set Resource Settings (_SRS) device method SHOULD NOT be implemented. -2+| _ACPI resource descriptors are typically used to describe devices with fixed CSR regions that do not change. Flexible resource assignment is not supported by most modern ACPI OSes._ -| AML_040 | Per-hart device objects MUST be defined under \_SB (System Bus) namespace and not in the deprecated \_PR (Processors) namespace. -| AML_050 | Systems supporting OS-directed hart performance control and power management MUST expose these via Collaborative Processor Performance Control (CPPC, cite:[ACPI] Section 8.4.6). -| AML_060 | Processor idle states MUST be described using Low Power Idle (LPI, cite:[ACPI] Section 8.4.3). -| [[acpi-tad]] AML_070 | Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST implement the Time and Alarm Device (TAD). -2+| _Also see <>_. -| AML_080 | Systems implementing a TAD MUST be functional without additional system-specific OS drivers. +| `AML_020` | The Current Resource Setting (`_CRS`) device method for a PCIe Root Complex SHOULD NOT contain resources of type `DWordIO`, `QWordIO` or `ExtendedIO`. +2+| _Legacy PCI I/O BARs are uncommon in modern PCIe devices and support for PCI I/O space may complicate configuration of PCIe Root Complex hardware in a compliant manner._ +| `AML_030` | The Possible Resource Settings (`_PRS`) and Set Resource Settings (`_SRS`) device method SHOULD NOT be implemented. +2+| _ACPI resource descriptors are typically used to describe devices with fixed I/O regions that do not change. Flexible resource assignment is not supported by most modern ACPI OSes._ +| `AML_040` | Per-hart device objects MUST be defined under `\_SB` (System Bus) namespace and not in the deprecated `\_PR` (Processors) namespace. +| `AML_050` | Systems supporting OS-directed hart performance control and power management MUST expose these via Collaborative Processor Performance Control (CPPC, cite:[ACPI] Section 8.4.6). +| `AML_060` | Processor idle states MUST be described using Low Power Idle (`_LPI`, cite:[ACPI] Section 8.4.3). +| [[acpi-tad]] `AML_070` | Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST implement the Time and Alarm Device (TAD). +2+| _Also see <>_. +| `AML_080` | Systems implementing a TAD MUST be functional without additional system-specific OS drivers. 2+| _In situations where the Time and Alarm Device (TAD) depends on a vendor-specific OS driver for correct function (SPI, I2C, etc), the TAD MUST be functional if the OS driver is not loaded. That is, when a dependent driver is loaded, an AML method switches further accesses to go -through the driver-backed OperationRegion._ -| [[acpi-irq-gsb]] AML_090 | PLIC and APLIC device objects MUST support -the Global System Interrupt Base (_GSB, cite:[ACPI] Section 6.2.7) object. +through the driver-backed `OperationRegion`._ +| [[acpi-irq-gsb]] `AML_090` | PLIC and APLIC device objects MUST support +the Global System Interrupt Base (`_GSB`, cite:[ACPI] Section 6.2.7) object. <>. -| [[acpi-irq-dep]] AML_100 | Devices with Global System +| [[acpi-irq-dep]] `AML_100` | Devices with Global System Interrupt (GSI, aka wired interrupt) resources MUST indicate the dependency on the corresponding -interrupt controller using Operation Region Dependencies (_DEP, +interrupt controller using Operation Region Dependencies (`_DEP`, cite:[ACPI] Section 6.5.8). <>. -| AML_110 | UART device objects with ID `RSCV0003` MUST implement <>. +| `AML_110` | UART device objects with ID `RSCV0003` MUST implement <>. |=== include::acpi-id.adoc[] diff --git a/hart.adoc b/hart.adoc index 1c7367b..aab7b59 100644 --- a/hart.adoc +++ b/hart.adoc @@ -9,7 +9,7 @@ The BRS specification is minimally prescriptive on the RISC-V hart requirements. [%header, cols="5,25"] |=== | ID# ^| Requirement -| HR_010 | The RISC-V application processor harts MUST be compliant to RVA20S64 Profile cite:[Profile]. +| `HR_010` | The RISC-V application processor harts MUST be compliant to `RVA20S64` profile cite:[Profile]. 2+| _The BRS governs the interactions between 64-bit OS supervisor-mode software and 64-bit firmware. These are minimum requirements allowing for the wide variety of existing and future hart implementations to be supported. It is expected that operating systems and hypervisors may impose additional profile/ISA requirements, depending on the use-case and application._ |=== diff --git a/intro.adoc b/intro.adoc index e6cd204..a87c9bf 100644 --- a/intro.adoc +++ b/intro.adoc @@ -1,7 +1,7 @@ [[intro]] == Introduction -The Boot and Runtime Services (BRS) specification 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 _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. @@ -9,11 +9,11 @@ This specification standardizes the requires for software interfaces and capabil === Releases -It is expected that the Boot and Runtime Services specification 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. +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 Boot and Runtime Services specification 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 recipe names are named BRS-I and BRS-B, Interoperable and Bespoke, respectively. +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 @@ -25,7 +25,7 @@ The requirements in this specification use the following format: [%header, cols="5,20"] |=== | ID# ^| Requirement -| CAT_NNN | The `CAT` is a category prefix that logically groups the +| `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. + + @@ -44,25 +44,25 @@ The requirements in this specification use the following format: === 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 (PCIe) Base Specification cite:[PCI] (even if they are not in this table). +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). .Terms and definitions [width=90%] [%header, cols="5,20"] |=== | Term ^| Definition -| ACPI | Advanced Configuration and Power Interface Specification cite:[ACPI]. -| BRS | RISC-V Boot and Runtime Services. 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. +| 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]. +| EBBR | _Embedded Base Boot Requirements Specification_ cite:[EBBR]. | OSV | Operating System Vendor. | OS | Operating System or Hypervisor. | Profile | RISC-V Profile cite:[Profile]. -| SBI | RISC-V Supervisor Binary Interface Specification cite:[SBI]. -| SMBIOS | System Management BIOS cite:[SMBIOS]. +| 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. | System | A system is the entirety of a computing entity, including all hardware, firmware and software (hypervisor, operating system, user applications, user data). A system can be thought of both as a logical construct (e.g. a software stack) or physical construct (e.g. a notebook, a desktop, a server, a network switch, etc). -| UEFI | Unified Extensible Firmware Interface Specification cite:[UEFI]. +| UEFI | _Unified Extensible Firmware Interface Specification_ cite:[UEFI]. |=== diff --git a/non-normative/acpi.adoc b/non-normative/acpi.adoc index 1f30282..b1fc866 100644 --- a/non-normative/acpi.adoc +++ b/non-normative/acpi.adoc @@ -1,9 +1,9 @@ ACPI information is structured as tables with the address of the root of these tables known as Root System Description Table (RSDP) passed to the OS -via a EFI_ACPI_20_TABLE_GUID configuration table in the UEFI firmware. +via a `EFI_ACPI_20_TABLE_GUID` configuration table in the UEFI firmware. The Operating System uses this address to locate all other ACPI tables. -Certain implementations may make use of the RISC-V Functional Fixed hardware Specification cite:[FFH]. +Certain implementations may make use of the _RISC-V Functional Fixed Hardware Specification_ cite:[FFH]. [[acpi-guidance-64bit-clean]] ==== 64-bits Clean @@ -19,7 +19,7 @@ located in any part of the physical address space. [[acpi-guidance-hw-reduced]] ==== Hardware-Reduced ACPI -Compliant RISC-V systems only implement the HW-Reduced ACPI Model cite:[ACPI] (Section 4.1). +Compliant RISC-V systems only implement the hardware-reduced ACPI model cite:[ACPI] (Section 4.1). This means the hardware portion of cite:[ACPI] (Section 4) is not required or supported. All functionality is instead provided through equivalent software-defined interfaces and the complexity in supporting ACPI is reduced. @@ -40,12 +40,12 @@ implemented. |ACPI Table |ACPI Section|Note |Root System Description Pointer (RSDP) |5.2.5 | See <>. |Extended System Description Table (XSDT) |5.2.8 | Contains pointers to other tables. -|Fixed ACPI Description Table (FADT) |5.2.9 | See <>, <> and <>. +|Fixed ACPI Description Table (FADT) |5.2.9 | See <>, <> and <>. |Differentiated System Description Table (DSDT)|5.2.11.1 | See <> and <>. |Multiple APIC Description Table (MADT) |5.2.12 | See <> |RISC-V Hart Capabilities Table (RHCT) |New | Communicates information about certain capabilities like ISA string, cache and MMU info. -|Processor Properties Topology Table (PPTT) |5.2.29 | See <> +|Processor Properties Topology Table (PPTT) |5.2.29 | See <> |=== // Add RIMT for IOMMU here. @@ -55,9 +55,9 @@ information about certain capabilities like ISA string, cache and MMU info. [cols="3,2,2", width=95%, align="center", options="header"] |=== |ACPI Table |ACPI Section |Note -|Memory-mapped Configuration space (MCFG) |cite:[PCIFW] |See <> and <> +|Memory-mapped Configuration space (MCFG) |cite:[PCIFW] |See <> and <> |Secondary System Description Table (SSDT) |5.2.11.2 |See <> and <>. -|Serial Port Console Redirection (SPCR) |cite:[SPCR] |See <> and <> +|Serial Port Console Redirection (SPCR) |cite:[SPCR] |See <> and <> |ACPI Table for TPM 2.0 (TPM2) |cite:[TcgAcpi]|If the system supports TPM 2.0 |System Resource Affinity Table (SRAT) |5.2.16 |If the system supports NUMA |System Locality Information Table (SLIT) |5.2.17 |If the system supports NUMA @@ -107,8 +107,8 @@ describe affinities. [[acpi-guidance-gsi-namespace]] ==== PLIC/APLIC Namespace Devices -Here's an example of an ASL excerpt satisfying <>, -<> and <> requirements. +Here's an example of an ASL excerpt satisfying <>, +<> and <> requirements. Scope (\_SB) { @@ -141,15 +141,14 @@ Here's an example of an ASL excerpt satisfying <>, [[acpi-guidance-pcie]] ==== PCIe -On some architectures, it became an industry accepted norm to describe PCIe implementations not compliant to the PCI Firmware Specification cite:[PCIFW] +On some architectures, it became an industry accepted norm to describe PCIe implementations not compliant to the _PCI Firmware Specification_ cite:[PCIFW] using specification-defined ACPI tables and objects. RISC-V systems compliant to the BRS must only expose ECAM-compatible implementations using the -MCFG and the standard AML Hardware ID (HID) PNP0A08 and Compatible ID (CID) PNP0A03, and must not rely on ACPI table header information or other out-of-band -means of detecting quirked behavior. +MCFG and the standard AML Hardware ID (`_HID`) `PNP0A08` and Compatible ID (`_CID`) `PNP0A03`, and must not rely on ACPI table header information or other out-of-band means of detecting quirked behavior. Some minor incompatibilities, such as incorrect CFG0 filtering, broken BARs/capabilities for RCs, embedded switches/bridges or embedded endpoints can be handled by emulating ECAM accesses in privileged firmware (e.g. M-mode) or similar facilities (e.g. a hypervisor). -Non-compliant implementations must be exposed using vendor-specific mechanisms (e.g. AML object with custom HID, custom vendor-specific ACPI table if necessary). +Non-compliant implementations must be exposed using vendor-specific mechanisms (e.g. AML object with custom `_HID`, custom vendor-specific ACPI table if necessary). In cases where such PCIe implementations are only used to expose a fixed non-removable device (e.g. USB host controller or NVMe), the device could be exposed via a DSDT/SSDT MMIO device object without making the OS aware of the underlying PCIe connection. @@ -158,13 +157,13 @@ a DSDT/SSDT MMIO device object without making the OS aware of the underlying PCI [[acpi-guidance-spcr]] ==== SPCR -Early serial console can be implemented using either an NS16550 UART (SPCR Interface Type 0x12) or -SBI console (SPCR Interface Type 0x15). When SPCR describes SBI console, the OS must use -the SBI Probe extension (FID #3) to detect the appropriate facilities, e.g. the Debug Console Extension -(DBCN) or the deprecated legacy console EIDs. +Early serial console can be implemented using either an NS16550 UART (SPCR `Interface Type` 0x12) or +SBI console (SPCR `Interface Type` 0x15). When SPCR describes SBI console, the OS must use +the SBI Probe extension (`FID #3`) to detect the appropriate facilities, e.g. the Debug Console Extension +(`DBCN`) or the deprecated legacy console EIDs. -The new Precise Baud Rate field, introduced in cite:[SPCR] rev. 4, allows describing rates faster +The new `Precise Baud Rate` field, introduced in cite:[SPCR] rev. 4, allows describing rates faster than 115200 baud for NS16550-compatible UARTS. Hardware not capable of interrupt-driven operation and SBI console should be described with -Interrupt Type 0 and Global System Interrupt 0. +`Interrupt Type` of 0 and `Global System Interrupt` of 0. diff --git a/non-normative/smbios.adoc b/non-normative/smbios.adoc index a83aeac..a344002 100644 --- a/non-normative/smbios.adoc +++ b/non-normative/smbios.adoc @@ -2,4 +2,4 @@ Note the DMTF requirements on the 64-bit SMBIOS 3.0 entry point (cite:[SMBIOS] S ==== Type 44 Processor-Specific Data -The Machine Vendor ID, Machine Architecture ID, and Machine Implementation ID fields typically reflect the mvendorid, marchid and mimpid CSRs respectively. +The `Machine Vendor ID`, `Machine Architecture ID`, and `Machine Implementation ID` fields typically reflect the `mvendorid`, `marchid` and `mimpid` CSRs respectively. diff --git a/non-normative/uefi.adoc b/non-normative/uefi.adoc index e01f191..8fd052d 100644 --- a/non-normative/uefi.adoc +++ b/non-normative/uefi.adoc @@ -17,19 +17,19 @@ drivers and applications. [[uefi-guidance-firmware-update]] ==== Firmware Update -UpdateCapsule() is only required before ExitBootServices() is called. -The UpdateCapsule() implementation is expected to be suitable for use by generic firmware update services like fwupd and Windows Update. Both fwupd and Windows Update read the ESRT table to determine what firmware can be updated and use an EFI helper application to call UpdateCapsule() before ExitBootServices() is called. +`UpdateCapsule()` is only required before `ExitBootServices()` is called. +The `UpdateCapsule()` implementation is expected to be suitable for use by generic firmware update services like fwupd and Windows Update. Both fwupd and Windows Update read the ESRT table to determine what firmware can be updated and use an EFI helper application to call `UpdateCapsule()` before `ExitBootServices()` is called. [[uefi-guidance-pcie]] ==== PCIe -Every implementation of the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL provides the -correct Address Translation Offset field to translate between the hart +Every implementation of the `EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL` provides the +correct `Address Translation Offset` field to translate between the hart MMIO and bus addresses. -EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION structures report resources +`EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION` structures report resources produced by the PCIe root bridges, not resources consumed by their register maps. In the cases where there are unpopulated PCIe slots -behind a root bridge, EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION +behind a root bridge, `EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION` reports valid resources assigned (e.g. for hot plug), or reports no resources assigned. diff --git a/recipes.adoc b/recipes.adoc index 88d30c7..0cb3b97 100644 --- a/recipes.adoc +++ b/recipes.adoc @@ -67,4 +67,4 @@ custom distributions. | >= RVA20 | EBBR, >= 2.1.0 cite:[EBBR] | optional, >= 6.6 | optional, >= v0.3 | >= 2.0 | optional, >= 3.7.0 |=== -Either of ACPI table or device-tree must be supplied. +Either of ACPI table or Device Tree must be supplied, but never both at the same time. diff --git a/sbi.adoc b/sbi.adoc index 7471f22..34cc576 100644 --- a/sbi.adoc +++ b/sbi.adoc @@ -1,7 +1,7 @@ [[sbi]] == SBI Requirements -The supervisor binary interface (SBI) cite: [SBI] specification defines the interface +The _RISC-V Supervisor Binary Interface Specification_ (SBI) cite: [SBI] defines the interface between the supervisor mode and the next higher privilege mode. This section defines the mandatory SBI version and extensions implemented by the higher privilege mode in order to be compatible with this specification. @@ -10,8 +10,8 @@ privilege mode in order to be compatible with this specification. [%header, cols="5,25"] |=== | ID# ^| Requirement -| SBI_010 | The SBI implementation MUST conform to SBI v2.0 or later. -| SBI_020 | The SBI implementation MUST implement the Hart State Management (HSM) extension. +| `SBI_010` | The SBI implementation MUST conform to SBI v2.0 or later. +| `SBI_020` | The SBI implementation MUST implement the Hart State Management (HSM) extension. 2+| _HSM is used by an OS for starting up, stopping, suspending and querying the status of secondary harts._ |=== @@ -21,9 +21,9 @@ Certain requirements are conditional on the presence of RISC-V ISA extensions or [%header, cols="5,25"] |=== | ID# ^| Requirement -| SBI_030 | The Timer (TIME) extension MUST be implemented, if the RISC-V "stimecmp / vstimecmp" Extension (Sstc) cite: [Sstc] is not available. -| SBI_040 | The S-Mode IPI (IPI) extension MUST be implemented, if the Incoming MSI Controller (IMSIC) cite: [Aia] is not available. -| SBI_050 | The RFENCE (RFNC) extension MUST be implemented, if the Incoming MSI Controller (IMSIC) cite: [Aia] is not available. -| SBI_060 | The Performance Monitoring (PMU) extension MUST be implemented, if the counter delegation-related ISA extensions (S*csrind cite: [Sscsrind], Smcdeleg cite: [Smcdeleg], Ssccfg cite: [Smcdeleg]) are not present. +| `SBI_030` | The Timer Extension (TIME) MUST be implemented, if the RISC-V "stimecmp / vstimecmp" Extension (Sstc) cite: [Sstc] is not available. +| `SBI_040` | The S-Mode IPI Extension MUST be implemented, if the Incoming MSI Controller (IMSIC) cite: [Aia] is not available. +| `SBI_050` | The RFENCE Extension (RFNC, cite: [SBI]) extension MUST be implemented, if the Incoming MSI Controller (IMSIC) cite: [Aia] is not available. +| `SBI_060` | The Performance Monitoring Extension (PMU) MUST be implemented, if the counter delegation-related ISA extensions (S*csrind cite: [Sscsrind], Smcdeleg cite: [Smcdeleg], Ssccfg cite: [Smcdeleg]) are not present. 2+| _NOTE: The PMU extension is currently being developed by the performance analysis TG cite: [PerfAnalysis]._ |=== diff --git a/smbios.adoc b/smbios.adoc index 135530e..8f68d4a 100644 --- a/smbios.adoc +++ b/smbios.adoc @@ -1,40 +1,39 @@ [[smbios]] == BRS-I SMBIOS Requirements -The System Management BIOS (SMBIOS) specification defines a standard format for presenting management information about an implentation, mostly focusing on hardware components. +The _System Management BIOS (SMBIOS) Reference Specification_ defines a standard format for presenting management information about an implentation, mostly focusing on hardware components. This section defines the BRS-I mandatory and optional SMBIOS requirements on top of existing cite:[SMBIOS] specification requirements. Additional -non-normative guidance may be found in the <> section. +non-normative guidance may be found in the <> section. IMPORTANT: All content in this section is optional and recommended for BRS-B. -NOTE: The structures and fields in this section are defined in a manner consistent with the DMTF specification -language (cite:[SMBIOS]). +NOTE: The structures and fields in this section are defined in a manner consistent with the DMTF specification language (cite:[SMBIOS]). [width=100%] [%header, cols="5,25"] |=== | ID# ^| Requirement -| SMBIOS_010 | A Baseboard/Module Information (Type 02) structure SHOULD be implemented. -| SMBIOS_020 | A System Enclosure/Chassis (Type 03) structure SHOULD be implemented. +| `SMBIOS_010` | A Baseboard/Module Information (Type 02) structure SHOULD be implemented. +| `SMBIOS_020` | A System Enclosure/Chassis (Type 03) structure SHOULD be implemented. 2+|_This relaxes the SMBIOS specification requirement._ -| SMBIOS_030 | A Processor Information (Type 04) structure, meeting the additional <> clarifications, MUST be implemented. +| `SMBIOS_030` | A Processor Information (Type 04) structure, meeting the additional <> clarifications, MUST be implemented. 2+|_This supersedes the RISC-V specific language in the SMBIOS specification (cite:[SMBIOS], Section 7.5.3.5)._ -| SMBIOS_040 | A Port Connector Information (Type 08) SHOULD be implemented. -| SMBIOS_050 | A System Slots (Type 09) structure MUST be implemented, when expansion slots are present. -| SMBIOS_060 | An OEM Strings (Type 11) structure SHOULD be implemented. -| SMBIOS_070 | A BIOS Language Information (Type 13) structure SHOULD be implemented. -| SMBIOS_080 | A Group Associations (Type 14) structure SHOULD be implemented. -| SMBIOS_090 | An IPMI Device Information (Type 38) structure MUST be implemented, when an IPMIv1.0 host interface is present. -| SMBIOS_100 | A System Power Supplies (Type 39) structure SHOULD be implemented. -| SMBIOS_110 | An Onboard Devices Extended Information (Type 41) structure SHOULD be implemented. -| SMBIOS_120 | A Redfish Host Interface (Type 42) structure MUST be implmented, when a Redfish host interface is present. -| SMBIOS_130 | A TPM Device (Type 43) structure MUST be implmented, when a TPM is present. -| SMBIOS_140 | A Processor Additional Information (Type 44) structure MUST be implemented. +| `SMBIOS_040` | A Port Connector Information (Type 08) SHOULD be implemented. +| `SMBIOS_050` | A System Slots (Type 09) structure MUST be implemented, when expansion slots are present. +| `SMBIOS_060` | An OEM Strings (Type 11) structure SHOULD be implemented. +| `SMBIOS_070` | A BIOS Language Information (Type 13) structure SHOULD be implemented. +| `SMBIOS_080` | A Group Associations (Type 14) structure SHOULD be implemented. +| `SMBIOS_090` | An IPMI Device Information (Type 38) structure MUST be implemented, when an IPMIv1.0 host interface is present. +| `SMBIOS_100` | A System Power Supplies (Type 39) structure SHOULD be implemented. +| `SMBIOS_110` | An Onboard Devices Extended Information (Type 41) structure SHOULD be implemented. +| `SMBIOS_120` | A Redfish Host Interface (Type 42) structure MUST be implmented, when a Redfish host interface is present. +| `SMBIOS_130` | A TPM Device (Type 43) structure MUST be implmented, when a TPM is present. +| `SMBIOS_140` | A Processor Additional Information (Type 44) structure MUST be implemented. 2+| _See the <>_. -| SMBIOS_150 | A Firmware Inventory Information (Type 45) structure SHOULD be implemented. +| `SMBIOS_150` | A Firmware Inventory Information (Type 45) structure SHOULD be implemented. |=== [[smbios-type04]] @@ -44,35 +43,34 @@ IMPORTANT: The information in this section supersedes the definitions in (cite:[ A processor is a grouping of harts in a physical package. In modern designs this MAY mean a SoC. -For RISC-V class CPUs, the Processor ID field contains two DWORD-formatted values describing +For RISC-V class CPUs, the `Processor ID` field contains two `DWORD`-formatted values describing the overall physical processor package vendor and version. For some implementations -this may also be known as the SoC ID. The first DWORD (offsets 08h-0Bh) is the JEP-106 code for -the vendor. The second DWORD (offsets 0Ch-0Fh) reflects vendor-specific part versioning. +this may also be known as the SoC ID. The first `DWORD` (offsets 08h-0Bh) is the JEP-106 code for +the vendor. The second `DWORD` (offsets 0Ch-0Fh) reflects vendor-specific part versioning. -For hart-specific vendor and revision information, please see Type 44 Processor-Specific Data -structures. +For hart-specific vendor and revision information, please see Type 44 Processor-Specific Data structures. [[smbios-type44]] === Type 44 Processor-Specific Data The processor-specific data structure fields are defined to follow the standard Processor-Specific Block fields (cite:[SMBIOS], Section 7.45.1). -The structure is valid for processors declared as architecture 07h (64-bit RISC-V) only. +The structure is valid for processors declared with `Processor Type` 07h (64-bit RISC-V) only. A Type 44 structure needs to be provided for every hart meeting <> requirements. [cols="2,2,3,2,2,4", width=95%, align="center", options="header"] |=== | Offset | Version | Name | Length | Value | Description -| 00h| 0100h|Revision|WORD|Varies|See <>. -| 02h| 0100h| Hart ID| QWORD| Varies| The ID of this RISC-V hart. -| 0Ah| 0100h| Machine Vendor ID | QWORD| Varies| The vendor ID of this +| 00h| 0100h| `Revision`|`WORD`|Varies|See <>. +| 02h| 0100h| `Hart ID`| `QWORD`| Varies| The ID of this RISC-V hart. +| 0Ah| 0100h| `Machine Vendor ID` | `QWORD` | Varies| The vendor ID of this RISC-V hart. -| 12h| 0100h| Machine Architecture ID| QWORD| Varies| Base +| 12h| 0100h| `Machine Architecture ID` | `QWORD` | Varies| Base microarchitecture of the hart. Value of 0 is possible to indicate the field is -not implemented. The combination of Machine Architecture ID and Machine Vendor -ID should uniquely identify the type of hart microarchitecture that is implemented. -| 1Ah| 0100h| Machine Implementation ID| QWORD| Varies| Unique encoding +not implemented. The combination of `Machine Architecture ID` and `Machine Vendor +ID` should uniquely identify the type of hart microarchitecture that is implemented. +| 1Ah| 0100h| `Machine Implementation ID` | `QWORD`| Varies| Unique encoding of the version of the processor implementation. |=== diff --git a/uefi.adoc b/uefi.adoc index 152674a..f006d37 100644 --- a/uefi.adoc +++ b/uefi.adoc @@ -1,12 +1,12 @@ [[uefi]] == BRS-I UEFI Requirements -The Unified Extensible Firmware Interface (UEFI) specification describes the interface between the OS and the supervisor-mode firmware. +The _Unified Extensible Firmware Interface Specification_ (UEFI) describes the interface between the OS and the supervisor-mode firmware. This section defines the BRS-I mandatory and optional UEFI requirements on top of existing cite:[UEFI] specification requirements. Additional non-normative guidance may be found in the -<> section. +<> section. IMPORTANT: All content in this section is optional and recommended for BRS-B. @@ -14,20 +14,20 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. [%header, cols="5,25"] |=== | ID# ^| Requirement -| UEFI_010 | Implement a 64-bit UEFI firmware. -| UEFI_020 | Meet the 3rd Party UEFI Certificate Authority (CA) requirements on UEFI memory mitigations cite:[MSUefiCaRequirements]. -| UEFI_030 a| Meet BRS-I specific memory map requirements: +| `UEFI_010` | Implement a 64-bit UEFI firmware. +| `UEFI_020` | Meet the 3rd Party UEFI Certificate Authority (CA) requirements on UEFI memory mitigations cite:[MSUefiCaRequirements]. +| `UEFI_030` a| Meet BRS-I specific memory map requirements: - * The default memory space attribute MUST be EFI_MEMORY_WB. + * The default memory space attribute MUST be `EFI_MEMORY_WB`. * Enable address translation. - * Only use EfiRuntimeServicesData memory type for describing any SMBIOS data structures. -| UEFI_040 | An implementation MAY comply with the UEFI Platform Initialization Specification cite:[UEFI-PI]. -| UEFI_050 | All hart manipulation internal to a firmware implementation SHOULD be done before completion of the EFI_EVENT_GROUP_READY_TO_BOOT event, with all secondary harts remaining offline from that point on. + * Only use `EfiRuntimeServicesData` memory type for describing any SMBIOS data structures. +| `UEFI_040` | An implementation MAY comply with the _UEFI Platform Initialization Specification_ cite:[UEFI-PI]. +| `UEFI_050` | All hart manipulation internal to a firmware implementation SHOULD be done before completion of the `EFI_EVENT_GROUP_READY_TO_BOOT` event, with all secondary harts remaining offline from that point on. 2+| _This ensures an OS loader is entered with an OS-compatible state for all harts._ -| UEFI_060 | Declare a EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile. -2+| _The EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile MUST be declared, as the BRS requirements are a superset of UEFI cite:[UEFI] (Section 2.6)._ -| UEFI_070 | Declare EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile ({ 0x05453310, 0x0545, 0x0545, { 0x05, 0x45, 0x33, 0x05, 0x45, 0x33, 0x05, 0x45 }}). -2+| _Only a system fully compliant to the requirements in this section MAY declare the EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile._ +| `UEFI_060` | Declare the `EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID` conformance profile. +2+| _The `EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID` conformance profile MUST be declared, as the BRS requirements are a superset of UEFI cite:[UEFI] (Section 2.6)._ +| `UEFI_070` | Declare the `EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID` conformance profile `({ 0x05453310, 0x0545, 0x0545, { 0x05, 0x45, 0x33, 0x05, 0x45, 0x33, 0x05, 0x45 }})`. +2+| _Only a system fully compliant to the requirements in this section MAY declare the `EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID` conformance profile._ |=== === BRS-I Security Requirements @@ -36,13 +36,13 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. [%header, cols="5,25"] |=== | ID# ^| Requirement -| USEC_010 | Systems implementing UEFI Secure Boot are RECOMMENDED to implement the EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL protocols cite:[UEFI-PI]. -2+| _The Security and Security2 Architectural Protocols are overridden by some bootloaders (e.g. systemd-boot) to validate EFI binaries that cannot be validated against the UEFI security database._ -| USEC_020 | Systems implementing a TPM MUST implement the TCG -EFI Protocol Specification cite:[TcgEfiPlat]. +| `USEC_010` | Systems implementing UEFI secure boot are RECOMMENDED to implement the `EFI_SECURITY_ARCH_PROTOCOL` and `EFI_SECURITY2_ARCH_PROTOCOL` protocols cite:[UEFI-PI]. +2+| _The Security and Security2 architectural protocols are overridden by some bootloaders (e.g. systemd-boot) to validate EFI binaries that cannot be validated against the UEFI security database._ +| `USEC_020` | Systems implementing a TPM MUST implement the _TCG +EFI Protocol Specification_ cite:[TcgEfiPlat]. |=== -See additional <>. +See additional <>. === BRS-I I/O-specific Requirements @@ -50,10 +50,10 @@ See additional <>. [%header, cols="5,25"] |=== | ID# ^| Requirement -| UIO_010 | Systems implementing PCIe MUST always initialize all root complex hardware and perform resource assignment for all endpoints and usable hotplug-capable switches in the system, even in a boot scenario from a non-PCIe boot device. +| `UIO_010` | Systems implementing PCIe MUST always initialize all root complex hardware and perform resource assignment for all endpoints and usable hotplug-capable switches in the system, even in a boot scenario from a non-PCIe boot device. 2+| _This is a stronger requirement than the PCI Firmware Specification firmware/OS device hand-off state (cite:[PCIFW] Section 3.5). <>._ -| UIO_020 | Systems implementing EFI_GRAPHICS_OUTPUT_PROTOCOL SHOULD configure the frame buffer to be directly accessible. -2+| _That is, EFI_GRAPHICS_PIXEL_FORMAT is not PixelBltOnly and FrameBufferBase is reported as a valid hart MMIO address._ +| `UIO_020` | Systems implementing `EFI_GRAPHICS_OUTPUT_PROTOCOL` SHOULD configure the frame buffer to be directly accessible. +2+| _That is, `EFI_GRAPHICS_PIXEL_FORMAT` is not `PixelBltOnly` and `FrameBufferBase` is reported as a valid hart memory-mapped I/O address._ |=== [[uefi-rt]] @@ -63,25 +63,25 @@ See additional <>. [%header, cols="5,25"] |=== | ID# ^| Requirement -| URT_010 a| Systems without a Real-Time Clock (RTC) MUST meet the following requirements: +| `URT_010` a| Systems without a Real-Time Clock (RTC) MUST meet the following requirements: - * GetTime MUST be implemented (e.g. in terms of CPU cycle counter). - * SetTime MUST return EFI_UNSUPPORTED, and be appropriately described in EFI_RT_PROPERTIES_TABLE. -| [[uefi-rtc]] URT_020 a| Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST meet the following requirements: + * `GetTime()` MUST be implemented (e.g. in terms of CPU cycle counter). + * `SetTime()` MUST return `EFI_UNSUPPORTED`, and be appropriately described in the `EFI_RT_PROPERTIES_TABLE`. +| [[uefi-rtc]] `URT_020` a| Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST meet the following requirements: - * GetTime and SetTime MUST return EFI_UNSUPPORTED, when called after the UEFI boot services have been exited. - * GetTime and SetTime MUST be appropriately described in EFI_RT_PROPERTIES_TABLE. -2+|_Also see <>_. -| URT_030 a| The UEFI ResetSystem() runtime service MUST be implemented. -2+| _The OS MUST call the ResetSystem() runtime service call to reset or shutdown the system, preferring this to SBI, ACPI or other system-specific mechanisms. This allows for systems to perform any required system tasks on the way out (e.g. servicing UpdateCapsule() or persisting non-volatile variables in some systems)._ -| URT_040 | Non-volatile UEFI variables MUST persist across calls to the Reset System() runtime service call. -| URT_050 | UEFI Runtime Services MUST be able to update the variables directly without the aid of an OS. -| URT_060 a| The following requirements MUST be met for systems with UEFI Secure Boot: + * `GetTime()` and `SetTime()` MUST return `EFI_UNSUPPORTED`, when called after the UEFI boot services have been exited. + * `GetTime()` and `SetTime()` MUST be appropriately described in the `EFI_RT_PROPERTIES_TABLE`. +2+|_Also see <>_. +| `URT_030` a| The UEFI `ResetSystem()` runtime service MUST be implemented. +2+| _The OS MUST call the `ResetSystem()` runtime service call to reset or shutdown the system, preferring this to SBI, ACPI or other system-specific mechanisms. This allows for systems to perform any required system tasks on the way out (e.g. servicing `UpdateCapsule()` or persisting non-volatile variables in some systems)._ +| `URT_040` | Non-volatile UEFI variables MUST persist across calls to the `ResetSystem()` runtime service call. +| `URT_050` | UEFI runtime services MUST be able to update the variables directly without the aid of an OS. +| `URT_060` a| The following requirements MUST be met for systems with UEFI secure boot: * MUST support a minimum of 128 KiB of non-volatile storage for UEFI variables. * The maximum supported variable size MUST be at least 64 KiB. - * The 'db' signature database variable EFI_IMAGE_SECURITY_DATABASE MUST be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback attacks. - * The 'dbx' signature database variable EFI_IMAGE_SECURITY_DATABASE1 MUST be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback. + * The `db` signature database variable (`EFI_IMAGE_SECURITY_DATABASE`) MUST be created with `EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS`, to prevent rollback attacks. + * The `dbx` signature database variable (`EFI_IMAGE_SECURITY_DATABASE1`) MUST be created with `EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS`, to prevent rollback attacks. |=== === BRS-I Firmware Update @@ -90,10 +90,10 @@ See additional <>. [%header, cols="5,25"] |=== | ID# ^| Requirement -| UFU_010 | Systems with in-band firmware updates MUST do so either via UpdateCapsule() UEFI runtime service (cite:[UEFI] Section 8.5.3) or Delivery of Capsules via file on Mass Storage Device (cite:[UEFI] Section 8.5.5). +| `UFU_010` | Systems with in-band firmware updates MUST do so either via `UpdateCapsule()` UEFI runtime service (cite:[UEFI] Section 8.5.3) or via _Delivery of Capsules via file on Mass Storage Device_ (cite:[UEFI] Section 8.5.5). 2+| _In-band means the firmware running on a hart updates itself._ -| UFU_020 | Systems implementing in-band firmware updates via UpdateCapsule MUST accept updates in the "Firmware Management Protocol Data Capsule Structure" format as described in "Delivering Capsules Containing Updates to Firmware Management Protocol" cite:[UEFI] (Section 23.3). -| UFU_030 | Systems implementing in-band firmware updates via UpdateCapsule MUST provide an ESRT cite:[UEFI] (Section 23.4) describing every firmware image that is updated in-band. -| UFU_040 | Systems implementing in-band firmware updates via UpdateCapsule MAY return EFI_UNSUPPORTED, when called after the UEFI boot services have been exited. +| `UFU_020` | Systems implementing in-band firmware updates via `UpdateCapsule()` MUST accept updates in the _Firmware Management Protocol Data Capsule Structure_ format as described in _Delivering Capsules Containing Updates to Firmware Management Protocol_ cite:[UEFI] (Section 23.3). +| `UFU_030` | Systems implementing in-band firmware updates via `UpdateCapsule()` MUST provide an ESRT cite:[UEFI] (Section 23.4) describing every firmware image that is updated in-band. +| `UFU_040` | Systems implementing in-band firmware updates via `UpdateCapsule()` MAY return `EFI_UNSUPPORTED`, when called after the UEFI boot services have been exited. 2+| _<>_. |===