Before we do a dive into the ACPI standard, let’s go back to what the main goal is for firmware. Utopia is to have a universal firmware solution which can boot and support any Operating System (open, propriety and future) and any version of that Operating System. The firmware solutions are based on common standards which allow for multiple implementations. This is achieved since each firmware implementation is written and conforms to a set of open standards. The standards allow both manufacturers and consumers to have an advantage.
To achieve this advantage an abstraction layer has to be defined which hides the control-details of a hardware platform.
Note: for companies not requiring universal boot firmware there are other directions which can be taken. There are different technologies to solve different problems and each software technology has advantages and disadvantages. In the boot world there are many choices.
If you agree with the concept of universal firmware, I thought it would be interesting to discuss the ACPI standard in the context of “boot and support everything”. As a background, please take a look at the blog I co-authored with Dong Wei (HP Fellow):
“Why should you care about ACPI definition merging into the UEFI Forum?”
In that blog we discussed the industry announcement of the ACPI governance change and the organizational movement of ACPI underneath the UEFI Forum. This announcement was a big event since it allows ACPI to be adopted and influenced by a broader set of companies throughout the industry. Any member company can put forward changes and improvements to the standard. The broader adoption means ACPI is applicable to a wider set of applications and can move quickly with peer review.
When we started exploring the software requirements for ARM Servers we received a common request to standardize firmware and more precisely standardize on UEFI & ACPI. We tend to take a neutral stance with software and follow commercial guidance. We received a solid universal request from both Server manufacturers and Operating Systems companies that UEFI & ACPI was a preferred option.
The UEFI Forum has a number of working groups including groups looking at Test and UEFI Specification; see the following link for more details.
http://www.uefi.org/workinggroups
Each group has a charter, for the ASWG the charter is as follows:
The group’s scope is to manage and evolve the definition of the “Advanced Configuration and Power Interface” specification (ACPI Spec). The purpose of the specification is to define flexible and extensible interfaces for system configuration, power management and RAS (Reliability, Availability, and Supportability) features useful for systems across all market segments from embedded and ultra-mobile devices to the enterprise servers. ACPI normally includes static tables for platforms to communicate system information to the OS during early boot and a name space with control methods as primary runtime interfaces between platform firmware and operating systems software.
In summary the ASWG charter is to correct any deficiencies and improve the ACPI Specification moving forward.
As mentioned above, ACPI is being driven by the industry because of the intersection of ARM Servers and ARM 64-bit Processors. Servers require three fundamental pieces of software. Namely standard firmware, standard power management and a consistent Operating System stack. In the above context, ACPI covers the mechanisms for both Device Discovery and Power Management.
Let’s explore ACPI itself ACPI provides standardized mechanisms for Device Discovery, Operating System Power Management, Thermal Management and RAS (Reliability, Availability and Serviceability) communication - just to name but a few. And the specification is comprehensive and Operating System agnostic which is important for universal firmware goal.
It means standard enterprise server software can be created to run on complex ARM-based platforms without requiring major re-engineering. For example, given an ARM processor based SoC with standard UEFI boot firmware and ACPI, a manufacturer has the opportunity to choose the Operating System provided that Operating System supports the handling of ACPI. The hardware support is achieved without major re-writes or re-builds of the software stack. This is important for enterprise solutions and is different from the traditional embedded and mobile markets. Embedded and mobile can afford to be unique due to the nature of the problems being solved. In contrast, Server software is all about providing an open application platform that sits on top of standard compliant firmware.
Enterprise Server Operating Systems can take advantage of the separation to boot-many using only one image instance. This is achieved since both hardware-discovery and hardware-control is separated by the ACPI abstraction layer. Operating Systems can reduce the test-scenario permutations since only one image is required to be tested, released and supported. There are engineering savings since the AML code embedded within the ACPI tables removes the need for the kernel image to contain drivers for everything. ACPI as a standard allows for stability. This means a 5-year-old Operating System can run on new hardware. This extends the longevity and in turn improves the return-on-investment (ROI).
Yes, the mobile market is much more vertically integrated so not all of the advantages of ACPI playout.
for mobile market, it seems FDT (device tree) is welcome.