ACPI Hardware Overview

Sau DXE, firmware không chỉ boot OS rồi biến mất. Nó còn phải để lại một bản mô tả platform đủ tin cậy để OS hiểu: CPU nào tồn tại, memory nằm ở đâu, PCI root bridge có resource nào, EC giao tiếp ra sao, GPIO nào dùng cho wake, thiết bị nào có power state nào.

ACPI và SMBIOS chính là hai lớp dữ liệu lớn nhất trong phần này. SMBIOS trả lời “máy này là máy gì”, còn ACPI trả lời “OS phải điều khiển phần cứng này như thế nào”.

Bản đồ kiến thức

ACPI Hardware
├─ ACPI Table Types: DSDT, SSDT, FADT, MADT, MCFG, DBG2
├─ AML / Namespace / Method
│  ├─ Device, Scope, Name, Method
│  ├─ _HID, _CID, _STA, _CRS
│  └─ _DSM, _PS0/_PS3, _PRW
├─ Hardware Control
│  ├─ EC handshake
│  ├─ GPIO OperationRegion
│  └─ Power sequence / Power state
├─ Bus Description
│  ├─ PCIe enumeration
│  └─ USB init in DXE
└─ Inventory
   └─ SMBIOS Type 0-4, 17, 19-20

ACPI khác PCI/SMBIOS ở đâu?

Debug diary: OS không nhận phần cứng

Một lỗi rất dễ gặp là firmware nhìn thấy thiết bị trong DXE, nhưng OS lại không tạo driver node đúng. Lúc đó đừng chỉ nhìn một tầng.

DXE PCI scan OK
↓
ACPI _CRS sai hoặc thiếu
↓
OS không cấp resource đúng
↓
Driver không bind hoặc device bị disable

Ví dụ thực tế: PCIe device có BAR hợp lệ trong firmware, nhưng ACPI root bridge _CRS không expose đúng MMIO window. OS sẽ nghĩ resource không hợp lệ dù thiết bị thật sự vẫn tồn tại.

Blog seeds

• ACPI không chỉ là table: nó là hợp đồng giữa firmware và OS.
• Vì sao firmware thấy device nhưng Windows/Linux không thấy?
• DSDT/SSDT/SMBIOS/PCI phối hợp với nhau như thế nào?

Bài liên quan

• ACPI Table Types cần biết
• ACPI Namespace là gì?
• PCI Architecture Overview
• HII Architecture Overview