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
Yes .. . 128 pages . . . I have never had any serious bootrom problems so #2888 wasn't on my " must read" list. Congrats to you AND h9826790 for his confirmation of your discovery.
Good news. Perhaps this "discovery" should be added to your #1 post
Good news. Perhaps this "discovery" should be added to your #1 post
This isn’t a new discovery. @tsialex concluded and tested this a few hours after I reported the first occurrence. I guess you missed it...
A bit off topic, but what is the reasoning for requiring the full installer for BootRom updates? Considering 99.9% of people just use the delta installer, what's the sense?
Mac Pro 1,1 to 5,1 need manual firmware upgrades/user intervention, it's the last supported Mac that still has this way of firmware upgrades.
Before High Sierra, firmware upgrades for MP5,1 were standalone packages and not much people did the upgrades. Maybe even less than today.
Since 10.13 needed a firmware upgrade to support APFS, Apple made a firmware check/update at the beginning of the installer and not a standalone package. This continues to be the way firmware upgrades are done with MP5,1.
Delta and combo updates need to be made in a way that updates can be installed without user intervention, automatically and even remotely. So, this is probably the reason that made Apple use the full installers.
Anyone here has a mid-2012 Mac Pro built in the second semester of 2013? I only have 3 dumps of mid-2012 Mac Pros made after July 2013 and I need more.
Seems that the last ones have a newer hardware descriptor and I only found one example until now.
Usually mid-2012 Mac Pros have the Base_21 descriptor with this header/version:
I have a dump that still has the Base_21 but with this header/version:
If anyone have mid-2012 with 2013 build dates and could PM the dump, preferably later build dates, I'll be grateful. No need to send it again if you ever sent it before.
The easiest way to check is running MachineProfile:
[doublepost=1554028890][/doublepost]Btw, refurbished 5,1 Mac Pros have different headers/versioning, usually 010A thru 010D. This one is from a mid-2012 refurb:
refurbished 4,1 Mac Pros seems to start with 0107:
[doublepost=1554029101][/doublepost]Mid-2010 Mac Pros that had the backplane replaced by Apple after 2013 would be interesting too.
Seems that the last ones have a newer hardware descriptor and I only found one example until now.
Usually mid-2012 Mac Pros have the Base_21 descriptor with this header/version:
Code:
01050000 00000809I have a dump that still has the Base_21 but with this header/version:
Code:
01060000 00000809If anyone have mid-2012 with 2013 build dates and could PM the dump, preferably later build dates, I'll be grateful. No need to send it again if you ever sent it before.
The easiest way to check is running MachineProfile:
[doublepost=1554028890][/doublepost]Btw, refurbished 5,1 Mac Pros have different headers/versioning, usually 010A thru 010D. This one is from a mid-2012 refurb:
Code:
010D0000 00000809refurbished 4,1 Mac Pros seems to start with 0107:
Code:
01070000 00000810
With the original config you can’t run Mojave.
MacTracker do something similar, warning that the current OS version is supported with a METAL GPU.
Please not further discuss this, it’s totally useless for the purpose of my post.
You can't. The prerequisite for installing 138/139/140/141/142.0.0.0.0 is having a METAL GPU.
Th only way to overcome this prerequisite is reconstructing the BootROM.
@tsialex would that be the RomTool and DXEInject method ?
https://docs.google.com/document/d/1WNkM9LuGPq1sArO9EedWBHYq14NU7m-mDBLAWWJipyM/mobilebasic
https://docs.google.com/document/d/1WNkM9LuGPq1sArO9EedWBHYq14NU7m-mDBLAWWJipyM/mobilebasic
No. No one should risk your Mac Pro with this obsolete and unsafe method.
I’ll send you a PM with instruction later.
Thanks. I'll look forward to that.. I also found this method using the Next boot loader..
https://github.com/abdyfranco/next-loader/wiki/Installing-Next-Loader
https://github.com/abdyfranco/next-loader/wiki/Installing-Next-Loader
Folks, this thread is for research of bleeding edge firmware developments. Alex and several other contributors have made this abundantly clear: do not muck around with beta firmware if you do not have the means to recover from a failure. If it is a beta firmware, there is no reasonable reason the vast majority of people should install it. If it is public, read the first page of this thread as it is updated as new information is gleaned.
When it comes to features that are part of the more recent firmware (ie. NVMe booting), if you are unwilling to invest in the hardware required to enable these updates (a Metal graphics card), learn to accept that you have reached the limit of what have been pretty fantastic machines.
Putting the onus on Alex or others to rebuild your firmware for free because you do not want to purchase a new graphics card means he and others have less time to work on the central goal of this thread: research! Their research and reporting to Apple is a central part of why we have gotten these new features from Apple.
When it comes to features that are part of the more recent firmware (ie. NVMe booting), if you are unwilling to invest in the hardware required to enable these updates (a Metal graphics card), learn to accept that you have reached the limit of what have been pretty fantastic machines.
Putting the onus on Alex or others to rebuild your firmware for free because you do not want to purchase a new graphics card means he and others have less time to work on the central goal of this thread: research! Their research and reporting to Apple is a central part of why we have gotten these new features from Apple.
Last edited:
Hello! I want to analyse my bootROM.
The steps i did:
1. disable SIP
2. run ROMTool, dump rom
3. rom saved at the desktop with name MyRom.bin
4. Binwalk installation
In terminal i wrote ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
then
brew install binwalk
5. what to do next?
Found this post by tsialex
"Binwalk is a very complex tool to use and you have to know how to interpret the output.
The most basic way to use it is just:
command + filename of the file that you want to analyse
Code:
binwalk BootROM_dump.rom
This is almost useless, but shows the MS X509 certificates."
But the dump i extracted with ROMTool has an extension .bin not .rom
The steps i did:
1. disable SIP
2. run ROMTool, dump rom
3. rom saved at the desktop with name MyRom.bin
4. Binwalk installation
In terminal i wrote ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
then
brew install binwalk
5. what to do next?
Found this post by tsialex
"Binwalk is a very complex tool to use and you have to know how to interpret the output.
The most basic way to use it is just:
command + filename of the file that you want to analyse
Code:
binwalk BootROM_dump.rom
This is almost useless, but shows the MS X509 certificates."
But the dump i extracted with ROMTool has an extension .bin not .rom
Last edited:
Hi again,
since 141.0.0.0.0 doesent have important updates I think I leave it alone for now.
Im still trying to get my machine ready for the Titan Ridge.
I installed Windows 10 on a SATA drive by pressing the C Key, its all working so far, I hope that was not the wrong way. Diskutil says FDisk_partition_scheme, according to Wikipedia its MBR
Now what I don't get,
What is bricking the rom is it installing windows, or starting windows from the Mac boot picker ?
Now with the fresh installed 10.13.6 on a NVME blade, dosent show in the bootcamp boot disk chooser panel in windows.
Since I have a 4K and Mac edition GTX 680, to go back to Mac OS have to restart and blindly choose Mac OS from the boot picker. This thread explains how to fix that, it seems BootChamp 6.1. fixes that.
A other way would be a second screen on the DVI port, not sure if that still works with 10.13.6.
If choosing the windows boot drive from the boot picker bricks the ROM, I need to fix the panel in windows.
if not I can live with choosing it blind.
since 141.0.0.0.0 doesent have important updates I think I leave it alone for now.
Im still trying to get my machine ready for the Titan Ridge.
I installed Windows 10 on a SATA drive by pressing the C Key, its all working so far, I hope that was not the wrong way. Diskutil says FDisk_partition_scheme, according to Wikipedia its MBR
Now what I don't get,
What is bricking the rom is it installing windows, or starting windows from the Mac boot picker ?
Now with the fresh installed 10.13.6 on a NVME blade, dosent show in the bootcamp boot disk chooser panel in windows.
Since I have a 4K and Mac edition GTX 680, to go back to Mac OS have to restart and blindly choose Mac OS from the boot picker. This thread explains how to fix that, it seems BootChamp 6.1. fixes that.
A other way would be a second screen on the DVI port, not sure if that still works with 10.13.6.
If choosing the windows boot drive from the boot picker bricks the ROM, I need to fix the panel in windows.
if not I can live with choosing it blind.
Thank you!
I never installed Windows in EFI, so it seems there no Windows certificates, but I found IASInstallPhaseList.
Should I worry?
Last edited:
Windows installed via UEFI mode writes SecureBoot certificates over the 1st and 2nd NVRAM streams every time you run it.
Post all this superfluous chatter in a different thread. This has nothing to do with your BootROM.
No, you just have one IASInstallPhaseList log, you probably interrupted or had an unsuccessful macOS install. Two or more is a symptom of something wrong with the NVRAM, one is expected.
BTW, let's use the correct terms. It's Windows installed with UEFI mode. CSM mode is the correct name of the standard/old Windows mode. Mac Pro up to mid-2012 is just EFI, the predecessor of UEFI.
I ALWAYS wait for the tone. It can take a it. But if I wait, the update works. I also have to set my display to force Displayport 1.1.
So do I, but keep in mind that not all of our cMP's perform the way we expect.
I've had 3 LogicBoards in my machine since it was purchased new from Apple. On two of the boards, I must continue holding the power-button beyond the strobing light, and then release once the long tone starts.
On one LogicBoard (all with the same firmware version mind you), I had to release as soon as the light would start strobing. If I didn't release the power button before the strobing completed, the machine would never get the long tone, and would simply restart or power off.
As a matter of safe procedure for firmware updates, I now do an SMC reset, and an NVRAM reset, prior to attempting a firmware flash. Doing this has been 100% effective on all 3 logic boards. Without doing this, I would say that "I" have had a 5%-10% occurrence of the machine shutting off instead of booting into programming mode.
Also as another matter of safe procedure, after the firmware update, I do another SMC reset, and NVRAM reset.
This may seem excessive to some of you, but for me, the results are optimal in this way. I'm not sure why some machines have a different launch point for programming mode, but I suspect it has something to do with installed hardware, amount of memory, video card, etc... The whole ball of wax is involved here...
Just something to consider....
Last edited: