diff --git a/CONTRIBUTING.html b/CONTRIBUTING.html index a0d7973..adf6ef0 100644 --- a/CONTRIBUTING.html +++ b/CONTRIBUTING.html @@ -262,7 +262,7 @@ - Embedded Controller + Embedded Controller @@ -447,7 +447,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Supporting the guides

Note: This is a community run guide which is not officially endorsed by Acidanthera. Please do not bug Acidanthera with issues about this guide.

@@ -563,7 +563,7 @@ diff --git a/Desktops/desktop-disable.html b/Desktops/desktop-disable.html index 836220b..1cdb93b 100644 --- a/Desktops/desktop-disable.html +++ b/Desktops/desktop-disable.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Disabling unsupported GPUs(Desktops)

So this is mainly needed for GPUs that are not supported in macOS, mainly this will be Nvidia users who wish to pair an AMD GPU for macOS use. While WhateverGreen does support the boot-arg -wegnoegpu, this only works when running on iGPU so for the rest of us we'll need to make an SSDT.

@@ -529,7 +529,7 @@ Method (_SB.PCI0.PEG0.PEGP._DSM, 4, NotSerialized) diff --git a/Desktops/desktop-ec.md b/Desktops/desktop-ec.md index 38425fc..f3735ce 100644 --- a/Desktops/desktop-ec.md +++ b/Desktops/desktop-ec.md @@ -1,7 +1,7 @@ # Fixing Embedded Controller (Desktop) -## You'll want to go to [SSDT-EC under the Universal tab](/Universal/desktop-ec.md) for the new SSDT-EC page. +## You'll want to go to [SSDT-EC under the Universal tab](/Universal/desktop-ec.md) for the new SSDT-EC page What we'll be doing is hiding our actual EC and creating a fake Embedded Comtroller for macOS to play with. diff --git a/Laptops/backlight.html b/Laptops/backlight.html index 861560d..d39e730 100644 --- a/Laptops/backlight.html +++ b/Laptops/backlight.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Fixing Backlight

So what this SSDT does is create a PNLF device for macOS to play with, specifically one with a hardware ID of APP0002. WhateverGreen will handle the rest of the work

@@ -515,7 +515,7 @@ diff --git a/Laptops/laptop-disable.html b/Laptops/laptop-disable.html index 6f4da47..0eed1c1 100644 --- a/Laptops/laptop-disable.html +++ b/Laptops/laptop-disable.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Disabling laptop dGPUs

So with laptops, we can hide the dGPU from macOS with the little boot-arg called -wegnoegpu from WhateverGreen. But one small problem, the dGPU is still pulling power draining your battery slowly. We'll be going over 2 methods for disabling the dGPU in a laptop:

@@ -539,7 +539,7 @@ External (_SB_.PCI0.PEG0.PEGP._PS3, MethodObj) // dGPU ACPI Path - + @@ -550,7 +550,7 @@ External (_SB_.PCI0.PEG0.PEGP._PS3, MethodObj) // dGPU ACPI Path diff --git a/Laptops/laptop-ec.md b/Laptops/laptop-ec.md index e11d979..7ebb8de 100644 --- a/Laptops/laptop-ec.md +++ b/Laptops/laptop-ec.md @@ -1,6 +1,6 @@ # Fixing Embedded Controller (Laptop) -## You'll want to go to [SSDT-EC under the Universal tab](/Universal/desktop-ec.md) for the new SSDT-EC page. +## You'll want to go to [SSDT-EC under the Universal tab](/Universal/desktop-ec.md) for the new SSDT-EC page To fix the ECs found in laptops, we'll be renaming them to look like the ones macOS expects. The reason for this is that many laptops break when you turn off their EC with an SSDT. So this is why we can't use the fancy SSDTTime to make a patch for us. diff --git a/Laptops/trackpad.html b/Laptops/trackpad.html index c82112f..3b5fae3 100644 --- a/Laptops/trackpad.html +++ b/Laptops/trackpad.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Fixing Trackpads

This SSDT is used to force enable our GPI0 for VoodooI2C to connect onto.

@@ -574,7 +574,7 @@ diff --git a/Manual/compile.html b/Manual/compile.html index 97f1bbf..b240430 100644 --- a/Manual/compile.html +++ b/Manual/compile.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Compiling and decompiling ACPI Tables

See Troubleshooting if you have dumping/compiling errors

@@ -525,7 +525,7 @@ diff --git a/Manual/dump.html b/Manual/dump.html index ae453d2..af9348d 100644 --- a/Manual/dump.html +++ b/Manual/dump.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Getting a copy of our DSDT

So to start, we'll need to get a copy of your DSDT from your firmware. The easiest way is grabbing the DSDT.aml SSDTTime dumped for us earlier but here are some other options:

@@ -533,7 +533,7 @@ fs0:\EFI\OC\Tools> acpidump.efi -b -n DSDT -z diff --git a/Universal/awac.html b/Universal/awac.html index dc334d4..6cc65fa 100644 --- a/Universal/awac.html +++ b/Universal/awac.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
-

Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

+

Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

Fixing System Clocks

For Intel 300 series chipsets and newer, this also includes X299 refreshes and Icelake laptops. Common machines:

@@ -462,7 +462,7 @@
  • Z370 (Gigabyte and AsRock boards with newer BIOS versions)
  • Z390
  • 400 series (Cometlake)
    • -
  • 495 series (Icelake)
    • +
  • 495 series (Icelake)

    • So on newer Intel 300 series motherboards, manufactures started pushing for a new type of system clock: AWAC( A Weird Ass Clock). One small problem, macOS doesn't know what the hell an AWAC clock is instead only familiar with the legacy RTC(Real Time Clock). So we need to figure out how to bring back the old clock, thats where SSDT-AWAC and SSDT-RTC0 come in:

      @@ -536,7 +536,7 @@ diff --git a/Universal/ec-fix.html b/Universal/ec-fix.html index ff5eafb..76f41b0 100644 --- a/Universal/ec-fix.html +++ b/Universal/ec-fix.html @@ -4,7 +4,7 @@ - Embedded Controller · GitBook + Embedded Controller · GitBook @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -433,7 +433,7 @@

      - Embedded Controller + Embedded Controller

      @@ -449,7 +449,7 @@
      -

      Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

      +

      Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

      Fixing Embedded Controller

      What we'll be doing is creating a fake Embedded Controller (EC) to satisfy macOS Catalina's EC addiction, and disabling the EC on desktops to prevent panics and crashes.

      @@ -538,7 +538,7 @@ External (_SB_.PCI0.LPCB.EC0, DeviceObj) <- Rename this
    • _GPE (General Purpose Events)

    Note if you have an STA Method as well, see below: STA Edge Case

    -

    What happens if no PNP0C09 show up?

    +

    What happens if no PNP0C09 show up

    This means you only need to fake an Embedded Controller rather so that AppleBusPowerController will load and handle USB power properly and continue booting. To make the actual SSDT, its almost plug and play as no uncommenting needed. The main thing that needs to be changed:

    • LowPinCount path
      • @@ -633,7 +633,7 @@ The reason for this is that the real EC is considered disabled already.

      diff --git a/Universal/irq.html b/Universal/irq.html index 62332ed..46cc173 100644 --- a/Universal/irq.html +++ b/Universal/irq.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
      -

      Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

      +

      Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

      Fixing IRQ Conflicts

      So you miss having those fancy hot-patches from Clover like FixIPIC, FixTMR, FixRTC, FixHPET, etc

      @@ -497,7 +497,7 @@ diff --git a/Universal/nvram.html b/Universal/nvram.html index 0267185..15e3588 100644 --- a/Universal/nvram.html +++ b/Universal/nvram.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
      -

      Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

      +

      Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

      Fixing NVRAM

      This SSDT is required for all "true" 300 series motherboards and newer(Z370 is excluded), it specifically brings back NVRAM support and requires very little configuration for the end user.

      @@ -460,15 +460,15 @@
    • H370
    • Z390
    • 400 series (Cometlake)
      • -
    • 495 series (Icelake)
      • +
    • 495 series (Icelake)

    By default it uses PCI0.LPCB for the PCI and LowPinCount path. The device names can vary between PC00 and PCI0 for PCI path and LPCB, LBC and LBC0 for LowPinCount path. To see what you have:

      -
    • Finding the LowPinCount path:
        +
      • Finding the LowPinCount path:
        • Intel: Search Name (_ADR, 0x001F0000)
        • -
      • Finding the PCI path:
          +
        • Finding the PCI path:
          • Intel: Search PNP0A08 (If multiple show up, use the first one)
          • @@ -518,7 +518,7 @@ diff --git a/Universal/plug.html b/Universal/plug.html index d9155d0..6eee911 100644 --- a/Universal/plug.html +++ b/Universal/plug.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,17 +449,20 @@
          -

          Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

          +

          Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

          Fixing Power Management

          CPU naming is fairly easy to figure out as well, open your decompiled DSDT and search for Processor. This should give you a result like this:

          -

          As we can see, the first processor in our list is PR00. This is what we'll be applying the plugin-type=1 property too. Now grab SSDT-PLUG and replace the default CPU0 with our PR00. There's a couple things to note:

          +

          As we can see, the first processor in our list is PR00. This is what we'll be applying the plugin-type=1 property too. Now grab SSDT-PLUG and replace the default CPU0 with our PR00. There's a couple things to note:

          • There's 2 mentions of CPU0 to change
          • The PR path may need to be changed, in our example we can see that our PR00 has SB in front.

          So in our final example, we'd have _SB_.PR00 and \_SB.PR00

          +
            +
          • Note: If you're having issues, see the SSDT-PLUG provided by Acidanthera for example on what other ACPI paths may look like.
            • +

          There are also some edge cases with Processor, specifically on HEDT series like X79, X99 and X299. This edge case is that the ACPI path is much longer and not so obvious:

          If we then search for instances of CP00 we find that it's ACPI path is SB.SCK0.CP00:

          @@ -506,7 +509,7 @@ Scope (\_PR.CPU0) <- Rename this - + @@ -522,7 +525,7 @@ Scope (\_PR.CPU0) <- Rename this diff --git a/Universal/smbus.html b/Universal/smbus.html index 5bf6cf7..2efa389 100644 --- a/Universal/smbus.html +++ b/Universal/smbus.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
          -

          Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

          +

          Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

          Fixing SMBus support

          This section of the guide refers to fixing AppleSMBus support in macOS, what is AppleSMBus? Well this mainly handles the System Management Bus, which has many functions like:

          @@ -466,7 +466,7 @@
        • Aids in proper memory reporting and can aid in getting better kernel panic details if memory related
        • -
      • Other things SMBus does: SMBus wiki
        • +
      • Other things SMBus does: SMBus wiki

      For install purposes, this SSDT isn't needed but for post-install it's recommended to put the final touches on your hack.

      So to get started, we'll want to grab our SMBus SSDT:

      @@ -497,7 +497,7 @@ Look for the SMBus device under Subclass, then look beside and you'll see t 
      External (_SB_.PC00, DeviceObj) <- Renamed
 External (_SB_.PC00.SMBS.BUS0, DeviceObj) <- Renamed
 
-Scope (_SB.PC00) 
+Scope (_SB.PC00)
 {
     Device (MCHC)
     {
@@ -554,7 +554,7 @@ Device (_SB.PC00.SMBS.BUS0) <- Renamed
     
 
diff --git a/Universal/spoof.html b/Universal/spoof.html
index a40429e..7666a83 100644
--- a/Universal/spoof.html
+++ b/Universal/spoof.html
@@ -264,7 +264,7 @@
                 
             
                     
-                    Embedded Controller 
+                    Embedded Controller
             
                 
             
@@ -449,7 +449,7 @@
                                 
      
                                 
                                 
      
-
      Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)
      
+
      Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)
      
 
      
 
      Renaming GPUs
      
 
      So this is mainly needed for GPUs that are not natively supported out of the box due to their names, most commonly:
      
@@ -485,7 +485,7 @@ Buffer (0x04)

      As you can see, the bytes are swapped in pairs. Keep this in mind when we make our SSDT

      The specifics are due to Endianness for those who are curious

      Finding the ACPI Path of the GPU

      -

      To find the PCI path of a GPU is fairly simple, best way to find it is running Windows:

      +

      To find the PCI path of a GPU is fairly simple, best way to find it is running Windows:

      • Open Device Manager
      • Select Display Adapters, then right click your GPU and select Properties
        • @@ -525,7 +525,7 @@ Buffer () { "AMD Radeon R9 390" } -

        "device-id" will be set to our PCI ID that we found in "Finding a suitable PCI ID" and "model" is mainly cosmetic

        +

        "device-id" will be set to our PCI ID that we found in "Finding a suitable PCI ID" and "model" is mainly cosmetic

        Now you're ready to compile the SSDT!

        @@ -570,7 +570,7 @@ Buffer () diff --git a/Universal/vbios.md b/Universal/vbios.md index 2704a0e..28ff17c 100644 --- a/Universal/vbios.md +++ b/Universal/vbios.md @@ -9,7 +9,7 @@ So this is mainly needed for GPUs that are not natively supported out of the box * HIS * VisionTek -Instead, these GPUs need to be flashed to a model that works best in macOS which gernally being Sapphire. This is the brand that AMD uses for making their reference cards and what Apple bases a lot of their GPU logic off of. +Instead, these GPUs need to be flashed to a model that works best in macOS which gernally being Sapphire. This is the brand that AMD uses for making their reference cards and what Apple bases a lot of their GPU logic off of. One small problem, flashing VBIOSes can be a bit dangerous and can even brick a card. So for us, we'll be injecting one via an SSDT that will only load in macOS. This means 2 things: @@ -22,7 +22,6 @@ So to force a VBIOS onto the GPU, we need to find a couple things: * ACPI Path of the GPU * [SSDT-VBIOS]() - ## Finding a suitable VBIOS To find a suitable VBIOS, we'll be using [TechPowerUps Video BIOS Collection](https://www.techpowerup.com/vgabios/) which has a full database of basically all GPU VBIOSes. For this example, we'll be creating a VBIOS SSDT for the XFX RX 560 4GB. Now lets pull up the [Sapphire RX 560 4GB](https://www.techpowerup.com/vgabios/192320/sapphire-rx560-4096-170419) and download the VBIOS linked at the bottom: @@ -30,26 +29,14 @@ To find a suitable VBIOS, we'll be using [TechPowerUps Video BIOS Collection](ht ``` Sapphire.RX560.4096.170419.rom ``` + Now we have 1 small issue, our VBIOS must be padded to 65536 bytes(64KB). And our VBIOS is 262KB... *Shit* [Insert magic software to shrink our VBIOS] - - - - - - - - - - - - - ## Finding the ACPI Path of the GPU -To find the PCI path of a GPU is fairly simple, best way to find it is running Windows: +To find the PCI path of a GPU is fairly simple, best way to find it is running Windows: * Open Device Manager * Select Display Adapters, then right click your GPU and select Properties @@ -59,8 +46,8 @@ To find the PCI path of a GPU is fairly simple, best way to find it is running W ![Credit to 1Revenger1 for the image](/images/Desktops/nvidia.png) - The second "ACPI" is what we care about: + ``` ACPI(_SB_)#ACPI(PC02)#ACPI(BR2A)#ACPI(PEGP)#PCI(0000)#PCI(0000) ``` @@ -70,6 +57,7 @@ Now converting this to an ACPI path is quite simple, remove the `#ACPI` and `#PC ``` `_SB_.PC02.BR2A.PEGP ``` + And voila! We've found our ACPI path, now that we have everything we're ready to get cooking ## Making the SSDT @@ -80,6 +68,7 @@ To start grab our [SSDT-VBIOS]() and open it up. Here there's a couple things to External (_SB_.PCI0, DeviceObj) External (_SB_.PCI0.PEG0.PEGP, DeviceObj) ``` + For our example, we'll change all mentions of : * `PCI0` with `PC02` @@ -92,14 +81,13 @@ Now that the ACPI pathing is correct, we can finally inject our VBIOS!! So the part we want to change: **VBIOS**: + ``` -"ATY,bin_image", +"ATY,bin_image", Buffer (0x00010000) { // Put your VBIOS here }, ``` - ## [Now you're ready to compile the SSDT!](/Manual/compile.md) - diff --git a/cleanup.html b/cleanup.html index 3118626..b205eb0 100644 --- a/cleanup.html +++ b/cleanup.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
        -

        Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

        +

        Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

        Cleanup

        So you've made all your SSDTs but now there's one thing left: Adding them to Opencore

        @@ -510,7 +510,7 @@ diff --git a/extra-files/SSDT-PLUG.dsl b/extra-files/SSDT-PLUG.dsl new file mode 100644 index 0000000..dbd2a0f --- /dev/null +++ b/extra-files/SSDT-PLUG.dsl @@ -0,0 +1,50 @@ +/* + * XCPM power management compatibility table. + */ +DefinitionBlock ("", "SSDT", 2, "Dortania", "CpuPlug", 0x00003000) +{ + External (_PR_.CPU0, ProcessorObj) // Rename this + + Scope (\_PR.CPU0) // Rename this + { + Method (DTGP, 5, NotSerialized) + { + If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b"))) + { + If ((Arg1 == One)) + { + If ((Arg2 == Zero)) + { + Arg4 = Buffer (One) + { + 0x03 // . + } + Return (One) + } + + If ((Arg2 == One)) + { + Return (One) + } + } + } + + Arg4 = Buffer (One) + { + 0x00 // . + } + Return (Zero) + } + + Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method + { + Local0 = Package (0x02) + { + "plugin-type", + One + } + DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) + Return (Local0) + } + } +} diff --git a/extra-files/SSDT-PLUG.dsl.zip b/extra-files/SSDT-PLUG.dsl.zip new file mode 100644 index 0000000..c556573 Binary files /dev/null and b/extra-files/SSDT-PLUG.dsl.zip differ diff --git a/index.html b/index.html index 4da693e..02a50ef 100644 --- a/index.html +++ b/index.html @@ -262,7 +262,7 @@ - Embedded Controller + Embedded Controller @@ -447,7 +447,7 @@
        -

        Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

        +

        Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time)

        Getting started with ACPI

        @@ -459,8 +459,8 @@

        macOS can be very picky about the devices present in the DSDT and so our job is to correct it. The main devices that need to be corrected for macOS to work properly:

          -
        • Embedded controllers(EC)
            -
          • All semi-modern intel machines have an EC (usually called H_EC, ECDV, EC0, etc...) exposed in their DSDT, with many AMD systems also having it exposed. These controllers are generally not compatible with macOS and can cause panics, so then need to be hidden from macOS. macOS Catalina requires a device named EC to be present though, so a dummy EC is created.
            • +
          • Embedded controllers(EC)
              +
            • All semi-modern intel machines have an EC (usually called H_EC, ECDV, EC0, etc...) exposed in their DSDT, with many AMD systems also having it exposed. These controllers are generally not compatible with macOS and can cause panics, so then need to be hidden from macOS. macOS Catalina requires a device named EC to be present though, so a dummy EC is created.
            • With laptops, the actual embedded controller still needs to be enabled for battery and hotkeys to work, and renaming the EC can additionally cause issues with windows, so creating a fake EC without disabling the real embedded controller is preferable to renaming.
            • @@ -713,7 +713,7 @@ diff --git a/search_plus_index.json b/search_plus_index.json index cc1accf..a779dac 100644 --- a/search_plus_index.json +++ b/search_plus_index.json @@ -1 +1 @@ -{"./":{"url":"./","title":"Getting Started With ACPI","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Getting started with ACPI A quick explainer on ACPI So what are DSDTs and SSDTs? Well, these are tables present in your firmware that outline hardware devices like USB controllers, CPU threads, embedded controllers, system clocks and such. A DSDT(Differentiated System Description Table) can be seen as the body holding most of the info with smaller bits of info being passed by the SSDT(Secondary System Description Table). You can think of the DSDT as the building blueprints with SSDTs being sticky notes outlining extra details to the project You can read more about ACPI and it's spec here: ACPI 6.3 Manual So why do we care about these tables? macOS can be very picky about the devices present in the DSDT and so our job is to correct it. The main devices that need to be corrected for macOS to work properly: Embedded controllers(EC) All semi-modern intel machines have an EC (usually called H_EC, ECDV, EC0, etc...) exposed in their DSDT, with many AMD systems also having it exposed. These controllers are generally not compatible with macOS and can cause panics, so then need to be hidden from macOS. macOS Catalina requires a device named EC to be present though, so a dummy EC is created. With laptops, the actual embedded controller still needs to be enabled for battery and hotkeys to work, and renaming the EC can additionally cause issues with windows, so creating a fake EC without disabling the real embedded controller is preferable to renaming. Plugin type This allows the use of XCPM providing native CPU power management on Intel Haswell and newer CPUs, the SSDT will connect to the first thread of the CPU. Not meant for AMD AWAC system clock. This applies to all 300 series motherboards including many Z370 boards, the specific issue is that newer boards ship with AWAC clock enabled. This is a problem because macOS cannot communicate with AWAC clocks, so this requires us to either force on the legacy RTC clock or if unavailable create a fake one for macOS to play with NVRAM SSDT True 300 series motherboards(non-Z370) don't declare the FW chip as MMIO in ACPI and so the kernel ignores the MMIO region declared by the UEFI memory map. This SSDT brings back NVRAM support Backlight SSDT Used for fixing backlight control support on laptops GPIO SSDT Used for creating a stub to allow VoodooI2C to connect onto, for laptops only XOSI SSDT Used for rerouting OSI calls to this SSDT, mainly used for tricking our hardware into thinking its booting Windows so we get better trackpad support. This is a very hacky solution known for breaking Windows boot, use the GPIO SSDT instead. Usage of XOSI will not be covered in this guide IRQ SSDT and ACPI patches Needed for fixing IRQ conflicts within the DSDT, for laptops mainly. SSDTTime exclusive What SSDTs do each platform need Please see the specific ACPI section of your config.plist, all SSDTs needed are covered there with a breif explainer. But here's a very quick TL;DR: Desktop SSDT IvyBridge Haswell/Broadwell Skylake KabyLake CoffeeLake CometLake AMD(15/16/17h) CPU CPU-PM(Run in Post-Install) SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG N/A EC SSDT-EC SSDT-EC SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX AWAC N/A N/A N/A N/A SSDT-AWAC SSDT-AWAC N/A NVRAM N/A N/A N/A N/A SSDT-PMC SSDT-PMC N/A High End Desktop SSDT IvyBridge-E Haswell-E Broadwell-E Skylake-X CPU CPU-PM(Run in Post-Install) SSDT-PLUG SSDT-PLUG SSDT-PLUG EC SSDT-EC SSDT-EC SSDT-EC SSDT-EC-USBX AWAC N/A N/A N/A SSDT-AWAC Laptop SSDT IvyBridge Haswell Broadwell Skylake KabyLake CoffeeLake(8thGen) Coffee/Comet/IceLake(9/10thGen) CPU CPU-PM(Run in Post-Install) SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG EC SSDT-EC SSDT-EC SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX Backlight SSDT-PNLF SSDT-PNLF SSDT-PNLF SSDT-PNLF SSDT-PNLF SSDT-PNLF-CFL SSDT-PNLF-CFL I2C TrackPad SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 AWAC N/A N/A N/A N/A N/A N/A SSDT-AWAC NVRAM N/A N/A N/A N/A N/A N/A SSDT-PMC IRQ Patch IRQ SSDT IRQ SSDT IRQ SSDT N/A N/A N/A N/A "},"ssdt-easy.html":{"url":"ssdt-easy.html","title":"SSDTs: Easy Way","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) SSDTs: The easy way So here we'll be using a super simple tool made by CorpNewt: SSDTTime What this tool does is dumps your DSDT from your firmware, and then creates SSDTs based off your DSDT. This must be done on the target machine running either Windows or Linux So what can't SSDTTime do?: HEDT SSDTs: The ACPI is odd on these platforms so manual work is required This includes X79, X99 and X299 systems Laptop EC fix: This is because you need to use an ACPI rename over an SSDT on laptops SSDT-PNLF: Need to be configured to your system SSDT-GPI0: Need to be configured to your system AWAC and RTC0 SSDTs: 300 series Intel boards will also need to figure his out(Z390 systems are most common for requiring this but some Gigabyte Z370 do as well) PMC SSDT: For fixing 300 series Intel NVRAM USBX SSDT: This is included on sample SSDTs but SSDTTime only makes the SSDT-EC part, Skylake and newer users can grab a pre-built here: SSDT-USBX.aml For users who don't have all the options avaible to them in SSDTTime, you can follow the \"SSDTs: The long way\" section. You can still use SSDTTime for SSDTs it support for you. Running SSDTTime Run the SSDTTime.bat file as Admin on the target machine and you should see something like this: What are all these options?: 1. FixHPET - Patch out IRQ Conflicts IRQ patching, mainly needed for X79, X99 and laptop users(use option C to omit conflicting legacy IRQs) 2. FakeEC - OS-aware Fake EC This is the SSDT-EC, required for Catalina users 3. PluginType - Sets plugin-type = 1 on CPU0/PR00 This is the SSDT-PLUG, for Intel only 4. Dump DSDT - Automatically dump the system DSDT Dumps your DSDT from your firmware What we want to do is select option 4. Dump DSDT first, then select the appropriate option(s) for your system. What about USBX? For Skylake and newer plus AMD, you can grab a pre-built file here: SSDT-USBX.aml. This file is plug and play and requires no device configuration, do not use on Broadwell and older. Troubleshooting note: See General Troubleshooting if you're having issues running SSDTTime Adding to OpenCore Don't forget that SSDTs need to be added to Opencore, reminder that .aml is complied, .dsl is code. Add only the .aml file: EFI/OC/ACPI config.plist -> ACPI -> Add Reminder that Cmd/Crtl+R with ProperTree pointed at your OC folder will add all your SSDTs, kexts and .efi drivers to the config for you. Do not add your DSDT to OpenCore, its already in your firmware. If you are unsure what this is referring to, go back to the OpenCore guide and select your config based of the architecture of your CPU. Users of FixHPET will also need to merge oc_patches.plist into their config.plist Steps to do this: Open both files, Delete the ACPI -> Patch section from config.plist Copy the ACPI -> Patch section from patches.plist Paste into where old patches were in config.plist "},"ssdt-long.html":{"url":"ssdt-long.html","title":"SSDTs: Long Way","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) SSDTs: The long way Well sadly some things are not handled by SSDTTime, well have no fear as making SSDTs is super easy. The basic process: Dump DSDT(the one SSDTTime did for use will work) Decompile DSDT Make SSDTs based of of it(You'll need either MaciASL or a text editor for this) Compile SSDTs Now continue forth and master the ways of ACPI! "},"Manual/dump.html":{"url":"Manual/dump.html","title":"Dumping the DSDT","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Getting a copy of our DSDT So to start, we'll need to get a copy of your DSDT from your firmware. The easiest way is grabbing the DSDT.aml SSDTTime dumped for us earlier but here are some other options: SSDTTime Supports both Windows and Linux for DSDT dumping 4. Dump DSDT - Automatically dump the system DSDT MaciASL Open the app on the target machine(must already be running macOS) and the system's DSDT will show, then File -> SaveAs System DSDT. Make sure the file format is ACPI Machine Language Binary(.AML), this will require the machine to be running macOS Do note that all ACPI patches from clover/OpenCore will be applied to the DSDT acpidump.exe In command prompt run path/to/acpidump.exe -b -n DSDT -z, this will dump your DSDT as a .dat file. Rename this to DSDT.aml F4 in Clover Boot menu DSDT can be found in EFI/CLOVER/ACPI/origin, the folder must exist before dumping acpidump.efi Add this to EFI/OC/Tools and in your config under Misc -> Tools with the argument: -b -n DSDT -z and select this option in OpenCore's picker. Rename the DSDT.dat to DSDT.aml. Tool is provided by acpica If OpenCore is having issues running acpidump, you can call it from the shell with OpenShell(reminder to add to both EFI/OC/Tools and in your config under Misc -> Tools ): shell> fs0: // replace with proper drive fs0:\\> dir // to verify this is the right directory Directory of fs0:\\ 01/01/01 3:30p EFI fs0:\\> cd EFI\\OC\\Tools fs0:\\EFI\\OC\\Tools> acpidump.efi -b -n DSDT -z "},"Manual/compile.html":{"url":"Manual/compile.html","title":"Decompiling and Compiling","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Compiling and decompiling ACPI Tables See Troubleshooting if you have dumping/compiling errors macOS Compiling and Decompiling Windows Compiling and Decompiling Linux Compiling and Decompiling macOS So compiling DSDTs and SSDTs are quite easy with macOS, all you need is MaciASL. To compile, just File -> SaveAs -> ACPI Machine Language Binary(.AML), decompiling is just opening the file in MaciASL. For those who prefer the command line, grab iasl-stable and run the following: path/to/iasl.exe path/to/DSDT.aml If compiled .aml file is provided, a decompiled .dsl file will be given and vice versa. Windows Compiling and decompiling on windows is fairly simple though, you will need iasl.exe and Command Prompt: path/to/iasl.exe path/to/DSDT.aml If compiled .aml file is provided, a decompiled .dsl file will be given and vice versa. Linux Compiling and decompiling with Linux is just as simple, you will need a copy of iasl. You can get it here (iasl) or through the iasl package in your package manager. iasl can be used as such: path/to/iasl path/to/DSDT.aml If compiled .aml file is provided, a decompiled .dsl file will be given and vice versa. "},"Desktops/desktop-disable.html":{"url":"Desktops/desktop-disable.html","title":"Disabling desktop dGPUs","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Disabling unsupported GPUs(Desktops) So this is mainly needed for GPUs that are not supported in macOS, mainly this will be Nvidia users who wish to pair an AMD GPU for macOS use. While WhateverGreen does support the boot-arg -wegnoegpu, this only works when running on iGPU so for the rest of us we'll need to make an SSDT. So to disable a specific GPU, we need to find a couple things: ACPI Path of the GPU SSDT-GPU-DISABLE Finding the ACPI Path of the GPU To find the PCI path of a GPU is fairly simple, best way to find it is running Windows: Open Device Manager Select Display Adapters, then right click your GPU and select Properties Under the Details Tab, search for \"Location Paths\" Note some GPUs may be hiding under \"BIOS device name\" The second \"ACPI\" is what we care about: ACPI(_SB_)#ACPI(PC02)#ACPI(BR2A)#ACPI(PEGP)#PCI(0000)#PCI(0000) Now converting this to an ACPI path is quite simple, remove the #ACPI and #PCI(0000): `_SB_.PC02.BR2A.PEGP And voila! We've found our ACPI path, now that we have everything we're ready to get cooking Making the SSDT To start grab our SSDT-GPU-DISABLE and open it up. Here there's a couple things to change: External (_SB_.PCI0.PEG0.PEGP, DeviceObj) Method (_SB.PCI0.PEG0.PEGP._DSM, 4, NotSerialized) For our example, we'll change all mentions of : PCI0 with PC02 PEG0 with BR2A Hint: If your ACPI path is a bit shorter than the example, this is fine. Just make sure the ACPI paths are correct to your device, some users may also need to adapt _SB_ to their path Now you're ready to compile the SSDT! "},"Laptops/backlight.html":{"url":"Laptops/backlight.html","title":"Backlight PNLF","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing Backlight So what this SSDT does is create a PNLF device for macOS to play with, specifically one with a hardware ID of APP0002. WhateverGreen will handle the rest of the work No configuration required for most, just drop the pre-built file into your EFI: SSDT-PNLF For most users SSDT-PNLFCFL For Coffee Lake and newer Note: there are some rare cases where the iGPU is called GPU0 or VIDin the DSDT, you can double check by searching for PCI0.GFX0, PCI0.VID and PCI0.GPU0. Whichever shows up is your device If Windows has been installed on the device, you can also do the following: Device Manager -> Display Adapters -> Properties -> Details > BIOS device name Note some GPUs may be hiding under \"BIOS device name\" "},"Laptops/trackpad.html":{"url":"Laptops/trackpad.html","title":"Trackpad GPI0","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing Trackpads This SSDT is used to force enable our GPI0 for VoodooI2C to connect onto. With most modern laptop DSDTs, there's a variable called GPEN or GPHD which are used for setting the status of the GPI0 device. For us, we want to enable the device. Finding our GPI0 So first things we need to do is find out what variable is used to enable our GPI0 device, lets open up our decompiled SSDT and search for Device (GPI0). Should give you a desult similar to this: What we care about from this is the _STA method: Method (_STA, 0, NotSerialized) { If ((GPHD == One)) { Return (0x03) } Return (0x0F) } What we want is for this to always return 0x0F when booting macOS, so we want to make an SSDT that will return GPHD == Zero in macOS. NOTE that you may have the other way around where GPHD needs to be set as One to return 0x0F. And your device name may also be different, don't throw random SSDTs in thinking it'll work Once you found the variable and what it should be set to, grab a copy of SSDT-GPI0.dsl and make the required edits. Then clean up with compiling it More examples With this example, we can see that we need both SBRG and GPEN to return One. If only one is present, it'll create some issues so in our SSDT we'll want to have both of them return One: DefinitionBlock(\"\", \"SSDT\", 2, \"ACDT\", \"GPI0\", 0) { External(GPEN, FieldUnitObj) External(SBRG, FieldUnitObj) Scope (\\) { If (_OSI (\"Darwin\")) { GPEN = One SBRG = One } } } GPIO Troubleshooting So if you're still having issues enabling your trackpad in macOS, you can try removing SSDT-GPIO and instead swap for the following. Note that using these 2 will most likely break Windows and Linux so only use XOSI when troubleshooting: SSDT-XOSI XOSI Rename: Comment String Change _OSI to XOSI Enabled Boolean YES Count Number 0 Limit Nuber 0 Find Data 5f4f5349 Replace Data 584f5349 "},"Laptops/laptop-disable.html":{"url":"Laptops/laptop-disable.html","title":"Disabling laptop dGPUs","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Disabling laptop dGPUs So with laptops, we can hide the dGPU from macOS with the little boot-arg called -wegnoegpu from WhateverGreen. But one small problem, the dGPU is still pulling power draining your battery slowly. We'll be going over 2 methods for disabling the dGPU in a laptop: Optimus Method Bumblebee Method Note that this is not needed for install, but recommended for post-install Optimus Method How this works is that we call the .off method found on Optimus GPUs, this is the expected way to power off a GPU but some may find their dGPU will power back up later on. Mainly seen in Lenovo's, the Optimus method should work for most users: To start, grab SSDT-dGPU-Off.dsl Next we need to get on Windows, and head to the following: Device Manager -> Display Adapters -> dGPU -> Properties -> Details > BIOS device name Note some GPUs may be hiding under \"BIOS device name\" This should provided you with an ACPI path for your dGPU, most commonly: Nvidia dGPU: \\_SB.PCI0.PEG0.PEGP AMD dGPU: \\_SB.PCI0.PEGP.DGFX Now with that, we'll need to change the ACPI path in the SSDT. Main sections: External(_SB.PCI0.PEG0.PEGP._OFF, MethodObj) If (CondRefOf(\\_SB.PCI0.PEG0.PEGP._OFF)) { \\_SB.PCI0.PEG0.PEGP._OFF() } Once adapted to your config, head to the compile section For those with sleep issues, you can refer to the original Rehabman thread Bumblebee Method With some machines, the simple .off call won't keep the card off properly, that's where the Bumblebee method comes in. This SSDT will actually send the dGPU into D3 state being the lowest power state a device can support. Credit to Mameo for the original adaptation. To start, grab SSDT-NoHybGfx.dsl Next we need to get on Windows, and head to the following: Device Manager -> Display Adapters -> dGPU -> Properties -> Details > BIOS device name This should provided you with an ACPI path for your dGPU, most commonly: Nvidia dGPU: \\_SB.PCI0.PEG0.PEGP AMD dGPU: \\_SB.PCI0.PEGP.DGFX Now with that, we'll need to change the ACPI path in the SSDT. Main sections: External (_SB_.PCI0.PEG0.PEGP._DSM, MethodObj) // dGPU ACPI Path External (_SB_.PCI0.PEG0.PEGP._PS3, MethodObj) // dGPU ACPI Path If ((CondRefOf (\\_SB.PCI0.PEG0.PEGP._DSM) && CondRefOf (\\_SB.PCI0.PEG0.PEGP._PS3))) // Card Off Request \\_SB.PCI0.PEG0.PEGP._DSM (ToUUID (\"a486d8f8-0bda-471b-a72b-6042a6b5bee0\"), 0x0100, 0x1A, Buffer (0x04) // Card Off \\_SB.PCI0.PEG0.PEGP._PS3 () Once adapted to your config, head to the compile section Now you're ready to compile the SSDT! "},"Universal/ec-fix.html":{"url":"Universal/ec-fix.html","title":"Embedded Controller ","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing Embedded Controller What we'll be doing is creating a fake Embedded Controller (EC) to satisfy macOS Catalina's EC addiction, and disabling the EC on desktops to prevent panics and crashes. You'll want to begin by grabbing either one of these uncompiled SSDT files: SSDT-EC-USBX For Skylake and newer and all AMD systems SSDT-EC For Broadwell and older Fixing the Path For Intel systems, the path is likely correct, though it's worth double checking. You will want to find your current EC by opening your decompiled DSDT and searching for PNP0C09. You should get a result similar to this: Note: If your EC device happens to already be named EC in your DSDT, you do not need SSDT-EC at all and can move on. As you can see, PNP0C09 is found under the EC0 device and _SB.PC00.LPC0 scope. Looking at the SSDT though, this differs from the path _SB_.PCI0.LPCB seen within. This will need to be corrected in the SSDT to match what is found in the DSDT. Using the above image, you should get something similar to this: Scope (\\_SB.PC00.LPC0) Generally, PC00.LPC0 is most common on Intel HEDT while PCI0.SBRG is most common on AMD. Always verify your path and device. DO NOT ASSUME. If you are having issues finding the Scope, you can use the below Hardware IDs or Addresses: Finding the LowPinCount path: Intel: Search Name (_ADR, 0x001F0000) AMD: Search Name (_ADR, 0x00140003) Finding the PCI path: Intel: Search PNP0A08 (If multiple show up, use the first one) AMD: Assume PCI0(most AMD DSDTs don't declare the PCI path directly) Make sure that you do not rename Device (EC). This is what macOS Catalina looks for to boot! Desktop users, continue down below to disabling your actual EC Disabling real EC (Desktops only) For desktops, it's preferable to disable the actual Embedded Controller as it is not supported by macOS 100% and is known to sometimes cause panics. If we use the screenshot above, we'll see that the device name is EC0. Other common names for ECs are H_EC, ECDV, and EC0. You'll want to grab your SSDT again and uncomment the _STA method to disable it (remove the /* and */ around it): /* Like above, make sure the path is correct for the External and Scope field. What happens if device in the DSDT is already named EC For laptops, you don't need SSDT-EC at all. What happens if multiple PNP0C09 show up When this happens you need to figure out which is the main and which is not, it's fairly easy to figure out. Check each controller for the following properties: _HID (Hardware ID) _CRS (Current Resource Settings) _GPE (General Purpose Events) Note if you have an STA Method as well, see below: STA Edge Case What happens if no PNP0C09 show up? This means you only need to fake an Embedded Controller rather so that AppleBusPowerController will load and handle USB power properly and continue booting. To make the actual SSDT, its almost plug and play as no uncommenting needed. The main thing that needs to be changed: LowPinCount path PCI path We want to make sure the SSDT hooks into our DSDT correctly so we need to make sure the ACPI path is correct: Finding the LowPinCount path: Intel: Search Name (_ADR, 0x001F0000) AMD: Search Name (_ADR, 0x00140003) Finding the PCI path: Intel: Search PNP0A08 (If multiple show up, use the first one) AMD: Assume PCI0(most AMD DSDTs don't declare the PCI path directly) Once you find out, change PCI0.LPCB to your correct path: Scope (\\_SB.PC00.LPC0) For those having issues, you can also check Device Manager -> CPU -> BIOS device Name. Windows will only report the main EC so will save you some headache on that STA Edge Case Do note that if your PNP0C09 device has a Method (_STA already you can skip down to \"What happens if no PNP0C09 show up?\". The reason for this is that the real EC is considered disabled already. Correcting USB Power Hey what about USBX? Do I need to do anything? USBX is universal across all systems, it just creates a USBX device that forces USB power properties. This is crucial for fixing Mics, DACs, Webcams, Bluetooth Dongles and other high power draw devices. This is not mandatory to boot but should be added in post-install if not before. Note that it requires the EC functioning correctly and that USBX is only used on skylake+ systems - those on Broadwell and older can ignore. Now you're ready to compile the SSDT! "},"Universal/plug.html":{"url":"Universal/plug.html","title":"Plugin type","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing Power Management CPU naming is fairly easy to figure out as well, open your decompiled DSDT and search for Processor. This should give you a result like this: As we can see, the first processor in our list is PR00. This is what we'll be applying the plugin-type=1 property too. Now grab SSDT-PLUG and replace the default CPU0 with our PR00. There's a couple things to note: There's 2 mentions of CPU0 to change The PR path may need to be changed, in our example we can see that our PR00 has SB in front. So in our final example, we'd have _SB_.PR00 and \\_SB.PR00 There are also some edge cases with Processor, specifically on HEDT series like X79, X99 and X299. This edge case is that the ACPI path is much longer and not so obvious: If we then search for instances of CP00 we find that it's ACPI path is SB.SCK0.CP00: So for this X299 board, we'd change \\_PR.CPU0 with \\_SB.SCK0.CP00 and External (_PR_.CPU0, ProcessorObj) with External (_SB_.SCK0.CP00, ProcessorObj) External (_PR_.CPU0, ProcessorObj) For those having issues, you can also check Device Manager -> CPU -> BIOS device Name Note: X299 may report CP10 or higher for the CPU, when this happens use CP00 instead. This issue is due to weird numeration on Windows' side Now you're ready to compile the SSDT! "},"Universal/awac.html":{"url":"Universal/awac.html","title":"AWAC vs RTC","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing System Clocks For Intel 300 series chipsets and newer, this also includes X299 refreshes and Icelake laptops. Common machines: X299X (10th Gen refresh) B360 B365 H310 H370 Z370 (Gigabyte and AsRock boards with newer BIOS versions) Z390 400 series (Cometlake) 495 series (Icelake) So on newer Intel 300 series motherboards, manufactures started pushing for a new type of system clock: AWAC( A Weird Ass Clock). One small problem, macOS doesn't know what the hell an AWAC clock is instead only familiar with the legacy RTC(Real Time Clock). So we need to figure out how to bring back the old clock, thats where SSDT-AWAC and SSDT-RTC0 come in: SSDT-AWAC Disables AWAC and enables RTC In your DSDT, there's a variable called STAS used for holding either a One or Zero to determine which clock to use(One for RTC and Zero for AWAC) SSDT-RTC0 Used for creating a fake RTC device for macOS to play with In very rare circumstances, some DSDTs may not have a legacy RTC to fall back on. When this happens, we'll want to create a fake device to make macOS happy Note: AWAC actually stands for ACPI Wake Alarm Counter/Clock for those curious, though I'll forever know it as A Weird Ass Clock ;p Determining which SSDT you need To determine whether you need SSDT-AWAC or SSDT-RTC0: open your decompiled DSDT and search for Device (AWAC) If nothing shows up then no need to continue and no need for this SSDT as you have no AWAC. Otherwise, continue on! If you get a result then you have an AWAC system clock present, then continue with the next search for STAS: As you can see we found the STAS in our DSDT, this means we're able to force enable our Legacy RTC. In this case, SSDT-AWAC will be used As-Is with no modifications required. Just need to compile. Note that STAS may be found in AWAC first instead of RTC like in our example, this is normal. For systems where no STAS shows up but you do have AWAC, you can use SSDT-RTC0 though you will need to check the naming of LPC in your DSDT By default the SSDT uses LPCB, you can check what your system uses by just searching for Name (_ADR, 0x001F0000). This address is used for Low Pin Count devices(LPC) but the device name can vary between LPCB, LBC or LBC0: Now you're ready to compile the SSDT! "},"Universal/nvram.html":{"url":"Universal/nvram.html","title":"NVRAM PMC","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing NVRAM This SSDT is required for all \"true\" 300 series motherboards and newer(Z370 is excluded), it specifically brings back NVRAM support and requires very little configuration for the end user. B360 B365 H310 H370 Z390 400 series (Cometlake) 495 series (Icelake) By default it uses PCI0.LPCB for the PCI and LowPinCount path. The device names can vary between PC00 and PCI0 for PCI path and LPCB, LBC and LBC0 for LowPinCount path. To see what you have: Finding the LowPinCount path: Intel: Search Name (_ADR, 0x001F0000) Finding the PCI path: Intel: Search PNP0A08 (If multiple show up, use the first one) Now you're ready to compile the SSDT! "},"Universal/irq.html":{"url":"Universal/irq.html","title":"IRQ Fix","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing IRQ Conflicts So you miss having those fancy hot-patches from Clover like FixIPIC, FixTMR, FixRTC, FixHPET, etc Well 1 very small problem, figuring out IRQ patching is a massive headache. I highly recommend you use SSDTTime. So head over to SSDT: Easy Way on how to make it.(use option C to omit conflicting legacy IRQs) "},"Universal/spoof.html":{"url":"Universal/spoof.html","title":"GPU Spoof","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Renaming GPUs So this is mainly needed for GPUs that are not natively supported out of the box due to their names, most commonly: R9 290/390 R9 280/380 R7 270/370 R9 260/360 R7 250 R7 240 Instead, these GPUs need to be \"spoofed\" or faked into a model that closely matches theirs, generally this will be the \"X\" variant of the card. For some reason Apple never bothered adding the PCI IDs for these other cards even though their GPU cores are supported by the driver. So to spoof the GPU, we need to find a couple things: Suitable PCI ID for the GPU ACPI Path of the GPU SSDT-GPU-SPOOF Finding a suitable PCI ID To find a suitable PCI ID, we'll be using PCI ID Repository which has a full database of all AMD GPUs. For this example, we'll be creating a Spoof SSDT for the R9 390. For a full list of supported GPUs, please see the GPU Buyers Guide. The closest match to this GPU would be the 390X, and looking on that site near the top gives us this: Vendor 1002 -> Device 1002:67b0 Now lets break this down into a device ID we can use: 1002: The vendor ID, all AMD devices have this ID 67B0: The device ID, this is what we care about So how do we convert this to a fake ID? Well the format of a fake ID: \"device-id\", Buffer (0x04) { 0xB0, 0x67, 0x00, 0x00 }, As you can see, the bytes are swapped in pairs. Keep this in mind when we make our SSDT The specifics are due to Endianness for those who are curious Finding the ACPI Path of the GPU To find the PCI path of a GPU is fairly simple, best way to find it is running Windows: Open Device Manager Select Display Adapters, then right click your GPU and select Properties Under the Details Tab, search for \"Location Paths\" Note some GPUs may be hiding under \"BIOS device name\" The second \"ACPI\" is what we care about: ACPI(_SB_)#ACPI(PC02)#ACPI(BR2A)#ACPI(PEGP)#PCI(0000)#PCI(0000) Now converting this to an ACPI path is quite simple, remove the #ACPI and #PCI(0000): `_SB_.PC02.BR2A.PEGP And voila! We've found our ACPI path, now that we have everything we're ready to get cooking Making the SSDT To start grab our SSDT-GPU-SPOOF and open it up. Here there's a couple things to change: External (_SB_.PCI0, DeviceObj) External (_SB_.PCI0.PEG0.PEGP, DeviceObj) For our example, we'll change all mentions of : PCI0 with PC02 PEG0 with BR2A Hint: If your ACPI path is a bit shorter than the example, this is fine. Just make sure the ACPI paths are correct to your device. Now that the ACPI pathing is correct, we can finally apply our fake ID!!! So the 2 parts we want to change: device ID: \"device-id\", Buffer (0x04) { 0xB0, 0x67, 0x00, 0x00 }, Model: \"model\", Buffer () { \"AMD Radeon R9 390\" } \"device-id\" will be set to our PCI ID that we found in \"Finding a suitable PCI ID\" and \"model\" is mainly cosmetic Now you're ready to compile the SSDT! "},"Universal/smbus.html":{"url":"Universal/smbus.html","title":"Fixing SMBus Support","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Fixing SMBus support This section of the guide refers to fixing AppleSMBus support in macOS, what is AppleSMBus? Well this mainly handles the System Management Bus, which has many functions like: AppleSMBusController Aids with correct temperature, fan, voltage, ICH, etc readings AppleSMBusPCI Same idea as AppleSMBusController except for low bandwidth PCI devices Memory Reporting Aids in proper memory reporting and can aid in getting better kernel panic details if memory related Other things SMBus does: SMBus wiki For install purposes, this SSDT isn't needed but for post-install it's recommended to put the final touches on your hack. So to get started, we'll want to grab our SMBus SSDT: SSDT-SBUS-MCHC.dsl So the important parts we care about are: External (_SB_.PCI0, DeviceObj) To find the correct pathing for your devices, grab Hackintool (Github link) and head to the PCI tab: Look for the SMBus device under Subclass, then look beside and you'll see the ACPI path(under IOReg Name). To convert , omit @... /PC00@0/SMBS@1F,4 -> PC00.SMBS Once finished, it'll look something like this: External (_SB_.PC00, DeviceObj) For those having issues, you can also check Device Manager -> CPU -> BIOS device Name Note: The MCHC is actually the DRAM controller, similar idea to SMBus for fixing memory reporting Now you're ready to compile the SSDT! "},"cleanup.html":{"url":"cleanup.html","title":"Cleanup","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Cleanup So you've made all your SSDTs but now there's one thing left: Adding them to Opencore The 2 main locations: EFI/OC/ACPI (Only .aml files, reminder to compile your SSDTs) config.plist -> ACPI -> Add You can save yourself some work with the config.plist by running Cmd/Ctrl+R in ProperTree. Reminder do not add your DSDT.aml to your EFI Users of FixHPET will also need to merge oc_patches.plist into their config.plist Steps to do this: Open both files, Delete the ACPI -> Patch section from config.plist Copy the ACPI -> Patch section from patches.plist Paste into where old patches were in config.plist "},"troubleshooting.html":{"url":"troubleshooting.html","title":"Troubleshooting","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Troubleshooting Fixing SSDTTime: Could not locate or download iasl! Can't run acpidump.efi iASL warning, # unresolved Decompiling Error Invalid character (0x3D), expecting ASL keyword or name Syntax error, unexpected PARSEOP_ONE, expecting '(' Fixing SSDTTime: Could not locate or download iasl! This is usually due to an outdated version of Python, try either updating Python or add iasl to the scripts folder for SSDTTime: iasl macOS version iasl Windows version iasl Linux version Can't run acpidump.efi from OpenCore Grab OpenShell and add it to EFI/OC/Tools and config.plist -> Misc -> Tools. Next, call upon OpenCore shell and enter the following: shell> fs0: //replace with proper drive fs0:\\> dir //to verify this is the right directory Directory of fs0:\\ 01/01/01 3:30p EFI fs0:\\> cd EFI\\OC\\Tools //note that its with forward slashes fs0:\\EFI\\OC\\Tools> acpidump.efi -b -n DSDT -z iASL warning, # unresolved If you try to decompile your DSDT and get an error similar to this: iASL Warning: There were 19 external control methods found during disassembly, but only 0 were resolved (19 unresolved) This happens when one ACPI table requires the rest for proper referencing, it does not accept the creation of DSDTs as we're only using it for creating a select few SSDTs. For those who are worried, you can run the following: iasl * [insert all ACPI files here] Decompiling Error Loading Acpi table from file iASLAwjHrs.aml Acpi table [DSDT] successfully installed and loaded Pass 1 parse of [DSDT] This is a common error on DSDTs that have methods that aren't supported by maciASL, the easiest way is to delete maciASL and make sure you grab it from Acidanthera's repo: maciASL Invalid character (0x3D), expecting ASL keyword or name Similar to the above error, you're running an outdated copy of maciASL. Make sure you're using the latest from Acidanthera's repo: maciASL Syntax error, unexpected PARSEOP_ONE, expecting '(' Similar to the above 2 errors, you're running an outdated copy of maciASL. Make sure you're using the latest from Acidanthera's repo: maciASL "},"CONTRIBUTING.html":{"url":"CONTRIBUTING.html","title":"Contributing","keywords":"","body":" Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time) Supporting the guides Note: This is a community run guide which is not officially endorsed by Acidanthera. Please do not bug Acidanthera with issues about this guide. Want to help support the guide? Well there's some ways you can help! Contributing via Issues Contributing via PRs Note: For those wanting to contribute financially, we seriously appreciate it but we're a non-profit organization. We do this to teach, not to make money. If you have some money left over we highly recommend donating it to a charity. Crohn's and Colitis Canada is one we recommend if you have none on mind. Contributing via Issues Contributing via Issues is pretty simple but there are some rules: Keep issues tab dedicated to guides issues only, no personal hackintosh issues. It is not a place to discuss installation issues. If for a typo or better clarification, please indicate what page it was on. Would appreciate not going for a scavenger hunt on where these issues are. You can find the issues tab here: Getting Started With ACPI Issues Contributing via PRs Some guidelines when contributing via PRs: Use your brain (please). Proofread your submissions. Pull Requests can be denied if we feel it does not fit or has inaccurate information. We will generally tell you why it is rejected though or ask for revisions. We would also appreciate sources for any bigger commits to make it easier on us to verify the info your provide is valid Images must be hosted locally in the repo under the /images/ folder Your PR must be run through a markdown lint and have all issues fixed. In general, try to avoid using \"non-Acidanthera\" tools when possible. Generally we want to avoid use of third-party tools - though if it's impossible otherwise, then you can link it. Tools explicitly banned: UniBeast, MultiBeast and KextBeast More info can be found here: Tonymacx86-stance Transmac Know for creating borked USB drives Niresh Installers We'd like to avoid piracy with the guides How to Contribute Best way to test your commits and make sure they are formatted correctly is downloading nodejs and getting the gitbook-cli and markdownlint-cli tools. When you run gitbook serve, it will set up a local webserver which you can connect to view the changes you made. markdownlint * will throw any errors at you about formatting as well, and markdownlint -f * will attempt to fix these. Fork this repo Install the required tools: npm install -g markdownlint-cli npm install -g gitbook-cli Make your changes. Build the site: gitbook install (To install all the required gitbook plugins) gitbook serve (Preview the site) Can be found at http://localhost:4000 Check markdown format: markdownlint -f * (To fix any potential issues) Tips Some tools that make contributing a bit easier: Typora for real time markdown rendering. TextMate for easy and powerful mass find/replace. Github Desktop for more user friendly GUI. "}} \ No newline at end of file +{"./":{"url":"./","title":"Getting Started With ACPI","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Getting started with ACPI A quick explainer on ACPI So what are DSDTs and SSDTs? Well, these are tables present in your firmware that outline hardware devices like USB controllers, CPU threads, embedded controllers, system clocks and such. A DSDT(Differentiated System Description Table) can be seen as the body holding most of the info with smaller bits of info being passed by the SSDT(Secondary System Description Table). You can think of the DSDT as the building blueprints with SSDTs being sticky notes outlining extra details to the project You can read more about ACPI and it's spec here: ACPI 6.3 Manual So why do we care about these tables? macOS can be very picky about the devices present in the DSDT and so our job is to correct it. The main devices that need to be corrected for macOS to work properly: Embedded controllers(EC) All semi-modern intel machines have an EC (usually called H_EC, ECDV, EC0, etc...) exposed in their DSDT, with many AMD systems also having it exposed. These controllers are generally not compatible with macOS and can cause panics, so then need to be hidden from macOS. macOS Catalina requires a device named EC to be present though, so a dummy EC is created. With laptops, the actual embedded controller still needs to be enabled for battery and hotkeys to work, and renaming the EC can additionally cause issues with windows, so creating a fake EC without disabling the real embedded controller is preferable to renaming. Plugin type This allows the use of XCPM providing native CPU power management on Intel Haswell and newer CPUs, the SSDT will connect to the first thread of the CPU. Not meant for AMD AWAC system clock. This applies to all 300 series motherboards including many Z370 boards, the specific issue is that newer boards ship with AWAC clock enabled. This is a problem because macOS cannot communicate with AWAC clocks, so this requires us to either force on the legacy RTC clock or if unavailable create a fake one for macOS to play with NVRAM SSDT True 300 series motherboards(non-Z370) don't declare the FW chip as MMIO in ACPI and so the kernel ignores the MMIO region declared by the UEFI memory map. This SSDT brings back NVRAM support Backlight SSDT Used for fixing backlight control support on laptops GPIO SSDT Used for creating a stub to allow VoodooI2C to connect onto, for laptops only XOSI SSDT Used for rerouting OSI calls to this SSDT, mainly used for tricking our hardware into thinking its booting Windows so we get better trackpad support. This is a very hacky solution known for breaking Windows boot, use the GPIO SSDT instead. Usage of XOSI will not be covered in this guide IRQ SSDT and ACPI patches Needed for fixing IRQ conflicts within the DSDT, for laptops mainly. SSDTTime exclusive What SSDTs do each platform need Please see the specific ACPI section of your config.plist, all SSDTs needed are covered there with a breif explainer. But here's a very quick TL;DR: Desktop SSDT IvyBridge Haswell/Broadwell Skylake KabyLake CoffeeLake CometLake AMD(15/16/17h) CPU CPU-PM(Run in Post-Install) SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG N/A EC SSDT-EC SSDT-EC SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX AWAC N/A N/A N/A N/A SSDT-AWAC SSDT-AWAC N/A NVRAM N/A N/A N/A N/A SSDT-PMC SSDT-PMC N/A High End Desktop SSDT IvyBridge-E Haswell-E Broadwell-E Skylake-X CPU CPU-PM(Run in Post-Install) SSDT-PLUG SSDT-PLUG SSDT-PLUG EC SSDT-EC SSDT-EC SSDT-EC SSDT-EC-USBX AWAC N/A N/A N/A SSDT-AWAC Laptop SSDT IvyBridge Haswell Broadwell Skylake KabyLake CoffeeLake(8thGen) Coffee/Comet/IceLake(9/10thGen) CPU CPU-PM(Run in Post-Install) SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG SSDT-PLUG EC SSDT-EC SSDT-EC SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX SSDT-EC-USBX Backlight SSDT-PNLF SSDT-PNLF SSDT-PNLF SSDT-PNLF SSDT-PNLF SSDT-PNLF-CFL SSDT-PNLF-CFL I2C TrackPad SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 SSDT-GPI0 AWAC N/A N/A N/A N/A N/A N/A SSDT-AWAC NVRAM N/A N/A N/A N/A N/A N/A SSDT-PMC IRQ Patch IRQ SSDT IRQ SSDT IRQ SSDT N/A N/A N/A N/A "},"ssdt-easy.html":{"url":"ssdt-easy.html","title":"SSDTs: Easy Way","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:15 GMT+0000 (Coordinated Universal Time) SSDTs: The easy way So here we'll be using a super simple tool made by CorpNewt: SSDTTime What this tool does is dumps your DSDT from your firmware, and then creates SSDTs based off your DSDT. This must be done on the target machine running either Windows or Linux So what can't SSDTTime do?: HEDT SSDTs: The ACPI is odd on these platforms so manual work is required This includes X79, X99 and X299 systems Laptop EC fix: This is because you need to use an ACPI rename over an SSDT on laptops SSDT-PNLF: Need to be configured to your system SSDT-GPI0: Need to be configured to your system AWAC and RTC0 SSDTs: 300 series Intel boards will also need to figure his out(Z390 systems are most common for requiring this but some Gigabyte Z370 do as well) PMC SSDT: For fixing 300 series Intel NVRAM USBX SSDT: This is included on sample SSDTs but SSDTTime only makes the SSDT-EC part, Skylake and newer users can grab a pre-built here: SSDT-USBX.aml For users who don't have all the options avaible to them in SSDTTime, you can follow the \"SSDTs: The long way\" section. You can still use SSDTTime for SSDTs it support for you. Running SSDTTime Run the SSDTTime.bat file as Admin on the target machine and you should see something like this: What are all these options?: 1. FixHPET - Patch out IRQ Conflicts IRQ patching, mainly needed for X79, X99 and laptop users(use option C to omit conflicting legacy IRQs) 2. FakeEC - OS-aware Fake EC This is the SSDT-EC, required for Catalina users 3. PluginType - Sets plugin-type = 1 on CPU0/PR00 This is the SSDT-PLUG, for Intel only 4. Dump DSDT - Automatically dump the system DSDT Dumps your DSDT from your firmware What we want to do is select option 4. Dump DSDT first, then select the appropriate option(s) for your system. What about USBX? For Skylake and newer plus AMD, you can grab a pre-built file here: SSDT-USBX.aml. This file is plug and play and requires no device configuration, do not use on Broadwell and older. Troubleshooting note: See General Troubleshooting if you're having issues running SSDTTime Adding to OpenCore Don't forget that SSDTs need to be added to Opencore, reminder that .aml is complied, .dsl is code. Add only the .aml file: EFI/OC/ACPI config.plist -> ACPI -> Add Reminder that Cmd/Crtl+R with ProperTree pointed at your OC folder will add all your SSDTs, kexts and .efi drivers to the config for you. Do not add your DSDT to OpenCore, its already in your firmware. If you are unsure what this is referring to, go back to the OpenCore guide and select your config based of the architecture of your CPU. Users of FixHPET will also need to merge oc_patches.plist into their config.plist Steps to do this: Open both files, Delete the ACPI -> Patch section from config.plist Copy the ACPI -> Patch section from patches.plist Paste into where old patches were in config.plist "},"ssdt-long.html":{"url":"ssdt-long.html","title":"SSDTs: Long Way","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:15 GMT+0000 (Coordinated Universal Time) SSDTs: The long way Well sadly some things are not handled by SSDTTime, well have no fear as making SSDTs is super easy. The basic process: Dump DSDT(the one SSDTTime did for use will work) Decompile DSDT Make SSDTs based of of it(You'll need either MaciASL or a text editor for this) Compile SSDTs Now continue forth and master the ways of ACPI! "},"Manual/dump.html":{"url":"Manual/dump.html","title":"Dumping the DSDT","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Getting a copy of our DSDT So to start, we'll need to get a copy of your DSDT from your firmware. The easiest way is grabbing the DSDT.aml SSDTTime dumped for us earlier but here are some other options: SSDTTime Supports both Windows and Linux for DSDT dumping 4. Dump DSDT - Automatically dump the system DSDT MaciASL Open the app on the target machine(must already be running macOS) and the system's DSDT will show, then File -> SaveAs System DSDT. Make sure the file format is ACPI Machine Language Binary(.AML), this will require the machine to be running macOS Do note that all ACPI patches from clover/OpenCore will be applied to the DSDT acpidump.exe In command prompt run path/to/acpidump.exe -b -n DSDT -z, this will dump your DSDT as a .dat file. Rename this to DSDT.aml F4 in Clover Boot menu DSDT can be found in EFI/CLOVER/ACPI/origin, the folder must exist before dumping acpidump.efi Add this to EFI/OC/Tools and in your config under Misc -> Tools with the argument: -b -n DSDT -z and select this option in OpenCore's picker. Rename the DSDT.dat to DSDT.aml. Tool is provided by acpica If OpenCore is having issues running acpidump, you can call it from the shell with OpenShell(reminder to add to both EFI/OC/Tools and in your config under Misc -> Tools ): shell> fs0: // replace with proper drive fs0:\\> dir // to verify this is the right directory Directory of fs0:\\ 01/01/01 3:30p EFI fs0:\\> cd EFI\\OC\\Tools fs0:\\EFI\\OC\\Tools> acpidump.efi -b -n DSDT -z "},"Manual/compile.html":{"url":"Manual/compile.html","title":"Decompiling and Compiling","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Compiling and decompiling ACPI Tables See Troubleshooting if you have dumping/compiling errors macOS Compiling and Decompiling Windows Compiling and Decompiling Linux Compiling and Decompiling macOS So compiling DSDTs and SSDTs are quite easy with macOS, all you need is MaciASL. To compile, just File -> SaveAs -> ACPI Machine Language Binary(.AML), decompiling is just opening the file in MaciASL. For those who prefer the command line, grab iasl-stable and run the following: path/to/iasl.exe path/to/DSDT.aml If compiled .aml file is provided, a decompiled .dsl file will be given and vice versa. Windows Compiling and decompiling on windows is fairly simple though, you will need iasl.exe and Command Prompt: path/to/iasl.exe path/to/DSDT.aml If compiled .aml file is provided, a decompiled .dsl file will be given and vice versa. Linux Compiling and decompiling with Linux is just as simple, you will need a copy of iasl. You can get it here (iasl) or through the iasl package in your package manager. iasl can be used as such: path/to/iasl path/to/DSDT.aml If compiled .aml file is provided, a decompiled .dsl file will be given and vice versa. "},"Desktops/desktop-disable.html":{"url":"Desktops/desktop-disable.html","title":"Disabling desktop dGPUs","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Disabling unsupported GPUs(Desktops) So this is mainly needed for GPUs that are not supported in macOS, mainly this will be Nvidia users who wish to pair an AMD GPU for macOS use. While WhateverGreen does support the boot-arg -wegnoegpu, this only works when running on iGPU so for the rest of us we'll need to make an SSDT. So to disable a specific GPU, we need to find a couple things: ACPI Path of the GPU SSDT-GPU-DISABLE Finding the ACPI Path of the GPU To find the PCI path of a GPU is fairly simple, best way to find it is running Windows: Open Device Manager Select Display Adapters, then right click your GPU and select Properties Under the Details Tab, search for \"Location Paths\" Note some GPUs may be hiding under \"BIOS device name\" The second \"ACPI\" is what we care about: ACPI(_SB_)#ACPI(PC02)#ACPI(BR2A)#ACPI(PEGP)#PCI(0000)#PCI(0000) Now converting this to an ACPI path is quite simple, remove the #ACPI and #PCI(0000): `_SB_.PC02.BR2A.PEGP And voila! We've found our ACPI path, now that we have everything we're ready to get cooking Making the SSDT To start grab our SSDT-GPU-DISABLE and open it up. Here there's a couple things to change: External (_SB_.PCI0.PEG0.PEGP, DeviceObj) Method (_SB.PCI0.PEG0.PEGP._DSM, 4, NotSerialized) For our example, we'll change all mentions of : PCI0 with PC02 PEG0 with BR2A Hint: If your ACPI path is a bit shorter than the example, this is fine. Just make sure the ACPI paths are correct to your device, some users may also need to adapt _SB_ to their path Now you're ready to compile the SSDT! "},"Laptops/backlight.html":{"url":"Laptops/backlight.html","title":"Backlight PNLF","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing Backlight So what this SSDT does is create a PNLF device for macOS to play with, specifically one with a hardware ID of APP0002. WhateverGreen will handle the rest of the work No configuration required for most, just drop the pre-built file into your EFI: SSDT-PNLF For most users SSDT-PNLFCFL For Coffee Lake and newer Note: there are some rare cases where the iGPU is called GPU0 or VIDin the DSDT, you can double check by searching for PCI0.GFX0, PCI0.VID and PCI0.GPU0. Whichever shows up is your device If Windows has been installed on the device, you can also do the following: Device Manager -> Display Adapters -> Properties -> Details > BIOS device name Note some GPUs may be hiding under \"BIOS device name\" "},"Laptops/trackpad.html":{"url":"Laptops/trackpad.html","title":"Trackpad GPI0","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing Trackpads This SSDT is used to force enable our GPI0 for VoodooI2C to connect onto. With most modern laptop DSDTs, there's a variable called GPEN or GPHD which are used for setting the status of the GPI0 device. For us, we want to enable the device. Finding our GPI0 So first things we need to do is find out what variable is used to enable our GPI0 device, lets open up our decompiled SSDT and search for Device (GPI0). Should give you a desult similar to this: What we care about from this is the _STA method: Method (_STA, 0, NotSerialized) { If ((GPHD == One)) { Return (0x03) } Return (0x0F) } What we want is for this to always return 0x0F when booting macOS, so we want to make an SSDT that will return GPHD == Zero in macOS. NOTE that you may have the other way around where GPHD needs to be set as One to return 0x0F. And your device name may also be different, don't throw random SSDTs in thinking it'll work Once you found the variable and what it should be set to, grab a copy of SSDT-GPI0.dsl and make the required edits. Then clean up with compiling it More examples With this example, we can see that we need both SBRG and GPEN to return One. If only one is present, it'll create some issues so in our SSDT we'll want to have both of them return One: DefinitionBlock(\"\", \"SSDT\", 2, \"ACDT\", \"GPI0\", 0) { External(GPEN, FieldUnitObj) External(SBRG, FieldUnitObj) Scope (\\) { If (_OSI (\"Darwin\")) { GPEN = One SBRG = One } } } GPIO Troubleshooting So if you're still having issues enabling your trackpad in macOS, you can try removing SSDT-GPIO and instead swap for the following. Note that using these 2 will most likely break Windows and Linux so only use XOSI when troubleshooting: SSDT-XOSI XOSI Rename: Comment String Change _OSI to XOSI Enabled Boolean YES Count Number 0 Limit Nuber 0 Find Data 5f4f5349 Replace Data 584f5349 "},"Laptops/laptop-disable.html":{"url":"Laptops/laptop-disable.html","title":"Disabling laptop dGPUs","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Disabling laptop dGPUs So with laptops, we can hide the dGPU from macOS with the little boot-arg called -wegnoegpu from WhateverGreen. But one small problem, the dGPU is still pulling power draining your battery slowly. We'll be going over 2 methods for disabling the dGPU in a laptop: Optimus Method Bumblebee Method Note that this is not needed for install, but recommended for post-install Optimus Method How this works is that we call the .off method found on Optimus GPUs, this is the expected way to power off a GPU but some may find their dGPU will power back up later on. Mainly seen in Lenovo's, the Optimus method should work for most users: To start, grab SSDT-dGPU-Off.dsl Next we need to get on Windows, and head to the following: Device Manager -> Display Adapters -> dGPU -> Properties -> Details > BIOS device name Note some GPUs may be hiding under \"BIOS device name\" This should provided you with an ACPI path for your dGPU, most commonly: Nvidia dGPU: \\_SB.PCI0.PEG0.PEGP AMD dGPU: \\_SB.PCI0.PEGP.DGFX Now with that, we'll need to change the ACPI path in the SSDT. Main sections: External(_SB.PCI0.PEG0.PEGP._OFF, MethodObj) If (CondRefOf(\\_SB.PCI0.PEG0.PEGP._OFF)) { \\_SB.PCI0.PEG0.PEGP._OFF() } Once adapted to your config, head to the compile section For those with sleep issues, you can refer to the original Rehabman thread Bumblebee Method With some machines, the simple .off call won't keep the card off properly, that's where the Bumblebee method comes in. This SSDT will actually send the dGPU into D3 state being the lowest power state a device can support. Credit to Mameo for the original adaptation. To start, grab SSDT-NoHybGfx.dsl Next we need to get on Windows, and head to the following: Device Manager -> Display Adapters -> dGPU -> Properties -> Details > BIOS device name This should provided you with an ACPI path for your dGPU, most commonly: Nvidia dGPU: \\_SB.PCI0.PEG0.PEGP AMD dGPU: \\_SB.PCI0.PEGP.DGFX Now with that, we'll need to change the ACPI path in the SSDT. Main sections: External (_SB_.PCI0.PEG0.PEGP._DSM, MethodObj) // dGPU ACPI Path External (_SB_.PCI0.PEG0.PEGP._PS3, MethodObj) // dGPU ACPI Path If ((CondRefOf (\\_SB.PCI0.PEG0.PEGP._DSM) && CondRefOf (\\_SB.PCI0.PEG0.PEGP._PS3))) // Card Off Request \\_SB.PCI0.PEG0.PEGP._DSM (ToUUID (\"a486d8f8-0bda-471b-a72b-6042a6b5bee0\"), 0x0100, 0x1A, Buffer (0x04) // Card Off \\_SB.PCI0.PEG0.PEGP._PS3 () Once adapted to your config, head to the compile section Now you're ready to compile the SSDT! "},"Universal/ec-fix.html":{"url":"Universal/ec-fix.html","title":"Embedded Controller","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing Embedded Controller What we'll be doing is creating a fake Embedded Controller (EC) to satisfy macOS Catalina's EC addiction, and disabling the EC on desktops to prevent panics and crashes. You'll want to begin by grabbing either one of these uncompiled SSDT files: SSDT-EC-USBX For Skylake and newer and all AMD systems SSDT-EC For Broadwell and older Fixing the Path For Intel systems, the path is likely correct, though it's worth double checking. You will want to find your current EC by opening your decompiled DSDT and searching for PNP0C09. You should get a result similar to this: Note: If your EC device happens to already be named EC in your DSDT, you do not need SSDT-EC at all and can move on. As you can see, PNP0C09 is found under the EC0 device and _SB.PC00.LPC0 scope. Looking at the SSDT though, this differs from the path _SB_.PCI0.LPCB seen within. This will need to be corrected in the SSDT to match what is found in the DSDT. Using the above image, you should get something similar to this: Scope (\\_SB.PC00.LPC0) Generally, PC00.LPC0 is most common on Intel HEDT while PCI0.SBRG is most common on AMD. Always verify your path and device. DO NOT ASSUME. If you are having issues finding the Scope, you can use the below Hardware IDs or Addresses: Finding the LowPinCount path: Intel: Search Name (_ADR, 0x001F0000) AMD: Search Name (_ADR, 0x00140003) Finding the PCI path: Intel: Search PNP0A08 (If multiple show up, use the first one) AMD: Assume PCI0(most AMD DSDTs don't declare the PCI path directly) Make sure that you do not rename Device (EC). This is what macOS Catalina looks for to boot! Desktop users, continue down below to disabling your actual EC Disabling real EC (Desktops only) For desktops, it's preferable to disable the actual Embedded Controller as it is not supported by macOS 100% and is known to sometimes cause panics. If we use the screenshot above, we'll see that the device name is EC0. Other common names for ECs are H_EC, ECDV, and EC0. You'll want to grab your SSDT again and uncomment the _STA method to disable it (remove the /* and */ around it): /* Like above, make sure the path is correct for the External and Scope field. What happens if device in the DSDT is already named EC For laptops, you don't need SSDT-EC at all. What happens if multiple PNP0C09 show up When this happens you need to figure out which is the main and which is not, it's fairly easy to figure out. Check each controller for the following properties: _HID (Hardware ID) _CRS (Current Resource Settings) _GPE (General Purpose Events) Note if you have an STA Method as well, see below: STA Edge Case What happens if no PNP0C09 show up This means you only need to fake an Embedded Controller rather so that AppleBusPowerController will load and handle USB power properly and continue booting. To make the actual SSDT, its almost plug and play as no uncommenting needed. The main thing that needs to be changed: LowPinCount path PCI path We want to make sure the SSDT hooks into our DSDT correctly so we need to make sure the ACPI path is correct: Finding the LowPinCount path: Intel: Search Name (_ADR, 0x001F0000) AMD: Search Name (_ADR, 0x00140003) Finding the PCI path: Intel: Search PNP0A08 (If multiple show up, use the first one) AMD: Assume PCI0(most AMD DSDTs don't declare the PCI path directly) Once you find out, change PCI0.LPCB to your correct path: Scope (\\_SB.PC00.LPC0) For those having issues, you can also check Device Manager -> CPU -> BIOS device Name. Windows will only report the main EC so will save you some headache on that STA Edge Case Do note that if your PNP0C09 device has a Method (_STA already you can skip down to \"What happens if no PNP0C09 show up?\". The reason for this is that the real EC is considered disabled already. Correcting USB Power Hey what about USBX? Do I need to do anything? USBX is universal across all systems, it just creates a USBX device that forces USB power properties. This is crucial for fixing Mics, DACs, Webcams, Bluetooth Dongles and other high power draw devices. This is not mandatory to boot but should be added in post-install if not before. Note that it requires the EC functioning correctly and that USBX is only used on skylake+ systems - those on Broadwell and older can ignore. Now you're ready to compile the SSDT! "},"Universal/plug.html":{"url":"Universal/plug.html","title":"Plugin type","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing Power Management CPU naming is fairly easy to figure out as well, open your decompiled DSDT and search for Processor. This should give you a result like this: As we can see, the first processor in our list is PR00. This is what we'll be applying the plugin-type=1 property too. Now grab SSDT-PLUG and replace the default CPU0 with our PR00. There's a couple things to note: There's 2 mentions of CPU0 to change The PR path may need to be changed, in our example we can see that our PR00 has SB in front. So in our final example, we'd have _SB_.PR00 and \\_SB.PR00 Note: If you're having issues, see the SSDT-PLUG provided by Acidanthera for example on what other ACPI paths may look like. There are also some edge cases with Processor, specifically on HEDT series like X79, X99 and X299. This edge case is that the ACPI path is much longer and not so obvious: If we then search for instances of CP00 we find that it's ACPI path is SB.SCK0.CP00: So for this X299 board, we'd change \\_PR.CPU0 with \\_SB.SCK0.CP00 and External (_PR_.CPU0, ProcessorObj) with External (_SB_.SCK0.CP00, ProcessorObj) External (_PR_.CPU0, ProcessorObj) For those having issues, you can also check Device Manager -> CPU -> BIOS device Name Note: X299 may report CP10 or higher for the CPU, when this happens use CP00 instead. This issue is due to weird numeration on Windows' side Now you're ready to compile the SSDT! "},"Universal/awac.html":{"url":"Universal/awac.html","title":"AWAC vs RTC","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing System Clocks For Intel 300 series chipsets and newer, this also includes X299 refreshes and Icelake laptops. Common machines: X299X (10th Gen refresh) B360 B365 H310 H370 Z370 (Gigabyte and AsRock boards with newer BIOS versions) Z390 400 series (Cometlake) 495 series (Icelake) So on newer Intel 300 series motherboards, manufactures started pushing for a new type of system clock: AWAC( A Weird Ass Clock). One small problem, macOS doesn't know what the hell an AWAC clock is instead only familiar with the legacy RTC(Real Time Clock). So we need to figure out how to bring back the old clock, thats where SSDT-AWAC and SSDT-RTC0 come in: SSDT-AWAC Disables AWAC and enables RTC In your DSDT, there's a variable called STAS used for holding either a One or Zero to determine which clock to use(One for RTC and Zero for AWAC) SSDT-RTC0 Used for creating a fake RTC device for macOS to play with In very rare circumstances, some DSDTs may not have a legacy RTC to fall back on. When this happens, we'll want to create a fake device to make macOS happy Note: AWAC actually stands for ACPI Wake Alarm Counter/Clock for those curious, though I'll forever know it as A Weird Ass Clock ;p Determining which SSDT you need To determine whether you need SSDT-AWAC or SSDT-RTC0: open your decompiled DSDT and search for Device (AWAC) If nothing shows up then no need to continue and no need for this SSDT as you have no AWAC. Otherwise, continue on! If you get a result then you have an AWAC system clock present, then continue with the next search for STAS: As you can see we found the STAS in our DSDT, this means we're able to force enable our Legacy RTC. In this case, SSDT-AWAC will be used As-Is with no modifications required. Just need to compile. Note that STAS may be found in AWAC first instead of RTC like in our example, this is normal. For systems where no STAS shows up but you do have AWAC, you can use SSDT-RTC0 though you will need to check the naming of LPC in your DSDT By default the SSDT uses LPCB, you can check what your system uses by just searching for Name (_ADR, 0x001F0000). This address is used for Low Pin Count devices(LPC) but the device name can vary between LPCB, LBC or LBC0: Now you're ready to compile the SSDT! "},"Universal/nvram.html":{"url":"Universal/nvram.html","title":"NVRAM PMC","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing NVRAM This SSDT is required for all \"true\" 300 series motherboards and newer(Z370 is excluded), it specifically brings back NVRAM support and requires very little configuration for the end user. B360 B365 H310 H370 Z390 400 series (Cometlake) 495 series (Icelake) By default it uses PCI0.LPCB for the PCI and LowPinCount path. The device names can vary between PC00 and PCI0 for PCI path and LPCB, LBC and LBC0 for LowPinCount path. To see what you have: Finding the LowPinCount path: Intel: Search Name (_ADR, 0x001F0000) Finding the PCI path: Intel: Search PNP0A08 (If multiple show up, use the first one) Now you're ready to compile the SSDT! "},"Universal/irq.html":{"url":"Universal/irq.html","title":"IRQ Fix","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing IRQ Conflicts So you miss having those fancy hot-patches from Clover like FixIPIC, FixTMR, FixRTC, FixHPET, etc Well 1 very small problem, figuring out IRQ patching is a massive headache. I highly recommend you use SSDTTime. So head over to SSDT: Easy Way on how to make it.(use option C to omit conflicting legacy IRQs) "},"Universal/spoof.html":{"url":"Universal/spoof.html","title":"GPU Spoof","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Renaming GPUs So this is mainly needed for GPUs that are not natively supported out of the box due to their names, most commonly: R9 290/390 R9 280/380 R7 270/370 R9 260/360 R7 250 R7 240 Instead, these GPUs need to be \"spoofed\" or faked into a model that closely matches theirs, generally this will be the \"X\" variant of the card. For some reason Apple never bothered adding the PCI IDs for these other cards even though their GPU cores are supported by the driver. So to spoof the GPU, we need to find a couple things: Suitable PCI ID for the GPU ACPI Path of the GPU SSDT-GPU-SPOOF Finding a suitable PCI ID To find a suitable PCI ID, we'll be using PCI ID Repository which has a full database of all AMD GPUs. For this example, we'll be creating a Spoof SSDT for the R9 390. For a full list of supported GPUs, please see the GPU Buyers Guide. The closest match to this GPU would be the 390X, and looking on that site near the top gives us this: Vendor 1002 -> Device 1002:67b0 Now lets break this down into a device ID we can use: 1002: The vendor ID, all AMD devices have this ID 67B0: The device ID, this is what we care about So how do we convert this to a fake ID? Well the format of a fake ID: \"device-id\", Buffer (0x04) { 0xB0, 0x67, 0x00, 0x00 }, As you can see, the bytes are swapped in pairs. Keep this in mind when we make our SSDT The specifics are due to Endianness for those who are curious Finding the ACPI Path of the GPU To find the PCI path of a GPU is fairly simple, best way to find it is running Windows: Open Device Manager Select Display Adapters, then right click your GPU and select Properties Under the Details Tab, search for \"Location Paths\" Note some GPUs may be hiding under \"BIOS device name\" The second \"ACPI\" is what we care about: ACPI(_SB_)#ACPI(PC02)#ACPI(BR2A)#ACPI(PEGP)#PCI(0000)#PCI(0000) Now converting this to an ACPI path is quite simple, remove the #ACPI and #PCI(0000): `_SB_.PC02.BR2A.PEGP And voila! We've found our ACPI path, now that we have everything we're ready to get cooking Making the SSDT To start grab our SSDT-GPU-SPOOF and open it up. Here there's a couple things to change: External (_SB_.PCI0, DeviceObj) External (_SB_.PCI0.PEG0.PEGP, DeviceObj) For our example, we'll change all mentions of : PCI0 with PC02 PEG0 with BR2A Hint: If your ACPI path is a bit shorter than the example, this is fine. Just make sure the ACPI paths are correct to your device. Now that the ACPI pathing is correct, we can finally apply our fake ID!!! So the 2 parts we want to change: device ID: \"device-id\", Buffer (0x04) { 0xB0, 0x67, 0x00, 0x00 }, Model: \"model\", Buffer () { \"AMD Radeon R9 390\" } \"device-id\" will be set to our PCI ID that we found in \"Finding a suitable PCI ID\" and \"model\" is mainly cosmetic Now you're ready to compile the SSDT! "},"Universal/smbus.html":{"url":"Universal/smbus.html","title":"Fixing SMBus Support","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Fixing SMBus support This section of the guide refers to fixing AppleSMBus support in macOS, what is AppleSMBus? Well this mainly handles the System Management Bus, which has many functions like: AppleSMBusController Aids with correct temperature, fan, voltage, ICH, etc readings AppleSMBusPCI Same idea as AppleSMBusController except for low bandwidth PCI devices Memory Reporting Aids in proper memory reporting and can aid in getting better kernel panic details if memory related Other things SMBus does: SMBus wiki For install purposes, this SSDT isn't needed but for post-install it's recommended to put the final touches on your hack. So to get started, we'll want to grab our SMBus SSDT: SSDT-SBUS-MCHC.dsl So the important parts we care about are: External (_SB_.PCI0, DeviceObj) To find the correct pathing for your devices, grab Hackintool (Github link) and head to the PCI tab: Look for the SMBus device under Subclass, then look beside and you'll see the ACPI path(under IOReg Name). To convert , omit @... /PC00@0/SMBS@1F,4 -> PC00.SMBS Once finished, it'll look something like this: External (_SB_.PC00, DeviceObj) For those having issues, you can also check Device Manager -> CPU -> BIOS device Name Note: The MCHC is actually the DRAM controller, similar idea to SMBus for fixing memory reporting Now you're ready to compile the SSDT! "},"cleanup.html":{"url":"cleanup.html","title":"Cleanup","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Cleanup So you've made all your SSDTs but now there's one thing left: Adding them to Opencore The 2 main locations: EFI/OC/ACPI (Only .aml files, reminder to compile your SSDTs) config.plist -> ACPI -> Add You can save yourself some work with the config.plist by running Cmd/Ctrl+R in ProperTree. Reminder do not add your DSDT.aml to your EFI Users of FixHPET will also need to merge oc_patches.plist into their config.plist Steps to do this: Open both files, Delete the ACPI -> Patch section from config.plist Copy the ACPI -> Patch section from patches.plist Paste into where old patches were in config.plist "},"troubleshooting.html":{"url":"troubleshooting.html","title":"Troubleshooting","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:15 GMT+0000 (Coordinated Universal Time) Troubleshooting Fixing SSDTTime: Could not locate or download iasl! Can't run acpidump.efi iASL warning, # unresolved Decompiling Error Invalid character (0x3D), expecting ASL keyword or name Syntax error, unexpected PARSEOP_ONE, expecting '(' Fixing SSDTTime: Could not locate or download iasl! This is usually due to an outdated version of Python, try either updating Python or add iasl to the scripts folder for SSDTTime: iasl macOS version iasl Windows version iasl Linux version Can't run acpidump.efi from OpenCore Grab OpenShell and add it to EFI/OC/Tools and config.plist -> Misc -> Tools. Next, call upon OpenCore shell and enter the following: shell> fs0: //replace with proper drive fs0:\\> dir //to verify this is the right directory Directory of fs0:\\ 01/01/01 3:30p EFI fs0:\\> cd EFI\\OC\\Tools //note that its with forward slashes fs0:\\EFI\\OC\\Tools> acpidump.efi -b -n DSDT -z iASL warning, # unresolved If you try to decompile your DSDT and get an error similar to this: iASL Warning: There were 19 external control methods found during disassembly, but only 0 were resolved (19 unresolved) This happens when one ACPI table requires the rest for proper referencing, it does not accept the creation of DSDTs as we're only using it for creating a select few SSDTs. For those who are worried, you can run the following: iasl * [insert all ACPI files here] Decompiling Error Loading Acpi table from file iASLAwjHrs.aml Acpi table [DSDT] successfully installed and loaded Pass 1 parse of [DSDT] This is a common error on DSDTs that have methods that aren't supported by maciASL, the easiest way is to delete maciASL and make sure you grab it from Acidanthera's repo: maciASL Invalid character (0x3D), expecting ASL keyword or name Similar to the above error, you're running an outdated copy of maciASL. Make sure you're using the latest from Acidanthera's repo: maciASL Syntax error, unexpected PARSEOP_ONE, expecting '(' Similar to the above 2 errors, you're running an outdated copy of maciASL. Make sure you're using the latest from Acidanthera's repo: maciASL "},"CONTRIBUTING.html":{"url":"CONTRIBUTING.html","title":"Contributing","keywords":"","body":" Last modified: Thu Apr 30 2020 15:41:14 GMT+0000 (Coordinated Universal Time) Supporting the guides Note: This is a community run guide which is not officially endorsed by Acidanthera. Please do not bug Acidanthera with issues about this guide. Want to help support the guide? Well there's some ways you can help! Contributing via Issues Contributing via PRs Note: For those wanting to contribute financially, we seriously appreciate it but we're a non-profit organization. We do this to teach, not to make money. If you have some money left over we highly recommend donating it to a charity. Crohn's and Colitis Canada is one we recommend if you have none on mind. Contributing via Issues Contributing via Issues is pretty simple but there are some rules: Keep issues tab dedicated to guides issues only, no personal hackintosh issues. It is not a place to discuss installation issues. If for a typo or better clarification, please indicate what page it was on. Would appreciate not going for a scavenger hunt on where these issues are. You can find the issues tab here: Getting Started With ACPI Issues Contributing via PRs Some guidelines when contributing via PRs: Use your brain (please). Proofread your submissions. Pull Requests can be denied if we feel it does not fit or has inaccurate information. We will generally tell you why it is rejected though or ask for revisions. We would also appreciate sources for any bigger commits to make it easier on us to verify the info your provide is valid Images must be hosted locally in the repo under the /images/ folder Your PR must be run through a markdown lint and have all issues fixed. In general, try to avoid using \"non-Acidanthera\" tools when possible. Generally we want to avoid use of third-party tools - though if it's impossible otherwise, then you can link it. Tools explicitly banned: UniBeast, MultiBeast and KextBeast More info can be found here: Tonymacx86-stance Transmac Know for creating borked USB drives Niresh Installers We'd like to avoid piracy with the guides How to Contribute Best way to test your commits and make sure they are formatted correctly is downloading nodejs and getting the gitbook-cli and markdownlint-cli tools. When you run gitbook serve, it will set up a local webserver which you can connect to view the changes you made. markdownlint * will throw any errors at you about formatting as well, and markdownlint -f * will attempt to fix these. Fork this repo Install the required tools: npm install -g markdownlint-cli npm install -g gitbook-cli Make your changes. Build the site: gitbook install (To install all the required gitbook plugins) gitbook serve (Preview the site) Can be found at http://localhost:4000 Check markdown format: markdownlint -f * (To fix any potential issues) Tips Some tools that make contributing a bit easier: Typora for real time markdown rendering. TextMate for easy and powerful mass find/replace. Github Desktop for more user friendly GUI. "}} \ No newline at end of file diff --git a/ssdt-easy.html b/ssdt-easy.html index 6e878cd..3ee4ffa 100644 --- a/ssdt-easy.html +++ b/ssdt-easy.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
            -

            Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

            +

            Last modified: Thu Apr 30 2020 15:41:15 GMT+0000 (Coordinated Universal Time)

            SSDTs: The easy way

            So here we'll be using a super simple tool made by CorpNewt: SSDTTime

            @@ -573,7 +573,7 @@ diff --git a/ssdt-long.html b/ssdt-long.html index 5594375..cfad1ca 100644 --- a/ssdt-long.html +++ b/ssdt-long.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
            -

            Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

            +

            Last modified: Thu Apr 30 2020 15:41:15 GMT+0000 (Coordinated Universal Time)

            SSDTs: The long way

            Well sadly some things are not handled by SSDTTime, well have no fear as making SSDTs is super easy. The basic process:

            @@ -503,7 +503,7 @@ diff --git a/troubleshooting.html b/troubleshooting.html index 12870af..d082871 100644 --- a/troubleshooting.html +++ b/troubleshooting.html @@ -264,7 +264,7 @@ - Embedded Controller + Embedded Controller @@ -449,7 +449,7 @@
            -

            Last modified: Mon Apr 27 2020 19:57:31 GMT+0000 (Coordinated Universal Time)

            +

            Last modified: Thu Apr 30 2020 15:41:15 GMT+0000 (Coordinated Universal Time)

            Troubleshooting

              @@ -545,7 +545,7 @@ Pass 1 parse of [DSDT]