Arm announced the SystemReady certification program at Dev Summit in October 2020, as part of the Project Cassini initiative for Edge and IoT, and supported by a broad set of partners from across the data center ecosystem. SystemReady 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 a vibrant, diverse ecosystem of Arm-based hardware. It delivers a foundational certification program and we now report on the tremendous progress made during the last year.SystemReady is divided into a set of bands with a combination of specs available to suit the different devices and markets.
SystemReady SR is tailored to meet the needs of Windows, VMware, Linux, and BSD OSes on server or workstation Arm SoCs. It ensures the deployment and maintenance of standard firmware interfaces. The SR band targets generic off-the-shelf OSes supporting old OSes to run on new hardware and vice versa.
SystemReady ES is designed to meet the needs of Windows, VMware, Linux, and BSD OSes on embedded Arm SoCs. It ensures the deployment and maintenance of standard firmware interfaces. The ES band targets generic off-the-shelf OSes supporting old OSes to run on new hardware and vice versa.
SystemReady IR is tailored to meet the needs of Linux and BSD OSes on embedded Arm SoCs. These SoCs are supported by the mainline Linux. It ensures the deployment and maintenance of standard firmware interfaces and targets both custom (Yocto, OpenWRT, buildroot) and pre-build (Debian, Fedora, SUSE). Find out more about SystemReady IR in this blog.
SystemReady LS is tailored to meet the needs of using LinuxBoot firmware on server Arm SoCs. It ensures the deployment and maintenance of standard firmware interfaces and targets the Linux environment for hyperscalers. We are working with our partners on defining the requirements for this band.
Underpinning the Arm SystemReady program is a new set of system architecture standards. In particular, the Base System Architecture (BSA) which provides a minimum set of hardware requirements for an operating system to boot successfully. The corresponding minimum set of firmware interface requirements is called the Base Boot Requirements (BBR). We also provide a market segment specific BSA supplement, for example, the SBSA supplement for the server sector. Choosing different combinations, or recipes, of these specifications enable different bands of the SystemReady program, applicable to different system types and market segments. In addition, the Base Boot Security Requirements (BBSR) specification which provides the requirements for secure boot and secure firmware update.
We are working with partners on the CXL on Arm Integration and Design document to provide guidance on building SoCs that present CXL-compliant system and boot requirements to generic off-the-shelf OSes. This will be the precursor to the CXL requirements in future SBSA and BBR specifications.
These specifications are developed with our partners in the System Architecture Advisory Committee. This includes over 50 companies made up of silicon providers, OS vendors, IP providers, OEMs, ODMs, independent firmware vendors, IHVs, ISVs, and cloud service providers.
In addition, the SystemReady Requirements Specification documents the requirements of the certification for each of the SystemReady bands. This specification also defines the certification waiver policies and certification processes. We intend to update this specification on a semiannual basis in April and October.
The Enterprise Architecture Compliance Suite (ACS) was designed for testing server compliance to the BSA/SBSA specifications and the SBBR recipe in the BBR specification. It is still used for certifying servers and workstations for SystemReady SR. In addition, a new SystemReady ACS is now available for certifying devices for SystemReady IR and ES. Eventually, this new ACS will also cover SystemReady SR certification.
Please note we are still working on defining the LBBR recipe in the BBR specification and the requirements for the SystemReady LS band in the SystemReady Requirements Specification.
The biggest issue we face is that none are compliant to the PCI Express Enhanced Configuration Access Mechanism (ECAM) for use by the OSes to enumerate the PCI Express devices. Unless the per-SoC quirk is supported by the mainline Linux or other OSes, our vision of enabling software to just work would not be possible. As a result, Arm has worked with partners to create the Arm PCI Express Configuration Space Access Firmware Interface specification. This provides standard (permitted by the PCI Express Base Specification) SMC interfaces for PCI Express Configuration Space Access for these SoCs not able to support ECAM. Arm has developed patches for the Raspberry Pi 4 device in Trusted Firmware-A and tianocore EDK2 as well as Linux kernel to support these SMC interfaces. VMware and NetBSD are now supporting these SMC interfaces.
“We are excited to support the Arm SystemReady ecosystem and are working closely with Arm and the Arm community to drive greater standardization across non-server Arm platforms. It is for this reason we support the Arm PCIe Config Space Access Firmware interface spec to better support these devices.” Kit Colbert, CTO, VMware Cloud.
UART is another major issue. Both Arm Generic UART and 16550 UART are BSA-compliant, but currently the safest choice is the former (for example, PL011). We have not yet found any SoC integration of third-party IP that is fully 16550 compliant.
Other issues include wakeup timer, watchdog timer, USB host controller, interrupt controller and MSI support. The best way to address these issues is through pre-silicon compliance testing.
Arm SystemReady pre-silicon compliance testing is key for designing a BSA - and therefore SystemReady - compliant SoC. The pre-silicon program is a part of the SystemReady journey, not an option, or certification in its own right. It enables silicon partners to design BSA-compliant SoCs and have a well-defined and low-risk path to becoming SystemReady once they are manufactured.
Arm has strengthened the collaboration with EDAs such as Cadence and Synopsys to integrate the compliance tests into various pre-silicon environments. We are now engaging with a limited number of initial partners to test chips before spin-out, reducing risk and cost, and are planning a wider commercial roll-out.
Arm SystemReady offers a Security Interface Extension (SIE) which provides a way to certify that secure boot and secure firmware update are implemented correctly, as prescribed by the Base Boot Security Requirements (BBSR) specification. As we have now released the ACS for BBSR, we can start the process of certifying systems for SystemReady SIE. The SIE can be followed alongside the SystemReady IR, ES and SR bands, or followed as a standalone if certification under these bands has already been achieved.
When we announced the Arm SystemReady program last October, we launched with the two initial systems certified: Ampere Mt Jade platform for SystemReady SR and Raspberry Pi 4 model B for SystemReady ES.
Throughout this year, we have been working with many partners and are proud to have certified twenty-six new systems under all three available SystemReady bands as follows:
In addition, since the ACS test suite for SystemReady IR became available earlier this year, we are now certifying the first systems under SystemReady IR. In the last four months, we have worked closely with partners and are proud to have certified the following devices under the IR band:
We are delighted with this achievement, made possible by the strong support we have received across the industry and throughout our ecosystem. We have many more devices in the pipeline working towards certification. We are also in the process of onboarding a set of test labs to expand the certification process.
In conclusion, Arm is very proud to be working with an ambitious ecosystem to drive forward the rapidly expanding Arm SystemReady certification program, based on underlying architecture standards. The BSA provides a minimum set of hardware requirements for an operating system to boot successfully, while the BBR provides the corresponding minimum set of firmware interface requirements. In addition, we are providing system-specific standards enabling a set of bands for compliance certification from cloud to edge under the program.
Since introducing the program last year, we have made huge progress, releasing the ACS for the IR band and thus starting IR certification, (see the blog Simplifying Embedded Linux with SystemReady IR), updating the BBSR Specification and the Security Interface Extension, defining the pre-silicon compliance aspect of the program and, most importantly, certifying more than twenty devices under all three bands, now proudly sporting the SystemReady certification stamp and listed on our partner section of the website.
For the future, we now plan to start certification of the Security Interface Extension for those devices including secure boot and firmware update.
Arm SystemReady is part of the Project Cassini initiative for the edge and IoT sector, aiming to create a seamless cloud native experience with standards, security, and reference implementations as the three key pillars. It is also the foundation of the recently announced SOAFEE initiative for the automotive market.
You can find out more about SystemReady on our website.