Contribute
Register

Is 500W enough for an AMD 6700XT GPU ?

@craighazan I would recommend you have a look at the following issues in your /EFI/OC folders.
  1. You have SSDT-HPET.aml in your ACPI folder but do not have the ACPI > Patches in your config.plist. So this SSDT will be doing nothing for your setup.
  2. You have SSDT-USB-Reset.aml, but probably don't need this for the two USB controllers in your AMD system. As this SSDT is primarily aimed at fixing USB issues in Intel Asus Z490 motherboards.
  3. I have added an extra SSDT, SSDT-SBUS-MCHC.aml to help with any components added to the system for my Asus B550 setup(s), so they work better in macOS.
    1. Have a read of this guide the SSDT and see if your system requires the SSDT.
    2. https://dortania.github.io/Getting-Started-With-ACPI/Universal/smbus.html
  4. Personally I use HfsPlus.efi in place of OpenHfsPlus.efi, as it is a faster and better HFS+ driver.
    1. This driver can be obtained from Acidanthera's OcBinaryData repository, in the Drivers folder. So you may already have the driver.
    2. https://github.com/acidanthera/OcBinaryData
  5. You don't need acpidump.efi in your Tools folder, but it won't be doing anything unless used from the OC boot screen, so can remain if you want.
Here are two screenshots, the first showing your EFI folder contents, the second showing the OC 0.9.4 EFI folder contents for my B550 TUF Gaming system.

Screenshot 2023-11-18 at 17.37.19.png Screenshot 2023-11-18 at 17.43.29.png

As you can see there are a few differences, with the issues listed above being the only ones that really matter. The kext differences are related to your use of an Intel WiFi/BT card in Sonoma while I am using a Broadcom WiFi/BT card in Ventura. I refuse to use the OCLP Root Patches, as I think this is poorly designed fix for the Broadcom WiFi issue. I also can still use NVMeFix.kext as it works in Ventura.

Regarding NootRX.kext (NRX) I am using a release from 25th October, as it is the most stable I have tried. Your NRX is dated 13th November. So that is probably the most telling difference in the EFI sub-folder contents as far as your RX 6700 XT issues.

@ExtremeXT stated that AMDRyzenCPUPowerManagement.kext could be problematic and lead to the CPU running hotter than necessary. I am going to remove this kext from my OC setup to see what difference it makes.

Something I noticed when testing an Intel AX210 WiFi/BT card was that the order in which the Bluetooth kext were injected/sorted in OC would give different results. Ordering them as shown below seemed to work best with my system.

Screenshot 2023-11-18 at 18.09.07.png

BlueToolFixup.kext seems to be often be injected second. If the kexts are not manually sorted so IntelBluetoothFirmware and IntelBTPatcher are before BlueToolFixup.kext.

We are both using Shaneee's PAT Fix in the AMD Kernel Patches, so that is good. It might be worth switching to the algrey patch, just to see if it makes any difference. But one change at a time. So we don't get mixed results.

Looking through your config.plist, I would make the following changes:
  1. Remove any redundant/unused entries so the config is easier to read and navigate.
  2. As you don't have a custom USBPorts.kext or USBMap.kextfor your system.
    1. would recommend enabling the Kernel > Quirks > XhciPortLimit patch, so all your USB ports work in Sonoma.
    2. Then using either Hackintool or Corpnewt's USBMap-Master python script to create a custom USB kext.
    3. As your system has 2 x USB controllers you should be able to activate all the USB ports in your setup.
  3. You have SecureBootModel Quirk set as Disabled. I have mine set as Default. This might make a difference to how your dGPU works in macOS. But shouldn't prevent it from booting.
  4. You have a different csr-active-config entry than I expected - <E7030000>, I have SIP fully enabled <00000000> with no issues.
  5. You are using iMacPro1,1 SMBIOS, I am using MacPro7,1 SMBIOS. I think the MacPro7,1 is a better fit for these AMD systems. This is one of the reasons I have SIP and SecureBootModel enabled/Default.
I have attached a revised EFI for you to test on your system, to see if it helps. Taking in to account of most of the items listed above.

Testing/Booting:
If you want to try this revised EFI, do the following:
  • Add your Serial Number, MLB, ROM and System UUID data to the revised config.plist.
  • Add the OC patches you generated using Corpnewt's SSDTTime script for your SSDT-HPET.aml table to the ACPI > Patch section, so the SSDT works.
Don't make any other changes to the setup.
  • Unless you want to generate a new SMBIOS (MacPro7,1) for your system.
  • Then and only then should you set Misc > Security > SecureBootModel to 'Default' and
  • csr-active-config to <00000000> (SIP enabled)
Copy the revised EFI folder to the EFI partition on a spare USB pen drive and boot from the pen drive to test the EFI.

Don't replace your current EFI until you are sure the revised EFI works and boots without any issues.

You will need to use the ResetNvramEntry.efi option before you boot with this revised OC setup.
  • Simply boot from the USB pen drive, press the Spacebar when you arrive on the OC boot screen (GUI),
    • This will unhide the tools and drivers contained in your OC setup.
  • Select the ResetNvramEntry.efi and the system should automatically reboot.
  • Select your USB pen drive from the system Boot Menu (F8) again, and
    • This time boot in to macOS Sonoma using the revised EFI.
See how it behaves, let me know if it throws up any issues.

The revised EFI folder looks like this:

Screenshot 2023-11-18 at 18.25.49.png Revised EFI folder contents.
 

Attachments

  • EFI.zip
    35.1 MB · Views: 10
@Edhawk

What can I say. A thorough break down of my rather messy EFI, I will go through these changes and report back tomorrow. Thank you.
 
Not a problem, hope this helps.
 
@Edhawk

How's Bertie?. Upon your recommendations I made the following changes to my config;
  1. Misc > Security > SecureBootModel > Default
  2. NVRAM > csr-active-config > <00000000>
  3. Switched SMBIOS to MacPro7,1
  4. Replaced OpenHfsPlus.efi with HfsPlus.efi
  5. Added patches for SSDT-HPET
Windows 11 still drops video when booting from OpenCore picker.
Update: Just installed Windows 11 Home edition on my 4700G system and Windows boots from OpeCore fine, doesn't drop video.

I have tried building SSDT-SBUS-MCHC.aml before, but my attempt wasn't very good, I'll revisit it again.

@ExtremeXT stated that AMDRyzenCPUPowerManagement.kext could be problematic and lead to the CPU running hotter than necessary. I am going to remove this kext from my OC setup to see what difference it makes.
I have read about this before on the NRed Github, the advice from VisualEhrmanntraut is to remove AMDRyzenCPUPowerManagement & SMCAMDProcessor kexts, needed by AMD Power Gadget. And replace it with SMCProcessorAMD, used by iStats, HWMonitorSMC2 and Macs Fan Control.

Benches are nice, Metal score on a MacPro7,1 SMBIOS is similar to the iMacPro1,1. That single core though!, I’ve never seen 2K before.

Screenshot 2023-11-19 at 8.12.51 AM.png
Screenshot 2023-11-19 at 7.34.21 AM.png
 

Attachments

  • config.plist.zip
    6.3 KB · Views: 7
Last edited:
  1. Do you have both the AMD IGPU and dGPU active in Windows & macOS?
    • If yes, try disabling the AMD IGPU, if one is present
    • The Ryzen 7 5700X doesn't have an IGPU, so if that is the CPU you are using forget about the IGPU.
  2. I have you disabled the AMD IGPU in the Bios, so only the dGPU is used in either OS (using Ryzen 5 5600G).
    • Because that is what the iMacPro1,1 and MacPro7,1 SMBIOS expects, not to have an IGPU available.
  3. Which display out connectors are you using with the RX 6700 XT, DP or HMDI?
  4. I am using the 2 x DP connectors and DP to DP cables to my dual displays.
    • Are you using two displays?
    • If yes, are they both using the same type of display out connector.
    • Are you using any adapters or cable adapters?
 
Try booting with the AlGrey AMD Kernel Patch in place of Shaneee's. See if that makes any difference.

I have changed patches 20 & 21 in the attached config.plist. But you can do the same with your current test EFI config, so you don't have to mess around adding the SMBIOS data again.

Other than this patch test everything looks good in your config.plist.
 

Attachments

  • config.plist.zip
    6.3 KB · Views: 5
@Edhawk
I couldn't find any graphics settings in my BIOS. I have two 27" monitors, the Dell is DP and the Hp is HDMI. I have tried with the ALGrey patch, same as before but now its repairing the disk with Windows.
 
OK, trying the AlGrey patch was a long shot.

But there is a chance of this being fixed by the Windows repair. Depends on what it ends up repairing! You may end up having to reinstall Windows, off the repair doesn't work.

There is nothing in your latest config.plist that would cause this issue.
 
OK, trying the AlGrey patch was a long shot.

But there is a chance of this being fixed by the Windows repair. Depends on what it ends up repairing! You may end up having to reinstall Windows, off the repair doesn't work.

There is nothing in your latest config.plist that would cause this issue.
I thinks it’s a disk issue. I clean installed a few days ago and the same issues are returning.
 
Could as easily be an issue with the M.2 connector.

You tried swapping the macOS and Windows drives (assuming they are both M.2 NVMe drives) from their current motherboard M.2 connector to the other. See what that does to them when you boot to OpenCore.

If the motherboard M.2 connector is suspect adding the Windows drive to a PCIe NVMe adapter might solve the issue. These PCIe adapters are fairly in expensive.

I have a couple of these GLOTRENDS PCIe adapters in use in a Skylake and a Kaby Lake Hack. No limitation on the speed of the drive from the adapter. If it is a Gen 3x4 or Gen 4x4 NVMe drive it works at the expected speed.

 
Back
Top