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

[Alan Young]

I'll second trifero's remarks above. I had a rom dump from a 5,1 that I am presently using. I sent it to tsialex for evaluation and it turned out that the rom had many problems with it. Don't know how much longer it would have lasted but my 4,1's rom bit the dust. I don't have a romdump from that machine. But the 5,1 rom was reconstructed by tsialex. I received it, flashed it and it is working like a champ. If this rom fails I am golden. I have the reconstructed rom with enhancements from the last version of the rom Apple put on the last machines made. I would just flash the reconstructed file to a new boot rom and replace it on the board. As for the 4,1 tsialex has created a rom that has most of everything to make it unique to the backplane with the exception of the BD. I am going to remove the rom from the backplane and try to dump anything that can be obtained from it. If any pertinent information is recovered tsialex can recreate the boot rom for it as it would be completely unique.
I am very happy with what he has done.

Alan

 

[gradyg22]

I'll second trifero's remarks above. I had a rom dump from a 5,1 that I am presently using. I sent it to tsialex for evaluation and it turned out that the rom had many problems with it. Don't know how much longer it would have lasted but my 4,1's rom bit the dust. I don't have a romdump from that machine. But the 5,1 rom was reconstructed by tsialex. I received it, flashed it and it is working like a champ. If this rom fails I am golden. I have the reconstructed rom with enhancements from the last version of the rom Apple put on the last machines made. I would just flash the reconstructed file to a new boot rom and replace it on the board. As for the 4,1 tsialex has created a rom that has most of everything to make it unique to the backplane with the exception of the BD. I am going to remove the rom from the backplane and try to dump anything that can be obtained from it. If any pertinent information is recovered tsialex can recreate the boot rom for it as it would be completely unique.
I am very happy with what he has done.

Alan

I can third that! Same deal for me. My system has been incredibly stable, and working beautifully since I got my bootROM reconstructed. I would even recommend ANY 4,1 -> 5,1 users get a reconstructed bootROM, as @tsialex showed me that the Netkas forum tool leaves thing in a hybrid state that is not good for long term stability. 5/5 stars for Alex and his work.

 

[flygbuss]

Same here! And it wasn’t just one cMP. Let’s say he saved a lost gang of almost bricked working horses! Great Job!

 

[ironmanny1]

See your PMs, I've sent my instructions to people that want a reconstruction, you will learn what to do following it.

@tsialex, Please PM about reconstruction. been holding back on it for a long time. but it is time. TY

 

[tsialex]

Same here! And it wasn’t just one cMP. Let’s say he saved a lost gang of almost bricked working horses! Great Job!

Almost all of your Mac Pros were good, when you think about 10+ years of usage and failed DIMMs messing with the NVRAM, but one that had a botched serialization process with a backplane replacement was the real challenge.

MacPro5,1s are very resilient beasts, it's very difficult to kill one even with the absolutely ridiculous NVRAM for today standards.

 

[flygbuss]

Almost all of your Mac Pros were good, when you think about 10+ years of usage and failed DIMMs messing with the NVRAM, but one that had a botched serialization process with a backplane replacement was the real challenge.

MacPro5,1s are very resilient beasts, it's very difficult to kill one even with the absolutely ridiculous NVRAM for today standards.

Thank you! Didn’t mean to belittle these awesome machines. I’m just glad we can keep them running since they are doing their job perfectly fine every day.

 

[Alan Young]

In addition to the above response, I would like to add that when tsialex sends a PM with instructions, they are the most precise, easy to follow and concise imaginable. Very thorough and very easy to get him the requested information. Like I have said before, I am very pleased with what he has done for my machines and what he has contributed to our quest for keeping these great machines running. The pre 6,1 Mac Pro's were marvelously engineered and it will be possible to be one of the last consumer computers in that category. I don't consider the 7,1 being there, as I cannot afford one for what I use a computer for. Not a traditional consumer computer.
It is great that we have the resources we have to keep them running. I applaud all of the people that spend their time working on the various problems we have had.
Thanks tsialex.

Alan

 

[zzzippp]

Which version of RefindPlus added that feature? Sounds like a worthy upgrade for me..

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.

You can use RefindPlus, it's using OC protection, but it's even more secure to add OC to the ESP of your Windows disk.

Thanks for mentioning this, @tsialex. With so much information and discussion on OC, it's difficult to read through to find out what advantages OC has over RefindPlus for my situation. To keep things on-topic, I will post on the OC thread to ask more about how OC is a more secure choice than using RefindPlus.

I chose to use RefindPlus for simplicity, and to as a proof-of-concept that my mid-2010 Mac Pro 5,1 can dual boot MacOS Mojave and Windows 10 installed on their own respective NVMe drives.

Since I now know in the unlikely event that Windows adds SecureBoot x509 certificates/DBs/PKs to my Mac's NVRAM, I can flash with the reconstructed BootROM to clear those certificate entries, I have successfully booted into Windows 10 (a clone of a BIOS-boot install converted to UEFI/GPT) on my second NVMe drive.

However, on checking a dump of my Mac Pro 5,1's BootROM, I see that two SecureBoot x509 certificate entries have been added:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
24972         0x618C          CRC32 polynomial table, little endian
35787         0x8BCB          mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
524288        0x80000         UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
549260        0x8618C         CRC32 polynomial table, little endian
560075        0x88BCB         mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
1048576       0x100000        UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1064960       0x104000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1065216       0x104100        Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1077504       0x107100        Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1085696       0x109100        Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1114112       0x110000        UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1130496       0x114000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1130752       0x114100        Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1143040       0x117100        Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1151232       0x119100        Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1179648       0x120000        UEFI PI Firmware Volume, volume size: 196608, header size: 1, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50
1188331       0x1221EB        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1253867       0x1321EB        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511       0x148017        bzip2 compressed data, block size = 100k
1376256       0x150000        UEFI PI Firmware Volume, volume size: 2686976, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
4063232       0x3E0000        UEFI PI Firmware Volume, volume size: 65536, header size: 1, revision: 0, GUID: E3B980A9-5FE3-48E5-929B-2798385A9027
4128768       0x3F0000        UEFI PI Firmware Volume, volume size: 65536, header size: 0, revision: 0, Apple Boot Volume, GUID: 04ADEEAD-61FF-4D31-BAB6-64F8BF901F5A

Since I did quite a few tests in my attempts to get a BIOS-boot Windows 10 install to boot off of my second NVMe drive, I can't say for sure when these certificates were added, but I note that the newest RefindPlus release 0.13.0.AG - which I haven't installed yet - includes a fix to "filtering of Windows Secure Boot Certificates on Apple Firmware", so perhaps the NVRAM protection feature wasn't working correctly?

Even more worrying than the X509 certificate entries is the state of my NVRAM. There are no invalid or duplicate entries, but instead of Free Space, there is only padding???

I have no idea if padding instead of free space is an issue, as I've not seen this before and don't remember reading about it anywhere. The second VSS store is identical to the primary one. I now wonder if using RefindPlus circumvents an otherwise unbootable NVRAM store if the "fallback" boot method is used (clearing the blessed boot volume by command-p-r reset to force the Mac to look for bootx64.efi on any EFI partition of connected drives).

Anyhow, updating to the latest RefindPlus release, I will be flashing my BootROM with my reconstructed backup, booting into the UEFI Windows 10 install, and then check ROM dump after all that to see if SecureBoot X509 certificate entries were added again.

 

[tsialex]

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 what advantages OC has over RefindPlus for my situation. To keep things on-topic, I will post on the OC thread to ask more about how OC is a more secure choice than using RefindPlus.

I chose to use RefindPlus for simplicity, and to as a proof-of-concept that my mid-2010 Mac Pro 5,1 can dual boot MacOS Mojave and Windows 10 installed on their own respective NVMe drives.

Since I now know in the unlikely event that Windows adds SecureBoot x509 certificates/DBs/PKs to my Mac's NVRAM, I can flash with the reconstructed BootROM to clear those certificate entries, I have successfully booted into Windows 10 (a clone of a BIOS-boot install converted to UEFI/GPT) on my second NVMe drive.

However, on checking a dump of my Mac Pro 5,1's BootROM, I see that two SecureBoot x509 certificate entries have been added:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
24972         0x618C          CRC32 polynomial table, little endian
35787         0x8BCB          mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
524288        0x80000         UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
549260        0x8618C         CRC32 polynomial table, little endian
560075        0x88BCB         mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
1048576       0x100000        UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1064960       0x104000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1065216       0x104100        Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1077504       0x107100        Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1085696       0x109100        Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1114112       0x110000        UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1130496       0x114000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1130752       0x114100        Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1143040       0x117100        Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1151232       0x119100        Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1179648       0x120000        UEFI PI Firmware Volume, volume size: 196608, header size: 1, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50
1188331       0x1221EB        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1253867       0x1321EB        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511       0x148017        bzip2 compressed data, block size = 100k
1376256       0x150000        UEFI PI Firmware Volume, volume size: 2686976, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
4063232       0x3E0000        UEFI PI Firmware Volume, volume size: 65536, header size: 1, revision: 0, GUID: E3B980A9-5FE3-48E5-929B-2798385A9027
4128768       0x3F0000        UEFI PI Firmware Volume, volume size: 65536, header size: 0, revision: 0, Apple Boot Volume, GUID: 04ADEEAD-61FF-4D31-BAB6-64F8BF901F5A

Since I did quite a few tests in my attempts to get a BIOS-boot Windows 10 install to boot off of my second NVMe drive, I can't say for sure when these certificates were added, but I note that the newest RefindPlus release 0.13.0.AG - which I haven't installed yet - includes a fix to "filtering of Windows Secure Boot Certificates on Apple Firmware", so perhaps the NVRAM protection feature wasn't working correctly?

Even more worrying than the X509 certificate entries is the state of my NVRAM. There are no invalid or duplicate entries, but instead of Free Space, there is only padding???

View attachment 1816875

I have no idea if padding instead of free space is an issue, as I've not seen this before and don't remember reading about it anywhere. The second VSS store is identical to the primary one. I now wonder if using RefindPlus circumvents an otherwise unbootable NVRAM store if the "fallback" boot method is used (clearing the blessed boot volume by command-p-r reset to force the Mac to look for bootx64.efi on any EFI partition of connected drives).

Anyhow, updating to the latest RefindPlus release, I will be flashing my BootROM with my reconstructed backup, booting into the UEFI Windows 10 install, and then check ROM dump after all that to see if SecureBoot X509 certificate entries were added again.

AFAIK, it's OC that is blocking Windows SecureBoot, but you should ask for confirmation on the thread.

Being honest here, the only fail proof way to never have SecureBoot installed by Windows when you reset the NVRAM (or change your config in a way that you don't boot from your OC install), is to install OC to the ESP of the Windows UEFI disk. All other fail-safes, one way or the other fail.

When you don't have free space anymore and UEFITool shows only padding, you already partially corrupted the VSS store, garbage collection probably failed and a variable (entry with UEFITool parlance) is now corrupt and being detected as padding space.

Since the NVRAM volume of MacPro5,1 is so tiny for today's usage, the only way to prevent this is to be pro-active and re-flash the never booted BootROM image on a schedule. Nothing will workaround the exiguous NVRAM space, this is a problem long know for some hackintoshes setups and now is a real problem with Mac Pros with more complex configs.

 

[Dayo]

I note that the newest RefindPlus release 0.13.0.AG - which I haven't installed yet - includes a fix to "filtering of Windows Secure Boot Certificates on Apple Firmware", so perhaps the NVRAM protection feature wasn't working correctly?

It wasn't indeed, hence the need for a fix but not in the way you suspect.

The summary of the fix is written below the headline you quoted:

• Fixes Filtering of Windows Secure Boot Certificates on Apple Firmware
  • Reverts Extension to Legacy Windows
  • This appears to have been linked to observed negative impacts on some Macs

Touching on an earlier post, as a techinicality, while RefindPlus does indeed hook into OC as a third party library to leverage some features, this filtering is not such a case.

Anyway, what the feature does is to process attempts to write to NVRAM and if the payload is a Windows Certificate, it is simply discarded. This filtering was only activated when UEFI Windows was detected but in the 0.13.2.AF release, I had changed this to just happen whenever Windows was detected.

That is, to just filter when running Windows, regardless of whether it was Legacy or UEFI Windows, to avoid situations where Legacy Windows is also writing certificates (no evidence it does, just in case) or where UEFI Windows was somehow misidentified. Basically just felt it would be more complete that way.

However, this change coincided with some NVRAM related funnies reported on Legacy Windows. I had no explanation for those so I reverted the only NVRAM related change affecting Legacy Windows made before, which was to set this back to how it was.

The change and reversion only affected Legacy Windows. UEFI Windows remained the same throughout but as with any such amendments, improvements invariably go in.

All said and done, my view is that Legacy Windows is best for a Legacy Mac.

Anyhow, updating to the latest RefindPlus release, I will be flashing my BootROM with my reconstructed backup, booting into the UEFI Windows 10 install, and then check ROM dump after all that to see if SecureBoot X509 certificate entries were added again.

That would be very useful feedback. Please mention me when you post it, or since it would be a RefindPlus issue that needs addressing if it doesn't work as it should, please raise an issue on the GitHub Repo.

 

[tsialex]

Please note that I’m not criticizing RefindPlus in any capacity, but I stand by my assessment that the only way to really be secure about Windows UEFI SecureBoot is to install OC to the ESP of the Windows disk. It’s not just SecureBoot, that can brick a Mac Pro only with specific circumstances, but also all the boot coups with Windows updates. A Windows boot coup is more serious than SecureBoot and a lot more complicated to get out.

People focus too much with SecureBoot, I’m not downplaying it just putting things into perspective, and forget things much more capable of bricking a MacPro5,1/6,1 like Windows boot coups or the garbage collection not working anymore.

Edit: removed typo.

 

[Dayo]

Please note that I’m not criticizing RefindPlus in any capacity, but I stand by my assessment that the only way to be really be secure about Windows UEFI SecureBoot is to install OC to the ESP of the Windows disk.

Sorry if I implied you were and no problem if so anyway as can try to fix shortfalls which would otherwise remain.

Was just clarifying that item on Certificate Filtering because it is done differently from OC implementation. Just different and not necessarily better btw. Just couldn't hook into that specific OC feature easily at the time which would have been the preference. So it was basically replicated directly in RP with tweaks.

My assessment is that there no way to be 100% certain about UEFI Windows. Hence the preference for Legacy Windows.

I see it as similar to it being perfectly safe to keep a fully grown Bengal Tiger in a corner of the back garden as long as it has a strong enough leash, its strike range marked out clearly on the grass and the kids told not to cross that line when playing.

An extreme view I suppose and there is a point where it is indeed safe enough ... I just happen to prefer smaller cats around the house!

 

[joevt]

Anyway, what the feature does is to process attempts to write to NVRAM and if the payload is a Windows Certificate, it is simply discarded.

Another option would be to save the certificate to RAM. It will get discarded after reboot. The only way to make it persist after a reboot is to have a Windows app that is executed at shutdown to save the RAM data to disk (since an EFI runtime service can't access the disk). I think this method is used by Clover for hackintoshes that can't access NVRAM.

This filtering was only activated when UEFI Windows was detected but in the 0.13.2.AF release, I had changed this to just happen whenever Windows was detected.
That is, to just filter when running Windows, regardless of whether it was Legacy or UEFI Windows, to avoid situations where Legacy Windows is also writing certificates (no evidence it does, just in case) or where UEFI Windows was somehow misidentified. Basically just felt it would be more complete that way.

However, this change coincided with some NVRAM related funnies reported on Legacy Windows. I had no explanation for those so I reverted the only NVRAM related change affecting Legacy Windows made before, which was to set this back to how it was.

The change and reversion only affected Legacy Windows. UEFI Windows remained the same throughout but as with any such amendments, improvements invariably go in.

All said and done, my view is that Legacy Windows is best for a Legacy Mac.

Does legacy Windows have access to UEFI NVRAM? Or does it save to a different NVRAM? I don't think legacy Windows would use the UEFI UUIDs? What kind of stuff would legacy Windows save to NVRAM? I guess it would be interesting to compare nvram before and after running legacy Windows.

 

[irayet]

Somewhat new to this, so I want to verify my understanding before I start trying to do anything.
If I dump my rom now, when the chip is still functional, I can buy a replacement chip and flash the dump onto that chip. Once it's been flashed on I can then just replace the existing rom chip with the new one. After that's done, its like nothing changed and I have a new chip without the wear of a decade-ish of usage.
Did I understand correctly?

 

[tsialex]

Somewhat new to this, so I want to verify my understanding before I start trying to do anything.
If I dump my rom now, when the chip is still functional, I can buy a replacement chip and flash the dump onto that chip. Once it's been flashed on I can then just replace the existing rom chip with the new one. After that's done, its like nothing changed and I have a new chip without the wear of a decade-ish of usage.
Did I understand correctly?

You are correct, the only thing that you are missing is that your dump is from a SPI flash memory that have a decade old NVRAM volume. The NVRAM is a component of the BootROM image and right now you have one that have ten years of usage.

Replacing the SPI flash memory will solve just the SPI flash NAND cells overuse, but still needs a clean-up/upgrade/reconstruction to have a brand new functional BootROM.

 

[Alan Young]

You are correct, the only thing that you are missing is that your dump is from a SPI flash memory that have a decade old NVRAM volume. The NVRAM is a component of the BootROM image and right now you have one that have ten years of usage.

Replacing the SPI flash memory will solve just the SPI flash NAND cells overuse, but still needs a clean-up/upgrade/reconstruction to have a brand new functional BootROM.

It is very worth it. The reconstructed rom image will have the 144.0.0.0 but will also incorporate other things that were in the last of the 5,1’s.
tsialex has all of the details he will pm you with. Send him the rom dump (his methodology is very easy and is described extremely well) and he will look at it and offer a reconstruction.

Alan

 

[trifero]

It is very worth it. The reconstructed rom image will have the 144.0.0.0 but will also incorporate other things that were in the last of the 5,1’s.
tsialex has all of the details he will pm you with. Send him the rom dump (his methodology is very easy and is described extremely well) and he will look at it and offer a reconstruction.

Alan

I agree.

 

[kurnitb]

Hi guys, I am a newbie in this. Currently I am running Sierra and trying to upgrade it High Sierra, I was wondering whether there would be any ways to update the BOOT ROM firmware without having a MAC EFI GPU? Many thank's in advance. I have tried pressing the power button until the tone but apparently it didn't update it and after reading on a few forums post I think I may need to put a MAC EFI GPU. At the moment, I have the ATI 5770 and have also RX 580. Tried them both with no luck. Many thank's for your help.

 

[tsialex]

Hi guys, I am a newbie in this. Currently I am running Sierra and trying to upgrade it High Sierra, I was wondering whether there would be any ways to update the BOOT ROM firmware without having a MAC EFI GPU? Many thank's in advance. I have tried pressing the power button until the tone but apparently it didn't update it and after reading on a few forums post I think I may need to put a MAC EFI GPU. At the moment, I have the ATI 5770 and have also RX 580. Tried them both with no luck. Many thank's for your help.

Nope - unless you are doing a BootROM reconstruction and that's not an end user procedure.

Please read the first post of the thread below and see what you are doing wrong:

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

 

[kurnitb]

Nope - unless you are doing a BootROM reconstruction and that's not an end user procedure.

Please read the first post of the thread below and see what you are doing wrong:

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

Thank's @tsialex and much appreciated.

 

[tsialex]

Thank's @tsialex and much appreciated.

If you want to workaround the whole upgrade process and get a never booted/fully cleaned 144.0.0.0.0 BootROM image for your Mac Pro, see the PM I've sent you.

 

[trifero]

If you want to workaround the whole upgrade process and get a never booted/fully cleaned 144.0.0.0.0 BootROM image for your Mac Pro, see the PM I've sent you.

@kurnitb My advice is that you get @tsialex recosntruction services. Many people here have a reconstructed BootRom from him and can´t be happier. Worth every cent.

 

[ironmanny1]

Just got my mac rom reconstructed by @tsialex. Very detailed and easy to follow instructions. There's a lot i don't understand about it. But, it gives me a peace of mind knowing my Mac Pro won't brick due to issues with my Rom. Totally recommend the reconstruction service.

 

[trifero]

Just got my mac rom reconstructed by @tsialex. Very detailed and easy to follow instructions. There's a lot i don't understand about it. But, it gives me a peace of mind knowing my Mac Pro won't brick due to issues with my Rom. Totally recommend the reconstruction service.

Remember reflash each three monts more or less.

 

[tsialex]

Remember reflash each three monts more or less.

The best way is to create a 3-month, or less, recurring/repeating Calendar appointment to re-flash the never booted BootROM image, so you never have a problem with the tiny MacPro5,1 NVRAM.