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

[G4fanboy]

I have a Mac Pro 1.1 upgraded to 2.1 with nVidia PC graphic cards (210 and 9400) and I wonder if OpenCore could bring me the boot screen. In my setup I have Lion only (I plan on upgrade to El Capitan soon but I still have only 8 Gig of RAM occupying the 8 memory slots).

In the requirements it mentions only Mac Pro 5.1 and up for catalina. Did anyone ported it to be a bootloader for these old systems?

 

[KingCachapa]

EDITED - explained better on post 2329 below

 

[Ludacrisvp]

I have a Mac Pro 1.1 upgraded to 2.1 with nVidia PC graphic cards (210 and 9400) and I wonder if OpenCore could bring me the boot screen. In my setup I have Lion only (I plan on upgrade to El Capitan soon but I still have only 8 Gig of RAM occupying the 8 memory slots).

In the requirements it mentions only Mac Pro 5.1 and up for catalina. Did anyone ported it to be a bootloader for these old systems?

I’m not aware of anyone using OC on a 1,1/2,1. I use it on my 3,1 though. you won’t get a boot screen with either of those GPUs though in any case as they don’t have a GOP style rom.

 

[KingCachapa]

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

1. Working macOS Mojave 10.14.6 on its own internal SATA drive installed in Bay 1.
2. Separate internal SATA drive for Windows. Mine was in Bay 4.
3. Have no other drives attached.
4. ROMTool from @dosdude1 (password 'rom').
5. Attached OpenCore EFI.
6. Windows 10 installer on a USB stick.
7. Time to burn and willingness to suffer.

Procedure

1. Power on and clear your NVRAM by holding down CMD-ALT-P-R over the chime.
2. Disable SIP by booting into Mojave Recovery (CMD-R) and using the Terminal to issue csrutil disable
3. Allow Mojave to boot and use ROMTool to take a backup of your BootROM. Keep it safe.
4. Load the resulting .bin file into TextEdit. Search contents for the word 'Secure'.
5. If you have any matching results STOP. Your BootROM already has problems, it doesn't need more.
6. Format the drive intended for Windows to Mac OS Extended (Journaled) with GUID Partition Map.
7. Note the Device number for that Windows drive in Disk Utility. We'll use disk2 in this example.
   View attachment 895214
8. Fire up Terminal and issue: sudo diskutil mount /dev/disk2s1
9. 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.
10. Go back to Terminal and issue: sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/BOOT/BOOTx64.efi --verbose
11. Stick the Windows installer USB into a socket and power off.
12. Pull the Mojave drive from Bay 1 and power up.
13. You should see the OpenCore Boot Menu. Pick your Windows installer.
14. When asked about the drive to install to, delete all the partitions and let Windows do its thing.
15. At around 29% the Windows installer will reboot your machine. Power it off when you hear the chime.
16. Insert your Mojave drive to Bay 1.
17. Boot to Mojave Recovery (CMD-R) and use Startup Disk from the Apple menu to choose macOS Mojave. Reboot into Mojave.
18. 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.
19. Fire up Terminal and issue: sudo diskutil mount /dev/disk2s2
20. 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.
21. Delete the Boot directory.
22. Copy the BOOT and OC directories from the OpenCore EFI directory you decompressed from the attached .zip file earlier.
23. Power off your machine and pull the Mojave drive from Bay 1.
24. Power on your machine and clear your NVRAM by holding down CMD-ALT-P-R over the chime.
25. 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.
26. 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.
27. You should now have a working copy of Windows in UEFI mode protected by OpenCore.
28. Install all drivers you need under Windows, probably using Brigadier to fetch the MacPro5,1 and iMacPro1,1 bundles.
29. Power off and insert your Mojave drive into Bay 1.
30. Power on. You should see Windows and Mojave appear as boot options on the OpenCore Boot Menu.
31. Boot to Mojave and use ROMTool to take another backup of your BootROM.
32. Load the resulting .bin file into TextEdit. Search contents for the word 'Secure' again. Fingers crossed you shouldn't find anything.

The final step is to swear profusely when, for no apparent reason, the boot spinner won't appear when firing up Windows - most likely after Windows has applied a mandatory patch in the background which you weren't expecting.

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.

Hello (=I need some help please. @roobarb! @h9826790
I am continuing following this guide, with the only differences are that I'm using the latest OC HCL package found here instead of the one attached to the post in Feb., and my destination drive is a 500GB nVME (connected via PCIe).
--
TLDR: stuck installing windows after first reboot, can't see or launch the internal drive to continue installation.
--

- I have Vega56 installed (from MVC), and the USB stick was created in Windows 10 with their media creation tool.

I have made it so far with no corruption (checked ROM dump), however when I got to Step 19 / 20, this is where I'm at:

1- The proper EFI volume is mounted, however instead of "EFI" now it is named "NO NAME". Considering that the importance of naming and structure is stressed in a few posts, I decided to rename it to match the guide, from "NO NAME" back to "EFI", with the "EFI" folder at its root and so on.

2- I made it finally to Step 24, however even though it *looks* like OC boot picker loads, the screen is the normal OC grey background with no Volumes to pick from, and it stays there indefinitely (at this point according to the guide, the only Drive in the system is the Windows destination, which should show up to continue Winstallation).
Note: I also removed the Windows Installation USB before this, because I have no way to tell the difference from "Windows" and "Windows" if they were both to show up.

3- As a precaution I shut down, plugged back in Mojave HD (with OC) in Bay 1. Now OC boot picker loads again, and I see MacHD, Recovery, & Windows volumes.

4- Out of curiosity I tried Windows volume, but it just brought me back instantly to OC boot picker, and the Volume stayed but the name "Windows" went away. Weird. I assumed this was no good news, so I went back to Mojave and wiped the Windows drive for safety, and checked ROM and I am still safe with no problems, and no matches for "Secure" in the bin.

So now that I've outlined this situation, I'm wondering if anyone has any insight, since I'm sure there's been developments since February, but I'm having trouble finding updates pertaining to this particular method, and the things I've run into.

Thank you in advance! Excited to get this going.
--

Troubleshooting updates:

- I also tried running this without renaming the EFI volume that comes up as "NO NAME". Same result.
- A second attempt with the "EFI" rename still only shows the USB installer and not the started up winstallation. It only shows up if I plug in the Mojave HD in bay 1, and even then the best I've gotten is the grey background with no loading anything.
- I also tried blessing the windows EFI that is recreated at the end of the guide, just in case. No better result.
- Also tried with Paragon ntfs for mac installed (to ensure my installer wasnt trying to mbr when deleting all partitions)

 

[TECK]

Ultimately each person will have to decide for them-self what tools and resources appropriate for them to use.

I agree, but the only issue I have with pre-made tools is the lack of understanding what's under the hood, like you say. Is probably the most important aspect. Acidanthera provides a very comprehensive manual for configuring OpenCore. To get the most out of OpenCore, it is important to read the manual and understand its settings.

My gfxinfo path looks a little different to the example. Does this look right?

You need to use your detected device path. You can use gfxutil or Hackintool to extract the device path of your video card. With gfxutil, this is how RX580 looks like on my Mac:

./gfxutil -f display
05:00.0 1002:67df /PCI0@0/IOU0@3/GFX0@0 = PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)

If you wonder how I got the IOName "display", run ioreg:

$ ioreg -b

$ ioreg -rn GFX0 | grep IOName
  |   "IOName" = "display"

You can also use Hackintool. Right click to copy device path:

 

[startergo]

Alternative to RadeonBoost.kext is Device properties injection:
Edited:
based on https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/post-28498419

<key>PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)</key>
            <dict>
                <key>@0,name</key>
                <data>
                QVRZLE9yaW5vY28=
                </data>
                <key>ATY,EFIVersion</key>
                <data>
                MDEuMDEuMTgz
                </data>
                <key>CFG,CFG_FB_LIMIT</key>
                <data>
                Bg==
                </data>
                <key>CFG,CFG_PTPL2_TBL</key>
                <data>
                ggAAAHwAAAB2AAAAcAAAAGoAAABkAAAAXgAAAFgAAABS
                AAAATAAAAEYAAABAAAAAOgAAADQAAAAuAAAAKAAAAA==
                </data>
                <key>PP,PP_WorkLoadPolicyMask</key>
                <data>
                IA==
                </data>
                <key>agdpmod</key>
                <data>
                cGlrZXJhAA==
                </data>
                <key>model</key>
                <data>
                QU1EIFJhZGVvbiBSWCA1ODA=
                </data>
                <key>rebuild-device-tree</key>
                <data>
                AA==
                </data>
                <key>shikigva</key>
                <data>
                kA==
                </data>
            </dict>

If the property exists you need to delete it:

<dict>
    <key>Delete</key>
    <dict>
        <key>PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)</key>
        <array>
            <string>ATY,EFIVersion</string>
        </array>
    </dict>
</dict>

You need to replace the path to match your path. You can copy and paste this in ProperTree and it will convert it automatically:

Download the dummy kext dAGPM (made by @toleda) that will help with power management for the GPU and place it into /Volumes/EFI /EFI/OC/Kexts

 

[donvito4ever]

Yes. Try adding

<key>bluetoothHostControllerSwitchBehavior</key>
<string>always</string>

to 7C436110-AB2A-4BBB-A880-FE41995C9F82.

This will be ok?

<key>NVRAM</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <dict>
                <key>boot-args</key>
                <string>agdpmod=pikera shikigva=80 mbasd=1 -wegtree -no_compat_check no32exec=0</string>
                <key>bluetoothHostControllerSwitchBehavior</key>
                <string>always</string>
            </dict>
        </dict>
        <key>Block</key>
        <dict>
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <array>
                <string>boot-args</string>
            </array>
        </dict>
        <key>LegacyEnable</key>
        <false/>
        <key>LegacySchema</key>
        <dict/>
    </dict>

 

[vit9696]

@startergo that's not correct. When doing DP injection you need to write CFG,CFG_SOMETHING and PP,PP_SOMETHING, since all these are handled by WhateverGreen. Also, most of these are not needed as explained by WEG FAQ:

WhateverGreen/Manual/FAQ.Radeon.en.md at master · acidanthera/WhateverGreen

Various patches necessary for certain ATI/AMD/Intel/Nvidia GPUs - acidanthera/WhateverGreen

github.com

(See the last two entries).

 

[h9826790]

This will be ok?

<key>NVRAM</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <dict>
                <key>boot-args</key>
                <string>agdpmod=pikera shikigva=80 mbasd=1 -wegtree -no_compat_check no32exec=0</string>
                <key>bluetoothHostControllerSwitchBehavior</key>
                <string>always</string>
            </dict>
        </dict>
        <key>Block</key>
        <dict>
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <array>
                <string>boot-args</string>
            </array>
        </dict>
        <key>LegacyEnable</key>
        <false/>
        <key>LegacySchema</key>
        <dict/>
    </dict>

I think you better block it as well (if you want to overwrite the existing variable)

e.g.

<key>NVRAM</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <dict>
                <key>boot-args</key>
                <string>agdpmod=pikera shikigva=80 mbasd=1 -wegtree -no_compat_check no32exec=0</string>
                <key>bluetoothHostControllerSwitchBehavior</key>
                <string>always</string>
            </dict>
        </dict>
        <key>Block</key>
        <dict>
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <array>
                <string>boot-args</string>
                <string>bluetoothHostControllerSwitchBehavior</string>
            </array>
        </dict>
        <key>LegacyEnable</key>
        <false/>
        <key>LegacySchema</key>
        <dict/>
    </dict>

 

[cdf]

If you wonder how I got the IOName "display", run ioreg:

$ ioreg -b

$ ioreg -rn GFX0 | grep IOName
  |   "IOName" = "display"

If the device tree has not yet been renamed by WEG, then GFX0 would be PXS1.

 

[cdf]

So now that I've outlined this situation, I'm wondering if anyone has any insight, since I'm sure there's been developments since February, but I'm having trouble finding updates pertaining to this particular method, and the things I've run into.

I plan on documenting a similar method (which also does not involve a VitualBox detour).

There is, however, an existing issue with all EFI installations: Windows will occasionally hang at the loading screen (logo with no spinner). The issue affects some users more than others. Although it appeared to be resolved with the built-in picker, the issue has arisen again with OpenCanopy...

 

[vit9696]

@cdf, try ExitBootServicesDelay quirk. Perhaps it is related to an old-standing bug with the timers on some older boards. Not all events complete at a certain time and thus boot failures happen with all operating systems. In the past I had it on macOS, but I would expect Windows to be affected as well.

 

[startergo]

@vit9696
Reading :

VirtualSMC/Docs/FAQ.md at master · acidanthera/VirtualSMC

SMC emulator layer. Contribute to acidanthera/VirtualSMC development by creating an account on GitHub.

github.com

"On older Macs it can be used to upgrade SMC generation with more features."
Can it be used to load the SMC from cMP5,1 on a cMP4,1 board (upgraded to cMP5,1). When cMP4,1 is firmware upgraded the only difference is that in the SMC as it cannot be upgraded. Therefore mix/match board from converted cMP4,1-->cMP5,1 with CPU tray from cMP5,1 is not possible (full blast of the fans)

 

[vit9696]

It can be used to let macOS boot if/when it drops older SMC generation, but I do not believe it can help you with the fans, as Mac fan control system is proprietary, and VirtualSMC plugins have no support for it.

 

[startergo]

It can be used to let macOS boot if/when it drops older SMC generation, but I do not believe it can help you with the fans, as Mac fan control system is proprietary, and VirtualSMC plugins have no support for it.

We noticed that Macs Fan Control was using fans of iMacPro or whatever the SMBIOS is spoofed to. That was with full spoofing. With only board-id spoofing it keeps the database of the original SMC.

 

[TECK]

Although it appeared to be resolved with the built-in picker, the issue has arisen again with OpenCanopy...

I installed Windows with VirtualBox and EFI enabled. I deleted all partitions, letting Windows create its own NTFS partitions. With builtin picker I have zero issues. With OpenCanopy, I experience boot freezes all the time. I usually login to Windows 5-6 times/week, for MeGUI usage. Is basically, the only reason I use Windows.

 

[startergo]

I installed Windows with VirtualBox and EFI enabled. I deleted all partitions, letting Windows create its own NTFS partitions. With builtin picker I have zero issues. With OpenCanopy, I experience boot freezes all the time. I usually login to Windows 5-6 times/week, for MeGUI usage. Is basically, the only reason I use Windows.

Try gdisk:

sudo gdisk /dev/diskX

and then p to show the partition table. If there is an error in the partition table it will automatically correct it.

 

[cdf]

I installed Windows with VirtualBox and EFI enabled. I deleted all partitions, letting Windows create its own NTFS partitions. With builtin picker I have zero issues. With OpenCanopy, I experience boot freezes all the time. I usually login to Windows 5-6 times/week, for MeGUI usage. Is basically, the only reason I use Windows.

Try the ExitBootServicesDelay quirk as suggested by @vit9696. Set it to something ≥ 3000 (3 seconds) and see if that helps. In my case, the issue is so sporadic, that I couldn't yet confirm the fix.

 

[doccelo]

I have a Mac Pro 1.1 upgraded to 2.1 with nVidia PC graphic cards (210 and 9400) and I wonder if OpenCore could bring me the boot screen. In my setup I have Lion only (I plan on upgrade to El Capitan soon but I still have only 8 Gig of RAM occupying the 8 memory slots).

In the requirements it mentions only Mac Pro 5.1 and up for catalina. Did anyone ported it to be a bootloader for these old systems?

I would also like to know as I'm still running an upgraded Mac Pro 1,1 (2,1) running El Capitan. Is it possible to run Capitan on a 1,1 using OC?

 

[Dayo]

Is it possible to run Capitan on a 1,1 using OC?

I don't recollect any one trying and reporting on this ... Why not have a go?
You could try the Refind based method I put up for 3,1 as a jump off point.

 

[vit9696]

I think MacPro2,1 and earlier have 32-bit EFI, which makes it very hard and less practical.

While you technically can compile and run 32-bit OpenCore on them, this will only let you run 10.8 or something like that, and I must say this is not tested at all. We have some distant plans to test 32-bit OpenCore on a regular basis, but that will most likely only target virtual machines and older Pentium machines to support older macOS like 10.4~10.6, which can sometimes be still used for development.

An alternative route is to try booting legacy variant of OpenCore (via DuetPkg). I don't know whether it works on Macs either, but probably should. This way you should be able to run new versions of macOS as long as you have enough compatible CPU/kexts, but you will not have working NVRAM for example.

To properly support MacPro2,1 and alike one will need to write an NVRAM driver and build something like a hybrid Duet-based firmware to replace the 32-bit services. I do not think we will do it as we do not have the hardware and are not really interested in it. We can accept such contributions and provide some very basic help on how to build such stuff if absolutely necessary.

 

[flabelline]

Is there a mean to change entries in the Boot Picker menu?

I have 3 disks, with partitions named Catalina, Mojave and Windows (SATA SSD).
Catalina and Windows are correctly displayed, but the Mojave one appear with the name of the Catalina device: "OWC Mercury EXTREME Pro 6G SSD Media", and not the container "Mojave" (with is on the device named "Samsung SSD 850 EVO 500GB Media").
Did I do something wrong with APFS?

Is it possible to rename entries of the menu?

Thanks.

 

[Pascal Baillargeau]

Is there a mean to change entries in the Boot Picker menu?

I have 3 disks, with partitions named Catalina, Mojave and Windows (SATA SSD).
Catalina and Windows are correctly displayed, but the Mojave one appear with the name of the Catalina device: "OWC Mercury EXTREME Pro 6G SSD Media", and not the container "Mojave" (with is on the device named "Samsung SSD 850 EVO 500GB Media").
Did I do something wrong with APFS?

Is it possible to rename entries of the menu?

Thanks.

I saw it's possible but you should consult an OC thread.

 

[startergo]

Is there a mean to change entries in the Boot Picker menu?

I have 3 disks, with partitions named Catalina, Mojave and Windows (SATA SSD).
Catalina and Windows are correctly displayed, but the Mojave one appear with the name of the Catalina device: "OWC Mercury EXTREME Pro 6G SSD Media", and not the container "Mojave" (with is on the device named "Samsung SSD 850 EVO 500GB Media").
Did I do something wrong with APFS?

Is it possible to rename entries of the menu?

Thanks.

it is possible, but with APFS you have to do it in two places: on the main and the preboot partition. You have to mount the Preboot, show hidden files Press "⇧ Shift+⌘ Command+.". Navigate to /System/Library/CoreServices on both partitions and edit .disk_label.contentDetails

You may need to mount the system folder writable sudo mount -uw / (SIP must be disabled). Enter root:

sudo -s
nano /System/Library/CoreServices/.disk_label.contentDetails

 

[KingCachapa]

@cdf, try ExitBootServicesDelay quirk. Perhaps it is related to an old-standing bug with the timers on some older boards. Not all events complete at a certain time and thus boot failures happen with all operating systems. In the past I had it on macOS, but I would expect Windows to be affected as well.

@cdf @h9826790 @vit9696

I have updated the config file with ExitBootServicesDelay set to 3, on the OC that is placed on the windows destination drive. I still can't continue installation after 1st reboot. Sometimes it shows no Windows drive. Sometimes it does, but when it does it does not launch, it just goes back to OC Boot Picker.
(this is after first reboot of windows install, where we intervene in order to re install OC and continue installation upon flashed NVRAM reboot).

- Concern: When I mount the Windows drive EFI volume, it comes up as "NO NAME" - although the expected Boot and Microsoft folders are there. I'm not sure if this makes a difference and if Windows takes care of this, or if I should be renaming it back to EFI before proceeding and adding OC?

- Question: should I re-bless the windows EFI volume before proceeding? It's not part of @roobarb! 's guide I mentioned earlier, but just asking just in case, to learn why or why not.