From: Rob Landley Copy text from archive.org copy of lesswatts.org inline, replacing dead link. Signed-off-by: Rob Landley --- Documentation/acpi/dsdt-override.txt | 110 ++++++++++++++++++++++++- 1 file changed, 107 insertions(+), 3 deletions(-) diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt index febbb1b..7011e0d 100644 --- a/Documentation/acpi/dsdt-override.txt +++ b/Documentation/acpi/dsdt-override.txt @@ -2,6 +2,110 @@ Linux supports a method of overriding the BIOS DSDT: CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. -When to use this method is described in detail on the -Linux/ACPI home page: -http://www.lesswatts.org/projects/acpi/overridingDSDT.php +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. + +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 at 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 + +or + + # 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. 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