Fixing System Clocks
-For Intel 300 series chipsets only
+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 (Gigabtye and AsRock boards with newer BIOS versions) +
- Z390 +
- 400 series (Cometlake) +
- 495 series (Icelake) +
So on newer Intel 300 series motherboards, manufactueres 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:
-
@@ -391,12 +402,12 @@
To determine whether you need SSDT-AWAC or SSDT-RTC0:
- open your decompiled DSDT and search for
Device (AWAC)
- - If nothing shows 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
AWACsystem clock present, then continue with the next search forSTAS ==:
+ - 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
AWACsystem clock present, then continue with the next search forSTAS ==:
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 thatSTASmay be found in AWAC first instead of RTC like in our example, this is normal.For systems where no
+STASshows up but you do haveAWAC, you can use SSDT-RTC0 though you will need to check the naming of LPC in your DSDTFor systems where no
STASshows up but you do haveAWAC, you can use SSDT-RTC0 though you will need to check the naming of LPC in your DSDTBy default the SSDT uses
LPCB, you can check what your system uses by just searching forName (_ADR, 0x001F0000). This address is used for Low Pin Count devices(LPC) but the device name can vary betweenLPCB,LBCorLBC0:
Now you're ready to compile the SSDT!
@@ -443,7 +454,7 @@ diff --git a/Universal/irq.html b/Universal/irq.html index da8808a..dd8c121 100644 --- a/Universal/irq.html +++ b/Universal/irq.html @@ -415,7 +415,7 @@ diff --git a/Universal/nvram.html b/Universal/nvram.html index dbfb156..bc8692f 100644 --- a/Universal/nvram.html +++ b/Universal/nvram.html @@ -370,7 +370,16 @@Fixing NVRAM
-This SSDT is required for all B360, B365, H310, H370, Z390 motherboards, it specifically brings back NVRAM support and requires very little configuration for the end user.
+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.LPCBfor the PCI and LowPinCount path. The device names can vary betweenPC00andPCI0for PCI path andLPCB,LBCandLBC0for LowPinCount path. To see what you have:- Finding the LowPinCount path:
-
@@ -427,7 +436,7 @@
diff --git a/Universal/plug.html b/Universal/plug.html
index b3bccee..c7afc25 100644
--- a/Universal/plug.html
+++ b/Universal/plug.html
@@ -437,7 +437,7 @@ Scope (\_PR.CPU0) <- Rename this
diff --git a/Universal/spoof.html b/Universal/spoof.html
index bb6657d..6fade38 100644
--- a/Universal/spoof.html
+++ b/Universal/spoof.html
@@ -484,7 +484,7 @@ Buffer ()
diff --git a/cleanup.html b/cleanup.html
index cf804c6..38b1bc1 100644
--- a/cleanup.html
+++ b/cleanup.html
@@ -422,7 +422,7 @@
diff --git a/index.html b/index.html
index 9b86b6a..7d5567e 100644
--- a/index.html
+++ b/index.html
@@ -556,7 +556,7 @@
diff --git a/search_plus_index.json b/search_plus_index.json
index a955f59..ae68c5c 100644
--- a/search_plus_index.json
+++ b/search_plus_index.json
@@ -1 +1 @@
-{"./":{"url":"./","title":"Getting Started With ACPI","keywords":"","body":"Getting started with ACPI A quick explainer on ACPI and how to make SSDTs 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) 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 exposed in their DSDT, with many AMD systems also having it exposed. These controllers are not compatible with macOS so then need to be hidden from macOS and replaced with a dummy EC when running macOS Catalina. With laptops, we still need these ECs so we rename them into what macOS would expect ECs to look like Plugin type This is used to enable 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 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 XNU ignores the MMIO region declared by the UEFI memory map. This SSDT brings back NVRAM support Backlight SSDT Used for fixing backlight 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. For laptops only IRQ SSDT and ACPI patch 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 Ivy Bridge: CPU-PM(Run in Post-Install) SSDT-EC Haswell: SSDT-PLUG SSDT-EC Skylake: SSDT-PLUG SSDT-EC-USBX Kabylake: SSDT-PLUG SSDT-EC-USBX Coffeelake: SSDT-PLUG SSDT-EC-USBX SSDT AWAC SSDT-PMC AMD: SSDT-EC-USBX High End Desktop Haswell-E: SSDT-PLUG SSDT-EC Broadwell-E: SSDT-PLUG SSDT-EC Skylake-X: SSDT-PLUG SSDT-EC-USBX Laptop Ivy Bridge: EC ACPI Patch CPU-PM SSDT-PNLF SSDT-GPI0 IRQ SSDT Haswell: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Broadwell: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Skylake: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Kabylake: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Coffeelake(8th Gen): EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Coffeelake(9th Gen): EC ACPI Patch SSDT-PLUG SSDT AWAC SSDT-PMC SSDT-PNLF SSDT-GPI0 IRQ SSDT "},"ssdt-easy.html":{"url":"ssdt-easy.html","title":"SSDTs: Easy Way","keywords":"","body":"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 Laptop EC fix: This is because you need to use an ACPI rename over an SSDT on laptops SSDT-PNLF: No need to configuration required for most, use prebuilt file here SSDT-GPI0: Need to be configured to your system: SSDT-GPI0.dsl 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 prebuilt 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 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 AMD, you can grab a prebuilt 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, eminder 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 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":"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":"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 OpenCoreShell(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 // note that it's with forward slashes fs0:\\EFI\\OC\\Tools> acpidump.efi -b -n DSDT -z "},"Manual/compile.html":{"url":"Manual/compile.html","title":"Decompiling and Compiling","keywords":"","body":"Compiling and decompiling ACPI Tables 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. 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 special copy of iasl and terminal: 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-ec.html":{"url":"Desktops/desktop-ec.html","title":"Embedded Controllers","keywords":"","body":"Fixing Embedded Controller (Desktop) What we'll be doing is hiding our actual EC and creating a fake Embedded Comtroller for macOS to play with. To find out what EC you have, open your decompiled DSDT and search for PNP0C09. This should give you a result like this: As you can see our PNP0C09 is found within the Device (EC0) meaning this is the device we want to hide from macOS(others may find H_EC, ECDV, etc, everyone's systems will be different). Now grab our SSDT-EC and uncomment the EC0 function(remove the /* and */ around it): SSDT-EC-USBX For Skylake and newer and all AMD systems SSDT-EC For Broadwell and older /* But looking back at the screenshot above we notice something, our ACPI path is different: PC00.LPC0 vs PCI0.LPCB. This is very important especially when you're dealing with Intel consumer vs Intel HEDT vs AMD, PC00.LPC0 is common on Intel HEDT while PCI0.SBRG is common on AMD. And they even come with name variation such as EC0, H_EC, PGEC and ECDV, so there can't be a one size fits all SSDT, always verify your path and device. DO NOT ASSUME. 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) And make sure to scroll to the bottom as the new Fake EC function also need the correct path to replace the old EC. Do not rename Device (EC), this is our fake EC we're using for macOS to play with so leave Device (EC) alone. Just change the path! 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) What happens if no PNP0C09 show up? So what this means: EC faking is not mandatory for booting, instead only recommended for proper USB power. So how do I make an SSDT without an EC? Well we'll only create a Fake EC for macOS to play with, this allows for AppleBusPowerController to load and handle our USB properly. 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) 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 USBX is only used on skylake+ systems, Broadwell and older can ignore and that USBX requires a patched EC to function correctly Now you're ready to compile the SSDT! "},"Laptops/laptop-ec.html":{"url":"Laptops/laptop-ec.html","title":"Embedded Controllers","keywords":"","body":"Fixing Embedded Controller (Laptop) 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. To find out what EC you have, open your decompiled DSDT and search for PNP0C09. This should give you a result like this: As you can see our PNP0C09 is found within the Device (EC0) meaning this is the device we want to rename. 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 that only the main EC needs renaming, if you only have one PNP0C09 then it is automatically your main regardless of properties. What if my main PNP0C09 device is already called Device (EC)? Mainly relevant for Lenovo and a few other OEMs, when this happens that means that your Embedded Controller is ready to use in macOS! Do make sure that this Device (EC) is actually your main EC and not a secondary one. And please verify that the DSDT hasn't already been patched by Clover or OpenCore, please dump it without booting either of them to be sure or triple check that there aren't any EC renames in your config already Applying your EC patch As you can see from the table below, we'll be renaming our EC listed in the DSDT. Do note you cannot just throw random renames without checking which is the main EC first, as this can cause actual damage to your laptop. Comment Find*[HEX] Replace[HEX] change EC0 to EC 4543305f 45435f5f change H_EC to EC 485f4543 45435f5f change ECDV to EC 45434456 45435f5f change PGEC to EC 50474543 45435f5f Inside your config: Comment String Change XXXX to EC Enabled String YES Count Number 0 Limit Number 0 Find Data xxxxxxxx Replace Data xxxxxxxx "},"Laptops/backlight.html":{"url":"Laptops/backlight.html","title":"Backlight PNLF","keywords":"","body":"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 prebuilt file into your EFI: SSDT-PNLF 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 "},"Laptops/trackpad.html":{"url":"Laptops/trackpad.html","title":"Trackpad GPI0","keywords":"","body":"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 } } } "},"Universal/plug.html":{"url":"Universal/plug.html","title":"Plugin type","keywords":"","body":"Fixing Power Management Intel CPUs only 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) Now you're ready to compile the SSDT! "},"Universal/awac.html":{"url":"Universal/awac.html","title":"AWAC vs RTC","keywords":"","body":"Fixing System Clocks For Intel 300 series chipsets only So on newer Intel 300 series motherboards, manufactueres 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 varaible 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 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":"Fixing NVRAM This SSDT is required for all B360, B365, H310, H370, Z390 motherboards, it specifically brings back NVRAM support and requires very little configuration for the end user. 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":"Fixing IRQ Conflicts So you miss having those fancy hotpatches from Clover like FixIPIC, FixTMR, FixRTC, FixHPET, etc Well 1 very small problem, figruing 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 "},"Universal/spoof.html":{"url":"Universal/spoof.html","title":"GPU Spoof","keywords":"","body":"Renaming GPUs So this is mainly needed for GPUs that are not natively supported OOB 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\" 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! "},"cleanup.html":{"url":"cleanup.html","title":"Cleanup","keywords":"","body":"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 "}}
\ No newline at end of file
+{"./":{"url":"./","title":"Getting Started With ACPI","keywords":"","body":"Getting started with ACPI A quick explainer on ACPI and how to make SSDTs 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) 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 exposed in their DSDT, with many AMD systems also having it exposed. These controllers are not compatible with macOS so then need to be hidden from macOS and replaced with a dummy EC when running macOS Catalina. With laptops, we still need these ECs so we rename them into what macOS would expect ECs to look like Plugin type This is used to enable 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 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 XNU ignores the MMIO region declared by the UEFI memory map. This SSDT brings back NVRAM support Backlight SSDT Used for fixing backlight 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. For laptops only IRQ SSDT and ACPI patch 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 Ivy Bridge: CPU-PM(Run in Post-Install) SSDT-EC Haswell: SSDT-PLUG SSDT-EC Skylake: SSDT-PLUG SSDT-EC-USBX Kabylake: SSDT-PLUG SSDT-EC-USBX Coffeelake: SSDT-PLUG SSDT-EC-USBX SSDT AWAC SSDT-PMC AMD: SSDT-EC-USBX High End Desktop Haswell-E: SSDT-PLUG SSDT-EC Broadwell-E: SSDT-PLUG SSDT-EC Skylake-X: SSDT-PLUG SSDT-EC-USBX Laptop Ivy Bridge: EC ACPI Patch CPU-PM SSDT-PNLF SSDT-GPI0 IRQ SSDT Haswell: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Broadwell: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Skylake: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Kabylake: EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Coffeelake(8th Gen): EC ACPI Patch SSDT-PLUG SSDT-PNLF SSDT-GPI0 IRQ SSDT Coffeelake(9th Gen): EC ACPI Patch SSDT-PLUG SSDT AWAC SSDT-PMC SSDT-PNLF SSDT-GPI0 IRQ SSDT "},"ssdt-easy.html":{"url":"ssdt-easy.html","title":"SSDTs: Easy Way","keywords":"","body":"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 Laptop EC fix: This is because you need to use an ACPI rename over an SSDT on laptops SSDT-PNLF: No need to configuration required for most, use prebuilt file here SSDT-GPI0: Need to be configured to your system: SSDT-GPI0.dsl 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 prebuilt 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 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 AMD, you can grab a prebuilt 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, eminder 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 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":"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":"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 OpenCoreShell(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 // note that it's with forward slashes fs0:\\EFI\\OC\\Tools> acpidump.efi -b -n DSDT -z "},"Manual/compile.html":{"url":"Manual/compile.html","title":"Decompiling and Compiling","keywords":"","body":"Compiling and decompiling ACPI Tables 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. 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 special copy of iasl and terminal: 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-ec.html":{"url":"Desktops/desktop-ec.html","title":"Embedded Controllers","keywords":"","body":"Fixing Embedded Controller (Desktop) What we'll be doing is hiding our actual EC and creating a fake Embedded Comtroller for macOS to play with. To find out what EC you have, open your decompiled DSDT and search for PNP0C09. This should give you a result like this: As you can see our PNP0C09 is found within the Device (EC0) meaning this is the device we want to hide from macOS(others may find H_EC, ECDV, etc, everyone's systems will be different). Now grab our SSDT-EC and uncomment the EC0 function(remove the /* and */ around it): SSDT-EC-USBX For Skylake and newer and all AMD systems SSDT-EC For Broadwell and older /* But looking back at the screenshot above we notice something, our ACPI path is different: PC00.LPC0 vs PCI0.LPCB. This is very important especially when you're dealing with Intel consumer vs Intel HEDT vs AMD, PC00.LPC0 is common on Intel HEDT while PCI0.SBRG is common on AMD. And they even come with name variation such as EC0, H_EC, PGEC and ECDV, so there can't be a one size fits all SSDT, always verify your path and device. DO NOT ASSUME. 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) And make sure to scroll to the bottom as the new Fake EC function also need the correct path to replace the old EC. Do not rename Device (EC), this is our fake EC we're using for macOS to play with so leave Device (EC) alone. Just change the path! 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) What happens if no PNP0C09 show up? So what this means: EC faking is not mandatory for booting, instead only recommended for proper USB power. So how do I make an SSDT without an EC? Well we'll only create a Fake EC for macOS to play with, this allows for AppleBusPowerController to load and handle our USB properly. 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) 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 USBX is only used on skylake+ systems, Broadwell and older can ignore and that USBX requires a patched EC to function correctly Now you're ready to compile the SSDT! "},"Laptops/laptop-ec.html":{"url":"Laptops/laptop-ec.html","title":"Embedded Controllers","keywords":"","body":"Fixing Embedded Controller (Laptop) 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. To find out what EC you have, open your decompiled DSDT and search for PNP0C09. This should give you a result like this: As you can see our PNP0C09 is found within the Device (EC0) meaning this is the device we want to rename. 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 that only the main EC needs renaming, if you only have one PNP0C09 then it is automatically your main regardless of properties. What if my main PNP0C09 device is already called Device (EC)? Mainly relevant for Lenovo and a few other OEMs, when this happens that means that your Embedded Controller is ready to use in macOS! Do make sure that this Device (EC) is actually your main EC and not a secondary one. And please verify that the DSDT hasn't already been patched by Clover or OpenCore, please dump it without booting either of them to be sure or triple check that there aren't any EC renames in your config already Applying your EC patch As you can see from the table below, we'll be renaming our EC listed in the DSDT. Do note you cannot just throw random renames without checking which is the main EC first, as this can cause actual damage to your laptop. Comment Find*[HEX] Replace[HEX] change EC0 to EC 4543305f 45435f5f change H_EC to EC 485f4543 45435f5f change ECDV to EC 45434456 45435f5f change PGEC to EC 50474543 45435f5f Inside your config: Comment String Change XXXX to EC Enabled String YES Count Number 0 Limit Number 0 Find Data xxxxxxxx Replace Data xxxxxxxx "},"Laptops/backlight.html":{"url":"Laptops/backlight.html","title":"Backlight PNLF","keywords":"","body":"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 prebuilt file into your EFI: SSDT-PNLF For most users SSDT-PNLF-CFL For Coffeelake users if the regular SSDT doesn't work, try SSDT-PNLF first and do not mix together 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 "},"Laptops/trackpad.html":{"url":"Laptops/trackpad.html","title":"Trackpad GPI0","keywords":"","body":"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 } } } "},"Universal/plug.html":{"url":"Universal/plug.html","title":"Plugin type","keywords":"","body":"Fixing Power Management Intel CPUs only 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) Now you're ready to compile the SSDT! "},"Universal/awac.html":{"url":"Universal/awac.html","title":"AWAC vs RTC","keywords":"","body":"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 (Gigabtye and AsRock boards with newer BIOS versions) Z390 400 series (Cometlake) 495 series (Icelake) So on newer Intel 300 series motherboards, manufactueres 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 varaible 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":"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":"Fixing IRQ Conflicts So you miss having those fancy hotpatches from Clover like FixIPIC, FixTMR, FixRTC, FixHPET, etc Well 1 very small problem, figruing 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 "},"Universal/spoof.html":{"url":"Universal/spoof.html","title":"GPU Spoof","keywords":"","body":"Renaming GPUs So this is mainly needed for GPUs that are not natively supported OOB 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\" 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! "},"cleanup.html":{"url":"cleanup.html","title":"Cleanup","keywords":"","body":"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 "}}
\ No newline at end of file
diff --git a/ssdt-easy.html b/ssdt-easy.html
index ba34d01..22b60d1 100644
--- a/ssdt-easy.html
+++ b/ssdt-easy.html
@@ -490,7 +490,7 @@
diff --git a/ssdt-long.html b/ssdt-long.html
index f37a523..5e803cb 100644
--- a/ssdt-long.html
+++ b/ssdt-long.html
@@ -421,7 +421,7 @@
- open your decompiled DSDT and search for