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