From 9c8be52c6837d70f78333cf767b194195b8639d1 Mon Sep 17 00:00:00 2001 From: Andrei Warkentin Date: Mon, 15 Apr 2024 12:23:29 -0500 Subject: [PATCH] Nits Signed-off-by: Andrei Warkentin --- acpi-id.adoc | 2 +- acpi.adoc | 12 ++++++------ smbios.adoc | 2 +- uefi.adoc | 22 +++++++++++----------- 4 files changed, 19 insertions(+), 19 deletions(-) diff --git a/acpi-id.adoc b/acpi-id.adoc index 8e323c0..e07a869 100644 --- a/acpi-id.adoc +++ b/acpi-id.adoc @@ -7,7 +7,7 @@ devices, that do not have a standard enumeration mechanism. The ACPI ID consists of two parts: a Vendor ID 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. diff --git a/acpi.adoc b/acpi.adoc index 1127586..61fe19d 100644 --- a/acpi.adoc +++ b/acpi.adoc @@ -17,8 +17,8 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. | ID# ^| Requirement | [[acpi-64bit-clean]]ACPI_010 a| Be 64-bits clean. - * RSDT must not be implemented, with RsdtAddress in RSDP set to 0. - * 32-bit address fields must be 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). 2+| _<>._ @@ -33,7 +33,7 @@ available to an OS loader via the standard UEFI EFI_GRAPHICS_OUTPUT_PROTOCOL int * Revision 4 or later of SPCR. * For NS16550-compatible UARTs: ** Use Interface Type 0x12 (16550-compatible with parameters defined in Generic Address Structure). - ** There must be a matching AML device object. + ** There MUST be a matching AML device object. 2+| _<>_. | [[acpi-namespace-dev]]ACPI_080 | Depending on the interrupt controller implemented by the system, PLIC or APLIC namespace devices MUST be @@ -65,12 +65,12 @@ objects. 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). +| 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_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 +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._ diff --git a/smbios.adoc b/smbios.adoc index b2a4a6c..81bebc8 100644 --- a/smbios.adoc +++ b/smbios.adoc @@ -20,7 +20,7 @@ language (cite:[SMBIOS]). | 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. diff --git a/uefi.adoc b/uefi.adoc index 4350548..152674a 100644 --- a/uefi.adoc +++ b/uefi.adoc @@ -18,16 +18,16 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B. | 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. 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)._ +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._ +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 @@ -65,12 +65,12 @@ See additional <>. | ID# ^| Requirement | 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. + * 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 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. + * 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)._ @@ -78,10 +78,10 @@ See additional <>. | 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 KB of non-volatile storage for UEFI variables. - * The maximum supported variable size must be at least 64 KB. - * 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. + * 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. |=== === BRS-I Firmware Update