Standards in Arm space (part III)

This post is part 3 of the "Standards in Arm Space" series:

  1. Standards in Arm space (part I)
  2. Standards in Arm space (part II)
  3. Standards in Arm space (part III)
  4. U-Boot and generic distro boot

In the first part I went from board files and ugly bootloaders to SBSA/SBBR and EBBR. The second part went through BSA, BBR etc. TLAs and what changes they brought into OFLAs.

And both were about specifications written for developers (both hardware and software). This time I will write something about ones written for marketing people.


Who is gonna remember all those acronyms and what they mean? Only those who really have to. Rest of people needs something easier to remember.


Design a System that “Just Works”

In 2018 Arm brought ServerReady program. Name sounds much better than “hardware needs to comply with SBSA and firmware has to be SBBR compliant”, right? Ah, and “has to pass ACS” (which stands for Architectural Compliance Suite).

Yeah — one simple name instead of three acronyms. So imagine situation when you need to convince your boss that project needs a serious AArch64 machine for Continuous Integration builds. You can say “We buy XYZ because it is a Server Ready system” and they assume that it is a server so IT should be able to handle it.

Try to say “we buy XYZ because it is SBSA and SBBR compliant and passes ACS” and you can get asked about your mental health…


But not every AArch64 system is server class hardware. Or needs what whole UEFI, ACPI etc. things in firmware.

So in 2020 Arm came with SystemReady program. It is basically ServerReady renamed and extended to cover wider selection of hardware and firmware options.

It came around same time as BSA, BBR, LBBR etc. which I described in the second part already so will not repeat what those acronyms mean.

certification bands

There are four ‘bands’ defined:

Certification Description hardware specs firmware spec
SystemReady SR ServerReady BSA + SBSA SBBR
SystemReady ES Embedded Server (*) BSA SBBR
SystemReady IR IoT Ready BSA EBBR
SystemReady LS LinuxBoot ServerReady BSA + SBSA LBBR

*) spec says “Embedded ServerReady” but it is probably an error as it was also mentioned as “Embedded Server” in few places outside of specification.

What that means for developers?

Certification hardware type usual firmware
SystemReady SR server class UEFI + ACPI
SystemReady ES some SBC UEFI + ACPI
SystemReady IR some SBC (UEFI or U-Boot) + DTB
SystemReady LS server class LinuxBoot

Where UEFI means Tianocore EDK2 or similar. And U-Boot needs EFI layer enabled (to fulfill EBBR requirements).


SystemReady specification says that SR systems are also ES compliant. There is no need for recertification if someone wants to put other sticker.

There are changes in progress. One of them is Devicetree requirement for IR band. So not every ES will be compliant with IR unless firmware be changed.

BTW — specification mentions 32-bit systems. But IoT Ready only as they are not covered by BSA.


Creation of ServerReady and later SystemReady specifications was good move. We got simple name which can be understood by mere mortals.

Developers and other interested people can go deeper and read about BSA, BBR, EBBR, LBBR, SBBR, SBSA and other TLAs and OFLAs.

aarch64 arm development