FIRM_010 | RISC-V SoCs MUST comply with the BRS-I recipe described in the Boot and Runtime Service v1.0 specification [16]. |
FIRM_020 | The firmware MUST implement the SBI v3.0 Debug Triggers (DBTR) extension [4]. |
Supervisor software needs DBTR in order to utilize Sdtrig, which is mandated by rule RVA_020. |
FIRM_030 | If the software running on the application processor supports RAS functionality for RISC-V components, the firmware MUST implement the SBI v3.0 Supervisor Software Events (SSE) extension [4]. |
FIRM_040 | The firmware MUST include configuration infrastructure, supporting relevant HII protocols ([17] number 2). |
FIRM_050 | The firmware SHOULD include the ability to boot from disk (block) device, supporting relevant protocols ([17] number 5). |
FIRM_060 | The firmware SHOULD include the ability to perform a TFTP-based boot from a network device ([17] number 6). |
FIRM_070 | The firmware SHOULD include the ability to validate boot images. |
FIRM_080 | The firmware SHOULD support UEFI general purpose network applications, including IPv4, IPv6, DNS, TLS, IPSec and VLAN features, supporting relevant protocols ([17] number 7). |
FIRM_090 | The firmware SHOULD support RISC-V option ROMs, compiled for the RVA20 profile or a later profile ([16] BRS-I Recipe), from devices not permanently attached to the platform ([17] number 19). |
FIRM_100 | The firmware SHOULD support 64-bit Intel architecture (aka x64, aka AMD64) UEFI option ROM drivers for additional compatibility with the third-party IHV ecosystem. |
| Since expansion cards for GPUs, High Speed NICs, etc. move faster than most platform vendors can integrate drivers into their platform firmware package (as well as those drivers making said firmware images extremely large), supporting UEFI Option ROM Drivers in x86_64 via emulation enables more hardware without having to wait for the platform vendor to port a drvier and ship it natively into their firmware. This is how Aarch64 systems solve the problem of no native drivers for the similar devices. The use of EFI Byte Code (EBC) is typically not used by hardware vendors because the compilers have not been available for some time and no open source compilers exist. Most add-in boards only ship x86_64 COFF EFI Drivers which are supported by github.com/tianocore/edk2-non-osi/tree/master/Emulator/X86EmulatorDxe if it’s included in the EDK2 build. |
FIRM_105 | If the firmware supports option ROMs, then it MUST support the ability to authenticate them ([17] number 19). |
FIRM_110 | The firmware SHOULD support the ability to perform a HTTP-based boot from a network device, including support for HTTPS and DNS, supporting relevant HII protocols ([17] number 22). |
FIRM_120 | The firmware MUST support software that runs from EFI firmware to install Load Option Variables (Boot####, or Driver####, or SysPrep####) consistent with [17] number 27. |
FIRM_130 | The firmware MUST support software that runs from EFI firmware to register for notifications when a call to ResetSystem is called, consistent with [17] number 32. |
FIRM_140 | IOMMU MUST be described using the RIMT ACPI table [18]. |
FIRM_150 | If the firmware allows forward-edge control-flow integrity (FCFI) to be enabled for the supervisor execution environment, the runtime services MUST be compiled to support FCFI. |
| The supervisor execution environment SHOULD enable FCFI through the SBI FWFT LANDING_PAD interface. |
FIRM_160 | The support for forward-edge control-flow integrity in runtime services MUST be signaled by the EFI_MEMORY_ATTRIBUTES_FLAGS_RT_FORWARD_CONTROL_FLOW_GUARD flag ([5] Section 4.6.3 EFI_MEMORY_ATTRIBUTES_TABLE). |
FIRM_170 | If the runtime services support forward-edge control-flow integrity, the instruction at the entry address of any runtime service MUST be a 4-byte aligned, unlabeled landing pad (lpad 0). |