This post is part 3 of the "Standards in Arm Space" series:
- Standards in Arm space (part I)
- Standards in Arm space (part II)
- Standards in Arm space (part III)
- 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.
SBSA, SBBR, EBBR, LBBR etc
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.
ServerReady
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…
SystemReady
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).
recertification
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.
Conclusion
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.