All Activity

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

I suggest to use the thread but It's up to you to decide. You not need to use the EFI just open the config 5450.plist then you will see what is need for the ATI 5450 Good luck to inject ATI 5450 with OC

Thank you for the quick diagnosis! No worries - I'll switch back to VoodooHDA.kext. Note that I did try renaming HDAS to HDEF after I saw the match in HDAUniversal's Info.plist, but that was not sufficient to load HDAUniversal. EDIT: @MaLd0n I played with this a little more and was able to get HDAUniversal to load, but it was intermittent. Sometimes it would load if I changed HDAUniversal's Info.plist (changing HDEF->HDAS and/or changing PCIClass) and sometimes it would load if I renamed ACPI HDAS->HDEF and/or change class-code. I couldn't figure out why it loaded some times and not others, but even when it did load, I still did not have audio. Based on your previous explanation, I think this is expected but I wanted to let you know in case it helps you. Thanks for your hard work on this.

@schrup21 I tweaked a bit my config.plist file removing a device property line "bcmc-srom-slide" that I defined as 00000000 and added the property "bcmc-disable-io-mapper" defined as 00000000 which is what you add. The computer now arrives at the desktop but frozen, which is different from what I was experiencing, as before the computer was freezing on a black screen that shows up after the Apple logo disappears. I verified again the boot args and device properties and nothing else has been messed AFAIK. wifi.log.zip

The device is exposed by firmware as HDAS with PCI class 040100, which means generic multimedia audio/SST-cAVS style, not classic HDA 040300. HDAUniversal currently matches only HDEF or real HDA class 040300, so it never reaches start() and cannot rename the device. We need controlled HDAS/040100 support with strong HDA validation, not a blind match, to avoid attaching to the wrong audio controller.