Jump to content
8755 posts in this topic

Recommended Posts

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.

@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

@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?

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.

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

 

@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.

 

That compiling does not work for me.... all kinds of error of header files not found... after I copy them manually... all kinds of compiling errors...

Sorry.... I am not knowledgeable enough with these tools.

Mike

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!

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

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.

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?

"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",

 

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.

 

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

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
On 1/11/2020 at 9:43 PM, nmano said:

Skylake X->Skylake U 0x0406E3
Cpuid1Data   <->  E3060400 00000000 00000000 00000000 
Cpuid1Mask  <->   FFFFFFFF 00000000 00000000 00000000 

 

 

What does this do? Is this worth applying on an X299 board with an i9 7900X?

  • Like 1
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
10 hours ago, jinbingmao said:

"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",

 

 

It 10.15.3 beta

3 hours ago, canyondust said:

Updated to OC 0.5.4 with all updated resources, kexts, etc without issue. Seem to have gained about 7% performance as well!

(Though on this update I went from manual platform info to automatic so that might be a factor)

Fantastic work devs!

 

what do you mean 7% performance boost? what kind of performance?

1 hour ago, justin said:

 

what do you mean 7% performance boost? what kind of performance?

 

GB5 scores went from an average of 1080sc/4650mc to 1250sc/4950mc. The only difference has been upgrading from OC 0.5.3 to OC 0.5.4 and all related support files and kexts. Possible that I had something incorrectly configured in the old version that got corrected in the new version? potentially, but all I did was add the new config parameters to my old config.plist, as well as the aforementioned switch from manual platform info to automatic platform info.

×
×
  • Create New...