Frequently Asked Questions

Q: What are the benefits to implementing the ACPI standard?

The benefits to using the ACPI standard include enhanced power management functionality and a robust interface for configuring motherboard devices. ACPI offers stability and backward-compatibility for legacy operating systems running on new hardware, without requiring major re-writes or re-builds of the software stack. This provides an open application platform that sits on top of standard compliant firmware. The hardware-discovery and hard-control, separated by the ACPI abstraction layer, allows OSes to condense test-case scenarios to a single image test. This reduces engineering expenses, as the AML (ACPI Machine Language) encoding embedded within the ACPI tables removes the need for the kernel image to contain individual drivers.

Q: What computing platforms are compatible with the ACPI standard?

ACPI supports a wide range of platforms including laptops, tablets, smartphones, workstations, desktops and servers. The specification already includes some support for ARM SoC (System-on-Chip) and architecture extensions. Future iterations of the ACPI specification will continue to develop and expand support for the ARM processor core architecture.

Q: Who is intended to implement the ACPI standard?
The target audiences for the ACPI specification include:
  • OEMs building hardware containing ACPI-compatible interfaces
  • Operating system and device driver developers
  • BIOS and ACPI system firmware developers
  • CPU and chip set vendors
  • Peripheral vendors

Q: What functional areas are covered by the ACPI specification?
Platforms compliant with the ACPI specification provide Operating System-directed configuration and Power Management (OSPM) with direct and exclusive control over the power management and motherboard device configuration functions of a computer. These functional areas include:
  • System power management
  • Device power management
  • Processor power management
  • Configuration/Plug and Play
  • System events
  • Battery management
  • Thermal management
  • Embedded controller
  • SMBus controller
ACPI requires that once an ACPI compliant platform is in ACPI mode, the platform’s hardware, firmware, or other non-OS software must not manipulate the platform’s configuration, power, performance, and thermal control interfaces independently of OSPM. OSPM alone is responsible for coordinating the configuration, power management, performance management, and thermal control policy of the system. 

Q: What are the ACPI features?

The two primary roles of ACPI include device configuration and power management. Under the role of device configuration, ACPI can let the OS know what hardware it contains, including devices that are not readily detectible. As for the role of power management, once the OS is running, there are functions that can move the machine into a low-power state. These mechanisms tend to be platform-specific, each with a different design and management process. Additionally, ACPI provides standard interfaces for RAS (reliability, availability and supportability) features.

Q: What is the UEFI Forum’s involvement with the ACPI standard?

The ACPI specification was transferred to the UEFI Forum in October 2013, following the ACPI v5.0a release. Uniting ACPI with the Forum’s existing standards portfolio helps synchronize interface definitions and increases participation of open-source developers, which is critical to expanding ACPI adoption onto new classes of platforms and devices. A working group within the UEFI Forum, the ACPI Specification Working Group (ASWG), was created to manage and evolve future ACPI developments.

Q: Why was the ACPI standard created?

The ACPI specification was created to define a standard model for controlling power state transitions and enabling new platform technologies to evolve independently in the operating system and hardware. Prior to the ACPI standard, custom vendor solutions for power management and system configuration inundated the market. Each proprietary solution required custom OS support, resulting in market fragmentation and influencing the demand for standardized firmware solutions.

Intel, Microsoft, Toshiba, HP and Phoenix set out to unify system power management through the ACPI standard. Over time, the ACPI standard replaced a collection of power management application-programming interfaces (APIs), such as Advanced Power Management (APM), as well as system configuration interfaces such like PNPBIOS APIs and the MultiProcessor Specification (MPS) for x86 architecture. More recently, bindings for ARM architecture and SoC devices were added in the ACPI v5.0 release.

Q: What is ACPI?

The Advanced Configuration and Power Interface (ACPI) provides standardized, flexible mechanisms for device discovery, operating system configuration and power management (OSPM), thermal management and RAS (reliability, availability and supportability) features. The ACPI standard improves system power distribution and conservation through its communications with the system firmware, operating systems and peripheral devices.

ACPI can be applied to all classes of systems and devices and is OS and processor architecture agnostic. It has an open framework that helps reduce market fragmentation and provides a robust interface for managing platform hardware at runtime.

Q: ------------------------------------------------------------------------------------------------------------------


Q: What is UEFI?

UEFI stands for "Unified Extensible Firmware Interface." The UEFI Specification defines a new model for the interface between personal-computer operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.

Q: What is the UEFI Forum?

Through a collaborative approach with world-class companies, institutions and experts, the UEFI Forum advances innovation in firmware technology standards. These extensible, globally-adopted UEFI specifications bring new functionality and enhanced security to the evolution of devices, firmware and operating systems.

Q: What problem is the UEFI Forum trying to solve with the UEFI Specification?

The UEFI Specification provides interfaces and mechanisms to allow for support of new technologies, improved development, and enhanced customer experience during the time before the operating system loads. The UEFI Specification has benefits for both the business and consumer end-user. Across multiple interfaces, the Specification supports a more secure system, a faster boot time, improved performance, platform feature innovation and a quicker, more cost-effective time-to-market product shipment. With regard to security, UEFI Secure Boot helps defend against malware attacks before the operating system loads.

For developers, the UEFI Specification increases efficiency because they allow developers to reuse code. In contrast to prior coding structures, UEFI standards allow for extensibility, modularity and easy prototyping during development.

The UEFI Forum promotes the implementation of the UEFI Specification by BIOS vendors, operating system vendors and add-in card vendors.

Q: What is the relationship between EFI and UEFI?

The UEFI specification is based on the EFI 1.10 specification published by Intel®, with corrections and changes managed by the UEFI Forum. Intel still holds the copyright on the EFI 1.10 specification, but has contributed it to the Forum so that the Forum can evolve it. There will not be any future versions of the EFI specification, but customers who license it can still use it under the terms of their license from Intel. The license to the Unified EFI Specification will come from the Forum, not from Intel.

Q: Can all systems disable UEFI Secure Boot?

While it is designed to protect the system by only allowing authenticated binaries in the boot process, UEFI Secure Boot is an optional feature for most general-purpose systems. By default, UEFI Secure Boot can be disabled on the majority of general-purpose machines. It is up to the system vendors to decide which system policies are implemented on a given machine. However, there are a few cases—such as with kiosks, ATM or subsidized device deployments—in which, for security reasons, the owner of that system doesn’t want the system changed.

Q: Can UEFI Secure Boot be adopted and implemented by a variety of operating systems?

UEFI specifications are platform-independent, supporting multiple platforms and architectures. In addition, UEFI specifications are designed to promote cross-functionality, as well as to support broad adoption across multiple operating systems, including Windows as well as Linux-based operating systems. The specifications are robust and can potentially complement—or even advance—other distributions, such as Linux-based distributions.

Q: What are the benefits of UEFI specifications?

UEFI specifications have benefits for both the business and consumer end-user. Across multiple interfaces, they support a more secure system, faster boot times, innovation and a faster time-to-market. In contrast to prior coding structures, UEFI standards allow for extensibility, modularity and easy prototyping during development. The UEFI Forum promotes the implementation of UEFI specifications by BIOS vendors, operating system vendors and add-in card vendors. UEFI specifications promote more efficient development because they allow developers to reuse code during the building process.

Q: How do UEFI specifications differ from BIOS?

BIOS is typically used to refer to an Intel® Architecture firmware implementation rooted in the IBM PC design. Based on older standards and methods, BIOS was originally coded in 16-bit real mode x86 assembly code and remained substantially unchanged until its recent decline in use.

By contrast, UEFI standards reflect the past 30 years of PC evolution by describing an abstract interface set for transferring control to an operating system or building modular firmware from one or more silicon and firmware suppliers. The abstractions of UEFI Forum specifications are designed to decouple development of producer and consumer code, allowing each to innovate more independently and with faster time-to-market for both. UEFI also overcame the hardware scaling limitations that the IBM PC design assumed, allowing its broad deployment across high-end enterprise servers to the embedded devices. UEFI is “processor architecture-agnostic,” supporting x86, x64, ARM and Itanium.

Q: Do UEFI specifications completely replace the BIOS?

The UEFI specifications define an interface and the BIOS refers to a specific implementation of the firmware that initializes the platform and loads an OS setup. UEFI specifications define an interface in which the implementation of UEFI performs the equivalent of the BIOS, by initiating the platform and loading the operating system.

Q: How is UEFI implemented on a computer system?

Today, UEFI implementation enables the ability for modern, high-level programming principals to be applied to the firmware space. There are many possible implementations of UEFI that encourage code reuse, modularization, flexibility and modernization. UEFI specifications contain interfaces that streamline and aid in firmware innovation by promoting interoperability between devices, software and systems. One typical implementation is done in high-level C programming language, which is fundamentally different than the Legacy BIOS by encouraging the use of modern software practices.

Q: Is there a charge to use the UEFI specification?

There is no charge for use of the specification itself. The promoters of UEFI specifications have agreed that any IP needed to implement the specification will be made available on reasonable and non-discriminatory terms.