1 |
PE |
L0 |
Number must be < 8 |
4.1.1 |
yes |
UEFI App |
2 |
PE |
L0+ |
PE(s) must implement SIMD extensions |
4.1.1 |
yes |
UEFI App |
3 |
PE |
L0+ |
PE(s) shall implement 16 bit ASID support |
4.1.1 |
yes |
UEFI App |
4 |
PE |
L0+ |
PE(s) shall support 4KB and 64KB at stage 1 and 2 |
4.1.1 |
yes |
UEFI App |
5 |
PE |
L0+ |
cache architecture type VIPT or PIPT |
4.1.1 |
yes |
UEFI App |
6 |
PE |
L0+ |
All PE(s) are coherent in the same same inner sharable domain |
4.1.1 |
yes |
UEFI App |
7 |
PE |
L0+ |
PE(s) where export restrictions allow should implement cryptography extensions |
4.1.1 |
yes |
UEFI App |
8 |
PE |
L0+ |
PE(s) shall implement LE support |
4.1.1 |
yes |
UEFI App |
9 |
PE |
L0+ |
PE(s) shall implement EL2 |
4.1.1 |
yes |
UEFI App |
10 |
PE |
L0+ |
PE(s) shall implement AArch64 at all levels |
4.1.1 |
yes |
UEFI App |
11 |
PE |
L1- |
The PMU overflow signal for each PE must be wired as a unique SPI or PPI with no intervening logic |
4.1.1 |
yes |
UEFI App |
11 |
PE |
L2+ |
The PMU overflow signal from each PE must be wired to a unique PPI interrupt with no intervening logic. PPI must be 23 |
4.3.1 |
yes |
UEFI App |
12 |
PE |
L0 |
Each PE will implement a minimal of four programable PMU counters |
4.1.1 |
yes |
UEFI App |
12 |
PE |
L1+ |
Each PE must implement a minimum of six programmable PMU counters |
4.2.1 |
yes |
UEFI App |
13 |
PE |
L0+ |
Each PE will implement a minimal of four synchronous watchpoints |
4.1.1 |
yes |
UEFI App |
14 |
PE |
L0 |
Each PE implements a minimum of four breakpoints, two of which must be able to match virtual address, contextID or VMID |
4.1.1 |
yes |
UEFI App |
14 |
PE |
L1+ |
Each PE must implement a minimum of six breakpoints, two of which must be able to match virtual address, contextID or VMID |
4.2.1 |
yes |
UEFI App |
15 |
PE |
L0+ |
All PE(s) are architecturally symetric (allowed exceptions in Appendix C) |
4.1.1 |
yes |
UEFI App |
16 |
PE |
L3+ |
Each PE implements EL3 Exception Level |
4.4.1 |
yes |
UEFI App |
17 |
PE |
L3+ |
Each PE implements CRC32 instructions |
4.4.1 |
yes |
UEFI App |
18 |
PE |
L2+ |
PMBIRQ will be wired as PPI 21 |
4.3.2.2 |
yes |
UEFI App |
19 |
PE |
L4+ |
All PEs must implement the RAS extension introduced in ARMv8.2 |
4.3.1 |
yes |
UEFI App |
20 |
PE |
L4+ |
All PEs must implement support for 16-bit VMD |
4.3.1 |
yes |
UEFI App |
21 |
PE |
L4+ |
All PEs must implement virtual host extensions |
4.3.1 |
yes |
UEFI App |
22 |
PE |
L5+ |
All PEs must provide support for stage-2 control of memory types and cacheability, as introduced by ARMv8.4 extensions |
4.4.1 |
yes |
UEFI App |
23 |
PE |
L5+ |
All PEs must implement enhanced nested virtualization |
4.4.1 |
yes |
UEFI App |
24 |
PE |
L5+ |
All PEs must support changing of page table mapping size using level1 and level2 solution proposed in the ARMv8.4 extension. Level2 is recommended |
4.4.1 |
yes |
UEFI App |
25 |
PE |
L4+ |
If PEs implement ARMv8.3 pointer signing, the PEs must provide the standard algorithm defined by the ARM architecture |
4.4.1 |
yes |
UEFI App |
26 |
PE |
L5+ |
All PEs must implement the Activity Monitors Extension |
4.4.1 |
yes |
UEFI App |
27 |
PE |
L5+ |
Where export control allows, all PEs must implement cryptography support for SHA3 and SHA512 |
4.4.1 |
yes |
UEFI App |
28 |
PE |
L3+ |
Where PEs implement the scalar vector extension, the vector length maximum must be at least 256 bits |
4.1.1 |
yes |
UEFI App |
101 |
GICv3 |
L2+ |
Interrupt controller shall conform to GICv3 specification |
4.3.2 |
yes |
UEFI App |
102 |
GICv3 |
L2+ |
If the base server system includes PCI Express then the GICv3 interrupt controller shall implement ITS and LPI |
4.3.2 |
yes |
UEFI App |
103 |
GIC |
L3+ |
The GICv3 interrupt controller shall support two Security states |
4.4.4 |
yes |
UEFI App |
104 |
GICv2/3 |
L2+ |
GIC maintenance interrupt shall be wired as PPI 25 |
4.3.2.4 |
yes |
UEFI App |
201 |
System counter and generic timer |
L0+ |
Must run between 10Mhz and 400Mhz |
4.1.5 |
yes |
UEFI App |
202 |
System counter and generic timer |
L1- |
The local PE timer when expiring must generate a PPI when EL1 physical timer expires |
4.1.5 |
yes |
UEFI App |
202 |
System counter and generic timer |
L2+ |
The local PE timer when expiring must generate a PPI when EL1 physical timer expires, and PPI must be 30 |
4.3.2.1 |
yes |
UEFI App |
203 |
System counter and generic timer |
L1- |
The local PE timer when expiring must generate a PPI when the virtual timer expires |
4.1.5 |
yes |
UEFI App |
203 |
System counter and generic timer |
L2+ |
The local PE timer when expiring must generate a PPI when the virtual timer expires, and PPI must be 27 |
4.3.2.1 |
yes |
UEFI App |
204 |
System counter and generic timer |
L1- |
The local PE timer when expiring must generate a PPI when EL2 physical timer expires |
4.1.5 |
yes |
UEFI App |
204 |
System counter and generic timer |
L2+ |
The local PE timer when expiring must generate a PPI when EL2 physical timer expires, and PPI must be 26 |
4.3.2.1 |
yes |
UEFI App |
205 |
System counter and generic timer |
L1- |
For systems where PE are 8.1 or greater local PE timer when expiring must generate a PPI when EL2 virtual timer expires |
4.1.5 |
yes |
UEFI App |
205 |
System counter and generic timer |
L2+ |
For systems where PE are 8.1 or greater local PE timer when expiring must generate a PPI when EL2 virtual timer expires, and PPI must be 28 |
4.3.2.1 |
yes |
UEFI App |
206 |
System counter and generic timer |
L1+ |
In systems that implement EL3, the memory mapped timer (the CNTBaseN frame and associated CNTCTLBase frame) must be mapped into the Non-secure address space |
4.2.3. |
yes |
UEFI App |
206 |
System counter and generic timer |
L3+ |
If the system includes a system wakeup timer, this memory-mapped timer must be mapped on to Non-secure address space |
4.4.6 |
yes |
UEFI App |
207 |
System counter and generic timer |
L1+ |
Unless all local PE timers are Always ON, a system timer based on architecture memory mapped generic itmer view shall generate an SPI |
4.2.3 |
yes |
UEFI App |
208 |
System counter and generic timer |
L0 |
A system specific system timer shall generate an SPI |
4.1.7 |
yes |
UEFI App |
301 |
Watchdog |
L1+ |
system implements a Generic Watchdog as specified in APPENDIX A: Generic Watchdog. |
|
yes |
UEFI App |
301 |
Watchdog |
L3+ |
The watchdog required by level 2 must have both its register frames mapped on to Non-secure address space; this is referred to as the Non-secure watchdog |
4.4.7 |
yes |
UEFI App |
302 |
Watchdog |
L1- |
Watchdog Signal 0 is routed as an SPI to the GIC and usable as a EL2 interrupt |
4.2.4 |
yes |
UEFI App |
302 |
Watchdog |
L2+ |
Watchdog Signal 0 is routed as an SPIor LPI to the GIC and usable as a EL2 interrupt |
4.3.8 |
yes |
UEFI App |
401 |
PCIe |
L1+ |
Systems must map memory space to PCI Express configuration space, using the PCI Express Enhanced Configuration Access Mechanism (ECAM). Tests should be robust to ARI being implemented |
8.1 |
yes |
Linux driver |
402 |
PCIe |
L1+ |
The base address of each ECAM region is discoverable from system firmware data |
8.1 |
yes |
Linux driver |
403, 801 |
PCIe |
L1+ |
PEs are able to access the ECAM region |
8.1 |
yes |
Linux driver |
404, 802 |
PCIe |
L1+ |
All systems must support mapping PCI Express memory space as either device memory or non-cacheable memory |
8.2 |
yes |
Linux driver |
404, 802 |
PCIe |
L1+ |
When PCI Express memory space is mapped as normal memory, the system must support unaligned accesses to that region. |
8.2 |
yes |
Linux driver |
405 |
PCIe |
L3+ |
In systems that are compatible with level 3 or above of the SBSA, the addresses sent by PCI express devices must be presented to the memory system or SMMU unmodified |
8.3 |
yes |
Linux driver |
405 |
PCIe |
L0+ |
In a system where the PCI express does not use an SMMU, the PCI express devices have the same view of physical memory as the PEs |
8.3 |
yes |
Linux driver |
405, 803 |
PCIe |
L0+ |
PCIe I/O Coherency Scenarios without System MMU are covered |
8.7.1 |
yes |
Linux driver |
405 |
PCIe |
L1+ |
PCIe I/O Coherency Scenarios with System MMU are covered |
8.7.2 |
yes |
Linux driver |
406 |
PCIe |
L0+ |
In a system with a SMMU for PCI express there are no transformations to addresses being sent by PCI express devices before they are presented as an input address to the SMMU. |
8.3 |
yes |
Linux driver |
406 |
PCIe |
L3+ |
the addresses sent by PCI express devices must be presented to the memory system or SMMU unmodified |
4.4.8 |
yes |
Linux driver |
407 |
PCIe |
L1+ |
Support for Message Signaled Interrupts (MSI/MSI-X) is required for PCI Express devices. MSI and MSI-X are edge-triggered interrupts that are delivered as a memory write transaction |
8.4 |
yes |
Linux driver |
408, 804 |
PCIe |
L1+ |
each unique MSI(-X) shall trigger an interrupt with a unique ID and the MSI(-X) shall target GIC registers requiring no hardware specific software to service the interrupt |
8.4 |
Yes |
Linux driver |
|
PCIe |
L1+ |
Add GICv2/v3 support details |
8.4.1/2 |
No |
Linux driver |
409 |
GICv3 |
L2+ |
All MSIs and MSI-x are mapped to LPI |
4.3.2 |
yes |
Linux driver |
410, 805 |
PCIe |
L3+ |
If the system supports PCIe PASID, then at least 16 bits of PASID must be supported |
8.11 |
yes |
Linux driver |
411 |
PCIe |
L0+ |
The PCI Express root complex is in the same Inner Shareable domain as the PEs |
8.7 |
yes |
Linux driver |
412, 806 |
PCIe |
L1+ |
Each of the 4 legacy interrupt lines must be allocated a unique SPI ID and is programmed as level sensitive |
8.5 |
yes |
Linux driver |
413 |
MemoryMap |
L3+ |
All Non-secure on-chip masters in a base server system that are expected to be under the control of the OS or hypervisor must be capable of addressing all of the NS address space. If the master goes through a SMMU then it must be capable of addressing all of the NS address space when the SMMU is off. |
4.4.3 |
yes |
Linux driver |
413 |
MemoryMap / PCIe |
L3+ |
Non-secure off-chip devices that cannot directly address all of the Non-secure address space must be placed behind a stage 1 System MMU compatible with the ARM SMMUv2 or SMMUv3 specification. that has an output address size large enough to address all of the Non-secure address space. |
4.4.3 |
yes |
Linux driver |
414 |
Peripheral Subsystems |
L3+ |
Memory Attributes of DMA traffic are one of (1) Inner WB, Outer WB, Inner Shareable (2) Inner/Outer Non-Cacheable (3) Device TypeIO Coherent DMA is as per (1) Inner/Outer WB, Inner Shareable |
4.4.8 |
yes |
Linux driver |
415, 807 |
PCIe |
L0+ |
PCI Express transactions not marked as No_snoop accessing memory that the PE translation tables attribute as cacheable and shared are I/O Coherent with the PEs. |
8.7 |
yes |
Linux driver |
416 |
PCIe |
L4+ |
For Non-prefetchable (NP) memory, type-1 headers only support 32bit address, systems complaint with SBSA level 4 or above must support 32bit programming of NP BARs on such endpoints |
D.2 |
yes |
Linux driver |
504 |
Watchdog |
L1+ |
Watchdog Signal 0 should be able to wakeup at least one PE from various low power states. Based off power states supported - this should be covered for 1 of N condition with some PEs in low power and from the lowest power stated where the Watchdog is ON. |
4.2.6 |
yes |
UEFI App |
504 |
System counter and generic timer |
L1+ |
Unless all local PE timers are Always ON, a system timer based on architecture memory mapped generic timer view shall generate an SPI that wake the platform from states with semantics B,C,D,E,F,H,I |
4.2.3 |
yes |
UEFI App |
505 |
System counter and generic timer |
L0 |
A system specific system timer shall generate an SPI that wake the platform from states with semantics B,C,D,E,F,H,I |
4.1.7 |
no |
UEFI App |
505 |
Wakeup semantics |
L0+ |
Whilst in state F a PE must not wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
yes |
UEFI App |
601 |
Peripheral Subsystems |
L0+ |
If the system has a USB2.0 host controller peripheral it must conform to EHCI v1.1 or later - Peripheral subsystems which do not conform to the above are permitted, provided that they are not required to boot and install an OS |
4.1.8 |
yes |
UEFI App |
601 |
Peripheral Subsystems |
L0+ |
If the system has a USB3.0 host controller peripheral it must conform to XHCI v1.0 or later - Peripheral subsystems which do not conform to the above are permitted, provided that they are not required to boot and install an OS |
4.1.8 |
yes |
UEFI App |
602 |
Peripheral Subsystems |
L0+ |
If the system has a SATA host controller peripheral it must conform to AHCI v1.3 or later - Peripheral subsystems which do not conform to the above are permitted, provided that they are not required to boot and install an OS |
4.1.8 |
yes |
UEFI App |
603 |
Peripheral Subsystems |
L1+ |
For the purpose of system development and bring up, the base server system shall include a Generic UART. The Generic UART is specified in Appendix B. The UARTINTR interrupt output is connected to the GIC as an SPI. |
4.2.7 |
yes |
UEFI App |
603 |
Peripheral Subsystems |
L3+ |
Check that that Generic UART is mapped to Non-Secure address space |
4.4.8 |
yes |
UEFI App |
604 |
Peripheral Subsystems |
L2+ |
UARTINTR of the generic UART shall be connected as SPI or LPI |
4.3.9 |
yes |
UEFI App |
605 |
MemoryMap |
L0+ |
Accesses to part of the memory map that is unpopulated should not deadlock and cause a precise data abort, SEI or SPU interrupt delivered to the GIC |
4.1.3 |
yes |
UEFI App |
605 |
MemoryMap |
L2+ |
Where a memory access is to an unpopulated part of the addressable memory space, accesses must be terminated in a manner that is presented to the PE as either a precise Data Abort or that causes a system error interrupt or an SPI or LPI interrupt to be delivered to the GIC. |
4.3.3 |
yes |
UEFI App |
606 |
Peripheral Subsystems |
L3 FW |
Some memory is mapped in secure address space. The memory shall not be aliased in Non-secure address space |
4.5.1 |
yes |
UEFI App |
701 |
IO Virtualisation |
L0+ |
SMMU if present must spport a 64KB granule, For L1- this would be an SMMUv1 for L2 SMMUv2, and |
4.1.4 |
yes |
UEFI App |
702 |
SMMU |
L3+ |
All the System MMUs in the system must the compliant with the same architecture version |
4.4.5 |
yes |
UEFI App |
703 |
SMMU |
L3+ |
If SMMUv3 is in use, The integration of the System MMUs is compliant with the specification in APPENDIX H: SMMUv3 Integration |
4.4.5Appendix H |
yes |
UEFI App |
703 |
IO Virtualisation |
L2+ |
Stage 2 System MMU functionality must be provided by a System MMU compatible with the ARM SMMUv2 spec |
4.3.5 |
yes |
UEFI App |
703 |
SMMU |
L3+ |
Stage 2 System MMU functionality must be provided by a System MMU compatible with the ARM SMMUv2 or SMMUv3 specification |
4.4.5 |
yes |
UEFI App |
703 |
PCIe |
L1+ |
Hardware support for I/O Virtualization is optional, but if required shall use a System MMU compliant with the ARM System MMU specification |
8.6 |
yes |
UEFI App |
703 |
IO Virtualisation |
L0+ |
Policing is required at stage 2 |
4.1.4 |
yes |
UEFI App |
703 |
SMMU |
L4+ |
Stage 1 and 2 SMMU functionality must be provided by a SMMU compatible with ARM SMMUv3 or higher |
4.3.2 |
yes |
UEFI App |
703 |
SMMU |
L5+ |
SMMU implementations must be complaint with the ARM SMMUv3.2 architecture revision or higher |
4.3.2 |
yes |
UEFI App |
704 |
SMMU |
L3+ |
The SMMUv3 spec requires that PCIe root complex must not use the stall model due to potential deadlock. |
Appendix H |
yes |
UEFI App |
705 |
SMMU |
L3+ |
If SMMUv2 is in use, Each context bank must present a unique physical interrupt to the GIC |
4.4.5 |
yes |
UEFI App |
706 |
PCIe |
L1+ |
Each function, or virtual function, that requires hardware I/O virtualization is associated with a SMMU context. The programming of this association is IMPLEMENTATION DEFINED and is expected to be described by system firmware data. |
8.6 |
yes |
UEFI App |
901 |
Watchdog |
L1+ |
Watchdog Signal 1 is available. This may be confirmed in the data base. This may not be possible to exersice as its handling is platform specific |
4.2.4 |
yes |
Secure FW |
901 |
Watchdog |
L3 FW |
The Watchdog Signal 1 is routed as a SPI to GIC and usable as an EL3 interrupt, directly targetting a single PE |
4.5.3 |
yes |
Secure FW |
902 |
System counter and generic timer |
L0+ |
Must implement at least 56 bits |
4.1.5 |
yes |
Secure FW |
902 |
System counter and generic timer |
L0+ |
The counter shall be sized and programmed to ensure that rollover never occurs in pract |
4.1.5 |
yes |
Secure FW |
902 |
System counter and generic timer |
L1+ |
In systems that implement EL3, CNTControlBase should be mapped to Secure address space only |
4.2.3 |
yes |
Secure FW |
902 |
System counter and generic timer |
L1+ |
Generic Timer required registers are implemented as specified in section 4.2.3.1 "Summary of required registers of the CNTControlBase frame" |
4.2.3.1 |
yes |
Secure FW |
903 |
System counter and generic timer |
L1- |
The local PE timer when expiring must generate a PPI when EL3 physical timer expires |
4.1.5 |
yes |
Secure FW |
903 |
System counter and generic timer |
L2+ |
The local PE timer when expiring must generate a PPI when EL3 physical timer expires, and PPI must be 29 |
4.3.2.1 |
yes |
Secure FW |
904 |
System counter and generic timer |
L0+ |
Any local timers that are marked by PE as always ON must be able to wake up the system. This applies to expiry of all secure views of the local timer (CNTPS) |
4.1.7 |
yes |
Secure FW |
904 |
Watchdog |
L3 FW |
Secure Watchdog is implemented. Secure watchdog is not-aliased in non-secure address space. Signal 0 if secure watchdog is routed as an SPI and usable as an interrupt to EL3, directly targetting a single PE |
4.5.3 |
yes |
Secure FW |
905 |
Peripheral Subsystems |
L3 FW |
Secure Generic UART is present. It is not aliased in Non-secure address space. The UARTINTR output of the secure generic UART is connected to the GIC as an SPI |
4.5.4 |
yes |
Secure FW |
906 |
System counter and generic timer |
L3 FW |
A secure system wakeup timer is present and the interrupt is presented to GIC as a SPI |
4.5.2 |
yes |
Secure FW |
501, 502 |
System counter and generic timer |
L0+ |
Any local timers that are marked by PE as always ON must be able to wake up the system. This applies to expiry of all non-secure views of the local timer (CNTV/P/HP/HV) |
4.1.7 |
yes |
UEFI App |
501, 502, 503, 504 |
Wakeup semantics |
L0+ |
Whilst in state B a PE must be able to wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
yes |
UEFI App |
|
PCIe |
L1+ |
only registers defined in the PCI Express specification and the ARM GIC specification are used to deliver legacy interrupts |
8.5 |
yes |
ARM Enterprise ACS package |
|
PCIe |
L1+ |
All end points claiming PCIe support must follow PCIe rules. |
8.9 |
yes |
ARM Enterprise ACS package |
|
Wakeup semantics |
L0+ |
Whilst in state C a PE must be able to wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
no |
|
|
Wakeup semantics |
L0+ |
Whilst in state D a PE must be able to wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
no |
|
|
Wakeup semantics |
L0+ |
Whilst in state E a PE must be able to wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
no |
|
|
Wakeup semantics |
L0+ |
Whilst in state G a PE must be able to wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
no |
|
|
Wakeup semantics |
L0+ |
Whilst in state H a PE must be able to wake upon receipt of an SGI, PPI or SPI that directly targets the PE |
4.3.4/7 |
no |
|
|
Power State Semantics |
L2+ |
System MMUs and, in the future, GICv3, make use of tables in memory in the power states where GIC is ‘On’, system memory shall be available and will respond to requests without requiring intervention from software. |
4.1.7 |
no |
|
|
Wakeup semantics |
L1+ |
Power States A-I as described in "Requirements on power state semantics" shall be covered |
4.2.5 |
no |
|
|
PCIe |
L0+ |
PCI Express transactions marked as No_snoop accessing memory that the PE translation tables attribute as cacheable and shared behave correctly when appropriate SW coherence is deployed |
8.7 |
no |
|
|
PCIe |
L3+ |
Systems compatible with level 3 or above of the SBSA must not deadlock if PCI express devices attempt peer-to-peer transactions – even if the system does not support peer-to-peer traffic |
8.10 |
no |
|
|
Debug |
L2+ |
COMMIRQ interrupt for Debug Communications Channel will be wired as PPI 22 |
4.3.2.1 |
no |
|
|
Debug |
L2+ |
Cross trigger interface interrupt shall be wired as PPI 24 |
4.3.2.3 |
no |
|
|
System counter and generic timer |
L2+ |
Where a system wake up timer is present it shall generate an SPI or LPI that wake the platform from states with semantics B,C,D,E,F,H,I |
4.3.6 |
no |
|
|
Watchdog |
L3 FW |
Routing of Signal 1 of Secure Watchdog to Platform |
4.5.3 |
no |
|