Arm SystemReady ACS

Important

This feature might not be applicable to all Platforms. Please check individual Platform pages, section Supported Features to confirm if this feature is listed as supported.

Arm SystemReady

Systems that are designed to just work for the end user with the ability to install and run generic, off-the-shelf operating systems out of the box, must follow a set of minimum hardware and firmware requirements.

For the Arm ecosystem, this requirement first surfaced in the server segment. The Arm ServerReady compliance certification program provides this ‘just works’ solution for servers, enabling confident deployment of Arm servers. The program is based on industry standards and is accompanied by a compliance test suite, and a process for certification.

For more information on the Arm SystemReady Certification Program, visit: Arm SystemReady

Arm SystemReady SR

Arm SystemReady SR is a band of system certification in the Arm SystemReady program.

SystemReady SR provides an interoperability framework and evaluation for Arm-based servers or workstations, uniting the ecosystem on a common foundation and enabling everyone to focus on differentiation and innovation. SystemReady SR ensures that Arm-based servers or workstations work out of the box, offering seamless interoperability with standard operating systems, hypervisors, and software.

SystemReady SR is designed for the Windows, Linux, VMware, and BSD environments on systems based on server or workstation Arm SoCs. SystemReady SR ensures standard firmware interfaces to deploy and maintain, reducing the cost of supporting multiple software versions. It also aims to support old operating systems to run on new hardware and vice versa, and targets generic off-the-shelf OSs.

SystemReady SR-compliant systems must conform to the:

The SystemReady SR certification and testing requirements are specified in the Arm SystemReady Requirements Specification (SRS).

SystemReady SR ACS

SystemReady SR ACS is the collection of code and scripts and an enhanced replacement of Arm Enterprise ACS repository.

The sections below describe how to build the software stack and execute the Architecture Compliance Suite (ACS) on Neoverse Reference Design platforms, using the prebuilt system-ready image.

For detailed instructions on how to build the system-ready image from source, refer to the github repository: SystemReady SR ACS

Build the platform software

Note

This section assumes the user has completed the chapter Getting Started and has a functional working environment.

The components of the RD platform software stack that are built are limited to those that provide the EFI implementation and the EFI shell (i.e, SCP, TF-A and EDK2).

To build the software stack, the command to be used is

  • If the target platform is SGI-575:

./build-scripts/sgi/build-test-acs.sh -p sgi575 <command>

  • If the target platform is a Reference Design (RD) platform:

./build-scripts/rdinfra/build-test-acs.sh -p <platform name> <command>

Supported command line options are listed below

  • <platform name>

  • <command>

    • Supported commands are

      • clean

      • build

      • package

      • all (all of the three above)

Examples of the build command are:

  • Command to clean, build and package the software stack needed for the ACS test on RD-N2 platform:

./build-scripts/rdinfra/build-test-acs.sh -p rdn2 all

  • Command to perform an incremental build of the software components included in the software stack for the RD-N2 platform.

./build-scripts/rdinfra/build-test-acs.sh -p rdn2 build

Note

This command should be followed by the package command to complete the preparation of the FIP and the disk image.

  • Command to package the previously built software stack and prepares the FIP and the disk image.

./build-scripts/rdinfra/build-test-acs.sh -p rdn2 package

Execute ACS Suite

Note

  • It is advised to use the latest prebuilt image if there is no specfic reason to build the disk image from source.

  • A new copy of the disk image shall be used every time the tests are to be executed, this ensures tests are not skipped due to presence of log files from the previous executions.

Prebuilt system-ready images are available to download here. After the download is complete, extract the image using:

xz -d sr_acs_live_image.img.xz

Commands to start the test are:

  • Set MODEL path before launching the model:

export MODEL=<absolute path to the platform FVP binary>

  • If the target platform is SGI-575:

cd model-scripts/sgi

  • If the target platform is a Reference Design (RD) platform

cd model-scripts/rdinfra

  • The actual test execution

./acs.sh -p <platform name> -v <path to sr_acs_live_image.img> -n [true|false] -a <additional_params>

Supported command line options are listed below

  • -p <platform name>

  • -v <absolute path to the sr_acs_live prebuilt image>

    • The absolute path to the sr_acs_live_image.img has to be supplied as the parameter.

  • -n [true|false] (optional)

    • Controls the use of network ports by the model. If network ports have to be enabled, use ‘true’ as the option. Default value is set to ‘false’.

  • -a <additional_params> (optional)

    • Specify any additional model parameters to be passed. The model parameters and the data to be passed to those parameters can be found in the FVP documentation.

Example:

  • Execute RD-N2 platform with networking enabled and additional parameter passed to the model. The ACS disk image located at /tmp/sr_acs_live_image.img.

./acs.sh -p rdn2 -v /tmp/sr_acs_live_image.img -n true -a "-C board.flash0.diagnostics=1"

The SBSA/SBBR tests are split into two phases - tests that execute from linux and the tests that execute from an EFI interface level.

Let the boot progress to the ‘Grub’ menu. To execute ACS test cases, choose the option ‘bbr/bsa’ from Grub menu, which will launch the EFI shell. Press ‘Enter’ key or wait till the timeout for the EFI startup script to run. The startup script will launch SBBR SCT test by default at first, skip the SCT test by pressing any key on the prompt ‘Press any key to stop the EFI SCT running’. This will start the SBSA UEFI test to start (if SCT is not skipped, the SBSA will run after completion of SCT).

On UEFI SBSA test completion, the startup script will reboot the platform, follow the same steps mentioned above till skipping SCT. This time SBSA UEFI test is not executed as the results are already captured in the sr_acs_live_image.img disk image and the validation OS starts boot. The Linux part of the test will be executed on validation OS boot complete.

On completion of the ACS SBSA and SBBR tests, the execution stops at the sr_acs_live_image filesystem command line prompt. The test can be stopped by terminating the FVP.

In case it is not required to run the complete ACS compliance, instead it is required to validate only the SBSA, the sr_acs_live_image.img has the provision. For this the SBSA test should be run from the EFI shell manually by executing the command listed below. This command skips the exerciser tests as well.

Shell> EFI\BOOT\bsa\sbsa\Sbsa.efi -skip 800

Running the test manually will not store the test result into sr_acs_live_image.img disk image, instead the test results will be available on console as the test proceeds to completion.

Select a SBSA compliance level (optional)

SBSA specification classifies hardware into different levels, level-3 through level-7. The ACS disk image is typically configured for a default level. For ACS disk image v3.0, the default SBSA level is 4. For running the ACS tests for any higher or lower level, press ESC from UEFI shell and run the SBSA efi binary manually to select the appropriate compliance level to be tested. An example of the command to be used to select the compliance level is listed below.

Shell> EFI\BOOT\bsa\sbsa\Sbsa.efi -l <y>

Here, y can be 3, 4, 5 or 6 for the SBSA compliance level.

Retrieve the test results

On completion of SBSA/SBBR tests, the test results can be retrieved by mounting the second partition of ACS test suite disk image that was used for the test.

mkdir /tmp/acs-disk
sudo mount -o loop,offset=537919488 sr_acs_live_image.img /tmp/acs-disk/

The test results can be found in the directories below:

  • UEFI SBSA test report: /tmp/acs-disk/acs_results/uefi/

  • Linux SBSA test report: /tmp/acs-disk/acs_results/linux/

  • FWTS result: /tmp/acs-disk/acs_results/fwts/

Unmount the disk after analysing the logs using the following commands.

losetup
sudo umount /dev/loop_x     # _x can be 0, 1, 2... based on losetup output