Why ARM Servers Use ACPI? ACPI vs DeviceTree

Recently, apart from the rampant news about the COVID-19 pandemic, the most attention-grabbing topic has undoubtedly been the war in Ukraine. Contrary to most people’s expectations, the war, which was thought to be one-sided, has become prolonged, much like the “temporary” lockdown in Shanghai — endless. Regardless of the outcome, this war has exposed the technological weaknesses of the former superpower, and with the assistance of high-tech weapons and information warfare from the United States and Europe, the Russian military has not only failed to sweep through, but has instead fallen into a passive position as time progresses. For China, which seems to be an outsider, this “special military operation” is, to some extent, a good thing; it serves as a real-life sandbox exercise, allowing us to observe the opponent’s moves without incurring losses. I believe that in the future, pursuing technological advancement, especially achieving complete autonomy in the chip industry, has become an urgent priority for the country.

The domestic chip design craze has been ongoing for some time now, and I occasionally hear about various companies working on chips. Some companies are quite famous, while others are difficult to find even on Baidu, only visible through software like Qichacha. Many of these companies have approached me for help with BIOS. Most of these new chips are based on the mature ARM architecture, and some are even based on the trendy RISC-V. There is a pattern here: the RISC-V chip family is still busy entering embedded systems, while ARM chips are growing upwards from embedded systems, continuously encroaching on desktop and laptop systems, and even launching a third wave of attacks into the server domain, where x86 holds absolute dominance. During discussions with these new partners, one question is often brought up: Why can’t the uboot + DeviceTree firmware, which works well in embedded systems, be applied directly to desktops, especially in the server market?

Behind the flickering eyes of the clients, I heard their unspoken question: uboot + DeviceTree mode has nothing to do with BIOS vendors, so why can’t ARM servers use it? It’s akin to asking an S4 store, what value can you bring? Why should we let middlemen profit? Hearing this ultimate question regarding the viability of the business model, I sat up in shock, mustering all my energy to answer: Why do general-purpose servers need UEFI + ACPI?

Not long ago, I spent some time introducing the origin and purpose of ARM SystemReady: What is the current status of UEFI in the ARM ecosystem?Introduction to the Gold Standard of ARM SystemReady Certification

I discussed the various limitations of uboot and the closed nature of traditional ARM software compared to the openness of x86 (even though the hardware situation is quite the opposite). Today, let’s look at this issue from another angle.

Let’s select a typical product from each category and see what differences exist in their customer base and business models. A smartphone is a typical embedded product; how does its customer base differ from that of a cloud server?

The customers of smartphones are end consumers, making it a highly customized product. Once its hardware and software leave the factory, they cannot be easily altered. Users cannot casually change various hardware components on the motherboard, nor can they replace the software. Try to see if you can install Huawei firmware (including the operating system) on an Apple phone and expect to get a Huawei phone that looks like an Apple? Not only can different manufacturers not flash each other’s firmware, but even products from the same manufacturer across different product lines generally cannot be flashed interchangeably. Such high customization greatly diminishes the general demand and, correspondingly, the need for interoperability between hardware and operating systems.

The customers of cloud servers are cloud service providers and enterprise IT professionals. A fundamental requirement for these customers is compatibility, both in hardware and software. The motherboard with chips and BIOS is just a small part of the puzzle; various peripheral cards, operating systems, middleware, databases, and upper-layer software make up a much larger part. These components are often sourced from different manufacturers, and some cards and software are inherited from older systems, which no one dares to modify. Servers are extremely complex; they cannot be vertically integrated and must adopt an ecosystem model. This places high demands on interoperability between hardware and operating systems. To be general and interoperable, standardization is necessary, and each component must be productized individually, rather than the entire product being treated as a single product. The operating system is a standalone product; PCIe cards are also products sold separately; although motherboards and CPUs vary widely, all these hardware and software products can run smoothly on them, with the motherboard’s BIOS customization playing a crucial role. The BIOS masks hardware differences and provides a unified interface.

The standardization of UEFI makes it more suitable for servers and personal computers compared to uboot. It initializes the hardware and primarily describes the hardware through ACPI, providing a hardware abstraction layer (the other being SMBIOS). However, DeviceTree is also a standardized and open-source data format that can also hide and report hardware differences, so why must servers use ACPI? Why does the ARM SystemReady mentioned earlier only recommend DeviceTree for the embedded-focused IR standard, while the server baseline SBBR (Server Base Boot Requirements) explicitly requires ACPI?

In the early days, Linux had a serious binding issue with hardware chips and platforms, with numerous directories named march-xxxx (chip micro-architecture) and plat-xxx (platform) under arch/arm, containing code for various chips and platforms. Essentially, adding a new chip or platform required adding a directory and a set of code, making scalability quite poor. In contrast, directories like i386 were much cleaner. This situation could not continue, and as Linux began to support more and more platforms and chips, the conflict erupted (Linus got furious).

The Open Firmware supporting PowerPC and SPARC has a nice hardware abstraction model: DeviceTree (DT). As the name suggests, it describes the organization and inheritance relationships of hardware devices in the system in a tree-like manner. When Linux began supporting these two CPU architectures, it also added support for DT. As the C language hard-coded mode of supporting chips and platforms in ARM Linux hit a bottleneck, DT was naturally adopted, leading to a much cleaner directory structure (with subsequent cleanup).

The text mode of DT is called DTS (Device Tree Source), which is a human-readable version akin to a C language .c file and can be edited with any text editor. It adopts a tree structure to describe the system’s devices. Let’s look at an example, such as the BeagleBone Black.

We abstract its devices as follows:

A corresponding DTS file is:

Due to space constraints, I won’t elaborate on the keywords and details, but interested readers can refer to the spec.

DTS is like C source code and must be compiled before use. The compiler for DT is called DTC (Device Tree Compiler), which compiles it into a DTB (Device Tree BLOB) file, akin to a C language .obj file. The compilation command looks like this:

dtc -O dtb -o outputBLOB.dtb -b 0 inputSOURCE.dts

Linux has a DTB interpreter that can parse DTB format (ePAPR) and achieve dynamic binding.

DT can be compiled with Linux, built into the final zImage, and you can find it in boot/dts. It can also be dynamically generated by BIOS and passed to the Linux kernel via parameters.

If we observe the DT device tree ourselves, we will find that it bears a strong resemblance to the device tree defined by ACPI. Both can describe the hardware of devices in the system and provide hardware abstraction, so what prevents DT from being used in the server market?

ACPI, like UEFI, was jointly proposed by Microsoft and Intel. The Microsoft flavor in its blood has naturally generated resistance within the Linux community, which initially attempted to adopt UEFI + DT for server support but ultimately chose to embrace ACPI. What is the reason? The Linux community has provided a detailed response. In simple terms, it includes the following points:

1. ACPI is more powerful: ACPI not only provides static tables and device counts but also offers dynamic methods (Methods) through AML. The Methods interpreted and executed by OSPM grant motherboard manufacturers greater flexibility to implement more complex behaviors. For instance, functions like RAS, which involve a series of operations, would be unimaginable to implement using DT. This means that ACPI not only achieves static abstraction of hardware devices but also dynamic abstraction of hardware behaviors.

2. ACPI is more comprehensive: As its name suggests, ACPI also provides comprehensive power management features.

3. ACPI has stronger compatibility: A single abstract model can support all operating systems, whereas using DT would require additional ACPI support for Windows (ARM Windows).

4. ACPI has already become the de facto standard for servers: As x86 servers dominate the mainstream, ACPI has secured its ecological niche in the server environment. For ARM, which is entering the market, adopting ACPI is a wise move to support existing components and ecosystems. The widespread acceptance of PCI/PCIe buses in ARM servers follows this rationale.

The above four points, especially the first, make the UEFI + ACPI model seem quite necessary for servers, allowing the BIOS business model to continue on ARM.

The DT standard is still evolving, with the latest standard released in 2021, firmly establishing its position in the ARM embedded systems. However, ACPI has already occupied the server and most desktop environments. Personally, I believe that the uboot + DT approach does not need to change in embedded systems, while UEFI + ACPI will inevitably be the choice for ARM servers. Interestingly, there is an intermediary zone represented by consumer products like desktops and laptops.

With the improvement of ARM performance, more and more manufacturers are embracing ARM computers, and Microsoft’s Windows ARM version is also performing well. The functionality of desktop ARM is becoming increasingly comprehensive, and the demand for universality is rising. The acceptance or migration of ACPI in the desktop realm has become a trend. However, domestic ARM desktop chips, aside from Kunpeng and Feiteng, have a low acceptance of ACPI. This has caused significant confusion for domestic Linux manufacturers. Although Linux supports both, it cannot support them simultaneously. Supporting two branches increases workload and can lead to product quality issues. DT and ACPI are like a pair of contradictions; on the battlefield of ARM desktops, will the shield block the spear, or will the spear pierce through the shield? The outcome may be quite clear.

[1] DeviceTree Official Website: https://www.devicetree.org/

[2] DeviceTree Spec: https://github.com/devicetree-org/devicetree-specification

[3]BeagleBoard BLACK Official Website: https://beagleboard.org/BLACK

[4]Why ACPI?: https://www.kernel.org/doc/html/latest//arm64/arm-acpi.html#why-acpi-on-arm