ACPI In Windows Vista

ACPI In Windows Vista
Allen Marshall
Lead Program Manager
Windows Core Platform Architecture
Microsoft Corporation

Agenda
ACPI Support in Windows Vista
ACPI Version support
Machine Role Flags
Screen Brightness
_OSI
Processor Power Management
PCI Express
ACPI Driver Interface
ACPI Test and Debugging
Common ACPI Errors

ACPI Support In Windows
Overview
Windows Vista requires ACPI
Non-ACPI HALs are not available in Windows Vista
Legacy power management and BIOS configuration
implementations are no longer supported
Both ACPI and Windows have seen
continual advancements
ACPI offers significant system advantages
Close platform integration with the operating system
Greatly increased reliability, diagnosability
Windows ACPI support promotes
faster system development
Rich ACPI feature support
Extensive ACPI debugging support
ACPI table overload for rapid system bring-up

Microsoft ASL compiler update
Updated ASL compiler now available
Version 3.0.0 released
Supports ACPI 2.0, 3.0 objects required for Windows Vista
Provides several features to facilitate development
and debugging
Saves ACPI tables from firmware to disk file
Un-assembling AML into ASL
Loading ACPI tables from disk, bypassing BIOS ROMs
See details later in this presentation
Available for download from Windows Hardware
and Driver Central (WHDC)
http://go.microsoft.com/fwlink/?LinkId=66535

ACPI version support
Windows Vista supports select objects
from ACPI 2.0, 3.0 specifications
Windows operating systems typically do not
support all features of any one version
of the ACPI specification
Key elements from ACPI are selected to support
development of emerging hardware, e.g.
PCI Express
Mobile dual core processors
High Performance Event Timers (HPET)

Using RSDT versus XSDT
In Windows Vista, if the RSDP Revision field is > 2
Windows will use the XSDT in place of the RSDT
Windows will calculate the checksum of the entire RSDP
Must match the Extended Checksum field
Ensure your XSDT address is valid if you report
Revision > 2 in the RSDP
Leverage the RSDP to support both older
and newer operating systems
RSDT can point to tables with older version support
XSDT points to newer tables

FADT implementation details
If the FADT Revision field is > 2,
Windows Vista will use the extended
64-bit addresses in the FADT
X_FIRMWARE_CTRL and X_DSDT
Extended addresses of ACPI fixed hardware
X_PM1a_EVT_BLK, etc.
DSDT Revision field is used to enable
ACPI 2.0 and greater interpreter support
A Revision > 1 enables interpreter support
for ACPI 2.0 and greater
All integers are treated as 64-bit in ASL

ACPI interpreter support
The Windows Vista AML interpreter features
expanded implicit source data type conversion
Only enabled for a subset of opcodes
Index()
Two-operand logical operators
Introduction of this change is constrained
to limit incompatibilities with existing ASL
As a best practice, leverage using explicit conversion
functions in your ASL to ensure the type correctness, e.g.
ToBuffer()
ToInteger()
See “Debugging type mismatch warnings”
in the Backup section of this presentation

Screen brightness
Laptop LCD brightness controls today are often
implemented with proprietary interfaces
SMM, Embedded Controller firmware
May required 3rd party driver to enable Fn+n hot keys
Breaks on OS upgrade
No in-box support after clean OS install
Not easily debugged
OEM code maintenance burden
Leveraging ACPI makes tight integration
with the operating system easy
Simplifies the implementation
Reduces development and support costs
Enhances reliability
Improves customer experience

Screen brightness
Windows Vista supports the ACPI
Appendix B screen brightness objects
_BCL, _BCM
Screen brightness levels are
controlled via Vista power policy
When _BCL, _BCM are present
Separate brightness levels for each
power policy, and for AC and DC

Screen brightness
Vista provides a temporary
override to control brightness
Slider control in Windows Mobility Center
WMI interface exposed
to control screen brightness
Get and set the current brightness level
Notification on change events
Allows for custom controls
For details, refer to the white paper
“Integrating with Windows Vista Power Management”

Machine role flags
Windows Vista leverages the FADT
Preferred_PM_Profile flags
Allows platform firmware to indicate to OSPM
if the system is mobile, desktop, server, etc.
Enables Windows to accurately determine
the default power policy for the system
Previous Windows operating systems
determine a mobile PC based on the
presence of a long-term battery
Vista falls back to this if Preferred_PM_Profile is 0

Machine role flags
Used throughout Windows Vista to make
mobile versus desktop determination
e.g., disable Hybrid Sleep on mobile PCs
Exposed to application software
through new Win32 API
PowerDeterminePlatformRole()

Operating system interface
_OSI method can be used to determine
the version of Windows running on the system
Windows Vista string is: “Windows 2006”
OS vendor is the only interface string supported by Windows Vista
Windows will return “true” for all OS interface levels supported
Other _OSI strings
Windows 2000: “Windows 2000”
Windows XP RTM: “Windows 2001”
Windows XP SP1: “Windows 2001 SP1”
Windows XP SP2: “Windows 2001 SP2”
Windows Server 2003: “Windows 2001.1”
Windows Server 2003 SP1: “Windows 2001.1 SP1”

Processor power management
ACPI 3.0 domain dependency objects
For multi-processor systems, these
describe any of the relationships between
Physical packages
Physical cores
Logical cores
Describes how OSPM must
coordinate state transitions
Performance states, idle
sleep states, throttle states

Methods supported
_PSD (CPU performance state dependency)
_TSD (CPU throttle state dependency)
_CSD (CPU idle state dependency)
C-states on systems with more than one
CPU must be hardware coordinated
_CSD must report CoordType 0xFE HW_ALL
Otherwise, Vista will disable
all C-states deeper than C1

New ACPI 3.0 throttling controls
Expand the control interface beyond P_BLK
Allows the use of Functional Fixed Hardware address space
Accommodates processor architecture-specific controls
Allows dynamic throttle states
Objects supported
_PTC
_TSS
_TPC
_TDC
Notify (cpu, 0x82)

PCI Express
Windows Vista requires _OSC
on PCI Express root bridges
Enables native OS control of PCI Express features
Windows will first evaluate _OSC to query
for supported capabilities
Evaluate _OSC again to assume control
Firmware must grant native OS control of all control field
feature bits, otherwise Windows takes control of none
ASPM
Hot plug
Power Management Event (PME)
Advanced Error Reporting
For details, see
CPA070 “PCI Express In Depth for Windows Vista”

PCI Express errata flags
Normally, _OSC should control these features
Windows Vista will look for FADT flags to globally
disable some PCI Express features
Message-signaled interrupts
Active State Power Management
These flags are intended as a temporary,
stop-gap mechanism
These features are required per spec

PCI Express FADT errata flags
However, as PCI Express development
continues, there are a number of systems
that fail to work correctly
This necessitates a platform firmware
override mechanism
The need for these flags will
diminish as PCI Express chipset
development matures
Future versions of Windows may
require these flags to be clear

PCI Express and legacy GPE
Don’t assert legacy GPE bits when
Windows is granted control of PCI Express PME
Firmware must not assert legacy GPE to notify
OSPM of device wake
Windows is granted control of PCI Express Hot Plug
If system wakes from PCI Express device, set
PCIEXP_WAKE_STS bit in PM1_STS register
Required to accurately notify Windows Vista
of platform wake source

Reporting wake sources
It is important that platform firmware
correctly reports wake sources
ACPI Fixed Feature hardware
GPE status bits
PCI Express device
Ensure your GPE handler issues
Notify() on appropriate device
Otherwise, Windows may misrepresent
the system wake source

Windows Vista will log and
display system wake sources
Available in the system event log
Can be viewed with the power
command line tool powercfg.exe
C:>powercfg /lastwake
Wake History Count - 1
Wake History [0]
Wake Source Count - 1
Wake Source [0]
Type: Device
Instance Path: USBROOT_HUB4&6a6c62d&0
Friendly Name:
Description: USB Root Hub
Manufacturer: (Standard USB Host Controller)

Example – system event log entry

- Data 2006-04-07T02:37:27.841Z
[ Name] SleepTime
- Data 2006-04-07T16:30:55.390Z
[ Name] WakeTime
- Data 7660
[ Name] SleepDuration
- Data 595
[ Name] WakeDuration
- Data 5945
[ Name] DriverInitDuration
- Data 576
[ Name] BiosInitDuration
- Data 147
[ Name] HiberWriteDuration
- Data 0
[ Name] HiberReadDuration
- Data 0
[ Name] HiberPagesWritten
- Data 0
[ Name] Attributes
- Data 4
[ Name] TargetState
- Data 4
[ Name] EffectiveState
- Data 3
[ Name] WakeSourceType
- Data 17
[ Name] WakeSourceTextLength
- Data ACPI Sleep Button
[ Name] WakeSourceText
Example – system event log wake details

Carefully handle unattended wake events
When a machine wakes due to an PME# event
or a remote event, BIOS ASL should not issue a
Notify(btn, 0x02) to the fixed feature power
button in order to wake the monitor
This indicates User Present to Windows
The power manager will
Turn on the display
Exit Away Mode, if enabled
Apply the current power policy for system idle timeout
This can break power management scenarios
Consider a Media PC

ACPI Support in Windows
Currently drivers can call
IOCTL_ACPI_EVAL_METHOD
IOCTL_ACPI_ASYNC_EVAL_METHOD
Requires a handle to device you
want to evaluate method for
No capability to enumerate or evaluate
control methods of child devices
Workarounds often involve redundant
information in namespace

ACPI Support in Windows
Windows does not allow arbitrary
execution of control methods
Drivers should not evaluate methods
on devices they have no knowledge of
Breaks rules of encapsulation
Leads to system instability
Compromise: Allow control method execution on
child devices beneath the device handle opened
Device should have knowledge of child devices
Allows for cleaner BIOS code in the future
No need to duplicate information in namespace

New IOCTLs to enumerate and evaluate child
device control methods
IOCTL_ACPI_EVAL_METHOD_EX
IOCTL_ACPI_ASYNC_EVAL_METHOD_EX
Take an additional “Name” field
Relative in namespace to the device
you have a handle to
Can be arbitrarily deep
Support passing/returning 64-bit integers

IOCTL_ACPI_ENUM_CHILDREN
Allows enumeration of one level, or multi-level
Supports passing in a filter
Only return specific children
e.g., return only children with _STA method
Returns back an array of child nodes
Flags indicate if a child has descendent

ECDT Table
ECDT – EC Boot Resource Table
Provides processor-relative resources
of an Embedded Controller
Allows EC op region access before the
entire namespace has been evaluated
Without this table, EC region space is
not available until EC device is enumerated
Verify by providing a _REG method under the EC
Windows Vista will return 2 when _REV is evaluated
Indicates firmware should use ECDT

ACPI Test And Debugging
Extracting ACPI tables
The Microsoft ASL compiler supports exporting
ACPI tables and saving them to a disk file
Extracted as ASL
Tables may be modified, temporarily re-loaded on a system
Facilitates development and debugging
Intended only as a firmware development aid – not for deployment!
Usage
asl /tab=DSDT
Produces DSDT.asl
- or –
Asl /=tab*
Produces ACPI.TXT (all tables)

ACPI Test And Debugging
Loading ACPI tables
Tables may be loaded from the
registry instead of from BIOS ROM
Requires the checked version of acpi.sys
The table to be overloaded must already
be present in the system's BIOS ROM
For instance, the DSDT can be overloaded
If the machine does not have an SSDT, you cannot force an
SSDT to be loaded from this registry override mechanism
The table with the highest version
number will be loaded
The table loaded into the registry for testing must have a
higher version number than the same table in the BIOS ROM

Common ACPI Errors
BIOS using OS memory
Windows Vista validates
ACPI memory type definitions
Microsoft has seen instances
of firmware accessing OS memory
This is a fatal error
Stop 0xA5 (ACPI_BIOS_ERROR)
0x1000
<address>
<length>
Seen when additional memory added to systems
Carefully design for top of memory range

Common ACPI Errors
BIOS using OS reclaim memory
Windows Vista validates ACPI memory type definitions
During development, Microsoft discovered instances
of table load from ACPI reclaim memory
ACPI reclaim memory is available for OS
use after ACPI mode has been enabled
Problem is that memory operation region
is mapped as ACPI reclaim
This is incorrect, per the ACPI specification
Load opcode was clarified in ACPI 3.0a
Common error in example code for handling
processor power management capabilities
OEMs and system designers should obtain the latest processor power
management ACPI reference code from your processor vendor

Common ACPI Errors
GPE index out of range
Windows Vista validates the index of
general-purpose event bits (GPEs)
GPE indexes referenced must be within
the length of the GPE register blocks
Validation failure results
in a fatal system error
Stop 0xA5 (ACPI_BIOS_ERROR)
Subcode 1 = 0x17 ACPI_INVALID_GPE_INDEX
Subcode 2 = GPE bit index specified

Common ACPI Errors
Memory corruption during sleep
During Vista development, BIOS
corruptions of the low 1MB of memory
were observed across suspend/
resume transitions
BIOS developers need to ensure that
their code does not have this issue
Detect this problem with Driver Verifier

Common ACPI Errors
Memory corruption during sleep
This check is automatically
enabled on checked builds
System checksums low 1 MB of memory
before, after suspend/resume
Corruption results in stop error 0xC4
DRIVER_VERIFIER_DETECTED_VIOLATION
Subcode 0xB7 indicates the BIOS
has corrupted low physical memory
Parameters 2,3,4: Number of corrupt
pages, first corrupt page, last corrupt page

Common ACPI Errors
Update table versions
Be sure to update OEM Revision
field in your table headers
Windows applies BIOS work-arounds
based on this revision
Failure to update this revision may
result in loss of functionality
Example: BIOS known to have problems
with PCI Express ASPM has this feature disabled
Updated ACPI BIOS corrects the problem, but fails
to update OEM Revision in description header
Windows will continue to disable this feature

Call To Action
Ensure your systems properly
support ACPI for Windows Vista
Leverage ACPI in place of proprietary
solutions wherever possible
Test your ACPI implementations
using checked builds or with
Driver Verifier enabled
Take advantage of Microsoft’s ASL
compiler and debugger extensions
to facilitate ACPI development

Additional Resources
Web Resources
White papers, other resources
http://www.microsoft.com/whdc/system/
pnppwr/powermgmt/default.mspx
Microsoft ACPI Source Language (ASL) Compiler v3.00
http://go.microsoft.com/fwlink/?LinkId=66535
ACPI Specification: http://www.acpi.info
Related Sessions
CPA075 Power Management in Windows Vista
CPA060 Kernel Plug and Play Support in Windows Vista
CPA070 PCI Express in Depth for Windows Vista and Beyond
For questions about ACPI in Windows, contact Microsoft
at:
aslhelp @ microsoft.com

Backup
PCI Express FADT override flags
BOOT_ARCH
Bit
Lengt
h
Bit
Offset
Description
LEGACY_DEVICES 1 0 If set, indicates that the motherboard supports user-visible devices on the
LPC or ISA bus. User-visible devices are devices that have end-user
accessible connectors (for example, LPT port), or devices for which the OS
must load a device driver so that an end-user application can use a device. If
clear, the OS may assume there are no such devices and that all devices in
the system can be detected exclusively via industry standard device
enumeration mechanisms (including the ACPI namespace).
8042 1 1 If set, indicates that the motherboard contains support for a port 60 and 64
based keyboard controller, usually implemented as an 8042 or equivalent
micro-controller.
VGA Not Present 1 2 If set, indicates to OSPM that it must not blindly probe the VGA hardware
(that responds to MMIO addresses A0000h-BFFFFh and IO ports 3B0h-3BBh
and 3C0h-3DFh) that may cause machine check on this system. If clear,
indicates to OSPM that it is safe to probe the VGA hardware.
MSI Not Supported 1 3 If set, indicates to OSPM that it must not enable Message Signaled Interrupts
(MSI) on this platform.
PCIe ASPM Controls 1 4 If set, indicates to OSPM that it must not enable ASPM on this platform.
Reserved 11 5 Must be 0.

Backup
ACPI Debugging
Debugging Tools for Windows can be
used to debug issues with ASL
Microsoft provides a kernel debugger
extension that enables AML debugging
Included with Debugging Tools for Windows
Some commands required
the checked acpi.sys

Backup
ACPI Debugging – Common Commands
!amli find <obj>
Finds all objects in the ACPI namespace with the specified name
!amli dns /s <full_obj_path>
Displays the specified namespace object and all elements underneath
!amli u <method>
Unassembles the corresponding ACPI method into ASL opcodes
!amli lc
Lists all the AML contexts currently inside the interpreter; the running
context is denoted with a “*” in the beginning of the entry line
!amli ds
Displays the interpreter stack in the current running context
!nsobj
Displays namespace object information
These commands are available in the retail (fre)
version of the acpi.sys driver

Backup
ACPI Debugging – Common Commands
!amli ln <method> | <addr>
Unassembles the nearest method to the specified line
!amli set <options>
Sets a variety of options related to ACPI debugging, such as turning
spew on, break on error, break on namespace loading time, etc.
!amli [bp | bl | bc | bd | be]
Commands that work with AML Breakpoints functioning exactly
like the equivalent commands inside regular kd environment
!amli [p | t]
Steps/traces over a line of AML code
!amli r
Displays the current context info, including local variables
These commands require the checked
version of the acpi.sys driver

Backup
ACPI Debugging – Example 1
Determine why a device is not wake-capable
0: kd> !devstack 0x837d4b98
!DevObj !DrvObj !DevExt ObjectName
837de020 Driverpci 837de0d8
837d55e8 DriverACPI 837ceb70
> 837d4b98 Driverpci 837d4c50 NTPNP_PCI0003
!DevNode 837daa88 :
DeviceInst is
"PCIVEN_xxxx&DEV_yyyy&SUBSYS_00000000&REV_xxa&123b45cd&6&e7"
ServiceName is "pci“
2. From the !devstack output we can get the ACPI device extension
0: kd> dt acpi!_DEVICE_EXTENSION 837ceb70
....
+0x164 RemoveEvent : (null)
+0x168 AcpiObject : 0x837c4070 _NSObj
+0x16c DeviceObject : 0x837d55e8 _DEVICE_OBJECT
....
1. We know this device is a PCI bus, and from the output
of !pcitree, we get the following !devstack

3. From the ACPI device extension, we can see
the namespace object corresponding to it
0: kd> !nsobj 0x837c4070
nsobj: dumping object at 837c4070
NameSpace Object PCI3 (00000000837c4070) – Device
ffffffff837ceb70
Flink ffffffff837c4ce8 Blink ffffffff837c33f8
Parent ffffffff837c0920 Child ffffffff837c40bc
Value 0000000000000000 Length 0000000000000000
Buffer 0000000000000000 Flags 0000000000000000
Object Data - 00000000837c4090 Type – 06 <Device>
4. With the namespace object of the device, we can find
all namespace objects corresponding to it
0: kd> !amli find PCI3
_SB.PCI0.PCI3
Backup

Backup
5. With the full namespace path, we can now display the actual object
0: kd> !amli dns /s _SB.PCI0.PCI3
ACPI Name Space: _SB.PCI0.PCI3 (ffffffff837c33f8)
Device(PCI3)
| Method(_S1D:Flags=0x0,CodeBuff=ffffffff837c0d6d,Len=3)
| Method(_S3D:Flags=0x0,CodeBuff=ffffffff837c34ed,Len=14)
| Method(_S4D:Flags=0x0,CodeBuff=ffffffff837c3565,Len=14)
| Method(_S5D:Flags=0x0,CodeBuff=ffffffff837c35dd,Len=14)
| Method(_ADR:Flags=0x0,CodeBuff=ffffffff837c3655,Len=9)
| Integer(_UID:Value=0x0000000000000016[22])
....
6. From examining the namespace object we can see
the object does not have capability to wake the
system, since no _PRW package is present.

Backup
The system has encountered Bug Check 0x7E in acpi.sys
1. Using the kernel debugger, we examine the stack trace:
1: kd> kn
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr
00 f7936cb0 f7365bae ACPI!WriteSystemMem+0x6a
01 f7936ce0 f7365d1a ACPI!AccessBaseField+0x1f7
02 f7936d04 f7365df0 ACPI!AccessFieldData+0x15c
03 f7936d2c f7367d77 ACPI!WriteFieldObj+0xcb
04 f7936d54 f7369622 ACPI!RunContext+0x65
....
2. Since the system was running in the ACPI driver,
we examine the AML context that was running:
1: kd> !amli lc
*Ctxt=ffffffff865be000, ThID=ffffffff865c06a0, Flgs=A--CR----, pbOp=ffffffff865af4a5,
Obj=_SB.PCI0._INI
1: kd> !amli ds
ffffffff865af65b: _SB.MSM1()
ffffffff86541627: _SB.MSM2()
0: _SB.PCI0._INI()
3. And we display the AML interpreter’s stack and
find that it was running the method _SB.MSM1()

Backup
4. From the AML context, we can see the current opcode points at
ffffffff865af4a5. However this would be the next opcode run, so
we unassemble _SB.MSM1() to examine the previous opcode
1: kd> !amli u _SB.MSM1
ffffffff865af469 : If(LEqual(^MSTB, Ones))
ffffffff865af473 : {
ffffffff865af473 : | If(CondRefOf(_OSI, Local0))
ffffffff865af47e : | {
ffffffff865af47e : | | If(_OSI("Windows 2001.1"))
ffffffff865af495 : | | {
ffffffff865af495 : | | | Store(0x20, ^MSV1)
ffffffff865af49d : | | | Store(0x20, ^MSV2)
ffffffff865af4a5 : | | }
ffffffff865af4a5 : | | Else
ffffffff865af4a8 : | | {
ffffffff865af4a8 : | | | If(_OSI("Windows 2001 SP1"))
ffffffff865af4c1 : | | | {
....

Backup
5. From the unassembled AML code, we can tell the problem
is within the Store(0x20, ^MSV2) call. We can display the
information for ^MSV2
1: kd> !amli dns /s _SB.MSV2
ACPI Name Space: _SB.MSV2 (ffffffff865af3d0)
FieldUnit(TPOS:FieldParent=ffffffff865af38c,ByteOffset=0x0,StartBit=0x0,NumBits=8,FieldFlags=0x0)
1: kd> !amli dns /s ffffffff865af38c
ACPI Name Space: _SB. (ffffffff865af38c)
Field(:Base=MSO1)
1: kd> !amli dns /s _SB.MS01
ACPI Name Space: _SB.MSO1 (ffffffff865af348)
OpRegion(OSTY:RegionSpace=SystemMemory,Offset=0x0,Len=-65465)
6. _SB.MSV2 is a field unit, which is a part of the field parent
_SB.MSO1
7. From this, we can tell there is something wrong with the object
_SB.MSO1, since it has a 0 offset and a negative length. At this point
we can go back to looking at the ASL to see how it is defined.

Backup
Additional ACPI Debugger extensions
!acpicache
Displays all of the ACPI tables cached
by the hardware application layer (HAL)
!acpiinf
Displays ACPI information such as the location of system
tables and the contents of the ACPI fixed feature hardware
!acpiirqarb
Displays the contents of the ACPI IRQ arbiter structure
!fadt
Displays the Fixed ACPI Description Table
!mapic
Displays an ACPI Multiple APIC Table
!rsdt
Displays the ACPI Root System Description Table

Backup
Debugging type mismatch warnings
Enable the AML interpreter
to break upon error
Type mismatches can be caught this way
!amli set errbkon
Turn on full AML debugging spew
!amli set spewon

© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

ACPI In Windows Vista

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ACPI In Windows Vista

Similar to ACPI In Windows Vista (20)

Recently uploaded

Recently uploaded (20)

ACPI In Windows Vista