Jump to content

Fix Sleep/Wake issue on older Macs


44 posts in this topic

Recommended Posts

1 hour ago, Stefanalmare said:

ACPI posted above is the original one extracted with hackintool.

 

Hackintool extracts ACPI after your patches have been applied.  You need to use something like Clover's F4 to extract unpatched ACPI before it is patched.

 

EDIT: In order to generate the correct hot-patches and find/replace rules, it is important to examine the original, unpatched ACPI (which can't be done after you boot macOS).

Edited by deeveedee
Link to comment
Share on other sites

18 minutes ago, deeveedee said:

 

Hackintool extracts ACPI after your patches have been applied.  You need to use something like Clover's F4 to extract unpatched ACPI before it is patched.

 

EDIT: In order to generate the correct hot-patches and find/replace rules, it is important to examine the original, unpatched ACPI (which can't be done after you boot macOS).

 I know, but OCLP EFI for this iMac doesn't have ACPI patches. Only 1 orig SSDT + mine. So, the Original tables are untouched. Latter I'll extract from linux. I read that clover may corupt the firmware in genuine Macs.

  • Like 1
Link to comment
Share on other sites

@Stefanalmare In your ACPIMac2010 folder, there is SSDT-4.aml which has the following:

            Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
            {
                0x0D, 
                Zero
            })

which is your patched _PRW.  That is why I asked.  I don't even trust myself and always extract the unpatched ACPI, even when I'm certain.  I'm not doubting you, it's just the way I operate.

 

EDIT: You do have a couple of options for extracting ACPI with a real Mac.  See this.

 

EDIT2: If you have any doubts about the safety of a solution for your real Mac, don't use it - not worth it.

Edited by deeveedee
Link to comment
Share on other sites

@Stefanalmare Attached is a variation of cankiulascmnfye's solution.  The attached solution does not require any _PRW renames, so if you try this, disable the renames in your config.plist.  I'm curious to know if this works.

 

EDIT: I just realized that we're in the "nstalling new macOS on unsupported hardware (OCLP patcher and others)" thread and have completely clobbered it.  If admins want to move this to a thread dedicated to Stefanalmare's issue that is unique to his iMac ...

 

SSDT-PRW.aml.zip

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

Firmware is in ROM chip which requires a special program to reflash it. Clover has no such a procedure. Nonsense.

Opencore writes into NVRAM values that shouldn't be there. It is really corrupted it.

Some year ago there was a precedent with Clover about written NVRAM. We made conclusions and avoided such cases.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 11/6/2023 at 12:18 PM, Slice said:

ACPI doesn't differ Name and Method if you want to read the value.

True when the Method takes zero arguments (like _PRW).

 

4 hours ago, Stefanalmare said:

I read this on Macrumors. Somebody tried to boot with clover and his firmware become corrupt. I never used clover on genuine Macs.

If you can still boot your iMac with a supported macOS that does not require OCLP/OC, you should be able to extract ACPI with Hackintool after booting the last supported macOS.  If you still want help with this (because my last solution here does not work for you), we'll need your original, unpatched ACPI and your current Open Core EFI.

  • Like 1
Link to comment
Share on other sites

Hackintool and Xiasl may extract ACPI tables but already patched, dropped and added because they take them from patched memory after a bootloader.

Native tables you may get with Clover or with AIDA64 in Windows (booted without OC!) or with Linux (I don't know the method). 

  • Like 1
Link to comment
Share on other sites

6 hours ago, Slice said:

Firmware is in ROM chip which requires a special program to reflash it. Clover has no such a procedure. Nonsense.

Opencore writes into NVRAM values that shouldn't be there. It is really corrupted it.

Some year ago there was a precedent with Clover about written NVRAM. We made conclusions and avoided such cases.

NVRAM can brick a genuine MAC (firmware):

"Advice after several bricks over the years:

First a fact, MacPro5,1 NVRAM was designed back in 2008ish, when the NVRAM was used sparingly. Now we are in 2023 and the NVRAM is used constantly for all sort of things, like all sort of iCloud related variables (for example, Wi-Fi credentials for the wireless networks that you connect with your iPhone and MacBooks are saved into the Mac Pro NVRAM) to the several variables needed to bootstrap software updates when you have sealed containers (BigSur and Monterey) that have a payload of ~25KB.
The NVRAM is now the Achilles heel of our MacPro5,1 and I personally don't wait for the garbage collection to fail. Now I have a recurring appointment on my Calendar to flash the never booted BootROM image every 3 months. Since starting doing it, I never had a brick or any NVRAM problems - even with all my crazy tests that bricked so much times my backplanes in the past. Do the same."

 

From: https://forums.macrumors.com/threads/macpro5-1-bootrom-thread-144-0-0-0-0.2132317/

 

When I'll find again the clover "issue", I'll post it here.

  • Like 1
Link to comment
Share on other sites

20 minutes ago, Slice said:

Hackintool and Xiasl may extract ACPI tables but already patched, dropped and added because they take them from patched memory after a bootloader.

Native tables you may get with Clover or with AIDA64 in Windows (booted without OC!) or with Linux (I don't know the method). 

 

True, but if he boots the last supported macOS on his real iMac (a version of macOS that does not require boot loader), using Hackintool will extract the unpatched ACPI.

Link to comment
Share on other sites

51 minutes ago, deeveedee said:

 

True, but if he boots the last supported macOS on his real iMac (a version of macOS that does not require boot loader), using Hackintool will extract the unpatched ACPI.

Real Mac yes but I see no sense to explore them. It works better then we can do.

Link to comment
Share on other sites

9 minutes ago, Slice said:

Real Mac yes but I see no sense to explore them. It works better then we can do.

 

Agreed, but Stefanalmare is asking for help with his real iMac..

Link to comment
Share on other sites

2 hours ago, Cyberdevs said:

@Stefanalmare

Hi, sure thing but I'm not sure where to start.

Which posts are you looking to be separated into a different thread?

Hey man! Starting with this: https://www.insanelymac.com/forum/topic/354499-installing-new-macos-on-unsupported-hardware-oclp-patcher-and-others/?do=findComment&comment=2813013, all about genuine iMac. Thank you!

 

15 minutes ago, cankiulascmnfye said:

@Stefanalmare I recently dumped the ACPI Tables etc for the iMac11,3: https://github.com/khronokernel/DarwinDumped/issues/3

 

 

Me too. Direct linux boot (no OC) with acpidump.

 

ACPIiMac2010.zip

Edited by Stefanalmare
Link to comment
Share on other sites

 Share

×
×
  • Create New...