The folks at ARM offer a certification program based on a set of hardware and firmware standards: the Base System Architecture (BSA), and Base Boot Requirements (BBR) specifications, plus a selection of supplemental standards. Termed Arm SystemReady, these standards ensure Arm-based computer systems of all types and form-factors are designed to specific requirements, enabling operating systems to boot and "just work" right out of the box, no customization required.

Some context: in earlier times in the history of ARM processor architecture, there was a great proliferation of implementations, each unique, and therefore requiring a unique firmware image and OS image.  A Linux image built for a Raspberry Pi computer, for example, would not boot on a BeagleBone.  With the great proliferation of single-board computers (SBCs), it is crazy-inefficient for the Linux distros to have to create a unique OS image (including a custom kernel) for every SBC on the market.  Add to that the need to securely update and otherwise maintain an ever-growing collection of board-unique firmware/OS images—such a situation is not scalable.

ARM has been rectifying the situation over the last ~seven years by creating a series of specification documents that aim to define hardware requirements and a common firmware/OS interface.  The initiative began with ARM-based servers, and recently has been extended to include ARM-based embedded systems.

Arm SystemReady

Arm SystemReady is defined by four different "bands":
  1. Arm SystemReady SR (ServerReady)
    • ensures that ARM-based servers work out of the box, offering seamless interoperability with standard operating systems, hypervisors, and software
  2. Arm SystemReady LS (LinuxBoot Server)
    • ensures that a server platform is suitable for deployment on the LinuxBoot firmware stack
  3. Arm SystemReady ES - Embedded Server
    • ensures interoperability with standard operating systems and hypervisors
  4. Arm SystemReady IR - IoT
    • for devices in the IoT edge sector that are built around SoCs based on the ARM A-profile architecture; ensures interoperability with embedded Linux and other embedded operating systems.

The preceding chart defines the bands and the specifications applicable to each.  As you can see, each band combines a set of required specifications, each set applicable to a particular application/form-factor.

The Inventory of Specifications

There are quite a few—here they are:
Rather than inventing new technologies, the goal of specifications like BBR/EBBR is to encourage ARM customers to craft ARM-based products that embrace popular industry standards (e.g. UEFI, ACPI, DeviceTree, U-Boot) in an agreed-upon way.  For example, EBBR requires that hardware/firmware provide a method of self-description for consumption by the OS; but rather than define a new method, EBBR says that implementations should choose either ACPI or DeviceTree.

Once implemented in EBBR-compliant bootloaders like  U-boot or Tianocore/EDK2, this initiative should allow a single version of an OS image (e.g. RHEL/Fedora, Debian/Ubuntu, et. al.) to boot on any ARM-based SBC without the per-platform customization traditionally required.

There is also a compliance test suite, called Arm SystemReady ACS, where "ACS" stands for Architecture Compliance Suite.  More information here:  BBR-ACS.


Hopefully this article serves as a comprehensive overview of what Arm SystemReady is all about.  Please dig into the various specifications (linked above) for more information.  Also, following are some references I've found helpful:

Arm SystemReady and the UEFI Firmware Ecosystem

A UEFI Plugfest presentation by Dong Wei and Samer El-Haj-Mahmoud of ARM:

A real ARM customer (NXP) making Arm SystemReady-compliant devices:

Grant Likely (ARM Ltd.) discussing EBBR at the Embedded Linux Conference in 2018:

Dong Wei discussing SystemReady at the UEFI Fall 2023 Developer's Conference:

Post a Comment

Be sure to select an account profile (e.g. Google, OpenID, etc.) before typing your comment!