Jump to content

OpenCore General Discussion


dgsga
8,888 posts in this topic

Recommended Posts

I've just made the switch from Clover to OpenCore and generally everything is working great once it's booted. My only problem is that I use FileVault and my boot process seems to hang for anything from 20-60 seconds with the Apple logo on the screen before I'm asked for my password.

 

I've attached my OC debug log, the issue seems to be in this section:

 

04:091 00:003 OCABC: Only 187/256 slide values are usable!
04:095 00:003 OCABC: Valid slides - 0-167, 237-255
24:547 20:452 Trying XNU hook on System\Library\PrelinkedKernels\prelinkedkernel
24:561 00:013 Kext reservation size 7979008
25:340 00:779 Result of XNU hook on System\Library\PrelinkedKernels\prelinkedkernel is Success
25:356 00:015 OC: Read kernel version 19.2.0 (190200)

I'm using the OC Debug version with Target 83 verbose debugging, but nothing shows on the screen except that logo during the hang.

 

System: iMac17,1 - i7-6700k, Asus Z170 Pro w/ RX 580 GPU

opencore-2020-01-12-163735.txt

Link to comment
Share on other sites

@Mike Ranger, ForceBoost was broken at the time you tried it. It should be fixed now, but indeed I strongly do not recommend it, as it maxes frequency. The quirk is designed for specialised setups. The PCI patch is implemented in master, but we cannot test it.

 

@Sniki, generally we use WhateverGreen to disable discrete GPU. As for battery, I am afraid somebody else knows better.

 

@floodlitworld, this sounds like an older Dell issue. Please check UEFI → Input preferences. Perhaps playing with the timer resolution will improve the situation for you. Also make sure there are no conflicting UEFI drivers, just in case.

Edited by vit9696
Link to comment
Share on other sites

6 minutes ago, vit9696 said:

 

@floodlitworld, this sounds like an older Dell issue. Please check UEFI → Input preferences. Perhaps playing with the timer resolution will improve the situation for you. Also make sure there are no conflicting UEFI drivers, just in case.

 

I'm only running ApfsDriverLoader, FwRuntimeServices, HFSPlus and VirtualSmc in my drivers, so nothing I can drop there.

 

This is the config I'm running.

config.plist

 

I'm running a TimerResolution of 60000 since I have an ASUS motherboard.

Edited by floodlitworld
Link to comment
Share on other sites

27 minutes ago, vit9696 said:

Not sure we can help with this. Does password menu appear quickly if you set KeySupport to NO? You may not be able to access OpenCore menu in this casem however.

Turned off KeySupport... didn't get to the screen any faster and my keyboard stopped working on the login screen too. Had to boot from USB to recover.

 

Seem to be getting diverted to the MacOS Password Recovery screen 9/10 boots now... System won't boot properly until I click the "Restart" button on the Password Recovery screen.

 

Shame... OC is working great once it gets me to that password screen.

Link to comment
Share on other sites

@vit9696... you did it!!!! with the latest quirk IncreasePciBarSize I can boot without a single kext / kernel patch needed anymore!!! This is outstanding!!!

Many thanks for your ongoing focus on execution! The last 4 weeks have brought so many improvements, and I am very impressed.

 

Best, Mike

 

  • Like 1
Link to comment
Share on other sites

@floodlitworld, this issue sounds like some pretty serious issue in your firmware. Did you have it with Clover? Did you use AppleUiSupport driver with Clover? If not, does it work for you? Also, you have OpenCore Debug mentioned in your signature, does the issue happen with release builds as well?

Link to comment
Share on other sites

26 minutes ago, vit9696 said:

@floodlitworld, this issue sounds like some pretty serious issue in your firmware. Did you have it with Clover? Did you use AppleUiSupport driver with Clover? If not, does it work for you? Also, you have OpenCore Debug mentioned in your signature, does the issue happen with release builds as well?

No. It didn't happen with Clover. I did use AppleUISupport. My Clover EFI driver folder contained:

  1. ApfsDriverLoader
  2. AppleGenericInput
  3. AppleUISupport
  4. AptioMemoryFix
  5. HFSPlus
  6. UsbKbDxe
  7. VirtualSmc

Rebooted with the release version. It didn't go to password recovery this time and only stalled for about 15 seconds.... so better.

Is there anything else that could help? Reinstall BIOS firmware? Add extra drivers etc? Otherwise I'll just have to live with it. I don't restart more than once or twice a day. So it's not intolerable if it can't be fixed.

Link to comment
Share on other sites

I just saw the following, never really paid attention.....

 

Just before the picker menu is shown, is see a short message:

 

OCS: failed to parse data field of type 2

 

Since everything seems to work fine.... I closely checked the config.plist file again.... I could not find anything.

 

My question: is this something I should investigate... if yes... what could be the reason?

 

Thanks, Mike

 

Link to comment
Share on other sites

@floodlitworld, UsbKbDxe conflicts with AppleGenericInput in Clover. I would suggest you to remove it and check if there are any bugs.

 

As for OpenCore, could you try removing FwRuntimeServices? macOS will not boot, but it is interesting to see if that affects the situation anyhow. Also, I do not think your motherboard needs RequestBootVarRouting. In addition to that, I remember X99 boards had serious issues with hashing services, please set HashServices to YES.

 

@Mike Ranger, this means that some of the <data> fields in your configuration do not seem to be right. One can use OcSupportPkg/TestsUser/Serialized tool to debug configuration issues. Serialized.c contains the compilation command in the beginning of the file (clang -g -fsanitize=undefined,address …). Just compile it in Serialized directory and then pass your config.plist as an argument to see a verbose validation log.

 

Link to comment
Share on other sites

40 minutes ago, vit9696 said:

@floodlitworld, UsbKbDxe conflicts with AppleGenericInput in Clover. I would suggest you to remove it and check if there are any bugs.

 

As for OpenCore, could you try removing FwRuntimeServices? macOS will not boot, but it is interesting to see if that affects the situation anyhow. Also, I do not think your motherboard needs RequestBootVarRouting. In addition to that, I remember X99 boards had serious issues with hashing services, please set HashServices to YES.

I haven't got the Clover install anymore, so I can't check on that one.

 

Tried out those things. Complete failure to boot without the RequestBootVarRouting and HashServices didn't make any difference.

 

Think I might just have to grin and bear this one. Thanks for your help anyway!

Link to comment
Share on other sites

1 hour ago, vit9696 said:

@floodlitworld, UsbKbDxe conflicts with AppleGenericInput in Clover. I would suggest you to remove it and check if there are any bugs.

 

As for OpenCore, could you try removing FwRuntimeServices? macOS will not boot, but it is interesting to see if that affects the situation anyhow. Also, I do not think your motherboard needs RequestBootVarRouting. In addition to that, I remember X99 boards had serious issues with hashing services, please set HashServices to YES.

 

@Mike Ranger, this means that some of the <data> fields in your configuration do not seem to be right. One can use OcSupportPkg/TestsUser/Serialized tool to debug configuration issues. Serialized.c contains the compilation command in the beginning of the file (clang -g -fsanitize=undefined,address …). Just compile it in Serialized directory and then pass your config.plist as an argument to see a verbose validation log.

 

If you delete FwRuntimeServices.efi then there will be a circle with a bevel line ->  -> circle with a bevel line -> 

 

RequestBootVarRouting --- I do not need

Thanks for OPENCORE

Link to comment
Share on other sites

Ugh, of course I meant RequestBootVarFallback. RequestBootVarRouting is needed on all hacks with OpenCore for default boot volume selection to work. Anyway, I guess, we will try to explore this issue and let you know if we find anything.

Link to comment
Share on other sites

7 hours ago, vit9696 said:

@floodlitworld, try with 0. 60000 only applies to ASUS Z87 boards.

 

The documentation makes it sound as though the 60000 value applies to all ASUS boards:

 

Quote

The recommended value is 50000 (5 milliseconds) or slightly higher. ASUS boards use 60000 for the interface. Apple boards use 100000. 

 

Should that be updated? Want a PR?

Link to comment
Share on other sites

"MacBookPro15,1", "MBP151.88Z.F000.B00.1912090131", "1037.80.21.0.0", "Mac-937A206F2EE63C01",


"MacBookPro15,2", "MBP152.88Z.F000.B00.1912090107", "1037.80.21.0.0", "Mac-827FB448E656EC26",

"MacBookPro15,3", "MBP153.88Z.F000.B00.1912082358", "1037.80.21.0.0", "Mac-1E7E29AD0135F9BC", 

"MacBookPro15,4", "MBP154.88Z.F000.B00.1912090124", "1037.80.21.0.0", "Mac-53FDB3D8DB8CA971",

 "MacBookPro16,1", "MBP161.88Z.F000.B00.1912090148", "1037.80.21.0.0", "Mac-E1008331FDC96864", 

 "MacBookAir8,1", "MBA81.88Z.F000.B00.1912090041", "1037.80.21.0.0", "Mac-827FAC58A8FDFA22", 

"MacBookAir8,2", "MBA82.88Z.F000.B00.1912090131", "1037.80.21.0.0", "Mac-226CB3C6A851A671", 

"Macmini8,1", "MM81.88Z.F000.B00.1912082323", "1037.80.21.0.0", "Mac-7BA5B2DFE22DDD8C",

 "iMacPro1,1", "IMP11.88Z.F000.B00.1912082323", "1037.80.21.0.0", "Mac-7BA5B2D9E42DDD94", 

 "MacPro7,1", "MP71.88Z.F000.B00.1912090148", "1037.80.21.0.0", "Mac-27AD2F918AE68F61",

 

Link to comment
Share on other sites

Quick question.... what to do about in the compile errors for the serialized tool?

Anybody can help with the compile?

This error is driving me nuts.

Thanks, Mike

Quote

 Ranger, this means that some of the <data> fields in your configuration do not seem to be right. One can use OcSupportPkg/TestsUser/Serialized tool to debug configuration issues. Serialized.c contains the compilation command in the beginning of the file (clang -g -fsanitize=undefined,address …). Just compile it in Serialized directory and then pass your config.plist as an argument to see a verbose validation log.

 

Link to comment
Share on other sites

5 hours ago, Tony Arnold said:

 

The documentation makes it sound as though the 60000 value applies to all ASUS boards:

 

 

Should that be updated? Want a PR?

We have already updated the docs.

 

2 hours ago, Mike Ranger said:

Quick question.... what to do about in the compile errors for the serialized tool?

Anybody can help with the compile?

This error is driving me nuts.

Thanks, Mike

 

Find the error manually for the time being. We will add some build scripts for user tools later.

  • Like 1
Link to comment
Share on other sites

tried the same thing with the provided clang command..... full off errors... mostly missing headfiles.

Probably need to download more stuff and put it in the right structure.

I just downloaded the OCSupportPkg Folder and tried to compile from there.

Edited by Mike Ranger
Link to comment
Share on other sites

17 hours ago, vit9696 said:

generally we use WhateverGreen to disable discrete GPU. As for battery, I am afraid somebody else knows better

Thanks @vit9696 if im correct i think it is documented as it disables external/Dedicated GPU, thanks for the clarification

 

So by that now i know that includes discrete graphics on laptops as well. Nice.

 

I wanted to discuss about Dual Battery support on VirtualSMC/smcbatterymanager.kext

Laptops with Dual Batteries are very common.

MacOS itself has buggy/no dual battery support.

 

As a current solution we use SSDT-BATC.dsl from RehabMan which does work but is not a Acidanthera guidelines friendly solution.

 

What we do with it is that we combine both batteries into a single one and for that to work we also have modify battery notifiers of BAT0 and BAT1 into BATC in order to have correct battery percentage reporting.

For now im modifying battery notifiers with ACPI renames like:

_SB.PCI0.LPCB.EC.BAT0, 0x80 to .....BATC, 0x81.

Usually the notifiers are located into Methods like Method (_Q69,...) etc.

 

I believe with a slight modification for the SSDT to work only with Darwin and if it is possible on virtualsmc side to include a boot-arg or something similar to rename these notifiers in i/o registry level we can have a decent solution.

Or maybe even better solution that those.

 

Its is not a high priority thing but it would be nice to add this if and when it is possible.

 

So what do you think of raising this matter on bugtracker, the number of affected people is decent but the number of them with technical knowledge regarding this is very small, they basically use the guides that we/us with a bit more knowledge make and use them as they are.

I have guides for most of the Haswell Generation Lenovo ThinkPads and pretty much 80% of them have dual batteries, 1 internal and 1 external (removable).

 

Thanks !

Edited by Sniki
Link to comment
Share on other sites

×
×
  • Create New...