Jump to content
30960 posts in this topic

Recommended Posts

2 hours ago, MICKHAEL said:

I think you have a problem) check again your config

Brilliant diagnosis :)   'The problem' may be that, when converting from OC config.plist to CLOVER config.plist (after already booting a system with OC), copying the following from OC to CLOVER changes the system definition (in ways that I don't understand as I stated here ).  It is possible that after converting from OC to CLOVER, I need to remove the com.apple.PowerManagement...plist kexts from /Library/Preferences and reconfigure.  I am not running that system at the moment and will need to test again later.

 

OC > CLOVER

PlatformInfo.Generic.MLB > Rt Variables.MLB

PlatformInfo.Generic.ROM > Rt Variables.ROM

PlatformInfo.Generic.SystemProductName > SMBIOS.Product Name

PlatformInfo.Generic.SystemSerialNumber > SMBIOS.Serial Number

PlatformInfo.Generic.SystemUUID > SMBIOS.SmUUID

Edited by tonyx86
4 hours ago, Slice said:

But where did you find this "__ZN12AppleUSBXHCI11createPortsEv.cold.1"?

 

In /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBXHCI.kext/Contents/MacOS/AppleUSBXHCI, a search for __ZN12AppleUSBXHCI11createPortsEv results in this:

395663094_ScreenShot2021-01-05at3_43_54PM.thumb.png.f390c6ab9671e26fbe0814d7bfd1c09e.png

 

I also tried your proposal of changing to ".Count = 2" in OpenCorePkg/Library/OcAppleKernelLib/CommonPatches.c, but it still doesn't get applied.

(I will mention that previously, I also checked reverting the commit pointed above in Library/OcAppleKernelLib/KextPatcher.c to the original state, and it works properly when reverted).

 

Edited by Pene
  • Like 1
1 hour ago, Slice said:

But hex search inside the binary found one occurrence

Just checked with hex search inside the binary, and there are 4 occurrences on the Big Sur binary: two with __ZN12AppleUSBXHCI11createPortsEv and two with __ZN12AppleUSBXHCI11createPortsEv.cold.1

I attach the 11.1 binary just in case: AppleUSBXHCI

 

I also checked the Catalina binary, and there are 2 occurrences: one with __ZN12AppleUSBXHCI11createPortsEv and one with __ZN12AppleUSBXHCI11createPortsEv.cold.1

 

Actually, first I put a debug in OpenCorePkg/Library/OcAppleKernelLib/CommonPatches.c at PatchUsbXhciPortLimit2(...) and see that:

with your change at Library/OcAppleKernelLib/KextPatcher.c -> PatcherApplyGenericPatch(Patcher, &mRemoveUsbLimitV2Patch) returns Error

without that change -> it returns Success.

 

So then I looked in the binary to see why it could happen, and saw the two names, so it seemed to make sense and explain the problem.

 

Edited by Pene
  • Like 1

@ameenjuz I posted my guess.  I'm not currently running Big Sur (I occasionally "visit" BS only to test it), so I can't be certain.  Hopefully my guess offers you a clue.

Edited by tonyx86
8 hours ago, Pene said:

Just checked with hex search inside the binary, and there are 4 occurrences on the Big Sur binary: two with __ZN12AppleUSBXHCI11createPortsEv and two with __ZN12AppleUSBXHCI11createPortsEv.cold.1

I attach the 11.1 binary just in case: AppleUSBXHCI

 

I also checked the Catalina binary, and there are 2 occurrences: one with __ZN12AppleUSBXHCI11createPortsEv and one with __ZN12AppleUSBXHCI11createPortsEv.cold.1

 

Actually, first I put a debug in OpenCorePkg/Library/OcAppleKernelLib/CommonPatches.c at PatchUsbXhciPortLimit2(...) and see that:

with your change at Library/OcAppleKernelLib/KextPatcher.c -> PatcherApplyGenericPatch(Patcher, &mRemoveUsbLimitV2Patch) returns Error

without that change -> it returns Success.

 

So then I looked in the binary to see why it could happen, and saw the two names, so it seemed to make sense and explain the problem.

 

It's BigSur so there's a ARM and an x86 binary inside which means there's going to be two of everything.

I used Hopper to disassemble the x86 (because Hackintosh doesn't use ARM). It got the second one:

                                    __ZN12AppleUSBXHCI11createPortsEv.cold.1:        // AppleUSBXHCI::createPorts() [clone .cold.1]
000000000004305a 55                     push       rbp                          ; CODE XREF=sub_17210+1427
000000000004305b 4889E5                 mov        rbp, rsp
000000000004305e 488D3D084E0000         lea        rdi, qword [aAppleinternalb_47e6d] ; argument #1 for method _panic, "@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/IOUSBHostFamily_Drivers/IOUSBHostFamily-939.60.10/AppleUSBXHCI/AppleUSBXHCI.cpp:2439"
0000000000043065 31C0                   xor        eax, eax
0000000000043067 E8FC990400             call       _panic                       ; _panic

but the first one did not get turned into a proc correctly - I guess this is a bug in Hopper.app. According to your screenshot, the first one is supposed to start at 0x15826:


        ; ================ B E G I N N I N G   O F   P R O C E D U R E ================


                                    sub_15825:
0000000000015825 90                     nop
0000000000015826 55                     push       rbp
0000000000015827 4889E5                 mov        rbp, rsp
000000000001582a 4157                   push       r15
000000000001582c 4156                   push       r14
000000000001582e 4155                   push       r13
0000000000015830 4154                   push       r12
0000000000015832 53                     push       rbx
0000000000015833 4881ECC8000000         sub        rsp, 0xc8
000000000001583a 4989FE                 mov        r14, rdi
000000000001583d 488B05C4880300         mov        rax, qword [qword_4e108]     ; qword_4e108
0000000000015844 488B00                 mov        rax, qword [rax]
0000000000015847 488945D0               mov        qword [rbp+-48], rax
000000000001584b C78554FFFFFF00000000   mov        dword [rbp+-172], 0x0
0000000000015855 488D87BC040000         lea        rax, qword [rdi+0x4bc]
000000000001585c 48894588               mov        qword [rbp+-120], rax
0000000000015860 F687BC04000008         test       byte [rdi+0x4bc], 0x8
0000000000015867 48897D98               mov        qword [rbp+-104], rdi
000000000001586b 0F84D2010000           je         loc_15a43

Anyway, shouldn't Clover be searching for the null string terminator so that it doesn't confuse these two symbols? Or if you want to keep the substring option then add an option to not do substring.

 

  • Like 1

Just upgraded my production rig to r5127.  Upgrade was flawless/easy!  I'm noticing the same ACPI parse error caused by r5127's "Fix SBUS" that I observed in r5122:

 

2021-01-06 10:22:19.632515-0500 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:

2021-01-06 10:22:19.632515-0500 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:

2021-01-06 10:22:19.632516-0500 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) Method parse/execution failed

2021-01-06 10:22:19.632517-0500 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) Method parse/execution failed

2021-01-06 10:22:19.632518-0500 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [\_SB.PCI0.SBUS.BUS0.DVL0._DSM] (Node ffffff80524fb210)

2021-01-06 10:22:19.632519-0500 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [\_SB.PCI0.SBUS.BUS0.DVL0._DSM] (Node ffffff80524fb210)

 

If I disable CLOVER r5127's (and r5122's) "Fix SBUS" and use the attached SSDT instead, this problem is resolved.  Note that the attached SSDT also adds Device (MCHC) (this is an SSDT that I use for OpenCore), so I also disable CLOVER's "Add MCHC" when using the attached SSDT.  My system is completely defined here.

 

 

SSDT-SBUS-MCHC.zip

Edited by tonyx86
  • Like 2
On 1/5/2021 at 5:34 AM, MICKHAEL said:

I think you have a problem) check again your config

 

After upgrading from r5122 to r5127, I "lost" all but two Energy configuration options as shown below.  I tried deleting /Library/Preferences/com.apple.Power...plists and rebooting, but that did not restore the missing energy options.  The only config.plist changes I made from r5122 to r5127 were to add missing Quirks (which I copied directly from the sample plist). Despite the missing Energy Saver options, sleep/wake still works fine after upgrading from r5122 to r5127.

 

@MICKHAEL @MifJpn @Matgen84 @chris1111  I'd value your eagle-eyes to determine the error in my config.  Full problem reporting files are attached.  Thanks!

 

EDIT: On a positive note: I've never had GB5 multi-core benchmarks this good.

 

EDIT2: @MacKonsti Are you by any chance using SMBIOS MacMini8,1 (like I am) with your NUC that is experiencing the Energy Saver issues?

 

Energy Saver Options with CLOVER r5127

Spoiler

204647561_ScreenShot2021-01-06at12_15_49PM.png.1a24387e5938e4fd2c4565ae28537690.png

 

Energy Saver Options with CLOVER r5122

Spoiler

274108965_ScreenShot2021-01-03at11_13_07PM.png.6f73f939f9fe0c5de7f41688bd46c2a2.png.dbf1dd5f2ba80dc0fb914d7788e5a6d5.png

 

debug_10640.zip

Edited by tonyx86
Added link to GB5 benchmarks
  • Thanks 1

Hi

I am currently triple booting my Hack with HighSierra, Mojave and Catalina on the same SSD, with one single EFI partition with Clover 5100 in BIOS mode.
 

Spoiler

iMac:~ phil$ sudo gpt -r show disk0
Password:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 156325576 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
156735216 156325576 3 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
313060792 155801296 4 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
468862088 7
468862095 32 Sec GPT table
468862127 1 Sec GPT header
iMac:~ phil$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *240.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk2 80.0 GB disk0s2
3: Apple_APFS Container disk1 80.0 GB disk0s3
4: Apple_APFS Container disk3 79.8 GB disk0s4
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +80.0 GB disk1
Physical Store disk0s3
1: APFS Volume Mojave SSD512 28.0 GB disk1s1
2: APFS Volume PreBoot 24.6 MB disk1s2
3: APFS Volume Recovery 517.5 MB disk1s3
4: APFS Volume VM 20.5 KB disk1s4
/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +80.0 GB disk2
Physical Store disk0s2
1: APFS Volume Catalina SSD512 - Data 16.1 GB disk2s1
2: APFS Volume Catalina SSD512 11.3 GB disk2s2
3: APFS Volume PreBoot 352.1 MB disk2s3
4: APFS Volume Recovery 2.7 GB disk2s4
5: APFS Volume VM 1.1 MB disk2s5
/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +79.8 GB disk3
Physical Store disk0s4
1: APFS Volume High Sierra SSD512 35.7 GB disk3s1
2: APFS Volume PreBoot 21.6 MB disk3s2
3: APFS Volume Recovery 515.0 MB disk3s3
4: APFS Volume VM 20.5 KB disk3s4


If I put ApfsDriverLoader.efi in the drivers/BIOS folder, Clover as a result shows only the first APFS volumes in the menu, i.e. Catalina.
I do not know which apfs.efi is loaded out of the 2 available on the disk (one per OS) but I guess it's loading the apfs.efi from Catalina as this is the first Volume of the disk. Am I right ?

If I copy the apfs.efi from Catalina (as this is the most recent one, v1412.141.1) to drivers/BIOS and remove ApfsDriverLoader.efi, then Clover show all the APFS Volumes. This allow me to select the OS I want to start.

So apparently it solved my issue but :
1/ is there a better way to do this ? For example by still using ApfsDriverLoader.efi which always load the last version on the disk. But then, why it doesn't work ?
2/ can I really use the same apfs.efi driver for any OS without issue ? I guess I should to use the latest available one, depending on the OS update installed on each of the 3 OS on my SSD ?
3/ is there a way to know which apfs.efi file is loaded by ApfsDriverLoader.efi ? I saw nothing in preboot.log
4/ does ApfsDriverLoader.efi load apfs.efi to show the volumes, but then when you select an OS and start to boot, it does reload the apfs.efi of the selected OS, as part of the normal boot process ?
5/ There is the known side effect : I now face the old issue of messages send to console by apfs.efi when loading : how can I get rid of these and avoid them ?
 
Thanks for your help

Thanks
 
EDIT Jan 10th

I tried to boot with Clover r5128 on a USB Key. Here is an extract from preboot where ApfsDriverLoader.efi is loaded (but do not know which apfs.efi has been loaded) and then all containers are not recognized. Any idea ?
 

3:095 0:000 === [ LoadDrivers ] =============================
3:112 0:016 Loading AudioDxe.efi status=Success
3:129 0:016 - driver needs connecting
3:129 0:000 Loading FSInject.efi status=Success
3:146 0:016 Loading SMCHelper.efi status=Success
3:163 0:016 Loading XhciDxe.efi status=Success
3:180 0:016 - driver needs connecting
3:180 0:000 Loading ApfsDriverLoader.efi status=Success
3:197 0:016 - driver needs connecting
3:197 0:000 3 drivers needs connecting ...
3:197 0:000 PlatformDriverOverrideProtocol->GetDriver overriden
3:197 0:000 APFS driver loaded

../..

8:125 0:016 === [ ScanVolumes ] =============================
8:125 0:000 Found 12 volumes with blockIO
8:125 0:000 - [00]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)
8:125 0:000 Result of bootcode detection: bootable unknown (legacy)
8:125 0:000 - [01]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(1,GPT,C7DCF6FC-3398-4CC0-9281-03DEAB3D2A62,0x28,0x64000)
8:126 0:000 Result of bootcode detection: bootable unknown (legacy)
8:126 0:000 label : EFI
8:126 0:000 - [02]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(2,GPT,9FEEE078-DFB6-4245-B2E9-DA486A646341,0x64028,0x95156C8)
8:127 0:000 Result of bootcode detection: bootable unknown (legacy)
8:127 0:000 - [03]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(3,GPT,11E01983-12EC-42F8-B831-1BDDB4BF393A,0x95796F0,0x95156C8)
8:127 0:000 Result of bootcode detection: bootable unknown (legacy)
8:127 0:000 - [04]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(4,GPT,93F8DC4A-469D-4203-BEEF-1D6C1BD959E4,0x12A8EDB8,0x94956D0)
8:127 0:000 Result of bootcode detection: bootable unknown (legacy)
8:127 0:000 - [05]: Volume: PcieRoot(0x0)\Pci(0x1A,0x0)\USB(0x0,0x0)\USB(0x3,0x0)
8:139 0:011 Result of bootcode detection: bootable unknown (legacy)
8:139 0:000 - [06]: Volume: PcieRoot(0x0)\Pci(0x1A,0x0)\USB(0x0,0x0)\USB(0x3,0x0)\HD(1,MBR,0x00000000,0x2,0x1EA7FE)
8:150 0:011 Result of bootcode detection: bootable unknown (legacy)
8:167 0:016 label : TESTCLOVER
8:167 0:000 This is SelfVolume !!
8:167 0:000 - [07]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(2,GPT,9FEEE078-DFB6-4245-B2E9-DA486A646341,0x64028,0x95156C8)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,092A473E02BA4F4995EDAA22A3DF127B)
8:167 0:000 apfsFileSystemUUID=3E472A09-BA02-494F-95ED-AA22A3DF127B, ApfsContainerUUID=733C664D-FD93-4C88-A6F2-711594B28BC6, ApfsRole=0x10
8:168 0:000 label : PreBoot
8:168 0:000 - [08]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(2,GPT,9FEEE078-DFB6-4245-B2E9-DA486A646341,0x64028,0x95156C8)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,25DDFB1832678B438635A61F885C212A)
8:168 0:000 apfsFileSystemUUID=18FBDD25-6732-438B-8635-A61F885C212A, ApfsContainerUUID=733C664D-FD93-4C88-A6F2-711594B28BC6, ApfsRole=0x40
8:174 0:006 label : Catalina SSD512 - Data
8:174 0:000 - [09]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(2,GPT,9FEEE078-DFB6-4245-B2E9-DA486A646341,0x64028,0x95156C8)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,9BDBFFC41EFCBA439823488236B031B2)
8:174 0:000 apfsFileSystemUUID=C4FFDB9B-FC1E-43BA-9823-488236B031B2, ApfsContainerUUID=733C664D-FD93-4C88-A6F2-711594B28BC6, ApfsRole=0x1
8:179 0:004 label : Catalina SSD512
8:179 0:000 - [10]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(2,GPT,9FEEE078-DFB6-4245-B2E9-DA486A646341,0x64028,0x95156C8)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,E5BCDE05309CD74EBA60B0C031600853)
8:179 0:000 apfsFileSystemUUID=05DEBCE5-9C30-4ED7-BA60-B0C031600853, ApfsContainerUUID=733C664D-FD93-4C88-A6F2-711594B28BC6, ApfsRole=0x4
8:179 0:000 label : Recovery
8:179 0:000 - [11]: Volume: PcieRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0x0,0x0)\HD(2,GPT,9FEEE078-DFB6-4245-B2E9-DA486A646341,0x64028,0x95156C8)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,175955BDE4041D4AA5DED75D940A9587)
8:180 0:000 apfsFileSystemUUID=BD555917-04E4-4A1D-A5DE-D75D940A9587, ApfsContainerUUID=733C664D-FD93-4C88-A6F2-711594B28BC6, ApfsRole=0x8
8:180 0:000 label : VM
8:180 0:000 Searching volumes for latest nvram.plist ...
8:180 0:000 loaded Status=Not Found
8:180 0:000 PutNvramPlistToRtVars: nvram.plist not found

Edited by pctmac
16 hours ago, tonyx86 said:

@ameenjuz I posted my guess.  I'm not currently running Big Sur (I occasionally "visit" BS only to test it), so I can't be certain.  Hopefully my guess offers you a clue.

:thanks_speechbubble: solved above mentioned

sometime i get instant wake reboot on Big Sur 11.1

i have mapped my all usb port correctely but i get this kernel panic

i don't have idea what is this issue  only occure on Big Sur

after reboot i get kernel panic report

i attached screenshot

Spoiler

image.thumb.png.05b5935caf31b913b7e193eaf61b38f7.png

 

7 hours ago, ameenjuz said:

sometime i get instant wake reboot on Big Sur 11.1

i have mapped my all usb port correctely but i get this kernel panic

i don't have idea what is this issue  only occure on Big Sur

You think this is a CLOVER problem (since we're in the Clover General Discussion thread)?  I beg to differ.  Seems like it might be a pmset or sleepimage issue.  Hard to tell anything without your system specs and problem reporting files. I think you'll have more likely success if you post Big Sur post install questions in a thread that discusses your system, or create a new thread in the appropriate forum.  You can then update your post in this thread with a link to your new post / thread.

On 1/5/2021 at 5:34 AM, MICKHAEL said:

I think you have a problem) check again your config

 

@MICKHAEL @MifJpn @Matgen84 @chris1111 - This might help you to identify my "config" problem.  If I retain the exact same config.plist, kexts and ACPI that I'm using with r5127 and I switch back to r5122, all of my Energy Saver options are restored.

 

Energy Saving after switching back to r5122

Spoiler

74382233_ScreenShot2021-01-06at10_50_39PM.png.570a58010152f307fbfd6378ece7d86b.png

 

Whenever I install a new version of CLOVER, I save the config.plist, kexts and ACPI, wipe the EFI, install the new CLOVER from scratch and then restore my config.plist, kexts and ACPI.  I did the same here when I switched back to r5122.

 

Let me know if you see something in my config that is causing this "loss of Energy Saver settings" that occurs when switching from r5122 to r5127.  My full problem reporting files (after switching back to r5122) are attached.  Thanks!

 

EDIT: I have confirmed that my GB5 scores are better with CLOVER r5127 than they are with r5122.  With this "restored" r5122 config (same config.plist, same ACPI, same kexts as r5127), my GB5 scores are back to the r5122 benchmarks that I reported here.  Also of interest is that my minimum CPU multiplier (i7-8700) is 13x with r5122 and 10x with r5127 (max multiplier is 46x with both versions).  I may be alone here and you may be right, but I believe there is something different about r5127 that handles energy differently than r5122.  Call me crazy.

 

cc'ing @MacKonsti

 

@Slice I don't know what "system profile" information is stored in CLOVER, but could this Energy Saver issue be specific to the MacMini8,1 SMBIOS profile that I am using?  If others don't see this strange behavior and they are specifying a different SMBIOS ...

 

debug_28480.zip

Edited by tonyx86
  • Like 1

Thank you, @MifJpn.  I just switched back to CLOVER r5127 and see the same "loss of Energy Saver settings."  I have done my best to limit the changes to the CLOVER version (r5122 vs. r5127 while retaining the exact same config.plist, kexts and ACPI).

  • Haha 1
15 hours ago, tonyx86 said:

After upgrading from r5122 to r5127, I "lost" all but two Energy configuration options as shown below.  I tried deleting /Library/Preferences/com.apple.Power...plists and rebooting, but that did not restore the missing energy options.  The only config.plist changes I made from r5122 to r5127 were to add missing Quirks (which I copied directly from the sample plist). Despite the missing Energy Saver options, sleep/wake still works fine after upgrading from r5122 to r5127.

 

@MacKonsti Are you by any chance using SMBIOS MacMini8,1 (like I am) with your NUC that is experiencing the Energy Saver issues?

 

Energy Saver Options with CLOVER r5127

  Reveal hidden contents

204647561_ScreenShot2021-01-06at12_15_49PM.png.1a24387e5938e4fd2c4565ae28537690.png

 

Energy Saver Options with CLOVER r5122

  Reveal hidden contents

274108965_ScreenShot2021-01-03at11_13_07PM.png.6f73f939f9fe0c5de7f41688bd46c2a2.png.dbf1dd5f2ba80dc0fb914d7788e5a6d5.png

 

 

Yes mate, same Macmini8,1 SMBIOS and exactly the same problem. I reported this few pages back here (13 December) but got no solution, nor some insight from a person who understands the Clover code.
Something must have changed because only CLOVER binary changed (and the handful of drivers used) not Kexts not parameters (and added Quirks instead of AptioMemoryFix) and I also lose wake besides those Energy parameters...

I've given up :(

 

ALSO:  In my other post here, I asked those that have been hackintoshing since 2010 like myself (like @Slice) about the fact that I remember VERY WELL that it was fully advised to TICK the option "Startup automatically after a power failure". This was in every guide. Is this still the case? Perhaps it was for Chameleon, and early Clover. Any idea if we need this ticked/active at all times? I have it anyway, from old habits... your feedback would be very significant, as usual.

 

Anyone can justify this setting please?

Edited by MacKonsti
  • Thanks 1
5 hours ago, tonyx86 said:

 

@MICKHAEL @MifJpn @Matgen84 @chris1111 - This might help you to identify my "config" problem.  If I retain the exact same config.plist, kexts and ACPI that I'm using with r5127 and I switch back to r5122, all of my Energy Saver options are restored.

 

 

Hi @tonyx86 I never see this kind of issue in my system. Can you complete your signature with the details of your configuration, please.
 

The problem occurs on which macOS Catalina (r5122) or Big Sur (r5127)? I do not understand :(

  • Like 1
  • Thanks 1
2 hours ago, MacKonsti said:

ALSO:  In my other post here, I asked those that have been hackintoshing since 2010 like myself (like @Slice) about the fact that I remember VERY WELL that it was fully advised to TICK the option "Startup automatically after a power failure". This was in every guide. Is this still the case? Perhaps it was for Chameleon, and early Clover. Any idea if we need this ticked/active at all times? I have it anyway, from old habits... your feedback would be very significant, as usual.

 

Anyone can justify this setting please?

"Startup automatically after a power failure" means if there is a power blackout your computer will start automatically after the power is restored, there aren't any big meaning in this. If you want your computer to start automatically after a blackout, tick. If not, then untick.

 

Also about the Power Options. I sold my ASUS Z170 system, but I did have those Power Options on Clover v5127. Maybe it's related to HWP, I have that enabled. I remember days from High Sierra when you only could have those options if you enabled HWP in Clover.

Edited by kushwavez

Hi @kushwavez thanks, I am aware of the true nature of this setting on real Macs. But this was advised from old days to keep it ticked/enabled for a specific reason, most likely related to sleep or wake so that they both work. Not related to rebooting on power-failure really but rather wake, I think. The BIOS (possibly pre-UEFI) was starting with some parameters that older Mac OS X versions did or didn't like. This is a puzzle and can't find an exact technical explanation as either Chameleon or early Clover reference, but I am certain of this been needed in the past. Was hoping that someone would vividly remember why and explain if it is needed.

 

As an example, look at this https://forum.thinkpads.com/viewtopic.php?t=86621: SleepFix: Turn off "use secured virtual memory" in System Preferences->Security ( to get rid of an annoying starting message "Error 192 ...") and Turn On "startup automatically after a power failure" in System Preferences->Energy Saver

3 hours ago, kushwavez said:

Clover v5128 (git release), Notebook 1:

Big Sur 11.1 system: OK

Big Sur 11.1 Recovery: Instant restart, see log

 

2021-1-7_8-16-1_CLOVERX64.efi.log 38.74 kB · 0 downloads

BigSur Recovery is still not implemented. Sorry!

  • Thanks 1
  • Sad 1

Oh so it's "normal". No problem then! 

If it's not so much could you please explain what is changed in Big Sur Recovery? Is it booting directly from "BaseSystem.dmg" so that's why it's not working anymore?

Sorry if I'm babling nonsense, I didn't look into how the new Recovery working so much. :D 

2 hours ago, MifJpn said:

Thank you for your help! 
As promised, I went home and tried it with Clover 5122 and 5127.
As you know, config.plist cannot be the same.

Also, SSDT-PMC.aml for NV-RAM for Intel 300 series is included in both Clover5122 and 5127.

In addition, SSDT-AWAC.aml, SSDT-EC-USBX-DESKTOP.aml, and SSDT-PLUG-DRTNIA.aml derived from Dortania are applied to Clover 5127. (I think these are the standard aml after OC integration.)

Kext is also the latest at that time. (Since the result is as follows, the equivalization test was canceled.)

 

I tried to review your r5127 and r5122 configurations and failed to understand what you were testing or what you were trying to demonstrate.  One config.plist includes boot-arg -lilubetaall when the other does not, one includes DeviceProperties for PciRoot(0x0)/Pci(0x1f,0x3) and PciRoot(0x0)/Pci(0x2,0x0) while the other does not.  Also, your kext versions are different (Lilu is 1.4.7 in one EFI and 1.5.0 in the other EFI).  I really do appreciate your help - do you think these two EFIs are valid tests to determine the differences between r5122 and r5127?

 

"As you know, config.plist cannot be the same" - I do not agree.  The config.plists can be the same.  r5122 should ignore some of the extra Quirks required by r5127.  I believe that my config.plist is valid for both versions of CLOVER.  Thank you again for your help!

4 hours ago, Matgen84 said:

 

Hi @tonyx86 I never see this kind of issue in my system. Can you complete your signature with the details of your configuration, please.
 

The problem occurs on which macOS Catalina (r5122) or Big Sur (r5127)? I do not understand :(

 

Thank you for your help. The problem occurs in r5127 (if it were in r5122 and fixed in r5127, that would be a good thing - right?).  I'm running Catalina 10.15.7 with both versions of CLOVER.  I have updated my signature - thank you for pointing that out! My system is fully documented here.  Thank you!

Edited by tonyx86
  • Like 1
17 minutes ago, tonyx86 said:

 

Thank you for your help. The problem occurs in r5127 (if it were in r5122 and fixed in r5127, that would be a good thing - right?).  I believe I have set my signature (Profile > About Me) - is that correct?  My system is fully documented here.  Thank you!

 

System: HP EliteDesk 800 G4 Mini: Q370 Chipset, I7-8700 CPU, UHD 630 Graphics, 32GB DDR4 (SMBIOS MM8,1)

 

Thanks. In your topic, your signature is present. To set it, at top right: users/account settings/signature :) Your problem occurs with r5127 on Catalina, right ? I don't find your r5127 EFI folder in your topic.

 

×
×
  • Create New...