LessWatts.org - Saving Power on Intel systems with Linux

Linux ACPI

Overriding a DSDT

Why override a DSDT?

The DSDT (Differentiated System Description Table) is the primary AML table in the BIOS. Per the description of acpidump, the DSDT can be extracted from the machine, the ASL modified, and a new AML DSDT can be compiled. The sections below show two ways to tell Linux to use this modified DSDT instead of the version that came with the BIOS.

Note that overriding the DSDT is a debugging technique only. It is not a viable way to run a production system, as no vendor would support a system when the customer has modified the system firmware, and no Linux Distributor could possibly support modified system firmware either.

In the early days of Linux/ACPI, DSDT modifications were common to work around both BIOS bugs and Linux bugs. However, the stated goal of the Linux/ACPI project today is that Linux should run on un-modified firmware. Thus, the DSDT database at the old http://acpi.sourceforge.net web site is now largely a historical artifact.

Where do I get iasl for dis-assembling and compiling tables?

iASL is part of the ACPICA release,
http://acpica.org.
Note that "iasl -d" can now not only dis-assemble a DSDT and SSDT, but also most other ACPI table images.

What if I also want to override the SSDTs?

If you need to modify the code present in an SSDT, then combine all of the SSDTs into a DSDT override, modify it as necessary, and boot with "acpi_no_auto_ssdt" to prevent Linux from automatically loading the SSDTs listed in the RSDT/XSDT.

Is it important if my DSDT doesn't re-compile

Not necessarily. Many static ASL bugs that are rejected by iASL have workarounds present in the Linux kernel. This is because even if you might be able to modify and override your DSDT, most users with a system like yours cannot.

Of course you need to get the DSDT to re-compile if you want to run your modifications.

How to print to the Linux console from AML

When CONFIG_ACPI_DEBUG=y and when acpi.debug_level & 0x8, ASL stores to the special object "Debug" will come out in the dmesg. eg

Store("hello world!", Debug)

Store(Local0, Debug)

[ACPI Debug] String: [0x0C] "hello world!"

[ACPI Debug] Integer: 0x00000042

How to Build a custom DSDT into the kernel

Get original DSDT:

# cp /proc/acpi/dsdt DSDT

# acpidump > acpidump.out

$ acpixtract DSDT acpidump > DSDT.dat

Disassemble it
```
$ iasl -d DSDT.dat
```
Make your changes:
```
$ vi DSDT.dsl
```
Build it:
```
$ iasl -tc DSDT.dsl
```
Put it where the kernel build can include it:
```
$ cp DSDT.hex $SRC/include/
```

Add this to the kernel .config:

CONFIG_STANDALONE=n
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="DSDT.hex"

Make the kernel and off you go!

You should see in dmesg:
Table [DSDT] replaced by host OS

How to build a custom DSDT into an initrd

If you are unable to re-build the kernel, or you'd like to run the same kernel binary on multiple machines that require different DSDT overrides, then the initrd method should suit your needs.

For kernels before Linux-2.6.25, this method requires the out-of-tree patch found here: http://gaugusch.at/kernel.shtml (thanks to Markus Gaugusch and Eric Piel)

Some distributors, such as SuSE and Ubuntu, included that patch, and you can tell if it is present by finding the following line in the console log:
"Looking for DSDT in initramfs..."

In Linux-2.6.25 and later, this method is enabled using CONFIG_ACPI_CUSTOM_DSDT_INITRD, and you can tell if a kernel binary includes it by finding the following line in the console log:
"ACPI: Checking initramfs for custom DSDT"

The process for creating the DSDT image is the same as above. But note that the format of the table included in the initramfs is binary (iasl -ta), while if you build a DSDT into the kernel, C-source code is used (iasl -tc).

In case your mkinitrd tool does not support this feature, a script is provided in the kernel source tree, Documentation/acpi/initramfs-add-dsdt.sh