ARM, Servers and the Shrink-Wrap OS

ARM just released the Server Base Boot Requirements document (more info here) which "defines the ARMv8 platform firmware abstractions necessary for OS deployment and boot, HW configuration and management, and power control" for servers that follow their SBSA specification. This is an important step so that OS vendors, like Red Hat and Microsoft, can produce "standard" operating systems distributions that work on any SBBR-compliant system.

What do you need to boot? Well, first of all, the operating system needs to detect all of the undetectable devices on the platform without a lot of poking and probing. That's because the standard OS image can only support a limited number of interrupt controllers, CPU memory management schemes, and high-resolution timers. So its a good idea if everyone can agree on a standard hardware architecture for these devices or, if not, a standard abstraction for how to talk to them. You don't want to use kernel configuration files, because that requires that the OS image is not the "standard" OS image, but rather one which has been modified for a specific SoC or specific board. So SBBR recommends the new ACPI 5.1 specification. People may not remember this, but one of the things that ACPI does (the "Configuration" part of the acronym) is provide a way to describe the hardware resources (memory, I/O, IRQ, DMA, etc.) used by non-enumerable devices and providing an identifier that the OS can use to load a specific device. The ACPI 5.1 specification did a few tweaks to that basic model for new ARM devices, but the same ideas are still valid.

Next, the operating system needs to be able to talk to the boot device long enough for it to be able to get its own drivers loaded. It is a sort of contract where the firmware finds the OS loader, validates it, and then jumps into it. But that OS loader then needs to load other files. Now it can try to put everything into a massive super-loader that can handle every device known to man or woman, or it can ask the firmware to read those files. That's why SBBR recommends UEFI 2.4, because UEFI has a well-defined mechanism for handing off control to OS loaders, loading files and then cleanly handing over control of devices to an OS driver.

How does the OS find out more information about the platform? Manufacturer name? DIMM types? Platform UUID? SBBR recommends the SMBIOS specification, version 2.8.0, published by the DMTF , which "addresses how motherboard and system vendors present management information about their products in a standard format" (see DSP0134).

Finally, ARM CPU cores can be arranged in a bewildering array of topologies, with an amazing variety of power states, can be described by the PSCI interface (from ARM and ACPI). This interface allows the interface to manage the tricky business of manipulating individual cores and managing the dependencies between them.

All of these work together to support the shrink-wrap experience. The goal: one DVD or one OS image can boot the system enough to get to the net and download any other updated or missing pieces. So standards that provide the pieces so that I can get my system to that point based on the information built into the firmware make everyone's job easier.

UEFI Forum releases the ACPI 5.1 Specification

For years, the ACPI specification was developed by what was essentially a 5-way tangle of an IP agreement between Microsoft, Intel, Toshiba, Phoenix and HP. It was a closed group with no simple way for new ideas and direction from outside.

After ACPI 5.0 was released, it became clear that if ACPI were going to have wider industry adoption, it would need to open up to a different sort of development process. At the UEFI board meetings (when I was with Phoenix), I saw most of the same companies and most of the same people as with ACPI. After much discussion between companies with large contingents of lawyers, the UEFI Forum took over management of ACPI and the UEFI board created the ASWG (ACPI Specification Working Group) to manage ACPI's development.

One of the first challenges after this change in management was to clean up the ACPI specification and make it more ARM AArch64 friendly. ACPI 5.0 had already paved the way with the Hardware-Reduced profile, removing many of the assumptions about hardware registers, processor states and bus hierarchies . These had been driven to some extent by Microsoft when Windows RT was on the horizon. For a description of the ACPI-related changes made by Linaro and other ARM partners, see this summary. Linaro has been very active in submitting kernel patch after kernel patch to modify the X86-only flavor of some of the Linux kernel pieces.

Now, with the release of the new ACPI 5.1 specification in a timely fashion, the remaining bits that didn't fit have been cleared away. There is still more work to be done, but at least Linux, ACPI an ARM have a clear path forward, both in terms of technology and open specification governance.