All Activity

thanks @MaLd0n so, does this mean that I need to boot with SIP=03000000 to install it, right? And once installed, can I change it to 01000000 (allows untrusted kexts)?

We need a CSR value different from 00000000 because 00000000 means SIP is fully enabled, which can block development or unsigned kexts before the Security/Privacy approval prompt appears. 00000000 = SIP fully enabled. 01000000 = allows untrusted kexts. 03000000 = untrusted kexts + unrestricted filesystem. 03020000 = untrusted kexts + unrestricted filesystem + unapproved kexts. 030A0000 = untrusted kexts + unrestricted filesystem + unapproved kexts + unauthenticated root. FF0F0000 = almost everything allowed in the classic CSR bits. This kext is specific for Tahoe, old system i'm using AppleAlc or VoodooHDA.

Small update! Just added a Windows 11 + MyDockFinder showcase to the Tahoe Drive Icons Pack. Although the project primarily targets macOS, the included high-resolution PNG assets can also be converted into Windows .ico files, making it possible to create a surprisingly authentic macOS-inspired desktop environment under Windows 11. The README and Post #1 have both been updated accordingly. Enjoy!

@MaLd0n Great Job!

@MakAsrock Thanks for the feedback!

Did you make release for Old mac 10.6 to Catalina?

@MaLd0n great development. I would like to test it. Is there a need to partially disable SIP when installing for the first time like with VoodooHDA? If yes, what is the csr value to define in config file for installation? Can we change SIP to 01000000 after installation like with VoodooHDA? Or there is no need to tweak SIP?

Working on HP Prodesk 600 G1 Thanks dear freind

Tested HDAUniversal on my Hackintosh and it works perfectly Thanks @MaLd0n

Tahoe, aggregate sound: works OK. Good job! 👏

Clover 520x soon A major modernization goal for Clover is full AMD platform support, from Ryzen and Threadripper to EPYC and future AMD generations. Clover should be able to handle AMD-specific macOS boot requirements more cleanly, including kernel patch handling, CPUID compatibility, SMBIOS adaptation, PCI device preparation and stable boot behavior, while still keeping every option controlled by config.plist. Another important goal is to make Clover capable of managing the common ACPI fixes selected by the user, reducing the need for separate manual SSDTs on most chipsets. Clover should not blindly apply ACPI changes by itself. The user still enables the desired fixes in config.plist, and Clover then performs the selected work dynamically and safely according to the real firmware ACPI layout. This means that when the user enables fixes such as EC, USBX, PLUG/plugin-type, PMCR, RTC, AWAC, HPET, IRQ fixes, NVMe injection, USB power properties or _DSM collision handling, Clover should detect the correct ACPI scope, PCI root, bridge and device path instead of relying on fixed names like PCI0, PC00 or PC02. The objective is not to remove user control. The objective is to remove the need for hand-made SSDTs for common fixes. Clover should provide selectable ACPI fixes that work across many Intel and AMD chipsets by detecting where the patch belongs, avoiding duplicate devices, preserving valid firmware devices and renaming only target-device _DSM methods when required. With this approach, Clover becomes more powerful and easier to maintain. Most users can rely on Clover’s built-in selectable ACPI fixes instead of manually creating SSDTs for every board, while advanced users still remain free to disable Clover fixes and use custom SSDTs when they need full manual control.

@MaLd0n This is exciting! I'm looking forward to testing!

@izzat It's best to post your EFI (at least your config.plist) when asking questions like this. Re-read these instructions carefully to learn about modifying your display properties for DP. Starting with macOS Tahoe, audio requires either VoodooHDA.kext (what I use and have documented in this thread) or OCLP.

HDAUniversal is a modern AppleHDA-like audio kernel extension for macOS and Hackintosh systems, created to deliver clean, stable, and natural onboard audio with a behavior closer to Apple’s native audio stack. This release represents an important milestone for the project. After extensive development, testing, debugging, and fine tuning across desktop and laptop configurations, HDAUniversal now provides a solid AppleHDA-like foundation with native-style volume handling, reliable output routing, combo-jack support, and compatibility with AppleALC-style layout IDs. The goal has always been clear: make audio feel native, predictable, and stable on supported Hackintosh systems. Donations help keep the project alive, supporting development time, testing hardware, hosting, maintenance, and future improvements. If HDAUniversal helps your system, consider supporting the work so the project can continue growing. Link HERE A New AppleHDA-like Audio Solution HDAUniversal was designed with a strong focus on native macOS behavior. Instead of relying on artificial volume tricks or unstable routing workarounds, the kext follows a cleaner AppleHDA-like approach for codec initialization, output selection, mute handling, and endpoint switching. The current release includes support for: Internal Speakers Headphones Line-out Internal Microphone Headset Microphone Laptop combo-jack detection Desktop non-combo audio paths AppleHDA-like selector/source behavior Stable speaker/headphone switching Correct headset microphone handling Native-style output volume Proper mute and unmute lifecycle Clean Power/EAPD restore order This release is the result of careful iteration and real-world testing, with each change validated to avoid regressions in volume, routing, combo-jack behavior, or system stability. Installation 1- Remove VoodooHDA, AppleAlc or other and inject bootarg alcid=xx or Device Properties. Check Instructions HERE 2- Run the .pkg installer, then open System Settings > Privacy & Security and allow the HDAUniversal kernel extension if macOS asks for permission. Example: In my ALC897 i'm using alcid=98 and HDAUniversal.kext, only it. Why HDAUniversal Must Be Installed in /Library/Extensions HDAUniversal is designed to work as a system-installed macOS audio kext, not as a simple bootloader-injected kext. For this first release, the correct and supported installation path is: /Library/Extensions/HDAUniversal.kext This requirement is intentional. Unlike small helper kexts that can usually be injected from EFI, HDAUniversal publishes real IOAudio devices, IOAudio engines, selectors, controls, volume ranges, mute controls, input/output sources, and AppleHDA-like audio endpoints. These objects are used not only by the kernel, but also by macOS user-space audio services such as CoreAudio, Sound Settings, Audio MIDI Setup, Control Center, and coreaudiod. Installing the kext in /Library/Extensions gives macOS a proper on-disk bundle with the expected structure, metadata, permissions, cache handling, and resource visibility. This is important for stable audio registration, correct IOAudio behavior, system audio discovery, sleep/wake lifecycle, and future localization or UI-related metadata. Loading HDAUniversal only from EFI may load the binary, but it can produce incomplete or inconsistent behavior because macOS may not treat the kext as a fully installed audio bundle. In that case, CoreAudio and the system UI may not reliably see all metadata, resources, localized names, or audio endpoint information the same way they do when the kext is installed properly in /Library/Extensions. For this reason, EFI injection is not supported for the first public release. Supported Installation Method Install HDAUniversal here: /Library/Extensions/HDAUniversal.kext Then rebuild the kext cache / kernel collection and reboot. Not Supported EFI/OC/Kexts/HDAUniversal.kext EFI/CLOVER/kexts/Other/HDAUniversal.kext Temporary manual loading Mixed copies in EFI and /Library/Extensions Only one copy of HDAUniversal should be present on the system. Multiple copies can cause duplicate matching, wrong versions being loaded, broken audio registration, or inconsistent behavior after reboot or sleep/wake. This approach keeps HDAUniversal closer to the way a real macOS audio driver is expected to live in the system and helps provide the most stable AppleHDA-like experience. Compatible with AppleALC-style Layout IDs HDAUniversal works with the same layout-id concept used by AppleALC, making it familiar and practical for Hackintosh users who already understand AppleALC layouts. This allows users to test audio using known layout IDs while HDAUniversal provides its own AppleHDA-like engine, routing logic, and runtime behavior. The layout-based approach makes the kext easier to configure, easier to compare, and easier to integrate into existing Hackintosh setups. Native Volume Philosophy One of the main goals of HDAUniversal is to provide a correct and natural volume experience. The output volume model is designed around real codec capabilities and AppleHDA-like behavior: Output volume reaches 0 dB No positive output boost is used No artificial -dB cap is applied No defensive volume lock is used Volume range follows real AmpCaps Mute is handled independently from logical volume Volume 0 provides real silence Unmute restores the previous logical volume This avoids common issues such as distorted sound, excessive loudness, broken volume steps, mute getting stuck, or inconsistent speaker/headphone volume behavior. Combo-Jack Support Combo-jack support is one of the strongest points of this release. HDAUniversal now supports AppleHDA-like endpoint behavior for laptops with shared headphone/headset microphone jacks. When a headset is connected, the kext can switch the output source to Headphones and the input source to Headset Microphone. When removed, it can safely return to Internal Speakers and Internal Microphone. This behavior was carefully tuned to preserve desktop non-combo systems while improving laptop combo-jack handling. Built for Stability and Real Hardware Testing HDAUniversal has been developed with stability as a priority. Every major stage of the project focused on avoiding regressions, protecting working audio paths, and keeping the kext predictable under real macOS usage. The release was fine tuned around: Boot stability Runtime audio stability Speaker/headphone separation Combo-jack switching Headset microphone detection Mute/unmute behavior Sleep/wake restore order Output volume correctness Avoiding artificial boost and distortion Keeping validated code paths intact This is not just a feature update. It is a carefully tested release built around practical Hackintosh audio behavior. Download HDA-Universal HERE Credits and Acknowledgements HDAUniversal exists because of years of work from Apple, open-source developers, and the Hackintosh audio community. Special thanks to Fabiano and Mirone Credits: Apple For the original AppleHDA architecture, macOS audio stack, IOAudioFamily, codec handling concepts, and the native behavior that inspired the AppleHDA-like design goals of this project. AppleALC For the layout-id ecosystem, codec research, audio patching knowledge, layout data, and years of Hackintosh audio development that helped define how modern macOS audio should be configured on non-Apple hardware. HDAUniversal follows the same layout-id concept familiar to AppleALC users, making testing and configuration easier for the community. VoodooHDA For its long history as one of the most important open-source Hackintosh audio projects, providing valuable knowledge about HDA codecs, routing, mixer handling, and alternative audio implementation strategies. The Hackintosh Community For continuous testing, codec dumps, bug reports, layout experiments, logs, real hardware validation, and years of shared knowledge that make projects like this possible. Olarila For development, testing, debugging, validation, and maintaining tools, guides, patches, and resources for the Hackintosh community. Project development by Daniel Maldonado / MaLd0n - Olarila.com. Disclaimer HDAUniversal is an independent project. It is not affiliated with, endorsed by, or sponsored by Apple, AppleALC, VoodooHDA, or any hardware vendor. Apple, macOS, AppleHDA, and related names are trademarks of Apple Inc. AppleALC and VoodooHDA are separate projects with their own authors, licenses, and development history. Full respect and credit belong to their respective developers and contributors. Reporting Issues If you find a problem with HDAUniversal, please report it with proper logs. Before posting, run the included log collector: Collect-HDAUniversal.command Download HERE This script collects the information needed to understand what is happening on your system, including codec data, IORegistry audio devices, IOAudio engines, CoreAudio state, loaded kexts, system audio information, and relevant HDAUniversal logs. When reporting an issue, please include: 1. The zip generated by Collect-HDAUniversal.command 2. Your codec model 3. Your layout-id 4. macOS version 5. Bootloader used 6. Whether the kext is installed in /Library/Extensions 7. A clear description of the problem 8. Steps to reproduce the issue Please avoid reports without logs. Messages such as “audio does not work” or “headphones are broken” are not enough to debug the problem. Useful examples: - Internal speakers work, but headphones do not switch after plug/unplug. - Headset microphone is not detected on a combo-jack laptop. - Audio works after boot, but not after sleep/wake. - Volume is too low or too high compared to AppleHDA. - The wrong input or output source is selected. For best results, reproduce the problem first, then run Collect-HDAUniversal.command immediately after the issue happens. This gives the log collector a better chance of capturing the real failure. Reports with complete logs are much easier to analyze and help improve HDAUniversal for more codecs, layouts, laptops, and desktop systems.

But how did you install for example macOS 15 on Core2Duo system? If it somehow possible. Moreover Inspiron 1520 has 2gb memory which is not enough for systems 10.8 and later.

I upgrade to Tahoe and use the fi from the 1st page. however after do the fresh upgrade, the display is not working, I have to pull out and reconnect again to have a display (im using 2 display via DP) and sound is not working. do you guys have in mind what is actually wrong with the EFI. I forget to backup the previous EFI, my bad

Got around to testing it. My Asrock-Z690-PG-Riptide-hackintosh, Wi-Fi / BT: BCM94360 PCI-E adapter, Clover revision: 5172 (HEAD, commit 79c169ea9) / macOS 26.5.1 (25F80) worked fine. Great work @Mirone. 🤝

Problem with random wake was with Sequoia 15.7.8 24G809 Beta. With regular 15.7.7 24G720 everything is fully functional as in final Ventura. I will check in future possible power events. Great work @Mirone.

Hi, i tested this NOAVX version on MacBook Pro RX 560. Both models the small 4B one and the lmma8B failed - after much longer run compared to the v .42 version. All normal versions never failed. qwen3 4B Q4_K - Medium | 2.32 GiB | 4.02 B | MTL,BLAS | 6 | 1 | 0 | pp512 | 71.90 ± 0.25 | test_gen: failed to decode generation batch, res = -3 llama_bench: error: failed to run gen For me that's no problem that your app maybe need really a minimum of an RX 5600XT - they are now , buyer used, not. more expensive. That non AVX2 cpus fail or RX 560/RX580 mama probs should not give you sleepless nights! Even they would run - they will be (useless) slow for that kind of KI GPU tasks - I think. I will upload missed RX 5600 XT test with that NONAVX and normal v .42 version later.

[Info] Fixing Slow POST and Boot Loop issues after Shutdown/Reboot (macOS 11+) some ACPI/DSDT fixes regarding shutdown, reboot, and POST issues that occur on macOS 11 (Big Sur) and later. 1. Fixing Extremely Slow POST after Shutdown In macOS 11 and later, there is a known issue where the POST process becomes extremely slow when powering on the machine after a proper shutdown. This can be bypassed by modifying the ACPI RTC device as follows (adjusting the IO length/alignment): Before: Device (RTC) { Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */) // _HID: Hardware ID Name (RT, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x10, // Alignment 0x02, // Length ) IO (Decode16, 0x0072, // Range Minimum 0x0072, // Range Maximum 0x02, // Alignment 0x06, // Length ) }) Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (RT) } } After: Device (RTC) { Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */) // _HID: Hardware ID Name (RT, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x02, // Length ) }) Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (RT) } } 2. Fixing Boot Loops / Multiple Restarts Before OpenCore Loads Another common symptom is when the machine is powered on after a shutdown or reboot, it repeatedly restarts a few times right before OpenCore manages to load. This is likely caused by certain power/sleep states not being cleared properly during the shutdown or reboot sequence. To prevent this, you can define the following operation regions and fields, and explicitly clear the statuses in _PTS: OperationRegion (PMCR, SystemIO, 0x1004, 0x02) Field (PMCR, ByteAcc, NoLock, Preserve) { SCEN, 1, //SCI_EN , 9, SLPT, 3, // SLP_TYP SLPN, 1 //SLP_EN } OperationRegion (PMRS, SystemIO, 0x1030, 0x08) Field (PMRS, ByteAcc, NoLock, Preserve) { , 4, SLPE, 1, // SLP_SMI_EN , 31, SLPX, 1 // SLP_SMI_STS } OperationRegion (PMCB, SystemIO, 0x1000, 0x10) Field (PMCB, ByteAcc, NoLock, Preserve) { P1ST, 16, // PM1A status Offset (0x04), P1CN, 16 // PM1A_CNT } Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep { If ((Arg0 == 0x05)) { \_SB.PCI0.EHC1.PMEE = Zero \_SB.PCI0.EHC2.PMEE = Zero \_SB.PCI0.LPCB.AG3E = One P1ST = 0x0800 P1CN = 0x4900 SLPX = Zero SLPE = Zero Local0 = 0x4268 While ((Local0 > Zero)) { Local0-- Stall (0x64) } } } You should also append the status clearing logic to Method (_WAK) and Method (_INI) inside Device (PCI0) as shown below: Method (_WAK, 1, NotSerialized) // _WAK: Wake { P1ST = 0x0800 P1CN = 0x4900 SLPX = Zero SLPE = Zero Sleep (0x10) SCEN = One Sleep (0x10) SMI (0x9A, Arg0) Local0 = SMI (0x6D, Zero) If ((Local0 == 0x03)) { Local0 = SMI (0x46, Zero) \_SB.PCI0.VID.CLID = Local0 If ((Arg0 == 0x03)) { If (((MIS1 != Local0) || (Local0 == Zero))) { If ((OSID () >= 0x20)) { \_SB.PCI0.VID.GLID (Local0) } Else { LIDE () } } } } If ((Arg0 == 0x04)) { Notify (\_SB.PWRB, 0x02) // Device Wake MIS4 = One SOST () } MIS0 = SMI (0x98, Zero) Notify (\_SB.ADP1, 0x80) // Status Change \_SB.PCI0.WKHP () Local0 = HSCO (One) If (Local0) { If ((OSID () >= 0x20)) { Notify (\_SB.MBTN, 0x02) // Device Wake HSCO (0x02) } } Return (Package (0x02) { Zero, Zero }) } Method (_INI, 0, NotSerialized) // _INI: Initialize { P1ST = 0x0800 P1CN = 0x4900 SLPX = Zero SLPE = Zero Sleep (0x10) SCEN = One Sleep (0x10) MIS0 = SMI (0x98, Zero) MIS0 &= 0x13 MIS4 = One Local0 = SMI (0x46, Zero) Local6 = SMI (0x6D, Zero) If ((Local6 == 0x03)) { ^VID.GLID (Local0) } SOST () } add Device (LPCB) or ISAB OperationRegion (LPC0, PCI_Config, 0xA4, One) Field (LPC0, ByteAcc, NoLock, Preserve) { AG3E, 1 } Note: For machines that experience issues when waking up from a second consecutive sleep cycle, writing 0 to SLP_SMI_EN inside _WAK might potentially resolve the issue. By explicitly clearing the statuses like this, the boot loop issue has completely disappeared on my end so far. Hope this helps anyone facing similar ACPI power state headaches ACPI_original.zip DSDT.aml.zip config.plist.zip

Since December 2025, I have been maintaining OCLP-Plus on my own. Looking back, I'm saddened to see the Hackintosh era come to a close. This project was officially archived on June 28, 2026. 📢 Important notice for users: Unless something extraordinary happens, no further updates will be released. Existing versions will remain functional. Best wishes and prosperity to all.

Hey @mitch_de try to teste with a custom build on this issue, https://github.com/engeldlgado/toshllm/issues/1#issuecomment-4775184370 Theres is a custom build im testing for the RX-500 series, so maybe this work better, also the project will be delayed for few days because there was an earthquake in my city few days ago. Fortunately, my family and friends are all safe, but internet connections were severely affected and part of my home was damaged... I hope to fully get back to the project soon. Best regards.

@Lost-Entrepreneur439 You might get more responses if you post your EFI (and if you can't upload it because of its size, post a link to it). Note that some offered assistance to you in your previous thread here and you never responded. Good luck.

Thats Great