Skip to content

Latest commit

 

History

History
137 lines (109 loc) · 9.25 KB

README.md

File metadata and controls

137 lines (109 loc) · 9.25 KB
Raw

Dropping ACPI Tables

TABLE of CONTENTS

About

Sometimes ACPI Tables provided with your Firmware/BIOS might hinder some features or devices to work properly in macOS. Boot managers like Clover and OpenCore provide means to block certain tables from loading or to replace them. In order to do so, you need to know the Tables Signature, OEM Table ID and/or Table Length. Therefore, you need to extract ("dump") the ACPI tables from your BIOS/Firmware to analyze them.

Preparations: Dumping the ACPI Tables

There are various ways of dumping ACPI Tables from your Firmware/BIOS. The most common way is to use either Clover or OpenCore:

  • Using Clover (the easiest method): Hit F4 in the Boot Menu. You don't even need a working configuration to do this. Just download the latest Release as a .zip file, extract it, put it on a FAT32 formatted USB flash drive and boot from it. The dumped ACPI Tables will be located in: EFI/CLOVER/ACPI/origin

  • Using OpenCore (req. the Debug version of OC): enable Misc/Debug/SysReport Quirk. The ACPI Tables will be dumped during next boot.

Method 1: Dropping Tables based on OEM Tabled ID

This method is used to drop tables such as SSDTs and others which have a distinct OEM Table ID in the header to describe them. In this example we drop CpuPm.

  • Open the Table you want to drop in maciASL and find its Table Signature and OEM Table ID:
    Header
  • Open your config.plist and a new rule under "ACPI" > "Delete"
  • Add the discovered TableSignature (here "53534454" = "SSDT" in HEX) and OEMTableID (here "437075506D000000" = "CpuPm" in HEX) into the corresponding fields in HEX format. In OCAT, you can use the ASCII to HEX converter at the bottom of the app to do this:
    DropCpuPM
  • Enable the rule and save your config.plist.
  • Reboot.

Verifying that the table has been dropped

  • Open maciASL
  • Select "File" > "New from ACPI"
  • If you dropped the table successfully, "SSDT (CpuPm)" shouldn't be listed, unless you replaced it with a new table with the same OEM Table ID. If you created your own SSDT-PM.aml which is injected by OpenCore, this would be present, since it has the same OEM Table ID.

Note: Dropping "internal" tables that load other tables

Some SSDTs are "internal" tables that will only provide data to the primary or parent table that references them. If you drop the primary table, then the referenced secondary table(s) will not be loaded.

💡 Therefore, you don't need to create additional drop rules to drop these tables. If you still try to drop these "internal" tables which are not visible to the system – since they are not referenced in either the Root (RSTD) or Extended System Description Table (XSTD) – you will receive an error message from OpenCore:

OC: Failed to drop ACPI … – Not Found

Example:

Sometimes, you can already guess by the name of the tables alone which ones are subsequent tables to others. Look at this screenshot:

SubTables

SSTD-4-CpuPM is followed by SSDT-x4_0…, SSDT-x4_1… and SSDT-x4_2… which indicates some type of hierarchy in regards to SSDT-4….

And if we have a look inside SSTD-4-CpuPM, you find the references:

Scope (\)
    {
        Name (SSDT, Package (0x0C)
        {
            "CPU0IST ",
            0xD3322018, 
            0x00000C31, 
            "APIST   ", // Reference to SSDT-x4_0-ApIst
            0xDAE3DA98, 
            0x00000303, 
            "CPU0CST ", // Reference to SSDT-x4_1-Cpu0Cst
            0xDAE3C018, 
            0x00000A01, 
            "APCST   ", // Reference to SSDT-x4_2-ApCst
            0xDAE3BD98, 
            0x00000119
        })

Find out more about "internal" tables here

Method 2: Dropping Tables based on Table Signature

For tables other than SSDTs, OEM Table ID isn't a reliable source to detect and drop a table by because (based on vendor) the OEM Table IDs may only contain some letters followed by a lot of blanks or underscores, for example AMI____. In this case, we use the Table Signature and Table Length instead to clearly identify the table.

Example 1: dropping the DMAR Table

On some Z490/Z590 boards (e.g. Gigabyte), the presence of Reserved Memory Regions in the DMA Remapping Table (DMAR) in combination with disabled VT-d and/or DisableIOMapper Kernel Quirk render the dreaded on-board Intel(r) I225-V Ethernet Controller and PCIe Ethernet cards useless in macOS Monterey and newer. In this case, DMAR has to be modified, VT-d enabled in BIOS and DisableIOMapper disabled.

Therefore, you might consider dropping the DMAR table completely and/or replace it with a modified version. Here's how you do it:

  • Open maciASL
  • Select "File" > "New from ACPI"
  • Pick DMAR
  • Open the DMAR Table in maciASL and scroll to the end
  • Copy the table length (in this case, 168):
    Tlength
  • Open your config and add a new rule under ACPI/Delete.
  • Enter 444D4152 (HEX for "DMAR") in TableSignature. If you use OCAT, you can use the ASCII to HEX converter at the bottom of the app:
    Drop
  • In TableLength, enter the Length listed in the DMAR Table. In this case 168.
  • Save the Config.
  • Reboot.

Verifying that the table has been dropped/deleted

After rebooting, do the following:

  • Open maciASL
  • Select "File" > "New from ACPI"
  • If you dropped the table successfully, it shouldn't be listed. As you can see, it's not present:
    nodmar
  • The DMAR table has been dropped successfully. If it's table is still present, you either did something wrong or a table of the same name is present in OpenCore's ACPI folder and is injected by OpenCore.

Example 2: replacing the DMAR table by a modified one

  • Dump the ACPI Tables as explained at the beginning
  • Drop the OEM DMAR table as explained in Example 1
  • Modify the OEM DMAR Table:
    • Open it in maciASL
    • In this case we delete the Reserved Memory Regions:
      Delmem
  • Save the file as DMAR.aml. It should have a new table length now (104).
  • Put it in the EFI/OC/ACPI and add it to your config.plist.
  • Save and reboot.

This will disable the OEM DMAR table and inject the modified one instead but we need to check if it worked. If you are scared editing the DMAR table yourself, you can also use SSDTTime for this now, too.

Important

I've noticed that macOS 14.2 crashes on my Z490 system if a Reserved Memory Region for the XHCI Controller is present in the OEM DMAR Table (cross-reference PCI paths to figure out which memory region is for what). In this case, drop and replace the OEM DMAR table by a modified one without reserved memory regions to resolve the issue!

Verifying that the DMAR Table has been replaced

  • Open maciASL
  • Select "File" > "New from ACPI"
  • Pick DMAR. The file should be shorter in length than the original (in this case it's 104) and should no longer contain Reserved Memory Regions (which it doesn't in this case):
    DMARnu

NOTES

  • OpenCore 0.9.2 introduced a new Kernel Quirk called DisableIoMapperMapping which can be used to address new connectivity issues in macOS 13.3+ (if they weren't present before).
  • You should only import ACPI tables with maciASL if you know that they are unmodified by OpenCore. Otherwise, dump the OEM ACPI Tables using the debug version of OpenCore and enabling the SysReport Quirk and work with those.