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":
- Arm SystemReady SR (ServerReady)
- ensures that ARM-based servers work out of the box, offering seamless interoperability with standard operating systems, hypervisors, and software
- Arm SystemReady LS (LinuxBoot Server)
- ensures that a server platform is suitable for deployment on the LinuxBoot firmware stack
- Arm SystemReady ES - Embedded Server
- ensures interoperability with standard operating systems and hypervisors
- 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:
- Arm SystemReady Requirements specification
- Arm Base System Architecture specification (BSA)
- Arm Base Boot Requirements specification (BBR)
- Arm Server Base System Architecture supplement specification (SBSA)
- Arm Embedded Base Boot Requirements specification (EBBR)
- Arm Base Boot Security Requirements specification (BBSR)
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.
References
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: https://www.brighttalk.com/webcast/18206/460753
Post a Comment
Be sure to select an account profile (e.g. Google, OpenID, etc.) before typing your comment!