Linux And The Big Bad Wolf

With great interest, I am following any news around the progress of Linaro and the Linux kernel community with regard to addressing all the requirements for an ARMv8 64-bit server software stack.

Well-established standards, such as the Unified Extensible Firmware Interface (UEFI) and Advanced Configuration and Power Interface (ACPI), are impacting the development direction of the community big time. UEFI is a mandatory standard counting 2,226 pages, which ARM servers need to adhere to. UEFI for ARM SoCs continues to be a work in progress because drivers for many IP titles are still to be developed. Also, the whole aspect of secure boot is a big construction area.

But a major chunk of work has been done and Linaro is providing UEFI firmware as part of its open embedded release snaphots. Virtual platforms have been a critical enabler for porting an open source version (EDK2/Tianocore) of the Intel/Microsoft rooted UEFI standard. UEFI has not been that intrusive with regard to its impact on prior ARM Linux kernel work as ACPI is.

ACPI, a standard for runtime configuration of the hardware, has a tremendous effect on the Linux kernel. One of ACPI’s great impacts is its complete overlap with the objectives of the recently established device trees. Device trees have been critical for ARM to find a way out of the board support mess in the Linux kernel.

Before device trees, each board/SoC had its own directory underneath the ARM architecture and was polluted with many vendor specific drivers and hard-coded configurations. With device trees, the entire configuration (e.g. memory, interrupt, clocks, voltages) is defined and called a flattened device tree file (instead of hard-coded in C). This is an ASCII file, which is compiled into a binary blob and then analyzed by the kernel during the boot stage in order to configure its device drivers. Device trees have been fully adapted for the ARM 64bit kernel port and, as a result, there are no longer directories for SoCs or boards. The same binary kernel will run on any ARM hardware along with a separated configuration file, i.e., the flattened device tree file.

This could be the happy end of a nice fairy tale if the big bad wolf wasn’t coming around the corner. That big bad wolf’s name is ACPI, and unlike the fairy tale, he does have good intentions. But plan on a lot of changes. ACPI is important for standardizing the run-time configuration of a server system, as datacenter operators will not want to care about the artifacts of the underlying hardware and would like to operate the servers in a uniform way.

The scope of ACPI is very large and comprises system run-time configuration, power and thermal management as well as Reliability Accessibility Serviceability (RAS), e.g., hardware error handling support. ACPI has been declared the preferred runtime interface for ARMv8 servers. ACPI is likely to be included in the upcoming ARM SBSR (server base firmware requirements) document, which goes together with the ARM server standard SBSA (server base system architecture). As a consequence, drivers will need to be adapted to be able to obtain their configuration via ACPI rather than the device tree interface.

However, this is not the end of the story. The biggest impact of ACPI may come through the changes needed for low-level power management. Historically, ACPI has been defined to shift power management of the BIOS (predecessor of UEFI) into the operating system in order to perform operating system power management (OSPM).

The OS is supposed to be able to execute wise decisions for run-time power management because it has an understanding of the varying performance needs and through guidance from the upper application layers it can even take the usage context into account. With this, the OS can deliver the right Quality-of-Service (QoS) and trade off power and performance demands optimally and dynamically.

Of course, this is not new for ARM Linux, and run-time power management has been a sweet spot due to ARM’s deployment in the power sensitive mobile market. But with ACPI fundamental changes coming into the picture, the low-level clock and voltage control implies that the drivers for clock and voltage regulators no longer will be part of the kernel and will need to be done by the firmware through ACPI. This concerns all components, the CPU as well as the peripherals.

For the kernel developers, this means giving up a lot of control and is highly debated. But ACPI is a mandate and there is no way around. When dealing with clocks and voltages, in particular, a lot of debugging challenges arise. Not only can you can break the hardware through violating voltage ranges, but debugging un-powered hardware or transitions such as suspend/resume is not any fun. Now this gets even more complex as the low-level power management need to be debugged across multiple software layers such as the kernel and the firmware.

Another key challenge for the software developers is the missing hardware with sufficient power infrastructure to develop, debug and test the ACPI implementation for ARM. The demand for a development target for ACPI power management software is well expressed in this short video snapshot from a Linaro connect session in Asia, March 2014. Functionally accurate models of hardware, such as virtual prototypes, will again play a key role here.

A key misconception of non-virtual prototype users is that virtual prototypes are too abstract here. In fact, power management software bring-up has been a key use case for Synopsys virtual prototype power users in the past. Virtual prototypes are able to capture the software relevant power architecture of a SoC and beyond. This includes components such as clock management units, power management ICs (PMICs), as well as the power domains defined by the complex clock and voltage trees.

Virtual prototypes can accurately replicate fault scenarios such as exceptions or time-outs due to accessing unpowered hardware. Instead of burning a prototype, illegal voltage settings will just result in an informative assertion for the software developer. Next to the aspect of simulating power management software, virtual prototypes provide exceptional debug visibility, even when parts of the system are powered off. Synopsys virtual prototypes extend the scope of the ARM FastModels and foundation models and allow capturing the SoC specific power infrastructure as well as integrate any other custom hardware, enabling everyone to live happily ever after.