MaLd0n

ZeroRPMBuilder is a native macOS utility created to generate AMD GPU fan-control patches for Clover/OpenCore through DeviceProperties. The application can extract or import an AMD PowerPlay table, validate its structure, apply a controlled Zero RPM modification, and generate a ready-to-use PP_PhmSoftPowerPlayTable without flashing or modifying the GPU VBIOS. It was designed for users who want a cleaner and safer way to disable Zero RPM or configure a predictable fan start/stop temperature on supported AMD GPUs. Extracting the VBIOS with Clover (if you don't use Windows) You can dump your GPU VBIOS directly from the boot menu: Boot with Clover HERE Press F6. Clover will save the GPU ROM/VBIOS to the EFI partition, usually inside the Clover misc folder. Copy the generated file and load it into ZeroRPMBuilder. This is useful when you want ZeroRPMBuilder to work with the exact VBIOS from your GPU. Main Features Native macOS application AMD GPU and PowerPlay table detection Automatic GFX0 detection Bundled gfxutil 1.84b Automatic OpenCore PCI Device Path detection VBIOS / PowerPlay table extraction SPPT import support Strict PowerPlay structure validation Automatic Clover/OpenCoreDeviceProperties generation Automatic device-id spoofing when required Automatic no-gfx-spoof for supported Lexa cases Offline patch generation for GPUs not installed in the current Mac Original SPPT backup Patched binary and hexadecimal exports OpenCore config.plist generation OpenCore DeviceProperties snippet generation Detailed export report No VBIOS flashing required Fan Presets ZeroRPM OFF — Fan Always On This mode disables the GPU's Zero RPM behavior. Only the Zero RPM enable field is changed. The original: fan start temperature fan stop temperature fan curve RPM limits thermal targets are preserved. This is intended for users who prefer the fans to remain available instead of entering the GPU's factory Zero RPM state. FAN 35°C — Stop 30°C This preset keeps Zero RPM enabled but changes the fan activation temperatures to: Fan Stop Temperature: 30°C Fan Start Temperature: 35°C Zero RPM: Enabled The GPU can stop its fans below the configured threshold and restart them at approximately 35°C. Only the required PowerPlay fan-control fields are modified. Supported AMD Architectures ZeroRPMBuilder currently supports validated PowerPlay layouts for: Polaris Polaris 10 Polaris 11 Polaris 12 / Lexa Polaris 20 Polaris 21 Polaris 23 Examples include: RX 460 RX 470 RX 480 RX 550 RX 560 RX 570 RX 580 RX 590 Radeon Pro WX series Vega 10 Including: RX Vega 56 RX Vega 64 Vega Frontier Edition Radeon Pro WX 8100 / 8200 / 9100 Vega 20 Including: Radeon VII Radeon Pro VII Navi 10 / Navi 14 Including: RX 5300 RX 5500 RX 5600 RX 5700 Radeon Pro W5500 Radeon Pro W5700 Navi 21 / Navi 22 / Navi 23 Including members of the: RX 6600 family RX 6700 family RX 6800 family RX 6900 family Radeon Pro W6600 / W6800 families The application currently recognizes 56 AMD PCI Device IDs across the supported PowerPlay families. Automatic DeviceProperties Detection ZeroRPMBuilder includes gfxutil 1.84b directly inside the application bundle. No Homebrew installation is required. The application first attempts: gfxutil -f GFX0 to obtain the real EFI PCI device path. Example: PciRoot(0x2)/Pci(0x0,0x0)/Pci(0x0,0x0) If gfxutil cannot resolve the device, ZeroRPMBuilder uses its internal IORegistry detector. If no usable GPU path can be determined, generation is still allowed through a generic fallback: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) The user can also manually enter the required DeviceProperties path. Offline / Cross-GPU Patch Generation ZeroRPMBuilder does not require the target GPU to be installed in the Mac used to generate the patch. For example: Mac currently running: RX 6600 XT / Navi 23 Loaded VBIOS: RX 580 / Polaris The application will still generate the Polaris patch. The local GPU is used only when appropriate for DeviceProperties path detection. The loaded VBIOS/SPPT remains authoritative for the actual patch. This makes ZeroRPMBuilder useful for: preparing an EFI for another computer; preparing a patch before installing the GPU; building patches remotely; working with VBIOS dumps from another machine. A different GPU installed in the current Mac will no longer block generation. Automatic Device-ID Spoofing For selected GPUs that require a compatible PCI Device ID, ZeroRPMBuilder can automatically generate: device-id inside OpenCore DeviceProperties. Current automatic mappings include selected: Navi 21 Navi 23 Polaris Lexa Examples: 73EF → 73FF 73AF → 73BF 73A5 → 73BF and supported Lexa mappings such as: 699F → 67FF 6987 → 67FF 6995 → 67E3 6985 → 67E3 6981 → 67E3 The property is stored in the correct little-endian OpenCore format. Lexa no-gfx-spoof For the supported Lexa Device IDs that require the additional WhateverGreen behavior, ZeroRPMBuilder also generates: <key>no-gfx-spoof</key> <data>AQAAAA==</data> which corresponds to: 01 00 00 00 This is currently applied to: 699F 6987 6995 6985 6981 It is not added globally to every spoofed GPU. Generated OpenCore Properties A generated entry can look like: DeviceProperties └── Add └── PciRoot(...)/Pci(...)/Pci(...) ├── PP_PhmSoftPowerPlayTable ├── device-id └── no-gfx-spoof device-id and no-gfx-spoof are only added when applicable. The actual PowerPlay patch is stored as raw binary data in: PP_PhmSoftPowerPlayTable Safe PowerPlay Validation ZeroRPMBuilder does not blindly patch arbitrary offsets. Before modifying a table, it validates the expected PowerPlay structure for the detected architecture. Depending on the GPU family, validation can include: PowerPlay format revision content revision table revision declared structure size fan table revision fan table offset SMU PowerPlay version thermal controller type OverDrive table layout required field bounds If the loaded table does not match a supported structure, the application refuses to patch it. Unknown layouts are not guessed. What Does ZeroRPMBuilder Modify? Depending on the architecture, only the equivalent fields for: FanZeroRpmEnable FanStopTemp FanStartTemp are modified. ZeroRPMBuilder does not intentionally change: GPU core clocks memory clocks GPU voltage memory voltage power limits TDC limits fan curves minimum RPM maximum RPM fan target temperature OverDrive capability tables FeaturesToRun Original Table Preservation Before exporting the modified PowerPlay table, ZeroRPMBuilder preserves the original source. Generated packages can contain: Original SPPT Patched SPPT HEX export OpenCore config.plist OpenCore DeviceProperties snippet Generation report This makes it easier to compare or restore the original configuration. VBIOS Safety ZeroRPMBuilder does not flash your GPU. It does not write anything to the physical VBIOS. The modified PowerPlay table is applied through OpenCore: DeviceProperties → PP_PhmSoftPowerPlayTable Removing the property restores normal behavior without reflashing the graphics card. Built-in gfxutil ZeroRPMBuilder includes the official Acidanthera gfxutil 1.84b RELEASE universal binary: x86_64 arm64 It is used exclusively for PCI / EFI Device Path discovery. The application therefore does not require the user to install gfxutil separately. Credit for gfxutil belongs to its respective upstream authors and contributors. Testing The current release has been validated through automated regression, structural, parser and stress testing. The current development test set includes: Core regression tests: 405/405 Structural validation: 143/143 Swift parser checks: 13/13 AddressSanitizer tests: 405/405 ThreadSanitizer tests: 405/405 Stress testing: PASS Stress testing includes repeated: PowerPlay modifications; VBIOS extraction; PCI path parsing; OpenCore plist generation; ZIP generation; import/export operations. The patch matrix also covers both fan modes across all currently recognized GPU IDs. Important Notes PowerPlay tables can vary between: GPU generations; board partners; VBIOS revisions; OEM cards; workstation variants. ZeroRPMBuilder therefore validates the structure before writing anything. If a VBIOS contains an unknown PowerPlay layout, please provide the original ROM/SPPT so support can be investigated safely. Always keep a working EFI backup before modifying your OpenCore configuration. Feedback and Hardware Samples Compatibility reports are welcome. If a GPU is detected but its PowerPlay table is rejected, please include: exact GPU model; PCI Device ID; VBIOS ROM if possible; original SPPT; macOS version; ZeroRPMBuilder log. Additional real-world VBIOS samples help improve validation without resorting to unsafe generic offsets. Credits ZeroRPMBuilder ©DNMTechLabs dnmtechlabs@gmail.com Additional credit to the Acidanthera project and the authors/contributors of gfxutil, Lilu, WhateverGreen and the broader Hackintosh development community. Download ZeroRPMBuilder HERE AMD PowerPlay / Zero RPM patch generator for macOS and OpenCore. No VBIOS flashing. No permanent GPU modification.

Disable HT, dual socket dont work with HT enable in many cases

Yes. Have support.

I think this processor is kabylake

**UPDATE** Here are the most important improvements. 🔹 Major Intel HDMI / DisplayPort audio evolution Intel integrated graphics display audio received one of the largest development efforts in the project. Support was improved for shared-HDEF architectures and multiple Intel generations, with better framebuffer discovery, native audio-codec-info handling and stricter association between the HDA controller and the correct graphics device. HDMI/DP endpoints can now be matched using actual framebuffer topology instead of relying only on generic assumptions. 🔹 Native framebuffer audio topology HDAUniversal can use framebuffer-provided codec information to identify: • Codec Address • Audio Function Group • Digital Pin • Active display endpoint The discovered topology is cross-checked against the live HDA widget graph and ELD information before being accepted. Ambiguous mappings fail safely rather than selecting an arbitrary display output. 🔹 Improved Intel display-audio wake Display-audio codec wake handling was added for supported Intel generations. The implementation verifies the correct GPU, framebuffer, codec address, active endpoint and display state before interacting with the display-audio hardware. Wake attempts are bounded and protected against unsupported hardware. 🔹 Intel HDMI/DP mux improvements Intel Haswell-style digital mux handling was significantly expanded. Dynamic converter selection can now follow the actual codec topology instead of assuming a fixed converter. Multiple HDMI/DP pins are handled more safely, with retry and end-to-end validation of the selected path. 🔹 Better multi-monitor and MST support DisplayPort MST routing received additional protection around converter selection and Device Select state. Previous hardware state is preserved and can be restored if a route transaction fails. This significantly reduces the risk of leaving another display endpoint in an invalid state. 🔹 Linux-aligned Intel stripe control Intel display audio gained capability-driven WCAP_STRIPE support. Stripe configuration now considers: • controller NSDO capability • sample rate • sample width • channel count • converter capabilities • active stream descriptor Both converter and stream-descriptor programming are verified through hardware readback. If the physical commit cannot be confirmed, the previous state is restored. 🔹 Capability-driven HDMI/DP amplifier handling Digital pins that expose a hardware output amplifier can now be detected through their widget capabilities. Muted amplifier channels are selectively unmuted while preserving the existing gain value. The operation includes physical readback and rollback protection. This behavior is limited to qualified Intel display-audio routes and is not applied blindly to analog codecs or unrelated digital hardware. 🔹 Stronger hotplug handling HDMI/DisplayPort hotplug processing was extensively redesigned to eliminate lifecycle races. Framebuffer callbacks no longer perform heavy HDA operations directly. Events are safely transferred to the HDAUniversal workloop, while callback lifetime is protected during detach, sleep and teardown. This also addresses scenarios involving rapid monitor connection/disconnection. 🔹 Deadlock prevention Lock ordering between framebuffer events and HDA runtime operations was hardened. Registry operations, notifier callbacks and graphics discovery are kept outside inappropriate HDA lock regions. This reduces the risk of WindowServer or graphics-stack stalls during HDMI/DP hotplug events. 🔹 Late framebuffer metadata recovery HDAUniversal can now recover when framebuffer audio metadata is not available during the first hardware scan. A bounded retry mechanism allows audio-codec-info to appear later without permanently losing the HDMI/DP endpoint. Retries stop automatically after the metadata becomes valid or the defined retry budget is exhausted. No unlimited polling is used. 🔹 Connection List parser hardening Malformed HDA Connection List ranges are now handled safely. Invalid range entries can be skipped without corrupting neighboring valid connections, selector indices or downstream routes. This behavior was aligned more closely with proven Linux HDA parsing strategies. 🔹 Physical route qualification Route discovery became more rigorous. A route can now be physically qualified by checking: • Pin direction • Widget type • Converter direction • Connection graph • Canonical path edges • DAC/ADC reachability • Pin capabilities This prevents a semantic label from overriding an impossible physical topology. 🔹 Route Authority separated from hardware qualification Detecting a valid physical path no longer automatically gives that path authority over the selected layout. This preserves an important project principle: the selected layout remains authoritative unless explicit runtime route authority is enabled. Live codec discovery is used as a fallback when layout information is absent, not as an uncontrolled replacement. 🔹 AppleALC-style layout authority preserved User-selected layouts remain the primary source for: • Pin configuration • Routing • PathMap • Codec-specific initialization Live codec data cannot silently replace a valid selected layout. This makes behavior more predictable across different machines using the same codec. 🔹 Advanced combo-jack support Combo-jack handling was extensively redesigned. Headphone and microphone detection are treated independently. A simple TRS headphone is no longer incorrectly interpreted as a headset microphone. CTIA/OMTP headset routing can be handled through explicit layout policy while ordinary layouts retain their existing behavior. 🔹 Improved microphone and headset transitions Headset state changes now use transactional routing. If a new microphone or headphone route cannot be fully committed, HDAUniversal can restore the previous verified state. This prevents partial jack transitions from leaving the codec incorrectly configured. 🔹 Smarter jack detection Jack monitoring received major efficiency improvements. HDAUniversal prioritizes unsolicited codec events whenever they are reliable. Physical polling becomes a fallback rather than the default source of constant hardware traffic. 🔹 Automatic unsolicited-event recovery When unsolicited jack events stop behaving correctly, HDAUniversal can temporarily enable fallback polling and later attempt to restore event-driven operation. This provides recovery without forcing permanent aggressive polling. 🔹 Adaptive jack fallback Fallback polling uses bounded timing and backoff. Stable hardware is queried less frequently, reducing unnecessary verb traffic while still allowing physical changes to be detected. 🔹 Corrected analog fallback latency A timing interaction that could accidentally increase non-combo jack polling from approximately hundreds of milliseconds into multi-second intervals was identified and corrected. Normal analog fallback detection once again operates at the intended responsive cadence. 🔹 Bluetooth / A2DP idle isolation Idle HDA behavior was reduced where unnecessary so that the driver avoids generating avoidable hardware activity while another audio transport is active. The implementation deliberately avoids making unsupported assumptions about the Bluetooth stack itself. 🔹 Transactional output routing Output routing now follows a stricter transaction model. Before changing hardware, previous codec state can be captured. After programming, the result is verified. If verification fails, HDAUniversal attempts a controlled rollback rather than continuing with a partially configured route. 🔹 Transactional input routing The same fail-safe model was expanded to input and capture paths. ADC selection, mixers, PinControl, amplifier state and related routing components can participate in verified route transactions. 🔹 Fail-closed recovery One of the most important architectural changes was the wider adoption of fail-closed behavior. If a hardware transaction fails and the previous known-good state cannot be restored, HDAUniversal avoids pretending that the route is valid. Unknown codec state is treated as unsafe. 🔹 Verified rollback Rollback itself is no longer assumed to succeed. Critical restoration paths can be physically verified through codec readback. This applies to several routing, initialization, capture and digital-output operations. 🔹 Capture lifecycle hardening Capture start, stop and rollback paths received additional protection. Partial ADC or stream ownership cannot silently remain active after a failed capture transaction. Lease and ownership states are kept consistent with the actual hardware state. 🔹 Exact Init safety Codec-specific initialization sequences were integrated more tightly with transactional state management. Initialization failures can participate in the same verification and rollback model instead of leaving partially programmed codec state behind. 🔹 Controller stability audit Low-level HDA controller operations were reviewed for compliance and stability. Work included: • CORB handling • RIRB handling • stream format programming • register access • bounded transport recovery • controller reset boundaries • DMA lifecycle protection 🔹 Sleep / wake improvements Command transport, framebuffer state, timers and codec state received additional lifecycle protection across system sleep and wake. The driver avoids freeing resources when hardware quiescence cannot be proven. This favors safety over aggressive cleanup. 🔹 Timer lifecycle hardening Timer creation, arming, cancellation and teardown were audited. Timers are armed with a new deadline before being enabled, preventing stale deadlines from being accidentally reused. Callback draining is also coordinated with teardown. 🔹 Framebuffer lifecycle cleanup Graphics resources, notifier objects and framebuffer references are released through safer lifecycle boundaries. Races between discovery, callback execution and driver shutdown received additional protection. 🔹 Release signing integrity The build pipeline was hardened so Release artifacts consistently use the expected signing model. Nested Mach-O components are processed correctly instead of assuming that only the main kext executable requires handling. 🔹 Executable-mode integrity Release packaging now verifies that executable permissions survive every stage of the build/package process. Nested binaries remain executable inside the final bundle instead of depending on filesystem luck. 🔹 Stronger release validation The project now uses an extensive regression matrix covering previous fixes as new functionality is introduced. Validation includes areas such as: • layouts and codecs • routing • jack handling • HDMI/DP • MST • capture • controller transport • sleep/wake • rollback • framebuffer lifecycle • release packaging • signing • resource integrity 🔹 Expanded hardware database HDAUniversal continued expanding its codec and layout database while preserving strict (Codec ID + Layout ID) identity. New layouts can coexist for the same codec without changing existing configurations. ⚙️ What these development cycles represent The biggest change is not a single codec or feature. HDAUniversal has progressively moved toward a hardware-verified, transactional and fail-safe HDA architecture. Instead of assuming that a verb worked, critical operations can verify the hardware. Instead of accepting an ambiguous route, the driver can reject it. Instead of leaving partially programmed state behind, transactions can roll back. Instead of continuously polling hardware, event-driven mechanisms are preferred and polling becomes a controlled fallback. And instead of letting runtime discovery override everything, the user-selected layout remains authoritative. The goal remains simple: broader HDA hardware compatibility on macOS while maintaining predictable behavior, strong isolation and strict hardware-state control.

With one GPU with support yes

We are releasing a version of VoodooI2C with VoodooI2CSynaptics that includes a specific fix for Sleep/Wake issues affecting Synaptics trackpads. On some laptops, the Synaptics trackpad works normally after boot, but stops responding after macOS enters Sleep and wakes up again. The device may still remain present in the system, but the RMI communication/interrupt state is not properly restored after wake. This version introduces specific power-management handling inside VoodooI2CSynaptics. What does the fix do? During Sleep, the driver tracks the device power-state transition. After Wake, VoodooI2CSynaptics performs the required recovery procedure to restore proper trackpad operation, including: restoring RMI ATTN mode; restoring the F01 interrupt mask; dedicated handling through IOKit power states; preventing unnecessary reinitialization when the trackpad is already awake; dedicated Sleep/Wake diagnostic messages. When the recovery succeeds, the driver reports: Woke up from Sleep! RMI ATTN mode restored. There are also specific diagnostic messages if any part of the recovery procedure fails: Wake recovery failed to restore RMI ATTN mode Wake recovery failed to restore F01 interrupt mask If the device is already active, the driver reports: Trackpad already awake! Not reinitializing. Version The provided package contains: VoodooI2C 2.9.1 VoodooI2CSynaptics 1.0 Current architecture: x86_64 The current build is configured for the Synaptics device identified as: SYNA2B61 Please verify the ACPI device name of your trackpad before using this version. Purpose of this fix The main goal is to address the common behavior where: Boot → Trackpad works → Sleep → Wake → Trackpad stops working With this fix, the RMI state required for trackpad interrupts is restored during Wake, allowing the device to remain operational without requiring a macOS reboot. Check the trackpad device name in IORegistryExplorer (IOReg) for each laptop, then replace the existing device name in the VoodooI2CSynaptics.kext Info.plist with the correct one for your hardware. Download: VoodooI2CSynaptics.zip Credits to the original VoodooI2C project and its developers. This version keeps the original project base while adding the Synaptics Sleep/Wake handling described above.

If driver don't exist u can try create one driver for that, but it's a hard work.

U can use this patch

DSDT_FIXED_GPE_L08.aml.zip

Check whatevergreen instructions

HDA-Universal has native volume, without boost or -dB adjustment.

HDAUniversal-Release.zip use alcid=171

Use this balena version https://olarila.com/files/Utils/balenaetcher-1-18-11.exe.zip

These configurations comming from a layout. Check if ur layout have a correct things. In some cases to detect all ports, etc need check from linux and connect headset, test mic, etc then extract codec dump.

No support

Enable sip after installation

Payment Links - Links de Pagamento Paypal - https://www.paypal.com/donate/?hosted_button_id=AA4QBFJQYW2N2 Ko-Fi - https://ko-fi.com/olarila Revolut - @olarila or any crypto

No support

is about layout not kext

Yes

AMD vc tem de patchear muitos apps e outros não funcionam.

Sequoia or Tahoe with 32gb ram

Essas placas são complicadas e precisam de patches extras. Vai no suporte de 200 R$ que a gente resolve isso.