Contribute
Register

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

The compilation problem is fixed thanks, but I still can't inject properties through SSDT nor device properties. Should I add DSM method?
Several more questions:
  • Which slot on the motherboard is GPU installed in?
  • What is the make/model of the GPU?
  • What version of macOS are you running?
  • Why are you trying to inject device properties for your GPU? For what purpose?
 
Several more questions:
  • Which slot on the motherboard is GPU installed in?
  • What is the make/model of the GPU?
  • What version of macOS are you running?
  • Why are you trying to inject device properties for your GPU? For what purpose?
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.
 
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.
 
Last edited:
@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.
 

Attachments

  • SSDT-AMD6950.zip
    313 bytes · Views: 25
  • SysReport.zip
    123.7 KB · Views: 35
  • Mac Pro.zip
    2 MB · Views: 25
@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).

Screen Shot 2022-05-21 at 1.26.26 PM.png
 
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
 

Attachments

  • SSDT-BRG0-X299.dsl
    9.4 KB · Views: 23
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.
 

Attachments

  • SSDT-AMD6950-V1.aml
    235 bytes · Views: 38
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”.
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?
 
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.
 
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 o_O... so I guess I will go for the Fenvi (sorry guys... I appreciated your work :clap:)
 
Last edited:
Back
Top