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
Thanks for the heads up. I don’t need nvme badly enough to do it manually. But when it gets to the instal via public beta stage I’ll give it a shot.
I've extracted my ROM, which is still on 084, with flashrom under Linux. I've dumped it 4 times directly one after another. I've compared them with md5sum and all 4 are equal. Does this mean I've successfully backup up my bootrom? And it is also readable with UEFitool, but I have no idea how to list the firmware version of that file or check the CRC-values.
I've also ran binwalk on it and haven't found a single X509-certificate, luckily.
I've also ran binwalk on it and haven't found a single X509-certificate, luckily.
This BootROM, from a mid-2010, is one of the corrupted ones that boots sometimes after some power-on/power-off retries:
What is causing problem booting is the corruption into parts 1 and 2 of the NVRAM volume, showed easily by this:
First IASInstallPhaseList, note that is mixed with Language Chooser setting:
Second IASInstallPhaseList, same as the first, repeated down into the second part of the NVRAM volume:
This is the same BootROM, Apple refurbished tracking codes removed and HardwareIDs from the case. No more trouble booting:
I had to change the oversized SON, since AHT couldn't parse the serial number.
- Highlighted in red: oversized SON
- Highlighted in yellow: Apple refurbished tracking codes
- Highlighted in black: SSNP and SSN
What is causing problem booting is the corruption into parts 1 and 2 of the NVRAM volume, showed easily by this:
First IASInstallPhaseList, note that is mixed with Language Chooser setting:
Code:
IASCurrentInstallPhaseLanguage Chooser™U(‘fiM«8jJú∆Kî≥å
IASInstallPhaseList<?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">
<array>
<dict>
<key>InstallPhase</key>
<string>Boot 1</string>
<key>InstallPhasePercentageKey</key>
<real>33.0078125</real>
</dict>
<dict>
<key>InstallPhase</key>
<string>Language Chooser</string>
<key>InstallPhasePercentageKey</key>
<real>66.9921875</real>
</dict>
</array>
</plist>Second IASInstallPhaseList, same as the first, repeated down into the second part of the NVRAM volume:
Code:
IASCurrentInstallPhaseLanguage Chooser™U(‘fiM«8jJú∆Kî≥å
IASInstallPhaseList<?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">
<array>
<dict>
<key>InstallPhase</key>
<string>Boot 1</string>
<key>InstallPhasePercentageKey</key>
<real>33.0078125</real>
</dict>
<dict>
<key>InstallPhase</key>
<string>Language Chooser</string>
<key>InstallPhasePercentageKey</key>
<real>66.9921875</real>
</dict>
</array>
</plist>This is the same BootROM, Apple refurbished tracking codes removed and HardwareIDs from the case. No more trouble booting:
I had to change the oversized SON, since AHT couldn't parse the serial number.
And again a wonderful job of @tsialex of crafting a new bootROM for my MacPro.
I didn't use the ROMtool but used a gparted live CD (linux based with the flashrom-tool) to dump and write back the bootROM. If anybody is interested I can do a sum-up of the steps I took to do all this.
I didn't use the ROMtool but used a gparted live CD (linux based with the flashrom-tool) to dump and write back the bootROM. If anybody is interested I can do a sum-up of the steps I took to do all this.
Do you have to be on Linux? Can you not brew flashrom-tool? A quick guide would be wonderful.
As @tsialex explained to me, using RomTool IS using flashrom. RomTool is just a GUI frontend for flashrom. If you right click on RomTool and select "Show Package Contents" > "Contents" > "Resources" you will see the flashrom executable (aka flashrom-tool) is right there.
Yes, you can install it from brew also, but it will be CLI only...
Last edited:
The thing for me was to try a usb-bootable OS that wasn’t macOS. That way you can restore your backup rom if you somehow screwed up your macOS install on your brand new NVMe drive. I don’t plan to have a spare ssd laying around for this purpose but I do want some kind of backup that is readily available.
And I don’t want to deal with disabling and enabling SIP every time I need to use flashrom.
Third advantage is, it is usable with my good ol’ GT120!!
And I don’t want to deal with disabling and enabling SIP every time I need to use flashrom.
Third advantage is, it is usable with my good ol’ GT120!!
If you screwed up your macOS install, flashing the firmware again won’t help.
Last edited:
I know that i have asked that a while ago, but since its going forward in examining the bootrom - thanks to @tsialex - i am curious wether it is possible to make any changes to the initialization process, to be exact - disable the ram check before chime -> that could lead to a serious decrease in pre-chime speed and also would fasten up the overall boot speed from zero to hero. Any chance to check that?
Completely correct. But this was more true before the 140 bootROM, and maybe again later.
But let me rephrase. If you cannot access a macOS install because something happend with you bootROM regarding drivers or something else that prevents you from accessing that disk or login into macOS, it is nice that you don't have to install macOS onto a separate disk or SSD, just to flash your backup bootROM back. In the releases prior to 140, without the NVMe-driver in it, you had to have a spare non-NVMe-disk just to extract the non-NVMe-bootROM, inject it with the NVMe-driver and put it back. And cloning your disk back and forth between NVMe-disks and non-NVMe-disks doesn't sound ideal to me. I just hope Apple leaves the NVMe-driver in the new bootROM-releases so we don't have to revert to self-injecting the NVMe-driver.
He was actually implying that if the bootrom is garbage you can't access any operating system and you say (correct me if I am wrong) you can boot from an external flash drive (LiveCD) with Linux with corrupted bootrom?
There is no fix for a non bootable system because of a completely corrupted bootrom, other than desoldering the chip and reflashing it or using the little frank connector to bypass the corrupted bootrom.
What I was trying to say, that this method works if you have you macOS install on your NVMe, and that is your only macOS install you have at the moment, and the bootrom gets updated by the OS and you lose the possibility to boot from NVMe. You can then insert your live CD and do the flashrom-part (read/modify/write) without needing to install a separate macOS on another disk. As this is not valid anymore if you are on bootrom 140 or newer (I hope) this has no practical use for a NVMe-situation.
But some people want to boot from USB3 (why, I don't know because you have NVMe now) and those drivers aren't included in the current bootom (yet?). So if someone actually manages to insert the USB3-drivers into the bootrom and you can boot from that, this is stil valid.
But this is all semantics, doesn't matter. It worked for my and I was in the situation where I had no macOS install at all, bootrom version 084 (without NVMe-support), and wanted to install it onto my NVMe-drive directly. Tsialex fixed me a 140-bootrom, I flashed it and installed 10.13.6 directly onto my NVMe without the need to install it first onto some other disk.
I manually checked my non-booting Windows installation. Partitions seemed to have been shuffled or corrupted. 128MB partitions/spaces make me think something went wrong in disk utility, or I did something wrong elsewhere. I usually manually set up partitions, and what I saw was not what I had created before.
I reinstalled and now have Windows EFI running again, and what appears to be 2 new certificates in my cleaned 0140 bootROM that was created by tsialex.
In the new installation I made the EFI partition 260MB instead of 100MB, as is recommended for 4k sectors in the M$ guide. Alhough I don't think it should matter for a 480GB SSD.
I (re)reflashed the cleaned 0140 bootROM, and everything seems to still be OK.
I will keep watching and tinkering. I'll probably upgrade to Mohave soon as well.
I'm hoping after today's Apple event some resources are freed to keep the 5,1 bootROM updates coming.
And or see what direction they're taking with this go-round of hardware.
Even if it's possible to disable the memory checking part of the POST, I never investigated this, why it would be a good idea?
Why exchange reliability for 20s faster boot?
@tsialex, i understand the reliability problem.
I know some people running non ECC RAM on 4,1 and 5,1 machines, which are booting faster because no extended ECC check is happening. I also know for sure that apple has the possibility to disable some checks via a service application and the LittleFrank connector.
The question is not why would someone want to have that, its more the "if it's is possible to change, then..." thing what is interesting me, like on the old PowerMac computers where you had an OpenFirmware interface to change settings...
I know some people in this thread who are working at apple.
They need the input from the thread to see what people want.
No mention in keynote. It's apparently "scheduled" but not 100% confirmed whatever that means.
If people from Apple read this, forget POST time and work with AMD to bring bootscreens a la RTX2080.
[USER=1033365][/user]
Too much to ask to work with NVIDIA to bring GTX/RTX GPUs to Mojave with CUDA?
Off-topic:
Btw, people here noticed that HEVC encoding is done by T2 and not by the GPU on the new mini?
When I saw that, my hopes of RX-580 hardware encoding seriously withered.
Btw, people here noticed that HEVC encoding is done by T2 and not by the GPU on the new mini?
When I saw that, my hopes of RX-580 hardware encoding seriously withered.
Yes, and with that my hopes for a user upgradeable internal GPU in MacPro7,1 slightly decreased. Getting the sense these machines will be treated as more of a closed "box" with all upgrades done externally via TB3 (or another connection). Then you can upgrade modules at will.