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
A friendly heads-up to all owners of flashed GPUs, at least those similar to my own AMD Radeon HD 7970 3 GB: The new GopBurstMode parameter, if activated, may cause the dreaded prohibitory sign to appear at boot time! I had to get rid of it for 0.9.1 to work on my cMP.
You couldn't pop over a debug log of the failed boot, could you? Also if at all possible the SysReport/GOP/GOPInfo.txt file, generated on a run with the new option disabled? Tyvm.
Last edited:
Okay. If you do have time to do it, you can just use
cp -r ~/Downloads/OpenCore-0.9.1-DEBUG/X64/EFI /Volumes/EFI and cp -r ~/Downloads/OpenCore-0.9.1-RELEASE/X64/EFI /Volumes/EFI to switch between versions (assuming you are not using secure boot or vaulting, which I am assuming you would not be).
Last edited:
@cdf (or anyone else who might know)
Per your advice in the Titan Ridge thread, I tried loading the unmodified Titan Ridge SSDT from post #1, and that solved both issues--I am now seeing Apple branding for the card in System Profiler and my USB 3 devices are working.
Should I just go ahead and use this SSDT as-is, or should I attempt to modify it again per your instructions in post #1? I guess since everything seems to be working fine now I'm tempted to leave it alone. But maybe there is some additional reason I should be customizing it.
Is modifying the SSDT only necessary if someone has the card in a slot other than slot 4?
Per your advice in the Titan Ridge thread, I tried loading the unmodified Titan Ridge SSDT from post #1, and that solved both issues--I am now seeing Apple branding for the card in System Profiler and my USB 3 devices are working.
Should I just go ahead and use this SSDT as-is, or should I attempt to modify it again per your instructions in post #1? I guess since everything seems to be working fine now I'm tempted to leave it alone. But maybe there is some additional reason I should be customizing it.
Is modifying the SSDT only necessary if someone has the card in a slot other than slot 4?
The reason for customizing the SSDT (as described in post #1) is to ensure that the card has a unique ID. See post #11,981.
By the way, I think that the issue with your custom SSDT (posted over on the TB3 AIC thread) is that it is missing the ThunderboltConfig block. You can use MaciASL to copy it over from the sample.
@Bmju: Please, excuse my ignorance. I'm planning to do as requested next evening (it's morning now in Europe). I plan to install the debug build of OC 0.9.1 on a USB flash drive and boot from it (I don't want to mess with the "release" OC on my regular Monterey boot volume). Whether if fails again or doesn't, where exactly should I look for the relevant log of the failed boot? Where should I look for SysReport/GOP/GopInfo.txt? Last, but not least, do I have to install the debug build of each of the kexts I use?
Due to possible incompatibilities with GopBurstMode, the default now recommended in post #1 is to disable the feature. The guide and sample config have been updated accordingly.
Ah, thanks for catching my error. I guess when I was inserting the ThunderboltDROM output from the script I accidentally also overwrote the ThunderboltConfig block. I will add it back in and test later on today.
Is there a (public) summary or discussion about these incompatibilities showing up with GopBurstMode? I'd been considering re-flashing my Vega 56 to enable it but I think I will hold off until I understand more about these apparent issues.
EDIT: Oh, perhaps you're talking about @PeterHolbrook's report above? Not sure if this only affects those legacy "Mac edition" cards/MVC-flashed stuff or if newer cards could also have this problem. I tend to think not since several people have already reported success with @Bmju's EnableGop 1.2
Last edited:
I'm waiting for some instructions as to how to best carry out the diagnosis of the problem my GPU seems to be experiencing. I tend to believe the problem, in case it resurfaces, may well be limited to my GPU and perhaps others like it that were flashed by MVC. More likely than not, regular GPUs won't have any issues.
If you are making a USB, the quickest way would be:
- mount your ESP (however you normally do it, but e.g.
sudo diskutil mount EFI) cp -r /Volumes/EFI/EFI /Volumes/USB(replace EFI and USB folder names as necessary)- Now the USB should be a clone of your ESP, so you can check that it boots; then:
cp -r ~/Downloads/OpenCore-0.9.1-DEBUG/X64/EFI /Volumes/USB(to switch USB to Debug)
config.plist on the USB, set Target=65, and SysReport=true (or ON, depending on what you use to edit it)Boot once with
GopBurstMode=false (or OFF), and get the file from /Volumes/USB/SysReport/GOP ; boot again with GopBurstMode on then also send all (both, at this stage) /Volumes/USB/opencore*.txt files too.Thanks in advance!
Please test GopBurstMode by enabling both GopBurstMode and DirectGopRendering in OpenCore's config.plist.
If that works fine on your system, you are safe to install EnableGopDirect.efi in vBIOS or firmware for native boot picker support.
OK. For now, I've booted (it's agonizingly slow) with
GopBurstMode=false. My /Volumes/USB/SysReport/ folder doesn't have a GOP folder. It only has an ACPI folder that contains 13 aml files. So, I can't send you a GopInfo.txt. I'm enclosing the config.plist for you to verify if something is wrong. Notice some of the kexts included in my config.plist are disabled. Let me know if and how I should proceed.
You need to delete any existing SysReport folder. (Obviously, you need to delete the SysReport folder - and look for the new one - on the USB drive, not the normal ESP or EFI drive...!) Once you've done that, if you boot with the latest release, it definitely should generate a SysReport with a GOP subfolder.
Well, if you
Idk - something is wrong. The config.plist you posted is correct for the purposes. If you wanted to PM me with a zip of your EFI I can have a look?
@PeterHolbrook It's just about possible that if you delete SysReport in the original EFI folder, and then boot from the USB, that it will recreate its SysReport in the original EFI folder - I'm not quite sure, but I know some OC stuff is like that, so it is worth trying.
It now appears that my computer's failure to boot with the GopBurstMode parameter set as true may be caused by some shortcoming in my flashed GPU. It seems the computer will fail to boot if I use the DEBUG build of OC 0.9.1 installed on a USB flash drive, no matter how I set GopBurstMode. I don't know if other MVC cards may be equally problematic; I would think they aren't.
All MVC cards are equally problematic in respect to the APFS.efi. They often hijack the apfs loader. Why don't you flash it with the GOP from @Bmju ?
Was going to make a post asking why I'm now getting multiple-minute long boot times with my cMP4,1>5,1 with OpenCore + Monterey. I was going to point the finger at the Titan Ridge card since that is the most recent thing I was messing with. But some google-fu led me to discussions here and elsewhere about super-long boot times with Samsung SSDs in Monterey due to TRIM. Yuck.
When I was following the guidelines in post #1, I changed SetApfsTrimTimeout to 9999999 without really understanding why. if I was using another brand of SSD I don't think it would be an issue, but my Samsung 970 EVO is definitely affected.
The last posts I can find about this issue in this thread were back in November, in which @h9826790 suggested that setting SetApfsTrimTimeout=0 was likely no problem (even without overprovisioning?), as someone said the OS performs TRIM commands at times other than at boot time.
But before I make that change to my config, I just wanted to double-check to see if there is a consensus on this. On a scale of 1-10 in terms of how much this bothers me it's probably a 6--mainly because I am rebooting a lot right now as I'm getting this machine fully set up and configured. Bu I think I also have some trauma dating back to when we all used 5400rpm fragmented IDE hard drives and booting always took a couple of minutes--so it just feels "wrong" for my boot times in 2023 to feel like they did in 2003 😆
Has it been determined why this issue cropped up (or at least got significantly worse) with Monterey? And what it is about Samsung blades that makes them so much slower doing TRIM operations than, say a WD Black? Just curious.
Is the boot drive the only one getting TRIM'ed at startup? I've got 4 Samsung blades in a High Point 7101A (no arrays). The other 3 have no data on them at this point, but are my boot times going to get even longer once I start using those drives too?
When I was following the guidelines in post #1, I changed SetApfsTrimTimeout to 9999999 without really understanding why. if I was using another brand of SSD I don't think it would be an issue, but my Samsung 970 EVO is definitely affected.
The last posts I can find about this issue in this thread were back in November, in which @h9826790 suggested that setting SetApfsTrimTimeout=0 was likely no problem (even without overprovisioning?), as someone said the OS performs TRIM commands at times other than at boot time.
But before I make that change to my config, I just wanted to double-check to see if there is a consensus on this. On a scale of 1-10 in terms of how much this bothers me it's probably a 6--mainly because I am rebooting a lot right now as I'm getting this machine fully set up and configured. Bu I think I also have some trauma dating back to when we all used 5400rpm fragmented IDE hard drives and booting always took a couple of minutes--so it just feels "wrong" for my boot times in 2023 to feel like they did in 2003 😆
Has it been determined why this issue cropped up (or at least got significantly worse) with Monterey? And what it is about Samsung blades that makes them so much slower doing TRIM operations than, say a WD Black? Just curious.
Is the boot drive the only one getting TRIM'ed at startup? I've got 4 Samsung blades in a High Point 7101A (no arrays). The other 3 have no data on them at this point, but are my boot times going to get even longer once I start using those drives too?
Hi
Want to triple boot my iMac 2011 with OCLP. Got any outline advice for order of install or gotchas?
Was thinking wipe HDD with Windows 10 installer and then format to give Windows 250GB, then boot MacOS installer and format partition of 100Gb for MacOS, rest for Linux but then boot Linux installer and install that and finally boot MacOS installer and install and add OCLP. Reasons for order: Windows & MacOS have different ideas what makes a GB and it annoys me to get "funny" sized partitions, Windows needs MSR partition and generally wants a 350Mb EFI partition, Linux installs Grub and finally OCLP can be config'd to pick up all 3 OS afterwards? Make any sense?
Not being funny, but it genuinely sounds as if you understand all the issues well enough to play with it yourself and get the result you want already! (Since you quoted my post, I don't have a fixed order for this - I did just notice recently that Windows does not seem to want to recreate the ESP on a completely blank disk, but Linux I am sure and macOS IIRC are happy to create one.)
When you set that to 9999999, and after you boot to desktop, you can use the following command to check which drive was TRIMed during boot.
Code:
log show --predicate "processID == 0" \--start $(date "+%Y-%m-01") | grep spacemanApart from which drive was TRIMed, you can also see how much time spent on each drive. Then you will know why it takes so long.
Since APFS was introduced into macOS, this bug exist, not just in Monterey.
Anyway, I set SetApfsTrimTimeout=0 for a few months now. No issue so far, and can't feel any performance degradation. The following is from the latest OpenCore manual under the SetApfsTrimTimeout section.
If you really concern about it, may be you can set that to zero just for this "setup period". Once you finish the initial setup, and no need to reboot that often, you can set that back to 9999999.
Or, you may set that to 9999999 then make a reboot once every few weeks. So that the SSD at least will be manually TRIMed something like once a month.
Last but not least, the Samsung SSD should has overprovisioning built in.