MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[vit9696]

So, regarding NVRAM and SecureBoot certificates. Windows does not hash the firmware, and there is no such thing at all. It cannot do it in the first place, as it does not have a SPI driver to access its memory. However, it does write large NVRAM variables containing secure boot database (db, dbx, dbt, dbr, PK, KEK). I believe MacPro5,1 has the same issue as Insyde, very likely it has borked garbage collection and thus simply cannot handle that. Recent OpenCore supports ProtectSecureBoot option, it will abort any write attempt to these variables and should fix NVRAM issues when booting Windows in UEFI mode.

OpenCore also received a very serious update to output subsystem. For MacPro5,1 you need to set Resolution to Max, TextRenderer to BuiltinGraphics, ProvideConsoleGop to YES, Scale to 100. Leave the rest as NO/empty. I will add the Radeon VII users to the PM soon (let me know if I did not). In case the issue with no output is still present, I will need you to update to the latest OC, set the configuration as prescribed, and include OC directory and OpenCore log.

@astonius86, regarding multiple operating systems on the same drive. Currently you can either put OpenCore's BOOTx64.efi to some other place and bless it (unsure how well it works). Or remove Windows' BOOTx64.efi and add BlessOverride with \EFI\Microsoft\Boot\bootmgfw.efi (you will also have to disable HideSelf). The latter is covered in the configuration manual "12.1 Windows support".

 

[startergo]

Are your Windows 10 and macOS partitions on the same physical drive? Did you overwrite a bootx64.efi when you installed OC? Also, my PCIe drive is AHCI, not NVMe. Not sure if this makes a difference, but @w1z seemed to believe it might, and I should mention it to @vit9696 as well (forgot to do so in my original message).

As I said. Everything is on a dedicated drive. OC is on a USB. This is an cMP not a Mac mini or a MacBook pro. Best is to install different os's on its own dedicated drive.

 

[rroumen]

Let's see if rroumen can get us some good news.

Well you beat me to it, I just compiled latest 0.5.6 dbg and reconfigured config.plist. I set ui to color 121 / 0x79 which should be blue on grey but I have not been able to boot OC anymore, I also see no bootlog so must have screwed up somewhere.

 

[startergo]

Well you beat me to it, I just compiled latest 0.5.6 dbg and reconfigured config.plist. I set ui to color 121 / 0x79 which should be blue on grey but I have not been able to boot OC anymore, I also see no bootlog so must have screwed up somewhere.

See if you did not copy RELEASE instead of DEBUG by mistake.

 

[astonius86]

@astonius86, regarding multiple operating systems on the same drive. Currently you can either put OpenCore's BOOTx64.efi to some other place and bless it (unsure how well it works). Or remove Windows' BOOTx64.efi and add BlessOverride with \EFI\Microsoft\Boot\bootmgfw.efi (you will also have to disable HideSelf). The latter is covered in the configuration manual "12.1 Windows support".

I must have overlooked that section of the guide. This worked like a charm! No need for a second drive anymore.

One more question: I can successfully switch from Windows 10 to macOS through Boot Camp, however Startup Disk doesn't even see my Windows partition anymore (it did before I made this change). Do I still need to run a bless command to switch from macOS to Windows, or is there a way to use Startup Disk?

 

[vit9696]

I must have overlooked that section of the guide. This worked like a charm! No need for a second drive anymore.

One more question: I can successfully switch from Windows 10 to macOS through Boot Camp, however Startup Disk doesn't even see my Windows partition anymore (it did before I made this change). Do I still need to run a bless command to switch from macOS to Windows, or is there a way to use Startup Disk?

You will have to update FirmwareFeatures/FirmwareFeaturesMask in PlatformNVRAM and SMBIOS for this to work. It is simple if you use Automatic, just enable AdviseWindows. For manual you will have to update corresponding sections in both PlatformNVRAM and SMBIOS manually (according to bits found in OC).

 

[rroumen]

Well you beat me to it, I just compiled latest 0.5.6 dbg and reconfigured config.plist. I set ui to color 121 / 0x79 which should be blue on grey but I have not been able to boot OC anymore, I also see no bootlog so must have screwed up somewhere.

@vit9696
Well got it booting again although still some strange behaviour regarding "StartupDisk" but will look into that later: including "StartupDisk":

1) Small step forward I think, now I get the light grey bootscreen as expected with PickerAttributes 0x79 but still no bootmenu text yet. (Tested other background colours, work also)
2) From the config pdf it states that ConsoleMode should not make a difference for Builtin text renderer but I do see a difference in the log file as below.
3) If I use "SystemGraphics" / "SystemText" I don't get the grey background according to PickerAttributes and log shows:
00:196 00:002 OCC: Requesting 0x0 (max: 1) console mode, curr 0, max 1
00:198 00:001 OCC: Mode 0 - 80x25
4) I noticed that the "Install console control" address changes with every boot. Is this expected behaviour?
00:220 00:006 OCC: Install console control (73ED0730/0/0) - Success
00:192 00:001 OCC: Install console control (73ED67A0/0/0) - Success
00:211 00:002 OCC: Install console control (73ED47A0/0/0) - Success

Attached my EFI folder and bootlog.

<ConsoleMode> blank:
00:000 00:000 OC: OpenCore DBG-056-2020-02-09 is loading in Optional mode (0/0)...
00:143 00:002 OCC: GOP exists on ConsoleOutHandle and has 0 modes
00:145 00:002 OCC: Looking for GOP replacement due to invalid mode count
00:148 00:002 OCC: Alternative GOP status is - Success
00:152 00:004 OC: Requested resolution is 0x0@0 (max: 1) from Max
00:155 00:002 OCC: Requesting 0x0@0 (max: 1) resolution, curr 4294967295, total 8
00:157 00:002 OCC: Mode 0 - 3840x2160:1
00:159 00:002 OCC: Mode 1 - 640x480:1
00:162 00:002 OCC: Mode 2 - 800x600:1
00:164 00:002 OCC: Mode 3 - 1024x768:1
00:166 00:002 OCC: Mode 4 - 1280x1024:1
00:169 00:002 OCC: Mode 5 - 1400x1050:1
00:171 00:002 OCC: Mode 6 - 1600x1200:1
00:174 00:002 OCC: Mode 7 - 1280x960:1
00:176 00:002 OCC: Setting mode 0 with 3840x2160 resolution
00:203 00:026 OCC: Changed resolution mode to 0
00:205 00:002 OC: Changed resolution to 0x0@0 (max: 1) from Max - Success
00:208 00:002 OCC: Using builtin text renderer with 1 scale
00:214 00:006 OCC: Install console control (73EBE730/0/0) - Success
00:217 00:002 OC: Requested console mode is 0x0 (max: 0) from

<ConsoleMode> Max:
00:000 00:000 OC: OpenCore DBG-056-2020-02-09 is loading in Optional mode (0/0)...
00:131 00:001 OCC: GOP exists on ConsoleOutHandle and has 0 modes
00:133 00:001 OCC: Looking for GOP replacement due to invalid mode count
00:135 00:001 OCC: Alternative GOP status is - Success
00:137 00:001 OC: Requested resolution is 0x0@0 (max: 1) from Max
00:139 00:001 OCC: Requesting 0x0@0 (max: 1) resolution, curr 4294967295, total 8
00:140 00:001 OCC: Mode 0 - 3840x2160:1
00:142 00:001 OCC: Mode 1 - 640x480:1
00:144 00:001 OCC: Mode 2 - 800x600:1
00:146 00:001 OCC: Mode 3 - 1024x768:1
00:148 00:001 OCC: Mode 4 - 1280x1024:1
00:149 00:001 OCC: Mode 5 - 1400x1050:1
00:154 00:004 OCC: Mode 6 - 1600x1200:1
00:158 00:004 OCC: Mode 7 - 1280x960:1
00:160 00:001 OCC: Setting mode 0 with 3840x2160 resolution
00:187 00:026 OCC: Changed resolution mode to 0
00:188 00:001 OC: Changed resolution to 0x0@0 (max: 1) from Max - Success
00:190 00:001 OCC: Using builtin text renderer with 1 scale
00:196 00:005 OCC: Install console control (73EC3730/0/0) - Success
00:198 00:001 OC: Requested console mode is 0x0 (max: 1) from Max
00:200 00:001 OCC: Requesting 0x0 (max: 1) console mode, curr 0, max 1
00:202 00:001 OCC: Mode 0 - 478x133
00:203 00:001 OCC: Current console mode matches desired mode 0, forcing update
00:205 00:001 OCC: Setting mode 0 (prev 0) with 478x133 console mode
00:207 00:001 OCC: Changed console mode to 0
00:209 00:001 OC: Changed console mode to 0x0 (max: 1) from Max - Success

 

[vit9696]

Thanks for the test, please try with the OpenCore version I attached in the PM, and reply there. I think we may have text outside of the screen, but that yet needs to be proven.
— System renderer will never work on MacPro with a generic GPU
— ConsoleMode log difference does exist, but it does not do anything
— The address is supposed to change, this is ok

 

[astonius86]

You will have to update FirmwareFeatures/FirmwareFeaturesMask in PlatformNVRAM and SMBIOS for this to work. It is simple if you use Automatic, just enable AdviseWindows. For manual you will have to update corresponding sections in both PlatformNVRAM and SMBIOS manually (according to bits found in OC).

Thank you. I would like to use Automatic, but to get HEVC encode I'm using BoardProduct.

I'm totally in the dark when it comes to setting the appropriate bits in these .plist files. Do you have a link to a good walkthrough or tutorial on how to set these FirmwareFeatures and FirmwareFeaturesMask bits appropriately? I see this in the doc...

FW_FEATURE_SUPPORTS_UEFI_WINDOWS_BOOT (0x20000000)

...but I don't know how to actually translate that into something I can put in the config.

 

[vit9696]

@astonius86 you will need to perform bitwise OR of this value with the original values you can take from e.g. MacInfoPkg (see this link) or dump with dmidecode (we have it on github). Check google/wiki and use calculator in programmer mode in case bitwise maths sounds a bit tricky.

 

[startergo]

I'm totally in the dark when it comes to setting the appropriate bits

It is simple if you use Automatic, just enable AdviseWindows

 

[astonius86]

I saw that. I have Automatic set to false to override BoardProduct for HEVC encoding.

Just to be sure, I switched back to Automatic TRUE with AdviseWindows set to TRUE as well. Windows still doesn't appear in Startup Disk.

 

[w1z]

So, regarding NVRAM and SecureBoot certificates. Windows does not hash the firmware, and there is no such thing at all. It cannot do it in the first place, as it does not have a SPI driver to access its memory. However, it does write large NVRAM variables containing secure boot database (db, dbx, dbt, dbr, PK, KEK). I believe MacPro5,1 has the same issue as Insyde, very likely it has borked garbage collection and thus simply cannot handle that. Recent OpenCore supports ProtectSecureBoot option, it will abort any write attempt to these variables and should fix NVRAM issues when booting Windows in UEFI mode.

OpenCore also received a very serious update to output subsystem. For MacPro5,1 you need to set Resolution to Max, TextRenderer to BuiltinGraphics, ProvideConsoleGop to YES, Scale to 100. Leave the rest as NO/empty. I will add the Radeon VII users to the PM soon (let me know if I did not). In case the issue with no output is still present, I will need you to update to the latest OC, set the configuration as prescribed, and include OC directory and OpenCore log.

We are loving all these new features and are very thankful for your time and effort ?

On to the results -

On the new ProtectSecureBoot feature - I reflashed a clean ROM that does not include any of Windows' certs or XML, booted Windows via OC then dumped the rom and noticed a new cert was added -

On the reworked boot screen support under OC - I can now see the Apple boot logo and progress bar as soon as macOS boots which is FANTASTIC! Does this mean we can now enable Filevault?

Note: I needed to set Scale to 200.

Unfortunately, I did not compile/use the debug version of OC to provide you with logs but will do so later today.

Thanks again for OC!

 

[astonius86]

@astonius86 you will need to perform bitwise OR of this value with the original values you can take from e.g. MacInfoPkg (see this link) or dump with dmidecode (we have it on github). Check google/wiki and use calculator in programmer mode in case bitwise maths sounds a bit tricky.

Started with the hex values from MacInfoPkg as linked. Ran through a bitwise OR with 0x20000000, and the value didn't change, so the bit must be pre-flipped? I then converted the hex to base64 and put it in both the NVRAM and SMBIOS sections of the config. No luck, still no Windows partition in Startup Disk. I also tried the extended 64-bit versions.

Config and latest log attached.

 

[Ludacrisvp]

Does this mean we can now enable Filevault?

I would think that would be a ”YES”.
But you’ll have to use a workaround like the one I posted to remove the board id check or boot with modded smbios settings to be able to enable it. (Assuming you arent already for AMD acceleration).

I was able to boot refit with GOP for a FileVault enabled partition on my 3,1... but I’m not sure without testing again.

 

[vit9696]

@w1z, please send me the original and the new firmware dump via PM. Perhaps some extra variable needs to be included.

@astonius86, this is a bit strange. The bit (as well as the other one) is indeed set in MacInfoPkg, so the values are already correct there. I am not positive they are on a real MacPro (as we do not always have latest system dumps), but they likely may. In case the values match when you run dmidecode and it says that both bits (yes, should be both, 0x20000000 and 0x1) are set, it is likely either some board-id check or some mac model check.

You can use wincheck utility to test your disk for being Windows UEFI Boot capable: https://github.com/acidanthera/bugtracker/issues/327#issuecomment-583819821.
The utility works in 10.14 as it relies on private APIs. The workflow is roughly this:

sudo mkdir /Volumes/DiskManagementLog
sudo touch /Volumes/DiskManagementLog/com.apple.diskmanagement.log
sudo ./wincheck /Volumes/WindowsPartition
cat /Volumes/DiskManagementLog/com.apple.diskmanagement.log
sudo rm -rf /Volumes/DiskManagementLog

UPD: Note, that BootKicker and Apple BootPicker supported landed in OpenCore master.

 

[cdf]

@vit9696 Many thanks for the updates. The current version now displays the APFS JumpStart verbosity right before the picker. With PickerMode=Apple (and without BootPicker being blessed), this is the only thing that stays on the screen.

With Builtin, the picker appears after the verbosity, but the background no longer fills the screen.

 

[startergo]

Guys the latest revision has completely reworked config file. I attempted to test it, but I got a black screen and it never finished booting. I also noticed additional EFI drivers being compiled do we need to add them to the config file connect drivers?

 

[cdf]

Guys the latest revision has completely reworked config file. I attempted to test it, but I got a black screen and it never finished booting. I also noticed additional EFI drivers being compiled do we need to add them to the config file connect drivers?

Take a look at the differences document to update your config file. I was able to boot fine, although not with PickerMode=Apple.

 

[w1z]

@w1z, please send me the original and the new firmware dump via PM. Perhaps some extra variable needs to be included.

Working on it. I'm compiling the latest debug version, reflashing and I'll PM you the rom dumps and logs.

Thanks

 

[astonius86]

@astonius86, this is a bit strange. The bit (as well as the other one) is indeed set in MacInfoPkg, so the values are already correct there. I am not positive they are on a real MacPro (as we do not always have latest system dumps), but they likely may. In case the values match when you run dmidecode and it says that both bits (yes, should be both, 0x20000000 and 0x1) are set, it is likely either some board-id check or some mac model check.

Unfortunately I don't have a 10.14 install handy, only 10.15. Not sure if this info helps, but Windows used to appear in Startup Disk before doing the BlessOverride.

Also, I ran dmidecode, and this was my output in regards to FirmwareFeatures:

Apple specific FirmwareVolume
FirmwareFeatures: 0
FirmwareFeaturesMask: 0

Guessing this isn't right?

 

[w1z]

@vit9696 Sent you a PM with the archive.


Cheers

 

[startergo]

but the background no longer fills the screen.

Wait how did you get the white background?

 

[cdf]

Wait how did you get the white background?

This white (or gray) background is what the default (PickerAttributes=0) gives me.

 

[startergo]

For me it is 112.

01:199 00:062 OCC: GOP exists on ConsoleOutHandle and has 0 modes
01:270 00:071 OCC: Looking for GOP replacement due to invalid mode count
01:333 00:062 OCC: Alternative GOP status is - Success
01:394 00:061 OC: Requested resolution is 0x0@0 (max: 1) from Max
01:462 00:068 OCC: Requesting 0x0@0 (max: 1) resolution, curr 4294967295, total 7
01:523 00:060 OCC: Mode 0 - 1920x1080:1
01:584 00:061 OCC: Mode 1 - 640x480:1
01:733 00:149 OCC: Mode 2 - 800x600:1
01:796 00:062 OCC: Mode 3 - 1024x768:1
01:857 00:061 OCC: Mode 4 - 1280x1024:1
01:931 00:073 OCC: Mode 5 - 1400x1050:1
01:993 00:062 OCC: Mode 6 - 1280x960:1
02:055 00:062 OCC: Setting mode 0 with 1920x1080 resolution
02:140 00:084 OCC: Changed resolution mode to 0
02:202 00:062 OC: Changed resolution to 0x0@0 (max: 1) from Max - Success
02:264 00:061 OCC: Using builtin text renderer with 1 scale
02:344 00:079 OCC: Install console control (75070910/0/0) - Success
02:405 00:061 OC: Requested console mode is 0x0 (max: 1) from Max
02:466 00:061 OCC: Requesting 0x0 (max: 1) console mode, curr 0, max 1
03:285 00:818 OCC: Mode 0 - 238x65
03:347 00:061 OCC: Current console mode matches desired mode 0, forcing update
03:408 00:061 OCC: Setting mode 0 (prev 0) with 238x65 console mode
03:482 00:073 OCC: Changed console mode to 0
03:544 00:062 OC: Changed console mode to 0x0 (max: 1) from Max - Success
03:607 00:062 OC: Got 1 drivers
03:681 00:074 OC: Driver FwRuntimeServices.efi at 0 is being loaded...
03:884 00:203 OC: Driver FwRuntimeServices.efi at 0 is successfully loaded!