27.10.2015 Views

Advanced Configuration and Power Interface Specification

ACPI_6.0

ACPI_6.0

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

ACPI Software Programming Model<br />

Field<br />

Firmware Waking<br />

Vector<br />

Byte<br />

Length<br />

Byte<br />

Offset<br />

Description<br />

4 12 This field is superseded by the X_Firmware_Waking_Vector<br />

field.<br />

The 32-bit address field where OSPM puts its waking vector.<br />

Before transitioning the system into a global sleeping state,<br />

OSPM fills in this field with the physical memory address of an<br />

OS-specific wake function. During POST, the platform firmware<br />

first checks if the value of the X_Firmware_Waking_Vector field<br />

is non-zero <strong>and</strong> if so transfers control to OSPM as outlined in<br />

the X_Firmware_Waking_vector field description below. If the<br />

X_Firmware_Waking_Vector field is zero then the platform<br />

firmware checks the value of this field <strong>and</strong> if it is non-zero,<br />

transfers control to the specified address.<br />

On PCs, the wake function address is in memory below 1 MB<br />

<strong>and</strong> the control is transferred while in real mode. OSPM’s wake<br />

function restores the processors’ context.<br />

For IA-PC platforms, the following example shows the<br />

relationship between the physical address in the Firmware<br />

Waking Vector <strong>and</strong> the real mode address the BIOS jumps to.<br />

If, for example, the physical address is 0x12345, then the BIOS<br />

must jump to real mode address 0x1234:0x0005. In general this<br />

relationship is<br />

Real-mode address =<br />

Physical address>>4 : Physical address <strong>and</strong> 0x000F<br />

Notice that on IA-PC platforms, A20 must be enabled when the<br />

BIOS jumps to the real mode address derived from the physical<br />

address stored in the Firmware Waking Vector.<br />

Global Lock 4 16 This field contains the Global Lock used to synchronize access<br />

to shared hardware resources between the OSPM environment<br />

<strong>and</strong> an external controller environment (for example, the SMI<br />

environment). This lock is owned exclusively by either OSPM or<br />

the firmware at any one time. When ownership of the lock is<br />

attempted, it might be busy, in which case the requesting<br />

environment exits <strong>and</strong> waits for the signal that the lock has<br />

been released. For example, the Global Lock can be used to<br />

protect an embedded controller interface such that only OSPM<br />

or the firmware will access the embedded controller interface at<br />

any one time. See Section 5.2.10.1, “Global Lock,” for more<br />

information on acquiring <strong>and</strong> releasing the Global Lock.<br />

Flags 4 20 Firmware control structure flags. See Table 5-39 for a<br />

description of this field.<br />

Version 6.0 131

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!