Nothing wrong, that's normal.
Unless you download the new full macOS installer and run it. Your cMP's firmware won't be update.
In other words, macOS update via system preference will NOT update the firmware.
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
Nothing wrong, that's normal.
Unless you download the new full macOS installer and run it. Your cMP's firmware won't be update.
In other words, macOS update via system preference will NOT update the firmware.
Thanks for info. Is there any benefits I'm missing out on by not having 141.0.0.0.0?
Did you ever took a look on the first post of the thread? All your questions are already answered there in detail.
I did read the first post. Maybe I missed something but all it said about 141 is "minor updates". That could mean many things like performance improvement or security updates. If I'm causing an issues then I'm sorry...
There is one thing about the boot rom I am curious about: Since it is a serial rom, what loads it into RAM to execute? Is that the SMCs job, or is there some other low level process that does it? Does the SMC know how to identify the boot ROM part number, so it can read it, or is SMC firmware hard coded to match the boot ROM part number?
Using romtool made me curious why it had to ask for the part number of the ROM and why it couldn't identify it on its own. Is that something that only the SMC has access to?
Using romtool made me curious why it had to ask for the part number of the ROM and why it couldn't identify it on its own. Is that something that only the SMC has access to?
The PCH.
No.
It's purely hardware.
SMC control of the Mac Pro is limited to sensors and thing a like, it's the PCH that read the BootROM and then transfer control to it.
ROMTool is a GUI to a command line software, flashrom.
flashrom do all the work and when reading MXIC SPI flash memories, flashrom asks you to correctly identify the SPI, since MXIC use the same chip ID for various SPI flash memories that have different parameters.
This is not critical with MP4,1/MP5,1, but can brick a MacBook Pro if the wrong type of SPI flash is selected.
Last edited:
Just a quick question for the experts, I did manage to get my MP 5,1 flashed to 141.0.0.0 by READING ALL of the instructions and following them...pay attention these guys know what they are talking about...here's my question...
Just for educational purposes/self interest I now have 2 MP 4,1 backplanes...pulled the rom chips and tried programming them with 141.0.0.0 via several methods (ch341a_spi/flashrom and Raspberry Pi)...neither chip would verify and it left both chips in "unknown state" so I erased them and read contents (via Hex editor) all "FF" now...I do have a saved 4,1 bin file...but so far these chips refuse to program and I noticed something...
Both chips are SST25VF038B chips...the one I upgraded via Apples convoluted process is a MX25L3205D...both sets of chips are 32Mbit chips they are fairly similar...
My question: Is it possible that the 141.0.0.0 rom from the MX chip will NOT flash to a SST chip?
I suppose I could get a 4,1 cpu tray and try the convoluted process with that, but I was hoping just flashing the chip and re-installing it would upgrade these backplanes...obviously out of y depth here, but it is for purely self education so I'm not ashamed to be dumb.
p.s. just for experimenting I did order a couple of new MX25L3205D to try and flash, also a couple of the SST's just in case I did not extract them properly non-damage-wise...
I do find it odd that I cannot reflash them with the older M,1 rom...and am looking into my flash procedures to make sure I am not a dunce.
Just for educational purposes/self interest I now have 2 MP 4,1 backplanes...pulled the rom chips and tried programming them with 141.0.0.0 via several methods (ch341a_spi/flashrom and Raspberry Pi)...neither chip would verify and it left both chips in "unknown state" so I erased them and read contents (via Hex editor) all "FF" now...I do have a saved 4,1 bin file...but so far these chips refuse to program and I noticed something...
Both chips are SST25VF038B chips...the one I upgraded via Apples convoluted process is a MX25L3205D...both sets of chips are 32Mbit chips they are fairly similar...
My question: Is it possible that the 141.0.0.0 rom from the MX chip will NOT flash to a SST chip?
I suppose I could get a 4,1 cpu tray and try the convoluted process with that, but I was hoping just flashing the chip and re-installing it would upgrade these backplanes...obviously out of y depth here, but it is for purely self education so I'm not ashamed to be dumb.
p.s. just for experimenting I did order a couple of new MX25L3205D to try and flash, also a couple of the SST's just in case I did not extract them properly non-damage-wise...
I do find it odd that I cannot reflash them with the older M,1 rom...and am looking into my flash procedures to make sure I am not a dunce.
Last edited:
The Apple way is convoluted because the hardware IDs that have to be kept or your Mac will lose iCloud/FaceTime/iMessage access. If you flash the generic MP51.fd, all of your hardwareIDs will be erased and you can't go back unless you have a dump. Not even Apple can recover BD and BootBlock version, these are flashed at the manufacture time by the OEM. It's possible to make it work again with a lot of tests and tweaks, but never will be original again.
Another thing, you can't flash the dump from one Mac to another one, this effectively clone the Mac and Apple will get down hard, blocking both Macs. Never do this, Apple could even block your iCloud and you will have a lot of headache to get it going again. Apple is very serious about this, people who have to replace backplanes keeping the same serial, like @crjackson2134 and others, had similar problems with Apple and they had to prove ownership and more. Never do this.
Once a SPI flash is correctly dumped, the binary dump can be flashed to each of the 3 common types of SPI flash (SST25VF032B, MX25L3205D, MX25L3206E) - Apple supports another one but let's not get there.
Never flash a generic MP51.fd or a a dump from another Mac. NEVER.
Last thing: MP4,1 and MP5,1 BootBlock and MLB sector are not compatible. You will brick a MP4,1 flashing a MP5,1 firmware without the correct adjusts. Reverse is true too.
This is much more complex than people think, I needed almost a year researching to start to understand this.
Last edited:
See this is why it's important to ask questions...I think I need to "unlearn" a lot of crap I've carried over from the PC Microsoft world...
Thanks for the response, I guess if I want to use these backplanes I'll need to find a compatible cpu tray and go that route...I did save the dumps for each chip and the working MP 5,1 I am carefully not messing with it...
I had no idea the hardware was so wired to the ID's...and I can see why now if its iCloud related...probably lots of reasons to stay out of that mess...makes sense.
Thanks Alex, and if you don't mind me asking, why flash a rom via the ch341a_spi method if everything is so machine dependant?
I read with fascination you removing the chip and flashing it, but it begs the question where did the Documents/Apple MP5,1.fd file come from in the first place, is it a generic Apple rom file that will then load hardware specific to the machine?
(post #955 page 39)
You can boot macOS with a SPI flashed with MP51.fd. You can't get access to iCloud/FaceTime/iMessage, but you can get it ""working"".
Every full installer since 10.13.0 has a generic MP51.fd in the installer app (
/Applications/Install\ macOS\ Mojave.app/Contents/Resources/Firmware/MP51.fd )
to upgrade the BootROM to the the version needed by the OS release - I'm simplifying here, this is a little more complex since Mojave needs two firmware upgrades. This MP51.fd is stripped of everything that identifies a Mac.
When I brick one of my Macs, this happens more than I care to admit, I can get it booting again easily just flashing the generic MP51.fd. After I get it working again, I reconstruct the BootROM with the NVRAM and MLB/LBSN sector extracted from the original dump, then I flash my ex-bricked Mac Pro with the reconstructed BootROM. I usually have more than one bricked backplane to repair, so it's easy to work this way.
You can flash the original dump, it's just my way of doing things.
Thanks for the info...since I am doing this for "self education" I started by picking up a Mac Pro 4,1 with no cpu tray for $40...bought a tray on ebay that ended up being a 5,1...so I had to by a 5,1 backplane...managed to finally flash everything and upgraded the cpu to a 6 core and ram to 32 gigs plus added a PCIe drive and am running Xcode on it at about 4x the speed I was running it on my MacBook Pro with 16 gigs of ram...plus I do some audio editing and recording from my studio stuff (I build vintage Studio Recording gear as a hobby as well)...all because of your help...you have saved me a TON of bad experience via failure...tip definitely coming your way....my dad used to tell me a young man either gets wisdom or money, not sure how that works now that I am no longer young!
Thanks very much!
Thanks very much!
I'm trying to find MP51.0083.B00, from High Sierra DP5/PB4 (17A330h), to check the BootBlock version. It's the first recent BootROM and the one that started the APFS native support.
I already have the BIOS version, from a @squuid screenshot: MP51.88Z.0083.B00.1707271620
I had it saved on a disk that died recently. Anyone else saved it? @Squuiid @LightBulbFun
I already have the BIOS version, from a @squuid screenshot: MP51.88Z.0083.B00.1707271620
I had it saved on a disk that died recently. Anyone else saved it? @Squuiid @LightBulbFun
Last edited:
I have all other recent releases saved in my iCloud Drive. I took a look at MP51.0083.B00 last year, before thinking about making a table with all releases.
Yesterday I got an email from a reader showing another BootBlock version, good chance of being MP51.007F.B02. Until I have confirmation, I'm not going to add it.
Rats...don't suppose the first Beta or DP10 would be of any use? I've got those...
Nope, MP51.0084.B00 starts with 10.13 DP6 and goes with every new release until 10.13.3.
request kindly assistance from tsialex to restore my bootrom. through a late night, bonehead move, I updated my bootrom when prompted. I had booted to recovery mode, while running the Mojave developer, to reinstall mac os. I was thinking it would place me back to the release candidate but wasn't paying close attention. i was mistakenly thinking, since I hadn't downloaded the full installer yet, it wouldn't be harmful. surprise
the result was a dead Mac Pro that wouldn't boot. finally got it up and running by installing s X5xxx processor and can see the bootrom is currently 142.0.0.0.0. drat. the mac pro is 4,1 flashed to 5,1 some years ago and has been running without problems since. it even upgraded High Sierra, and then onto Mojave without issue. until it ran into me that one late night.
please assist and let me know all the steps to extract and provide you with the files to in order to recover.
Hardware Overview:
Model Name: Mac Pro
Model Identifier: MacPro5,1
Processor Name: 6-Core Intel Xeon
Processor Speed: 3.46 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 12 MB
Memory: 48 GB
Boot ROM Version: 142.0.0.0.0
SMC Version (system): 1.39f5
SMC Version (processor tray): 1.39f5
the result was a dead Mac Pro that wouldn't boot. finally got it up and running by installing s X5xxx processor and can see the bootrom is currently 142.0.0.0.0. drat. the mac pro is 4,1 flashed to 5,1 some years ago and has been running without problems since. it even upgraded High Sierra, and then onto Mojave without issue. until it ran into me that one late night.
please assist and let me know all the steps to extract and provide you with the files to in order to recover.
Hardware Overview:
Model Name: Mac Pro
Model Identifier: MacPro5,1
Processor Name: 6-Core Intel Xeon
Processor Speed: 3.46 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 12 MB
Memory: 48 GB
Boot ROM Version: 142.0.0.0.0
SMC Version (system): 1.39f5
SMC Version (processor tray): 1.39f5
My current rom post cleaning (thx tsialex):
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
I even needed to run Windows 8.1 DVD twice after cleaning for maintenance reasons (I needed to fix UEFI boot files on my new SSD post cloning) but thankfully it didn't wrote anything to my bootrom.
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
I even needed to run Windows 8.1 DVD twice after cleaning for maintenance reasons (I needed to fix UEFI boot files on my new SSD post cloning) but thankfully it didn't wrote anything to my bootrom.
@Riff_Al dump has *just* 25 MemoryConfig entries, new record:
- 0x1200a2
- 0x120ba2
- 0x1210a2
- 0x1218a2
- 0x121ddd
- 0x1225dd
- 0x122ddd
- 0x1243cc
- 0x124bcc
- 0x1253cc
- 0x125fe9
- 0x1267e9
- 0x126fe9
- 0x127a2c
- 0x12822c
- 0x128a2c
- 0x1294a3
- 0x129ca3
- 0x12a4a3
- 0x12aee6
- 0x12b6e6
- 0x12bee6
- 0x12ccbb
- 0x12d4bb
- 0x12dcbb