dsdt

https://www.tonymacx86.com/threads/pressing-f4-when-booting-clover.140954/

    RehabMan said:
    F4 at the Clover bootloader screen dumps native ACPI files to EFI/Clover/ACPI/origin. In the guide you mention, these files are used by the ProBook Installer in later stages for automatic DSDT/SSDT patching.

You're right. They are native ACPI files. I exported my DSDT using linux "sudo cat /sys/firmware/acpi/tables/DSDT > DSDT.aml" and it matches /EFI/Clover/ACPI/origin/DSDT.aml. The two files are exactly the same.

I used to export the native DSDT in Mavericks using:

    $ sudo perl -e 'open(CMD, "ioreg -lw0 \| grep DSDT|") or die; while(<CMD>) { chomp; if($_ =~ /\"DSDT\.?\d?\"=<([^>]*)>/) { $buff = $1; open(PIP, "|xxd -r -p > ~/Desktop/dsdt.aml") or die; print PIP "$1"; } }'

but it doesn't work in Yosemite. I think that Probook Installer uses the /EFI/Clover/ACPI/origin/DSDT.aml as the starting point then apply patches with patchmatic.

dsdthowto

https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/

Overview

In order to make many OS X features work well on a laptop, you will always need a properly patched DSDT (and maybe some of the SSDTs). The purpose of this guide is to provide a foundation for proper patching of your OEM DSDT/SSDTs.

Advanced users may wish to implement hotpatching via Clover. See guide here: http://www.tonymacx86.com/threads/guide-using-clover-to-hotpatch-acpi.200137/

Although you may be tempted to use a DSDT from another computer, it will almost always end in failure. You simply cannot be certain it is valid to use ACPI files from another computer. Even minor differences in hardware configuration (BIOS version, amount of memory installed, BIOS options selected, and other hardware differences such as which WiFi card is installed) can make for differences that cause instability and weird bugs if you use foreign ACPI files. Such differences can make various OperationRegion addresses different, which makes a patched DSDT for one system incompatible with another. It is also not uncommon for the same laptop model to be produced in different runs with different motherboards, and potentially incompatible ACPI files.

Keep in mind that even changes you make to your own system (BIOS, hardware, etc.) will require re-extract, re-patch.

If any of the following is changed, you must re-extract, re-patch, as these changes may cause significant changes to the native ACPI (especially SystemMemory regions):
- updating BIOS
- changing any BIOS option
- changing hardware or memory configuration

The process of patching involves several steps:
- extracting native files
- disassembling the native files
- analyzing the native files
- patching
- saving (compiling) and installing


Extracting native ACPI files

All BIOS implementations provide ACPI files to the OS. So, on any OS, you can extract them for patching later. Extraction can therefore be done on Linux, OS X, Windows, or even in the Clover bootloader. Native files extracted are generally identical, although because of the software used to extract, they may be named differently.

This guide will focus on three methods of extraction: using F4 with Clover, using patchmatic in OS X, or using Linux.
Only the first is the recommended method. The others are provided for your information only.

Extracting with Clover F4 (recommended):

Extracting with Clover F4 is recommended, due to ease of extraction, and due to ease of comparison between ACPI/origin and ACPI/patched (for troubleshooting).

At the main Clover bootloader screen, you can press F4 and Clover will dump the native ACPI files to EFI/Clover/ACPI/origin. You can then access them after you boot OS X to disassemble them and patch. Note that some BIOS implementations reverse the function of Fn+F4 with F4, so when in doubt, press both Fn+F4 and F4. There is no feedback during or after the dump, just a slight delay as the files are written. The delay is more noticeable if they are being written to USB, as would be the case when booting from a Clover USB.

Sometimes, Clover F4 will write duplicate SSDTs. These duplicates will cause problems during disassembly. If you run into issues (duplicate definitions) during disassembly, you will need to analyse all SSDTs to eliminate the files which are duplicate. It is easy to see which are duplicates by looking at the file sizes. Files with equal size are likely duplicates.

You can see file sizes in bytes of all SSDTs in Terminal:
Code:

ls -l SSDT*.aml


Extracting with 'patchmatic' (NOT recommended):

If you've already installed OS X, provided you're not currently booting with any patched ACPI files, you can extract your native DSDT/SSDT with patchmatic. Download the patchmatic binary here: https://github.com/RehabMan/OS-X-MaciASL-patchmatic (be sure to read the README as the download location is linked from it). For ease of use in Terminal, you should copy the binary (inside the ZIP) to /usr/bin.

After installing patchmatic, you can invoke it in Terminal, as such:

Code:

cd ~/Desktop
mkdir extract
cd extract
patchmatic -extract

The patchmatic binary will extract all loaded ACPI files and place them in the current directory. If you're using any options in the bootloader that affect the injected DSDT/SSDT, you will not get native ACPI files, so be sure you're not using those options. For example, if you're using (Chameleon) DropSSDT=Yes, or (Clover) DropOem=true, the native SSDTs are being dropped before OS X can load them, so you'll be missing them in the patchmatic output. Same goes for any Clover DSDT "Fixes" -- those fixes are patching the native DSDT, and to do your own DSDT patching, you don't want that. Options such as GeneratePStates/GenerateCStates=Yes, or with Clover /ACPI/SSDT/Generate/CStates /ACPI/SSDT/Generate/PStates will inject extra SSDTs which can cause complications with disassembly.

It is for all those reasons, it is often easier to extract via Linux or using Clover F4.

Note: Using 'patchmatic -extract' to confirm you're patching DSDT/SSDTs as you expect is a useful diagnostic tool.


Extracting with Linux (NOT recommended):

In Linux, the native ACPI files are available directly from the file system. You can find them at /sys/firmware/acpi/tables and /sys/firmware/acpi/tables/dynamic. It is possible to copy the entire set with a single command in Terminal.

It is not necessary to install Linux. Simply run it from USB: http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-windows.

In Linux Terminal:
Code:

# substitute DEST with the mountpoint of a FAT32 formatted USB stick
sudo cp -R /sys/firmware/acpi/tables DEST

You should copy the files to a FAT32 formatted USB. Using FAT32 avoids permissions issues as FAT32 has no file permissions. The value of DEST for an auto-mounted USB will depend on the version of Linux you're using and how you booted it. You can see the mount-point by typing 'mount' in Terminal, or hover your mouse over the volume name in the Linux file explorer.


Preparing tools for disassembly

To properly disassemble your extracted files, you need the iasl compiler, which is run from Terminal.

You will need a recent build of iasl to disassemble them properly. There is an appropriate version available here: https://bitbucket.org/RehabMan/acpica/downloads/. It is a good idea to copy the iasl binary to your path (eg. /usr/bin), so it is easily accessed from Terminal.

For example, if you downloaded it to ~/Downloads/iasl.zip, you can extract and copy it in Terminal:
Code:

cd ~/Downloads
unzip iasl.zip
sudo cp iasl /usr/bin


Building the latest iasl from github

You can also build the latest version of my iasl from my github. The newer version of iasl will eventually be available at the bitbucket link, but for those who want to be on the "bleeding edge", you can build it yourself. The latest version always tends to have experimental and not well tested code.

Assuming you have Xcode installed:
Code:

mkdir ~/Projects && cd ~/Projects
git clone https://github.com/RehabMan/Intel-iasl.git iasl.git
cd iasl.git

Then build it:
Code:

make

At that point, you can install it with:
Code:

sudo make install

And assuming you have MaciASL.app installed to /Applications, you can use the new version (that you just built and installed to /usr/bin) in MaciASL as well:
Code:

sudo cp /usr/bin/iasl /Applications/MaciASL.app/Contents/MacOS/iasl62



Disassembling ACPI files

Although the extracted native files can be opened directly in MaciASL, it is not recommended. Opening an AML file directly in MaciASL will cause MaciASL to disassemble the file (with iasl) standalone, and if the AML has complex references to other AMLs, it will not disassemble it correctly. You'll be left with many hard to fix errors.

As a result, it is better to disassemble all files as a group using iasl in Terminal. To prepare, place all DSDT and SSDT files in a single directory (DO NOT copy ACPI files that don't begin with DSDT or SSDT), and change the names such that they have an .aml extension.

Then disassemble in OS X Terminal:
Code:

cd "to directory where you placed all SSDT/DSDT"
iasl -da -dl DSDT.aml SSDT*.aml

For newer ACPI sets (usually [but not always] with Skylake and later), there is no need for -da as they have embedded External opcodes:
Code:

cd "to directory where you placed all SSDT/DSDT"
iasl -dl DSDT.aml SSDT*.aml

Note: Do NOT attempt to disassemble other ACPI files with the -da option. It will not work.

Note: Also read the section below regarding refs.txt. Using refs.txt takes little more effort, but can eliminate many common errors.

From this point onward, you will work exclusively with the resulting *.dsl files using MaciASL. Of course, to use them you must save as "ACPI Machine Language Binary" with an extension .aml and place them where they will be loaded by the bootloader. But keep your patched .dsl files in case you need to apply more patches in the future.

Let me state it quite simply (because this comes up a lot): If you are opening an AML file directly in MaciASL and clicking Compile, you are doing it WRONG. Let that soak into the gray matter between your ears for a minute. The only exception to this rule is AML files compiled with a recent enough iasl that places embedded External opcodes in the file. This includes files you compiled yourself with the current iasl and native ACPI compiled by the OEM (generally, Skylake and later).

Note: The new tools with ACPI 6.1 (and later) are much more robust when dealing with AML files that have been compiled with the new version of iasl. ACPI 6.1+ adds a feature to the compiler where opcodes for External references are added to the AML binary. ACPI interpreters ignore this data, but the data is useful to the disassembler (also only ACPI 6.1+ iasl) to create a better disassembly from a standalone AML. As a result, you might find that AML files that have been recompiled with the latest tools may open directly more reliably. Of course, existing OEM ACPI DSDT and SSDTs are not using the new tools at this point, so you still must disassemble initially with all DSDT/SSDT with option -da, as described in this guide.

Note regarding Snow Leopard ACPI implementation: Unfortunately, the 10.6.8 ACPI is old enough that it chokes on AMLs with the external opcode. If you are planning to use your ACPI files with Snow Leopard use the undocumented "-oe" switch to iasl when you compile your AML files. This option is not set when you compile (Save As) from MaciASL, so you will need to compile your files in Terminal. The "-oe" option disables generation of the external opcode in the output AML files.


Disassembly with refs.txt

Sometimes there are additional unresolved externals (symbols not defined in any file). The iasl disassembler will attempt to guess the number of arguments, but often it guesses poorly. You can correct it, by providing the External declarations in a text file. Some common unresolved symbols are SGPO, ECRD, ECWT, and MMTB.

The following refs.txt content has some common (and not so common) missing symbols (as reported by users in this thread) that the disassembler tends to be confused by.

First create refs.txt in the directory where your DSDT/SSDT files are:
Code:

External(MDBG, MethodObj, 1)
External(_GPE.MMTB, MethodObj, 0)
External(_SB.PCI0.LPCB.H_EC.ECWT, MethodObj, 2)
External(_SB.PCI0.LPCB.H_EC.ECRD, MethodObj, 1)
External(_SB.PCI0.LPCB.H_EC.ECMD, MethodObj, 1)
External(_SB.PCI0.PEG0.PEGP.SGPO, MethodObj, 2)
External(_SB.PCI0.GFX0.DD02._BCM, MethodObj, 1)
External(_SB.PCI0.SAT0.SDSM, MethodObj, 4)
External(_GPE.VHOV, MethodObj, 3)
External(_SB.PCI0.XHC.RHUB.TPLD, MethodObj, 2)

Note: With newer ACPI sets (generally Skylake and later), the ACPI files have been compiled with a new enough version of iasl that embeds External opcodes in the resulting AML code. For these newer ACPI sets, no need for -da and especially not refs.txt as the refs.txt content here may conflict with the embedded External opcodes.

A handy way to create refs.txt is to use pbpaste in Terminal. Copy the text above to the clipboard (I'm assuming you know how to do that), then:
Code:

pbpaste>refs.txt

That will create refs.txt in your current working directory.

Then use it during disassembly:
Code:

iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml


Analyzing native ACPI

After disassembly, you may want to look at the content of each .dsl file to familiarize yourself with the content in each. Certain patching is dependent on the content. For example, if you're patching to disable the discrete graphics device, you may be looking for the _OFF method as it relates to that device (this process is covered in a separate guide, linked later in this guide).

Except for patching to disable the discrete graphics device, it is not necessary to patch any SSDTs as the common renames are already done by the plists provided in the Clover laptop guide (https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/). And renaming is best accomplished via config.plist/ACPI/DSDT/Patches as it can avoid a lot of mistakes compared with patching for renames manually.

For the most part, you should be focused on only DSDT.aml.


Fixing Errors

Even by disassembling all at once (iasl with -da option), the native files can still have errors. The disassembled files have errors due to changes in iasl over time, imperfections in iasl itself, and differences in the compilation environment between our laptops and the OEM. A common cause of errors (my theory), for example, is that some of the methods referenced are actually inside Windows (MMTB and MDBG for example). There is also clearly cases where bugs are in the code or code was written uninitentionally (sometimes hard to tell the difference).

So.. after determining which files you need, you must patch them so they compile without errors. There are many common patches for such errors in my laptop patch repository for MaciASL.

MaciASL: https://github.com/RehabMan/OS-X-MaciASL-patchmatic
Laptop Patches: https://github.com/RehabMan/Laptop-DSDT-Patch

Note: I do not test my patches with DSDT Editor. It has too many bugs and a very old version of iasl. Please do not ask me about it.

Be certain to always read the README, in order to download from the correct location and in order to setup MaciASL correctly. The patches for syntax/error problems begin with "[syn]" in the name. Common examples for older DSDTs are "Fix _PLD Buffer/Package Error", "Fix TNOT Error", and "Fix FPED Parse Error". In order to determine which patch you need, you can look at the error message coming from the iasl compiler and the code at the line the error was detected. You can also attempt to apply a patch just to see if it makes changes as shown in the Preview window in MaciASL. If you're not familiar with each type of error, it can take some experimentation and trial/error.

For some errors, you can simply remove the line of code causing the error. But, it depends on whether the line is necessary for proper operation of the code or not. For example, errors caused by 'External' declarations can generally be removed to fix the error. If you wish, you can create automated patches of your own to remove these lines.

It helps to have some experience with the ACPI spec and some programming experience.

Your goal is to get each .dsl file to compile without errors (warnings/remarks/optimizations are ok). Once you have files that compile without errors, you can move on to patching them to fix issues you may have with your OS X installation.

It is very common to have extraneous/unnecessary External declarations. For example a recent DSDT I looked at had quite a few "Name already exists in scope" errors. For DTSE, DTS1, DTS2, DTS4, BNUM, PDTS, PKGA, SPST.

The fix is to simply comment out the related External declarations.
For example:
Code:

//   External (DTS1, FieldUnitObj)    // (from opcode)
//   External (DTS2, FieldUnitObj)    // (from opcode)
//   External (DTS3, FieldUnitObj)    // (from opcode)
//   External (DTS4, FieldUnitObj)    // (from opcode)
//   External (DTSE, FieldUnitObj)    // (from opcode)
... and so on ...

Another common error in recent DSDT is with ECRW (in a _CRS method). It is a very common error caused by an iasl bug. I'm not going to add a MaciASL patch for it, since it will eventually be fixed by Intel (it is a regression).

Easy to fix.

Replace:
Code:

                If (LEqual (PM6H, One))
                {
                    CreateBitField (BUF0, \_SB.PCI0._Y0C._RW, ECRW)  // _RW_: Read-Write Status
                    Store (Zero, ECRW (If (PM0H)
                            {
                                CreateDWordField (BUF0, \_SB.PCI0._Y0D._LEN, F0LN)  // _LEN: Length
                                Store (Zero, F0LN)
                            }))
                }

With:
Code:

                If (LEqual (PM6H, One))
                {
                    CreateBitField (BUF0, \_SB.PCI0._Y0C._RW, ECRW)  // _RW_: Read-Write Status
                    Store (Zero, ECRW)
                }
If (PM0H)
                            {
                                CreateDWordField (BUF0, \_SB.PCI0._Y0D._LEN, F0LN)  // _LEN: Length
                                Store (Zero, F0LN)
                            }


Common Patches

Generally, a DSDT patch should only be applied after finding a need for that specific fix. But there are several patches that are commonly needed and that have only a small chance of causing a problem. They are in my laptop repo and are listed here:
"Fix _WAK Arg0 v2"
"HPET Fix"
"SMBUS Fix"
"IRQ Fix"
"RTC Fix"
"OS Check Fix"
"Fix Mutex with non-zero SyncLevel"
"Fix PNOT/PPNT" (use only if you're dropping CPU related SSDTs)
"Add IMEI" (do not use if your DSDT or SSDTs already have IMEI/HECI/MEI device)

Note: The OS Check Fix patch you use has nothing to do with the version of Windows the laptop came with, nor with the version of Windows you're currently using.

Note: Do not use the "Fix PNOT/PPNT" patch if you're including all OEM SSDTs. It is intended only for the case you omit the OEM CPU related SSDTs.


These patches can be used to inject power properties for USB:
"6-series USB"
"7-series/8-series USB"

The _PRW patches can be used to fix "instant wake" where the laptop will not sleep without waking up seconds after sleep begins. Use only "USB _PRW 0x6D (instant wake)" or "USB _PRW 0x0D (instant wake)" as it relates to existing code in your DSDT (also note specific versions of these patches for Skylake and later). You should examine your DSDT to determine what the relevant _PRW methods return to be certain the patch is appropriate for your DSDT.

If you have a Haswell CPU/8-series chipset, and AppleLPC.kext is not loading, you should use this patch to inject a compatible ID that will allow it to load:
"Haswell LPC"

If you have a Skylake CPU/100-series chipset, and AppleLPC.kext is not loading, you should use this patch to inject a compatible ID that will allow it to load:
"Skylake LPC"
Note: AppleLPC not likely needed with Skylake and later.

Note regarding renames: Renames must be "balanced." It is common to rename objects to better match what OS X expects (example "Rename GFX0 to IGPU" for proper IGPU power management). In such cases, all DSDT/SSDTs with references to that name must also be renamed. This is why renames are best accomplished with config.plist/ACPI/DSDT/Patches.

Note regarding duplicate identifiers: You must be sure that your patched files do not contain duplicate identifiers. A common case would be adding a _DSM method to a given path in one SSDT, where the OEM has defined a _DSM at the same path in another SSDT. To avoid this problem, you can use the "Remove _DSM methods" patch as one of the first patches you do to all DSDT/SSDTs. Also, "Rename _DSM methods to XDSM" is an alternative (sometimes "Remove _DSM methods" exposes a bug in MaciASL).


Problem specific patching

Battery status: http://www.tonymacx86.com/yosemite-laptop-support/116102-guide-how-patch-dsdt-working-battery-status.html

Backlight control: http://www.tonymacx86.com/yosemite-laptop-support/152659-patching-dsdt-ssdt-laptop-backlight-control.html

Disabling nVidia/Radeon discrete graphics: http://www.tonymacx86.com/yosemite-laptop-support/163772-guide-disabling-discrete-graphics-dual-gpu-laptops.html

When following a guide for a specific laptop, it may instruct you to apply a patch that is provided in the post itself. You will recognize it as the syntax used will look similar to other patches you've seen in the repository (eg. 'into_all method label FOO code_regex xxyy removeall_matched;'). These patches are intended to be pasted directly into the patch window in MaciASL so they can be applied.

If you're interested in writing your own patches, read the documentation on MaciASL patch grammar: http://sourceforge.net/p/maciasl/wiki/Patching Syntax Grammar/

Note: In many cases, DSDT patches are used in conjunction with additional kexts, patched kexts, or Clover config.plist patches that patch the system kexts as they are loaded.


Patches for using patched AppleHDA

With patched AppleHDA, there are two patches that are needed in conjunction with the kext:
"Audio Layout 12" (change the layout-id from 12 to the one used by your DSDT)
"IRQ Fix"

Note that you must have an AppleHDA that matches your codec, and must determine which layout-id was chosen. The layout-id is an arbitrary choice by the creator of the patched AppleHDA.

To determine the layout-id used by a particular patched AppleHDA: First you need to know your codec id in decimal (eg. 0x10ec0269 = 283902569). Then look in the Info.plist for AppleHDAHardwareConfigDriver.kext (at AppleHDA.kext/Contents/PlugIns/AppleHDAHardwareConfigDriver.kext/Contents/Info.plist), find your codec id under HDAConfigDefault (there may be many entries in a sloppy patched AppleHDA or only one). The LayoutID that matches your codec id is the layout id you need. It is possible that a patched AppleHDA contains more than one layout-id for a given codec. In that case, choose the one you want to use.


Saving files for loading by the bootloader

In order to use your patched DSDT/SSDTs, you must save them where the bootloader can load them. Each bootloader location is unique and has different requirements for naming. Files must be saved in "ACPI Machine Language Binary" (MaciASL->Save As). Saving a text file (dsl) with an AML extension will likely cause panic or very strange behavior in OS X.

Clover: Files should be placed on the Clover bootloader partition (usually the EFI partition), in EFI/Clover/ACPI/patched. DSDT.aml, if present, will automatically replace the OEM DSDT. This guide (and other guides linked from this guide) assumes you are using config.plist/ACPI/AutoMerge=true, config.plist/ACPI/SSDT/DropOem=false. With AutoMerge=true, patched SSDTs can be placed in ACPI/patched with their original name (from ACPI/origin) and they will be inserted such that the original order of SSDTs is not disturbed. It is not necessary (or advised) to use SortedOrder with AutoMerge=true. Other configurations are covered below in "Recommended configurations".

As mentioned above, a new feature in the RehabMan fork of Clover allows you to replace OEM SSDTs without using DropOem=true, and without using SortedOrder, all the while maintaining original order of the unpatched and patched SSDTs as injected by Clover. By setting config.plist/ACPI/AutoMerge=true, this feature is enabled. The SSDT must retain its original numbering scheme when placed in ACPI/patched. This feature is fully working as of 2017-12-15, Clover_v2.4k_r4359.RM-4506.c5fc0346.zip, on the RehabMan bitbucket site. The required changes are implemented in the official Clover (on sourceforge) as of r4334 (but there are bugs you may run into, use the RehabMan build). Each of the plists linked by the main laptop guide uses AutoMerge=true by default.

Although you can use patched DSDT and patched SSDTs in Chameleon, this guide will not cover it. Chameleon is not recommended. Use Clover instead.

RehabMan fork of Clover: https://github.com/RehabMan/Clover
Main laptop guide: https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/


Recommended configurations

The following are valid configurations, anything else is likely wrong (there are some edge cases I'd rather not get into, hence the use of 'likely').

Configurations listed first are more desirable.

Full hotpatch:
- all patching is done via config.plist
- only add-on SSDTs in ACPI/patched (eg. no patched DSDT, no patched SSDTs)
- SortedOrder can be left unspecified
- DropOem=false

Partial hotpatch:
- patched DSDT.aml in ACPI/patched
- only add-on SSDTs in ACPI/patched (eg. no patched SSDTs)
- renames (applies to DSDT.aml in ACPI/patched and native SSDTs) done with config.plist
- SortedOrder left unspecified
- DropOem=false

Partial hotpatch with patched SSDTs:
- RehabMan Clover required
- patched DSDT.aml in ACPI/patched
- select patched SSDTs in ACPI/patched (must be named as extracted to ACPI/origin)
- add-on SSDTs also placed in ACPI/patched
- renames can still be done with config.plist
- SortedOrder left unspecified
- config.plist/ACPI/AutoMerge=true
- DropOem=false

Full patched DSDT + SSDTs:
- patched DSDT.aml in ACPI/patched
- full set of static patched OEM SSDTs in ACPI/patched (original names as from ACPI/origin)
- add-on SSDTs also placed in ACPI/patched
- renames in config.plist not recommended (they will apply only to DSDT.aml)
- SortedOrder required to set SSDT load order
- DropOem=true


Floating regions

In ACPI, an OperationRegion can define a MMIO region, SystemMemory region, EmbeddedControl region, etc. These regions usually have fixed addresses dependent only on the machine configuration, BIOS version, or BIOS options. Sometimes, these regions can change randomly or unexpectedly. This is referred to as "floating regions".

Since by patching DSDT and/or SSDTs, we are providing a snapshot of these addresses at a given point in time, they may not match up should the BIOS decide to place such regions at a different address. If this is the case, you may notice that certain features are intermittently working, or other stability issues that appear to be random.

If you have randomly floating regions, you can try Clover's FixRegions feature (config.plist/ACPI/DSDT/Fixes/FixRegions=true). You can find the details in the Clover Wiki. Note: Only floating regions in DSDT can be fixed by FixRegions. Floating regions in SSDTs are problematic and there is no good solution other than to not provide patched SSDTs for SSDTs subject to randomly floating regions. Working around floating regions in patched SSDTs is beyond the scope of this guide. Note that FixRegions is relatively buggy. It cannot fix all regions and it can sometimes "fix" regions incorrectly.


Resources

MaciASL (RehabMan fork): https://github.com/RehabMan/OS-X-MaciASL-patchmatic
patchmatic: https://github.com/RehabMan/OS-X-MaciASL-patchmatic
iasl (RehabMan fork): https://bitbucket.org/RehabMan/acpica/downloads
ACPI spec:
5.0a: http://acpi.info/spec.htm
Latest: http://www.uefi.org/specifications

RehabMan github: https://github.com/RehabMan?tab=repositories

Clover laptop guide: http://www.tonymacx86.com/yosemite-laptop-support/148093-guide-booting-os-x-installer-laptops-clover-uefi.html
Clover config.plist files for laptops: https://github.com/RehabMan/OS-X-Clover-Laptop-Config

Clover thread: http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/
Clover changes: http://www.insanelymac.com/forum/topic/304530-clover-change-explanations/

howtoextractyourdsdt

https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/wiki/How-to-patch-your-DSDT

Although there are pre-patched DSDTs available as downloads from the tonymacx86.com forums and in installer packages such as the HP ProBook Installer, there can be differences in individual DSDTs that can cause delays in booting and perhaps other problems. Perhaps there are slight differences in BIOS settings, memory installed, etc, that is causing these differences. It is best, therefore, to patch your own DSDT and install it into /Extra/dsdt.aml (Chameleon) or EFI/Clover/ACPI/patched (Clover).

Note: The current version of the ProBook Installer actually uses this patch repo to patch your own DSDT.
Extracting your native DSDT

I have included five different methods for extracting your native DSDT. Just pick the method that seems easiest for you. The easiest one will depend on whether you still have Windows installed, whether you already have a Linux USB stick prepared, and just how familiar you are with both systems.
Extracting your native/clean DSDT using MaciASL or DSDT Editor under OS X

Boot your OS X installation with DSDT=No or without a DSDT installed to /Extra/dsdt.aml. To boot with DSDT=No, just type it at the Chimera/Chameleon boot screen and press enter. This will boot your system with the OEM provided DSDT such that MaciASL or DSDT Editor can be used to extract the raw DSDT.

If you have a high-resolution screen (1600x900 or 1920x1080) you will not be able to boot without a DSDT. If this is your case, copy Mini-SSDT-DualLink.aml to the Unibeast USB /Extra/ssdt.aml. This SSDT inserts a small patch into ACPI namespace that allows you to get a valid screen on the laptop display, but will not impact the raw DSDT extracted by MaciASL or DSDT Editor.
Extracting your native/clean DSDT using Linux 'acpidump'

In order to use the patches provided in this repository, you first have to acquire your native/clean DSDT. One way to do that is with acpidump in Linux.

First of all, you need the ability to run Linux. For that I recommend creating a USB stick with Ubuntu. Read and follow these complete instructions: http://www.ubuntu.com/download/help/create-a-usb-stick-on-windows. After you get your Ubuntu USB stick made, boot from it. On the HP ProBook, you tap the F9 key during BIOS startup and you will get the opportunity to boot from devices other than the hard disk. Select your USB stick with Ubuntu on it. When the Ubuntu menu appears, choose the first one, where you are just running (not installing) Ubuntu. If you decide to use Ubuntu on a regular basis, you can install it. For that I suggest you see my guide at http://racerrehabman.wordpress.com/2012/07/06/guide-to-installing-windows-7-windows-8-mac-os-x-lion-and-ubuntu-multi-boot/ which has complete instructions for multi-booting Win7, Win8, Lion, and Ubuntu.

Now you should be running Ubuntu. To get 'acpidump' you first need to enable the 'universe' software repository. To do so, it is easiest to follow this guide: https://help.ubuntu.com/community/Repositories/Ubuntu#Adding_Repositories_in_Ubuntu

After adding 'universe' to the Ubuntu Software Center's software sources, you are ready to install acpidump and run it. You will need internet access to get the acpidump software, so if you are using a wireless connection, now is a good time to connect to it. After that, open Terminal (Ctrl+Alt+T), and type the following commands:

sudo apt-get update
sudo apt-get install acpidump

Now you have acpidump installed so, we can run it:

sudo acpidump -b -t DSDT -o dsdt.aml

Now copy the dsdt.aml file somewhere that you can access from your installation of Mac OS (a USB key perhaps). The dsdt.aml file you have now is a raw DSDT from your BIOS that you can use to apply the patches in this repository to create your patched DSDT.
Extracting your native/clean DSDT using Linux /sys/firmware/acpi/tables/DSDT

I didn't know this, but evidently the ACPI tables are directly available and mounted in the file system. This is much simpler than using acpidump, especially if running from the Ubuntu Live USB.

All you have to do is run the following command in Terminal:

sudo cat /sys/firmware/acpi/tables/DSDT >dsdt.aml

Then copy resulting dsdt.aml somewhere convenient to bring with you to your OS X install for patching.
Extracting your native/clean DSDT using Clover F4

If you press F4 at the main Clover bootloader screen, Clover will write your native files to EFI/Clover/ACPI/origin. There is no feedback when you press F4, so don't expect anything to "happen" when you press the key. Also, keep in mind that some BIOS implementations (newer computers) tend to reverse the Fn+F1..F12 and F1..F12 keys, so be sure you're pressing the correct key combination to generate F4.
Extracting your native/clean DSDT using Windows

I haven't used this method personally, but have used this application for other things and it seems that it also has the capability to extract ACPI tables. The program is "Read-Write Everything" and it is available at the following website: http://rweverything.phpnet.us/index.htm

Once you have installed RW-Everything, run it and from the "Access" menu, choose "ACPI Tables". From the "ACPI Table" window that opens, first select the DSDT tab to make sure the DSDT table is active, then choose the "Save as Binary" button on toolbar (or Shift+F2). Save that file to a place easy to transfer to your MAC OS installation.
Creating your patched DSDT using MaciASL

MaciASL is a very nice native OS X program. It is much faster than using DSDT Editor and more polished. MaciASL is the recommended way to patch your DSDT. MaciASL is available only on Lion or newer.

    First, you need MaciASL, so download it: http://www.tonymacx86.com/dsdt/83565-native-dsdt-aml-ide-compiler-maciasl-open-beta.html#post517290

Note: You can also use my fork of MaciASL: https://github.com/RehabMan/OS-X-MaciASL-patchmatic

    Now Run MaciASL.
    First time through, check preferences, iASL tab: Compiler options set to ACPI 5.0
    While in preferences, add the repo under Sources tab: Click the [+] button to add a patch repo.
    Type whatever name you like in the first column... "ProBook" is fitting.
    Type (or copy/paste) the URL for the patch repo:

http://raw.github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/master

    Now you can close Preferences
    Use File Open to open your unpatched/raw DSDT you extracted earlier
    Choose Patch from the toolbar
    On the left you should see "ProBook" patch repo added in Preferences earlier
    The patches are divided into groups. Select one from the first group "ProBook 4x30s" "ProBook 4x40s Ivy Bridge" or "ProBook 4x40s Sandy Bridge" depending on your specific laptop.
    The patch text will load in the upper part of the patch window, and after a few seconds the preview window in the lower section will fill in with before/after data
    For my machine (4540s w/ F.60 BIOS) it shows 128 Patches, 173 changes, 0 Rejects
    Click on the Apply button to apply the patches. The patch window will clear.
    Now select from the next group, either "IGPU/LVDS Single-Link" if you have the standard 1366x768 laptop display, or "IGPU/LVDS Dual-Link" if you have the high resolution 1600x900 or 1920x1080 upgraded screen.
    Again the patch text will load in the upper part of the patch window. Click on the Apply button to apply the patches. The patch window will clear.
    Now select from the next group, your desired fan behavior. The patch window will fill, then hit Apply to apply the patch.
    None of the Optional patches are not necessary
    Now select "ACPI backlight control". Click Apply.
    Select one of the keyboard maps depending on your hardware "ProBook 102-key layout" or "Probook 87-key layout"
    You can now Close the patch window by clicking on the Close button.
    Choose Save As... and pick a location to save your patched DSDT. Be sure to save it as File Format "ACPI Machine Language Binary" Save it to the desktop if you're not sure where to save it.
    Now copy the resulting DSDT.aml to your /Extra/dsdt.aml or EFI/Clover/ACPI/patched (depending on bootloader). You can use Terminal:

# assuming Chameleon
sudo cp ~/Desktop/DSDT.AML /Extra/DSDT.AML

# assuming Clover, EFI partition mounted at /Volumes/EFI
cp ~/Desktop/DSDT.AML /Volumes/EFI/Clover/ACPI/patched/DSDT.AML

Note regarding native power management

This version of the patching instructions assumes you'll be implementing native power management where the OEM SSDTs are not dropped. This is a change to how native power management had been implemented in the past.

If you're not using this new technique for native power management, you should also apply "For non-OEM CPU SSDTs (deprecated patches)" to your DSDT.

If you are using the new technique (recommended), you should check your settings:

    set config.plist/ACPI/SSDT/DropOem=false (DropSSDT=No if using Chameleon)
    set config.plist/ACPI/SSDT/Generate=false
    optionally, drop SSDT 'PtidDevc' (with DropTables)

Note: Even with the new technique, you still need SSDT.AML generated from ssdtPRgen.sh (the script that the Probook Installer uses)