diff --git a/acpi.adoc b/acpi.adoc index 6c3fbaa..a81d6df 100644 --- a/acpi.adoc +++ b/acpi.adoc @@ -14,7 +14,7 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | [[acpi-64bit-clean]]`ACPI_010` a| Be 64-bits clean. * RSDT MUST NOT be implemented, with `RsdtAddress` in RSDP set to 0. @@ -52,13 +52,13 @@ objects. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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`. +| `AML_020` | The Current Resource Setting (_CRS) device method for a PCIe Root Complex SHOULD NOT return any descriptors for I/O ranges (such as created by ASL macros WordIO, DWordIO, QWordIO, IO, FixedIO, 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._ diff --git a/hart.adoc b/hart.adoc index aab7b59..6727d2d 100644 --- a/hart.adoc +++ b/hart.adoc @@ -8,7 +8,7 @@ The BRS specification is minimally prescriptive on the RISC-V hart requirements. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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 bc79434..a86e7b5 100644 --- a/intro.adoc +++ b/intro.adoc @@ -24,7 +24,7 @@ The requirements in this specification use the following format: [width=100%] [%header, cols="5,20"] |=== -| ID# ^| Requirement +| 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. + diff --git a/non-normative/acpi.adoc b/non-normative/acpi.adoc index 3867673..6044fab 100644 --- a/non-normative/acpi.adoc +++ b/non-normative/acpi.adoc @@ -166,8 +166,8 @@ a DSDT/SSDT MMIO device object without making the OS aware of the underlying PCI 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 SBI Probe extension (`FID #3`) to detect the Debug Console Extension +(`DBCN`). The new `Precise Baud Rate` field, introduced in cite:[SPCR] rev. 4, allows describing rates faster than 115200 baud for NS16550-compatible UARTS. diff --git a/sbi.adoc b/sbi.adoc index 1969ec8..952174d 100644 --- a/sbi.adoc +++ b/sbi.adoc @@ -9,7 +9,7 @@ privilege mode in order to be compatible with this specification. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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._ @@ -20,7 +20,7 @@ Certain requirements are conditional on the presence of RISC-V ISA extensions or [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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 (sPI) MUST be implemented, if the Incoming MSI Controller (IMSIC, cite: [Aia]) is not available. | `SBI_050` | The RFENCE Extension (RFNC) extension MUST be implemented, if the Incoming MSI Controller (IMSIC, cite: [Aia]) is not available. diff --git a/smbios.adoc b/smbios.adoc index c634b28..f9f417c 100644 --- a/smbios.adoc +++ b/smbios.adoc @@ -15,7 +15,7 @@ NOTE: The structures and fields in this section are defined in a manner consiste [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `SMBIOS_010` | A Baseboard/Module Information (Type 02) structure SHOULD be implemented. 2+|_This relaxes the SMBIOS specification requirement._ | `SMBIOS_020` | Processor Information (Type 04) structures, meeting the additional <> clarifications, MUST be implemented. diff --git a/uefi.adoc b/uefi.adoc index 2a60e20..eaaf5fc 100644 --- a/uefi.adoc +++ b/uefi.adoc @@ -4,7 +4,7 @@ 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 +rules on top of existing cite:[UEFI] specification requirements. Additional non-normative guidance may be found in the <> section. @@ -13,17 +13,17 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `UEFI_010` | MUST implement a 64-bit UEFI firmware. | `UEFI_020` | MUST meet the 3rd Party UEFI Certificate Authority (CA) requirements on UEFI memory mitigations cite:[MSUefiCaRequirements]. -| `UEFI_030` a| MUST meet the following memory map requirements: +| `UEFI_030` a| MUST meet the following memory map rules: * The default memory space attribute is `EFI_MEMORY_WB`. * Address translation is enabled. * 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_050` | All hart manipulation internal to a firmware implementation SHOULD be done before completion of the `EFI_EVENT_GROUP_READY_TO_BOOT` event. Firmware MUST place all secondary harts in an offline state before completion of the EFI_EVENT_GROUP_READY_TO_BOOT event. +2+| _This ensures an OS loader is entered with an OS-compatible state for all harts.The OS loader and/or the OS may resume the secondary harts, if required, as part of their boot and join sequence._ | `UEFI_060` | The implementation MUST 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` | The implementation MUST declare the `EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID` conformance profile `({ 0x05453310, 0x0545, 0x0545, { 0x05, 0x45, 0x33, 0x05, 0x45, 0x33, 0x05, 0x45 }})`. @@ -39,7 +39,7 @@ hand-off info to an OS, for example, to provide RAM disk information [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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 @@ -53,7 +53,7 @@ See additional <>. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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. @@ -66,7 +66,7 @@ See additional <>. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `URT_010` a| Systems without a Real-Time Clock (RTC), but with an equivalent alternate source for the current time, MUST meet the following requirements: * `GetTime()` MUST be implemented. @@ -81,6 +81,7 @@ See additional <>. 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 UEFI variables directly without the aid of an OS. +2+| _UEFI variables are normally saved in a dedicated storage which is not directly accessible by the operating system._ | `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. @@ -94,7 +95,7 @@ See additional <>. [width=100%] [%header, cols="5,25"] |=== -| ID# ^| Requirement +| ID# ^| Rule | `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).