Thanks for the tests. Note that according to the manual,
Last edited:
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
Thanks for the tests. Note that according to the manual,
Again, no one without means to reflash the SPI should mess with OpenCore, besides the log that fill up @startergo NVRAM, a big binary table was inside the first stream/store of the NVRAM. Enabling OC log to NVRAM can cause flash cell starvation, be warned.
If you don't have a clean dump, you can't repair a messed up BootROM since this NVRAM areas are not cleaned by Command-Option-P-R.
[automerge]1574875977[/automerge]
If you don't have a clean dump, you can't repair a messed up BootROM since this NVRAM areas are not cleaned by Command-Option-P-R.
[automerge]1574875977[/automerge]
IASInstallPhaseList.plist is a log that macOS installer (Recovery too) creates to facilitate debug process of unsuccessful macOS installs. It's not needed for anything else and it's recreated when you run macOS installer or Recovery again. It's not permanent and can be erased if NVRAM space is needed.
Last edited:
There is an option in OC config file to enable "clear NVRAM" . If enabled it appears in the OC boot selection menu. I wonder if that one clears whatever it wrote in the NVRAM.
So has a bug been filed with the opencore devs who claim that OC doesn’t / can’t write to places it shouldn’t that can corrupt the ability to boot a real Mac?
Because the cMP has such a capricious firmware, we may need to be more specific if we want the issue to get addressed.
I wonder if what is triggering the binary blobs is related to the Data Hub. Originally, SMBIOS testing involved writing to the Data Hub and blobs appeared. Now this:
Again blobs appeared.
Again my wild guess is when we tested the imacPro smbios and checking "update data hub" or even "update NVRAM" will write something to the NVRAM. At least we know everything related to the data hub gets written there. Maybe "update 'smbios" does not write to the NVRAM?
[automerge]1574944270[/automerge]
Another option to test is the emulated NVRAM.
Yes. That's what I'm thinking. Perhaps we could approach this methodically with a known clean BootROM, starting with a basic configuration (like the one in the guide), then PlatformInfo manual mode with UpdateSMBIOS true, then with UpdateNVRAM true, then with UpdateDataHub true. Hopefully, we can pinpoint when the blobs start to appear. @tsialex may already have done some of this testing...
I just compared the clean ROM I flashed yesterday with the one i just dumped. OC still writes logs. And compared to the previous ROM when the NVRAM was full it has less writing but still there. And it deleted the XML file again. That really needs to be addressed by the developers.
Code:
<key>Debug</key>
<dict>
<key>DisableWatchDog</key>
<true/>
<key>DisplayDelay</key>
<integer>0</integer>
<key>DisplayLevel</key>
<integer>2147483714</integer>
<key>Target</key>
<integer>113</integer>
</dict>
<key>Security</key>
<dict>
<key>AllowNvramReset</key>
<true/>
<key>ExposeSensitiveData</key>
<integer>3</integer>
<key>HaltLevel</key>
<integer>2147483648</integer>
<key>RequireSignature</key>
<false/>
<key>RequireVault</key>
<false/>
<key>ScanPolicy</key>
<integer>0</integer>
</dict>Is it an issue that OpenCore only seems to detect a single CPU package in dual CPU systems? Happens in the dual 3,1 and I don’t know who all has a dual 5,1 but the logs from the 5,1 ive seen appear to be only 1 package.
With a target value of 113, you have the non-volatile flag. So it is expected that OC writes to NVRAM. Try 65 to only log to file.
I have a dual CPU system, and I seem to recall OC detecting both. However, ever since the bricking risk was discovered, I have not used OC beyond the basic configuration in the guide.
From what I understand, target is where the logging output occurs. I think file logging is sufficient.
Note that the manual warns about using non-volatile NVRAM logging, because some firmwares may not be able to free space after deleting variables. Perhaps this is part of what we are seeing.
Well there are some good news:
I tried NVRAM reset from the OC bootpicker. It cleared all instances of "opencore" or just "open" in the firmware as well as the normal MAC NVRAM variables such as SIP or boot arguments. Next I booted from the USB where my OC is through the apple bootpicker and in the OC configuration there is a Csr_active_config set to disable the SIP, so it disabled it without going to the recovery partition
Last edited:
NVRAM delete log file:
Code:
41:253 00:039 OCB: Found FW NVRAM, full access 0
41:299 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:bluetoothInternalControllerInfo... OK
41:349 00:050 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:EFIBluetoothDelay... OK
41:396 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:fmm-computer-name... OK
41:442 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:csr-active-config... OK
41:488 00:045 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:fmm-mobileme-token-FMM-BridgeHasAccount... OK
41:536 00:047 Deleting 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0081... OK
41:582 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload0-data... OK
41:628 00:045 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload0... OK
41:676 00:048 Deleting 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootOrder... OK
41:722 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:bluetoothActiveControllerInfo... OK
41:780 00:057 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:_kdp_ipstr... OK
41:826 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:SystemAudioVolumeDB... OK
41:874 00:048 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:security-key... OK
41:920 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:AAPL,PanicInfoLog... OK
41:967 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:BootCampHD... OK
42:013 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:prev-lang:kbd... OK
42:062 00:048 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:fmm-mobileme-token-FMM... OK
42:108 00:046 Deleting 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootFFFF... OK
42:155 00:047 Deleting 36C28AB5-6566-4C50-9EBD-CBB920F83843:current-network... OK
42:202 00:047 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-backup-boot-device-data... OK
42:248 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-backup-boot-device... OK
42:294 00:045 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-backup-boot-device-data-data... OK
42:340 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:SystemAudioVolume... OK
42:388 00:047 Deleting 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080... OK
42:446 00:057 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-boot-device-data... OK
42:492 00:046 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-boot-device... OK
42:540 00:048 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:AAPL,PathProperties0001... OK
42:586 00:046 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:AAPL,PathProperties0002... OK
42:632 00:046 Deleting 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-log... OK
42:679 00:046 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:AAPL,PathProperties0000... OK
42:722 00:043 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:FirmwareFeaturesMask... OK
42:762 00:039 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:system-id... OK
42:802 00:039 Deleting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:FirmwareFeatures... OK
42:841 00:039 Deleting 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootCurrent... OK
42:882 00:041 Deleting 7C436110-AB2A-4BBB-A880-FE41995C9F82:boot-args... OK
42:922 00:039 Deleting 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version... OK
42:961 00:039 Deleting 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path... OK
43:002 00:041 OCB: Restoring FW NVRAM...
Last edited:
And no more "secure boot" certificates in the firmware. Overall ithe NVRAM clean option in OC bootpicker cleans pretty well NVRAM
Indeed 65 does not write to the NVRAM. Attached is a configuration for safe debug logging. Opencore version: DBG-053-2019-11-26
Another thing for you guys to try regarding HEVC on native Mac Pro SMBIOS with latest WEG / Lilu Builds. Set shikigva=16 only without a board-id spoof. According to vit9696 this should work. I somehow doubt it tho.
Feel free to report your results on your own here: https://www.insanelymac.com/forum/t...support-topic/?do=findComment&comment=2699066
Feel free to report your results on your own here: https://www.insanelymac.com/forum/t...support-topic/?do=findComment&comment=2699066
It isn't surprising you get a boot loop when using two different shikigva boot-args since that is not how it works. The value of shikigva is a sum and the result by adding parameters which each have a different value. Here is an excerpt of the source code for better understanding:
Anyhow, if using solely shikigva=16 doesn't work things are as already expected. Doesn't work just like the board-id spoof. WEG seems to be broken with regards to that but it looks like DEVs don't want to admit it.
Edit: Another thing to test. Does adding -wegtree boot-arg trigger proper device renaming for your Mac Pros? GPU should be called GFX0 in IOReg if it does.
Code:
// Aside generic DRM unlock patches, which are always on, Shiki also provides a set of patches
// to workaround various issues with hardware video acceleration support.
// These are set as a shikigva boot-arg bitmask.
// For example, to enable ForceOnlineRenderer, ExecutableWhitelist, and ReplaceBoardID
// you sum 1 + 8 + 32 = 41 -> and pass shikigva=41.
enum ShikiGVAPatches {
// Remove forceOfflineRenderer from AppleGVA Info.plist.
// This is required to allow hardware acceleration on several mac models with discrete GPUs
// when only IGPU is available.
// See /System/Library/PrivateFrameworks/AppleGVA.framework/Resources/Info.plist for more details.
ForceOnlineRenderer = 1,
// Remve hweBGRA from AppleGVA Info.plist.
// hweBGRA is not supported by NVIDIA GPUs, so the patch is sometimes required when using NVIDIA
// in a mac model meant to be used with AMD or Intel.
// See /System/Library/PrivateFrameworks/AppleGVA.framework/Resources/Info.plist for more details.
AllowNonBGRA = 2,
// Prior to 10.13.4 certain GPU+CPU combinations were not meant to provide hardware acceleration and had to be patched.
// The overall problematic configuration list is: NVIDIA+BDW, NVIDIA+SKL, NVIDIA+KBL, AMD+IVB, NVIDIA+SNB.
// Enabled automatically if shikigva is *NOT* passed on 10.13.3 and earlier. All are fixed in 10.13.4.
ForceCompatibleRenderer = 4,
// Unlike 10.12.6 without security updates and earlier, on 10.13 and latest 10.12.6 AppleGVA patches
// do not apply to all processes, and each process needs to be patched explicitly. This is a bug
// in Lilu, which needs to be explored and fixed. For now this bit ensures that the processes present
// in WHITELIST section of Patches.plist will definitely get the fixes even on 10.13 and 10.12.6.
// On 10.12.6 and 10.13 this must be used if any of the following bits are used:
// - ForceOnlineRenderer
// - AllowNonBGRA
// - ForceCompatibleRenderer
// - ReplaceBoardID
// - FixSandyBridgeClassName
// It is enabled automatically on 10.12 and 10.13 if shikigva is *NOT* passed and ForceCompatibleRenderer or
// FixSandyBridgeClassName are automatically enabled.
AddExecutableWhitelist = 8,
// Use hardware decoder (normally AMD) by pretending to be iMacPro in apps that require it.
// For example, in Music.app or in TV.app for TV+.
UseHwDrmDecoder = 16,
// Replace board-id used by AppleGVA and AppleVPA by a different board-id.
// Sometimes it is feasible to use different GPU acceleration settings from the main mac model.
// By default Mac-27ADBB7B4CEE8E61 (iMac14,2) will be used, but you can override this via shiki-id boot-arg.
// See /System/Library/PrivateFrameworks/AppleGVA.framework/Resources/Info.plist for more details.
ReplaceBoardID = 32,
// Attempt to support fps.1_0 (FairPlay 1.0) in Safari.
// This should technically fix some very old streaming services in Safari, which rely on FairPlay DRM
// similar to the one found in iTunes. Newer streaming services require FairPlay 2.0, which is hardware-only,
// so nothing could be done about them.
UnlockFP10Streaming = 64,
// Disables software decoder unlock patches for FairPlay 1.0.
UseLegacyHwDrmDecoder = 128
};Anyhow, if using solely shikigva=16 doesn't work things are as already expected. Doesn't work just like the board-id spoof. WEG seems to be broken with regards to that but it looks like DEVs don't want to admit it.
Edit: Another thing to test. Does adding -wegtree boot-arg trigger proper device renaming for your Mac Pros? GPU should be called GFX0 in IOReg if it does.
Last edited: