How to successfully rename bare pci8086,xxxx devices in IODeviceTree as ACPI devices via SSDT?

MacKonsti · April 25, 2020

Hello everyone, I hope you are well and safe. Long time Hackintosh user, didn't post new topics really as most solutions are here, just need some good digging around.

However, there has been no talk about renaming "bare" PCI devices shown in IORegistryExplorer such as e.g. pci8086,1911@8 or pci8086,9def@14,2 to something more meaningful such as ACPI Devices like (SPI1) or (PGMM) or (SHRM) etc. etc.

I have been experimenting a lot with different SSDT ways of making code and injecting the compiled AML via Clover, in preparation for OpenCore, but I cannot succeed for this one.

Why is this needed? For starters, I have two good reasons.

a) My device pci8086,3ed0@0 is MCHC per lspci and despite Clover being able to inject the parameter AddMCHC, I cannot achieve the same result via SSDT injection instead, meaning OpenCore would not do it either (well, for now).

b) Moreover, I discovered by accident from another config.plist in some Github repository, that my device pci8086,9df9@12 that is listed in lspci as Coffee Lake Thermal Controller [8086:9df9] can be set to being compatible with Apple's accepted and combatible device-id of pci8086,9d21 via Clover injection in Devices -> Properties section or via SSDT, but I cannot make it get a human-friendly ACPI name at all so it get to work and load kext com.apple.driver.AppleIntelPCHPMC.

Believe me, I have a few structures of code... Here is my code (compiles 100%) as an example and below, a blocking issue as well.

/*
 * Intel ACPI Name Space Architecture for NUC8i7BEH2 device
 *
 * NOTES:
 * Assigned PCI device generic (PGMM) and working (PMCR) to undefined devices in IODeviceTree.
 * Added new (SBUS) sub-system (BUS0) and (DVL0) devices for improved vanilla detection.
 * Added new (LPCB) sub-system (EC) device for improved Catalina detection.
 */

DefinitionBlock ("SSDT-OTHER.aml", "SSDT", 2, "Clover", "OTHER", 0x00000000)
{
    External (_SB_.PCI0, DeviceObj)
    External (_SB_.PCI0.LPCB, DeviceObj)
    External (_SB_.PCI0.LPCB.H_EC, DeviceObj)
    External (_SB_.PCI0.SBUS, DeviceObj)

    Scope (\_SB.PCI0)
    {
//      Device (MCHC)  // Intel Corporation Host Bridge/DRAM Registers [8086:3ed0]
//      {
//          Name (_ADR, 0x00000000)
//      }

//      Device (PGMM)  // Intel Corporation Core Processor Gaussian Mixture Model [8086:1911]
//      {
//          Name (_ADR, 0x00080000)
//      }

        Device (PMCR)  // Intel Corporation Coffee Lake Thermal Controller [8086:9df9]
        {
            Name (_ADR, 0x00120000)
        }

//      Device (SRAM)  // Intel Corporation Coffee Lake Shared SRAM [8086:9def]
//      {
//          Name (_ADR, 0x00142000)
//      }

//      Device (SPI1)  // Intel Corporation Coffee Lake Serial Bus SPI Controller [8086:9da4]
//      {
//          Name (_ADR, 0x001F5000)
//      }
    }

    Scope (\_SB.PCI0.LPCB)  // Intel Corporation Coffee Lake LPC Controller [8086:9d84]
    {
        Device (EC)
        {
            Name (_HID, "ACID0001")

            Method (_STA, 0, NotSerialized)
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }
    }

    // Do not rename EC0, H_EC, etc. to EC as these devices are incompatible with macOS
    // and may break at any time; AppleACPIEC kext must NOT load. If your motherboard
    // has an existing Embedded Controller of PNP0C09 type, use the code below to disable.

    Scope (\_SB.PCI0.LPCB.H_EC)
    {
        Method (_STA, 0, NotSerialized)
        {
            If (_OSI ("Darwin"))
            {
                Return (Zero)
            }
            Else
            {
                Return (0x0F)
            }
        }
    }

    Scope (\_SB.PCI0.SBUS)  // Intel Corporation Coffee Lake SMBus Controller [8086:9da3]
    {
        Device (BUS0)
        {
            Name (_ADR, Zero)
            Name (_CID, "smbus")

            Device (DVL0)
            {
                Name (_ADR, 0x57)
                Name (_CID, "diagsvault")

                Method (_DSM, 4, NotSerialized)
                {
                    If (LEqual (Arg2, Zero))
                    {
                        Return (Buffer (One) {0x57})
                    }

                    Return (Package (0x02) {"address", 0x57})
                }
            }
        }
    }
}

So if I use External (_SB_.PCI0, DeviceObj) reference on top, then a Scope (\_SB.PCI0) under it, I found out after many tests and reboots that device with 0x00120000 address is somehow allowed to be assigned a "name" in IODeviceTree but not any others! If I enable the other ones, nothing gets injected in this SSDT as a result !

00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3ed0] (rev 08)
00:08.0 System peripheral [0880]: Intel Corporation Core Processor Gaussian Mixture Model [8086:1911]
00:12.0 Signal processing controller [1180]: Intel Corporation Coffee Lake Thermal Controller [8086:9df9] (rev 30)
00:14.2 RAM memory [0500]: Intel Corporation Coffee Lake Shared SRAM [8086:9def] (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Coffee Lake SPI Controller [8086:9da4] (rev 30)

I guess this is likely due to the way my Intel NUC8i7BEH's BIOS and ACPI code is written ?

What's amazing is that if we use Clover's AddMCHC option, in MacIASL I see inside the main DSDT a new code portion added in the _SB.PCI0 very very end at the bottom:

But if I uncomment the code for adding Device (MCHC) in my SSDT code above, the device will not get injected ! This is nuts.

@MaLd0n I have been following most of your work for many years and know that you have better knowledge of ACPI code than me, can you possibly advise how we can rename these "naked" PCI devices in IORegistry Explorer to something meaningful like Device (XYZ) ? Is this possible via SSDT code injection?

Anyone else you have in mind, that could help? @Hervé peut-être, maybe you?

The idea is that, except device at 0x00120000 address being accepted (by chance!) and renamed as Device (PMCR) that helps enable the native power-management by injecting later in Clover's configuration a <key>compatible</key> ID, all others including MCHC cannot be assigned a name.

Your help is appreciated... I tried ways to define Devices with root " \ " reference as in External (\_SB_.PCI0, DeviceObj) and Scope (\_SB.PCI0) and without this, for the love of me I cannot understand how to do it.

Moreover, having disassembled all AML files obtained at Clover Boot time, there is no reference to a device with addresses Name (_ADR, 0x00000000), Name (_ADR, 0x00080000), Name (_ADR, 0x00120000) or Name (_ADR, 0x001F5000) anywhere...

Could it be that they do not belong to Scope (\_SB.PCI0) at all ? But Hackintool does report them as being under PciRoot(0x0) ! Could it be differently under some other device instead? ACPIPlane in IORegistryExplorer doesn't show anything

IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/MCHC@0 --> PciRoot(0x0)/Pci(0x0,0x0)
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PMCR@12 --> PciRoot(0x0)/Pci(0x12,0x0)
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/pci8086,9def@14,2 --> PciRoot(0x0)/Pci(0x14,0x2)
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/pci8086,9da4@1F,5 --> PciRoot(0x0)/Pci(0x1F,0x5)

Thanks... hope I can resolve this before spending time migrating to OpenCore...!

Here's a screenshot of the "bare" pci8086,xxxx devices without injection of my code at all, except Clover's AddMCHC option.

Edited April 25, 2020 by MacKonsti

MaLd0n · April 25, 2020

example with@14,2 adr, missing device in skylake+

Quote

DefinitionBlock ("", "SSDT", 2, "Apple", "Mald0n", 0x00000000)
{
External (_SB_.PCI0, DeviceObj)

Device (_SB.PCI0.MALD)
{
Name (_ADR, 0x00140002) // _ADR: Address
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg2 == Zero))
{
Return (Buffer ()
{
0x03 // .
})
}

Return (Package ()
{
"AAPL,slot-name",
"Built In",
"model",
Buffer ()
{
"Patched by MaLd0n - olarila.com"
},

"name",
Buffer ()
{
"MaLd0n"
},

"device_type",
Buffer ()
{
"MaLd0n"
},

"device-id",
Buffer ()
{
0xAA, 0xAA, 0x00, 0x00 // ....
},

"compatible",
Buffer ()
{
"pci8086,aaaa"
}
})
}
}
}

MaLd0n 2020-04-25 at 13.16.43.png

SSDT-MaLd0n.aml.zip

MacKonsti · April 25, 2020

Thanks @MaLd0n so you do not use Scope (\_SB.PCI0) at all, right? Direct reference to Device (_SB.PCI0.MALD) instead? And this gets added like that because it's not existing in any DSDT/SSDT of your computer BIOS?

You may be lucky, but I will try and report back, thank you for the tip!

Edited April 25, 2020 by MacKonsti

MaLd0n · April 25, 2020

just create missing device into pci0(in this case) and done

yes, any table have this device, we need create and inject properties

other example, same device

Quote

External (_SB_.PCI0, DeviceObj)

Scope (_SB.PCI0)
{
Device (MALD)
{
Name (_ADR, 0x00140002) // _ADR: Address
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg2 == Zero))
{
Return (Buffer ()
{
0x03 // .
})
}

Return (Package ()
{
"AAPL,slot-name",
"Built In",
"model",
Buffer ()
{
"Patched by MaLd0n - olarila.com"
},

"name",
Buffer ()
{
"MaLd0n"
},

"device_type",
Buffer ()
{
"MaLd0n"
},

"device-id",
Buffer ()
{
0xAA, 0xAA, 0x00, 0x00 // ....
},

"compatible",
Buffer ()
{
"pci8086,aaaa"
}
})
}
}
}

MacKonsti · April 25, 2020

@MaLd0n thank you again -- I have tried that second method, it doesn't work my friend.

If I inject these 2 devices only, it works:

DefinitionBlock ("SSDT-OTHER.aml", "SSDT", 2, "Clover", "OTHER", 0x00000000)
{
    External (_SB_.PCI0, DeviceObj)
    Scope (\_SB.PCI0)
    {
        Device (PGMM)  // Intel Corporation Core Processor Gaussian Mixture Model [8086:1911]
        {
            Name (_ADR, 0x00080000)
        }

        Device (PMCR)  // Intel Corporation Coffee Lake Thermal Controller [8086:9df9]
        {
            Name (_ADR, 0x00120000)
        }
    }
}

If I put the extra 2 more devices like SRAM or SPI1 to test, nothing gets injected at all ! And these extra 2 devices do exist.

DefinitionBlock ("SSDT-OTHER.aml", "SSDT", 2, "Clover", "OTHER", 0x00000000)
{
    External (_SB_.PCI0, DeviceObj)
    Scope (\_SB.PCI0)
    {
        Device (PGMM)  // Intel Corporation Core Processor Gaussian Mixture Model [8086:1911]
        {
            Name (_ADR, 0x00080000)
        }

        Device (PMCR)  // Intel Corporation Coffee Lake Thermal Controller [8086:9df9]
        {
            Name (_ADR, 0x00120000)
        }

        Device (SRAM)  // Intel Corporation Coffee Lake Shared SRAM [8086:9def]
        {
            Name (_ADR, 0x00142000)
        }

        Device (SPI1)  // Intel Corporation Coffee Lake Serial Bus SPI Controller [8086:9da4]
        {
            Name (_ADR, 0x001F5000)
        }
    }
}

Could it be that they are empty inside except the code Name (_ADR, 0x001F5000) for example? Is it possible that Clover doesn't inject them because they only have _ADR inside? But why does it work with the first two only?

Any further ideas?

MaLd0n · April 25, 2020

send me ur original dsdt

MacKonsti · April 25, 2020

Here is the dumped DSDT/SSDT from Clover boot option.

Intel NUC8i7BEH2 computer, using BIOS v56 and disassembled DSL included in ZIP.

Obrigada

BE0056 BIOS Disassembled.zip

Edited April 25, 2020 by MacKonsti

MaLd0n · April 25, 2020

i ever prefer dsdt, 2 minutes and all is done

use it with clover, dont need any ssdt or renames if u use whatevergreen and applealc kexts

all example inside dsdt

DSDT.aml.zip

MacKonsti · April 25, 2020

So you remain a DSDT fan, right? OK yes, I guess touching/editing DSDT fixes this, of course.

I just wanted to avoid compiling DSDT as it is huge, as you saw, and has many devices that I don't recognise or not even shown in IORegistry Exporer or IODeviceTree (too much generic garbage inside)

Obrigada for your time and help.

Shame I cannot use the simple SSDT as you also posted.

Intel released a new BIOS v78 which means I have to re-do the editing... that is what I was looking for a simpler solution via SSDT.

Thanks again.

For your information, on my MSI Z97i-AC board, this simple Device (MCHC) adding via SSDT works perfectly....

MacKonsti · April 25, 2020

@MaLd0n a quick question if you have some more time, please. In order to learn more and understand your changes/additions, can I ask you for the exact Terminal command for disassembling all the AMLs combined and re-assembling them? I understand if this is not done right, there's a risk of making a bad DSDT.

What version of iasl did you use? The code in the provided DSDT (thank you again very much!) seems a newer way to write it, looks like simpler syntax than original (especially in IF statements). Moreover the DSDTs have different size, not sure if they are due to optimised in re-assembling it...

Haven't messed with iasl for quite some time to be honest, not since leaving Chameleon and my previous Ivy Bridge hack, I admit

Thank you.

MaLd0n · April 26, 2020

all in one patch for skylake+, after it just need fix little changes for compile

2 minutes and i have a full solution

my dsdt for example, z390 mobo, i raped 35k lines, bios/uefi from common mobos have a many trashes for macos

60k lines to 25k lines

Apple use a very custom DSDT, iMac19,1 have a DSDT with 8k lines, a very custom DSDT is ever better and clean solution

many things don't work via ssdt

MacKonsti · April 26, 2020

Thank you @MaLd0n I understand now. I was under the idea that you were disassembling ALL the AML files in terminal via some special iasl parameters so the re-compilation of DSDT would include all the external references (in Terminal).

Allow me a few quick questions, will try for a Yes/No reply...

So you only take single file DSDT.aml and not care about the other SSDT-xx files yes? No problem with external references?
You open it in MacIASL with iasl 20200326 but latest MacIASL v1.5.7 has 20200110 (Stable) or 20200214 (Dev) on my Mac, is this a problem?
Is this your compiled version of Acidanthera's repo or are you compiling yourself sources from https://github.com/acpica/acpica/releases ?
In your video (nice work by the way) you are using non-available (by default) repo patches, are they your own local (HDD) files? I tried searching in olarila.com but I am not sure I could find a repo to add in MacIASL nor "300 Series" text file.
I see you choose "Series 300" patches but I think my Intel NUC is really a "Series 100" hardware: Intel Core i7-8559U Coffee Lake as Macmini8,1 so is this a problem you think?
Can this method of doing old-school DSDT patching add the EC, MCHC, SBUS and BUS0 devices like in the old times?

Thanks again, I see that you are keeping very active still, and it is good to have people like you still around!

Obrigada

MaLd0n · April 26, 2020

4 hours ago, MacKonsti said:

Thank you @MaLd0n

yes, compiled last version from here https://github.com/acpica/acpica

is my personal patches

this patch is for serie 100/200/300 chipset, just need a little changes after applied

this patch add all devices, inject all properties, remove some unused and problematic

2 minutes and all is working

MacKonsti · May 1, 2020

Hi again @MaLd0n I understand. They are your patches collection, of course.

All these years I am sure you got a lot of experience, as you continued DSDT editing compared to me who abandoned it after moving on to Clover

A few days back, I tried to remember my skills and tried to just recompile the AML in MacIASL but I get way too many errors to compile 100% -- this means we cannot do anything without patches anymore

Today, I did a leap of faith and updated my Intel NUC with BIOS v78 as it has been quite some revisions after BIOS v56 sheared earlier; but the SSDT-xxx renaming of pci8086,xxxx results are still bad.

I am attaching my Clover-extracted BIOS v78 if you have some time to fix the main DSDT.aml with your patch collection, it would be great.

Do you also include the latest needed patch for AWAC? I have to run a special SSDT to set value STAS=One so I can boot macOS now...

Thanks again!

BE0078 BIOS Extracted.zip

MaLd0n · May 1, 2020

DSDT.last.zip

Alpha22 · May 2, 2020

@MaLd0n

Quote

yes, compiled last version from here https://github.com/acpica/acpica

sorry if I intervene, you can explain how to fill it out

MacKonsti · May 3, 2020

You need to download sources @Alpha22 and compile it locally on your computer, I do not know how to achieve this as there are dependencies and requirements that are not part of this topic. However, the MacIASL.app contains a rather recent version (2020) of iasl so no need to go to a much newer version for basic edits/compilation.

What is more important is to know and apply the correct list of Patches inside MacIASL...

Edited May 3, 2020 by MacKonsti

tonyx86 · June 9, 2020

@MacKonsti I stumbled upon your thread while trying to figure out why my Device (PMCR) wasn't loading (as viewed in IORegistry Explorer). I ended up finding a real MacMini8,1 ACPI dump and found a solution that "works" for me (still testing). Take a look at the IONameMatch here in my HP EliteDesk 800 G4 Mini thread to see what's happening. With a "simple" Device (PMCR) injection, PMCR device was not loading for me. The key seems to have been the addition of the APP9876 ID.

I'm still testing this (and really haven't noticed any difference), so any feedback / constructive criticism is welcome.

MacKonsti · June 9, 2020

Hi @tonyx86 eventually I was making a mistake with the ",1" device in the address... I found a similar SSDT patch in some Git and eventually I am able to name the devices that are unnamed in my IORegistry.

It was lcpi that confused me... so eventually for the device that lcpi reported as 00:14.2 RAM memory [0500]: Intel Corporation Coffee Lake Shared SRAM [8086:9def] (rev 30) the address in SSDT was not Name (_ADR, 0x001420000) but Name (_ADR, 0x00140002) instead <facepalm>

Now all my unnamed devices load OK via a simple SSDT declaration of their _ADR

Eventually, for PMCR on my Intel NUC, I made two changes/additions a) add generic Apple-vanilla device PMCR and b) named my Thermal Device as Device (THRM) and as the lspci reported the device ID 98086:9df9] I found it was compatible with an Apple one.

The SSDT code is, thus:

    Scope (\_SB.PCI0)
    {
        Device (THRM)  // Intel Corporation Coffee Lake Thermal Controller [8086:9df9]
        {
            Name (_ADR, 0x00120000)  // _ADR: Address
        }
        Device (PMCR)
        {
            Name (_HID, EisaId ("APP9876"))  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadWrite,
                    0xFE000000,         // Address Base
                    0x00010000,         // Address Length
                    )
            })
            // Original _STA value for Device (PMCR) found in MacMini8,1 DSDT was 0x0B which
            // is 1011 in binary. Reading from right to left, it represents the following:
            //
            // 1 - Bit [0] – Set if the device is present
            // 1 - Bit [1] – Set if the device is enabled and decoding its resources
            // 0 - Bit [2] – Set if the device should be shown in the UI
            // 1 - Bit [3] – Set if the device is functioning properly (cleared if device failed its diagnostics)
            //
            // Converter: https://www.rapidtables.com/convert/number/hex-to-binary.html
            // Source: https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0B)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }
    }

And in Clover's config Devices section, I set it to a compatible device 9d21:

            <key>PciRoot(0x0)/Pci(0x12,0x0)</key>
            <dict>
                <key>compatible</key>
                <string>pci8086,9d21</string>
                <key>model</key>
                <string>Intel Corporation 100 Series Thermal Controller</string>
            </dict>

Obviously the PciRoot path is different for other motherboards.

KEXT REFERENCE: Check /System/Library/Extensions/AppleIntelPCHPMC.kext/Contents/Info.plist if your device ID is compatible with the ones supported by Apple, by cross-referencing with https://pci-ids.ucw.cz/read/PC/8086/9df9 (that is my own device).

What I noticed is a smoother line of Power Management in the graph, while checking Intel's Power Gadget, also made sure both these Devices appear in IORegistryExplorer as loaded and detected properly.

Please do a very careful check for the above if you can support them, I am using Coffee Lake platform. Not sure how it works on others!

tonyx86 · June 9, 2020

@MacKonsti Looks like we both found the same ACPI definition of Device (PMCR). Nice.

Scrubber · August 26, 2020

On 6/9/2020 at 9:25 PM, MacKonsti said:
Hi @tonyx86 eventually I was making a mistake with the ",1" device in the address... I found a similar SSDT patch in some Git and eventually I am able to name the devices that are unnamed in my IORegistry.

It was lcpi that confused me... so eventually for the device that lcpi reported as 00:14.2 RAM memory [0500]: Intel Corporation Coffee Lake Shared SRAM [8086:9def] (rev 30) the address in SSDT was not Name (_ADR, 0x001420000) but Name (_ADR, 0x00140002) instead <facepalm>

Now all my unnamed devices load OK via a simple SSDT declaration of their _ADR

Eventually, for PMCR on my Intel NUC, I made two changes/additions a) add generic Apple-vanilla device PMCR and b) named my Thermal Device as Device (THRM) and as the lspci reported the device ID 98086:9df9] I found it was compatible with an Apple one.

The SSDT code is, thus:
    Scope (\_SB.PCI0)
    {
        Device (THRM)  // Intel Corporation Coffee Lake Thermal Controller [8086:9df9]
        {
            Name (_ADR, 0x00120000)  // _ADR: Address
        }
        Device (PMCR)
        {
            Name (_HID, EisaId ("APP9876"))  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadWrite,
                    0xFE000000,         // Address Base
                    0x00010000,         // Address Length
                    )
            })
            // Original _STA value for Device (PMCR) found in MacMini8,1 DSDT was 0x0B which
            // is 1011 in binary. Reading from right to left, it represents the following:
            //
            // 1 - Bit [0] – Set if the device is present
            // 1 - Bit [1] – Set if the device is enabled and decoding its resources
            // 0 - Bit [2] – Set if the device should be shown in the UI
            // 1 - Bit [3] – Set if the device is functioning properly (cleared if device failed its diagnostics)
            //
            // Converter: https://www.rapidtables.com/convert/number/hex-to-binary.html
            // Source: https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0B)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }
    } 
And in Clover's config Devices section, I set it to a compatible device 9d21:
            <key>PciRoot(0x0)/Pci(0x12,0x0)</key>
            <dict>
                <key>compatible</key>
                <string>pci8086,9d21</string>
                <key>model</key>
                <string>Intel Corporation 100 Series Thermal Controller</string>
            </dict>
Obviously the PciRoot path is different for other motherboards.

KEXT REFERENCE: Check /System/Library/Extensions/AppleIntelPCHPMC.kext/Contents/Info.plist if your device ID is compatible with the ones supported by Apple, by cross-referencing with https://pci-ids.ucw.cz/read/PC/8086/9df9 (that is my own device).

What I noticed is a smoother line of Power Management in the graph, while checking Intel's Power Gadget, also made sure both these Devices appear in IORegistryExplorer as loaded and detected properly.

Please do a very careful check for the above if you can support them, I am using Coffee Lake platform. Not sure how it works on others!

Hi MacKonsti. My processor is Intel® Core ™ i3-8145U. I have the same devices in IORegistry Explorer, and at the same addresses as you do. Share your SSDT.aml for openCore to activate these devices properly.
I will be very grateful to you. (Can you write a small manual how to do this?)
Thank!

How to successfully rename bare pci8086,xxxx devices in IODeviceTree as ACPI devices via SSDT?

Recommended Posts

MacKonsti 48

MaLd0n 6,548

MacKonsti 48

MaLd0n 6,548

MacKonsti 48

MaLd0n 6,548

MacKonsti 48

MaLd0n 6,548

MacKonsti 48

MacKonsti 48

MaLd0n 6,548

MacKonsti 48

MaLd0n 6,548

MacKonsti 48

MaLd0n 6,548

Alpha22 44

MacKonsti 48

tonyx86 188

MacKonsti 48

tonyx86 188

Scrubber 0