Difference between revisions of "ACPI"

From coreboot
Jump to navigation Jump to search
Line 1: Line 1:
== ACPI setup HOWTO ==
= ACPI setup HOWTO =


Please have a look to files in the src/mainboard/asus/a8v-e_se. Check also the [ http://acpi.info ]  
Please have a look to files in the src/mainboard/asus/a8v-e_se. Check also the [ http://acpi.info ]  
which contains the specification.
which contains the specification.


=== Setup hardware ===
== Setup hardware ==


Setup the PMIO base address to some known address, and setup the desired ACPI IRQ (usually IRQ9).
Setup the PMIO base address to some known address, and setup the desired ACPI IRQ (usually IRQ9).
Sometimes it is called SCI interrupt.
Sometimes it is called SCI interrupt.


=== Fill FADT ===
== Fill FADT ==


Now you will need to create an ACPI table which describes the I/O port location for kernel ACPI implementation. This is the FACP table. You will need to create the fadt.c file and fill in  
Now you will need to create an ACPI table which describes the I/O port location for kernel ACPI implementation. This is the FACP table. You will need to create the fadt.c file and fill in  
Line 32: Line 32:
mostly could be used what are the defaults in the fadt.c
mostly could be used what are the defaults in the fadt.c


=== Fill DSDT ===
== Fill DSDT ==


The DSDT table contains a bytecode that is executed by driver in the kernel. This table stores also
The DSDT table contains a bytecode that is executed by driver in the kernel. This table stores also
Line 101: Line 101:
for you.
for you.


==== CPU Power Management ====
=== CPU Power Management ===


The CPU power management is hardware specific. It is described in APCI specs and also in AMD BIOS and Kernel Developer guide. The rest of this section describes the AMD specific part. AMD needs ACPI objects which describes the similar info as the legacy PowerNow table. Check the BKDG for details.
The CPU power management is hardware specific. It is described in APCI specs and also in AMD BIOS and Kernel Developer guide. The rest of this section describes the AMD specific part. AMD needs ACPI objects which describes the similar info as the legacy PowerNow table. Check the BKDG for details.
Line 110: Line 110:
Up to revE, all P state info must be hardcoded in tables (not supported).
Up to revE, all P state info must be hardcoded in tables (not supported).


===== C States =====
=== C States ====
C states are processor power states. C1 is mandantory and reached on IA32 compatible processors using the HLT instruction, C2 and C3 are optional and must be configured.
C states are processor power states. C1 is mandantory and reached on IA32 compatible processors using the HLT instruction, C2 and C3 are optional and must be configured.


Line 121: Line 121:
_CST is necessary if you want to support more than 3 C states, or if the transition procedure doesn't follow the ACPI requirement
_CST is necessary if you want to support more than 3 C states, or if the transition procedure doesn't follow the ACPI requirement


==== PCI root bus _CRS method ====
=== PCI root bus _CRS method ===


The Windows needs to know the actual decode ranges for PCI root bus (and any other). Windows needs to know platform independent way, how is I/O routed on PCI0 bus (and other busses). For K8 it means to read the I/O and MMIO routing registers (same as k8resdump provides) and make it ACPI object. This was perhaps done previously on Aruma board. The actual PCI regs are read in acpi-k8 in modelf and stored as SSDT table. The k8-util.asl code will construct the resources from that SSDT table.  
The Windows needs to know the actual decode ranges for PCI root bus (and any other). Windows needs to know platform independent way, how is I/O routed on PCI0 bus (and other busses). For K8 it means to read the I/O and MMIO routing registers (same as k8resdump provides) and make it ACPI object. This was perhaps done previously on Aruma board. The actual PCI regs are read in acpi-k8 in modelf and stored as SSDT table. The k8-util.asl code will construct the resources from that SSDT table.  
Line 127: Line 127:
One can use the k8-util.asl code which will construct the resource objects. Check the ASUS M2V-MX mainboard ACPI code.
One can use the k8-util.asl code which will construct the resource objects. Check the ASUS M2V-MX mainboard ACPI code.


==== DSDT debugging ====
=== DSDT debugging ===


There are two ways. You can store values in "debug" object, which will print it in dmesg.
There are two ways. You can store values in "debug" object, which will print it in dmesg.
Line 143: Line 143:
http://support.microsoft.com/kb/314830
http://support.microsoft.com/kb/314830


=== Other tables ===
== Other tables ==


Rest of the ACPI tables is located at acpi_tables.c. I will describe briefly all methods:
Rest of the ACPI tables is located at acpi_tables.c. I will describe briefly all methods:


==== acpi_fill_mcfg ====
=== acpi_fill_mcfg ===


If your platform supports MMCONFIG (memory mapped PCI configuration registers) just modify the
If your platform supports MMCONFIG (memory mapped PCI configuration registers) just modify the
function with correct base address.
function with correct base address.


==== acpi_fill_madt ====
=== acpi_fill_madt ===


This table describes the ACPI IRQ information, as well as IRQ override. For code example check the M2V-MX SE acpi_tables. You will need to create the sub-table for LAPIC (the APIC counterpart in CPU) and describe the APICs
This table describes the ACPI IRQ information, as well as IRQ override. For code example check the M2V-MX SE acpi_tables. You will need to create the sub-table for LAPIC (the APIC counterpart in CPU) and describe the APICs
Line 169: Line 169:
Last thing in this table are IRQ overrides. Usually there are two IRQ overrides. IRQ0 override means that IRQ0 is not connected to pin 0 on APIC but to another, most likely pin 2. Check the figure above why. Second IRQ override is for ACPI IRQ. This overrides the 'level' of the interrupt to 'active low'.  The rest of the table is filled with NMI entries for the processor.
Last thing in this table are IRQ overrides. Usually there are two IRQ overrides. IRQ0 override means that IRQ0 is not connected to pin 0 on APIC but to another, most likely pin 2. Check the figure above why. Second IRQ override is for ACPI IRQ. This overrides the 'level' of the interrupt to 'active low'.  The rest of the table is filled with NMI entries for the processor.


==== write_acpi_tables ====
=== write_acpi_tables ===


This is the main function which constructs the tables. Functions described above are callbacks from the
This is the main function which constructs the tables. Functions described above are callbacks from the
"construct" functions called here. You may ommit the HPET and MCFG tables.
"construct" functions called here. You may ommit the HPET and MCFG tables.


==== FACS table ====
=== FACS table ===
This table must be aligned to 64B boundary (Windows check this).
This table must be aligned to 64B boundary (Windows check this).


=== Suspend to RAM ===
= Suspend to RAM =


There are patches on ML which add support for suspend to RAM in coreboot. The resume start of the computer does not differ until OS waking vector is executed instead of payload.
There are patches on ML which add support for suspend to RAM in coreboot. The resume start of the computer does not differ until OS waking vector is executed instead of payload.
Line 195: Line 195:
* SMP might need some fixes
* SMP might need some fixes


=== ACPI bytecode generator ===
= ACPI bytecode generator =


Some ACPI stuff is generated runtime. To achieve this goal we have a AML code generator which generates binary
Some ACPI stuff is generated runtime. To achieve this goal we have a AML code generator which generates binary
Line 206: Line 206:
stack internally so more structures can be nested. Look to acpigen.c and learn what functions call  acpigen_write_len_f() - those needs patching.
stack internally so more structures can be nested. Look to acpigen.c and learn what functions call  acpigen_write_len_f() - those needs patching.


=== Debugging ACPI ===
= Debugging ACPI =


When CONFIG_ACPI_DEBUG is compiled into the kernel, the ACPI debug level can be specified on the kernel command line:
When CONFIG_ACPI_DEBUG is compiled into the kernel, the ACPI debug level can be specified on the kernel command line:
Line 249: Line 249:
  debug_level = 0x00000007 (* = enabled)
  debug_level = 0x00000007 (* = enabled)


=== More to Read ===
= More to Read =


* Some good FAQ: http://www.acpi.info/acpi_faq.htm
* Some good FAQ: http://www.acpi.info/acpi_faq.htm

Revision as of 12:56, 19 April 2009