MP 1,1-5,1 Activate AMD hardware acceleration

[joevt]

I’m running Windows 11 on my 5,1 and the version I have (22H2) hasn’t been supported in a while. Windows doesn’t offer me to update/upgrade to a newer version so apparently I need to update with a downloaded installer. Is there any risk here to mess up my Open Core (Martin Lo) installation by updating Windows? Is there a ”proper” way to upgrade for computers running Open Core?

Just backup your EFI folder containing OpenCore. After updating Windows, verify that the EFI folder is intact.
You can run my dumpvols.sh script before and after updating Windows to see if any partitions change. Likely you won't see any significant changes.

 

[5ibl1]

Just backup your EFI folder containing Open Core. After updating Windows, verify that the EFI folder is intact.
You can run my dumpvols.sh script before and after updating Windows to see if any partitions change. Likely you won't see any significant changes.

Thanks, I’ll try that. My EFI folder is actually installed on a different drive (not just partition) than Windows. Does this mean the chance of changing anything could be even smaller?

 

[joevt]

Thanks, I’ll try that. My EFI folder is actually installed on a different drive (not just partition) than Windows. Does this mean the chance of changing anything could be even smaller?

Probably. Windows install likely only affects the EFI of the disk that Windows is installed to (if it's installing EFI Windows).

Usually a EFI folder has a default EFI boot loader named BOOTx64.efi which is a copy of a boot loader in another folder. This file may get replaced by other OS installers. In the case of OpenCore, BOOTx64.efi is not a copy of OC/OpenCore.efi or anything else in the OC folder.

 

[5ibl1]

Probably. Windows install likely only affects the EFI of the disk that Windows is installed to (if it's installing EFI Windows).

Usually a EFI folder has a default EFI boot loader named BOOTx64.efi which is a copy of a boot loader in another folder. This file may get replaced by other OS installers. In the case of OpenCore, BOOTx64.efi is not a copy of OC/OpenCore.efi or anything else in the OC folder.

Ok, I'm going to update my OpenCore to a newer version before updating Windows and I'm seeing something I haven't seen before. I'm trying to mount the EFI and I get a warning:

"contains a bootloader that can harm the NVRAM volume of this Mac's bootrom if started without OpenCore or RefindPlus protection.

It should be checked regularly, especially after Windows updates and repairs.

This Uefi Windows can be started only by OpenCore or RefindPlus after this modification and can't harm the bootrom anymore.

Want to do this now?"

The options are "deactivate bootx64.efi" and "OK".

I'm really out of my element here with all of this, so I don't even know which one to click and what either option does. Any further advice would be very helpful!

 

[joevt]

I'm trying to mount the EFI and I get a warning:

"contains a bootloader that can harm the NVRAM volume of this Mac's bootrom if started without OpenCore or RefindPlus protection.

It should be checked regularly, especially after Windows updates and repairs.

This Uefi Windows can be started only by OpenCore or RefindPlus after this modification and can't harm the bootrom anymore.

Want to do this now?"

The options are "deactivate bootx64.efi" and "OK".

How are you mounting the EFI?

What is giving the warning message?

Your current version of Windows boots using EFI instead of legacy/BIOS?

The EFI you are mounting belongs to Windows? What folders exist next to the EFI folder?

Is the EFI for OpenCore on a different disk? There should be an OC folder next to the EFI folder.

This thread discusses the MacPro5,1 boot rom, and how Window EFI might affect it:
https://forums.macrumors.com/threads/macpro5-1-bootrom-thread-144-0-0-0-0.2132317/

There's info in this thread which also contains info about Macschrauber's Rom Dump tool for checking the NVRAM volume:
https://forums.macrumors.com/thread...our-on-4-1-5-1-machines.2333460/post-32055801

 

[Macschrauber]

I added the warning to the ESP mounting script. Martin uses it in his package.

 

[5ibl1]

I added the warning to the ESP mounting script. Martin uses it in his package.

So is this a general warning that pops up every time the script mounts the ESP? Or does some type of installation trigger the warning? Also, what does it do if I hit ”deactivate bootx64” or ”ok”?

 

[5ibl1]

How are you mounting the EFI?

What is giving the warning message?

Your current version of Windows boots using EFI instead of legacy/BIOS?

The EFI you are mounting belongs to Windows? What folders exist next to the EFI folder?

Is the EFI for OpenCore on a different disk? There should be an OC folder next to the EFI folder.

This thread discusses the MacPro5,1 boot rom, and how Window EFI might affect it:
https://forums.macrumors.com/threads/macpro5-1-bootrom-thread-144-0-0-0-0.2132317/

There's info in this thread which also contains info about Macschrauber's Rom Dump tool for checking the NVRAM volume:
https://forums.macrumors.com/thread...our-on-4-1-5-1-machines.2333460/post-32055801

I’m trying to mount the OC EFI with the script included in the latest Martin Lo package. My OC EFI is installed in a partition on the same disk as Mac OS. Windows is installed on a different disk as I mentioned before.

 

[joevt]

I’m trying to mount the OC EFI with the script included in the latest Martin Lo package. My OC EFI is installed in a partition on the same disk as Mac OS. Windows is installed on a different disk as I mentioned before.

You didn't describe the folders that are adjacent to the EFI folder that is on the EFI volume.

I added the warning to the ESP mounting script. Martin uses it in his package.

The ESP mounting script shouldn't give the warning if you're opening an EFI folder that doesn't boot Windows. What does the script check to know the difference between a Windows EFI and an OC EFI?

 

[Macschrauber]

You didn't describe the folders that are adjacent to the EFI folder that is on the EFI volume.


The ESP mounting script shouldn't give the warning if you're opening an EFI folder that doesn't boot Windows. What does the script check to know the difference between a Windows EFI and an OC EFI?

I distinguish Bootloaders by typical data points, naming, config files, etc.

Simple caveman logic, it checks if /EFI/Boot/*.efi is a Windows bootloader by patterns. If it flags it, being a Windows bootloader, it gives a warning, to take care about it, when on Mac Pro 4,1/5,1.

Plus the option to deactivate it by renaming it to .efioff. OpenCore does not need that .efi to boot Uefi Windows, so it can't be run from a native firmware start.

This is better than nothing, I know Windows repairs, installs and updates can re-write it. But that's what we can do with little effort.

I have another script in my package what can be run at every MacOs start and crawls thru all ESPs. Including checking NVRAM for Windows certificates by dumping it, if s.i.p. settings allows it, as it needs DirectHW.kext (Check ESPs for MS certificates, included in the Dumper package https://github.com/Macschrauber/Macschrauber-s-Rom-Dump/blob/main/ESP_tools.md).

 

[Macschrauber]

So is this a general warning that pops up every time the script mounts the ESP? Or does some type of installation trigger the warning? Also, what does it do if I hit ”deactivate bootx64” or ”ok”?

It is a warning, when it finds a Windows ESP. Deactivate bootx64 deactivates bootx64.efi by renaming it to bootx64.efioff. So that is reversible, if needed.

Booting Windows ESPs, will sign the NVRAM with Windows certificates, what can mess up the NVRAM. Even booting a Windows USB installer - and even booting a Windows ESP with no Windows OS on a disk, will sign it.

This can't be undone without re-flashing a firmware backup. Usually you have none.

This was the root purpose of doing the Dumper back in the day, making firmware backups. It escalated, becoming a firmware analyse and flashing tool, but thats another story.

 

[ianshepherd]

Update: I found the solution, which was to enable BlueToolFixup.kext in the config file, but *not* Bluetooth-Spoof.kext

***

Hi All,

I've just successfully installed Monterey on my Mac Pro 5,1 and as expected it's broken Bluetooth. I'd hoped to use a USB dongle, but I've tried both an Asus BT400 and Sonnet (CSR8510 A10) and neither of them work.

Is there something I can do to get these working, or a product that's known to work with this setup in 2025 ? I'm currently running 12.7.4

Thanks for any suggestions !

 

[naniscola]

Hi there,
I browsed the forum, but now my wisdom came to an end. Here is the story

I was on Catalina on my cMP 5.1, did an Open Core EFI update via Clover (mounted partition, updated BOOT and OC folders via drag and drop to version 1.0.1).
Then I started the installation of Big Sur, what I downloaded via Open Legacy Patcher.
So good so far...
The installation started at first, but got stuck somewhere. Black screen!
After a hard reset the installation continued. Black again!
No hard reset could reanimate the system, but a PRAM did the job, so I could at last boot into my good old Mojave on another partition.
The NVME drive with my old data and a maybe working Big Sur did only showed up as an external drive in the finder.
Thats why I did the innie trick with the manipulated kexts. Successfully!
Unfortunately the NVME does not show up under bootable volumes in the system.
I had to insert the new BOOT and OC folder again into the NVME EFI, because the changes I have done initially were gone.
When I tried to reinstall Big Sur from my First Aid Mojave system, the installer requires Catalina, what I have overwritten to install Big Sur.

There is no boot picker showing up, where I may choose Big Sur.
I can enter the recovery mode, but I thing there is no more Catalina to recover from.

Any ideas to get out of the mud?

 

[naniscola]

Update: success! After numerous attempts to boot the installer USB, that gave me a black screen, I inserted my old graphics card - and voila! Only to learn after the installation of Big Sur, that the Google Drive desktop app isn't supported anymore since Sep 2025... So I have to go for Monterey.
What I learned additionally, that the newest OCLP isn't appropriate for all MacOS installer. So be careful!