Sidebar Sidebar
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

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.
ylluminate said:
Have run into issues with DisplayLink's new userland driver/support software on Catalina and by extension Big Sur. It has been suggested that we need to start shifting model identification away from MacPro5,1 to perhaps MacPro7,1.

  • Any particular drawbacks here? What configuration changes are needed in the config.plist aside from the normal identity stuff?
  • What kext changes are required?
  • Any other considerations to keep in mind when switching?
  • I assume I need to generate a new serial number too for iCloud/iMessage support too, right?
Click to expand...
Hello

I have Mac Pro 5.1 with graphic card RX-580 flashed and Big Sur, with SMBIOS Mac Pro 7.1

<key>SMBIOS</key>
<dict>
<key>BoardProduct</key>
<string>Mac-27AD2F918AE68F61</string>
<key>FirmwareFeatures</key>
<data>
A1QM4A==
</data>
<key>FirmwareFeaturesMask</key>
<data>
P/8f/w==
</data>
</dict>

you don't need Lilu, WhateverGreen and graphic card PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0) but only AppleMCEReporterDisabler.kext

<key>Kernel</key>
<dict>
<key>Add</key>
<array>
<dict>
<key>BundlePath</key>
<string>AppleMCEReporterDisabler.kext</string>
<key>Comment</key>
<string>Disable AppleMCEReporter</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string></string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>19.0.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
</array>

You don't need new serial number because use your original Mac Pro 5.1 for all Apple services.

If you also want to have Night Shift that with Big Sur no longer works the NightShiftEnabler.kext, You must insert into SMBIOS
<string>MacPro7,1</string> butafterwards you will have an error message for the position of the RAM DIMMs that we have already talked about in the forum and also, all the internal temperature sensors are not correctly detected.
 
  • Like
Reactions: ylluminate
haralds said:
It's an MSI "Armor" RX-580 8GB OC Edition. ROM patching for Apple Boot display was done by Macvidcards. Works great.
Click to expand...
haralds said:
How do I get the Boot Screen to be black?
Click to expand...
8.3 Boot Properties

ConsoleAttributes
Type: plist integer
Failsafe: 0
Description: Sets specific attributes for console.

Text renderer supports colour arguments as a sum of foreground and background colours according to UEFI specification. The value of black background and black foreground (0) is reserved. List of colour names:
0x00 — EFI_BLACK
0x01 — EFI_BLUE
0x02 — EFI_GREEN
0x03 — EFI_CYAN
0x04 — EFI_RED
0x05 — EFI_MAGENTA
0x06 — EFI_BROWN
0x07 — EFI_LIGHTGRAY
0x08 — EFI_DARKGRAY
0x09 — EFI_LIGHTBLUE
0x0A — EFI_LIGHTGREEN
0x0B — EFI_LIGHTCYAN
0x0C — EFI_LIGHTRED
0x0D — EFI_LIGHTMAGENTA
0x0E — EFI_YELLOW
0x0F — EFI_WHITE
0x00 — EFI_BACKGROUND_BLACK
0x10 — EFI_BACKGROUND_BLUE
0x20 — EFI_BACKGROUND_GREEN
0x30 — EFI_BACKGROUND_CYAN
0x40 — EFI_BACKGROUND_RED
0x50 — EFI_BACKGROUND_MAGENTA
0x60 — EFI_BACKGROUND_BROWN
0x70 — EFI_BACKGROUND_LIGHTGRAY
Click to expand...
Note: This option may not work well with System text renderer. Setting a background different from black could help testing proper GOP functioning.
Click to expand...

Code: 
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:DefaultBackgroundColor Four-byte BGRA data defining boot.efi user interface background colour. Standard colours include BF BF BF 00 (Light Gray) and 00 00 00 00 (Syrah Black).
 
I can’t make hibernation go away in Windows 10. Is this an Open Core issue?

I can disable it (powercfg -h off), make the file go away, and then it comes back on when I reboot through OC.

Can someone else who is booting Windows through Open Core test this for me?

It’s quite annoying as with 96GB of ram it eats up quite a bit of disk
 
Paolo-Sp said:
Hello

I have Mac Pro 5.1 with graphic card RX-580 flashed and Big Sur, with SMBIOS Mac Pro 7.1

<key>SMBIOS</key>
<dict>
<key>BoardProduct</key>
<string>Mac-27AD2F918AE68F61</string>
<key>FirmwareFeatures</key>
<data>
A1QM4A==
</data>
<key>FirmwareFeaturesMask</key>
<data>
P/8f/w==
</data>
</dict>

you don't need Lilu, WhateverGreen and graphic card PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0) but only AppleMCEReporterDisabler.kext

<key>Kernel</key>
<dict>
<key>Add</key>
<array>
<dict>
<key>BundlePath</key>
<string>AppleMCEReporterDisabler.kext</string>
<key>Comment</key>
<string>Disable AppleMCEReporter</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string></string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>19.0.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
</array>

You don't need new serial number because use your original Mac Pro 5.1 for all Apple services.

If you also want to have Night Shift that with Big Sur no longer works the NightShiftEnabler.kext, You must insert into SMBIOS
<string>MacPro7,1</string> butafterwards you will have an error message for the position of the RAM DIMMs that we have already talked about in the forum and also, all the internal temperature sensors are not correctly detected.
Click to expand...

Really appreciate the tips there. On the MacPro7,1 string insertion, are we seeing any work on the temperature sensor resolution?

That's a pretty big deal for me...
 
When using a MacPro7,1 system identity as per above @Paolo-Sp and anyone else familiar with this, I'm seeing that for a MacPro5,1 the features should be:
Features: A1QM4A== (hex: 03540CE0)
Features Mask: P/8f/w== (hex: 3FFF1FFF)

But if you look at a real MacPro7,1 these two values are:
Features: ZvCv/QAAAAA= (hex: 66F0AFFD 00000000)
Features Mask: f////wAAAAA= (hex: 7FFFFFFF 00000000)

ProcessorType on a real MacPro7,1 is also OEI= (hex: 3842)

What is the logic in this? Should we perhaps use different features values? Why are the first ones suggested?
 
ylluminate said:
Have run into issues with DisplayLink's new userland driver/support software on Catalina and by extension Big Sur. It has been suggested that we need to start shifting model identification away from MacPro5,1 to perhaps MacPro7,1.

  • Any particular drawbacks here? What configuration changes are needed in the config.plist aside from the normal identity stuff?
  • What kext changes are required?
  • Any other considerations to keep in mind when switching?
  • I assume I need to generate a new serial number too for iCloud/iMessage support too, right?
Click to expand...
Technically, all you really need is just the ident spoofing (if that’s what the software checking).

No extra kext is really required.

Memory error notification may pop up, but only once after every boot, and no evidence there is any real memory issue.

Some software like iStat menu (base on ident to locate specific sensors) won’t able to function normally.

General consent is that we should generate a unique serial number. However, experience shows that we can keep our 5,1 serial number, and all functions can still work. But I really have no idea how reliable it is. Also, no idea if this will affect the associated Apple ID.
 
ylluminate said:
Really appreciate the tips there. On the MacPro7,1 string insertion, are we seeing any work on the temperature sensor resolution?

That's a pretty big deal for me...
Click to expand...
Use other software (e.g. MacsFanControl) to monitor the temperature.

AFAIK, TG-Pro also work (after switch on Hackintosh mode)
 
Nice, thanks @h9826790 - nice to hear.

Unfortunately something else must be going on because DisplayLink is still not working. Hmm.

One thing that's started popping up is a crash of ExpansionSlotNotification. The problem with this is that for some reason if you don't click it quickly enough the crash reporter dialogue's buttons become disabled and the dialogue will not become closable except by a reboot (haven't discovered the process that can be killed to eliminate the dialogue yet):
Code: 
Process:               ExpansionSlotNotification [704]
Path:                  /System/Library/CoreServices/ExpansionSlotNotification
Identifier:            ExpansionSlotNotification
Version:               25.120.3
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           ExpansionSlotNotification [704]
User ID:               501

Date/Time:             2020-11-21 00:36:13.251 -0500
OS Version:            Mac OS X 10.15.7 (19H2)
Report Version:        12

...
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [704]

...

Any idea about this?
 
Last edited:
The Spirit said:
Hi.
I used the SystemProductName of iMac Pro 1,1 like you mentioned and i got NightShift.
Thanks a lot.
Click to expand...
I just found out, that if i use SystemProductName of iMac Pro 1,1 NightShift works, but powering down seem to take much more time.
So i removed the SystemProductName of iMac Pro 1,1 again and power down is fast again.
Now i use f.lux for "NightShift".
 
Can you please confirm what are the required kexts with SMBIOS Mac Pro 7.1?
Code: 
        <key>SMBIOS</key>
        <dict>
            <key>BoardProduct</key>
            <string>Mac-7BA5B2D9E42DDD94</string>
            <key>FirmwareFeatures</key>
            <data>
            A1QM4A==
            </data>
            <key>FirmwareFeaturesMask</key>
            <data>
            P/8f/w==
            </data>
        </dict>

Can Lilu and Whatevergreen can be removed? What about the non-Apple RX580 GPU settings in DeviceProperties?

Code: 
    <key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)</key>
            <dict>
                <key>agdpmod</key>
                <data>
                cGlrZXJhAA==
                </data>
                <key>rebuild-device-tree</key>
                <data>
                AA==
                </data>
                <key>shikigva</key>
                <data>
                UA==
                </data>
            </dict>
 
  • Like
Reactions: naerct
TECK said:
Can you please confirm what are the required kexts with SMBIOS Mac Pro 7.1?
Code: 
        <key>SMBIOS</key>
        <dict>
            <key>BoardProduct</key>
            <string>Mac-7BA5B2D9E42DDD94</string>
            <key>FirmwareFeatures</key>
            <data>
            A1QM4A==
            </data>
            <key>FirmwareFeaturesMask</key>
            <data>
            P/8f/w==
            </data>
        </dict>

Can Lilu and Whatevergreen can be removed? What about the non-Apple RX580 GPU settings in DeviceProperties?

Code: 
    <key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)</key>
            <dict>
                <key>agdpmod</key>
                <data>
                cGlrZXJhAA==
                </data>
                <key>rebuild-device-tree</key>
                <data>
                AA==
                </data>
                <key>shikigva</key>
                <data>
                UA==
                </data>
            </dict>
Click to expand...
For Big Sur only, yes, you can remove Lilu and WEG even you want full HWAccel.

But IMO, just disable them in config.plist make more sense. The system still clean, but everything is there if you need to re-enable them later for whatever reason (e.g. OpenCore fixed the users space issue, and allow DRM streaming again via WEG).

Anyway, the board ID in your code is the iMac Pro board ID, not the 7,1 board ID Mac-27AD2F918AE68F61

With the 7,1 board ID, and no more Lilu WEG, you can also remove all those DeviceProperties
 
  • Like
Reactions: TECK and naerct
ylluminate said:
Nice, thanks @h9826790 - nice to hear.

Unfortunately something else must be going on because DisplayLink is still not working. Hmm.

One thing that's started popping up is a crash of ExpansionSlotNotification. The problem with this is that for some reason if you don't click it quickly enough the crash reporter dialogue's buttons become disabled and the dialogue will not become closable except by a reboot (haven't discovered the process that can be killed to eliminate the dialogue yet):
Code: 
Process:               ExpansionSlotNotification [704]
Path:                  /System/Library/CoreServices/ExpansionSlotNotification
Identifier:            ExpansionSlotNotification
Version:               25.120.3
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           ExpansionSlotNotification [704]
User ID:               501

Date/Time:             2020-11-21 00:36:13.251 -0500
OS Version:            Mac OS X 10.15.7 (19H2)
Report Version:        12

...
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [704]

...

Any idea about this?
Click to expand...
I am not a DisplayLink user, hard to know what's wrong.

But if that never work in Big Sur, highly likely the associate driver / software isn't' Big Sur compatible yet. You better contact DisplayLink to confirm the compatibility.
 
Hello,

I can't upgrade to Big Sur.

I've got hardware the is not supported yet and some audio plugins do not work.

How can I download the Catalina installer?

I tried getting it from apple but it tells me is not available and send me to Big Sur.
 
fabriciom said:
Hello,

I can't upgrade to Big Sur.

I've got hardware the is not supported yet and some audio plugins do not work.

How can I download the Catalina installer?

I tried getting it from apple but it tells me is not available and send me to Big Sur.
Click to expand...
You can download past macOS releases from this Apple Support page, but you have to be on a macOS release earlier or equal than the one you want to download. You can't download High Sierra from Mojave, for example.

How to download and install macOS - Apple Support

Download and install current or previous versions of the Mac operating system on compatible Mac computers.
support.apple.com support.apple.com

Just checked and the Catalina link is working fine.
 

Attachments

  • Screen Shot 2020-11-21 at 08.05.31.png
    Screen Shot 2020-11-21 at 08.05.31.png
    1,013.8 KB · Views: 175
  • Like
Reactions: naerct
tsialex said:
You can download past macOS releases from this Apple Support page, but you have to be on a macOS release earlier or equal than the one you want to download. You can't download High Sierra from Mojave, for example.

How to download and install macOS - Apple Support

Download and install current or previous versions of the Mac operating system on compatible Mac computers.
support.apple.com support.apple.com

Just checked and the Catalina link is working fine.
Click to expand...

im on Mojave and it won allow me....

The requested version of osx is not available.
 
  • Like
Reactions: naerct and 0488568
fabriciom said:
Download the dmg and formatted the disk as APFS.

When I try to install Catalina it tells me that the version of OSX cannot be installed in the computer....
Click to expand...
So, your OpenCore settings are wrong.

Enable VMM flag spoofing, or do the full SMBIOS spoofing for iMac Pro, to overcome MP5,1 not being supported anymore.

Look at the first post, Part I item 4 and Part III.
 
Last edited:
  • Like
Reactions: naerct and octoviaa
I have a slightly different issue. I have set my config.plist as per post #4399 and am trying to upgrade my installation of Catalina from within it. OTA works in that BS downloads and installation starts. Halfway through the initial progress bar or so the system restarts. I don't have OC as the initial boot picker because I have legacy versions of macOS I multiboot into plus Windows. I therefore hold down the option key at the chime and pick the "EFI" volume. This brings up the OC boot picker and when I select my Catalina volume instead of continuing the installation it just boots straight into Catalina.

Have I forgotten something along the way or should I update Catalina from another volume instead?
 
Finally was able to get Catalina installed.

I know have big sur stuck as the update option.

Will this keep me from getting Catalina updates?
 
h9826790 said:
I am not a DisplayLink user, hard to know what's wrong.

But if that never work in Big Sur, highly likely the associate driver / software isn't' Big Sur compatible yet. You better contact DisplayLink to confirm the compatibility.
Click to expand...

Been talking with DisplayLink, they will not support my hardware with their devices with this new userland driver situation. This new package was specifically designed with Big Sur and Catalina in mind. Sad when you've spend hundreds and hundreds of dollars on their devices (or devices using their chipsets). They basically have said to stick to the KEXT version that works on Catalina and if you want to "upgrade" to Big Sur you have to sacrifice your additional monitor(s).
 
ylluminate said:
They basically have said to stick to the KEXT version that works on Catalina and if you want to "upgrade" to Big Sur you have to sacrifice your additional monitor(s).
Click to expand...
It is actually good they have a support in Catalina, which by itself is not supported on cMP. You should consider yourself lucky.
 
startergo said:
It is actually good they have a support in Catalina, which by itself is not supported on cMP. You should consider yourself lucky.
Click to expand...

The big problem I see so far is that their developers don't really know enough about what they're doing to really isolate the problem as I've seen evidenced in our exchanges. Ultimately I need to try to isolate the APIs that they're using according to another more expert kernel/kext developer in order to work around the problem.

So there is hope, but I had most specifically hoped that, as per the more expert developer's suggestion, that OpenCore model spoofing could satisfactorily resolve the problem before jumping in deeper.

I am, though, also worried about some other crashes like that one I noted above with the ExpansionSlotNotification binary that seems as though it shouldn't be firing up.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back