Marcin Juszkiewicz

This post is part 2 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. Now let me try to explain how it evolve.

BSA, BBR?

During Arm DevSummit 2020 there was announcement of new standards for Arm devices:

Arm is extending the system architecture standards compliance from servers to other segments of the market, edge and IoT. We introduce the new BSA specification with market segment-specific supplements and provide the operating system-oriented boot requirements recipes in the new BBR specification.

BSA is meant to describe basic recommendations and requirements for hardware. Just like SBSA did it for servers before, BBR covers booting.

BSA

Base System Architecture specifies hardware that software can rely on. Compliance is not required:

Arm does not mandate compliance to this specification. However, Arm anticipates that OEMs, ODMs, cloud service providers and software providers will require compliance to maximize Out of Box software compatibility and reliability.

According to BSA 1.0 (DEN0094A document) there are two supplements:

• Server Base System Architecture (SBSA)
• Client Base System Architecture (CBSA)

Former is described in separate document (DEN0029E) covering AArch64 server requirements (look for spec v6.1+) while latter document (DEN0087) is not yet present on Arm developer website (I was told that you need to contact Arm for a copy).

SBSA changes

There are some interesting changes in specification. For example there is a table with hardware requirements for each SBSA level:

Previous (v6) version of SBSA specification mentioned that all PEs (cpu cores) must implement XYZ introduced in Armv8.y version (I selected just a few):

So level 4 is now v8.3+ from v8.2+ before.

Most of hardware requirements descriptions moved from SBSA to BSA. Due to this SBSA v6.1 spec is just 25 pages while SBSA v6.0 had 83 of them.

BSA and SBSA checklists

Both BSA and SBSA have now section with checklist. This allows to quickly check which components are required for ‘minimum BSA’ and each SBSA level.

Funny part is when you compare ‘minimum BSA’ with SBSA level 3 — latter one lists operating system requirements up to B_PE_14 while former goes to B_PE_17. At beginning it feels like mistake but B_PE_15 to B_PE_17 describe optional parts (_15 is part of Armv8.3 so SBSA level 4+ and _16 and _17 are required for SBSA level 6).

And the reason for above is backward compatibility. SBSA levels are defined as “previous one + some extras” so they can not be rebased on top of BSA. I wonder how it looks on CBSA.

BBR

Base Boot Requirements specifies firmware requirements to make booting easy and predictable.

BBR specification is highly based on SBBR one. It is visible in document number (DEN0044) as A-E versions were SBBR, from F it is BBR.

According to BBR 1.0 (DEN0044F document) there are four recipes:

• SBBR for servers
• ESBBR which is SBBR with some potential exceptions (none are defined so far)
• EBBR for those who can not into SBBR
• LBBR for LinuxBoot based systems

ESBBR?

So what for ESBBR was invented when it is the same as SBBR? Probably those so called “Edge” devices — nearly server class hardware but something went wrong or vendor was lazy to go for full SBBR.

LBBR?

LBBR stands for LinuxBoot BBR — systems where machine has very minimal firmware just to run Linux which initialize everything and then use kexec system calls to load final kernel image. Used by some datacenters that are compliant with the Open Compute Project (OCP).

In theory LBBR system can load UEFI instead of kernel and be SBBR compliant.

Required components

Each recipe has own list of required components:

*) EBBR system must provide ACPI or DeviceTree — both at same time are not allowed.

SBBR changes

SBBR 6.0 specification required SBSA hardware:

This document defines the Boot and Runtime Services expected by an enterprise platform Operating System or hypervisor, for an SBSA-compliant Arm AArch64 server which follows the UEFI and ACPI specifications.

In BBR 1.0 spec this requirement got wiped out:

Systems using SBBR recipe must meet the requirements that are specified in section 5 (PSCI/SMCCC), section 6 (Secondary Core Boot), section 7 (UEFI), section 8 (ACPI), and section 9 (SMBIOS).

SBBR-compliant systems must not present a DeviceTree binary to the operating system.

Now any device can be made ‘SBBR compliant’. SBSA requirement got moved to SystemReady specification but this is material for other post.

Secure and Trusted Boot

SBBR v1.2 spec (DEN0044E document) had “Secure and Trusted Boot” subsection in UEFI section. It was removed from BBR 1.0 version.

The reason is simple — it has own specification now: “Base Boot Security Requirements (BBSR)” (DEN0107 document) with more details in it. There will be separate test suite and certificate program for it.

Conclusion

BSA/BBR feel a bit like cleaning process. Non-server hardware was not defined before so now BSA kind of does that. Several extensions from v8.5 are required to cover all those mitigation issues. Too bad that CBSA was not released at same time as BSA…

Embedded devices did not got updated specification yet. EBBR 1.0.1 is from August 2020 and does not even mention BBR. I would see it as part of BBR specification but was told that it is handled by other team so have to stay separate.

Servers are like they were before — SBSA + SBBR cover like before. Unless you want Secure Boot as this is no longer defined. And for some server-like machines there is ESBBR allowing to make some exceptions (once they got defined).

Several datacenter servers got own part with LBBR. Normal users would not even play with them so nothing to worry for them.