Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

[CaseySJ]

I have 2 GPU's attached to slot one and 2. I have another device on my MOBO which is for iKVM access, so my slots might not be identified in the OSX correctly. Monterey 12.4. The main reason for the tests is to be able to spoof device-id of 6900xt for unsupported 6950xt. I was trying to create an SSDT for a real Mac Pro 2019 with 6950xt installed alongside Vega II, but the computer restarts with the spoof SSDT.

With latest WhateverGreen it's no longer necessary to use SSDT to spoof GPU device ID. We can simply apply a device-id property to the PCI Path of the GPU we wish to spoof. The device-id must be specified in reverse byte order.

However, it may not be possible to spoof a 6950XT to a 6900XT. It's still worth an attempt, but someone recently tried unsuccessfully to spoof a 6650XT to 6600XT.

To answer your previous question about the need for creating a _DSM method to inject device ID via SSDT -- yes, device properties in SSDT are typically injected via _DSM method.

 

[zirkaiva]

@CaseySJ
Here is the SSDT along with the Sysreport (SSDT-5) used to inject properties on the MP7,1, but it just reboots. Maybe you can see something wrong there. But actually, there is someone successfully spoofing 6650XT to 6600xt here:

Attached is the IOREG as well.

 

[CaseySJ]

@CaseySJ
Here is the SSDT along with the Sysreport (SSDT-5) used to inject properties on the MP7,1, but it just reboots. Maybe you can see something wrong there. But actually, there is someone successfully spoofing 6650XT to 6600xt here:

Attached is the IOREG as well.

Because the SSDT is not taking effect, please post your DSDT from macIASL. Save the DSDT as .dsl (we don't want to compile it to an .aml file).

 

[zirkaiva]

Because the SSDT is not taking effect, please post your DSDT from macIASL. Save the DSDT as .dsl (we don't want to compile it to an .aml file).

All tables in .aml and .dsl format are inside the Sysreport file including the DSDT.dsl. These are the tables generated by opencore during boot process.
I also finally got the properties injection through SSDT working on my x299 pro

 

[CaseySJ]

All tables in .aml and .dsl format are inside the Sysreport file including the DSDT.dsl. These are the tables generated by opencore during boot process.
...

Attached SSDT removes device US00 before creating the rest of the device tree.

 

[maeluse]

This is a well-known issue, at least in the CaseySJ threads! Intel Bluetooth (with OpenIntelWireless drivers) does not work in Monterey.

Please refer back to the OpenCore 0.7.8 mini-guide. At the top of it is a section called “Monterey - What does not work”.

Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

EDIT: Did a hard restart and it works now. Odd! Hi everyone, finally received my Vision D and am very excited to set this up. The guide is phenomenal, thanks heaps @CaseySJ. Almost too easy! However I am running into an issue that does not let me finish installation. I get stuck at WIFI...

www.tonymacx86.com

Ohh... indeed but I guess you wrote it after the version 12.3 is released right? My Bluetooth worked perfectly on Monterey 12.2. And as far as I remember, this indication did not appear at the time of updating to Monterey. Should I think of buying a Fenvi BT card or bet on a fix from the openintelwireless team?

 

[CaseySJ]

Ohh... indeed but I guess you wrote it after the version 12.3 is released right? My bluetooth worked perfectly on Monterey 12.2. And as far as I remember, this indication did not appear at the time of updating to Monterey. Should I think of buying a Fenvi BT card or bet on a fix from the openintelwireless team?

I was personally unable to get Intel Bluetooth working in any version of Monterey (if I recall correctly). Some people had better luck than me, but most did not. The developers of “IntelBluetoothFirmware” haven’t updated the kext for half a year or so. It seems they’re not aware of any systemic issues with the driver in Monterey.

My advice has always been to treat the Intel drivers as test versions only (to help the developers find problems or to use the drivers while knowing and accepting their limitations), but to use a natively supported Broadcom module for all other uses.

 

[maeluse]

I was personally unable to get Intel Bluetooth working in any version of Monterey (if I recall correctly). Some people had better luck than me, but most did not. The developers of “IntelBluetoothFirmware” haven’t updated the kext for half a year or so. It seems they’re not aware of any systemic issues with the driver in Monterey.

My advice has always been to treat the Intel drivers as test versions only (to help the developers find problems or to use the drivers while knowing and accepting their limitations), but to use a natively supported Broadcom module for all other uses.

Their limitations suited me until now as I only need basic Bluetooth features and no WIFI... but I now feel the limitations a bit hard with no BT at all ... so I guess I will go for the Fenvi (sorry guys... I appreciated your work )

 

[zirkaiva]

Attached SSDT removes device US00 before creating the rest of the device tree.

Now it reboots in OC, but still does not attach. In SSDT-5 those devices are already defined isn't that an issue?
Also, it is strange that the path in Windows is:

ACPI(_SB_)#ACPI(PC03)#ACPI(BR3A)#PCI(0000)#PCI(0000)#PCI(0000)

Whereas Vega's II path MPX in slot one is:

\_SB.PC01.BR1A.EGP0.EGP1.GFX0

Also it is strange that both devices do not load Windows drivers simultaneously. It is either/or.
What do you think about this:

DefinitionBlock ("", "SSDT", 2, "Apple", "AMD6950", 0x00000000)
{
    External (_SB_.PC03, DeviceObj)
    External (_SB_.PC03.BR3A, DeviceObj)
    External (_SB_.PC03.BR3A.US00, DeviceObj)
    External (DTGP, MethodObj)    // 5 Arguments

    Scope (\_SB.PC03.BR3A)
    {
        Scope (US00)
        {
            Name (_STA, Zero)  // _STA: Status
        }

        
                Device (GFX1)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                    Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                    {
                        If (!Arg2)
                        {
                            Return (Buffer (One)
                            {
                                 0x03                                             // .
                            })
                        }

                        Return (Package (0x02)
                        {
                            "device-id",
                            Buffer (0x04)
                            {
                                 0xBF, 0x73, 0x00, 0x00                           // .s..
                            }
                        })                       
                    }
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                }

                Device (HDAU)
                {
                    Name (_ADR, One)  // _ADR: Address
                }
            }     
  
}

 

[cliffDeane]

Hi Guys,

Has anyone found a solution to the slow boot when Thunderbolt is enabled? I have a z490 Vision D and flashed the firmware via the guide mentioned on this thread.

All working great but a 30 sec delay before post when Thunderbolt is enabled. If disabled, I get an almost instant post.

I have also booted with no drives attached, cleared the CMOS and still the same issue.

Has anyone else experienced this?

Cliff