ARM, SBSA, UEFI, and ACPI

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

For some years now we have been promised that ARM-based servers were going to start showing up in data centers. Opinions differ on whether ARM processors can be successful in this market, but there tends to be widespread agreement on a related point: the free-form, highly differentiated nature of ARM-based systems would make them painful to support in large, server-oriented environments, where users expect to be able to treat servers like interchangeable parts. ARM Ltd. clearly understands this problem; its recently announced "Server Base System Architecture" (SBSA) is an attempt to improve the situation. SBSA has been greeted with generally optimistic reviews, but the requirements that are coming along for the ride may yet stir things up in the development community.

In truth, it can be hard to say for sure what the SBSA mandates; the standard is currently kept behind a restrictive license, limiting the number of people who have read it. Arnd Bergmann described it this way (in the comments):

SBSA describes various hardware components that are required for a compliant server. Things like CPU, PCIe, timers, IOMMU, UART, watchdog, and interrupts are described in enough detail that it should be possible to take a compliant OS image and boot to the stage where you can load drivers for all other components that are not standardized...

Arnd went on to describe the requirements as "extremely reasonable." Olof Johansson, one of the maintainers of the arm-soc kernel tree, was also supportive of the idea:

It is an incredibly important document, because it does away with so much of the variables where ARM vendors in the past have chosen to differentiate between each other for no useful purpose. It allows us to write software that is much simpler, and that has a better chance to work across a large range of hardware with very small changes made over time.

In short, the SBSA is trying to create a base platform that can be assumed to be present as part of any compliant system. ARM has always lacked that platform, which is part of why supporting ARM systems has traditionally been a messy affair. To the extent that the SBSA succeeds, it will make life easier for kernel developers, hardware manufacturers, and server administrators; it is hard to be upset about that.

Nonetheless, the SBSA announcement has stirred up some heated discussion in the community. But the SBSA is mostly guilty by association; the controversial part of the platform is the firmware requirements, which are not addressed by the SBSA at all. Instead, these requirements will be released as part of a separate specification. The details of that specification are not known, but it has been made clear that it will mandate the use of both UEFI and ACPI on compliant systems.

UEFI is the low-level firmware found on most current PC systems. Like any firmware, UEFI has caused its share of misery, but, for the most part, developers are fine with its use in this context. UEFI works well enough, it has an open-source reference implementation, and supporting UEFI is not hard for the kernel to do. So there is no real opposition to the idea of supporting UEFI on ARM systems.

ACPI (the "Advanced Configuration and Power Interface") is another story. Getting ACPI working solidly on x86 systems was a long and painful process. Its detractors cite a few reasons to believe that it could be just as bad — if not worse — in the ARM world. For example, most ARM system-on-chip (SoC) vendors currently have no experience with ACPI, so they are going to have to come up to speed quickly, repeating lots of mistakes on the way. Each one of those mistakes is likely to find its way into deployed systems, meaning that the kernel would have to support them indefinitely.

There are also concerns about how well an ACPI-based ARM platform will come together. In the PC world, it became clear fairly quickly that the specification only meant so much when it came to hardware support. The real acid test was not compliance with a spec; instead, it was the simple question of "does Windows run on it?" Once Windows worked, firmware authors tended to stop fixing things. That led to numerous situations where the Linux kernel has to carefully do things exactly as Windows does, since that's the only well-tested mode of operation. Windows compatibility is not the most satisfying compliance test out there, but it did result in ACPI implementations converging sufficiently to allow them to be supported in a generic manner.

Windows does not have the same dominating position in the ARM server market; indeed, it's not clear that Windows will be offered on such systems at all. It is certainly possible that, say, Red Hat Enterprise Linux could play a similar role in this space. But it's also possible that vendors will just try to push lots of patches into the kernel to support their specific ACPI implementations. The result could be an incompatible, bug-ridden mess that takes many years to settle out.

Finally, there is the question of whether ACPI is needed at all. ACPI is, in the end, a standardized way to enable the operating system to discover and initialize the system's hardware. But, ACPI critics point out, the ARM architecture already has such a mechanism: device trees. The device tree work is reaching a point where it is reasonably mature; as Olof recently noted in a pull request to Linus:

New boards and systems continue to come in as new devicetree files that don't require corresponding C changes any more, which is indicating that the system is starting to work fairly well.

The developers who have been working on getting this system working well are now asking: why should that work be pushed aside in favor of a PC standard with no history in the ARM world? Among certain developers one can easily pick up a feeling that the kernel should simply refuse ARM ACPI support and mandate the use of device trees on all ARM systems.

In the end, it is hard to see any such thing happening; Linux kernel development has almost always been done in such a way as to favor running on as many systems as possible. And there may well be technical reasons for favoring ACPI on some systems, especially in situations where strict compatibility has to be maintained for years. As Grant Likely put it in a lengthy posting about the upcoming firmware standards, ACPI can make it easier for manufacturers to keep things compatible:

To begin with they already have hardware and process built around ACPI descriptions. Platform management tools are integrated with ACPI and they want to use the same technology between their x86 and ARM product offerings. They also go to great lengths to ensure that existing OS releases will boot on their hardware without patches to the kernel. Using ACPI allows them limited control over low level details of the platform so that they can abstract away differences between systems.

As Grant points out, that abstraction runs counter to the way things have traditionally been done on ARM-based systems; normal practice is to go through a great deal of pin configuration, regulator setup, clock programming, and more just to get things into an operational state. ACPI pushes a lot of that work into the firmware, taking it out of kernel developers' hands. That, perhaps, is where some of the resistance comes from: kernel developers like that control and are reluctant to cede it to firmware authors. It just doesn't feel right if you don't have to establish the right pinmux configuration before anything will work.

Still, ARM servers with ACPI are coming, and the kernel will almost certainly support them. The kernel will also, of course, continue to support device-tree-based systems; the chances of ACPI moving into the embedded world in the near future seem relatively small. After a while, ACPI on ARM will just be another configuration supported by the kernel, and people will be wondering why it was ever controversial. But "a while" may turn out to be a longer period of time than some people expect.

