All Activity

I'm currently testing MaLd0n's new HDAUniversal.kext for audio in macOS Tahoe on our HP EliteDesk Minis. I think audio quality is outstanding. If you want to test, get the HDAUniversal installer from here and do the following: Remove your existing audio solution for macOS Tahoe (e.g., remove VoodooHDA.kext from /Library/Extensions) In your Open Core config.plist, set csr-active-config = <03000000> and reboot for the new SIP setting to take effect. If you already have csr-active-config set to something that's less restrictive than <03000000> (e.g., <03080000>) then you don't need to change SIP. Run the HDAUniversal installer and follow the prompts. Be sure to "Allow" HDAUniversal when prompted. After Restarting, you should have perfectly working audio. You may need to select the audio output (e.g., select 'Line Out' or 'Headphones') If you want more restrictive SIP, set csr-active-config = <01000000>. Just like VoodooHDA.kext, HDAUniversal needs SIP set to allow untrusted kexts since it is installed in /Library/Extensions.

I installed HDAUniversal on an HP EliteDesk 800 G4 Mini that I'm using for a multimedia system. The EliteDesk 800 G4 Mini has two audio outputs that I'm using to drive 1) main speakers and 2) a subwoofer. HDAUniversal is working perfectly with the Multi-Output Device that I created using macOS Tahoe's Audio MIDI Setup. Sound quality is outstanding. 🎶

@Slice The network configuration is bound to the system definition in the same way, as the USB port mapping.

@Slice I know you're a big fan of AI 🤣 .... Seriously, though - this might be a good question for ChatGPT. Some of the response doesn't make sense, but some of may offer a clue. If you're running a Hackintosh/OpenCore on macOS Tahoe 26.5.2 and the only variable is the SMBIOS (MacPro7,1 vs iMac20,1), then the Realtek controller itself is probably not the root cause. The SMBIOS changes how macOS configures several networking and security features. Here are the most likely explanations, roughly in order of probability: 1. Ethernet interface gets recreated or renamed - Booting with a different SMBIOS can cause macOS to treat the NIC as a different device. - Check: ifconfig networksetup -listallhardwareports - See whether the Ethernet interface is still en0 or became en1, or disappeared entirely. 2. Ethernet driver initialization timing - If you're using RealtekRTL8111.kext (Mieze) or LucyRTL8125Ethernet.kext, initialization timing may differ between SMBIOSes. - Look in: log show --last boot | grep -i RTL log show --last boot | grep -i ethernet - Also verify that the driver actually attached: kextstat | grep RTL or on newer macOS: kmutil showloaded | grep RTL 3. Different DeviceProperties or ACPI paths - Some OpenCore configurations inject properties conditionally depending on SMBIOS. - Compare: - DeviceProperties - ACPI patches - Kernel -> Add - Make sure nothing is enabled only for iMac20,1. 4. Network service order corruption macOS stores network configuration separately. Try backing up and deleting: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist Then reboot so macOS recreates them. 5. MacPro7,1-specific networking behavior MacPro7,1 expects workstation-class hardware and may enable features not present on consumer boards. Rarely this affects: - Wake-on-LAN - Energy Efficient Ethernet - PCIe ASPM A Realtek driver may not handle one of these correctly. 6. Different kernel cache or loaded extensions Verify that exactly the same kexts are loaded under both SMBIOSes: kmutil showloaded Compare the output between MacPro7,1 and iMac20,1. -------------------------------------------------- Information that would be most useful -------------------------------------------------- Boot using MacPro7,1 (where networking fails) and run: ifconfig networksetup -listallhardwareports kmutil showloaded | grep -i rtl log show --last boot --predicate 'subsystem CONTAINS "network"' --style compact or simply: log show --last boot | grep -i RTL Also provide: - Which Ethernet kext are you using? - RealtekRTL8111.kext? - LucyRTL8125Ethernet.kext? - Something else? - OpenCore version. - Motherboard model. - Does the Ethernet interface appear but have no IP address? - Or is the Ethernet interface completely missing? One additional question: When you say "lose internet," which of these best describes the problem? 1. The Ethernet interface is missing. 2. The Ethernet cable shows as unplugged. 3. Ethernet connects and gets an IP address, but nothing can reach the Internet. 4. Local network works but DNS or web browsing fails. That distinction will narrow the cause significantly. One thing I'd add based on experience with recent Hackintosh setups: if the only change is SMBIOS and the problem is 100% reproducible, I'd also compare the IORegistry between the two boots (IORegistryExplorer or ioreg -l) to see whether the Realtek PCI device receives different properties. That's one of the quickest ways to determine whether the issue lies in OpenCore's device injection versus the network driver itself.

I encountered a strange situation: 1. Booted as MacPro7,1 I loose internet. Reboot - the same. 2. Reboot as iMac20,1 I got all working Tahoe 26.5.2. Realtek8111H Why it may happens?

Clover 5173

I have an old PC with a Z390 motherboard and an NVIDIA GTX 1070. I was thinking about installing High Sierra because I don't want to spend money on a nostalgia box. I also have no interest in running newer versions of macOS, especially since they no longer support many older applications. Ideally, I'd run Leopard or Snow Leopard, but I don't have compatible hardware, and as I said, I don't want to spend money just for nostalgia. I managed to put together a reasonably decent OpenCore configuration but the installation always fails. Then I found out elsewhere that the Recovery images downloaded under Windows are basically useless—they simply don't work because of disabled servers. I also ran into an issue when trying to install High Sierra on a drive where the second partition is already occupied by Windows. From what I've read, this seems to be a limitation of the Recovery installer only, which would make sense since Recovery is intended to restore the system from the original macOS installation image (so without any other OS). So I installed Catalina in VMware and downloaded the full High Sierra installer from within macOS instead. Same story again: most of the servers and download commands for older installers no longer work, and when I finally managed to download the installer, the createinstallmedia command that was supposed to prepare the USB drive crashed after running for a while and eventually returned an error. After several attempts, I finally managed to download the full installer to the Applications folder and create a bootable USB installer. The USB drive is split into two partitions: a FAT32 EFI partition and an HFS+ partition containing the macOS installer (as an .app bundle) along with a few other files. I copied my OpenCore configuration to the EFI partition—the same one that previously allowed me to boot Recovery. However, now when I select the macOS installer from the OpenCore boot picker, the PC simply reboots and boots into Windows. It seems to me that OpenCore is unable to locate or launch the macOS installer. Previously the same EFI config worked fine with MacOS recovery image. I configured the EFI folder and config.plist under Windows, initially planning to use a Recovery image. After running into problems with Recovery, I downloaded the full macOS installer instead. The problem is that the file layout is different between the two methods. When creating a Recovery USB under Windows, the EFI folder is placed on the same partition as the macOS Recovery DMG. With the full installer created under macOS, however, the EFI folder is on the FAT32 EFI partition, while the installer itself is located on a separate HFS+ partition. Could this be the reason the installer won't boot? Is it possible that OpenCore simply has no idea where to find it? Please help.

@schrup21 I reverted to the Lilu kext version 1.7.2 released in March and no more issues, wifi back working. I was loading a Lilu kext version I downloaded from the Dortania build repo that is not really compatible with the AppleBCMWLANCompanion.kext.

Hi all Devs Try to use gcc16.1 But I can't build Clover with these settings and Default Toolchian GCC161: build error 4000 gcc161 not defined etc. if [[ $MYTOOLCHAIN == GCC* ]] && [[ ! -x "${GCC161_BIN}" ]]; then if [[ $MYTOOLCHAIN == GCC161 ]]; then cd "${CLOVERROOT}" ./build_gcc16.sh else MYTOOLCHAIN=XCODE16 fi fi I take a look at the repo and see : if [[ $MYTOOLCHAIN == GCC* ]] && [[ ! -x "${GCC152_BIN}" ]]; then if [[ $MYTOOLCHAIN == GCC152 ]]; then cd "${CLOVERROOT}" ./build_gcc16.sh else MYTOOLCHAIN=XCODE16 fi fi I can't build too if Default ToolChain is GCC161. I don't understand why Default ToolChain must be GCC152 !!! So Buildme use gcc152 parameters instead of gcc161 :

@Zevgoli I don't use revpatch in boot-args (I insert revpatch in NVRAM > Add > 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102), so I don't know the boot-arg syntax, but I'm suspicious of having two revpatch= statements in boot-args. The syntax that I know is revpatch=arg1,arg2 (the revpatch arguments are comma delimited). Also, depending on which macOS you're running, I don't think that amfi_get_out_of_my_way=1 works any more. I don't think you should be using it at all (I'd prefer using AMFIPass.kext if you're using it for OCLP), but that's just my preference. If you actually need it, then you probably should be using amfi=0x80 instead. Whenever you're asking questions about your config.plist, it's best to post the entire config.plist.

You all know the hassles Ive been having updating from one version to another. I was thinking could it be a boot arg that is causing the problem? Here are the ones I am currently using: -igfxvesa revpatch=sbvmm -btlfxboardid brcmfx-country=#a revpatch=auto npci=0x2000 amfi_get_out_of_my_way=1 Are there any here that might be a red flag to anyone? Thanks for any help. Cheers, Howard

Now that HDAUniversal is working well on my HP EliteBook 850 G7 laptop with MaLd0n's updated version here, I removed boot-arg alcid and kept only DeviceProperty layout-id. HDAUniversal continues to work fine with this configuration. EDIT: The same audio DeviceProperties are working fine with AppleALC (macOS up to Sequoia), VoodooHDA 4.0 (macOS Tahoe) and HDAUniversal (macOS Tahoe). EDIT2: Interesting... HDAUniversal does not appear in Hackintool's Extensions list. I never thought about it, but I guess Hackintool displays only Extensions that it knows.

I now have HDAUniversal working well on my HP EliteBook 850 G7 laptop in one Tahoe test Volume thanks to MaLd0n's updated kext here. I will maintain two Tahoe test volumes so that I can continue to experiment with both VoodooHDA and HDAUniversal. If either solution eventually enables Intel iGPU HDMI, that would be awesome, but for now, both solutions are outstanding. Thank you Slice and MaLd0n and any other Devs helping behind the scenes.

The problem was that the app was not always using the real hardware codec ID as the primary source. Check if work now. https://limewire.com/d/66w2b#nORvVw48bi Good to know

@MaLd0n Well done! Internal Intel HD audio is now working on my HP EliteBook 850 G7 laptop with your latest HDAUniversal!!! 🙌🙌 And you are correct, with your latest HDAUniversal.kext, HDAS is renamed to HDEF, so Codec-Info detects my audio without SSDT-HDAS. Nice work!!! ... and audio quality is outstanding! Menu Bar Codec-Info EDIT: I installed HDAUniversal with SIP csr-active-config = <03000000>. After installation, I restricted SIP with csr-active-config = <01000000>. All working well.

HDAUniversal-Release.zip Test this. Added a new personality for IOPCIClassMatch 0x04010000&0xffff0000. Remove SSDT HDAS, u dont need it, kext rename audio device. I'l check it

@MaLd0n I have an issue with codce-info, just in case you want to check in. This is Sonoma with AppleALC. No root patches. I'm sure that my onboard code is ALC1220. It's what I see in IOReg, Hackintool and ATH. But codec-info says that my codec is ALC897. Attached the logs. Maybe I am wrong and codec-info is intended to be used only with HDAUniversal. HDAUniversal-Test-Logs-2026-07-03_13-45-01.zip

@luxinhaus Only for onboard sound for now

Anyone got Intel HD630 HDMI audio working? AppleALC works with layout 11 but not with HDAUniversal. Tried all available layouts

New version 4.5.3 Fixes a bug where changing macOS version on the Firmwares tab did not reload the installers list with the same macOS Added macOS 14.0 UI fixes Version bump from to 4.5.3 (build 253) https://github.com/perez987/DownloadFullInstaller/releases/tag/4.5.3

Sonoma end of life will be sooner than for Tahoe.

I still have sonoma as well on one of my backup disk. I just don't bother to update it to Tahoe. 😅

but is AppleVTD activated? (it should, because I guess it would cause a KP otherwise) I've only added the mandatory properties according the documentation: disable-io-mapper, firmware-hash, firmware-path and srom-slide (the last would only be required for 4350 chips but doesn't hurt) you can verify if the kext is loaded with kextstat + you can grep the bcmc related log entries using dmesg (Acidanthera's debug enhancer is required for dmesg) kextstat | grep bcmc sudo dmesg | grep bcm