Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
This is from latest master branch:

The Warning is clear, set it to False while doing minor corrections of SMBIOS, like we do, therefore I'm leaving the property set to False.

View attachment 1727195
I'm completely re-editing this reply, as I was in large part mis-reading the OC warning here. Sorry! But I still think the doc is consistent with what I'm suggesting is a valid alternative. Yes, the doc as I understand it warns you NOT to set Automatic to false, unless you are only doing minor updates, in which case you can. But I don't think it says that when you are doing minor updates, you should choose to set it false, just that you can.
 
Last edited:
I strongly believe that this documentation exactly says that you *can*
Feel free to experiment with a Mac Pro 5,1 and report back the findings, thank you for looking into this and help the community.
 
  • Like
Reactions: Bmju
... from a developer perspective, I would not set Automatic=True on a Mac because I want to use the OEM values, not Generic values.
As regards 'generic' defaults, @TECK, I've now realised that you were most likely referring to OPENCORE_SN1 and OPENCORE_MLB_SN11.

I totally agree that those values are undesirable.

But there is an important wrinkle here.

These values only ever appeared for specifically missing config values. Really non-obviously and quite bizarrely, present but empty config values for these always gave OEM defaults. This has now, only recently, been made consistent, in favour of OEM defaults.

But, @cdf, this always meant that a Generic section with empty values present for these fields, where it mattered, has *always* been able to do a clean hybrid fake with Automatic=true. I know this, because I've been using (and then slowly experimenting with) a config which did this exactly for at least three or four months.

Also, I'm coming from a background where *this* was the only way that I knew how to do things, so (I agree!) I'm having to catch up, too!

Thank you.
 
has *always* been able to do a clean hybrid fake with Automatic=true.
What do you mean by clean hybrid? Before, if using Automatic and say board-id only in the generic section would write OPENCORE_SN1 and OPENCORE_MLB_SN11, which of course was undesirable behavior.
 
What do you mean by clean hybrid? Before, if using Automatic and say board-id only in the generic section would write OPENCORE_SN1 and OPENCORE_MLB_SN11, which of course was undesirable behavior.
Even before, if you put empty string <string></string> (instead of completely missing) values for those, you got the OEM defaults.
 
These values only ever appeared for specifically missing config values. Really non-obviously and quite bizarrely, present but empty config values for these always gave OEM defaults. This has now, only recently, been made consistent, in favour of OEM defaults.

The developer had always clearly and consistently said missing values was undefined behaviour.
It's basically a toss up and literally anything can happen. Luckily, and reinforcing the philosophy set out in Post 1, there wasn't al sorts of funnies being done which limited the opportunities for weird stuff to happen.

The current state of play is far better though. At least you know what you are getting ... more or less.
 
The developer had always clearly and consistently said missing values was undefined behaviour.
It's basically a toss up and literally anything can happen. Luckily, and reinforcing the philosophy set out in Post 1, there wasn't al sorts of funnies being done which limited the opportunities for weird stuff to happen.

The current state of play is far better though. At least you know what you are getting ... more or less.
Yes. But also, the weird, generic values only ever appeared for non-correct (i.e. missing value) configs. So even though seemingly everyone (including me) coming to OC assumes at first that missing values must be fine, and therefore would most probably have encountered those weird values, it is also true that getting a clean hybrid config using Automatic=true *always worked*, both before and after the recent changes, on a fully supported (i.e. all values present) config.

I do not really know how jackluke ever worked it all out though. I agree that the docs have only just caught up, and made it at all obvious that this is possible. I *started off* knowing it was possible, because I started off with someone else's already working config, already doing it successfully, before I ever dived into the docs, and found the (apparent) inconsistencies, and asked the questions that - fortunately - ended up with the docs being updated, and the anomalous and unfortunate missing value behaviour being removed.
 
Last edited:
Try this config
this config seems to work! boot took a while, and i blame debug. full res via DP from the 5500 XT. and i did get a bootpicker! however the apple logo was still squashed. could you tell me where i can mess around with the resolution, or should i not look this gift horse in the mouth?

here's my log, btw:
 

Attachments

  • opencore-2021-02-08-213144.txt.zip
    10.8 KB · Views: 105
  • Like
Reactions: startergo
this config seems to work! boot took a while, and i blame debug. full res via DP from the 5500 XT. and i did get a bootpicker! however the apple logo was still squashed. could you tell me where i can mess around with the resolution, or should i not look this gift horse in the mouth?

here's my log, btw:
Maybe @h9826790 or @cdf can help with the squashed logo, I don't have 4K screen to test.
 
When installing Linux the tutorial mentions this step:
Choose "Use as: Ext4 journaling file system", "Format the partition" and "Mount point: \"

This step should actually use a forward slash as the mount point. Replace the step with:
Choose "Use as: Ext4 journaling file system", "Format the partition" and "Mount point: /"
 
I was able to install Open Core and Catalina just fine. But for whatever reason, I cannot get my AMD 5700 XT to work in Catalina. It is a flashed card and it will allow me to boot into High Sierra and Mojave. It will NOT however, allow me to even so much as boot into Catalina. Anytime I try to boot using the AMD 5700 RX, it puts me through an infinite reboot cycle. Here's the error report. I'm basically at the end of my rope with this Mac. It's pretty much over unless I can resolve this.


---------------------
Anonymous UUID: E9D3B66F-08AF-4DC3-15A7-77D17DD4C140

Mon Oct 19 23:09:10 2020

*** Panic Report ***
panic(cpu 4 caller 0xffffff7f8b89747a): "[7:0:0][PPLIB] Failed Power Play Initialization. TTL Error Message: .
"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/GPUDriversAMD/GPUDriversAMD-3.10.18/Common/IONDRV/ATI/AMDUniversalFramebuffer/AMDUniversalFramebuffer/Controller/Controllers/AmdRadeonController.cpp:1670

Installing Big Sur fixed the issue for me.

  • My cMP 5,1 with MacVidCards AMD Radeon RX 5700 was running patched Catalina 10.15.4 (no OpenCore) nicely
  • Installed OC 0.6.6 using martin's package from #1,314 -> OK
  • Software Update offered Big Sur only; installing Big Sur directly from non-vanilla 10.15.4 failed due to gateKeeper error
  • After adding the VMM flag I could update Catalina to 10.15.7, using the "Another Update is available" link in Software Update.
    • I did not have to use The path of your graphics card
    • VMM/Cpuid1Mask was the only change to 0.6.6 from #1314

From there, I also had the "Failed Power Play Initialization" kernel panic.

After panicking myself too, I attached the SSD as an external drive to MBP2019 running Big Sur, installed vanilla macOS 11.2 onto the drive without any issues - I could even boot my "cMP Big Sur" in MacBook via Option-Key, all data and Apps were preserved.
Finally, I moved the SSD back into the PCIe slot - done


So the combination of flashed card + mix of patched/unpatched catalina caused the issue, which I could fix by upgrading to Big Sur.
 

Attachments

  • Screenshot 2021-02-09 at 11.04.25.png
    Screenshot 2021-02-09 at 11.04.25.png
    257.5 KB · Views: 80
No, OC does everything for you. Same for Catalina, not just Big Sur.
TECK, well I can't seem to get it working in Big Sur with the basic config.plist from the first post (only added the graphical bootloader). I have a BCM94360CDAX. Does getting continuity working require hardware acceleration or any other mods?
 
Hi, if I want to upgrade from Catalina to Big Sur I get :

Your Mac needs a firmware update in order to install to this volume.
Please select a Mac OS Extended (Journaled) volume instead.

My Boot ROM Version shows as 9999.0.0.0.0 ...
Do I have to remove SMBIOS / BIOSVersion = 9999.0.0.0.0 and/or other things to upgrade?
If yes, that should be maybe mentioned in #1
 
Do I have to remove SMBIOS / BIOSVersion = 9999.0.0.0.0 and/or other things to upgrade?
No. You might be getting the firmware message if your disk is not APFS-formatted (that shouldn't be the case if you're selecting your Catalina disk, though). Otherwise, you can try toggling a firmware feature bit. While the bit shouldn't be necessary for macOS ≥ 11.1, it's still something to confirm.
 
Last edited:
Hm, this disk is APFS formatted.
It is an SSD attached over an USB hard drive station, maybe that is the reason...
I boot from this disk, select to upgrade in the System Preferences,
download works fine, but then in the Install app I get that error.
 
Try:
XML:
<dict>
<key>BoardProduct</key>
<string>Mac-7BA5B2D9E42DDD94</string>
<key>BIOSVersion</key>
<string>9999.0.0.0.0</string>
<key>FirmwareFeatures</key>
<data>A1QM4A==</data>
<key>FirmwareFeaturesMask</key>
<data>P/8f/w==</data>
</dict>
 
@cdf I have a question about the SetApfsTrimTimeout set to 10 seconds. From documentation:
Depending on the SSD controller and the drive fragmenation trim procedure may take considerable amount of time, causing noticeable boot slowdown APFS driver explicitly ignores previously unmapped areas and trims them on boot again and again. To workaround boot slowdown macOS driver introduced a timeout (9.999999 seconds) that stops trim operation when it did not manage to complete in time.
I'm wondering why we cannot use the failsafe -1 value, shouldn't this be the same?
 
@cdf I have a question about the SetApfsTrimTimeout set to 10 seconds. From documentation:

I'm wondering why we cannot use the failsafe -1 value, shouldn't this be the same?
I believe that -1 corresponds to 4294967295 (unsigned), the high value mentioned in the manual. It's probably best to stick with Apple's default 10 seconds (9999999).
 
  • Like
Reactions: TECK
** Please Help **
I used the opencore program to upgrade to Catalina from Mojave and got that to work but I have no lost my WiFi. I have a zoom job interview tomorrow and I have no idea what to do to try and fix it.
 
Last edited:
  • Like
Reactions: z0Nker
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.