Updates for ARC and Roy's feedback on 0.0.3

acpi-prop.adoc

@@ -5,17 +5,17 @@ This section is used to define the `_DSD` device properties cite:[DSD] in the `r
 
 Where explicit values are provided in a property definition, only these values must be used. System behavior with any other values is undefined.
 
-Request for new property names in the `rscv-` namespace should be made as a git pull request to below table in this document.
-
 [width=100%]
 [%header, cols="10,5,25"]
 |===
 |  Property  ^| Type | Description
+3+|_Currently, there are no properties defined in the `riscv-` namespace. Request for new property names in the `rscv-` namespace should be made as a git pull request to this table._
 |===
 
+
 [[acpi-props-uart]]
 === ACPI Device Properties for UART Devices
-Generic 16550-compatible UART devices can have below device properties in the global name space
+Generic 16550-compatible UART devices can have device properties in the global name space
 since Operating Systems are already using them.
 
 [width=100%]

acpi.adoc

@@ -20,7 +20,7 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B.
   * RSDT MUST NOT be implemented, with `RsdtAddress` in RSDP set to 0.
   * 32-bit address fields MUST be 0.
 2+| _<<acpi-guidance-64bit-clean, See additional guidance>>._
-| [[acpi-hw-reduced]]`ACPI_020` a| Implement the hardware-reduced ACPI mode (no FACS table).
+| [[acpi-hw-reduced]]`ACPI_020` a| MUST implement the hardware-reduced ACPI mode (no FACS table).
 2+| _<<acpi-guidance-hw-reduced, See additional guidance>>._
 | [[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].

brs.bib

@@ -26,10 +26,6 @@ @electronic{DSD
   title = {_DSD (Device Specific Data) Implementation Guide},
   url = {https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf}
 }
-@electronic{RSPS,
-  title = {RISC-V Server Platform Specification},
-  url = {https://github.com/riscv-non-isa/riscv-server-platform}
-}
 @electronic{SBI,
   title = {RISC-V Supervisor Binary Interface Specification},
   url = {https://github.com/riscv-non-isa/riscv-sbi-doc}

intro.adoc

@@ -17,29 +17,29 @@ The BRS focuses on two solutions in the form of what is deemed a recipe. Each re
 
 === Testing and Conformance
 
-To be compliant with this specification, an implementation MUST support all mandatory requirements and MUST support the listed versions of the specifications. This standard set of capabilities MAY be extended by a specific implemenation with additional standard on custom capabilities, including compatible later versions of listed standard specifications. Portable system software MUST support the specified mandatory capabilities to the compliant with this specification.
+To be compliant with this specification, an implementation MUST support all mandatory rules and MUST support the listed versions of the specifications. This standard set of capabilities MAY be extended by a specific implementation with additional standard on custom capabilities, including compatible later versions of listed standard specifications. Portable system software MUST support the specified mandatory capabilities to the compliant with this specification.
 
-The requirements in this specification use the following format:
+The rules in this specification use the following format:
 
 [width=100%]
 [%header, cols="5,20"]
 |===
 | 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.                                   +
+             numeric ID to the rule.                                   +
                                                                               +
-             The requirements use the key words "MUST", "MUST NOT",
+             The rules use the key words "MUST", "MUST NOT",
              "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
              "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" that are
              to be interpreted as described in RFC 2119 cite:[RFC_2119] when,
              and only when, they appear in all capitals, as shown here. When
              these words are not capitalized, they have their normal English
              meanings.
-2+| _A requirement or a group of requirements may be followed by non-normative
-    text providing context or justification for the requirement. The
+2+| _A rule or a group of rules may be followed by non-normative
+    text providing context or justification for the rule. The
     non-normative text may also be used to reference sources that are the
-    origin of the requirement._
+    origin of the rule._
 |===
 
 === Glossary

non-normative/recipes.adoc

@@ -12,8 +12,3 @@ might be low-resolution and the sound, built-in network port or power
 management might not work out of the box. You could subsequently load
 the right drivers from the media coming with the board or fetch newest
 ones using a well-supported network adapter.
-
-Requirements for heterogeneous performance harts (e.g. mix of "performance"
-and "efficiency" harts) are described in the "RISC-V Server Platform
-specification" cite:[RSPS]. The ACPI specification cite:[ACPI] has a
-chapter on "Collaborative Processor Performance Control".

recipes.adoc

@@ -34,12 +34,10 @@ 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.
-<<recipe-brs-i-guidance, See additional guidance>>.
+missing I/O or accelerator drivers. Any additional firmware features
+that cause anomalous and unexpected behavior must be disabled by
+default, and only enabled by opt-in. <<recipe-brs-i-guidance, See
+additional guidance>>.
 
 .BRS-I Recipe Overview
 [width=100%]

uefi.adoc

@@ -28,7 +28,7 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B.
 | `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 }})`.
-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 MUST declare the `EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID` conformance profile._
 | `UEFI_080` | A Device Tree MUST only be exposed to the OS iff no actual hardware description is included in the DT.
 2+|_Such a "dummy" DT could be installed by firmware, as a UEFI configuration table entry of type `EFI_DTB_TABLE_GUID`, to provide necessary
 hand-off info to an OS, for example, to provide RAM disk information
@@ -80,7 +80,8 @@ See additional <<uefi-rt, requirements for UEFI runtime services>>.
              * `GetTime()` and `SetTime()` MUST be appropriately described in the `EFI_RT_PROPERTIES_TABLE`.
 | `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` | The UEFI variables MUST persist across calls to the `ResetSystem()` runtime service call.
+| `URT_040` | The non-volatile UEFI variables MUST persist across calls to the `ResetSystem()` runtime service call.
+2+| _This rule is included in this specification to address a common mistake in implementing the UEFI requirements for non-volatile variables, even though it may appear redundant with the existing UEFI specification._
 | `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: