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

[aconu]

^I certainly don't truly know what might be wrong with your current OC setup, but, if I were you, I'd use the generic safe config.plist provided by @cdf (see post #1) and see if that solves the particular graphics problem you are experiencing. If it does, I would then customize config.plist and fine-tune it to your particular hardware, et cetera. If @cdf's config.plist doesn't solve your problem at all, chances are something is fundamentally wrong with your hardware.

I forgot to mention that I did try the minimum config from initial post, but I'm facing the same issue at first boot, and then strangely I get the "unsupported platform" boot logo for subsequent tries, until I zap PRAM or revert to the OCLP config...

I think I will try to remove the original WiFi/BT card next, without much hope...

 

[borgo1971]

P.S. And if someone is guessing way I don't reinstall OpenCore from scratch to new nvme drive, I add that I tried this at first, but with no success. So I taught to make it easier and copy all from working drive. Although I realized that it is not as simple as I thought, now there is also another problem: if I boot the computer from Mojave and try to mount the EFI partition of the new nvme SSD (but also the old one), I get a error message, and partition won't be mounted. An error that is not detected if you boot from recovery. This is the error:

macpro:~ studio$ diskutil list
/dev/disk0 (external):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         2.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         2.0 TB     disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.0 TB     disk1
                                 Physical Store disk0s2
   1:                APFS Volume MacPro P2               790.5 KB   disk1s1

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS Emergency HD            39.3 GB    disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
   4:                  Apple_HFS Backup HD               2.0 TB     disk2s4

/dev/disk3 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS RED                     2.0 TB     disk3s2
   3:                 Apple_APFS Container disk4         2.0 TB     disk3s3

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.0 TB     disk4
                                 Physical Store disk3s3
   1:                APFS Volume Dati - APFS             823.3 GB   disk4s1
   2:                APFS Volume APFS                    11.2 GB    disk4s2
   3:                APFS Volume Preboot                 79.7 MB    disk4s3
   4:                APFS Volume Recovery                528.4 MB   disk4s4

macpro:~ studio$ nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version': (iokit/common) data was not found
macpro:~ studio$ diskutil mount /dev/disk0s1
Volume on disk0s1 failed to mount
If the volume is damaged, try the "readOnly" option

I can't figure what is causing this new issue... because before starting to try the upgrade, ssd's EFI partition mounted without problems, and now, even back old SSD, booting from it, and all seems as before... I get this error message if I try to mount EFI partition.

 

[paalb]

P.S. And if someone is guessing way I don't reinstall OpenCore from scratch to new nvme drive, I add that I tried this at first, but with no success. So I taught to make it easier and copy all from working drive. Although I realized that it is not as simple as I thought, now there is also another problem: if I boot the computer from Mojave and try to mount the EFI partition of the new nvme SSD (but also the old one), I get a error message, and partition won't be mounted. An error that is not detected if you boot from recovery. This is the error:

macpro:~ studio$ diskutil list
/dev/disk0 (external):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         2.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         2.0 TB     disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.0 TB     disk1
                                 Physical Store disk0s2
   1:                APFS Volume MacPro P2               790.5 KB   disk1s1

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS Emergency HD            39.3 GB    disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
   4:                  Apple_HFS Backup HD               2.0 TB     disk2s4

/dev/disk3 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS RED                     2.0 TB     disk3s2
   3:                 Apple_APFS Container disk4         2.0 TB     disk3s3

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.0 TB     disk4
                                 Physical Store disk3s3
   1:                APFS Volume Dati - APFS             823.3 GB   disk4s1
   2:                APFS Volume APFS                    11.2 GB    disk4s2
   3:                APFS Volume Preboot                 79.7 MB    disk4s3
   4:                APFS Volume Recovery                528.4 MB   disk4s4

macpro:~ studio$ nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version': (iokit/common) data was not found
macpro:~ studio$ diskutil mount /dev/disk0s1
Volume on disk0s1 failed to mount
If the volume is damaged, try the "readOnly" option

I can't figure what is causing this new issue... because before starting to try the upgrade, ssd's EFI partition mounted without problems, and now, even back old SSD, booting from it, and all seems as before... I get this error message if I try to mount EFI partition.

You have to use sudo.

 

[paalb]

I forgot to mention that I did try the minimum config from initial post, but I'm facing the same issue at first boot, and then strangely I get the "unsupported platform" boot logo for subsequent tries, until I zap PRAM or revert to the OCLP config...

I think I will try to remove the original WiFi/BT card next, without much hope...

Try minimal config, edit to allow install and then clean install OS on a new disk.

 

[sfalatko]

Oh I've given it a try since I connected my cMP 3 weeks ago and the longer I have it the more I realise its not for me.

I've said before I didn't even realise OpenCore was installed until I checked my Boot ROM version hoping to see the latest 144.0.0.0.0 only to find it reported as 9144.0.7.3.1 and after researching realised it was spoofing the ROM version.

And simple things like editing the SystemParameters.plist file to change ContinuitySupport from false to true to enable Apple Watch Unlock for the upgraded BCM94360CD Airport card and a few other things like I did on my iMac only the other day are made more complex by OpenCore spoofing the motherboard ID so it is not clear how/which or even if I can modify the plist.

I would at this point in time sacrifice OpenCore completely if it made it straightforward just to modify the entry in the plist above to enable full Continuity/Handoff.

And that's just the tip of the iceberg for me. 10.000 replies in this thread alone means I will never be up to speed on it and thats not including the many thousands more on related subject matter. My Modus Operandi has always been KISS...Keep It Simple Stupid even more so since I turned 60 and am struggling to learn anything new and even printed manuals often don't make much sense to me any more!

That's not to take anything away from those geniuses who figure it out in the first place and share their knowledge with others who in turn share their experiences with the rest of us. I am in awe of the discoveries & workarounds and gladly contribute my own humble experiences when I can.

Things is I don't have any desire to upgrade beyond High Sierra as my 2011 iMac is stuck there for ever and I have held my other Macs on HS as for peace of mind I would prefer them to be all on the same macOS rather than mix 'n match.

Having said that I might be tempted to try Mojave on the cMP if I can safely do so without using OpenCore or any other jiggery pokery and if I like it might install on all but the iMac as although I have been inside to replace a faulty HDD and ended up fitting 2 SSD's and the BCM94360CD Airport card I have no desire to start playing around with graphics cards which could leave me dependant upon OpenCore or other workarounds on that machine.

I'm just waiting to see if by removing OpenCore it might impact anything else on the cMP before I disable it.

Thanks & kind regards,
-=Glyn=-

Glyn,

You can use Mojave on the cMP without OpenCore - it is fully supported. You will have to have a metal compatible graphics card to install it (I don't recall what graphics card you have or if you mentioned it earlier). You will have to do more than just change a plist to get Handoff/Continuity/Watch unlock to work. See the thread I pointed you to earlier for instructions on how to patch or use the Continuity Handoff Tool.

 

[Ausdauersportler]

Doesn't look like the driver got loaded. Which device is the XHCI controller? Use pci > pci.txt to find out. Or better yet, use my FixPCIeLinkRate.efi app. Don't forget to include output for drivers. Also, devtree.

Remove the drivers from the OpenCore config.plist. Boot OpenCore. Load the drivers manually. Does it still hang? I wonder if OpenCore is setting something up that is required by the drivers. This is why I would prefer getting the XhciDxe driver source code working.

Obviously the drivers cannot be loaded....

All requested files attached, also the drivers after loading them with connecting via load -nc driver. Additionally the OC debug log showing which drivers are loaded by OC.

Will disable now the last OC drivers...

Spoiler: OC Debug Log extract

01:954 00:036 OC: Driver XhciDxe.efi at 0 () is skipped!
01:988 00:033 OC: Driver UsbBusDxe.efi at 1 () is skipped!
02:017 00:028 OC: Driver UsbMassStorageDxe.efi at 2 () is skipped!
02:054 00:037 OC: Driver AMDGOP.efi at 3 () is skipped!
02:088 00:033 OC: Driver M370.efi at 4 () is skipped!
02:125 00:037 OC: Driver CoreEG2_x64.efi at 5 () is skipped!
02:154 00:028 OC: Driver EDIDParser_x64.efi at 6 () is skipped!
02:188 00:033 OC: Driver OpenRuntime.efi at 7 () is being loaded...
02:227 00:039 OCB: Arch filtering 0(40964)->88CEC018(40964) caps 4 - Success
02:265 00:038 OCABC: Got rendezvous with OpenRuntime r12
02:283 00:017 OCABC: MAT support is 0
02:305 00:022 OC: Driver OpenRuntime.efi at 7 is successfully loaded!
02:335 00:029 OC: Driver OpenCanopy.efi at 8 () is being loaded...
02:366 00:030 OCB: Arch filtering 0(163840)->8881A018(163840) caps 4 - Success
02:405 00:039 OCUI: Registered custom GUI protocol
02:440 00:034 OC: Driver OpenCanopy.efi at 8 is successfully loaded!
02:478 00:038 OC: Driver OpenLinuxBoot.efi at 9 () is being loaded...
02:509 00:031 OCB: Arch filtering 0(118788)->88825018(118788) caps 4 - Success
02:538 00:029 OC: Driver OpenLinuxBoot.efi at 9 is successfully loaded!

 

[joevt]

Obviously the drivers cannot be loaded....

All requested files attached, also the drivers after loading them with connecting via load -nc driver. Additionally the OC debug log showing which drivers are loaded by OC.

Will disable now the last OC drivers...

If you use load -nc then you have to use connect -r to connect the drivers.

I see from the pci list that your FL1100 XHCI device is at 3B:00.0 but you can't convert a bus number to a UEFI device path without the secondary and subordinate bus numbers of all the parent bridges. That's why the output from FixPCIeLinkRate.efi would be useful - because it shows the PCIe hierarchy.

I suppose drivers loaded by OC should appear in the dh output with handle numbers that are greater than the handle number for the OpenCore image? But your dh output has a bunch of unnamed LoadedImages? Or does the OpenShell's dh command not include code to output the source of the LoadedImage? Well, some handles with LoadedImage do show the source (the one for OpenCore.efi for example), so that can't be it. I guess the OpenCore drivers don't name themselves? Well, you can take the first 4 bytes of the protocol GUIDs and match them to code in OpenCore. For example, the first GUID starts with BA1EB455 so you can google 0xBA1EB455 and see that it is gOcBootstrapProtocolGuid.

1C4: BA1EB455-B182-4F14-8521-E422C325DEF6 gOcBootstrapProtocolGuid
1C6: DBB6008F-89E4-4272-9881-CE3AFD9724D0 gOcLogProtocolGuid
1C7: 62257758-350C-4D0A-B0BD-F6BE2E1E272C gAppleBootPolicyProtocolGuid
1C8: DDFA34FB-FE1F-48EA-B213-FB4A4CD57BE3 gAppleDebugLogProtocolGuid
1C9: D5B0AC65-9A2D-4D2A-BBD6-E871A95E0435 gEfiUserInterfaceThemeProtocolGuid
1CB: C5C5DA95-7D5C-45E6-B2F1-3FD52BB10077 gAppleOsLoadedNamedEventGuid
1CC: E316E100-0751-4C49-9056-486C7E472903 gAppleFramebufferInfoProtocolGuid
1CD: 314735F0-26FE-11E8-A470-B8E8562CBAFA gAppleImg4VerificationProtocolGuid
1CE: 24B73556-2197-4702-82A8-3E1337DAFBF2 gAppleSecureBootProtocolGuid
1CF: C7CBA84E-CC77-461D-9E3C-6BE0CB79A7C1 gAptioMemoryFixProtocolGuid
1D1: 570332E4-FC50-4B21-ABE8-AE72F05B4FF7 gOcFirmwareRuntimeProtocolGuid
1D3: 53027CDF-3A89-4255-AE29-D6666EFE99EF gOcInterfaceProtocolGuid
1D4: 8604716E-ADD4-45B4-8495-08E36D497F4F gOcBootEntryProtocolGuid

Besides naming the drivers, I suppose since OpenCore has its own UEFI Shell, it should probably be updated to have names for these protocol GUIDs that the dh command can include in its output.
Maybe you can get more info from dh -d -v > dh_d_v.txt but then you'll want to start zipping the files.

 

[Dayo]

I wonder if OpenCore is setting something up that is required by the drivers.

XhciDxe.efi apparently requires CreateEventEx which is not available in EFI 1.x and will hang when called.

I believe the instances where it is working in OpenCore have the ForgeUefi config option, which spoofs UEFI 2.x (ported from RefindPlus which in turn ported it from your driver), active and that OC will also hang (on EFI 1.x cMP) if this option is not active when the driver is loaded.

If so, the Driver#### approach should therefore work if you provide your ForgeUefi driver to be loaded first.

BTW, the other two drivers of the trio may well be red herrings.

 

[Ausdauersportler]

If you use load -nc then you have to use connect -r to connect the drivers.

I see from the pci list that your FL1100 XHCI device is at 3B:00.0 but you can't convert a bus number to a UEFI device path without the secondary and subordinate bus numbers of all the parent bridges. That's why the output from FixPCIeLinkRate.efi would be useful - because it shows the PCIe hierarchy.

I suppose drivers loaded by OC should appear in the dh output with handle numbers that are greater than the handle number for the OpenCore image? But your dh output has a bunch of unnamed LoadedImages? Or does the OpenShell's dh command not include code to output the source of the LoadedImage? Well, some handles with LoadedImage do show the source (the one for OpenCore.efi for example), so that can't be it. I guess the OpenCore drivers don't name themselves? Well, you can take the first 4 bytes of the protocol GUIDs and match them to code in OpenCore. For example, the first GUID starts with BA1EB455 so you can google 0xBA1EB455 and see that it is gOcBootstrapProtocolGuid.

1C4: BA1EB455-B182-4F14-8521-E422C325DEF6 gOcBootstrapProtocolGuid
1C6: DBB6008F-89E4-4272-9881-CE3AFD9724D0 gOcLogProtocolGuid
1C7: 62257758-350C-4D0A-B0BD-F6BE2E1E272C gAppleBootPolicyProtocolGuid
1C8: DDFA34FB-FE1F-48EA-B213-FB4A4CD57BE3 gAppleDebugLogProtocolGuid
1C9: D5B0AC65-9A2D-4D2A-BBD6-E871A95E0435 gEfiUserInterfaceThemeProtocolGuid
1CB: C5C5DA95-7D5C-45E6-B2F1-3FD52BB10077 gAppleOsLoadedNamedEventGuid
1CC: E316E100-0751-4C49-9056-486C7E472903 gAppleFramebufferInfoProtocolGuid
1CD: 314735F0-26FE-11E8-A470-B8E8562CBAFA gAppleImg4VerificationProtocolGuid
1CE: 24B73556-2197-4702-82A8-3E1337DAFBF2 gAppleSecureBootProtocolGuid
1CF: C7CBA84E-CC77-461D-9E3C-6BE0CB79A7C1 gAptioMemoryFixProtocolGuid
1D1: 570332E4-FC50-4B21-ABE8-AE72F05B4FF7 gOcFirmwareRuntimeProtocolGuid
1D3: 53027CDF-3A89-4255-AE29-D6666EFE99EF gOcInterfaceProtocolGuid
1D4: 8604716E-ADD4-45B4-8495-08E36D497F4F gOcBootEntryProtocolGuid

Besides naming the drivers, I suppose since OpenCore has its own UEFI Shell, it should probably be updated to have names for these protocol GUIDs that the dh command can include in its output.
Maybe you can get more info from dh -d -v > dh_d_v.txt but then you'll want to start zipping the files.

Thank you again for helping, just learning a lot of things while reading through your posts here

Here we go....

Still not sure why I cannot load the driver this way.

 

[borgo1971]

You have to use sudo.

Oops, little forgetfulness. After your tip, I tried again with coping EFI folder, and this time I get picker from which I could select SATA clone for boot, and now I'm cloning boot partition back to new nvme SSD. Thanks.

 

[aconu]

Try minimal config, edit to allow install and then clean install OS on a new disk.

Thanks, I was able to make some progress.

I was able to perform a working clean install on a spare SATA SSD after removing every non critical devices in the Mac Pro, including the NVMe PCI card (I/O Crest SI-PEX40129). Then, after re-adding everything, the culprit seems to be the NVMe drive. The same open core config works well with the clean system on the SSD, but fails on the upgraded system on the NVMe 970 Pro.

The upgraded system drive can be accessed without any issues when booting from the clean install.

So it's either a stange hardware incompatibility, or some legacy software incompatibility on the upgraded system (probably the later)...

It will be probably faster to backup my data, perform a clean install on the NVMe drive and use migration assistant to restore my data...

 

[Ausdauersportler]

XhciDxe.efi apparently requires CreateEventEx which is not available in EFI 1.x and will hang when called.

I believe the instances where it is working in OpenCore have the ForgeUefi config option, which spoofs UEFI 2.x (ported from RefindPlus which in turn ported it from your driver), active and that OC will also hang (on EFI 1.x cMP) if this option is not active when the driver is loaded.

If so, the Driver#### approach should therefore work if you provide your ForgeUefi driver to be loaded first.

BTW, the other two drivers of the trio may well be red herrings.

Went back to OpenCore to check your assumption (ForgeUefiSupport is set to false in my config):

- loading only the XhciDxe.efi let OpenCore hang on the driver connect
- adding UsbBusDxe.efi adds USB3 boot support back with OCLP

So loading UsbMassStorageDxe.efi is not needed at least on my iMac12,2 - cannot test of confirm it this will be valid for the MacPro5,1, too.

Trying the Driver#### approach with only these two drivers in the order

1. UsbBusDxe.efi
2. XhciDxe.efi

does still not work. But this is surely not related to the drivers, it must another problem possibly caused by the guy sitting in front of my very own keyboard.

 

[Dayo]

Went back to OpenCore to check your assumption (ForgeUefiSupport is set to false in my config):

- loading only the XhciDxe.efi let OpenCore hang on the driver connect
- adding UsbBusDxe.efi adds USB3 boot support back with OCLP

You can try XhciDxe.efi alone and switch ForgeUefi on in OC to see if it works.
Hopefully ForgeUefi is done before drivers are loaded.

Also when @joevt provides the ForgeUefi driver, you can test that.
Either way, XhciDxe.efi will definitely not work on EFI 1.x without something done because of the missing CreateEventEx.

Presumably your unit is EFI 1.x? Not sure if this is logged by OC.

 

[PeterHolbrook]

Hmmm. I may have been done something wrong, but, for the time being, I can only confirm that setting ForgeUefiSupport to TRUE will allow OC 0.7.6 to load UsbBusDxe.efi, UsbMassStorageDxe.efi and XhciDxe.efi without issues (as far as I can perceive) on a Mac Pro 5,1. However, the OC Picker will not see any USB3 bootable thumb drives connected to a flashed Titan-Ridge Thunderbolt card. More likely than not, the relevant efi drivers were never intended for the Titan-Ridge card.

 

[Black Ninja Original]

Hi guys!
I have one Mac Pro 5.1 mid 2010 with Nvidia Quadro K5000 video card for mac, Mojave installed on a Samsung 970 EVO Plus (KyroM.2 EVO PCIe card) and Sonnet Allegro Pro USB 3.2 PCIe Card.

I'm looking to do a clean install of opencore with BigSur but I'm not sure what is the best process for me…Martin Lo or Legacy Patcher (OCLP)?

I want go to BigSur so I could use the latest version of Logic X. I have a FireWire 800 sound card and a USB MIDI card (MOTU express) everything works perfectly in Mojave!

My Nvidea Quadro K5000 for mac does not allow me to install Mojave from a USB pendrive installer… Bug, I don’t know… Would any of these solutions (Martin Lo or OCLP) allow me to install with a pendrive?

What is the best solution for my case? Martin Lo ou OCLP?



Thanks in advance!

 

[PeterHolbrook]

This thread advocates the method detailed in post #1, NOT OCLP or Martin Lo’s package, no matter the merits thereof.

 

[paalb]

It will be probably faster to backup my data, perform a clean install on the NVMe drive and use migration assistant to restore my data...

That is my preferred method.

 

[GlynH]

Glyn,

You can use Mojave on the cMP without OpenCore - it is fully supported. You will have to have a metal compatible graphics card to install it (I don't recall what graphics card you have or if you mentioned it earlier). You will have to do more than just change a plist to get Handoff/Continuity/Watch unlock to work. See the thread I pointed you to earlier for instructions on how to patch or use the Continuity Handoff Tool.

Hey sfalatko,

Thanks for taking the time to reply. I managed to disable OpenCore thanks to MacNB2 and others, got my motherboard ID back and I thought I'd try the plist mod that enabled Apple Watch unlock on the iMac but that didn't work on the cMP.

I then followed the post in the thread you linked to but that didn't work either.

I might just have to run CAT and see what happens if there is noting else I can try.

I'd rather do things myself as I will get a better understanding and learn form it rather than let a tool run amok on my system but I am running out of things to try.

I'll follow up in the Mac Pro Bluetooth thread when/if I/we get it working!

Thanks & kind regards,
-=Glyn=

 

[joevt]

XhciDxe.efi apparently requires CreateEventEx which is not available in EFI 1.x and will hang when called.

I believe the instances where it is working in OpenCore have the ForgeUefi config option, which spoofs UEFI 2.x (ported from RefindPlus which in turn ported it from your driver), active and that OC will also hang (on EFI 1.x cMP) if this option is not active when the driver is loaded.

If so, the Driver#### approach should therefore work if you provide your ForgeUefi driver to be loaded first.

BTW, the other two drivers of the trio may well be red herrings.

Weren't these drivers taken from a MacPro6,1? I thought the purpose of taking the drivers from a MacPro6,1 was because it was EFI 1.1 and compatible with MacPro5,1? Does MacPro6,1 have UEFI 2.0?

A dump from the RefindPlus debug log on a MacPro6,1 would be useful here. It will show the sizes of the Runtime Services and Boot Services tables which will tell us which functions they contain.

For example, my MacPro3,1 has this info in the RefindPlus debug log:

      System Table:- 'EFI  1.10' (HeaderSize: 120)
     Boot Services:- 'EFI  1.10' (HeaderSize: 368 ... Expected: 376)
  Runtime Services:- 'EFI  1.10' (HeaderSize: 120 ... Expected: 136)
      DXE Services:- 'Ver  0.90' (HeaderSize: 160 ... Expected: 168)

"HeaderSize" is the size of the table indicated in the header of the table. "Expected" is the size of the table defined in the edk2 headers that RefindPlus is compiled with. For 64bit EFI, Each missing 8 bytes is a pointer to a function that the MacPro3,1's EFI 1.1 does not have.
CreateEventEx is in Boot Services as the last function - the MacPro3,1 doesn't have that function.
EFI 1.1 is also missing two functions in Runtime Services (actually 3 - one of them is used in EFI 1.1 for a different purpose) and one function in DXE Services.

Thank you again for helping, just learning a lot of things while reading through your posts here

Here we go....

Still not sure why I cannot load the driver this way.

Ok, so dh lists all the protocols for each handle. And of course dh -d -v isn't going to show more info for all those protocols that it knows nothing about (handles 1C4 to 1CF etc.) but now we see more info for the LoadedImage protocols (1D0, 1D2, etc.) - the debug file path specifically, which shows the path of the LoadedImage's originating .dll file.
I suppose it would be cool for OpenShell to show some info for some OpenCore protocols.

And from the FixPCIeLinkRate.efi output, we can see that the path of the XHCI is like this:

+[0000]
++00:1C.4-[05-CB]    # g2x4          [8086:1C18] [060400] PCI bridge (Normal decode)          : Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5
|`+05:00.0-[06-CB]   # g2x4          [8086:1513] [060400] PCI bridge (Normal decode)          : Intel Corporation CV82524 Thunderbolt Controller [Light Ridge 4C 2010]
| ++06:04.0-[39-69]  # g1x4          [8086:1513] [060400] PCI bridge (Normal decode)          : Intel Corporation CV82524 Thunderbolt Controller [Light Ridge 4C 2010]
| |`+39:00.0-[3A-3E] # g1x4          [8086:156D] [060400] PCI bridge (Normal decode)          : Intel Corporation DSL5520 Thunderbolt 2 Bridge [Falcon Ridge 4C 2013]
| | ++3A:00.0-[3B]   # g2x1          [8086:156D] [060400] PCI bridge (Normal decode)          : Intel Corporation DSL5520 Thunderbolt 2 Bridge [Falcon Ridge 4C 2013]
| | |`-3B:00.0       # g2x1          [1B73:1100] [0C0330] USB controller (XHCI)               : Fresco Logic FL1100 USB 3.0 Host Controller

Which translates to this:
PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)

Which can be found in the dh output. Another way to get that path is to find the bus number Bus #.........: 3B in the dh -d -v output.
I suppose it would be handy for the pci or FixPCIeLinkRate commands to output a handle number for each device. Then you can get info for that specific device
dh -d -v 11B

 

[Riceman0]

Ok - I made a stupid NOOB move and installed OpenCore on my system without having the 144 firmware installed. I was still on the MP51.0089.800 firmware. For some reason, I thought the process was going to complete this. But the instructions are clear... I should already be on 144. When I ran Mohave after the OpenCore install, it ran and updated me from HS to Mojave, but without the firmware update.
OpenCore is now Spoofing 9144.0.7.6.0
I can't see my NVME drive and I never completed a Firmware update routine (reboot, power-button hold, LED/Beep, CD-tray eject, restart).
I do not presently have a metal GPU so I could not install Mojave before doing this.
My desire is to get the right firmware installed from MP51 to 144 so that I can get the NVME features. I really don't care which OS I'm running.
What do I do next? I would assume that I would need to undo OpenCore and then go back to High Sierra? Looking for a little advice before I make matters worse.
Thanks

 

[tsialex]

What do I do next? I would assume that I would need to undo OpenCore and then go back to High Sierra? Looking for a little advice before I make matters worse.
Thanks

Go back to High Sierra with a fully supported macOS install, get a METAL supported GPU (even a GT710 will work) then upgrade to 144.0.0.0.0, see the first post here:

MP5,1: What you have to do to upgrade to Mojave (BootROM upgrade instructions thread)

Please fully read this first post, you will probably find that you have one or more problems described into the various notes below. Mojave will only install if you have upgraded your BootROM to the current release and your Mac Pro have a Metal capable GPU*. If you are trying to install Mojave...

forums.macrumors.com

 

[TECK]

Where are the drivers installed and how?

This is how your OC EFI tree looks and where your drivers should be placed:

Configuration

OpenCore Plistlib Generator for Mac Pro 4,1 - 5,1. Contribute to axivo/opencore development by creating an account on GitHub.

github.com

Make sure your config.plist reflects the added drivers you placed into /Drivers directory.

 

[Dayo]

Weren't these drivers taken from a MacPro6,1? I thought the purpose of taking the drivers from a MacPro6,1 was because it was EFI 1.1 and compatible with MacPro5,1? Does MacPro6,1 have UEFI 2.0?

Well, Apple started using EFI 1.x with MacPro3,1 and as you know, their implementation is non-standard in that they patched it with features from UEFI 2.x and that it is effectively UEFI 2.0/1. IIRC, CreateEventEx was introduced in UEFI 2.3 released in 2012 ... after the MacPro5,1 which was released in 2010.

We also know from looking at some Mac Mini, I forget which one now, that when Apple went to UEFI 2.x, this was also patched and that QueryVariableInfo, available in other UEFI 2.x implementations, was missing.

Apple's Hybrid EFI 1.x was used for MacPro3,1 to MacPro5,1 with minor modifications (switched from UGA to the Mutant/Proto GOP implementation that made it such a challenge to provide bootscreen on the MacPro5,1 until the OC team finally cracked it ... by deleting it altogether and replacing with that from the GPU each time. Same approach was adopted in RefindPlus)

Apple could have patched their Hybrid EFI 1.x again, or perhaps used the by then stable and available UEFI 2.3 (vanilla or patched), to get CreateEventEx on the 6,1. A RefindPlus debug log from a 6,1 would tell. In the absence of this, some tests with your ForgeUefi driver can provide insight. I had a copy but can't find it right now

If @Ausdauersportler wants to continue driving this, please create a new thread so we can leave the Post 1 Nutters to their devices.

 

[cdf]

Hello guys,
I have gotten USB3 Boot with an FL1100 card working on the MacPro5,1 through OpenCore.

Very interesting. OC already includes a version of XhciDxe.efi. Do you think you could verify if that version can be used instead (in addition to UsbBusDxe.efi and UsbMassStorageDxe.efi)?

 

[Macschrauber]

Very interesting. OC already includes a version of XhciDxe.efi. Do you think you could verify if that version can be used instead (in addition to UsbBusDxe.efi and UsbMassStorageDxe.efi)?

I tested today again with VL805-06 and FL1100 and found that UsbMassStorageDxe.efi is not needed

OpenCore on the Mac Pro

I tested a USB3 card with VLI VL805-06 controller. To my surprise it also booted an USB thumb drive. USB3 - Sata adapter with Monterey 12.1 did not boot, it spit various USB errors in verbose mode. --- and tested a USB3 card with asm1142 USB 3 / USB C this thing booted the USB3 thumb drive...

forums.macrumors.com

OpenCore on the Mac Pro

can confirm it works :) of course just with FL1100 cards. tried USB Keyboard and Mouse on USB3 card with OpenCore and they worked In OC. booted an USB3 Stick with a Monterey Installer on it and it worked. also a USB3 - Sata adapter with a Sata SSD booted Montery 12.1 from USB3. Needed to...

forums.macrumors.com