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.
Good idea. Tested with shikigva=96 and shiki-id=Mac-7BA5B2D9E42DDD94, doesn't work, but I forget to test 32 or 1......

Are you using OpenCore to load WhateverGreen? According to the Shiki FAQ, early loading makes a difference.
 
Why did you set shikigva=96? Doesn't make sense.

That achieve the best result when try to activate HWAccel on cMP (without Opencore) few months back.

I can’t remember all exact differences between different settings now. But 96 allow me to use HWAccel (except HEVC encoding) and play some (DRM protected) videos (streaming) in iTunes during those tests.
[automerge]1572438004[/automerge]
Are you using OpenCore to load WhateverGreen? According to the Shiki FAQ, early loading makes a difference.

Not yet, that’s what I want to achieve as well.

Simply put the kext in the EFI/EFI/OC/Kexts folder doesn’t work.

So far, all tests only be done with the kexts installed in /L/E/

I will check if there is anything need to set in config.plist to load those kexts.

Update 1: found the kext injection code
Code:
            <dict>
                <key>BundlePath</key>
                <string>Lilu.kext</string>
                <key>Comment</key>
                <string></string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/Lilu</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string></string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
            <dict>
                <key>BundlePath</key>
                <string>WhateverGreen.kext</string>
                <key>Comment</key>
                <string>Video card</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/WhateverGreen</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string></string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
 
Last edited:
I started fiddling with OpenCore in more depth including the very useful command-line-tool and OpenCore configurator. It requires full knowledge of config.plist options as 10.15.1 did not resolve the disabled DisplayPort issue which is plaguing supported and unsupported macs under Catalina. Not sure if you are experiencing the same issue with your VII.

@Starplayr believes this may be a security restriction as some users managed to get their DisplayPorts working again once screen recording permission was given to vendor drivers or that Apple is intentionally restricting DisplayPorts on certain configurations. As for him, he managed to get his DisplayPort working again by changing the board-id of his cMP 3,1 to an iMac late 2009.

I'll post an update if I manage to get the displayports working again using OpenCore.

Edit: made a few corrections and added more references to @Starplayr's posts.
 
Last edited:
  • Like
Reactions: MORJOYES
@w1ss I already mentioned the reason for disabled outputs. AppleGraphicsDevicePolicy is responsible for this. It is enabled for certain SMBIOSes and disables outputs. Whatevergreen can patch AppleGraphicsDevicePolicy to not match your SMBIOS. For 10.15.1 it's best to add "agdpmod=pikera" to boot flags. This disables board-id check of AppleGraphicsDevicePolicy and should enable all outputs.
 
@w1ss I already mentioned the reason for disabled outputs. AppleGraphicsDevicePolicy is responsible for this. It is enabled for certain SMBIOSes and disables outputs. Whatevergreen can patch AppleGraphicsDevicePolicy to not match your SMBIOS. For 10.15.1 it's best to add "agdpmod=pikera" to boot flags. This disables board-id check of AppleGraphicsDevicePolicy and should enable all outputs.
Sorry, I must have missed your post. I am testing this now.

Thanks
 
Tested the following condition. Still no HEVC encoding yet in 10.15.1 official release (H264 still work, so WEG and shiki-id is working).

OpenCore
No SMBIOS injection (still boot as 5,1)
Lilu + WEG in /EFI/EFI/OC/Kexts
config.plist set to load both kexts
shikigva=32 and shiki-id=Mac-7BA5B2D9E42DDD94
 
  • Like
Reactions: cdf and octoviaa
@CMMChris You are a gentleman, a scholar and I honestly cannot thank you enough 👏👍🤝


2019-10-30_19-29-13.png



You clearly know your stuff! Thanks again.
 
  • Like
Reactions: CMMChris
@h9826790 Whatevergreen was also updated today so I think this may be of interest to you

- Added support for disabled AppleGraphicsDevicePolicy in AMD drivers on 10.15.1

Worth a shot.
 
Last edited:
As an explanation, there are two ways of patching AGDP. First is the board-id patch (agdpmod=pikera) and second is preventing AGDP from loading (agdpmod=vit9696). By default WEG uses the second way. This wasn't working for a while during the 10.15.1 beta versions and release version. The latest version of Whatevergreen should fix it and enable all ports of a graphics card just by having Whatevergreen installed. Just in some cases providing the "agdpmod=pikera" bootflag is still necessary - for example when using a Navi10 graphics card.
At least that's the situation in a Hackintosh but I guess it is the very same on any Mac Pro. After all, it's all the same.
 
@h9826790 Whatevergreen was also updated today so I think this maybe of interest to you

- Added support for disabled AppleGraphicsDevicePolicy in AMD drivers on 10.15.1

Worth a shot.

I inserted “agdpmod=pikera” in the boot argument yesterday indeed.

But since I only need to drive one monitor, and has lots of things to test. I haven’t really tested if that re-enable other display ports. However, I can’t see why not. So far, the cMP perform exactly as per any Hackintosh. This is the reason why we can use all these Hackintosh tools to achieve what we want.
 
  • Like
Reactions: TheStork
I just noticed this very useful OpenCore post, especially the part about spoofing a Catalina unsupported Mac as a Catalina (supported) virtual machine (VMM flag) that typically is checked and allowed by default from the "Distribution" inside a stock "OSInstall.mpkg" Catalina also "Core.pkg" either full app installer or Combo/delta pkgs.

To those who already tested this "OpenCore booloader with VMM flag":
does it allow to download (and install) the delta/combo Catalina "Software Update" without issuing any EFI (EEPROM) unwanted firmware updates ?

(Typically issued during the stage2 osx installer showing a big apple logo with big loading bar)

I mean setting a VMM flag on a real Mac machine should never install any "FirmwareUpdate*.pkg", am I right ?
 
Last edited:
I've used both "Install macOS Catalina" and "Software Update" a few times now with no issues. It would only make sense that no firmware updates get triggered with the VMM flag. Besides, if the model identifier is from an unsupported machine, then there would be no update present in the installer.

On the other hand, spoofing a supported model and starting the installation process places firmware files of the spoofed model on the EFI partition. It is therefore important to be extra careful in this case. Note that OpenCore does seem to have measures in place to prevent firmware updates (like spoofing the most recent firmware version and spoofing the manufacturer.)
 
I wonder if those OS installers can really update the cMP's firmware without users putting their Macs into the firmware flashing mode (hold power button to boot).

If they can, then why we still need to do that when update to 144.0.0.0.0 etc?

Of course, I don't want to take the risk, especially I don't have the tool to perform hardware flashing for recovery. But just thinking, if Apple can update our Mac's firmware without entering firmware flashing mode. Then most likely they will simply update our Mac's firmware silently when we run the HS/Mojave installer. Why they treat us so well, and allow us to choose not to update the BootROM?
 
  • Like
Reactions: octoviaa
So i tested today opencore, thanks this forum.
Work fine h265 decode/encode very fast in Davinci resolve. WOw
Geek , before OC i have (mac pro 5,1) about 3300 after i have (imac1,1) 4500 nice improvement.
I should try to put ddr3 at 1333 and not 1066 maybe the 5000 reach them.
Fan work well under pression.
Only not work now is DP port, only 1 work.
any ideas to activate the other DP ports?
 

Attachments

  • Screenshot 2019-10-30 at 22.56.55.png
    Screenshot 2019-10-30 at 22.56.55.png
    100.9 KB · Views: 574
  • Screenshot 2019-10-30 at 23.15.24.png
    Screenshot 2019-10-30 at 23.15.24.png
    100.6 KB · Views: 586
  • Screenshot 2019-10-30 at 23.27.37.png
    Screenshot 2019-10-30 at 23.27.37.png
    74.5 KB · Views: 784
  • Screenshot 2019-10-30 at 23.41.09.png
    Screenshot 2019-10-30 at 23.41.09.png
    97.9 KB · Views: 607
  • Like
Reactions: zoltm and octoviaa
So i tested today opencore, thanks this forum.
Work fine h265 decode/encode very fast in Davinci resolve. WOw
Geek , before OC i have (mac pro 5,1) about 3300 after i have (imac1,1) 4500 nice improvement.
I should try to put ddr3 at 1333 and not 1066 maybe the 5000 reach them.
Fan work well under pression.
Only not work now is DP port, only 1 work.
any ideas to activate the other DP ports?

Please re-read all CMMChris’s posts, he covered that a few times already.

Anyway, it’s interesting that your CPU performance is improved. Also, can see all fan sensors. My be I should try MFC.
[automerge]1572476599[/automerge]
I just confirmed that MacsFanControl can see all the fans, and control them properly. It's just iStat menu cannot read them when I spoofing the iMac Pro 1,1 SMBIOS.
Screenshot 2019-10-31 at 7.01.26 AM.png
 
Last edited:
  • Like
Reactions: octoviaa
I also found the root cause of the CPU performance issue.

That's completely my mistake, I disabled the VMM flag, which cause the CPU performance drop by ~50%.

Once I turn it back on, CPU performance back to normal level. (I did quite a few things when benchmarking. So, the scores isn't that high, but at least, back to the normal level. That's all I want to see)
Screenshot 2019-10-31 at 7.14.01 AM.png

[automerge]1572477402[/automerge]
So, apart from can't see the readings from some temperature sensors. Basically everything is working as expected.
[automerge]1572477556[/automerge]
In fact, manual mode PlatformInfo also work. My Mac can now boot as iMac Pro ident, but still with the 5,1 BootROM and SMC version.
Screenshot 2019-10-31 at 7.17.45 AM.png


I can set FSB in the config.plist etc. But since the CPU performance is normal. I prefer not to touch it now. I don't care about the incorrectly reported Processor Speed, as long as that's cosmetic, and no real disadvantage.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.