MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0

[tsialex]

EDIT: I found where I had read here, where to find the MP51 rom (Install macOS Mojave.app/Contents/Resources/Firmware), thanks @tsialex

After that you have the warning "A firmware reconstruction is needed to get your Mac Pro fully working."

The MP51.fd is not a complete BootROM image, it's a generic partial image specifically crafted by Apple to be used for EFI upgrades via efiflasher. It's created without the NVRAM volume and just a partial MLB sector to not mess with any of your Mac Pro serials/hardwareIDs.

Flashing it to the backplane makes your Mac Pro completely unserialized, without any hardware IDs and without the hardware descriptor. The MP51.fd is just enough to boot a Mac Pro, but you won't have any serialization/hardware IDs and consequentially no iCloud/Messages/FaceTime logins since these depend on the hardwareIDs to id your Mac Pro with the Apple services.

Btw, you can't flash a MP51.fd and serialize the backplane with BBS, there are lot's of other hardwareIDs other than the System Serial Number that BBS don't add to the BootROM. A blank board bought from Apple only won't have SSN, but all other hardwareIDs, the hardware descriptor and the MLB sector are already present inside the NVRAM volume and MLB sector.

 

[alphascorp]

If you haven't already, you should back up your BootROM: your chip's free space seems low (hopefully garbage collection still works).

Because your BootROM has identifiers that are unique to your machine, you can't obtain a perfectly functional one from a macOS installer. To get a clean BootROM, I highly recommend purchasing a reconstruction service from @tsialex. His work is top-notch.

I already made the backup.
That's what I suspected (that once installed the rom should contain some specific information about my cMP).
I actually read a lot of @tsialex's posts and I learned a lot from them, I'm going to think about buying a reconstruction service from him.

 

[tsialex]

Besides new betas for Monterey and BigSur, Apple just sent the WWDC emails:

Join developers worldwide from June 6 to 10 for an inspiring week
of technology and community. Get a first look at Apple’s latest
platforms and technologies in sessions, explore the newest tools and
tips, and connect with Apple experts in labs and digital lounges.
All online and at no cost.
In addition to the online conference, Apple will host a special day
for developers and students at Apple Park on June 6 to watch
the keynote and State of the Union videos together, along with
the online community. Space is limited and details on how to
apply to attend will be provided soon.
Wherever you watch from, get ready for a fantastic WWDC.
Talented students can showcase their creativity for the opportunity
to receive an award in the Swift Student Challenge.
Get the latest updates on the web, by email, and in
the Apple Developer app.

 

[speedbird436]

Today I also dumped my ROM file using the tool of @Macschrauber

Went all smooth, thanks a lot for the tool but it seems, I have a problem, see the screenshot.

What does that VSS Store 1 mean?

 

[speedbird436]

Does anybody have an idea how I can fix the (very bad) error in my ROM?

It says

"Invalid VSS Store 1 header (very bad!)
49024 Bytes free space of 65472"

 

[ammoune78]

Look, this solves absolutely nothing, if you ever read my previous posts, some weeks ago I've calculated all the non used and contiguous empty areas inside the whole BootROM image - there are around 2MB completely empty and unused TODAY. Even if you successfully address all the issues with relocating the modules and relative addresses for the X86 reset vector, SEC core, the PEI and inside the EFI for a 64Mb SPI flash, the PEI code (and later the EFI) will continue to work with the VSS store as a 64KB segment.

Without the source code to re-implement the VSS store design - if it's even possible with the MacPro5,1 platform, since Apple didn't change the size of the VSS store with MacPro6,1, but used other type of mitigations, like multiple VSS stores inside the NVRAM volume to spread the writes inside the NAND.

Maybe i've said nothing, but hey it was a tiny suggestion, but again there are misunderstanding. I was never talking about relocation of 64Mb chip, i was talking about creating an empty 128Mb ROM EFI image, and start from it. Migrates the whole volumes from the 64Mb BootRom to that empty new created 128Mb BootRom EFI image, relocating the volume that contains VSS with it's address and size from whatever size it have to a bigger. So for whatever reason i grows, it already have much more room and will not affect other modules addresses.
If one ROM is created, it will help all the Mac Pro's owners, it's not a simple thing to do, as it requires a high leveled knowledge, and this is why i've called Nikolaj schlej by his name, because he's a master.
Another thing, is that i said for that actual problem, we need the help of vit9696, to locate and redirect the trick or do anything solution.
I have a link to the Nikolaj schlej website, if you want, so we can expose to him that thing, and see what he could says, doable or not, and to explain what we can do if solution will be. I can try this thing on my Mac, it doesn't matter if it bricks, sat least i can roll back to the apple chip!

 

[tsialex]

Maybe i've said nothing, but hey it was a tiny suggestion, but again there are misunderstanding. I was never talking about relocation of 64Mb chip, i was talking about creating an empty 128Mb ROM EFI image, and start from it. Migrates the whole volumes from the 64Mb BootRom to that empty new created 128Mb BootRom EFI image, relocating the volume that contains VSS with it's address and size from whatever size it have to a bigger. So for whatever reason i grows, it already have much more room and will not affect other modules addresses.
If one ROM is created, it will help all the Mac Pro's owners, it's not a simple thing to do, as it requires a high leveled knowledge, and this is why i've called Nikolaj schlej by his name, because he's a master.
Another thing, is that i said for that actual problem, we need the help of vit9696, to locate and redirect the trick or do anything solution.
I have a link to the Nikolaj schlej website, if you want, so we can expose to him that thing, and see what he could says, doable or not, and to explain what we can do if solution will be. I can try this thing on my Mac, it doesn't matter if it bricks, sat least i can roll back to the apple chip!

The NVRAM module won't grow, that's what I've repeatedly explained to you and you seem to don't understand - it's a fixed size, installing a bigger SPI flash won't change it. It's a 192KB volume, with two fixed size 64KB VSS stores.

Installing it on a bigger SPI flash don't change the fact that it's programmed to work this way and the current SPI flash is almost half empty already.

 

[tsialex]

Does anybody have an idea how I can fix the (very bad) error in my ROM?

It says

"Invalid VSS Store 1 header (very bad!)
49024 Bytes free space of 65472"

BootROM reconstruction service, I'll send you a PM.

 

[zzzippp]

I am preparing to sell my MacPro5,1 8-core, and have been having trouble with Kernel Panics at macOS Big Sur boot time (via OpenCore) which left compressed logs in the machines NVRAM. So I flashed the BootROM with the reconstructed one provided by @tsialex (thanks again!) and after two reboots (one with SIP enabled to get the NVRAM varibles populated, and then the second reboot to disable SIP so I could dump the BootROM and view it.

To my surprise, I don't see a Free Space line in either VSS store, only Padding. Note that I booted into the RefindPlus boot selection menu solution to select to boot macOS Mojave "natively", not using OpenCore at all. I used RefindPlus's SIP status toggle tool to disable SIP before the second boot into macOS Mojave. So there were no Kernel Panics or any other issues after I flashed the BootROM.

How can this happen, only two reboots after flashing the reconstructed BootROM? Should I be concerned about it, and what can I do to make the NVRAM data correctly organized?

Spoiler: Terminal output of 'nvram -xp'

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>EFIBluetoothDelay</key>
    <data>
    uAs=
    </data>
    <key>LocationServicesEnabled</key>
    <data>
    AQ==
    </data>
    <key>SystemAudioVolume</key>
    <data>
    QA==
    </data>
    <key>SystemAudioVolumeDB</key>
    <data>
    AA==
    </data>
    <key>bluetoothActiveControllerInfo</key>
    <data>
    jYKsBQAAAAATWrgJit1nEg==
    </data>
    <key>bluetoothInternalControllerInfo</key>
    <data>
    jYKsBQAAE1q4CYrdZxI=
    </data>
    <key>boot-args</key>
    <string>-no_compat_check</string>
    <key>csr-active-config</key>
    <data>
    fwgAAA==
    </data>
    <key>fmm-computer-name</key>
    <data>
    TWFjUHJvOENvcmU=
    </data>
</dict>
</plist>

 

[tsialex]

I am preparing to sell my MacPro5,1 8-core, and have been having trouble with Kernel Panics at macOS Big Sur boot time (via OpenCore) which left compressed logs in the machines NVRAM. So I flashed the BootROM with the reconstructed one provided by @tsialex (thanks again!) and after two reboots (one with SIP enabled to get the NVRAM varibles populated, and then the second reboot to disable SIP so I could dump the BootROM and view it.

To my surprise, I don't see a Free Space line in either VSS store, only Padding. Note that I booted into the RefindPlus boot selection menu solution to select to boot macOS Mojave "natively", not using OpenCore at all. I used RefindPlus's SIP status toggle tool to disable SIP before the second boot into macOS Mojave. So there were no Kernel Panics or any other issues after I flashed the BootROM.

How can this happen, only two reboots after flashing the reconstructed BootROM? Should I be concerned about it, and what can I do to make the NVRAM data correctly organized?

Spoiler: Terminal output of 'nvram -xp'

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>EFIBluetoothDelay</key>
    <data>
    uAs=
    </data>
    <key>LocationServicesEnabled</key>
    <data>
    AQ==
    </data>
    <key>SystemAudioVolume</key>
    <data>
    QA==
    </data>
    <key>SystemAudioVolumeDB</key>
    <data>
    AA==
    </data>
    <key>bluetoothActiveControllerInfo</key>
    <data>
    jYKsBQAAAAATWrgJit1nEg==
    </data>
    <key>bluetoothInternalControllerInfo</key>
    <data>
    jYKsBQAAE1q4CYrdZxI=
    </data>
    <key>boot-args</key>
    <string>-no_compat_check</string>
    <key>csr-active-config</key>
    <data>
    fwgAAA==
    </data>
    <key>fmm-computer-name</key>
    <data>
    TWFjUHJvOENvcmU=
    </data>
</dict>
</plist>

View attachment 1987443

This shouldn't happen. Take some steps back and correctly diagnose what is going on. Maybe it's just a configuration error somewhere, maybe it's a hardware issue.

Btw, trying to sell a Mac Pro with an unsupported macOS is a serious risk for the seller, any mistake that the buyer do will cause you lot's of headache. Sell with Mojave. One thing is to install OC for a friend or a long-time client that you provide support and you have a contract, it's completely different headache when you are selling.

 

[Macschrauber]

I am preparing to sell my MacPro5,1 8-core, and have been having trouble with Kernel Panics at macOS Big Sur boot time (via OpenCore) which left compressed logs in the machines NVRAM. So I flashed the BootROM with the reconstructed one provided by @tsialex (thanks again!) and after two reboots (one with SIP enabled to get the NVRAM varibles populated, and then the second reboot to disable SIP so I could dump the BootROM and view it.

To my surprise, I don't see a Free Space line in either VSS store, only Padding. Note that I booted into the RefindPlus boot selection menu solution to select to boot macOS Mojave "natively", not using OpenCore at all. I used RefindPlus's SIP status toggle tool to disable SIP before the second boot into macOS Mojave. So there were no Kernel Panics or any other issues after I flashed the BootROM.

How can this happen, only two reboots after flashing the reconstructed BootROM? Should I be concerned about it, and what can I do to make the NVRAM data correctly organized?

Spoiler: Terminal output of 'nvram -xp'

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>EFIBluetoothDelay</key>
    <data>
    uAs=
    </data>
    <key>LocationServicesEnabled</key>
    <data>
    AQ==
    </data>
    <key>SystemAudioVolume</key>
    <data>
    QA==
    </data>
    <key>SystemAudioVolumeDB</key>
    <data>
    AA==
    </data>
    <key>bluetoothActiveControllerInfo</key>
    <data>
    jYKsBQAAAAATWrgJit1nEg==
    </data>
    <key>bluetoothInternalControllerInfo</key>
    <data>
    jYKsBQAAE1q4CYrdZxI=
    </data>
    <key>boot-args</key>
    <string>-no_compat_check</string>
    <key>csr-active-config</key>
    <data>
    fwgAAA==
    </data>
    <key>fmm-computer-name</key>
    <data>
    TWFjUHJvOENvcmU=
    </data>
</dict>
</plist>

View attachment 1987443

somehow this nvram got a MS Certificate.

checked back with some other dumps with certificates: UefiTool stops reading the VSS1 Stream when it comes to the certificate.

Binwalk reads it correctly

 

[tsialex]

somehow this nvram got a MS Certificate.

checked back with some other dumps with certificates: UefiTool stops reading the VSS1 Stream when it comes to the certificate.

Binwalk reads it correctly




View attachment 1987577

Plausible explanation, but @zzzippp didn't wrote that he booted UEFI Windows right after flashing a never booted image.

Btw, even if he booted UEFI Windows, OC should take care of blocking Windows SecureBoot, so it's a misconfiguration somewhere.

 

[Macschrauber]

I asked him for a rom dump to eventually add another check to the dumper. So that's his nvram volume what causes uefi tool to stop reading the vss stream.

 

[Dayo]

even if he booted UEFI Windows, OC should take care of blocking Windows SecureBoot, so it's a misconfiguration somewhere.

He might have booted it via RefindPlus, but this should also take care of blocking the certs ... unless this was disabled.

Most likely UEFI Windows disk was loaded after a KP or NVRAM reset. Looks like his UEFI Windows is in a PCI Slot:

https://forums.macrumors.com/posts/30207327

Although most believe SATA Bay 1 has priority, the SATA Bays appear to come after the PCI Slots in the boot search order. I can imagine this happening, recovered from and seen as being of no consequence, hence not being mentioned.

In any case, @zzzippp has previous form on certs triggering "padding only" in NVRAM info:

MP5,1: BootROM thread | 144.0.0.0.0

dakanji's release version 0.12.0.AN added the NVRAM protection feature, back in January. The latest release is version 0.13.0.AG, a week ago as I'm writing this. Thanks for mentioning this, @tsialex. With so much information and discussion on OC, it's difficult to read through to find out...

forums.macrumors.com

As a side note, as of the next release of RefindPlus, v0.13.2.AP, if you boot into UEFI Windows with ProtectNVRAM active, it will not just block Windows certs, but also delete any matching certs that are already stored in the NVRAM.

 

[zzzippp]

This shouldn't happen. Take some steps back and correctly diagnose what is going on. Maybe it's just a configuration error somewhere, maybe it's a hardware issue.

somehow this nvram got a MS Certificate.

Plausible explanation, but @zzzippp didn't wrote that he booted UEFI Windows right after flashing a never booted image.

I think I know the explanation. I was trying to troubleshoot an issue where the latest RefindPlus boot .efi binary will not display its graphical boot menu on the GTX 760 installed in the MacPro5,1 8-core machine. In trying a different boot .efi binary, I lost the ability to select boot items "blindly" (with no display) in the RefindPlus menu. After that I was having great trouble finding a way to just boot natively (without RefindPlus) to macOS Mojave so I could start over.

I think while I was trying to get the machine to boot natively, it may have booted into Windows (but still displaying a black screen), and then when I finally got the MacPro5,1 8-core to boot macOS Mojave from a USB flash drive, I must have somehow not correctly flashed my BootROM with the reconstructed binary that I have from @tsialex. This would explain why the MS Certificates appeared in the dumped BootROM that I sent to @Macschrauber on his request.

Since that BootROM dump, I went through the following steps to make 100% certain my reconstructed BootROM was flashed without any configuration error or interference from RefindPlus, OpenCore, or Windows:

Spoiler: Steps taken to resolve NVRAM issues

1. I disconnected ALL SSD & HDD drives
2. I removed the StarTech dual-M2 NVMe SSD PCIe card that was in the Mac Pro 8-core
3. I only connected USB wired Apple keyboard & mouse
4. I booted into Recovery mode from macOS Mojave installed onto a USB flash drive
5. Disabled SIP via csrutil disable in Terminal
6. Rebooted to macOS Mojave on the USB flash drive
7. Flashed reconstructed BootROM using ROMTool app
8. Shut down the Mac Pro, removed power for 30 seconds to reset SMC, and plugged back in
9. Power up and boot to macOS Mojave on the USB flash drive so NVRAM variables are set
10. Reboot into Recovery mode (USB flash drive) and disabled SIP
11. Reboot into macOS Mojave (USB flash drive) and dump BootROM
12. Examined dumped BootROM in UEFITool and with binwalk - SUCCESS!

Please note that I have never before this had to go through so much trouble to reset my NVRAM to never-booted state. I normally just had to shut down and then press-hold power to enter firmware write mode, boot to RefindPlus, toggle the SIP status, select macOS Mojave to boot (NOT using OpenCore), and then flash with the reconstructed BootROM image.

checked back with some other dumps with certificates: UefiTool stops reading the VSS1 Stream when it comes to the certificate.

Binwalk reads it correctly

So today I have learned that UEFITool has a bug/glitch where it may not display all NVRAM data of a BootROM dump, possibly getting "stuck" at an MS Certificate entry. If that happens, then I can instead examine the BootROM using binwalk.

Most likely UEFI Windows disk was loaded after a KP or NVRAM reset. Looks like his UEFI Windows is in a PCI Slot:
https://forums.macrumors.com/posts/30207327

Although most believe SATA Bay 1 has priority, the SATA Bays appear to come after the PCI Slots in the boot search order. I can imagine this happening, recovered from and seen as being of no consequence, hence not being mentioned.

That's my theory too, and it's probably my fault as I did boot with the PCI card still in place that has the Windows NVMe install but without the HDD that has the MyBootMgr ESP (so there was no defaulting of the EFI to select the RefindPlus binary named as BOOTx64.efi).

Thank you for all your help, @tsialex, @Macschrauber, and @Dayo!

 

[tsialex]

I think I know the explanation. I was trying to troubleshoot an issue where the latest RefindPlus boot .efi binary will not display its graphical boot menu on the GTX 760 installed in the MacPro5,1 8-core machine. In trying a different boot .efi binary, I lost the ability to select boot items "blindly" (with no display) in the RefindPlus menu. After that I was having great trouble finding a way to just boot natively (without RefindPlus) to macOS Mojave so I could start over.

I think while I was trying to get the machine to boot natively, it may have booted into Windows (but still displaying a black screen), and then when I finally got the MacPro5,1 8-core to boot macOS Mojave from a USB flash drive, I must have somehow not correctly flashed my BootROM with the reconstructed binary that I have from @tsialex. This would explain why the MS Certificates appeared in the dumped BootROM that I sent to @Macschrauber on his request.

Since your Windows SecureBoot signing is so early in the circular log, starting at 0x6F6, you probably booted UEFI Windows right after you flashed, anything else is less probable.

Since that BootROM dump, I went through the following steps to make 100% certain my reconstructed BootROM was flashed without any configuration error or interference from RefindPlus, OpenCore, or Windows:

Spoiler: Steps taken to resolve NVRAM issues

1. I disconnected ALL SSD & HDD drives
2. I removed the StarTech dual-M2 NVMe SSD PCIe card that was in the Mac Pro 8-core
3. I only connected USB wired Apple keyboard & mouse
4. I booted into Recovery mode from macOS Mojave installed onto a USB flash drive
5. Disabled SIP via csrutil disable in Terminal
6. Rebooted to macOS Mojave on the USB flash drive
7. Flashed reconstructed BootROM using ROMTool app
8. Shut down the Mac Pro, removed power for 30 seconds to reset SMC, and plugged back in
9. Power up and boot to macOS Mojave on the USB flash drive so NVRAM variables are set
10. Reboot into Recovery mode (USB flash drive) and disabled SIP
11. Reboot into macOS Mojave (USB flash drive) and dump BootROM
12. Examined dumped BootROM in UEFITool and with binwalk - SUCCESS!

View attachment 1987638

Please note that I have never before this had to go through so much trouble to reset my NVRAM to never-booted state. I normally just had to shut down and then press-hold power to enter firmware write mode, boot to RefindPlus, toggle the SIP status, select macOS Mojave to boot (NOT using OpenCore), and then flash with the reconstructed BootROM image.



So today I have learned that UEFITool has a bug/glitch where it may not display all NVRAM data of a BootROM dump, possibly getting "stuck" at an MS Certificate entry. If that happens, then I can instead examine the BootROM using binwalk.

This is not a bug on UEFITool. Binwalk just scan for signatures and nothing else while UEFITool follow the circular log flow, decoding each entry, when it detects a padding area you can be sure that the circular log is corrupt.

Like I said before, UEFITool probably could have better wording, since you need to interpret what the app is saying.

That's my theory too, and it's probably my fault as I did boot with the PCI card still in place that has the Windows NVMe install but without the HDD that has the MyBootMgr ESP (so there was no defaulting of the EFI to select the RefindPlus binary named as BOOTx64.efi).

Thank you for all your help, @tsialex, @Macschrauber, and @Dayo!

Unless your PCIe card have a OROM that change the firmware scanning priorities, SATA have preference after flashing a never booted BootROM image.

 

[joevt]

I asked him for a rom dump to eventually add another check to the dumper. So that's his nvram volume what causes uefi tool to stop reading the vss stream.

So today I have learned that UEFITool has a bug/glitch where it may not display all NVRAM data of a BootROM dump, possibly getting "stuck" at an MS Certificate entry. If that happens, then I can instead examine the BootROM using binwalk.

This is not a bug on UEFITool. Binwalk just scan for signatures and nothing else while UEFITool follow the circular log flow, decoding each entry, when it detects a padding area you can be sure that the circular log is corrupt.

Like I said before, UEFITool probably could have better wording, since you need to interpret what the app is saying.

It might be asking too much to add binwalk capabilities to UEFITool.

However, if the non-empty padding is a sign of corruption, and there is a valid VSS entry inside the padding, and the entry can be detected, then perhaps UEFITool could be made to find those valid VSS entries. A developer would need a sample corrupted dump to work with. On the other hand, if the non-empty padding can exist in a non-corrupted dump, then there isn't anything to do.

Does UEFITool NE have different behaviour than UEFITool? I usually use the new engine version and committed some changes back in October.

 

[zzzippp]

This is not a bug on UEFITool. Binwalk just scan for signatures and nothing else while UEFITool follow the circular log flow, decoding each entry, when it detects a padding area you can be sure that the circular log is corrupt.

Like I said before, UEFITool probably could have better wording, since you need to interpret what the app is saying.

Good to know. I just wish I had the knowledge to figure out how to add the additional signature definitions to make binwalk more useful.

.
Unless your PCIe card have a OROM that change the firmware scanning priorities, SATA have preference after flashing a never booted BootROM image.

In my experience, with an empty NVRAM, the MacPro5,1’s EFI gives priority to booting from a BOOTx64.efi boot binary on an ESP (EFI System Partition) of an HDD or SDD connected to one of the MacPro5,1’s internal SATA ports, before any drives connected via a PCIe card. Does that match your experience?

In my case, I made the mistake of disconnecting all drives connected to internal SATA ports, thinking that the Mac would boot from a normal macOS Mojave install on a USB flash drive, but forgetting that the Windows 10 boot .efi on one of the PCIe card’s NVMe drives would be prioritized over macOS on the USB flash drive.

Because of that, the security certificate blocking protections of RefindPlus and OpenCore didn’t even come into play.

Hindsight is 20/20.

 

[tsialex]

It might be asking too much to add binwalk capabilities to UEFITool.

However, if the non-empty padding is a sign of corruption, and there is a valid VSS entry inside the padding, and the entry can be detected, then perhaps UEFITool could be made to find those valid VSS entries. A developer would need a sample corrupted dump to work with.

We can provide examples/samples, no problem.

On the other hand, if the non-empty padding can exist in a non-corrupted dump, then there isn't anything to do.

Yes, the padding exists normally OUTSIDE the VSS store. When UEFITool shows a padding area inside the VSS store or over the secondary VSS store, it's clearly a problem.

I can explain this in detail later, show different samples and some code. UEFITool NE already does a great job, even with some warnings when it detect errors. Some tweaks here and there will make a lot easier to interpret what is happening.

Does UEFITool NE have different behaviour than UEFITool? I usually use the new engine version and committed some changes back in October.

The new engine decodes the VSS store, while the old one ignores it.

 

[tsialex]

In my experience, with an empty NVRAM, the MacPro5,1’s EFI gives priority to booting from a BOOTx64.efi boot binary on an ESP (EFI System Partition) of an HDD or SDD connected to one of the MacPro5,1’s internal SATA ports, before any drives connected via a PCIe card. Does that match your experience?

Yes.

In my case, I made the mistake of disconnecting all drives connected to internal SATA ports, thinking that the Mac would boot from a normal macOS Mojave install on a USB flash drive, but forgetting that the Windows 10 boot .efi on one of the PCIe card’s NVMe drives would be prioritized over macOS on the USB flash drive.

Because of that, the security certificate blocking protections of RefindPlus and OpenCore didn’t even come into play.

Hindsight is 20/20.

USB have the lowest priority, PCIe is always scanned/enumerated before USB. You have to remove even bootable FW drives to boot a USB createinstallmedia installer.

 

[Dayo]

In my experience, with an empty NVRAM, the MacPro5,1’s EFI gives priority to booting from a BOOTx64.efi boot binary on an ESP (EFI System Partition) of an HDD or SDD connected to one of the MacPro5,1’s internal SATA ports, before any drives connected via a PCIe card. Does that match your experience?

My experience, albeit on the MP31, matches this:

OpenCore on the Mac Pro

There is no default order. In my case, it is always my AHCI drive in PCIe slot 3 that gets priority after an NVRAM reset, no matter what other drives (and OSes) are present and where they are located. The quickest way to determine this is by trial and error (just be extra careful with Windows...

forums.macrumors.com

Set out here:

Boot drive priority/sequence in 5,1 cMP

There is likely randomness within each grouping indeed but the order of appearance of the groups, PCIe Slots -> Optical Drive Ports -> SATA Bays, has always been the same for me. Unless a fluke of course. As to what gets booted, remember that Intel Macs follows the UEFI spec (in spirit if not...

forums.macrumors.com

Thinking about it, it could be that the reason for a difference in experiences is that PCI Slots are handled differently based on whether they have AHCI/SATA or NVME drives attached, and that the order is actually...

PCIe|AHCI/SATA Slots -> Optical Drive Ports -> SATA Bays -> PCIe|NVME Slots -> Others

Needs confirmation at some point.

 

[tsialex]

My experience, albeit on the MP31, matches this:

OpenCore on the Mac Pro

There is no default order. In my case, it is always my AHCI drive in PCIe slot 3 that gets priority after an NVRAM reset, no matter what other drives (and OSes) are present and where they are located. The quickest way to determine this is by trial and error (just be extra careful with Windows...

forums.macrumors.com

Set out here:

Boot drive priority/sequence in 5,1 cMP

There is likely randomness within each grouping indeed but the order of appearance of the groups, PCIe Slots -> Optical Drive Ports -> SATA Bays, has always been the same for me. Unless a fluke of course. As to what gets booted, remember that Intel Macs follows the UEFI spec (in spirit if not...

forums.macrumors.com

Thinking about it, it could be that the reason for a difference in experiences is that PCI Slots are handled differently based on whether they have AHCI/SATA or NVME drives attached, and that the order is actually...

PCIe|AHCI/SATA Slots -> Optical Drive Ports -> SATA Bays -> PCIe|NVME Slots -> Others

Needs confirmation at some point.

Just a note, reseting/deep reseting the NVRAM is different from flashing a never booted BootROM image where the PEI will initialize/scan/enumerate all bootable drives without any previous reference (BootXXXX entries and etc).

 

[Burrowed]

Hello,

I just got my cross flashed cMP4.1 updated to the 144.0.0.0 firmware. It is a dual cpu with 12 gb (3 x 4 gb) ECC ram.

After that I upgraded Mojave to Catalina using the dosdude method (I used open core on an other Mac, I just wanted to try the dosdude method)

With this article in mind, I checked the free space within the bootrom image.

I think that I am in need for a deep nvram reset or all a fresh bootrom.

Below is a screenshot from the dump and the system information.

 

[tsialex]

Hello,

I just got my cross flashed cMP4.1 updated to the 144.0.0.0 firmware. It is a dual cpu with 12 gb (3 x 4 gb) ECC ram.

After that I upgraded Mojave to Catalina using the dosdude method (I used open core on an other Mac, I just wanted to try the dosdude method)

With this article in mind, I checked the free space within the bootrom image.

I think that I am in need for a deep nvram reset or all a fresh bootrom.

Below is a screenshot from the dump and the system information.

View attachment 1989314

View attachment 1989313

This is extremely common with early-2009 cross-flashed Mac Pros, already have a corrupt NVRAM volume, the missing secondary VSS store/header corrupt, you need a reconstruction service.

 

[Burrowed]

This is extremely common with early-2009 cross-flashed Mac Pros, already have a corrupt NVRAM volume, the missing secondary VSS store/header corrupt, you need a reconstruction service.

Thanks for the quick response!

Could you offer me the reconstruction service?