Archive for the ACPI Category

Note: Intel defined an ACPI _DSM for Android power button event on x86 platform

Posted in ACPI, android with tags , , , on 2014 年 06 月 24 日 by Kun-Yi

_DSM Parameters
Arg0(Buffer) : UUID : “9c355bcb-35fa-44f7-8a67-447359c36a03″
Arg1(Integer): Revision: 0
Arg2(Integer): Function Index :
0: PWRB_PROBE, detect support power button state method
1: PWRB_REGISTER, enable/register Power button release notify
2: PWRB_LEVEL, get current level of power button
Arg3(package): NULL

Return of Function index
Function 0: PWRB_PROBE
Type: Buffer,
return a bitmask of supported functions as a buffer. Return a failure here as 0:
method not present or not function correctly means “no functions support"

bitmask:
bit 0: supported PWRB_REGISTER(DSM notify)
bit 1: supported PWRB_LEVEL (DSM polling)
Just need support one method, if all support OS driver will use DSM notify method.

Function 1: PWRB_REGISTER
Type: Integer,
0 is success register a support control method power button device.
Notify(PWRB_Obj, 0x80) // 0x80 for press state
Notify(PWRB_Obj, 0xC0) // 0xC0 for release state

Function 2: PWRB_LEVEL
Type: Integer,
1 or 0,  return 1 when press button , others return 0

Note: ACPI 5.0 introduction Hardware-reduced ACPI

Posted in ACPI, ARM, BIOS on 2011 年 12 月 13 日 by Kun-Yi

ACPI 從 5.0 開始支援非 x86 系統, 如現在最熱門的ARM, 為此他必須移除本來x86系統下由Intel 主導的HW相關設計, 如原本的ACPI Controller 的 GPE 區塊, ACPI 規範稱此為 Hardward-reduced ACPI, 可以看出這是Microsoft為了讓 Windows 8 可以跨x86 & ARM 兩種不同平台的努力(由規格中的提案人可得知, MSFT-0001 HW-reduced ACPI, 另外可以該提案後的影響章節直接快速定位到想要了解的部分)

下面是 3.11.1的內容

ACPI offers an alternative platform interface model that removes ACPI hardware requirements for platforms that do not implement the PC Architecture. In the Hardware-reduced ACPI model, the Fixed hardware interface requirements of Chapter 4 are removed, and Generic hardware interfaces are used instead. This provides the level of flexibility needed to innovate and differentiate in low-power hardware designs while enabling support by multiple Operating Systems.

  • UEFI firmware interface for boot (Legacy BIOS is not supported).
  • Boot in ACPI mode only (ACPI Enable, ACPI Disable, SMI_CMD and Legacy mode are not
    supported)
  • No hardware resource sharing between OSPM and other asynchronous operating environments, such as UEFI Runtime Services or System Management Mode. (The Global Lock is not supported)
  • No dependence on OS-support for maintaining cache coherency across processor sleep states (Bus Master Reload and Arbiter Disable are not supported)

由上可以看出 UEFI + ACPI mode only 可以看出已經拋棄x86 PC 相容的包袱(沒有LegacyBIOS ACPI 必須在 E/F Segement的要求, ARM 本身也沒有 SMI的設計),  沒有SM/Runtime Services 主要應該MSFT不想要系統中還有一個可以讓 OS有不知不覺的管理層, 這樣對MSFT來說增加了被Rookit的風險, 最後應該可以有更理想的電源管理方式

Hardward-reduced ACPI 主要影響的章節

  • 3.11.x,
  • 4, 4.1.x, 4.3.7,
  • 5.2.9, 5.2.9.1,
  • 6.4.2.1, 6.4.3.6,
  • 7.2.11, 7.3.4,
  • 9.6,
  • 12, 12.1, 12.6, 12.11, 12.11.1,
  • 15, 15.1.x, 15.3, 15.3.1.x,
  • 18.5.55, 18.5.57

Note: About Integrated USB Device & System Fund 0200 WHQL item

Posted in ACPI, BIOS, WHQL on 2011 年 09 月 22 日 by Kun-Yi

Win7 有個測試項目 Single computer Display Object item (SystemFund-0200) , 專門測試系統內建的周邊是否有正確報告. 整合式的周邊因為不能被使用者任意移除所以不會出現在 Device & Printer 的ICON 列表中, 或者是出現在可以安全移除的裝置中!

一般BIOS 工程師會遇到的是 SATA & USB port, SATA 會有對應的控制 bit  可以設定, USB  則要透過 ACPI 去宣告 port 的屬性

Microsoft 已經提供有下列一些文件解釋

要補註的是 ACPI Spec. 應該要參考 4.x (Page 362 at 4.0a), 主要差異在於3.x中提到的 Integrated HUB 的Device Object 已經移除, 如果ASL code中有這一層, 實際上測試是錯誤的
非正式的做法是 _UPC 傳回的是 unconnectable
目前正式做法就是同時透過 _UPC & _PLD 宣告成 connectable, 與 invisiable, Microsoft 有提供下圖的流程解釋
Ref: Container IDs Generated from a Bus-Specific Unique ID

Note: Multi Batteries on Windows XP

Posted in ACPI, Battery, BIOS on 2011 年 07 月 29 日 by Kun-Yi

最近的案子有個 Dual Batteries 的需求, Battery 是設計由 EC  透過 ACPI Control method Battery 去report 給OS

基本行為是當A, B 兩顆電池同時存在時, 會先優先放電 B電池, 當B電池將到0%時, EC將會切換 放電路徑到A電池

而這個Issues 發生在當一切換電池時, OS就會發生 Crisis Battery Level Event(系統是設定 10%為Low Battery Level, 3%是Crisis Battery Level), 而此時A電池仍然為滿電力狀態. 但是確一直發生 Crisis Battery Event.

經查 ACPI 的ASL code 發現當 Battery Status change的 QEvent 發生, ASL將 Notify (\_SB.BATx, 0x80), Notify(\_SB.BATx, 0x81), Notify (\_SB.BATx, 0x80), 跟據 ACPI 4.0 spec. 指出 0x81的notify 是 Battery Information Change, 應該當Battery Replace才發生, 在XP下時, OS會因為該Event 重新抓取 Battery information 但也因此會發生 Crisis Event, 但當系統是單Battery時, 該Event並不會觸發 Crisis Battery Event. 解決之道有幾種方法, 將Battery Replace的Event重新指定另一個QEvent, 也可以在ASL中, 去儲存Battery 的Exist與否, 當狀態改變後在發出 0x81的 Notify code.

上述問題經測試在 Windows 7 上並未發生, 看來Microsoft 有改過一些OS Driver的行為模式

Note: An ACPI Debug method

Posted in ACPI, BIOS on 2011 年 07 月 10 日 by Kun-Yi

在 ACPI Spec. 有定義一個Debug Object, 因此寫ASL code時可以直接使用它來Dump Debug message, 目前在Linux 的Platform 上有實作出該Object, 並將其所收到的值/字串轉向到dmesg中. 這個方法應該比在Windows 下透過 check build的 acpi.sys 方便多了!

另外當 ACPI 在初期開發階段, 很容易因為錯誤導致 Windows BSOD, Microsoft 有在KB 314830 列出一個錯誤碼的參考文件

另外一個方法是透過 acpiexec, 在 iasl 的package 可以找到該執行檔, 我在windows上試過, 不跟硬體相關的測試, 可以當做study ASL code 的 tools, 但是看起來在linux下, 功用更大 http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html

Note: TPM with ACPI enabled OS

Posted in ACPI, BIOS, TPM on 2011 年 05 月 23 日 by Kun-Yi

目前 TCG 有要求, TPM Device應該實作下列的 _DSM method 給 ACPI award 的OS使用, DTM/WHQL 會測

分別是

MOR bit: Memory Overwrite Request (MOR) bit

Ref. http://msdn.microsoft.com/en-us/library/ff567986(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/dd424551.aspx

Note: 淺談 _GPE of ACPI

Posted in ACPI, BIOS on 2011 年 03 月 22 日 by Kun-Yi

在ACPI 的 DSDT Table 會有一個 _GPE Object 是用來讓OSPM 做 General-Purpose Event Handling (see Section 5.6.4 in ACPI 4.0a spec.)的動作指引.

這裏是用 Thinkpad X60 當做解說材料, 對應到 ICH7 (Intel ICH7 datasheet), Dump ACPI的方法可以參考之前的 Note: Dump ACPI Tables , iasl 我現在用的是 Intel 20090730 版本

_GPE 是HW/SW共同建構的, 主要是用來辨識SCI發生後, 系統需要另外處理的事件, 在Intel platform 裡 ICH 會包含一個 ACPI 對應I/O Registers, ICH7 稱Power Management I/O Registers (see 10.8.3 in Datasheet), 而ICH7 負責GPE的, 是 GPE0_STS/GPE0_EN 兩個暫存器, 這個可以在 FADT/ACPI Table找到對應的 GPE0_BLK (Section 4.7.4 in ACPI 4.0a)

_GPE在Section 5.6.4.1 in ACPI 4.0a 說明了, Event 的種類會有 _Exx/_Lxx/_Qxx 三種, E是Edge的縮寫, L是Level, Q則是 Query (from Query commad 0x84 of EC, Q event 對應 SMBUS Device與EC),  在Intel Platform上用到的主要是L與 Q event

下面是X60 用的 _GPE 描述

Scope (\_GPE)
{
Method (_L18, 0, NotSerialized)
{
Store (\_SB.PCI0.LPC.EC.HWAK, Local0)  // X60 的EC 透過 Read 這各 Byte 來清除 EC的 Wakeup event 處理, see coreboot patch
Store (Local0, \RRBF)
Sleep (0x0A)
If (And (Local0, 0x02)) {}
If (And (Local0, 0x04))
{
If (\W98F)
{
Notify (\_SB.SLPB, 0x02)
}
Else
{
Notify (\_SB.LID, 0x02)
}
}

If (And (Local0, 0x10))
{
And (Local0, 0xF7, Local0)
Notify (\_SB.SLPB, 0x02)
}

If (And (Local0, 0x08))
{
\_SB.GDCK.GGPE ()
Notify (\_SB.SLPB, 0x02)
}

If (And (Local0, 0x40)) {}
If (And (Local0, 0x80))
{
Notify (\_SB.SLPB, 0x02)
}
}

Method (_L09, 0, NotSerialized)
{
If (\_SB.PCI0.EXP0.PSP0)
{
Store (0x01, \_SB.PCI0.EXP0.PSP0)
Notify (\_SB.PCI0.EXP0, 0x02)
}

If (\_SB.PCI0.EXP1.PSP1)
{
Store (0x01, \_SB.PCI0.EXP1.PSP1)
Notify (\_SB.PCI0.EXP1, 0x02)
}

If (\_SB.PCI0.EXP2.PSP2)
{
Store (0x01, \_SB.PCI0.EXP2.PSP2)
Notify (\_SB.PCI0.EXP2, 0x02)
}

If (\_SB.PCI0.EXP3.PSP3)
{
Store (0x01, \_SB.PCI0.EXP3.PSP3)
Notify (\_SB.PCI0.EXP3, 0x02)
}
}

Method (_L01, 0, NotSerialized)
{
If (\_SB.PCI0.EXP2.HPCS)
{
Store (0x01, \_SB.PCI0.EXP2.HPCS)
If (\_SB.PCI0.EXP2.ABP)
{
Store (0x01, \_SB.PCI0.EXP2.ABP)
}

If (\_SB.PCI0.EXP2.PDC)
{
Store (0x01, \_SB.PCI0.EXP2.PDC)
Store (0x00, \_SB.PCI0.EXP2.XCPF)
Notify (\_SB.PCI0.EXP2, 0x00)
If (\_SB.PCI0.EXP2.PDS)
{
Store (0x01, \_SB.PCI0.EXP2.XCPF)
Sleep (0x64)
Notify (\_SB.PCI0.EXP2.EXUP, 0x01)
}
}
}
}

Method (_L02, 0, NotSerialized)
{
Store (0x00, \_SB.PCI0.LPC.SWGE)
If (\_SB.PCI0.LPC.EC.HKEY.DHKC)
{
If (DT02)
{
\_SB.PCI0.LPC.EC.HKEY.MHKQ (0x6022)
}
}

Notify (\_TZ.THM1, 0x80)
If (\OSPX)
{
Notify (\_PR.CPU0, 0x80)
If (\MPEN)
{
Notify (\_PR.CPU1, 0x80)
}
}
}
}

可以看到 _L18 是從EC讀 Wake-up event 產生的原因, 而 _L18 從 ICH7 的Datasheet (Section 10.8.3)看來應該是接到GPIO8

image

_L09, 則是對應 PCI Express 的PME Event,

image

_L01 則是PCI 相關的 HotPlug Event, _L02 則是SWGPE Event 看來是 Thermal 的對應策略!

image

在 Section 5.6.4 in ACPI 4.0a 有描述 OSPM 應該怎樣處理, 節錄於下

OSPM manages the bits in the GPEx blocks directly, although the source to those events is not directly
known and is connected into the system by control methods. When OSPM receives a general-purpose event
(the event is from a GPEx_BLK STS bit), OSPM does the following:
1. Disables the interrupt source (GPEx_BLK EN bit).
2. If an edge event, clears the status bit.
3. Performs one of the following:
 Dispatches to an ACPI-aware device driver.
 Queues the matching control method for execution.
 Manages a wake event using device _PRW objects.
4. If a level event, clears the status bit.
5. Enables the interrupt source.
For OSPM to manage the bits in the GPEx_BLK blocks directly:
 Enable bits must be read/write.
 Status bits must be latching.
 Status bits must be read/clear, and cleared by writing a “1” to the status bit.