- Also, indicates the test coverage.
| Test Number | Component | Level | Test assertion | Section | Checked by ACS Now | Test Environment |
|---|---|---|---|---|---|---|
| 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 |
| 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 |
| 17 | PE | L3+ | Each PE implements CRC32 instructions | 4.4.1 | yes | UEFI App |
| 18 | PE | L6+ | If PEs implement the Scalable Vector Extension (SVE) and the Statistical Profiling Extension (SPE), the PEs will implement Armv8.5-SPE | 4.5.1 | 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 | 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 |
| 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 | 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 |
| 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 | L6+ | Hardware updates to Access flag and Dirty state in translation tables, must be supported | 4.5.1 | yes | UEFI App |
| 29 | PE | L6+ | PEs must implement restrictions on speculation introduced in the Arm v8.5 extensions | 4.5.1 | yes | UEFI App |
| 30 | PE | L6+ | PEs must implement Speculative Store Bypass Safe | 4.5.1 | yes | UEFI App |
| 31 | PE | L6+ | PEs must implement the SB speculation barrier | 4.5.1 | yes | UEFI App |
| 32 | PE | L6+ | PEs must implement the CFP RCTX, DVP RCTX, CPP RCTX instructions | 4.5.1 | yes | UEFI App |
| 33 | PE | L6+ | PEs must provide support for Branch Target Identification | 4.5.1 | yes | UEFI App |
| 34 | PE | L6+ | PEs must protect against timing faults being used to guess page table mappings | 4.5.1 | yes | UEFI App |
| 35 | PE | L6+ | PEs will provide support for enhanced virtualization traps | 4.5.1 | yes | UEFI App |
| 36 | PE | L6+ | All PEs will implement Armv8.5-PMU | 4.5.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 |
| 303 | Watchdog | L5+ | A system compatible with level 5 will implement a generic counter which counts in nanosecond units. ARM strongly recommends that such systems use revision 1 of the generic watchdog | 4.4.4 | 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 | PCIe | L1+ | PEs are able to access the ECAM region | 8.1 | yes | UEFI App |
| 801 | PCIe | L3+ | PEs are able to access the ECAM region | 8.1 | yes | Linux driver |
| 405 | PCIe | L1+ | All systems must support mapping PCI Express memory space as either device memory or non-cacheable memory | 8.2 | yes | Linux driver |
| 802 | PCIe | L3+ | All systems must support mapping PCI Express memory space as either device memory or non-cacheable memory | 8.2 | yes | UEFI App |
| 405 | 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 |
| 802 | PCIe | L3+ | When PCI Express memory space is mapped as normal memory, the system must support unaligned accesses to that region. | 8.2 | yes | UEFI App |
| 803 | PCIe | L3+ | PCIe I/O Coherency Scenarios with System MMU are covered | 8.3 | yes | UEFI App |
| 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 | 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 |
| 804 | PCIe | L3+ | 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 | UEFI App |
| PCIe | L3+ | 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 | PCIe | L3+ | If the system supports PCIe PASID, then at least 16 bits of PASID must be supported | 8.11 | yes | Linux driver |
| 805 | PCIe | L3+ | If the system supports PCIe PASID, then at least 16 bits of PASID must be supported | 8.11 | yes | UEFI App |
| 411 | PCIe | L0+ | The PCI Express root complex is in the same Inner Shareable domain as the PEs | 8.7 | yes | Linux driver |
| 412 | 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 |
| 806 | PCIe | L3+ | Each of the 4 legacy interrupt lines must be allocated a unique SPI ID and is programmed as level sensitive | 8.5 | yes | UEFI App |
| 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 | 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 |
| 807 | PCIe | L3+ | 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 | UEFI App |
| 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 |
| 417 | PCIe | L3+ | In a system where the PCIe hierarchy allows peer to peer transactions, the root ports in an ARM based SoC must implement PCIe access control service (ACS) features | D.13 | yes | Linux driver |
| 418 | PCIe | L3+ | All PCIe switches should support the minimal features, refer D.13 section for features list | D.13 | yes | Linux driver |
| 419 | PCIe | L3+ | All multi-function devices, SR-IOV and non-SR-IOV, that are capable of peer to peer traffic between different functions should support the minimal features, refer D.13 section for features list | D.13 | no | Linux driver |
| 420, 431, 432 | PCIe | L3+ | All PCIe devices, must implement the common registers of Type 0/1 header, as per requirements in E.3 and E.4 section | E.3/4 | yes | UEFI App |
| 421, 434 | PCIe | L3+ | All PCIe devices, must implement the registers of Type 0/1 header, as per requirements in E.3/E.4/D.1 section | E.3 | yes | UEFI App |
| 422 | PCIe | L3+ | All PCIe devices, must implement the registers of Type 1 header, as per requirements in E.4 section | E.3 | yes | UEFI App |
| 423 | PCIe | L3+ | i-EP Root Port, must implement the registers of PCIe capability(10h), as per requirements in E.15 section | E.15 | yes | UEFI App |
| 424, 433, 435 | PCIe | L3+ | All PCIe devices, must implement the Device capability register of PCIe capability(10h), as per requirements in E.14/15 section | E.14/15 | yes | UEFI App |
| 425 | PCIe | L3+ | All PCIe devices, must implement the Device Control register of PCIe capability(10h), as per requirements in E.14/15 section | E.14/15 | yes | UEFI App |
| 426, 436, 437 | PCIe | L3+ | All PCIe devices, must implement the Device capabilities 2 register of PCIe capability(10h), as per requirements in E.14/15 section | E.14/15 | yes | UEFI App |
| 427 | PCIe | L3+ | All PCIe devices, must implement the Device control 2 register of PCIe capability(10h), as per requirements in E.14/15 section | E.14/15 | yes | UEFI App |
| 428 | PCIe | L3+ | All PCIe devices, must implement the power management capability register of power management capability(01h), as per requirements in E.14/15 section | E.14/15 | yes | UEFI App |
| 429 | PCIe | L3+ | All PCIe devices, must implement the power management control/status register of power management capability(01h), as per requirements in E.14/15 section | E.14/15 | yes | UEFI App |
| 430 | PCIe | L3+ | Memory space access should raise Unsupported Request, when device Memory Space enable bit is clear | E.3/4 | yes | UEFI App |
| 808 | PCIe | L3+ | If the Bus Master Enable (BME) bit in Command register is cleared, the i-EP Endpoint must not generate any memory read or write requests. | E.15.1 | yes | UEFI App |
| 438, 439 | PCIe | L3+ | iEP root port must follow Completion timeout ranges supported, Completion timeout disable supported and AtomicOp routing supported bit as per Section E.15.11 | E.15.11 | yes | UEFI App |
| 440 | PCIe | L3+ | root port must not support ATS and PRS extened capability | yes | UEFI App | |
| 441 | PCIe | L3+ | RCiEP and iEP end point must support MSI or MSI-X interrupts | E.7 | yes | UEFI App |
| 442 | PCIe | L3+ | RCiEP, iEP root port and iEP end point must support have Power Management Capability | E.11 | yes | UEFI App |
| 443 | PCIe | L3+ | Root Port must implement ARI forwarding enable as per in E.15.12 section | E.15.12 | yes | UEFI App |
| 444 | PCIe | L3+ | Root Port Configuration Space must be under same ECAM as the Configuration Space of Endpoints and switches in hierachy that originates from that port | D.1 | yes | UEFI App |
| 445 | PCIe | L3+ | All Root Port Configuration Space under same Host Bridge must be in same ECAM | D.1 | yes | UEFI App |
| 446 | PCIe | L3+ | The Root Port must comply with the byte enable rules and must support 1 byte, 2 byte and 4 byte Configuration read and write requests | D.1 | yes | UEFI App |
| 447 | PCIe | L3+ | Must recognize and consume Configuration transactions intended for the Root Port Configurationspace and read/write the appropriate Root Port Configuration register | D.1 | yes | UEFI App |
| 448 | PCIe | L3+ | Must recognize transactions received on the primary side of the RP PCI-PCI bridge, targeting non-prefetchable memory spaces of devices and switches that are on the secondary side of the bridge : Where the address falls within the non-prefetchable memory window in the type 1 header registers, the transactions must be forwarded to the secondary side | D.1 | yes | UEFI App |
| 449 | PCIe | L3+ | Must recognize transactions received on the primary side of the RP PCI-PCI bridge, targeting prefetchable memory spaces of devices and switches that are on the secondary side of the bridge : Where the address falls within the prefetchable memory window in the type 1 header registers, the transactions must be forwarded to the secondary side | D.1 | yes | UEFI App |
| 450 | PCIe | L3+ | Each legacy interrupt SPI must be programmed as level-sensitive in the appropriate GIC_ICFGR | D.6 | yes | UEFI App |
| 451 | PCIe | L3+ | For i-EP, the Root Port must provide the ability to do a hot reset of the Endpoint using the Secondary Bus Reset bit in bridge Control Register | E.10 | yes | UEFI App |
| 452 | PCIe | L3+ | PCIe ATS capability must be supported if the RCiEP or i-EP has a software visible cache for address translations | E.9 | yes | UEFI App |
| 453 | PCIe | L3+ | If the PCIe hierarchy allows peer-to-peer transactions, Root Port must support ACS capability. | D.11 | yes | UEFI App |
| 454 | PCIe | L3+ | If the PCIe hierarchy allows peer-to-peer transactions, The root port must support ACS violation error detection, Logging and reporting must be through the usage of AER mechanism | D.11 | yes | UEFI App |
| 455 | PCIe | L3+ | If the Root port supports peer-to-peer traffic with other root ports then - If the root port supports Address Translation services and peer-to-peer traffic with other root ports, then it must support ACS direct translated P2P | D.11 | yes | UEFI App |
| 456 | PCIe | L3+ | If the i-EP endpoint is capable of sending transactions to a peer endpoint (RCiEP or i-EP endpoint or discrete), then the i-EP root port must have ACS capability | E.12 | yes | UEFI App |
| 457 | PCIe | L3+ | ACS capability must be present in the RCiEP or i-EP endpoint functions if the RCiEP or i-EP Endpoint isa multi-function device and supports peer to peer traffic between its functions. | E.12 | yes | UEFI App |
| 809 | PCIe | L3+ | Configuration transactions indented for secondary bus of root port must be of Type0 | D.1 | yes | Baremetal |
| 810 | PCIe | L3+ | Configuration transactions indented for subordinate bus range of root port must be of Type1 | D.1 | yes | Baremetal |
| 811 | PCIe | L3+ | Check Address Translation Service Functional Check | E.9 | yes | UEFI App |
| 812 | PCIe | L3+ | Check Peer-to-Peer ACS Source Validation & Transaction Blocking Functionality | D.11 | yes | UEFI App |
| 813 | PCIe | L3+ | Check Peer-to-Peer ACS Redirected Request Validation Functionality | D.11 | yes | UEFI App |
| 814 | PCIe | L3+ | PCI Express transactions marked as No_snoop accessing memory must have coherency managed by software . | D.8 | yes | UEFI App |
| 815 | PCIe | L3+ | Transactions that are targeted at devices must be treated as device type access. They must be ordered, must not merge and must not allocate in caches . | D.8.1 | yes | UEFI App |
| 816 | PCIe | L3+ | Root Port must implement ARI forwarding enable. | E.15 | yes | UEFI App |
| 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 |
| 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 |
| 707 | SMMU | L1+ | SMMU Version Check | 8.5.2 | yes | UEFI App |
| 708 | SMMU | L6+ | SMMU must implement support for 16 bit VMID. | 8.5.2 | yes | UEFI App |
| 709 | SMMU | L6+ | SMMU must implement support for 16 bit ASID. | 8.5.2 | yes | UEFI App |
| 710 | SMMU | L6+ | SMMU must support the translation granule sizes supported by the PEs. | 8.5.2 | yes | UEFI App |
| 711 | SMMU | L6+ | if PEs implement ARMv8.2-LVA, the SMMU must support extended virtual addresses | 8.5.2 | yes | UEFI App |
| 712 | SMMU | L3+ | if PEs implement Armv8.2-LPA, it follows that the SMMU must support a 52 bit output size | 8.5.2 | yes | UEFI App |
| 713 | SMMU | L6+ | The SMMU must implement coherent access to in memory structures, queues, and page tables | 8.5.2 | yes | UEFI App |
| 714 | SMMU | L6+ | The SMMU must support hardware translation table update (HTTU) of the Access flag and the Dirty state of the page for AArch64 translation tables. | 8.5.2 | yes | UEFI App |
| 715 | SMMU | L6+ | SMMU will support little endian for translation table walks, and at a minimum must match the endianness support of the PE's. | 8.5.2 | yes | UEFI App |
| 716 | SMMU | L6+ | The DVM capabilities of all DVM receivers (SMMUs and PEs) need to be the same or a superset of the DVM capabilities of all DVM initiators (PEs). Check For TLB Range Invalidation. | 8.5.2 | yes | UEFI App |
| 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 | |
| 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 | no | Secure FW | |
| 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 | no | Secure FW | |
| System counter and generic timer | L0+ | Must implement at least 56 bits | 4.1.5 | no | Secure FW | |
| System counter and generic timer | L0+ | The counter shall be sized and programmed to ensure that rollover never occurs in pract | 4.1.5 | no | Secure FW | |
| System counter and generic timer | L1+ | In systems that implement EL3, CNTControlBase should be mapped to Secure address space only | 4.2.3 | no | Secure FW | |
| 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 | no | Secure FW | |
| System counter and generic timer | L1- | The local PE timer when expiring must generate a PPI when EL3 physical timer expires | 4.1.5 | no | Secure FW | |
| 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 | no | Secure FW | |
| 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 | no | Secure FW | |
| 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 | no | Secure FW | |
| 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 | no | Secure FW | |
| 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 | no | Secure FW | |
| 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 | ||
| 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 | no | ||
| SMMU | L4+ | All addresses output from a device to an SMMU must lie in a continuous space with no holes. All address in said space will be treated equally by the SMMU. There should be no areas within the address space that receive exceptional treatment, such as bypassing the SMMU | 4.3.2 | no | ||
| PE | L5+ | PEs based on ARMv8.4 must implement the requirements of the CS-BSA combination C [6] | 4.4.1 | no | ||
| PE | L5+ | All PEs must implement the Memory Partitioning and Monitoring Extension with a minimal configuration | 4.4.1 | no | ||
| PE | L2+ | PMBIRQ will be wired as PPI 21 | 4.3.2.2 | no | ||
| PE | L3+ | Where PEs implement the scalar vector extension, the vector length maximum must be at least 256 bits | 4.1.1 | no | ||
| System counter | L5+ | A system compatible with level 5 will implement counter scaling as described in the ARMv8.4 architecture | 4.4.4 | no | ||
| PE | L4+ | if the system contains persistent memory that is exposed to the OS, all PEs must support the clean to point of persistence instruction (DC CVAP). The instruction must be able to perform a clean to the point of persistence for all memory that is exposed as persistent memory to the OS | 4.3.1 | no | ||
| PCIe | L5+ | Any system that implements PCIe Precision Time Measurement (PTM) [8] must use the ARM architecture defined System Counter [2] as PTM master time source at the PTM root(s) | D.15 | no | ||
| IO Virtualisation | L3+ | ARMv8.4 introduces TLB Invalidation instructions which apply to a range of input addresses rather than just to a single address. If PEs used by the server base system support TLB range instructions, then all OS visible masters that contain a TLB must support range invalidates | 4.1.6 | no | ||
| System counter and generic timer | L3+ | Previous versions of the SBSA imposed an upper limit of 400Mhz. This is instead replaced by an upper limit on the roll over period | 4.1.7 | no | ||
| IO Virtualisation | L5+ | MPAM architecture requires that all masters that can access an MPAM controlled resource, must support passing MPAM ID information. Therefore, an SMMUv3.2 implementation must support the MPAM extension if the requests it serves access MPAM controlled resources | 4.4.3 | no | ||
| PCIe | L3+ | If the Root port supports peer to peer traffic with other root ports, then it must support minimal features. Refer D.13 section for features list | D.13 | no |
Arm SBSA ACS is distributed under Apache v2.0 License.
Copyright (c) 2018-2021, Arm Limited and Contributors. All rights reserved.