Documentation/acpi/ssdt-overlays.txt

   1
   2 In order to support ACPI open-ended hardware configurations (e.g. development
   3 boards) we need a way to augment the ACPI configuration provided by the firmware
   4 image. A common example is connecting sensors on I2C / SPI buses on development
   5 boards.
   6
   7 Although this can be accomplished by creating a kernel platform driver or
   8 recompiling the firmware image with updated ACPI tables, neither is practical:
   9 the former proliferates board specific kernel code while the latter requires
  10 access to firmware tools which are often not publicly available.
  11
  12 Because ACPI supports external references in AML code a more practical
  13 way to augment firmware ACPI configuration is by dynamically loading
  14 user defined SSDT tables that contain the board specific information.
  15
  16 For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus of the
  17 Minnowboard MAX development board exposed via the LSE connector [1], the
  18 following ASL code can be used:
  19
  20 DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x00000003)
  21 {
  22     External (\_SB.I2C6, DeviceObj)
  23
  24     Scope (\_SB.I2C6)
  25     {
  26         Device (STAC)
  27         {
  28             Name (_ADR, Zero)
  29             Name (_HID, "BMA222E")
  30
  31             Method (_CRS, 0, Serialized)
  32             {
  33                 Name (RBUF, ResourceTemplate ()
  34                 {
  35                     I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
  36                                   AddressingMode7Bit, "\\_SB.I2C6", 0x00,
  37                                   ResourceConsumer, ,)
  38                     GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
  39                              "\\_SB.GPO2", 0x00, ResourceConsumer, , )
  40                     { // Pin list
  41                         0
  42                     }
  43                 })
  44                 Return (RBUF)
  45             }
  46         }
  47     }
  48 }
  49
  50 which can then be compiled to AML binary format:
  51
  52 $ iasl minnowmax.asl
  53
  54 Intel ACPI Component Architecture
  55 ASL Optimizing Compiler version 20140214-64 [Mar 29 2014]
  56 Copyright (c) 2000 - 2014 Intel Corporation
  57
  58 ASL Input:     minnomax.asl - 30 lines, 614 bytes, 7 keywords
  59 AML Output:    minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes
  60
  61 [1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29
  62
  63 The resulting AML code can then be loaded by the kernel using one of the methods
  64 below.
  65
  66 == Loading ACPI SSDTs from initrd ==
  67
  68 This option allows loading of user defined SSDTs from initrd and it is useful
  69 when the system does not support EFI or when there is not enough EFI storage.
  70
  71 It works in a similar way with initrd based ACPI tables override/upgrade: SSDT
  72 aml code must be placed in the first, uncompressed, initrd under the
  73 "kernel/firmware/acpi" path. Multiple files can be used and this will translate
  74 in loading multiple tables. Only SSDT and OEM tables are allowed. See
  75 initrd_table_override.txt for more details.
  76
  77 Here is an example:
  78
  79 # Add the raw ACPI tables to an uncompressed cpio archive.
  80 # They must be put into a /kernel/firmware/acpi directory inside the
  81 # cpio archive.
  82 # The uncompressed cpio archive must be the first.
  83 # Other, typically compressed cpio archives, must be
  84 # concatenated on top of the uncompressed one.
  85 mkdir -p kernel/firmware/acpi
  86 cp ssdt.aml kernel/firmware/acpi
  87
  88 # Create the uncompressed cpio archive and concatenate the original initrd
  89 # on top:
  90 find kernel | cpio -H newc --create > /boot/instrumented_initrd
  91 cat /boot/initrd >>/boot/instrumented_initrd
  92
  93 == Loading ACPI SSDTs from EFI variables ==
  94
  95 This is the preferred method, when EFI is supported on the platform, because it
  96 allows a persistent, OS independent way of storing the user defined SSDTs. There
  97 is also work underway to implement EFI support for loading user defined SSDTs
  98 and using this method will make it easier to convert to the EFI loading
  99 mechanism when that will arrive.
 100
 101 In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line
 102 parameter can be used. The argument for the option is the variable name to
 103 use. If there are multiple variables with the same name but with different
 104 vendor GUIDs, all of them will be loaded.
 105
 106 In order to store the AML code in an EFI variable the efivarfs filesystem can be
 107 used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all
 108 recent distribution.
 109
 110 Creating a new file in /sys/firmware/efi/efivars will automatically create a new
 111 EFI variable. Updating a file in /sys/firmware/efi/efivars will update the EFI
 112 variable. Please note that the file name needs to be specially formatted as
 113 "Name-GUID" and that the first 4 bytes in the file (little-endian format)
 114 represent the attributes of the EFI variable (see EFI_VARIABLE_MASK in
 115 include/linux/efi.h). Writing to the file must also be done with one write
 116 operation.
 117
 118 For example, you can use the following bash script to create/update an EFI
 119 variable with the content from a given file:
 120
 121 #!/bin/sh -e
 122
 123 while ! [ -z "$1" ]; do
 124         case "$1" in
 125         "-f") filename="$2"; shift;;
 126         "-g") guid="$2"; shift;;
 127         *) name="$1";;
 128         esac
 129         shift
 130 done
 131
 132 usage()
 133 {
 134         echo "Syntax: ${0##*/} -f filename [ -g guid ] name"
 135         exit 1
 136 }
 137
 138 [ -n "$name" -a -f "$filename" ] || usage
 139
 140 EFIVARFS="/sys/firmware/efi/efivars"
 141
 142 [ -d "$EFIVARFS" ] || exit 2
 143
 144 if stat -tf $EFIVARFS | grep -q -v de5e81e4; then
 145         mount -t efivarfs none $EFIVARFS
 146 fi
 147
 148 # try to pick up an existing GUID
 149 [ -n "$guid" ] || guid=$(find "$EFIVARFS" -name "$name-*" | head -n1 | cut -f2- -d-)
 150
 151 # use a randomly generated GUID
 152 [ -n "$guid" ] || guid="$(cat /proc/sys/kernel/random/uuid)"
 153
 154 # efivarfs expects all of the data in one write
 155 tmp=$(mktemp)
 156 /bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp
 157 dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp)
 158 rm $tmp
 159
 160 == Loading ACPI SSDTs from configfs ==
 161
 162 This option allows loading of user defined SSDTs from userspace via the configfs
 163 interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be
 164 mounted. In the following examples, we assume that configfs has been mounted in
 165 /config.
 166
 167 New tables can be loading by creating new directories in /config/acpi/table/ and
 168 writing the SSDT aml code in the aml attribute:
 169
 170 cd /config/acpi/table
 171 mkdir my_ssdt
 172 cat ~/ssdt.aml > my_ssdt/aml