For me everything looks OK it says it installs the upgrade then it reboots (not completely) it starts "updating" it reaches 50%, reboots and upon check it says it failed to install update.
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
My Bootrom is corrupted after installing Windows in UEFI Mode. Do you want to check my dump? PM?
Got it!
So, the key to making this work appears to be RequestBootVarFallback in combo with RequestBootVarRouting, BlessOverride and AdviseWindows, plus HideSelf set to false.
Once this was set (with an NVRAM reset for good measure) the installation proceeded without any issue. I performed it with only the Windows drive in Bay 4, so I can't attest to this working with multiple drives installed.
Funnily enough, with no specific bless and OC on all drives with operating systems installed the Mac Pro seems to pick up the copy of OC from the Windows drive (in Bay 4) each time, which has this layout:
The only residual effect I’m seeing are EFI entries in the boot picker. It would be nice to be able to specifically mark those EFI partitions as Auxiliary to prevent them from appearing, but the way Entries are handled in config.plist doesn't appear to provide a way to mark automatically discovered partitions as Auxiliary, either generically (by using the drive name) or by UUID.
It would be quite nice to lose the 'BOOTCAMP' in front of 'Windows' as well, but now I'm just being pernickety. I did find some info on how the naming is performed, but appear to have lost it. Something to do with hidden files, IIRC.
Last thing, I've also discovered that with the BCM943602CDP card installed for 802.11ac Wifi and Bluetooth 4.2 the only driver required from the old MacPro5,1 Boot Camp package is the Realtek one for the internal speaker. Everything else is either installed automatically by Windows 10 or available in the iMacPro1,1 package. The Bluetooth drivers are not in the usual Drivers folder, but in
So, the key to making this work appears to be RequestBootVarFallback in combo with RequestBootVarRouting, BlessOverride and AdviseWindows, plus HideSelf set to false.
Once this was set (with an NVRAM reset for good measure) the installation proceeded without any issue. I performed it with only the Windows drive in Bay 4, so I can't attest to this working with multiple drives installed.
Funnily enough, with no specific bless and OC on all drives with operating systems installed the Mac Pro seems to pick up the copy of OC from the Windows drive (in Bay 4) each time, which has this layout:
Code:
/dev/disk4 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk4
1: Windows Recovery 554.7 MB disk4s1
2: EFI EFI 104.9 MB disk4s2
3: Microsoft Reserved 16.8 MB disk4s3
4: Microsoft Basic Data Windows 10 999.5 GB disk4s4The only residual effect I’m seeing are EFI entries in the boot picker. It would be nice to be able to specifically mark those EFI partitions as Auxiliary to prevent them from appearing, but the way Entries are handled in config.plist doesn't appear to provide a way to mark automatically discovered partitions as Auxiliary, either generically (by using the drive name) or by UUID.
It would be quite nice to lose the 'BOOTCAMP' in front of 'Windows' as well, but now I'm just being pernickety. I did find some info on how the naming is performed, but appear to have lost it. Something to do with hidden files, IIRC.
Last thing, I've also discovered that with the BCM943602CDP card installed for 802.11ac Wifi and Bluetooth 4.2 the only driver required from the old MacPro5,1 Boot Camp package is the Realtek one for the internal speaker. Everything else is either installed automatically by Windows 10 or available in the iMacPro1,1 package. The Bluetooth drivers are not in the usual Drivers folder, but in
BootCamp-041-88815\$WinPEDriver$\BroadcomBluetoothHID64.
Last edited:
I have this enabled all the time, but I still can't update. I may try insider preview program.
Well I found the cause of my sleep issue. It is the USB 3.1 Orinoco pcie card...?
Never had an issue with it but now after 1st sleep-wake it will not sleep again and I get these DarkWake loggings:
2020-02-19 15:31:40 +0100 DarkWake DarkWake from Normal Sleep [CDN] : due to /Network Using AC (Charge:0%) 15 secs
After romping the USB card sleep works. I tried booting into Mojave, same issue. I booted Mojave without OC, same issue. Reset SMC, same issue, reset NVRAM, same issue.
Btw: Wake for network access is unticked and Allow bluetooth devices to wake this computer is also unticked.
I'm lost, any suggestion?
Since you've done so many things ;-), can you help provide step by step of your working configuration?
Yeah, I’ll write it up. Usually need to remind myself how to do these things after a couple of weeks.
@roobarb! that looks like awesome progress!!!
With ROMTool (that you kindly provided!) I’ve dumped all three selections for choice of chip (I’m assuming the first one that it is on is the one that is automatically chosen between systems?) but in all three chips I don’t seem to have any single windows certs in my nvram! *phew*
With that said I’m assuming that once I’ve dumped the correct one for my mobo and keep it for safe keeping, if I did ever get any certs I could just flash it back over with ROMTool?
I’ve also seen that you shall hopefully be writing up how you managed it.... When you do would you mind hyperlinking it for us? Because that would be awesome!!
With ROMTool (that you kindly provided!) I’ve dumped all three selections for choice of chip (I’m assuming the first one that it is on is the one that is automatically chosen between systems?) but in all three chips I don’t seem to have any single windows certs in my nvram! *phew*
With that said I’m assuming that once I’ve dumped the correct one for my mobo and keep it for safe keeping, if I did ever get any certs I could just flash it back over with ROMTool?
I’ve also seen that you shall hopefully be writing up how you managed it.... When you do would you mind hyperlinking it for us? Because that would be awesome!!
The ROMTool is all the work of @dosdude1, I take no credit for it! Beyond my capabilities.
Yes, so long as your BootROM isn't corrupted to the point of not starting the machine properly. Which leads on to my next remark.
I'll probably do a quick write-up on a post here tomorrow, but having lived with this setup for not very long, I'm already of the mindset to go back to my position that people should NOT run Windows UEFI on MacPro5,1. In my experience there is something too easily broken with the Windows UEFI boot process and the ramifications of leaving it unchecked are too grave. I don't know if it's Windows' or OC's fault, but it's too flakey for me to put up with right now.
Here's a quick write-up of the process I took to get OpenCore (OC) booting macOS and Windows in UEFI mode on the MacPro5,1. I don't recommend doing this right now. There's something flakey in either OC, my configuration of OC, or Windows itself which will eventually result in your Windows installation failing to boot.
The danger we're trying to avoid here is Windows ever booting autonomously in UEFI mode, outside of the control of OC. If this happens, your BootROM is likely to be immediately damaged by secure boot certificates being written which it wasn't designed to handle. We're getting around this by replacing part of the Windows bootloader with OpenCore.
So, if you like the idea of bricking your Mac Pro and having a copy of Windows that doesn't always work, crack on! I make no promises that this is the best method or a good fit for your needs.
Requirements
Hopefully that's enough to keep your expectations low. If you have greater success with alternative methods or config.plist files, please post.
NOTE: I modified BootEntryManagement.c in the OcSupportPkg code to read only "Windows" instead of "BOOTCAMP Windows" in the attached EFI. This may or may not be a sensible thing to do.
The danger we're trying to avoid here is Windows ever booting autonomously in UEFI mode, outside of the control of OC. If this happens, your BootROM is likely to be immediately damaged by secure boot certificates being written which it wasn't designed to handle. We're getting around this by replacing part of the Windows bootloader with OpenCore.
So, if you like the idea of bricking your Mac Pro and having a copy of Windows that doesn't always work, crack on! I make no promises that this is the best method or a good fit for your needs.
Requirements
- Working macOS Mojave 10.14.6 on its own internal SATA drive installed in Bay 1.
- Separate internal SATA drive for Windows. Mine was in Bay 4.
- Have no other drives attached.
- ROMTool from @dosdude1 (password 'rom').
- Attached OpenCore EFI.
- Windows 10 installer on a USB stick.
- Time to burn and willingness to suffer.
- Power on and clear your NVRAM by holding down CMD-ALT-P-R over the chime.
- Disable SIP by booting into Mojave Recovery (CMD-R) and using the Terminal to issue
csrutil disable - Allow Mojave to boot and use ROMTool to take a backup of your BootROM. Keep it safe.
- Load the resulting
.binfile into TextEdit. Search contents for the word 'Secure'. - If you have any matching results STOP. Your BootROM already has problems, it doesn't need more.
- Format the drive intended for Windows to Mac OS Extended (Journaled) with GUID Partition Map.
- Note the Device number for that Windows drive in Disk Utility. We'll use disk2 in this example.
- Fire up Terminal and issue:
sudo diskutil mount /dev/disk2s1 - Browse to the drive named EFI which has appeared in Finder. It should be empty. If it's not, delete the contents. Decompress the attached OpenCore EFI directory and copy the EFI directory to the root of the EFI drive.
- Go back to Terminal and issue:
sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/BOOT/BOOTx64.efi --verbose - Stick the Windows installer USB into a socket and power off.
- Pull the Mojave drive from Bay 1 and power up.
- You should see the OpenCore Boot Menu. Pick your Windows installer.
- When asked about the drive to install to, delete all the partitions and let Windows do its thing.
- At around 29% the Windows installer will reboot your machine. Power it off when you hear the chime.
- Insert your Mojave drive to Bay 1.
- Boot to Mojave Recovery (CMD-R) and use Startup Disk from the Apple menu to choose macOS Mojave. Reboot into Mojave.
- Check the Device number for your Windows drive in Disk Utility again. I'll assume it's still disk2 here, but it may not be.
- Fire up Terminal and issue:
sudo diskutil mount /dev/disk2s2 - Browse to the drive named EFI which has appeared in Finder. It should contain an EFI directory, in which there should be Boot and Microsoft directories.
- Delete the Boot directory.
- Copy the BOOT and OC directories from the OpenCore EFI directory you decompressed from the attached
.zipfile earlier. - Power off your machine and pull the Mojave drive from Bay 1.
- Power on your machine and clear your NVRAM by holding down CMD-ALT-P-R over the chime.
- You should see the OpenCore Boot Menu with an entry for 'Windows' (not external). Set it as the default by choosing it and pressing CTRL-ENTER.
- Allow the rest of the installation to proceed as normal. All reboots should show the OpenCore Boot Menu before booting into Windows. If it doesn't appear, panic and power off your machine.
- You should now have a working copy of Windows in UEFI mode protected by OpenCore.
- Install all drivers you need under Windows, probably using Brigadier to fetch the MacPro5,1 and iMacPro1,1 bundles.
- Power off and insert your Mojave drive into Bay 1.
- Power on. You should see Windows and Mojave appear as boot options on the OpenCore Boot Menu.
- Boot to Mojave and use ROMTool to take another backup of your BootROM.
- Load the resulting
.binfile into TextEdit. Search contents for the word 'Secure' again. Fingers crossed you shouldn't find anything.
Hopefully that's enough to keep your expectations low. If you have greater success with alternative methods or config.plist files, please post.
NOTE: I modified BootEntryManagement.c in the OcSupportPkg code to read only "Windows" instead of "BOOTCAMP Windows" in the attached EFI. This may or may not be a sensible thing to do.
Last edited:
I believe step 1 and 2 should be in reverse order.
Reason - NVRAM reset will automatically re-enable SIP
Oopsie, yes, you're right. Written from memory and stumbled at the first hurdle. Fixed!
Last edited:
I don't think this is an accurate statement. You may say a certificate will be written in the firmware. it may be damaged after 3 certificates, but not necessarily. Evidence showed so far this certificate appearing written 3 times in some machines using an old firmware revision. And it is believed that is what prevented the machines from booting and to be the cause of corruption. By now if a person is using Mojave the firmware revision is well past that firmware.
Depends on how you look at it. Can an end user easily expunge this certificate if they have no backup? I'm not aware of how they can, so I consider a certificate written to my BootROM to be damage. After a certain amount of damage, it'll stop working.
You are thinking with just one view of the problem, 3 certificates + variables + db inside will consume the available space, so you can’t change your boot drive or do anything.
Even two will make havoc if you have 27 MemoryConfig entries written all over like a dump I saw yesterday.
Last edited:
I am just curious about the 3 certificates. Are you 100% sure those certificates are the cause for the firmware corruption and not an indication (after fact) of a firmware corruption? In other words Windows writes the third certificate, because of the firmware corruption in the first place? Can you elaborate more on the 27 MemoryConfig entries? What is causing them?
This is what I'm talking about:
[automerge]1582215295[/automerge]
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
243907 0x3B8C3 BIOS version: MP51.88Z.F000.B00.1904121248
524288 0x80000 UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
768195 0xBB8C3 BIOS version: MP51.88Z.F000.B00.1904121248
1048576 0x100000 UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1064960 0x104000 UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1065216 0x104100 Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1077504 0x107100 Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1085696 0x109100 Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1114112 0x110000 UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1130496 0x114000 UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1130752 0x114100 Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1143040 0x117100 Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1151232 0x119100 Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1179648 0x120000 UEFI PI Firmware Volume, volume size: 196608, header size: 1, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50
1179688 0x120028 NVRAM start of the 1st VSS stream
1179766 0x120076 NVRAM MemoryConfig type: (i)
1181814 0x120876 NVRAM MemoryConfig type: (j)
1183658 0x120FAA Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1193508 0x123624 NVRAM MemoryConfig type: (g)
1195556 0x123E24 NVRAM MemoryConfig type: (h)
1197709 0x12468D NVRAM MemoryConfig type: (g)
1199757 0x124E8D NVRAM MemoryConfig type: (h)
1201910 0x1256F6 NVRAM MemoryConfig type: (g)
1203958 0x125EF6 NVRAM MemoryConfig type: (h)
1206111 0x12675F NVRAM MemoryConfig type: (g)
1208159 0x126F5F NVRAM MemoryConfig type: (h)
1210312 0x1277C8 NVRAM MemoryConfig type: (g)
1212360 0x127FC8 NVRAM MemoryConfig type: (h)
1214973 0x1289FD NVRAM MemoryConfig type: (g)
1217021 0x1291FD NVRAM MemoryConfig type: (h)
1219770 0x129CBA NVRAM MemoryConfig type: (g)
1221818 0x12A4BA NVRAM MemoryConfig type: (h)
1223971 0x12AD23 NVRAM MemoryConfig type: (g)
1226019 0x12B523 NVRAM MemoryConfig type: (h)
1228172 0x12BD8C NVRAM MemoryConfig type: (g)
1230220 0x12C58C NVRAM MemoryConfig type: (h)
1232373 0x12CDF5 NVRAM MemoryConfig type: (g)
1234421 0x12D5F5 NVRAM MemoryConfig type: (h)
1236574 0x12DE5E NVRAM MemoryConfig type: (g)
1238622 0x12E65E NVRAM MemoryConfig type: (h)
1245255 0x130047 NVRAM start of the 2nd VSS stream
1245302 0x130076 NVRAM MemoryConfig type: (i)
1247350 0x130876 NVRAM MemoryConfig type: (j)
1249194 0x130FAA Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1259044 0x133624 NVRAM MemoryConfig type: (g)
1343511 0x148017 bzip2 compressed data, block size = 100k
1345189 0x1486A5 HardwareID Base_xx: 20
1345198 0x1486AE HardwareID 11-digits SSN: xxxxxxxxxxx
1345215 0x1486BF HardwareID 3-digit HWC model: xxx
1376256 0x150000 UEFI PI Firmware Volume, volume size: 2686976, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1416827 0x159E7B BIOS version: MP51.88Z.F000.B00.1904121248
1614976 0x18A480 Apple NVMe EFI Module
4063232 0x3E0000 UEFI PI Firmware Volume, volume size: 65536, header size: 1, revision: 0, GUID: E3B980A9-5FE3-48E5-929B-2798385A9027
4128768 0x3F0000 UEFI PI Firmware Volume, volume size: 65536, header size: 0, revision: 0, Apple Boot Volume, GUID: 04ADEEAD-61FF-4D31-BAB6-64F8BF901F5A
4128867 0x3F0063 BootBlock version: AAPLEFI1.88Z.0005.I00.1006041028
4194000 0x3FFED0 HardwareID MLB/LBSN: xxxxxxxxxxx, BuildDate: xxxxxxxxxxxxThere are two different and unrelated problems with SecureBoot and MP5,1:
- Crash that happens when Windows write the SecureBoot certificates and etc in the NVRAM volume when there are no microcodes loaded by the firmware. This corrupts the NVRAM entirely. Happened with several MP4,1>5,1 and MP5,1 when Apple issued MP51.0087.B00. When this happens, it's a brick.
- Multiple SecureBoot certificates + etc saved when the superseded NVRAM entries are not being removed. This is the same problem that multiple MemoryConfigs show, the NVRAM store is fragmented and nothing is being removed. Since SecureBoot certificates and etc use considerable space, each store is just 64KB, you soon can't add anything to the store. When this happens, you usually can boot, but can't change anything inside the NVRAM. Several people had this and happens with other Macs, MM6,1 people are frequently having the same MP5,1 problems.
Last edited:
Reset NVRAM only remove user-accessible entries. MemoryConfig entries, SecureBoot, NVIDIA blobs and lots of other things stored inside the NVRAM are not user accessible.
Cosmetic indeed but has been a bit of a niggle for me so I went sleuthing and came across a post by @vit9696 on another site where he posted a link to part of the code used to determine the CPU types: https://github.com/acidanthera/EfiP...f/Include/IndustryStandard/AppleSmBios.h#L142.
I took a the value for the same cpu type in that dataset, 0x402 (which appears to be the correct value for the cMP 3,1) converted this to decimal, 1026, and added this to the SMBIOS section of my config
Code:
<key>ProcessorType</key>
<integer>1026</integer>Rebooted and viola! no more cosmetic issues:
Last edited:
Tried with and without but notice no difference. Also sleep worked fine in my initial OC setup when I had no kext loaded.