Ryzen 7000 Testing

[CaseySJ]

To automatically start the iStatistica app on login, move it to the Jonsbo D31 screen, and make it full size, I spent a few minutes with the Shortcuts app as follows:

Step 1: Create a shortcut that starts the app, moves it to Jonsbo D31, and makes it full size

Step 2: Add it to Dock, which is necessary before it can be launched at login



Step 3: Right click the icon in Dock and select Open at Login



Now iStatistica will run full size on the Jonsbo each time macOS boots:



I wish the Shortcuts app supported the ability to make a window full-screen (not just "fit screen").

 

[mariettosun]

@CaseySJ thank you for confirming Continuity Cam is working...
for me was an user error, I have installed from a backup an old kext (1.1.3 instead of a working one (1.1.4))

 

[CaseySJ]

** Owners of AMD 6650 XT, 6950 XT, and 6900 XTXH GPUs **​

These GPUs have device IDs that are not natively supported in macOS. We have historically overcome this problem by using a SSDT that creates necessary PCI bridge devices and then spoofs the DeviceID to each model's closest sibling.

The SSDT and device ID spoofing are no longer necessary.

Someone on the German Hackintosh website has created a kernel extension that allows all three of these GPUs to be fully supported by macOS. The kext is attached here.

Procedure:

• Disable or delete all device properties associated with the GPU (6650 XT, 6950 XT, or 6900 XTXH)
• Disable or delete any SSDT that creates bridge devices and spoofs the device ID
• Download attached kext and copy to EFI/OC/Kexts folder
• Add an entry for this kext in config.plist -> Kernel -> Add
• Reboot

---

Link to German website:

AMD Radeon 6650 XT, 6950 XT und 6900 XTXH ohne GPU-ID Spoofing - Hackintosh-Forum - Deine Anlaufstelle für Hackintosh & mehr...

Hallo allerseits,ich stelle hier mal meine Kernel Extension für die eigentlich nicht unterstützten Ausbaustufen von Navi21 (RX 6950 XT und RX 6900 XTXH) und Navi23 (RX 6650 XT) zur Verfügung.Ein VorwortWarum weg vom DeviceID Spoofing? ..DeviceID Spoofing…

www.hackintosh-forum.de

 

[ExtremeXT]

** Owners of AMD 6650 XT, 6950 XT, and 6900 XTX GPUs **​

These GPUs have device IDs that are not natively supported in macOS. We have historically overcome this problem by using a SSDT that creates necessary PCI bridge devices and then spoofs the DeviceID to each model's closest sibling.

The SSDT and device ID spoofing are no longer necessary.

Someone on the German Hackintosh website has created a kernel extension that allows all three of these GPUs to be fully supported by macOS. The kext is attached here.

Procedure:

• Disable or delete all device properties associated with the GPU (6650 XT, 6950 XT, or 6900 XTX)
• Disable or delete any SSDT that creates bridge devices and spoofs the device ID
• Download attached kext and copy to EFI/OC/Kexts folder
• Add an entry for this kext in config.plist -> Kernel -> Add
• Reboot

---

Link to German website:

AMD Radeon 6650 XT, 6950 XT und 6900 XTXH ohne GPU-ID Spoofing - Hackintosh-Forum - Deine Anlaufstelle für Hackintosh & mehr...

Hallo allerseits,ich stelle hier mal meine Kernel Extension für die eigentlich nicht unterstützten Ausbaustufen von Navi21 (RX 6950 XT und RX 6900 XTXH) und Navi23 (RX 6650 XT) zur Verfügung.Ein VorwortWarum weg vom DeviceID Spoofing? ..DeviceID Spoofing…

www.hackintosh-forum.de

Is there any advantage to this over the traditional device-id property? I use it on my 6650 XT and it works fine.

Looks like it injects a bunch of properties, any explications to those?

 

[CaseySJ]

Is there any advantage to this over the traditional device-id property? I use it on my 6650 XT and it works fine.

Looks like it injects a bunch of properties, any explications to those?

There are ease-of-use advantages:

• No need to determine PCI path of GPU
• No need to customize the SSDT and work with ACPI
• No need to disable the SSDT when changing GPUs
• kext auto-detects GPU in any slot of any motherboard
• kext does nothing if no compatible GPU found (we can change GPUs at any time)
• kext may even work with eGPUs (refer to green text below, but I have not seen concrete evidence of this yet)

And perhaps some technical advantages, which I'll defer to this auto-translation of the German text:

Hello everyone, I provide my kernel extension here for the actually unsupported expansion levels of Navi21 (RX 6950 XT and RX 6900 XTXH) and Navi23 (RX 6650 XT). A foreword Why away from DeviceID spoofing? .. In my opinion, DeviceID spoofing has "unclean" and even "dirty" solution qualities and should actually only be considered as a temporary workaround. unclean, because the GPU ID spoofing obviously does not reach the last (lowest) level. If you look at the "compatible" key with a spoofed GPU ID in the IORegistryExplorer in the GFX0 device, you will only find the original and not the spoofed ID there. .. So far, I have never had the problem that this becomes relevant, but this condition is not really consistent. dirty, because device-uncritically interferes with device/drivernstanzization here, and with the determination of the DeviceID according to PCI path, all devices in this slot get the same DeviceID (and thus the same Teiber) pressed on, .. no matter what is in there. The flexibility of the hardware configuration is thus (at least for the graphics card) gone. At the latest if you have to install another graphics card - e.g. in an emergency - this may catch up with you again .. certainly, but if the exchange device has a completely different architecture. In addition, I find DeviceProperties via config.plist or SSDT/DSM only suitable for devices that cannot be replaced because they are permanently installed on the board (Ethernet, Onboard Audio, etc.) For everything that is exchangeable, a dynamic solution should be sought .. The goal A PersonalityProvider that, like any normal driver, generates the driver instances sensitively, and assigns all additional DeviceProperties on-demand-only as an all-in-one solution. The result Originally, I had only implemented the project for the RX 6650 XT, but since the concept basically works for every device that runs via ID spoofing (not only graphics), I have extended this Kext to all Navi20 known to me. Creating the IOPersonalitiy is not very complicated and at GitHub I found a solution at the weekend to hand over the DeviceProperties via IOService (see here). I use a slightly modified version of these codes, the credit for this is due in any case Voight-Kampf. .. Thank you

However, it's still possible to add custom framebuffers and PowerPlayTables by entering them as child elements in info.plist under IOKitPersonalities as described here:

Unmodified, the Kext only passes on the properties model (Graka name), ATY,FamilyName and ATY,DeviceName (the latter for MetalDeviceName). By the way, I have omitted "AMD" from model, so that "about this Mac" does not become a two-liner, who wants can ever add it again. If FramebuffersEdits, PowerPlayTables or possibly other cosmetics etc. are to be given, they can be entered as child elements in the info.plist under IOKitpersonalities->corresponding root device->IOProviderMergeProperties.

 

[ExtremeXT]

There are ease-of-use advantages:

• No need to determine PCI path of GPU
• No need to customize the SSDT and work with ACPI
• No need to disable the SSDT when changing GPUs
• kext auto-detects GPU in any slot of any motherboard
• kext does nothing if no compatible GPU found (we can change GPUs at any time)
• kext may even work with eGPUs (refer to green text below, but I have not seen concrete evidence of this yet)

And perhaps some technical advantages, which I'll defer to this auto-translation of the German text:

Hello everyone, I provide my kernel extension here for the actually unsupported expansion levels of Navi21 (RX 6950 XT and RX 6900 XTXH) and Navi23 (RX 6650 XT). A foreword Why away from DeviceID spoofing? .. In my opinion, DeviceID spoofing has "unclean" and even "dirty" solution qualities and should actually only be considered as a temporary workaround. unclean, because the GPU ID spoofing obviously does not reach the last (lowest) level. If you look at the "compatible" key with a spoofed GPU ID in the IORegistryExplorer in the GFX0 device, you will only find the original and not the spoofed ID there. .. So far, I have never had the problem that this becomes relevant, but this condition is not really consistent. dirty, because device-uncritically interferes with device/drivernstanzization here, and with the determination of the DeviceID according to PCI path, all devices in this slot get the same DeviceID (and thus the same Teiber) pressed on, .. no matter what is in there. The flexibility of the hardware configuration is thus (at least for the graphics card) gone. At the latest if you have to install another graphics card - e.g. in an emergency - this may catch up with you again .. certainly, but if the exchange device has a completely different architecture. In addition, I find DeviceProperties via config.plist or SSDT/DSM only suitable for devices that cannot be replaced because they are permanently installed on the board (Ethernet, Onboard Audio, etc.) For everything that is exchangeable, a dynamic solution should be sought .. The goal A PersonalityProvider that, like any normal driver, generates the driver instances sensitively, and assigns all additional DeviceProperties on-demand-only as an all-in-one solution. The result Originally, I had only implemented the project for the RX 6650 XT, but since the concept basically works for every device that runs via ID spoofing (not only graphics), I have extended this Kext to all Navi20 known to me. Creating the IOPersonalitiy is not very complicated and at GitHub I found a solution at the weekend to hand over the DeviceProperties via IOService (see here). I use a slightly modified version of these codes, the credit for this is due in any case Voight-Kampf. .. Thank you

However, it's still possible to add custom framebuffers and PowerPlayTables by entering them as child elements in info.plist under IOKitPersonalities as described here:

Unmodified, the Kext only passes on the properties model (Graka name), ATY,FamilyName and ATY,DeviceName (the latter for MetalDeviceName). By the way, I have omitted "AMD" from model, so that "about this Mac" does not become a two-liner, who wants can ever add it again. If FramebuffersEdits, PowerPlayTables or possibly other cosmetics etc. are to be given, they can be entered as child elements in the info.plist under IOKitpersonalities->corresponding root device->IOProviderMergeProperties.

Okay, I'll try it tomorrow and let you know, benchmarks too.

 

[CaseySJ]

Okay, I'll try it tomorrow and let you know, benchmarks too.

Some users (not all) have reported that some DRM apps don't work, so it's good to check as many as possible (AppleTV+, Apple Music App, Netflix in Safari, etc.).

 

[etorix]

There are ease-of-use advantages:

• No need to determine PCI path of GPU
• No need to customize the SSDT and work with ACPI
• No need to disable the SSDT when changing GPUs
• kext auto-detects GPU in any slot of any motherboard
• kext does nothing if no compatible GPU found (we can change GPUs at any time)
• kext may even work with eGPUs (refer to green text below, but I have not seen concrete evidence of this yet)

My reading of the last point is that "exchangeable" ("tauschbar") refers to cards in PCIe slots, as opposed to devices which are soldered to the motherboard. I see no eGPU hint here.

For the rest, the ease of use benefit is clear. Decyphering ACPI and PCI paths is a major hurdle for many.

 

[CaseySJ]

My reading of the last point is that "exchangeable" ("tauschbar") refers to cards in PCIe slots, as opposed to devices which are soldered to the motherboard. I see no eGPU hint here.

For the rest, the ease of use benefit is clear. Decyphering ACPI and PCI paths is a major hurdle for many.

The SSDT method cannot be used for eGPUs because we can neither (a) create bridge devices on Thunderbolt device paths nor (b) inject device properties on those paths. But a kext should be able to get around both of these hurdles. The AMD drivers in macOS work equally well with eGPUs and internally-installed GPUs.

This kext uses the same IO PCI matching mechanism as the AMD drivers. These drivers are invoked by the kernel when all internal and external devices have been discovered and instantiated in IOReg. As long as the eGPU is visible in IOReg, it should be recognized by this driver.

Thunderbolt is an extension of the PCI bus, and devices connected there are also “exchangeable”, which means a “dynamic solution” applies here as well.

I have a flashed Thunderbolt bus and an eGPU enclosure, but I don't have a 6650XT, 6900 XTXH, or 6950XT -- otherwise I would run the experiment myself.

The post below seems to be an interesting (quirky) workaround to an eGPU, but it strips out the entire Thunderbolt device tree in favor of a string of bridges from PCI0 (root) to the GPU itself. I suppose if there's only one Thunderbolt port (e.g. on a laptop) and only one Thunderbolt device (eGPU) then this seems viable.

https://www.tonymacx86.com/threads/success-amd-rx6000-series-working-in-macos.306736/page-201#post-2363145

 

[ExtremeXT]

@CaseySJ Acceleration works, but hardware decoding is broken.

Screenshot

Captured with Lightshot

prnt.sc

 

[CaseySJ]

@CaseySJ Acceleration works, but hardware decoding is broken.

Screenshot

Captured with Lightshot

prnt.sc

Good to know.

Those who require hardware decoding should avoid this kext for now. Not sure if specifying a frame buffer will help.

 

[CaseySJ]

Today we use 8GB, 16GB and 32GB DIMMs. That gives us:

• 16GB (2x8)
• 32GB
• 64GB
• 128GB

But this article says support for “non-binary” DIMMs is coming soon, which means 24GB DIMMs and 48GB DIMMs! That enables:

• 48GB (2x24)
• 96GB (4x24) or (2x48)
• 192GB (4x48)

MSI & Gigabyte AMD AM5 Motherboards Shown To Be Running Non-Binary 24 GB & 48 GB DDR5-6400 Memory Perfectly

MSI & Gigabyte AMD AM5 motherboards are the latest to show support for non-binary 24 GB & 48 GB DDR5 memory kits.

wccftech.com

 

[mariettosun]

new latest beta bioses have given support of these new module and overall to achieve new high frequencies:

 

[CaseySJ]

new latest beta bioses have given support of these new module and overall to achieve new high frequencies:

That screenshot seems to be from this article.

Beta BIOS 1003 now available for Asus X670E Gene (and other boards):

 

[mariettosun]

• Tuesday at 5:02 PM

yes Casey, maybe you miss this
update went fine an d now it is possible to push at 4800 my ddr5 (four dimms)

 

[CaseySJ]

• Tuesday at 5:02 PM

yes Casey, maybe you miss this

I saw that post, but it seems I did not realize what it was about. I read "high density DDR5" but didn't know what it meant until I found the article in WCCFTECH this morning.

 

[mariettosun]

it is interesting motherboard manufacturers are adjusting stuff also for not EXPO DIMM
and in my case now, I am stable @4800 with all slots fulfilled
My System boots also @5000 but it is not stable
They added also a menu DOCP Tweaked
Before only manual
DOCP1
DOCP2
Also a thunderbolt bios firmware update in 1003 beta bios..but I can't see any improvements in things we miss (HotPlug)

 

[CaseySJ]

it is interesting motherboard manufacturers are adjusting stuff also for not EXPO DIMM
and in my case now, I am stable @4800 with all slots fulfilled
My System boots also @5000 but it is not stable
They added also a menu DOCP Tweaked
Before only manual
DOCP1
DOCP2
Also a thunderbolt bios firmware update in 1003 beta bios..but I can't see any improvements in things we miss (HotPlug)

Do you know the new Thunderbolt firmware version number (NVM number)? There have been many complaints about NVM 36 and newer. It seems Intel removed support for Thunderbolt 1 and Thunderbolt 2 devices from NVM36.

https://www.tonymacx86.com/threads/asus-z690-proart-creator-wifi-thunderbolt-4-i7-12700k-amd-rx-6800-xt.318311/page-293#post-2364496

 

[mariettosun]

Do you know the new Thunderbolt firmware version number (NVM number)? There have been many complaints about NVM 36 and newer. It seems Intel removed support for Thunderbolt 1 and Thunderbolt 2 devices from NVM36.

https://www.tonymacx86.com/threads/asus-z690-proart-creator-wifi-thunderbolt-4-i7-12700k-amd-rx-6800-xt.318311/page-293#post-2364496

I do not know how to check firmware version.. do you know how to check it in windows or in OSX?

 

[CaseySJ]

I do not know how to check firmware version.. do you know how to check it in windows or in OSX?

We can check quite easily in Linux. Here's what I get when running Ubuntu on my Asus X670E Gene with BIOS 0925:

$ cd /sys/bus/thunderbolt/devices/0-0/

$ ls
authorized  device  device_name  generation  nvm_active0  nvm_version  power  subsystem  uevent  unique_id  vendor  vendor_name  wakeup

$ cat nvm_version
34.0

We can see NVM 34.0.

We can also dump the Thunderbolt firmware using a command like this:

$ dd if=/sys/bus/thunderbolt/devices/0-0/nvm_active0/nvmem of=~/Documents/thunderboltFW.bin bs=256 count=256

Here's what that looks like:

In byte 0A we can see 34, which is NVM 34. The first section of bytes shown here is the Thunderbolt DROM. Notice the words ASUS ROG CROSSHAIR X670E GENE.