Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0
- Thread starter tsialex
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Actually I downloaded 10.14.4 not 10.14.3
So that one is ok also. Great.
I dumped the Rom with RomTool, just in case.
I hope that way, its fixable if something goes south.
Thanks for your great support here Tisalex !!!
All the best NoLemon =)
So that one is ok also. Great.
I dumped the Rom with RomTool, just in case.
I hope that way, its fixable if something goes south.
Thanks for your great support here Tisalex !!!
All the best NoLemon =)
Waiting a minute after shutdown is to ensure everything is actually shut down, all fans stop spinning, all HDDs stop, etc. Is this required? No. But if you're troubleshooting, it's an easy step to eliminate another issue.
Keep holding after the tone because way too many people release the power button hold at the first sight/sound of the tone. In many cases this "aborts" the firmware update process or does not "engage" correctly. I'm sure there are more technical terms for this, but it has solved the failed firmware update for many people.
Yes I made that mistake once before knowing you need to keep holding, you need to see it start flashing the power button light with the tone, then let it go few seconds later. Then with a pram reset a new machine I had to do it with here had no startup tone, I found post from person here who said they regularly did it two or three times to get it to take. That ended up being the case with that machine it would not reset with a one pass through, it took the three before I got the tone back.
Given the hoops you have to jump through to update firmware from a beta release on the MP 5,1, I don't think anyone is just going to "trip over" the upgrade to FW 142.
For example, just to update to 141 I had to download the 10.14.4 installer; automatic upgrades never update the firmware on the 5,1 because I think the power button reboot is a required part of the process.
For example, just to update to 141 I had to download the 10.14.4 installer; automatic upgrades never update the firmware on the 5,1 because I think the power button reboot is a required part of the process.
Some people like to be on the bleeding edge of firmware updates and even with all the hops, people DID upgrade to 142.0.0.0.0 even after the first brick report.
It's important to test beta firmware, but only people that have the means to recover from potentially botched firmware upgrades.
If at the time we already knew where Apple hide the firmware, maybe MP51.0087.B00 would be caught in time and a lot of people wouldn't have bricked.
Another thing, if we didn't found, reported and warned about it here, Apple probably would release 142.0.0.0.0 as of the BootROM of 10.14.4 final - this is really obvious now since Cupertino released the same 142.0.0.0.0 again as the firmware for 10.14.5 DP1 even after it was pulled with the 10.14.4 DP6.
Last edited:
Apologies to this thread's participants for creating any negative feelings re: the 10.14.4 release.
Had a long hard week & not looking forward to my 70th. B'day this year plus there seemed to an onslaught of negative threads appearing so suddenly. The bricking of a fair few cMPs didn't help either.
Anyway, I successfully installed 10.14.4 along with the 141.0.0.0 bootrom - everything seems to be working.
I did a clean install to a 480gb SanDisk SSD.
Tomorrow I'll try CCC cloning 10.14.4 to a Samsung 960 EVO HFS format.
PS : I had absolutely no idea that I could now boot ( & install Mojave ) from my Sandisk SSD in an external USB 3.0 dock. Must have missed those posts regarding this.
Had a long hard week & not looking forward to my 70th. B'day this year plus there seemed to an onslaught of negative threads appearing so suddenly. The bricking of a fair few cMPs didn't help either.
Anyway, I successfully installed 10.14.4 along with the 141.0.0.0 bootrom - everything seems to be working.
I did a clean install to a 480gb SanDisk SSD.
Tomorrow I'll try CCC cloning 10.14.4 to a Samsung 960 EVO HFS format.
PS : I had absolutely no idea that I could now boot ( & install Mojave ) from my Sandisk SSD in an external USB 3.0 dock. Must have missed those posts regarding this.
Yesterday, I tried to install the High Sierra Security Update 2019-002 on my 2012 Mac Pro (DP W3680 3.33 GHz processors). I used the standalone installer. After launching the installer and authorizing it, I clicked to restart and complete the installation. The screen went black except for the arrow cursor and nothing happened. After four hours, I pressed the power button to do a hard reset. I've never had problems prior to this, doing any updates, even those that contained EFI ROM (firmware) updates.
For comparison, I did the same procedure on my 2011 17" MacBook Pro. Its screen went black briefly (with the same cursor), then a whitish screen appeared and the installation began. It went through a few restarts for the security update and firmware update and finished everything just fine.
When I tried to power on my Mac Pro, a whitish screen appeared after the normal startup chime, so I guess memory and other HW checks were okay. A bunch of white text in a black background then appeared on the whitish display, in a way that happens (I believe) when starting up in verbose mode. The Mac then sat in that state for up to 3 hours without any further progress. I did two a few attempts at resetting the NVRAM ("PRAM") and unplugged the Mac to reset the SMC, both to no avail. Here is the text that displays on every attempt to boot the Mac:
I do have an EFI flashed NVIDIA Titan X (from macvidcards.com) display card installed. I've never had problems with OS or firmware updates before with the card installed.
I couldn't find any info in a few web searches about the text displayed on my Mac's screen. I did find a nice article by Howard Oakley on his Eclectic Light website (eclecticlight.co) about EFI boot issues, startup chimes, etc.:
Startup tones, EFI, and fixing failed firmware updates
From the article, I found info on Apple's website and downloaded a "Firmware Restoration CD 1.9" disk image and burned it to a CD. However, I couldn't get the CD tray to eject on system boot, whether I used keyboard shortcuts or held a mouse button depressed. I'm not even sure if the CD/DVD drive is "active" at the point I reached when trying to boot my Mac Pro.
Right now, I'm a bit at a loss to know how best to proceed. If anyone knows about the screen text I listed above and what it means, that info may be very useful. I may try putting in an old, GT8800 Apple-supported display card to see if the EFI-flashed Titan X card is causing the Mac Pro to balk... and then try booting the Mac Pro (with the older GPU), doing the updates, then re-install the Titan X card...
I was wondering if anyone might have seen this behavior or has some advice for how to proceed... I would appreciate any thoughts or suggestions.
Thanks!
P.S. Just a wild thought, but since the screen text I listed above seems to be info about a set of 4 things, it may suggest that those messages are related to the PCIe slots...?
P.P.S. Sorry, but I forgot to mention that I did try booting into recovery mode, verbose mode, single-user mode, etc., without any success...
For comparison, I did the same procedure on my 2011 17" MacBook Pro. Its screen went black briefly (with the same cursor), then a whitish screen appeared and the installation began. It went through a few restarts for the security update and firmware update and finished everything just fine.
When I tried to power on my Mac Pro, a whitish screen appeared after the normal startup chime, so I guess memory and other HW checks were okay. A bunch of white text in a black background then appeared on the whitish display, in a way that happens (I believe) when starting up in verbose mode. The Mac then sat in that state for up to 3 hours without any further progress. I did two a few attempts at resetting the NVRAM ("PRAM") and unplugged the Mac to reset the SMC, both to no avail. Here is the text that displays on every attempt to boot the Mac:
[0 0 ] start port.
[0 0 ] start port hard reset (probe 1).
[0 1 ] start port.
[0 1 ] start port hard reset (probe 1).
[0 2 ] start port.
[0 2 ] start port hard reset (probe 1).
[0 3 ] start port.
[0 3 ] start port hard reset (probe 1).
[0 0 ] failed to hard reset.
[0 0 ] failed to perform port hard reset.
[0 1 ] failed to hard reset.
[0 1 ] failed to perform port hard reset.
[0 2 ] failed to hard reset.
[0 2 ] failed to perform port hard reset.
[0 3 ] failed to hard reset.
[0 3 ] failed to perform port hard reset.
[0 0 ] start port hard reset (probe 1).
[0 1 ] start port.
[0 1 ] start port hard reset (probe 1).
[0 2 ] start port.
[0 2 ] start port hard reset (probe 1).
[0 3 ] start port.
[0 3 ] start port hard reset (probe 1).
[0 0 ] failed to hard reset.
[0 0 ] failed to perform port hard reset.
[0 1 ] failed to hard reset.
[0 1 ] failed to perform port hard reset.
[0 2 ] failed to hard reset.
[0 2 ] failed to perform port hard reset.
[0 3 ] failed to hard reset.
[0 3 ] failed to perform port hard reset.
I do have an EFI flashed NVIDIA Titan X (from macvidcards.com) display card installed. I've never had problems with OS or firmware updates before with the card installed.
I couldn't find any info in a few web searches about the text displayed on my Mac's screen. I did find a nice article by Howard Oakley on his Eclectic Light website (eclecticlight.co) about EFI boot issues, startup chimes, etc.:
Startup tones, EFI, and fixing failed firmware updates
From the article, I found info on Apple's website and downloaded a "Firmware Restoration CD 1.9" disk image and burned it to a CD. However, I couldn't get the CD tray to eject on system boot, whether I used keyboard shortcuts or held a mouse button depressed. I'm not even sure if the CD/DVD drive is "active" at the point I reached when trying to boot my Mac Pro.
Right now, I'm a bit at a loss to know how best to proceed. If anyone knows about the screen text I listed above and what it means, that info may be very useful. I may try putting in an old, GT8800 Apple-supported display card to see if the EFI-flashed Titan X card is causing the Mac Pro to balk... and then try booting the Mac Pro (with the older GPU), doing the updates, then re-install the Titan X card...
I was wondering if anyone might have seen this behavior or has some advice for how to proceed... I would appreciate any thoughts or suggestions.
Thanks!
P.S. Just a wild thought, but since the screen text I listed above seems to be info about a set of 4 things, it may suggest that those messages are related to the PCIe slots...?
P.P.S. Sorry, but I forgot to mention that I did try booting into recovery mode, verbose mode, single-user mode, etc., without any success...
No, not unless you plug it into the USB2 ports.
FL1100 has not been added to the bootrom firmware.
EDIT : Seems I was wrong ( at 4:30 am . .yawn ) I had TWO drives with the same name .. the Sandisk SSD was connected to my PCIe Inateck external USB 3.0 dock the other was a 960 EVO NVMe M.2
Sorry for the confusion. Gotta get to bed earlier.
Hopefully Apple will give us PCIe USB 3.0 booting in 10.14.5 / 6
This has absolute nothing to do with firmware, at least the initial failure since Security Updates don't have firmware updates for MP5,1 - only full Mac App Store installers. MP5,1 is the last supported Mac that don't have automatic firmware updates and only manual updates with full installers.
Remove all your disks, install an empty disk and do a clean install from a createinstallmedia USB key of 10.13.6. Put your Mac Pro working then you diagnose what is going on with your disks - seems a disk failure to me.
Note:
If you think that your Mac Pro could have an old BootROM version, use El Capitan or Sierra to make it working, since they don't need firmware updates. High Sierra 10.13.6 installer has MP51.0089.B00 and will ask you do to the upgrade - usually it won't work when booting from the createinstallmedia USB-key, only from macOS.
You can still download El Capitan and Sierra:
El Capitan: https://support.apple.com/en-us/HT206886
Sierra: https://support.apple.com/en-us/HT208202
Last edited:
Thanks for your prompt response. I appreciate it, truly.
Anyway, I reset the SMC and the PRAM/NV-RAM, having pulled out all of the internal drives, and I still get the messages on screen as I posted previously right after POST (the same as before).
I rebooted (powered off, then on) with the thumb drive inserted and nothing happens (same screen messages). Any thoughts?
Remove all disks, all PCIe cards besides the GPU, try to boot with just the createinstallmedia USB-key. This hard reset seems related to RAID or PCIe SATA controllers, at least RocketRAID has the same "start port hard reset". If you still has the same log messages, try with your second GPU.
Since this is totally off-topic, please open a thread to further discuss your problem.
Tried to get public 141.0.0.0.0 on the Mac, didnt work, releasing the button while and after flashing, releasing while beeping and after beeping makes my 5.1 W3680 restart right away, just like a forced shut down / restart
I have a 4k display it has the option for DP 1.1 and 1.2 didn't work,
unplugging the display didnt work. Do we have to have a display connected ?
I have a 4k display it has the option for DP 1.1 and 1.2 didn't work,
unplugging the display didnt work. Do we have to have a display connected ?
Last edited by a moderator:
Updated from 140 to 141, no problems. I'm still using Sierra so I have a basic High Sierra install on an external SSD that I boot from and upgrade the BootROM using that.
My binwalk was posted in 2475
I'm using Windows 10 EFI, so I'm curious how much of a risk mine is for bricking itself on a future BootROM update, assuming I only use public release macOS installers from the App Store.
My binwalk was posted in 2475
I'm using Windows 10 EFI, so I'm curious how much of a risk mine is for bricking itself on a future BootROM update, assuming I only use public release macOS installers from the App Store.
For anyone who is interested in BootROM v142 which has caused some machines to become very expensive paperweights temporarily, Apple has responded to my bug report again.
Their response basically thanks me for reporting the problem (that it is still included in the developer preview, and is unchanged). They advise that they are working on a remedy to the problem, but did not elaborate further.
So, as long as you stick with the publicly released firmwares, you are safe for the time being. Please don’t play around with BootROM v142 unless you are personally prepared/able to recover from a non-bootable condition. It may get worse, before it gets better, so just be patient while this gets worked out.
I’ll keep @tsialex posted, and he can update this thread if I don’t.
At least I have their ongoing attention to the matter.
Their response basically thanks me for reporting the problem (that it is still included in the developer preview, and is unchanged). They advise that they are working on a remedy to the problem, but did not elaborate further.
So, as long as you stick with the publicly released firmwares, you are safe for the time being. Please don’t play around with BootROM v142 unless you are personally prepared/able to recover from a non-bootable condition. It may get worse, before it gets better, so just be patient while this gets worked out.
I’ll keep @tsialex posted, and he can update this thread if I don’t.
At least I have their ongoing attention to the matter.
Last edited:
It will brick if Apple ever release a BootROM without microcodes for your Xeon. This is improbable to happen again, Apple probably learned the lesson with MP51.0087.B00.
The problem is that Mac Pro is not an UEFI computer, it's EFI and it's not certified to run Windows with UEFI. Microsoft never should use SecureBoot with EFI computers.
The NVRAM space reserved for configs and parameters is just 64KB, the SecureBoot certificates use space that was never meant to be used by Windows and because it some Mac Pros are getting the 1st stream/store of the NVRAM totally full and incapable of changing settings.
Another thing, Windows is frequently writing to the NVRAM - just this is sufficient to make me never use UEFI installed Windows again.
Nothing new here, but just want to report another confirmation that swap from W3690 to E5530 can recovery a “bricked” 142.0.0.0.0 logic board.
Update 1: 141.0.0.0.0 is successfully flashed back in, POST without issue.
Tsialex, I will PM you the dumped 142.0.0.0.0 for your research. Cheers!
Update 2: after flash to 141.0.0.0.0, W3690 work again on my cMP.
P.S. It’s so interesting that how easy to swap CPU with liquid metal. What I did is basically remove the W3690, let the liquid metal stay there (no cleaning at all). Install the E5530, no thermal paste application at all. Let the liquid metal which still stick on the heatsink to handle the cooling (which is extremely good performance indeed). Once finish the firmware downgrade, swap back the W3690 without any cleaning and thermal paste application. After the whole process, only little bit liquid metal remain on the E5530, and I can easily put them back onto the W3690. And I can confirm that liquid metal won’t do any damage to the cMP heatsink.
Update 1: 141.0.0.0.0 is successfully flashed back in, POST without issue.
Tsialex, I will PM you the dumped 142.0.0.0.0 for your research. Cheers!
Update 2: after flash to 141.0.0.0.0, W3690 work again on my cMP.
P.S. It’s so interesting that how easy to swap CPU with liquid metal. What I did is basically remove the W3690, let the liquid metal stay there (no cleaning at all). Install the E5530, no thermal paste application at all. Let the liquid metal which still stick on the heatsink to handle the cooling (which is extremely good performance indeed). Once finish the firmware downgrade, swap back the W3690 without any cleaning and thermal paste application. After the whole process, only little bit liquid metal remain on the E5530, and I can easily put them back onto the W3690. And I can confirm that liquid metal won’t do any damage to the cMP heatsink.
Last edited: