OpenCore General Discussion

[naiclub]

20 minutes ago, miliuco said:

@naiclub

 

No, as far as I know, these are used since I can remember. 

In short, the fake code you sent me to use is correct. Gen 8-Gen 9 is Coffee Lake. So, my internal components aren't compatible with older models.
I think even Mojave doesn't support the USB 3 port I'm using. I tried mapping it, but I can't find the USB 3 port. Only USB 2.1-2.0 ports are supported. Suppose I use the KEXT from Catalina. Will that work?
Thank you for your help.

 

[deeveedee]

Open Core works so well that I started taking it and the OC Devs for granted.  Haven't said it for a while, so Thank you, Devs!  Every time I think about how much work I've put into my hacks, I know it pales in comparison to the time and effort you have invested in Open Core and the Acidanthera kexts.  Thank you for your dedication and commitment to Open Core.  I just updated LegacyBoot and Applied LogoutHook with OC 1.0.5 on my old 2010 HackBookPro6,2 multi-booting Big Sur, Monterey, Ventura, Sonoma, Sequoia and Tahoe Beta.  All working great!  

 

Well done, Devs.  I don't use CLOVER any more, but the same thanks to Slice and the others who maintain CLOVER.  We are all very luck to have these Devs.

[deeveedee]

EDIT: I am running tests with ACPI debug statements to learn more about this.

 

EDIT2: I have confirmed that the Open Core GPRW -> XPRW patch is working as intended.  The issue reported below appears to be a problem with the way macIASL is reading/interpretting the patched System DSDT.

 

=======================================================

 

Is there a problem with Open Core's GPRW -> XPRW instant wake patch?  Details below...

 

I'm not sure where to post this, so here seems as good a place as any.  I am hacking a laptop for the first time in a while and have noticed strange behavior with the generally accepted instant wake patch here.  This patch has always worked for me in the past, but now on two newer PCs, the patch is suspect.  I invite others to test and attempt to duplicate this behavior which I think might have something to do with the ACPI version employed on the PC.

 

1. Apply the GPRW -> XPRW instant wake patch as described here.  I'm applying the patch with Open Core 1.0.5.  I have also duplicated this with Open Core versions 1.0.3 and 1.0.4.
2. After booting macOS with the ACPI patch installed, open MaciASL (I have tested with MaciASL versions 1.6.0 through 1.6.5)
3. In MaciASL, select File > New from ACPI > DSDT
4. In the DSDT, search for GPRW.  The first search return should be the declaration of the External GPRW which should be a Method, but in my case, it is not.  GPRW is declared as an External IntObj
   
5. Now search for the first instance where GPRW is called.  You should see the normal GPRW function call, but because GPRW is declared as an External IntObj, the function call is borked.  It should be Return (GPRW (0x72, 0x04)).
   

 

I see this strange behavior on newer PCs like the HP Elitebook 850 G7 (which needs the instant wake patch) and HP EliteDesk 800 G4 / G5 (which doesn't need the patch, but I tested it).  On older PCs, like my old Dell Latitude E6410, the external declaration and function calls are as expected.

 

Currently, since I don't know whether the problem is MaciASL or Open Core's patching, I am not using GPRW -> XPRW and am instead patching each _PRW method.  So far, I have only observed this strange behavior for the GPRW -> XPRW patch.  Other Method renames do not have this problem.

Edited November 4, 2025 by deeveedee

[Max.1974]

Hello @deeveedee, maybe it works differently for laptops. Take a look at my Lenovo T14 EFI and check the patches I added — they work great both in Clover and OpenCore.

Aside from that, I’ve been following an excellent tutorial by @jsassu20. My GitHub repository link contains all of my EFIs, and @jsassu20’s GitHub link is included below.  

 

https://github.com/jsassu20/OpenCore-HotPatching-Guide 

 

 

git clone https://github.com/maxpicelli/Lenovo-T14-Gen1-OpenCore-EFI.git

 

 

 

[Avery B]

@deeveedee Do you have a copy of the compiled DSDT both before and after patching? Wonder if the patch is not applying to the right offset.

[deeveedee]

@Max.1974 I'll check out your links - always excited to learn something new.  If the repos you linked have different GPRW -> XPRW patches, that will help.  If not, I'm currently focused on trying to fix the GPRW -> XPRW patch here.  I do have alternative patches that achieve the same result.

 

@Avery B Attached is the original/unpatched DSDT (compiled) and the patched DSDT  (disassembled).  MaciASL won't let me save the patched DSDT as compiled binary with errors.  Does this help you?  If not, let me know how to save the patched DSDT as a compiled binary with errors.

 

EDIT: @Avery B I noticed that the System DSDT (disassembled) posted here has the same problem after applying the GPRW -> XPRW patch.

Original DSDT.aml.zip Patched DSDT.zip

Edited November 2, 2025 by deeveedee

[deeveedee]

@miliuco I see that you're confused by my post here.  Please let me know if you need me to explain anything.

[miliuco]

@deeveedee

Bad vision, wrong icon, fixed 🙂

[deeveedee]

@Avery B I am running tests with ACPI debug statements to determine whether my reported issue is the Open Core ACPI patch or macIASL.

 

EDIT: @Avery B  I have confirmed that the Open Core GPRW -> XPRW patch is working as intended.  The issue reported here appears to be a problem with the way macIASL is reading/interpretting the patched System DSDT.

Edited November 4, 2025 by deeveedee

[fspkwonx86]

@deeveedee well it basically looks like its just simply renaming something (as for what im handing over is find the model mac that uses the same chipset where device ids apply and thats where they get the information from for the dtgp patches) , is the issue that its not saving the compiled aml file? that would be a syntax error somewhere is specifically why... 

if the syntax passes but in general is out of typical order it will not compile the aml file or itll compile but skip any proceeding errors that there may have been along the way is my general

experience with it at all....  let me see what your trying to actually fix , 

so these are the relevant fixes? not just sleep im more key focused on is it suspending? because even down to the RTC each of these matter: Fix RTC , AC Adaptor, Brightness, CStates (Variation):
https://www.insanelymac.com/forum/topic/211705-guide-snow-leopard-with-100-vanilla-sle-comprehensive-dsdt-patching-guide/

WAK, SBUS, HPET (Variation), and LPC Fix , EHCI, and AHCI are Extra:
https://www.insanelymac.com/forum/topic/246639-dsdt-nforce-680i-dsdt-development/

ECDV EC0 Embedded Controller Fix for SMBUS.Kext and Sleep:
https://www.tonymacx86.com/threads/guide-usb-power-property-injection-for-sierra-and-later.222266/page-65#post-1782596

Method GPRW in WAK fix:
https://www.insanelymac.com/forum/topic/341624-acpi-patches-for-sleep/

USB_Wake Bug Fix: on wake and messages: flash drive disconnected improperly....
https://www.insanelymac.com/forum/topic/286754-dsdt-usb-power-management/

USB UHCI Bus Fix:
https://www.insanelymac.com/forum/topic/168014-dsdt-trick-retail-drivers-by-changing-device-id-eg-usb/

and then of course the rest of what i have so far:
Works Cited: Fixing Legacy C States for CpuPm(Legacy) and XCPM(Modern):
https://www.insanelymac.com/forum/topic/181631-dsdt-vanilla-speedstep-generic-scope-_pr/page/6/

Fixing Legacy P States for CpuPm(Legacy) and XCPM(Modern):
https://www.insanelymac.com/forum/topic/181631-dsdt-vanilla-speedstep-generic-scope-_pr/#comments

CPU Plugin Type Fix (SpeedShift/HWP-Pm for X86PlatformPlugin):
https://www.insanelymac.com/forum/topic/321021-guide-hwpintel-speed-shift-enable-with-full-power-management/page/2/

Fixing HEDT , Servers, and New Arcitechture PMs Legacy and Modern:
https://www.insanelymac.com/forum/topic/349526-cpu-wrapping-ssdt-cpu-wrap-ssdt-cpur-acpi0007/#comment-2827951

Fixing New Arcitechture PMs CPU is out of Root-SCOPE:
https://www.tonymacx86.com/threads/solved-new-possibilities-for-x79-appleacpiplatform-panic.229491/

HPET DTGP and Understanding IRQs to fix those as well:
https://www.insanelymac.com/forum/topic/226081-guidedsdt-modshacks/#comment-1516511

Edited November 19, 2025 by fspkwonx86

[deeveedee]

@fspkwonx86 I believe you have misunderstood my posts.   macIASL is incorrectly extracting the patched DSDT (File > New from ACPI > DSDT) which gives the appearance of an ACPI error when there isn't one.

[Matgen84]

To all:

 

There is a strange issue since this morning. On my old Ivybridge, BootPicker shows Tahoe 26.1 instead of Sequoia 15.7.2. 🥲 I can't boot the system stuck at AHCI Controller !!! I Try SOS utility from another disk, without success.

 

Sorry, for OFF Topic. Need help please.

 

I can't reinstall Sequoia 15.7.2 on the volume...

Spoiler

Edited December 7, 2025 by Matgen84

[Max.1974]

2 hours ago, Matgen84 said:

To all:

 

There is a strange issue since this morning. On my old Ivybridge, BootPicker shows Tahoe 26.1 instead of Sequoia 15.7.2. 🥲 I can't boot the system stuck at AHCI Controller !!! I Try SOS utility from another disk, without success.

 

Sorry, for OFF Topic. Need help please.

 

I can't reinstall Sequoia 15.7.2 on the volume...

  Reveal hidden contents

Hi my friend, maybe need check your SMBIOS on USB kext, or try compile your SSDT for HUB ports. 

 

[Matgen84]

13 hours ago, Max.1974 said:

Hi my friend, maybe need check your SMBIOS on USB kext, or try compile your SSDT for HUB ports. 

 

 

Hi my friend. SMBIOS is correct.

[deeveedee]

Has anyone been able to set PP_WorkLoadPolicyMask DeviceProperty = 0x20 for Radeon dGPU using WhateverGreen 1.7.0 and OpenCore 1.0.6?  Details below...

 

I was experimenting with the WhateverGreen DeviceProperty PP,PP_WorkLoadPolicyMask (which sets PP_WorkLoadPolicyMask for Radeon dGPU) and found that I can set the value to 0x01 (DEFAULT_WORKLOAD) and to 0x08 (VIDEO_WORKLOAD), but I cannot set it to 0x20 (COMPUTE_WORKLOAD).  My attempts to set to 0x20 result in an empty PP,PP_WorkLoadPolicyMask property, which results in no PP_WorkLoadPolicyMask property in IOReg.  I have tried setting PP,PP_WorkLoadPolicyMask property with type number (value = 0x20 = 32) and I have tried setting with type data (value = <20000000>).

 

My test config is as follows:

• WhateverGreen.kext version 1.7.0
• Lilu.kext version 1.7.1
• Open Core 1.0.6.  
• dGPU is Radeon RX 560x (Polaris)
• macOS Tahoe 26.2
• SMBIOS MacMini8,1

 

Just curious to know if anyone else has observed this so that I know whether to invest any more time debugging.

[Matgen84]

To all: 

I don't know if is the right place, sorry. I clone my main disk called "Sequoia" to another internal disk called "Clone" on macOS. All is perfect there:  I've changed the names  in finder and disk utility, however opencore bootlicker hasn't changed as well. Is there a way to manually change an entry's name?

Any ideas, please ?

 

Happy new year 2026 !

 

 

Edited January 1 by Matgen84

[deeveedee]

@Matgen84 If I understand your question, you want to change the Volume name in Open Core boot picker.  There are a few different ways to achieve this.  If you search for "how to change volume labels in open core boot picker" you should find answers like this and this.  There are other methods, too.

 

Happy New Year!

Edited January 1 by deeveedee

[Matgen84]

@deeveedee You understand well. In fact, after cloning (SuperDuper), Opencore BootPicker GUI (Opencanopy) is keeping the original name instead of target. So I suppose, I have to manually rename something into .diskcontentDetails !

[miliuco]

@Matgen84

 

https://www.insanelymac.com/forum/topic/344251-opencanopy-icons/page/69/#findComment-2845714

[deeveedee]

I finally had some time to upgrade the EFI on my old HackBookPro6,2 with Open Core 1.0.7 and the latest releases of the Acidanthera kexts.  All is still working well.  I'm amazed that Open Core continues to work so well on this old (2010) hack.  I also applied the OC 1.0.7 LogoutHook and LegacyBoot.  All updates applied without issues.  Currently running Sequoia 15.7.6 RC and it is incredibly responsive!  Even if the journey on my old hack stops at Sequoia (because OCLP non-metal patches are never released for Tahoe), this hobby will have been fun and rewarding.

 

Thank you, OC and OCLP Devs, for making this possible.

[deeveedee]

I re-installed macOS Tahoe 26.4.1 on my HackMIni8,1 and accidentally enabled FileVault during the install.  With Open Core 1.0.7, FileVault works perfectly - so much so that the only difference I noticed was that the login screen appears earlier in the boot cycle.  The pioneers who struggled through the early days of Tahoe remember the difficulties with FileVault.  No problems at all with FileVault in macOS Tahoe 26.4.1 and Open Core 1.0.7.

Edited April 15 by deeveedee

[MakAsrock]

On 8/14/2025 at 5:33 PM, naiclub said:

In short, the fake code you sent me to use is correct. Gen 8-Gen 9 is Coffee Lake. So, my internal components aren't compatible with older models.
I think even Mojave doesn't support the USB 3 port I'm using. I tried mapping it, but I can't find the USB 3 port. Only USB 2.1-2.0 ports are supported. Suppose I use the KEXT from Catalina. Will that work?
Thank you for your help.

 

Try this fake code:
Cpuid1Data 55060A00000000000000000000000000
Cpuid1Mask FFFFFFFF000000000000000000000000
It is Alder Lake😉

[verdazil]

7 hours ago, MakAsrock said:

It is Alder Lake😉

This is not an Alder Lake CPUID.
The value Cpuid1Data 55060A corresponds to CPUID 0xA0655, which belongs to Intel Comet Lake (10th generation) processors.
It is commonly used to spoof Alder Lake CPUs as 10th-gen Comet Lake for compatibility reasons.

[MakAsrock]

2 hours ago, verdazil said:

This is not an Alder Lake CPUID.
The value Cpuid1Data 55060A corresponds to CPUID 0xA0655, which belongs to Intel Comet Lake (10th generation) processors.
It is commonly used to spoof Alder Lake CPUs as 10th-gen Comet Lake for compatibility reasons.

I meant for Alder Lake and above. 😉

[Slice]

17 hours ago, deeveedee said:

I re-installed macOS Tahoe 26.4.1 on my HackMIni8,1 and accidentally enabled FileVault during the install.  With Open Core 1.0.7, FileVault works perfectly - so much so that the only difference I noticed was that the login screen appears earlier in the boot cycle.  The pioneers who struggled through the early days of Tahoe remember the difficulties with FileVault.  No problems at all with FileVault in macOS Tahoe 26.4.1 and Open Core 1.0.7.

There is no problem with Clover as well. My struggle is because my HDD is very slow for FileVault encryption/decryption. I prefer to switch FileVault off.