Updates for some of the ARC feedback (#206)

* Update text around secondary core requirement (ARC #183)

Fix for the ARC feedback regarding secondary cores.

Fixes: #183
Closes: #183
Signed-off-by: Sunil V L <[email protected]>

* Remove allowing deprecated legacy SBI console (ARC #203)

Remove text around supporting deprecated SBI legacy console.

Fixes: #203
Closes: #203
Signed-off-by: Sunil V L <[email protected]>

* Add clarification for URT_050 (ARC #201)

Fixes: #201
Signed-off-by: Sunil V L <[email protected]>

* Change from Requirement to Rule (ARC #199)

As per ARC feedback, change the Table headings from Requirements to Rules.

Fixes: #199
Closes: #199
Signed-off-by: Sunil V L <[email protected]>

* ACPI: Clarify that WordIo etc are AML macros (ARC #197)

Clarify AML_020 requirement that DWordIo etc are ASL macros instead of
resource types. Add missing other IO macros as well.

Fixes: #197
Closes: #197
Signed-off-by: Sunil V L <[email protected]>

---------

Signed-off-by: Sunil V L <[email protected]>

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._

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._
 

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.                                   +

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.

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.

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 <<smbios-type04>> clarifications, MUST be implemented.

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
 <<uefi-guidance, firmware implementation guidance>> 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 <<uefi-rt, requirements for UEFI runtime services>>.
 [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). <<uefi-guidance-pcie, See additional guidance>>._
 | `UIO_020` | Systems implementing `EFI_GRAPHICS_OUTPUT_PROTOCOL` SHOULD configure the frame buffer to be directly accessible.
@@ -66,7 +66,7 @@ See additional <<uefi-rt, requirements for UEFI runtime services>>.
 [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 <<uefi-rt, requirements for UEFI runtime services>>.
 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 <<uefi-rt, requirements for UEFI runtime services>>.
 [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).