Vous êtes sur la page 1sur 6

ACPI

The Advanced Configuration and Power Interface (ACPI) specification combines Power
Management and Plug and Play functionality for notebooks, desktops, and servers. ACPI is the
keystone in Microsoft's Operating System Directed Power Management (OSPM). With OSPM, the
operating system determines when to do power management, and the BIOS determines how to
do power management. The two pieces work in concert to provide maximum power savings.
What is ACPI?
Why is ACPI important?
How is ACPI designed?
What are the differences between APM and ACPI?
How does ACPI support Plug and Play functionality?
ACPI Support and Logo Requirements
How does Phoenix's ACPI BIOS solution help developers?
LogoPlus ACPI
Advanced ACPI
ACPI Utilities
ACPI Disassembler
ACPI Embedded Controller Support
Additional Information

What is ACPI?
ACPI defines hardware and software interfaces used by the operating system to manipulate the
characteristics of motherboard devices. ACPI differs from APM and Plug and Play (PnP) in two
fundamental ways:
• The support code provided by the BIOS is not written in the native assembly language of
the platform but in AML (ACPI Machine Language).
• The BIOS does not determine the policies or time-outs for power management or
resource management.
Return to Top

Why is ACPI important?


Changing from Advanced Power Management (APM) and Plug and Play (PnP) to ACPI offers
many benefits including the following:
1. A cooperative "Plug and Play" environment for devices and power management for
desktops, notebooks, and servers
2. An open Operating System Architecture that allows the development of ACPI for non-
Microsoft operating systems. This O/S also lets ACPI-compliant operating systems
running on non-standard hardware use the ACPI interface.
3. New opportunities for product differentiation
4. Developer-defined control methods using the ACPI language
ACPI support is required for NT 5.0, Windows/PC 97& 98, Server 97& 98, and OnNow
Certification. Older versions of NT do not have any power management support. ACPI-compliant
systems running NT can take full advantage of power savings through ACPI power management.
Phoenix has an ACPI compliant BIOS, which the NT 5.0 and Win 98 development teams at
Microsoft have been using for several months.
The ACPI hardware interface provides two types of functionality to the operating system that
previously resided in the BIOS:
• Control and detection of system control events using a normal interrupt called System
Control Interrupt (SCI) rather than System Management Interrupt (SMI)
• Control of the system power state
Return to Top

How is ACPI designed?


The following diagram from the ACPI Specification shows the various system components: (ACPI
1.0 Specification Figure 1-1, Copyright © Intel/Microsoft/Toshiba, 1996)

The areas outlined by the dotted line are described in the ACPI 1.0 specification.
The system BIOS (shown as two blocks simply to indicate both the standard and ACPI functions
provided) provides the details for the platform's hardware interface in one or more well-defined
tables. These tables are written in ACPI Source Language (ASL) and compiled into ACPI
Machine Language (AML) for inclusion in the BIOS.
The ACPI software interface, implemented as a windows driver, provides the means for the
operating system to find the different tables in the system BIOS. Phoenix has added a feature to
the BIOS implementation that permits the tables to be dynamically modified at run time. This
allows changes to the tables actually stored in the BIOS ROM before they are processed by the
operating system.
A system supporting ACPI requires the following components to operate correctly:
• System Management Mode (SMM) - capable CPU
• SMM - capable chipset
• ACPI-capable support logic
The final key expectation is that the operating system being run is capable of supporting ACPI.
Although Microsoft operating systems will be ACPI aware in the near future, systems running
UNIX, LINIX, OS/2 or other operating systems will not have ACPI support as soon. If
manufacturers wish to offer any type of power management to these types of users, legacy BIOS
power management must be included on the platform.
Events
The ACPI compliant hardware informs the operating system about power management, resource
management ,and docking occurences, by creating an "event." Events generate a special
interrupt called the SCI (System Control Interrupt) which is then handled by the ACPI driver.
ACPI Tree
All ACPI hardware and features are organized as a tree structure. The tree represents how the
operating system communicates with the devices. Objects under other objects in the tree are
called children. The base of the tree is called the root. When the operating system begins to cut
back power because it has detected an idle or non-use state, it does so from the bottom of the
tree. This means that children are turned off before parents .
Return to Top

What are the differences between APM and ACPI?


Phoenix pioneered the development of BIOS-based power management which provides power
savings for early notebook computers. This early power management relied on the BIOS to
determine when a particular device had been "idle" long enough to reduce or remove power. With
no feedback from the operating system, however, power savings were not optimized. When
Microsoft introduced APM, the operating system was nominally involved in some of the power
management decision making.
Now, with ACPI, power management for system devices moves from the BIOS to the hardware
and operating system. ACPI specifies four base power levels, with three substates for the
sleeping state.
• APM States:
• Enabled
• Standby
• Suspend
• Off
• ACPI States:
• S0=On
• S1-3=Sleeping
• S4=Soft Off
• S5=Off
The ACPI BIOS tables define what these states mean for individual devices, and the operating
system determines when to move a device, or even the entire system, from one state to another.
Return to Top

How does ACPI support PnP Functionality?


In an ACPI implementation, the integrated Phoenix BIOS behaves as both a complete PnP (Plug
and Play) BIOS and an ACPI BIOS. The system determines at boot time if it will run in PnP or
ACPI mode. The ACPI BIOS contains the information necessary to communicate the hardware
specific configurations and features to the operating system.
Basic support for ACPI includes:
• POST - ACPI table relocation/modification during the Power on Self Test
• MCD - Integration during POST of Motherboard Configurable Devices
• Chipset - Additional services specific to ACPI
• SMM - OS Services, Global Lock, Phoenix Services, Save-to-Disk
• Build - Change process to support ACPI tables, new rules, and installable options
To run Windows 95 and other non-ACPI platforms, systems must support older Power
Management and Plug and Play functionality. This legacy support will probably be required for at
least the next two years. Although Phoenix can provide an ACPI only BIOS, an integrated
ACPI/Legacy BIOS will be the BIOS of choice for most manufacturers for several years.
All of the Phoenix ACPI BIOS solutions use an existing desktop, server, or notebook BIOS. All of
these implementations include Embedded Controller support.
Return to Top

ACPI Support and Logo Requirements


Microsoft requires ACPI support since April 1, 1998. The minimum requirements are included in
the ACPI Specification rev. 1.0, section 1.7 Minimum Requirements for OSPM/ACPI Systems.
The section numbers shown in parenthesis below indicate the section of the ACPI Specification
where these features are described.
Note: Software only requirements are identified by an asterisk (*).
• A power-management timer - 3.579 MHz (4.7.2.1)
• A power or sleep button (4.7.2.2)
• A real time clock wakeup alarm (4.7.2.4)
• Implementation of at least one system sleep state, S1-S3 ( 9.1) - Note desktop systems
may only implement S1.*
• Interrupt events generate SCI's and the GP_STS (General Purpose Register
Block_Status) registers are implemented (4.7.4.3)
• A Description Table provided in the BIOS. (5.2)*
• A user accessible fail-safe mechanism to either unconditionally reset or power off the
machine.
Minimal Requirements
Under the PC '97 and PC '98 Design Guide criteria, minimal ACPI support is required. As the list
above indicates, there are few mandatory ACPI requirements. It is essential to understand these
features and the impact they make upon different PC platforms.
Notebook computers operating at the minimum ACPI requirement level will lack many common
features. The minimal system requirements of the ACPI specification would produce a poorly
power managed notebook PC and decrease the flexibility of the system because of the lack of
support for dynamic device bays and docking. Additionally, the minimal requirements do not
include support for save to memory or to disk, which are standard features shipped with current
notebooks. The minimal ACPI requirements also do not include support for multiple batteries.
In the desktop and server markets, these minimal requirements are more realistic. The low end
consumer PC's that are selling for under $1,000.00 will be prime candidates for this set of
features. Minimal power management and device level OS management are completely
acceptable for these platforms. Servers are also not in high demand of advanced power
management and plug and play functionality as notebook PC's are. System differentiation is not
expected from manufacturers that ship with only the minimal ACPI requirements supported. In
order to raise the desktop and server products to the advanced power management and device
flexibility of the notebook PC's, designers will need more advanced functionality to compete.
Return to Top

How does Phoenix's ACPI BIOS solution help developers?


Phoenix implemented the first ACPI-compliant BIOS based on the ACPI BIOS that Microsoft
developed in August of 1996. This BIOS complied with Rev 0.7 of the ACPI Specification. Since
then, Phoenix continues to develop new features and add enhancements required for logo
certification.
The architecture of Phoenix's ACPI BIOS solution reduces the burden of implementing ACPI
support on a new platform by providing
• A simple interface to the most common porting requirements
• A strong set of core support routines
• Tight integration with Motherboard Configurable Devices (MCD)
Return to Top

LogoPlus ACPI
LogoPlus ACPI provides ASL code that supports power management and device configuration
capabilities. LogoPlus supports the following functions:
• Power management timer
• Either or both a power and a sleep button
• Real-time clock wake-up alarm
• System sleep states: S1 and S2
• SCI and GP_STS registers support in the BIOS
• DSDT support in the BIOS
• Fail-safe mechanism to power off or reset the system
Return to Top
Advanced ACPI
Advanced ACPI supports ASL code for power management and device configuration capabilities
beyond that which LogoPlus offers. Advanced ACPI supports the following functions:
• Power management timer
• Either or both a power and sleep button
• Real-time clock wake-up alarm
• System sleep states: S1, S2, S3, and S4
• SCI and GP_STS registers support in the BIOS
• DSDT support in the BIOS
• Fail-safe mechanism to power off or reset the system
• Device power management
• Phoenix services for SMI handling
• Device configuration - docking, PC Cards, swappable bays
• ACPI embedded controller
• Thermal zone management
• Multiple CPU support
• Multiple PCI bus support
• Wake-on-event support - USB device activity and LAN or modem activity
Return to Top

ACPI Utilities
Phoenix provides a set of utilities to assist hardware and BIOS developers.
APCI Architect
Phoenix has developed a powerful design tool called the APCI Architect. This tool includes:
1. Chip set support
2. Standard component, device and bus support
3. Device and system templates
4. Built in code editor, tree viewer, device icons
5. Ease of differentiation
6. On-line Help
ACPI Architect frees developers from learning the nuances of ASL and allows them to begin
designing their systems immediately. ACPI Architect is used to view, modify and create ACPI
System Description Tables. The table view is presented to the user in the form of an ACPI Tree
and the file is stored in ACPI Architect form, *.aa. The ACPI Architect tool can generate ASL code
from these *.aa files. The ASL code can then be compiled using the Microsoft ASL compiler to
generate AML code for use on ACPI systems.
MCD2ACPI
MCD2ACPI is used for the automatic generation of ACPI configuration objects. This utility is
designed to create ACPI ASL code from existing MCD structures in the Phoenix BIOS version 4.0
release 6. This should reduce the work required to build the ACPI configuration objects (PnP), for
any currently implemented platform BIOS. It will automate much of the task and eliminate part of
the manual coding of the ASL for already completed PhoenixBIOS 4.0 and NoteBIOS 4.0 release
6 ports.
ASLPP
ASL (ACPI Source Language) Preprocessor. The ACPI specification defines certain buffer
formats for use with the Plug and Play section of the specification. These buffer formats are
streams of bytes which detail the resources used by the device, including memory, I/O, interrupts,
and DMA channels. Manually coding the buffer contents is tedious and results in ACPI code that
is difficult to read. ASLPP provides a solution, extending the ASL with a preprocessor that
translates Phoenix defined operations into byte streams.
Return to Top
ACPI Disassembler

AD displays ACPI-related tables and checks them against the ACPI 2.0 specification. Under DOS
(or Windows 98/Me DOS box), these can be extracted from the system BIOS. Extract all files to a
single directory. See readme.txt for usage details. Phoenix has made this utility available for your
use, because of our commitment to technology leadership.

Error! Hyperlink reference not valid.Error! Hyperlink reference not valid.


Return to Top

ACPI Embedded Controller Support


Using the in-house expertise acquired during years of keyboard controller development, Phoenix
has a variety of solutions for supporting the ACPI Embedded controller. For details, refer to the
Phoenix White Paper ACPI Embedded Controller - Implementation Considerations (this
document is in Adobe Acrobat format. If you do not have the Adobe Acrobat reader, you can
download the Reader now). The two most popular approaches to the Embedded Controller use
either a single dual port controller for both Embedded Controller and Keyboard Controller (KBC),
or two separate chips, one for the Keyboard Controller and one dedicated to ACPI.
Embedded Controller Combined with KBC - Single Controller Solution
Advantages:
• Requires minimum hardware modifications to support non-ACPI and ACPI system
management features in the same platform
• Saves Power
• Costs Less
• Requires less real estate and glue logic
Supported Controllers:
• Mitsubishi 38813/38867/38869
• Hitachi H8/3434
• National Semiconductor PC87570
Discrete chip(s) for Embedded Controller(s) - Dual Controller Solution
Advantages:
• No modifications required to existing KBC firmware
• Provides more I/O ports for additional system control features
Supported Controllers:
• Mitsubishi 38813/38867/38869
• Hitachi H8/3434
• National Semiconductor PC87570
For more information about keyboard controller support, see our MultiKey page.
Return to Top

Additional Information
The following documents are in Adobe Acrobat format. If you do not have the Acrobat Reader,
you can download the Reader now.
ACPI Architect Data Sheet
ACPI BIOS Data Sheet
ACPI Embedded Controller - Implementation Considerations
ACPI Disasssembler

Vous aimerez peut-être aussi