Arm SystemReady IR

Arm SystemReady is a compliance certification program based on a set of hardware and firmware standards that enable interoperability with generic off-the-shelf operating systems and hypervisors. These standards include the Base System Architecture (BSA) and Base Boot Requirements (BBR) specifications, and market-specific supplements.

In this way, the Arm SystemReady program provides a formal set of compute platform definitions to cover a range of systems from the cloud to IoT and edge, helping software ‘just work’ seamlessly across an ecosystem of Arm-based hardware.

Arm SystemReady is divided into a set of bands with a combination of specs available to suit the different devices and markets. Arm SystemReady IR is one of these bands.

Arm SystemReady IR certified platforms implement a minimum set of hardware and firmware features that an operating system can depend on to deploy the operating system image. Hence, Arm SystemReady IR ensures the deployment and maintenance of standard firmware interfaces and targets both custom (Yocto, OpenWRT, Buildroot) and pre-built (Debian, Fedora, SUSE) Linux distributions.

At a high level, the IR band requires that:

  • Hardware implements the Base System Architecture (BSA)

  • Firmware implements a subset of UEFI as defined in Embedded Base Boot Requirements (EBBR)

  • Firmware by default provides a device tree suitable for booting mainline Linux

  • Firmware can be updated using UEFI UpdateCapsule()

  • At least three Linux distros must be able to boot, install, and run storage medium tests using the UEFI boot flow

Compliant systems must conform to the:

It is also recommended to conform to the Security Interface Extension (SIE) certification. If that’s not possible, the following Base Boot Security Requirements (BBSR) rules are still required:

  • R140_BBSR: Capsule payloads for updating system firmware must be digitally signed

  • R150_BBSR: Before updates to system firmware are applied, images must be verified using digital signatures

Support in Arm Automotive Solutions

This Reference Software Stack aims to be aligned with Arm SystemReady IR version 2.1.0 by implementing most of its requirements. Given this is a reference design, the software is not being submitted for formal certification.

The support for running the Architectural Compliance Tests (ACS) is included in the Reference Software Stack. For more details on how to run it, refer to the Arm SystemReady IR Architecture Compliance Suite (ACS) Tests section of this documentation.

The Arm SystemReady scripts used to check the test results skip the identified non-alignments which are further described in the Identified Non-Alignments on RD-Kronos section below.

Identified Non-Alignments on RD-Kronos

The Reference Software Stack is currently known to have the following non-alignments:

  • Reference Software Stack

    • Kronos system does not support populating the list of runtime variables, which will lead to “Can’t populate EFI variables. No runtime variables will be available”.

    • Kronos system does not support verifying signed db/dbx update, which will lead to “SecureBoot - Verify signed db/dbx update” test failures in SIE.

    • Kronos system does not support querying authenticated variables, which will lead to “RT.QueryVariableInfo - Query Auth Variable” test failures in SIE.

    • Kronos system does not support time base authenticated variables, which will lead to a “RT.SetVariable” test failure in SIE.

  • Devicetree

    • Missing schemas for components which have not yet been or are not appropriate to be upstreamed (arm,rd1-ae, arm,neoverse-v3ae, arm,mpam-msc, arm,slc, arm,si-channel, arm,si-rproc).

  • U-Boot

  • Model - FVP

  • Test environment

    • No text input is available in the test environment for Simple Text Input Ex protocol.

  • BSA tests

    • Tests are not compatible with certain devices in the RD-Kronos model.

Arm SystemReady IR Tests

Arm SystemReady IR ACS Tests

The Arm SystemReady ACS (Architecture Compliance Suite) is a set of tests that ensure architectural compliance across different implementations and variants of the architecture. The ACS is delivered as a prebuilt release image. The image is a bootable live OS image containing a collection of test suites.

The ACS includes 2 optional SIE subsets:

This Reference Software Stack supports running the SCT subset to cover the testing on authenticated variables, Secure Boot variables, and Secure Boot image loading.

The meta-arm-systemready/classes/arm-systemready-acs.bbclass class in the meta-arm-systemready Yocto layer contains the common logic to deploy the Arm SystemReady IR ACS version 2.1.0 pre-built image and set up the testimage environment. It also contains a testimage “postfunc” called acs_logs_handle which generates report files and checks the results.

The script meta-arm-systemready/lib/oeqa/runtime/cases/arm_systemready_ir_acs.py in the meta-arm-systemready Yocto layer monitors the ACS tests output from the bitbake testimage task.

The script yocto/meta-arm-bsp-extras/lib/oeqa/runtime/cases/arm_systemready_ir_acs_capsule_update.py automates the capsule update test. It covers the test of signed capsule, unsigned capsule and tampered capsule.

See meta-arm-systemready/README.md for more details. To run the tests, refer to Arm SystemReady IR Architecture Compliance Suite (ACS) Tests.

Linux Distributions Installation Tests

The Arm SystemReady IR requires that at least three Linux distros must be able to boot and install using the UEFI boot flow.

Recipes for testing the installation of Linux distributions are provided under meta-arm-systemready/recipes-test/arm-systemready-linux-distros. These recipes help to download the installation CD for the Linux distribution and generate an empty disk as the target disk for the installation.

See meta-arm-systemready/README.md for more details. To run the tests, refer to Linux Distribution Installation (Debian, openSUSE and Fedora).