ARM has publicly released the Server Base Boot Requirements (SBBR) Specification, a follow-on companion to the Server Base System Architecture (SBSA) specification. The SBBR defines the ARMv8 platform firmware abstractions necessary for OS deployment and boot, HW configuration and management, and power control of SBSA compliant systems with the intention of supporting today’s prevalent server OS’s.
When ARM announced the Server Base System Architecture (SBSA) specification this past January, it was the culmination of over 3 years of ARM and ARM partner discussions and collaboration around the goal of being able to deliver an industry standard server platform. Being an industry standard platform runs orthogonal to the ARM ecosystem’s broad direction of embedded platform applications, but is an absolute must if ARM partners are to successfully design and market data-center servers. Being an industry standard platform maximizes customer OS choice as it minimizes new product development cycles in the OS kernel. Providing an industry standard server platform enables heterogeneous datacenters where the end-users software and OS of choice can run side by side on both ARM-based servers as well as legacy server hardware.
Another key factor that I’d like to highlight in regards to the SBSA Specifications is the industry-wide guidance and collaboration that has gone into aiding ARM’s technologists in authoring these standards. Partners, such as RedHat, have trumpeted the call for standards and best practices for server platforms:
"We are excited to help drive various server standardization efforts around the ARM Architecture, in particular the SBBR, which we deem critical to the commercial success of ARM in the Enterprise", said Jon Masters, Chief ARM Architect at Red Hat. “Together with other ecosystem partners and Operating System vendors, we have built a strong foundation for a common ARM server platform".
In short, ARM’s new SBBR specification is a key standard to providing innovative, best-fit datacenter solutions based on the ARMv8 architecture.
What’s in a Name? What’s in the SBBR Spec?
First off, the Server Base Boot Requirements specification covers much more than just “Boot” support. It leverages (and in the process, often extends) the existing, prevalent firmware standards as the specific contact (or should I say contract?) points between the OS and the platform hardware. Let’s take a closer look at what is in the spec:
UEFI Boot Support – SBBR leverages the UEFI 2.4 standard and the UEFI Forum’s governance model for extending the UEFI spec as needed to enable UEFI Boot mechanism on ARM-based systems. UEFI covers both boot-time and minimal run-time interfaces as well as memory maps and pointers to other abstractions such as ACPI and SMBIOS.
ACPI Support – SBBR leverages the long running yet newly minted ACPI specification, which was very recently updated to ACPI 5.1 by the UEFI Forum. ACPI describes the tables and methods used to configure platform hardware, drive system and device power states, as well as describe the hardware functionality present for the OS. The SBBR spec spells out the ACPI structures, tables, and methods necessary for describing the server hardware to the OS. The ACPI 5.1 is publicly available and includes support of ARM-based platforms.
Please go here for further details on UEFI and ACPI 5.1: Specifications | Unified Extensible Firmware Interface Forum
SMBIOS Support – SBBR lists the common SMBIOS table structures and records required for server deployment and platform asset management.
Multiprocessor Support – SBBR covers two possible methods for the booting of additional symmetric application processor cores within a single ARM platform.
First, the recommended PSCI method that is further detailed in the ACPI spec, and second, the older MP Parking protocol that was originally cooked up by Microsoft in their work supporting ARM-based devices.
Leaving Legacy Behind
One item to note is the lack of “legacy” platform requirements. Starting clean, with modern server designs in mind for an ARM Server platform has both advantages and disadvantages. While there is a great deal of work being done up front in specifications and coding, the ARM ecosystem isn’t hindered by the inclusion of legacy HW, firmware, and OS baggage. The firmware in an ARM server does not include legacy BIOS API’s. The SOC hardware does not include legacy IO address ranges nor does it include interrupt controllers first mapped out by the IBM PC back in the early 1980’s. Not being tied to legacy implementations reduces cost and complexity of ARM-based SOC’s while also allowing for greater flexibility and innovation, which brings us back to the need for clearly defined abstractions, which are keenly delivered here in the SBBR Specification.
While we won’t be supporting MS-DOS here, we are laying the groundwork for support of your favorite server OS.
For further reading, the SBBR spec is publicly available here: