This repository is deprecated. All support for the repository will end on 31st October 2022 after which it shall be archived. Refer to Arm SystemReady SR ACS for the new ACS.
Architecture Compliance Suite (ACS) is used to ensure architectural compliance across different implementations of the architecture. Arm Enterprise ACS includes a set of examples of the invariant behaviors that are provided by a set of specifications for enterprise systems (For example: SBSA, SBBR, etc.), so that implementers can verify if these behaviours have been interpreted correctly. ACS is delivered with tests in source form along with a build script, the output of the build being a bootable Linux UEFI Validation (LUV) OS image that can run all tests required by these specifications.
Arm Enterprise ACS tests are available open source. The tests and the corresponding abstraction layers are available with an Apache v2 license allowing for external contribution.
In summary, the Arm Enterprise ACS product contains the following:
These tests are split between UEFI and Linux (supported by corresponding kernel driver) applications that together determine whether an architectural implementation is compliant with the enterprise specifications. These tests are further described in detail.
Before starting the ACS build, ensure that the following requirements are met:
Perform the following steps to start the ACS build:
Note:
The luv-live-image-gpt.img bootable image can be found in:
<work_dir>/arm-enterprise-acs/luv/build/tmp/deploy/images/qemuarm64/luv-live-image-gpt.img
This image comprises of two FAT file system partitions recognized by UEFI:
The grub-efi-bootaa64.efi netbootable image can be found in:
<work_dir>/arm-enterprise-acs/luv/build/tmp/deploy/images/qemuarm64/grub-efi-bootaa64.efi
This image is built to be used in PXE Booting and automatic execution of tests
For more details please check this document : build-options.
For more information, see Yocto Project and LuvOS.
Note: UEFI EDK2 setting for "Console Preference": The default is "Graphical". When that is selected, Linux output will go only to the graphical console (HDMI monitor). To force serial console output, you may change the "Console Preference" to "Serial".
- After [#define ARM_GIC_DEFAULT_PRIORITY 0x80] +#define ARM_GIC_MAX_NUM_INTERRUPT 16384 - Change this in GicV3DxeInitialize function. -mGicNumInterrupts = ArmGicGetMaxNumInterrupts (mGicDistributorBase); +mGicNumInterrupts = ARM_GIC_MAX_NUM_INTERRUPT;
Note: RD-N2 should be built with the GIC Changes mentioned in Prerequisites.
Note: sudo permission will be required by building software stack.
export MODEL=<absolute path to the RD-N2 FVP binary/FVP_RD_N2>
cd /path to RD-N2_FVP platform software/model-scripts/rdinfra/platforms/rdn2
./run_model.sh -v /path-to-luv-live-image/luv-live-image-gpt.img
This will start the luv live image automation and run the test suites in sequence.
The test suite execution can be automated or manual. Automated execution is the default execution method when no key is pressed during boot.
Note: SBBR SCT tests are now included as part of automation. For information about running these tests, see section ‘SBBR SCT tests’ in this document.
The execution varies depending on the test environment.
The next set of commands are an example of our typical run of the test suites.
Note that the File System Partition in your platform can vary.
The live image boots to UEFI Shell. The different test applications can be run in following order:
Server Base System Architecture (SBSA) TAG: v21.10_REL3.1.1
UEFI Self Certification Tests (UEFI-SCT) TAG: f3b3456152dacf26ec0abaa0c21a9432cc176630 Note: UEFI-SCT is based on edk2-test release (tag:edk2-test-stable202108) which supports UEFI Specifications version 2.7 Refer to https://uefi.org/testtools for more details
Arm Enterprise ACS test suite may run at higher privilege level. An attacker may utilize these tests as a means to elevate privilege which can potentially reveal the platform security assets. To prevent the leakage of secure information, it is strongly recommended that the ACS test suite is run only on development platforms. If it is run on production systems, the system should be scrubbed after running the test suite.
Validating the compliance of certain PCIe rules defined in the BSA specification require the PCIe end-point generate specific stimulus during the runtime of the test. Examples of such stimulus are P2P, PASID, ATC, etc. The tests that requires these stimuli are grouped together in the exerciser module. The exerciser layer is an abstraction layer that enables the integration of hardware capable of generating such stimuli to the test framework. The details of the hardware or Verification IP which enable these exerciser tests platform specific and are beyond the scope of this document.
The Live image does not allow customizations, hence, the exerciser module is not included in the Live image. To enable exerciser tests for greater coverage of PCIe rules, please refer to SBSA Or contact your Arm representative for details.
Arm Enterprise ACS is distributed under Apache v2.0 License.
Copyright (c) 2018-2021, Arm Limited and Contributors. All rights reserved.