Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Redo the DeviceProperties part. It looks like you got the nesting wrong.
Figured out my sleep issue. It’s Safari 16.1 causing issues sometimes. If I quit it, no sleep preventers. Reopen it and all the tabs, and it sleeps again. Maybe a bug in Safari?
None. Seems to be working now after quitting and restarting Safari.
You need to ask in the OCLP thread or better in the OCLP Discord. This isn't where deep OCLP users hang out.
Correct. There are a lot of smart, helpful people here but they are focused on the method outlined in Post #1 - hand coding OC.
You will get better, faster, more reliable OCLP help in the OCLP Discord.
AFAIK, OCLP requires custom SIP to work with Monterey and MacPro5,1 and, AFAIK, won't work with SIP enabled.
Only if patching is needed. If you do the same as most users on this thread (i.e. changing hardware to have it supported by the latest macOS version like using and AMD Polaris+ dGPU and a BT/WiFi upgrade connecting it to an USB2+ port) OCLP will allow you to disable SIP and enable SecureBootModel in the very same way as described here.
Users can limit the setup to the latest macOS supporting the available hardware, i.e. running Big Sur with a Kepler dGPU and leave SIP enabled, or move on to Monterey, allow root patching and have to sacrifice SIP and SBM.
There is no hard requirement to disable SIP on a MacPro5,1 running Monterey.
Thx for the clarification on disabling SIP not being a hard requirement for OCLP to work. Even if it's not required, that's a lot of fine print that most users will not understand, this probably needs more info on the OCLP setup guide.
As far as I know: Whether enabled or not, SIP is “hardwired” in OCLP. This is a source of confusion for many who try to disable SIP in Recovery and then realize that the setting has not taken.
Exactly: “the patcher will always overwrite the current SIP value on boot”.
On a computer not mine I tried to fully disable SIP by clicking all options in the OCLP Configure SIP Settings dialogue. That was useless, as OCLP totally disregarded my wishes and set a csr-active-configuration of its own choosing, i.e., not fully disabled. That made it impossible to install XtraFinder on the target Mac.
I haven't tried that yet on that computer, but it would appear that tweaking the OCLP config.plist might achieve the desired results if something like the following is entered:
NVRAM->Add->7C436110-AB2A-4BBB-A880-FE41995C9F82->csr-active-config=FF0F0000, or perhaps 67000000 or perhaps 6F020000.
Care to comment?
Just implement a solution to patch Ventura without setting the SIP in the config.plist. Fork OCLP, develop a different version fitting to the habits and needs of your user base and support it. It is that easy and you can avoid all the confusion. But stop posting half knowledge about OCLP, better send all requests to Discord.
Hey, don't you think that you are getting too aggressive here? We are all trying to help here.
Woah there. First, I am not posting half knowledge about OCLP. The link you posted describes exactly what I mentioned: the patcher overrides native control of SIP. This is a source of confusion for many, and that is the reason an entry has been included in the troubleshooting documentation. Second, because I understand the decision for overriding this control in OCLP, I will not go and meddle with it. It is a matter of respect for the larger scope of the project.
I watched a video where one hackintosh youtuber recommended using iMacPro1.1 spoofing for old xeon processors.
I tested Martin's config today, he just uses it.
no difference in performance in programs: Blender, UE5, Twinmotion, tested in all standard benchmarks.
there is no difference at all for me in the performance with OCLP, cdf, or Martin's config
probably still the main advantage is given to me by the GPU, which works with Lilu and Whatevergreen
and other settings simply should not harm the operation of the computer - they do not cause panic, they work correctly with PCi, USB or with ssd
worked for a whole week with cdf config- works fine, sleep/wakeup is ok, no issues
now i will test Martin's config, maybe I'll find a difference at least in something
Can anyone tell me why there are duplicate processes?
this is normal?
I understand that shaders in UE5 are compiled by each processor, since I have 12, then 12 processes
but I only observed standard root processes when opencore was configured incorrectly (for example, an outdated 0.8.0 martin could produce artifacts)
but now I'm using the new 0.8.6 according to cdf instructions
I’m asking this because I tested a new oclp a week ago, I didn’t notice a difference in performance, but when I returned to opencore, after turning off the computer for the night, in the morning I had a 40% kernel task
which was deleted only by reset smc and reset nvram
but every morning the process arose again
I deleted it this weekend by reinstalling macos
so i can conclude:
for my hardware, oclp (I don’t know why) it’s harmful (but it’s not completely clear why - for experiment, I set oclp without spoofing and with spoofing)
I'm already afraid that the developers of the ocpl will start to swear!
as I noted earlier that I had rebooted into Windows before leaving traces in nvram or somewhere else (for example, in the GPU)
maybe oclp also left traces
especially my hardware is strange: all owners of cMP can reset nvram many times
But my hardware allows only a one-time reset
- and obviously I use a wired keyboard to reset
and the main purpose of my post:
I don't like how my wireless magic mouse has been working for the last week (since 0.8.6)
this is normal?
I understand that shaders in UE5 are compiled by each processor, since I have 12, then 12 processes
but I only observed standard root processes when opencore was configured incorrectly (for example, an outdated 0.8.0 martin could produce artifacts)
but now I'm using the new 0.8.6 according to cdf instructions
I’m asking this because I tested a new oclp a week ago, I didn’t notice a difference in performance, but when I returned to opencore, after turning off the computer for the night, in the morning I had a 40% kernel task
which was deleted only by reset smc and reset nvram
but every morning the process arose again
I deleted it this weekend by reinstalling macos
so i can conclude:
for my hardware, oclp (I don’t know why) it’s harmful (but it’s not completely clear why - for experiment, I set oclp without spoofing and with spoofing)
I'm already afraid that the developers of the ocpl will start to swear!
as I noted earlier that I had rebooted into Windows before leaving traces in nvram or somewhere else (for example, in the GPU)
maybe oclp also left traces
especially my hardware is strange: all owners of cMP can reset nvram many times
But my hardware allows only a one-time reset
- and obviously I use a wired keyboard to reset
and the main purpose of my post:
I don't like how my wireless magic mouse has been working for the last week (since 0.8.6)
The acclaimed "Blame OCLP whenever something goes wrong" strategy. Patent pending.
good joke
followers of the ocpl are just like a sect, nothing can be said about them
and about ocpl I wrote as a joke
my main message in the post:
I'm constantly experimenting with configs
if someone writes about the problem, I also try to check how it will be for me
if I do not experiment, then I can safely work on my hardware without encountering a single problem
but out of curiosity i try to check what the community is reporting
and because of this I break the normal operation of the configured cMP
I asked a question:
1. Is it correct that processes are cloned?
2. and for the first time in 2 years of using a wireless mouse, I am experiencing a problem