Need assistance adapting EFI for macOS Tahoe (Ryzen 9 7950X3D + RX 6900 XT)

hinkin

Member
AMD OS X Member
Jan 4, 2025
62
8
8
CPU:
AMD Ryzon 9 7950X3D
Hi everyone,

I’ve been trying for several days to get my EFI configuration working for macOS Tahoe on my system, but I haven’t had any success so far.

Hardware Configuration​

  • CPU: AMD Ryzen 9 7950X3D
  • Motherboard: Gigabyte X870 AORUS ELITE WIFI7
  • RAM: 64GB DDR5 5000MHz
  • GPU: AMD Radeon RX 6900 XT 16GB
  • Network: Realtek RTL8125B
  • Wi-Fi/Bluetooth: Fenvi T919 PCIe WLAN Card

I currently have a fully working EFI for macOS Sequoia, but I need assistance in adapting or fixing it so that it can properly install and run macOS Tahoe on this setup.
I’m sharing my current EFI folder for anyone interested in helping improve or create a Tahoe-compatible version.

Any help or suggestions would be greatly appreciated.

Thank you in advance!
 

Attachments

Absolutely not, after you explained to me I needed to change my gpu, I sold it and got the Radeon RX 6800 xt, which actually allowed simplify to create an EFI folder. Yes I still use the same motherboard and cpu. This is new to me, I am learning as I go along. I am not aware of any proper mimo whitelisting needed for my motherboard.
 
Looking at the contents of your EFI/OC/Kexts folder I would comment as follows:
  1. The version of WhateverGreen.kext you are using (v1.7.1) isn't compatible with Tahoe.
    1. You need to be using version 1.7.1d7 for Tahoe as the other version from Acidanthera isn't working correctly in Tahoe.
Swapping the WhateverGreen kext for the supported forked version is simple, see the attached kext.

UTBMap.kext & USBToolBox.kext you are using aren't compatible with macOS Tahoe.
  1. UTBMap.kext lacks the new USB port and port name requirements for Tahoe.
  2. You need to be using a USBMap.kext from Corpnewt's USBMap script, or as a last resort a USBPorts.kext from Hackintool v4.1.4 or newer.
  3. Both of these USB tools can be used to convert your current USB configuration to a supported version.
  4. But your UTBMap.kext is incorrect for your motherboard, so I wouldn't bother.
    1. You are missing a whole load of ports, spread over the 2 x USB controllers currently shown as being available.
    2. You should never have any USB3 (SS01, SS02, SS03 etc.) ports set with connector type Internal (255).
    3. They should always be set as USB3 (3) no matter if they are served from a motherboard header or physical port on the rear I/O plate.
    4. Same goes for the virtual USB2 ports served from a USB3 connector, they should always match the companion port, I.e. USB3 (3).
    5. Screenshot 2026-05-27 at 14.30.17.png View of the Info.plist from your UTBMap.kext, as seen in ProperTree.
The prohibited sign you are seeing is I believe solely related to your poor USB configuration. If it worked in a previous version of macOS you were just lucky, as it is so far away from the actual port configuration for your motherboard as to be nearly useless.

These are the USB ports available from your motherboard.

Rear USB (Total 12 ports)
  • 2 x USB4® (40Gbps) ports(2 x USB Type-C® with DP Alt mode)
  • 6 x USB3.1 10Gbps ports (5 x Type-A + 1 x USB Type-C® with up to 30W PD Fast-charge)
  • 4 x USB3 5Gbps ports (4 x Type-A)
Front/Internal USB (Total 10 ports)
  • 1 x USB 20Gbps Type-E motherboard header/connector (supports USB Type-C®)
  • 2 x USB3 5Gbps headers support 4 additional USB3 5Gbps ports (total of 8 x ports available)
  • 2 x USB 2.0 headers support 4 additional USB 2.0 ports
  • 1 x USB2.0/1.1 port served from the Wifi/BT M.2 connector.
Based on the above lists
  1. You should not have any ports set as USB2.0 (0).
  2. You should have a maximum of 5 x ports set as Internal (255), the 4 x header ports plus the USB port served from the M.2 WiFi/BT connector.
  3. You can have 12 x physical USB3 ports, physical ports and header ports set with connector type USB3 (3).
  4. You can have 12 x Virtual USB2 ports, served from USB3 physical & Header ports and set with connector type USB3 (3).
  5. The 4 x Type-C ports & header need to be discovered before it is known if they are a Type-c+sw (9) or Type-c (10) without switch port.
  6. The 4 x Type-C ports will support a matching number of virtual USB2 ports, these should be set to match the port type discovered for the main physical Type-C port.
Actions going forward:
I would recommend you delete your current UTBMap.kext and create a USBMap.kext, assuming you can boot in to macOS Sonoma or Sequoia with your current setup. If you get stuck with the USB port configuration and port discovery, let us know and we see if we can help. But ask for help in a new thread.

These are the guidelines I use when undertaking a USBMap configuration on any of my Hacks.

Each USB controller present in your AMD system can support/activate a maximum of 15 x ports. That is each controller can support/activate 15 x ports. it is not an accumulation of all the ports across all the controllers. AMD systems often have 2 or 3 x USB controllers present, for example my X570-F system has 3 x USB controllers with a total of 28 x USB ports active and fully supported in macOS (Catalina up to and including Tahoe).

Screenshot 2026-05-27 at 15.10.20.png example of USBMap.kext ports across 3 x USB controllers (shown in Hackintool for simplicity).

Note that I use the comments/Nickname option for each port I discover and activate. This makes it much easier to see if the wrong connector has been applied. Although Hackintool often messes up a perfectly good USBMap configuration without any help from the User.

This is because Hackintool's USB support is primarily aimed at Intel systems, which don't often have more than the XHC USB controller present. If they do it is normally a controller for the Thunderbolt/USB4 ports.

When discovering the ports in your system, follow these basic guidelines.

USB2 (0) - Physical USB2 ports on rear I/O plate, these ports always have a Black coloured tang.
These are the only ports that should be set as USB2 (0)​

USB3 (3) - Physical USB3 ports on rear I/O plate, these ports can have a Red, Blue, Yellow or Cyan coloured tang, should be set with connector type USB3 (3).
Virtual USB2 ports - served from physical USB3 ports should be set the same as the physical port, i.e. USB3 (3).​

USB3 (3) - Motherboard Header, usually serving the case front USB3 ports, should be set with connector type USB3 (3).
Virtual USB2 ports - served from case front USB3 ports should be set the same as the physical port, i.e. USB3 (3).​

Internal (255) - Motherboard USB2 header, this will be any device served from a USB2 header port, such as Bluetooth module, case front USB2 ports, case front card reader etc.

Internal (255) - Built-in M.2 WiFi/BT connector, motherboard LEDs and CPU Cooler USB connection.

Testing Type-C ports requires an extra step.
  • When the Type-C device is inserted in to the port being discovered a specific port will be highlighted, you need to note this port number.
  • Remove the Type-C device, flip it 180° and reinsert it in to the same port.
    • If the same port number is highlighted, then this is a Type-C with Switch port (9).
    • If a different port number is highlighted, then this is a Type-C port without a switch (10).
Type-c+sw (9) - will only show two ports being available, 1 x Physical Type-C and 1 x virtual USB2 port.

Type-c (10) - will show 4 x ports being available, 2 x Type-C and 2 x virtual USB2 ports.

You won't fix the prohibited sign issue until you correctly configure the USB ports for your X870 system, simples!
 

Attachments

Im following everything u said to do. Can you tell me what this means, OCS: No schema for HideVerbose at 3 index, context <Drivers>!
 
It means that the HideVerbose entry has nothing declared in your OC config.plist for the forth driver in the list (list of drivers starts at 0).
 
Yes, it matters what you use for installation and how the installer was created. I assume it is a USB device of some sort or other.

What are you using?

Ideally for Tahoe it would be a 32GB or 64GB USB pen drive, formatted as HFS+/GUID, with a single (HFS+) partition and a hidden EFI partition. Assuming you have access to another Mac or Hack.

If you are using an over large storage device, i.e. 1TB SSD/HDD/NVME, then I would recommend setting the macOS installation partition at a maximum size of 32GB or 64GB and see if that helps with your installers progress.

The screen above, does this show and stall after the Verbose text has completed, i.e. is part of the second phase of the installation process, when macOS is trying to initialise all the components/devices in your setup.
 
Installing macOS to an external drive is fine. I have done this many times without issue, usually when I want to use the external drive in another system.
  1. How are you formatting the 64GB drive?
  2. Are you using macOS, Linux or Windows to create the installer?
  3. It could be that the installation media you are using to create the installer is borked and simply won't complete the installation. This is not as uncommon as you might think.
  4. You may need to delete the macOS installation folder you previously downloaded.
  5. Download a new version of the installation media and recreate your 64GB USB pen drive.
    1. Your OC setup gets you to this stage, past the verbose text stage yes? That being the case it is less likely to be an issue with the OC EFI than it is the actual installation media.
  6. How long are you leaving the system to run while it shows this screen?
  7. Is there any activity on the HDD LED showing something is happening in the background?
  8. AMD systems are notorious for having long pauses during the installation of macOS, with no obvious reason for the delay.
 
1. I first tried rufus the EFI and recovery image, now I am trying balena ecther with EFI and raw file. 2. I am using Windows to create the installer. 6. I dont let it run now longer than maybe 20 minutes after the pause state. 7. Since I tried the pen now I dont see any activity persisting.
 
Just out of curiosity can you leave it in the 'Paused' state for an hour. Just incase it is doing something in the background that is taking longer than it should.
 
@PYLZNER which EFI/config.plist are you using?
do you have only a GPU on board now?
Have you disabled the iGPU from bios or via others method?
HAve you tested without /with whatevergreen kext?
Have you mapped properly for tahoe your USB as suggested above?
 
is it a full installer you did or a recovery installer?
if recovery installer, are you sure your ethernet wifi is working to download os?
sometime it could be a very long time to wait
 
same image.
could you test these two config.plist?

with the EFI you use to see that apple hang :)
if possible answer also to my other questions please!
 

Attachments

  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.