Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8,888 posts in this topic

Recommended Posts

Sniki
Sniki
Posted
Posted (edited)
15 minutes ago, NorthAmTrans said:

@Snikii of course! 

 

A couple things. Rename patches are frowned on with OC. Someone here with a more articulate answer can fill in the blanks here but the short of it all is that they cause problems and should be avoided. I would go through and figure out which ones are actually necessary and then find some help here about how to make or find a patch for them. 

 

I don't know much about laptops here but for pure lucks sake try setting LegacyEnable to YES.

 

You should join the InsanelHack Discord. There is a channel there for OpenCore Laptops. Best of luck to ya. Report back with some progress!

The core problem is supposed to be somewhere in Quirks not on ACPI Renames as nothing is affecting CPU in terms of ACPI aside the Quirks and other General Options.

 

There is no way to make a laptop work without rename patches at the current stage not even with OC (there are only rare cases).

 

You need to patch EC Registers that are more than 8-bit that are battery related in order to have Battery Status working (whether you use ACPIBatteryManager.kext + FakeSMC.kext or VirtualSMC.kext + SMCBatteryManager.kext).

 

You need to patch/rename GPRW or a _PRW that causes instant wake from sleep.

 

You need to patch/rename ESEL, XSEL, XWAK (if present) as they cause issues with USB Ports

 

You need to patch/rename your Qxx methods for Fn Buttons like brightness and others so they can work natively without the need of 3rd party apps.

 

You need to patch/rename BAT0 and BAT1 notifiers to BATC if your laptop does have dual batteries so you can use SSDT-BATC to merge dual batteries into one and have hotswap functionality as dual battery support on macOS is bugged/not working natively.

 

ETC

 

But yes i do agree that with OC compared to Clover we need less more than we used.

Edited by Snikii
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
1 hour ago, rusty-bits said:

Hey @Pavo

Thanks for the reply. Sorry for appearing critical of ocBuilder.

 

I tend to shy away from things than need admin privileges. I try to put binaries into /usr/local/bin when possible to avoid the need for admin. As for ACPI and the Tools folder, I'm well aware that ocBuilder takes care of those, the point was that my tool doesn't yet.

 

I thought it would be a fun challenge to see if I could make a command line tool that will read the config.plist and then build a complete EFI folder based on it.

 

Anyways, thanks again for the reply, and thanks for all your work! :thanks_speechbubble:

Not at all, just some of the things you listed out where wrong and wanted to correct those things for you.

 

Thanks about the /usr/local/bin, I did not realize you did not need root privileges in order to install the build tools inside that location. I have updated my app to remove the root privileges now.

 

I would assume you can do that using /usr/libexec/PlistBuddy, with that being said, Apple has removed that tool from Catalina though.

 

  • Like 1
Link to comment
Share on other sites
rusty-bits
rusty-bits
Posted
Posted
4 hours ago, Pavo said:

I would assume you can do that using /usr/libexec/PlistBuddy, with that being said, Apple has removed that tool from Catalina though.

Nice to hear about ocBuilder, I'm going to check it out again.

 

Yes, I'm using PlistBuddy in the auto branch of my tool.  It reads the Drivers and Kexts from config.plist, then gets the repo url from a repo.plist.

It's working okay, but some of the code still feels quite clunky and needs more work.  

It figures that Apple removed the PlistBuddy tool from Catalina. Thanks a lot, Apple.

Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
6 minutes ago, rusty-bits said:

Nice to hear about ocBuilder, I'm going to check it out again.

 

Yes, I'm using PlistBuddy in the auto branch of my tool.  It reads the Drivers and Kexts from config.plist, then gets the repo url from a repo.plist.

It's working okay, but some of the code still feels quite clunky and needs more work.  

It figures that Apple removed the PlistBuddy tool from Catalina. Thanks a lot, Apple.

Seems they replaced PlistBuddy with plutil.

  • Thanks 2
Link to comment
Share on other sites
gengik84
gengik84
Posted
Posted
12 hours ago, Pavo said:

I would assume you can do that using /usr/libexec/PlistBuddy, with that being said, Apple has removed that tool from Catalina though.

Maybe in the future?
for now it is always here 

iMacdiGengik84:~ $ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.15
BuildVersion:	19A536g
iMacdiGengik84:~ $  ls /usr/libexec | grep PlistBuddy
PlistBuddy

 

Link to comment
Share on other sites
STLVNUB
STLVNUB
Posted
Posted
5 minutes ago, bronxteck said:

yes i tried it on an imac yesterday. the only thing is you have to hold the option key at boot to load OC first.

I think the idea is to bless bootx64.efi then it loads by itself

 

Link to comment
Share on other sites
leesureone
leesureone
Posted
Posted
On 8/15/2019 at 10:00 PM, Matgen84 said:

 

Your DSDT is good and effective (idem on CLOVER/ Catalina). I don't want to blame it on OC: I apologize for my comments. (Sorry for my bad english)

 

I was wrong to review the config.plist with Opencore configurator (macKie app) and save it by habit. What must have broken it, maybe.

 

So I want to continue to use DSDT + Config.plist on my Gigabyte Z390 system for testing OpenCore. 

 

Thanks

Hello, I was wondering if you ever got your OC configuration going? I've got the same motherboard and wondering if you would mind sharing your EFI folder?

Link to comment
Share on other sites
bronxteck
bronxteck
Posted
Posted (edited)

i got the imac to boot to OC directly.

i had to boot to recovery but i had to enable AppleBootPolicy in OC uefi in config.plist to be able to boot recovery from OC.

then i had to run terminal and do 

csrutil disable

then reboot into catalina then in terminal use  

sudo bless --device /dev/disk0s1 --file BOOTx64.efi --setBoot

my imac has only one internal drive hence disk0s1

the only weird thing i have noticed is that i had one instance of the machine not wanting to power on and since then my fans have been running full blast since. but the imac does power on and function. also sometimes the apple mouse gets disconnected

 

edit: i did an SMC reset and the fans are back to normal. i powerd off the machine. pulled the power cord for 15 seconds. plugged it back in waited 5 seconds then powered on the imac.

 

Edited by bronxteck
Link to comment
Share on other sites
canyondust
canyondust
Posted
Posted
41 minutes ago, bronxteck said:

 

edit: i did an SMC reset and the fans are back to normal. i powerd off the machine. pulled the power cord for 15 seconds. plugged it back in waited 5 seconds then powered on the imac.

 

Were you able to reenable SIP after this?

Link to comment
Share on other sites
tunglamvghy
tunglamvghy
Posted
Posted (edited)
On 8/20/2019 at 9:48 PM, tmbt said:

Hi guys,

i've performed a major upgrade from an old OpenCore version 0.2 to the new 0.4. While doing that i also upgraded most of my kexts (Lilu, whatervergreen etc).

After that i'm having a message while loading the MacOS :

Dependency com.apple.iokit.IOHIDSystem fallback to com.apple.iokit.IOHIDSystem succeded. Please fix your kext!

 

It appears while macos is loading on top of the Apple and the loading bar. The system is working as usual but i would like to fix it anyway. 

Could someone please point me on the right direction ?

 

Thanks


Mattia

 

I've the same issue but it stop booting. Have you fix it yet?

Edited by tunglamvghy1210
Link to comment
Share on other sites
STLVNUB
STLVNUB
Posted
Posted
15 hours ago, bronxteck said:

yes i tried it on an imac yesterday. the only thing is you have to hold the option key at boot to load OC first.

Can you please share your OC, mine does nothing

Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted
17 hours ago, Sniki said:

Hi @vit9696

It's a Haswell laptop not ivy bridge.

Intel Core i5 4300U

Hmm, I rechecked your panic screen, and to be honest it does not even look like a CFG Lock (or any MSR stuff), more like dereferencing null pointer. Perhaps you should consider looking somewhere else.

 

16 hours ago, STLVNUB said:

I think the idea is to bless bootx64.efi then it loads by itself

 

Correct, and you use a separate GUID space with FwRuntimeServices.efi to avoid other options getting into your way of running.

Link to comment
Share on other sites
hardcorehenry
hardcorehenry
Posted
Posted

Sorry @PMheart , but I think this fragment has to be corrected:

 

call in XNU kernel. Normally it is only the value of \texttt{EAX} that needs to be taken care of,
which represents the exact CPUID. And the remainders are to be left as zeroes.
For instance, \texttt{A9 06 03 00} stands for CPUID \texttt{0x0306A9} (Ivy Bridge).
A good example can be found at
\href{https://github.com/acidanthera/bugtracker/issues/365}{acidanthera/bugtracker\#365}.

(See \texttt{Special NOTES for Haswell+ low-end})

 

I used to boot my Intel Pentium Haswell with fake CPUID Ivy Bridge 0x0306A0

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...