Posted by Tom De Schutter on June 25, 2014
Guest blog by Achim Nohl
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 64bit 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 2226 pages which ARM servers need to adhere to. UEFI for ARM SoCs continue to be work in progress since 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 prototypes 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 impact 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 hardcoded configurations. With device trees, the entire configuration (e.g. memory, interrupt, clocks, voltages) is defined and called a flattened device tree file (instead of hardcoded 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 it will require 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 as 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, since the OS 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 will no longer 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. Especially, when dealing with clocks and voltages 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 in order 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.
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.