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

[Gustav Holdoff]

The change was to remove the board-ID spoofing (board-ID-only spoofing is called “hybridization” in post #1 and “minimal spoofing” in OCLP), but as @tsialex mentioned, this type of spoofing is important for hardware acceleration and other key features. So the default settings mentioned in post #1 as well as those used in OCLP are indeed correct.

Recall that sleeping and waking the machine before a GPU intensive task (including running a benchmark) can improve performance to a similar degree. I wonder if toggling the spoofing level and rebooting is not having the same effect…

for experiment I tried to remove the hybridization completely from cdf config
- the macos system stopped loading - recommends contacting Apple
on the other hand, I installed two OCPL loaders: with minimal spoofing and no spoofing,
I didn’t see any performance differences (neither in benchmarks nor in blender, twinmotion or UE5)
besides the fact that ocpl 5.1 loads the system for a very long time (there are a lot of kexts and extra drivers)

 

[cdf]

for experiment I tried to remove the hybridization completely from cdf config
- the macos system stopped loading - recommends contacting Apple
on the other hand, I installed two OCPL loaders: with minimal spoofing and no spoofing,
I didn’t see any performance differences (neither in benchmarks nor in blender, twinmotion or UE5)
besides the fact that ocpl 5.1 loads the system for a very long time (there are a lot of kexts and extra drivers)

Right. The reason you can disable spoofing in OCLP and still boot into Monterey is because of the VMM patch.

 

[David403]

A significant problem I suffered trying OCLP was because of its use of the VMM patch it is not practical to use it (in System Settings: Accessibility: Voice Control) for dictation as the VMM flag impacts performance so much there are a few minutes delay between speaking something and the text appearing on the screen.

https://forums.macrumors.com/threads/macos-12-monterey-on-unsupported-macs-thread.2299557/post-31444800

I reverted back to following Post 1 of this thread to run Monterey. I'll probably have to stay with Monterey as even if OCLP enables Ventura to be installed on my Mac Pro 5,1, I do need dictation, I'll have to forego Ventura.

 

[cdf]

A significant problem I suffered trying OCLP was because of its use of the VMM patch it is not practical to use it (in System Settings: Accessibility: Voice Control) for dictation as the VMM flag impacts performance so much there are a few minutes delay between speaking something and the text appearing on the screen.

This is surprising because OCLP uses VMM in a targeted fashion (rather than a blanket approach with CPUID as in post #1) to avoid issues like this. Have you tried disabling the patch in OCLP to confirm that it is really the cause of the slow down?

 

[trifero]

So you mixed up the things properly to create a SNAFU event. OK, we will sort it out.

1. Make sure you have a Windows machine* to run a couple of things. Run Rufus on this machine (portable version will do).
2. Download a Windows ISO - you can do it with Rufus, or just head to microsoft.com and download a x64 ISO.
3. Use Rufus to create an USB installer. Should you choose Windows 11 (works beautifully), make sure to create a custom, non-secure boot and non-TPM2 installer (Rufus will ask you that).

You're done with the Windows machine, get back home.

4. Attach a spare disk (Windows will go onto it so it will be erased) to the Mac Pro.
5. Power the Mac to MacOS through OpenCore. Make sure you run the latest OC (or OCLP for that matter). Search this thread for hints regarding how to set config.plist so Windows will not mess with your NVRAM nor boot disk settings (boot policy, if I recall correctly)
6. Attach the USB you made earlier. One or two partitions will appear on desktop.
7. Restart the Mac and watch carefully for an UEFI_BOOT icon to appear in your usual Open Core disk picker. This is the USB you created. Navigate there using arrow keys on the keyboard or your mouse. Boot from it.
8. Make sure you select the right disk once you pressed Install in Windows installer.
9. Make sure you stay there while Windows installs, as it reboots a gazillion times and you need to select the Windows disk manually in OC bootpicker for the installation to progress.
10. Once you're done with the install, treat the Windows installation as a regular PC, forget about Mac things. Skip Bootcamp drivers, install whatever you need from respective manufacturers (yes, you will need to search for the sound driver).

And the MountEFI script is called from within terminal. Extract the zip to your home directory, open the Terminal and cd MountEFI followed by sudo ./mountefi.command.


* - this may and in lots of cases actually is a temporary Windows virtual machine ran inside a VirtualBox or such.

You have A LOT of patience.

 

[Bmju]

WTF is "FAT formatter"?

Something which formats (partitions as) FAT? First time I've had a chance to double-check, but Apple's 'FAT formatter' (its thing which formats FAT), as part of Disk Utility, chooses FAT16 if the volume is below a certain size.

There is more to an EFI partition than just "200 MB FAT32". Read up here: https://apple.stackexchange.com/questions/57597/how-to-fix-broken-efi-partition/58892#58892

Not really true. All that matters is that the partition should be FAT (probably it should more strictly be FAT32, I'd have to agree, but it doesn't actually make any difference if it is FAT16, at least on Macs), ideally with the ESP bit set (which you can set e.g. with Linux gparted, which determines whether it will be hidden by default in macOS, but doesn't otherwise make any difference), and also ideally with the GPT ESP file system GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B), as opposed to Microsoft Basic Data (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7), but again this doesn't make any difference as to whether a Mac will use it.

BTW OCLP might not pick FAT16.

FUD? I've never had any problems using small FAT partitions (which have been formatted by Apple's FAT formatter as FAT16) as boot partitions on Macs.

 

[David403]

This is surprising because OCLP uses VMM in a targeted fashion (rather than a blanket approach with CPUID as in post #1) to avoid issues like this. Have you tried disabling the patch in OCLP to confirm that it is really the cause of the slow down?

Thanks for the response.

I'm not familiar with the inner workings of OCLP. I don't know how to do this with OCLP.

I have asked on other threads how to and if I can disable it but have failed to get any response.

I assume I'd still need to use a version with the patch enabled to do any updating?

I'm much more comfortable using the Post 1 approach of this thread but until (if ever) AVX can be emulated Ventura on pre-Haswell macs are going to need OCLP. Can you point me in the right direction for diaabling OCLP's VMM Patch?

Thanks

 

[joevt]

Thanks for the response.

I'm not familiar with the inner workings of OCLP. I don't know how to do this with OCLP.

I have asked on other threads how to and if I can disable it but have failed to get any response.

I assume I'd still need to use a version with the patch enabled to do any updating?

I'm much more comfortable using the Post 1 approach of this thread but until (if ever) AVX can be emulated Ventura on pre-Haswell macs are going to need OCLP. Can you point me in the right direction for diaabling OCLP's VMM Patch?

Go into OCLP settings and select Minimal Spoofing?
https://dortania.github.io/OpenCore-Legacy-Patcher/TROUBLESHOOTING.html#no-graphics-acceleration
You can build the OCLP folders without installing them. Compare before and after to see how the settings affect the OpenCore config.plist.
Installing the folders can be done by just copying them to a FAT partition. If you have boot screen, then setting it as the default boot can be done using the Option key at boot to get into the Mac's Startup Manager, and using the Control key to set the selected boot option as the default and boot it.

 

[David403]

Go into OCLP settings and select Minimal Spoofing?
https://dortania.github.io/OpenCore-Legacy-Patcher/TROUBLESHOOTING.html#no-graphics-acceleration
You can build the OCLP folders without installing them. Compare before and after to see how the settings affect the OpenCore config.plist.
Installing the folders can be done by just copying them to a FAT partition. If you have boot screen, then setting it as the default boot can be done using the Option key at boot to get into the Mac's Startup Manager, and using the Control key to set the selected boot option as the default and boot it.

Thanks

It'll be a couple of days before I can get the time to do this - but will come back saying what I did to get this to work (assuming I did succeed).

Thanks again.

 

[hwojtek]

Something which formats (partitions as) FAT? First time I've had a chance to double-check, but Apple's 'FAT formatter' (its thing which formats FAT), as part of Disk Utility, chooses FAT16 if the volume is below a certain size.

You mean there is something different, or even an app to sudo diskutil eraseVolume FAT32 name diskXsY? Amazing.

Not really true. All that matters is that the partition should be FAT (probably it should more strictly be FAT32, I'd have to agree, but it doesn't actually make any difference if it is FAT16, at least on Macs)
(...)
FUD? I've never had any problems using small FAT partitions (which have been formatted by Apple's FAT formatter as FAT16) as boot partitions on Macs.

Now wait until you want to have a working dual- or triple-booting system and then try again.

 

[startergo]

As an aside, and because there appears to exist a lot of inaccurate information about this on the Internet, it needs to be stressed out that there is absolutely nothing in the UEFI specifications that actually forces the use of FAT32 for UEFI boot. On the contrary, UEFI will happily boot from ANY file system, as long as your firmware has a driver for it. As such, it is only the choice of system manufacturers, who tend to only include a driver for FAT32, that limits the default boot capabilities of UEFI, and that leads many to erroneously believe that only FAT32 can be used for UEFI boot.

However, as demonstrated in this project, it is very much possible to work around this limitation and enable any UEFI firmware to boot from non-FAT32 filesystems.

GitHub - pbatard/uefi-ntfs: UEFI:NTFS - Boot NTFS or exFAT partitions from UEFI

UEFI:NTFS - Boot NTFS or exFAT partitions from UEFI - pbatard/uefi-ntfs

github.com

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.9, section 13.3.1.1), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system.

EFI system partition - ArchWiki

wiki.archlinux.org

 

[Bmju]

You mean there is something different, or even an app to sudo diskutil eraseVolume FAT32 name diskXsY? Amazing.


Now wait until you want to have a working dual- or triple-booting system and then try again.

gparted? Amazing.

I have a multi-boot system, with Windows and several Linux. I wrote the OpenCore support for booting Linux.

EDIT: I wasn't saying, 'there is no way to format FAT32 below a certain size'. I was saying that some FAT formatters (things which format as FAT, that is 'WTF' a FAT formatter is) format as FAT16 below a certain size by default (but that it has no bad effects I have ever seen). They do (and it doesn't).

 

[hwojtek]

GitHub - pbatard/uefi-ntfs: UEFI:NTFS - Boot NTFS or exFAT partitions from UEFI

UEFI:NTFS - Boot NTFS or exFAT partitions from UEFI - pbatard/uefi-ntfs

github.com

It's nice but in fact
1. it does not allow booting from NTFS (nor any other filesystem). It still boots from FAT and loads a driver to recognize a non-FAT partition. That's the difference between "booting" (natively launching whatever code sits on an EFI partition) and "chainloading" (which happens in Open Core for example) I borrowed from @tsialex
2. we are not discussing theoretically what filesystems may be used to boot if a motherboard developer had nothing better to do and implemented various drivers into his UEFI. The specs mentioned below call for FAT12/16/32 and as far as I know Apple didn't exactly care for the specs so on an Apple machine it is FAT32. Accidentaly, yet unsurprisingly, it's a de facto standard for an EFI partition.

gparted?

This is not the "Windows, Linux, macOS, & Others on the Mac" subforum. It seemed quite obvious for me we're talking MacOS here and not brag about our bash-fu in Linux, which I BTW wholeheartedly admire.

I have a multi-boot system, with Windows and several Linux. I wrote the OpenCore support for booting Linux.

Kudos, I respect that, just as well as the fact that you may be far more literate in the matter than I am. Oh well, I may actually even be a victim of your proceedings (openlinuxboot.efi does no longer work for me on 0.8.5), however: how does your OC and all the OSes work with the EFI partition formatted as a plain FAT16, without the ESP FS GUID? I find Windows and Ubuntu a little disoriented in such case about how they were actually launched and wrecking havoc on random EFI partitions on the physical disks trying to restore them to (in their opinion) "working" order during big updates or kernel upgrades.

 

[cdf]

Can you point me in the right direction for diaabling OCLP's VMM Patch?

Sure. Just look for "kern.hv_vmm_present" in the config and you'll find the patches. It is then just a matter of setting Enabled=false for each of them.

I assume I'd still need to use a version with the patch enabled to do any updating?

Correct. Alternatively, you could just toggle the flag as described in post #1.

 

[Bmju]

It's nice but in fact
1. it does not _allow booting_ from NTFS (or any other filesystem). It still boots from FAT and loads a driver to recognize a non-FAT partition. That's the difference between "booting" (natively launching whatever code sits on an EFI partition) and "chainloading" (which happens in Open Core for example).

That is false. That is a firmware driver. So yes, it could be loaded from a filesystem which the firmware natively supports, as you are suggesting. But it could also perfectly well be bundled into the firmware, in which case the firmware would then also natively support NTFS (and literally wouldn't ever need to see or read from a FAT partition, in order to fully boot).

2. we are not discussing theoretically what filesystems may be available if a motherboard developer had nothing better to do and implemented various drivers into his UEFI. The specs mentioned below call for FAT12/16/32 and as far as I know Apple didn't exactly care for the specs so on an Apple machine it is FAT32. Accidentaly, yet unsurprisingly, it's a de facto standard for an EFI partition.

Well, this is what we are disagreeing about. But I agree with @startergo who has found a ref that FAT16 should be supported; and I also agree with his claim that UEFI BIOS in general do not care what FS something is on, as long as they have a loaded driver for it. More specifically, Macs do support FAT16 as well as FAT32 in this respect.

This is not the "Windows, Linux, macOS, & Others on the Mac" subforum. It seemed quite obvious for me we're talking MacOS here and not brag about our bash-fu in Linux, which I BTW wholeheartedly admire.

I think you will find there will be many references in this thread to things you can do with Linux, that help with setting up (unsupported) macOS, whether by fully installing it, or even by just using it off a live boot USB. I find it extremely useful to have a small-ish (say 50GB) Linux install with gparted accessible on my machines - that OS can always be booted without OC, if need be, and gparted is much more capable than Disk Utility (except for doing container management, resizing, etc. of an APFS partition, of course - that should be done in macOS).

Kudos, I respect that

Thank you.

I may actually even be a victim of your proceedings (openlinuxboot.efi does no longer work for me on 0.8.5)

Feel free to open a ticket on the bugtracker.

however: how does your OC and all the OSes work with the EFI partition formatted as a plain FAT16, without the ESP FS GUID? I find Windows and Ubuntu a little disoriented in such case about how they were actually launched and wrecking havoc on random EFI partitions on the physical disks trying to restore them to (in their opinion) "working" order during big updates or kernel upgrades.

I do agree that it is far from easy to keep control of the boot partition, when you have several different OSes competing. In fact, that is one reason why I like to add some small FAT (FAT16 or FAT32!) partitions at the end of my HDD. 20MB only is sufficient to store the Linux boot files. 50MB only is sufficient to store the Windows boot files. I find that if you separate them out, it makes management of all this simpler. (That's just my preference, I'm not particularly planning to make a write-up on it, I'm afraid - ymmv!)

All I was saying (trying to say) is that despite all those (agreed) problems, I personally have not ever seen any such problem which is due to FAT16 over FAT32.

 

[cdf]

You mean there is something different, or even an app to sudo diskutil eraseVolume FAT32 name diskXsY?

I prefer to use gdisk in macOS to recreate the "Apple factory" 300 MiB (vs the "default" 200 MiB) EFI partitions on my SSDs.

 

[Macschrauber]

I prefer to use gdisk in macOS to recreate the "Apple factory" 300 MiB (vs the "default" 200 MiB) EFI partitions on my SSDs.

Can you give a quick failsave howto?

As I use RefindPlus along several instances of OpenCore 200 MB is sometimes a little tight.

 

[Darmok N Jalad]

I have managed to get OpenCore working in a default setup, but every time I try to build out the config.plist and add the kexts, I can't get the system to boot, much less get Monterey or Big Sur installed. I have a single CPU 5,1, booting from an NVMe with an RX 480 8GB installed. I'm guessing I got my config.plist coding screwed up, but I've failed 2x now.

Fortunately, I have my OG video card so I boot to a backup SSD and restore.

 

[HDMC]

Is there a solution in the meantime for my Mac Pro 3,1 and Bluetooth ?
No Bluetooth on Monterey 12.6.1 and BCM_4350C2 !
What is strange is that I have a Dual boot system with Catalina and Monterey and now Bluetooth isn´t working on Catalina also. Could it be that Opencore (0.4.11) is the problem here ?
I thought Catalina would be independent from Opencore ?!

Thanks !

 

[cdf]

Can you give a quick failsave howto?

I'll provide a mini-guide later. In the meantime, here's a quick description of the process: The idea is to use gdisk to manually create a GPT with a "customer partition" (this is the term Apple uses) and an EFI partition. The EFI partition is made into a proper volume by using asr to apply to it a FAT32 image created with hdiutil. The customer partition is then formatted as desired using Disk Utility.

 

[cdf]

I have managed to get OpenCore working in a default setup, but every time I try to build out the config.plist and add the kexts, I can't get the system to boot, much less get Monterey or Big Sur installed. I have a single CPU 5,1, booting from an NVMe with an RX 480 8GB installed. I'm guessing I got my config.plist coding screwed up, but I've failed 2x now.

If you post your config, we should be able to tell you what’s wrong.

 

[Bmju]

I prefer to use gdisk in macOS to recreate the "Apple factory" 300 MiB (vs the "default" 200 MiB) EFI partitions on my SSDs.

Yes. As mentioned (at too much length, probably!) I've actually found that the requirements for a viable ESP are much less exacting than that in reality. Which, surprised me too, at first. But equally, for normal everyday use, it is no doubt better to have as standard as possible a setup to rule out any possible problems.

 

[cdf]

As promised, I'm including here some instructions for creating a GPT disk with a 300 MiB EFI partition. As mentioned above, it is possible to create the partitions using gdisk and to do the formatting using hdiutil and asr, but for the purpose of these instructions, it is simpler to use gpt and diskutil (both already included with macOS).

If deemed useful enough, I may move these instructions to post #1.

Creating a GPT disk with a 300 MiB EFI partition

➊ Identify the desired disk by entering the following command in Terminal:

diskutil list

The identifier will be something like "diskA".

➋ Verify the block size of the disk:

diskutil info diskA

Look for "Device Block Size". These instructions apply to a disk with a block size of 512 bytes. For other block sizes, some of the steps will need to be modified.

⚠️ Proceeding with the following steps will permanently erase all data stored on the disk!

➌ Free up the disk:

diskutil eraseDisk free "free space" diskA

➍ Create a new GPT:

sudo gpt destroy diskA

sudo gpt create diskA

➎ Prepare the EFI partition:

sudo gpt add -b 48 -i 1 -s 614400 -t efi diskA

Explanation:

• 48 is the starting block corresponding to the same alignment on modern Apple devices with block sizes of 4096 bytes
• 614400 blocks = (300 MiB * 1048576 bytes/MiB) / (512 bytes/block)

➏ Format the EFI partition:

diskutil eraseVolume fat32 "EFI" diskAs1

➐ Finalize the EFI partition:

diskutil umountDisk diskA

sudo gpt remove -i 1 diskA

sudo gpt add -b 48 -i 1 -s 614400 -t efi diskA

sudo gpt label -i 1 -l "EFI System Partition" diskA

➑ Create the "customer" partition:

sudo gpt add -b 614448 -i 2 -t hfs diskA

sudo gpt label -i 2 -l "Customer" diskA

➒ Finally, format the "customer" partition:

diskutil eraseVolume apfs "Macintosh HD" diskAs2

The "customer" partition is formatted as APFS. Of course, Disk Utility can now be used to configure the disk as usual. Provided that the entire disk is not erased, the newly created 300 MiB EFI partition will remain.

 

[Darmok N Jalad]

If you post your config, we should be able to tell you what’s wrong.

I may take you up on that, but I’ve just downloaded a better code editor than TextEdit and am trying to fix the lines after checking my config through the terminal command. Might end up getting frustrated and posting what I got, but thought I’d try to do it myself and learn something first!

 

[Darmok N Jalad]

Figured out my errors and got my config.plist working. Had an extra array end and start in there when applying patches from two different sections on the OP setup.