I was trying to get more dumps to confirm the 0106 header version that I only have one dump, what I got? A dump with a new 0107 header…
Seems that every time I try to confirm something I just get new questions
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
Seems that every time I try to confirm something I just get new questions
I was trying to get more dumps to confirm the 0106 header version that I only have one dump, what I got? A dump with a new 0107 header…
Seems that every time I try to confirm something I just got new questions
Cool, something new learned.
I really want to know when Apple stopped the MP5,1 production. Initially I thought that it ended around early September, but I already have one dump that shows a backplane that was made in the end of it, so probably Apple produced mid-2012 around October too. Maybe in the future we will find a Base_22 hardware descriptor?!? I don’t doubt it anymore.
Last edited:
If it’s at all helpful, I do recall being contacted from Apple Business rep around the Thanksgiving US Holiday that any remaining BTO (custom) orders for the “tower” needed to be placed before December that year. They ended that style Apple Business program with dedicated rep shortly after.
This is interesting, so the production continued until beginning of December, at least. A Mac Pro with a SSN from December will probably have a backplane BD of early November, the earliest one that I have is from late September for a complete Mac Pro, not replacement parts.
Another thing, replacement parts continued to be made after 2013, I have a dump from a backplane made in 2014 that don’t have the 17 digit serial of refurbished backplanes.
Thx for your offer, really appreciated.
I’m trying to find MP5,1s made at the end of the production, after October 2013.
Replacement backplanes made in 2014 are interesting too, but those are more complicate to identify, you have to look at the MLB/LBSN sector for the real BuildDate.
I was trying to get more dumps to confirm the 0106 header version that I only have one dump, what I got? A dump with a new 0107 header…
Seems that every time I try to confirm something I just get new questions
That's what happens when corporate doesn't give you budget until November, and you didn't want a 2013 Mac Pro because you had an investment in Aja capture cards ;-)
Thx for your offer, really appreciated.
I’m trying to find MP5,1s made at the end of the production, after October 2013.
Replacement backplanes made in 2014 are interesting too, but those are more complicate to identify, you have to look at the MLB/LBSN sector for the real BuildDate.
Were they manufactured in 2014 or configured in 2014? It's hard to think apple would run the manufacturing line on such a small unit basis.
Manufactured, but this is replacement parts, not full systems.
[doublepost=1554337516][/doublepost]I only have one dump, I’ll wait more examples before any conclusions.
I tried to send the instructions for you by PM on how to dump and other info needed to validate the dump, but seems you only receive PMs by people you follow, I imagine.
I've been noticing one weird pattern lately. Some Mac Pros are not erasing old memory config parameters from the NVRAM after you change RAM.
Today I've found a dump that has 16 memory configs for just 4 16GB DIMMS:
I'd expect just 8, 4 in the 1st stream/store and 4 in the 2nd stream/store.
I'm going to keep an eye on this, seems a problem/bug to me.
[doublepost=1554462869][/doublepost]First I was thinking that this was a collateral problem of Netkas upgrade, since some parameters are stored differently in MP4,1 NVRAM from MP5,1, like the blobs that make TITAN GPUs not work, but this is a mid-2012.
Weird, no?
Today I've found a dump that has 16 memory configs for just 4 16GB DIMMS:
- 0x120076
- 0x12281D
- 0x12301D
- 0x12381D
- 0x1244D9
- 0x124cd9
- 0x1254D9
- 0x1262fb
- 0x126afb
- 0x127acc
- 0x1282cc
- 0x128ACC
- 0x130076
- 0x13281D
- 0x13301D
- 0x13381D
I'd expect just 8, 4 in the 1st stream/store and 4 in the 2nd stream/store.
I'm going to keep an eye on this, seems a problem/bug to me.
[doublepost=1554462869][/doublepost]First I was thinking that this was a collateral problem of Netkas upgrade, since some parameters are stored differently in MP4,1 NVRAM from MP5,1, like the blobs that make TITAN GPUs not work, but this is a mid-2012.
Weird, no?
Another curiosity, some firmware along the way changed the way the memory config data are stored, some dumps have big binary blobs with nothing identifiable (maybe a SPD dump?!?), but some recent ones have little blocks, almost an ASCII way to store the config, with the serial and some data clearly identifiable.
I don’t know if this have implications yet, still early days. It’s something that I thought that was a fluke, then become an observable pattern lately.
It’s not easy to check this here, my Macs never had this behavior, I’ll probably need to find someone that have the problem and have dual and single trays plus time to do tests.
I wonder if this is the reason why some people can use 32GB DIMM, but some others cannot (even for the exact same part number).
I commented about this with you last year, maybe the multiple memory configs has implications with this problem.
Windows 8.1 Pro installed twice in UEFI mode then upgraded to 141.0.0.1 and I got this, but all works perfectly fine:
Code:
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
1213557 0x128475 XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volumeNot erasing previous memory configs parameters is definitively a thing.
Look at this one, from the BootROM @Spacedust sent me to check:
Look at this one, from the BootROM @Spacedust sent me to check:
- 0x120076
- 0x1227ad
- 0x122fd9
- 0x1237d9
- 0x123fd9
- 0x124892
- 0x125092
- 0x125892
- 0x126b7a
- 0x12737a
- 0x127b7a
- 0x1290d3
- 0x1298d3
- 0x12a0d3
- 0x12b1ef
- 0x12b9ef
- 0x12c1ef
- 0x12ca9d
- 0x12d29d
- 0x12da9d
- 0x130076
- 0x1327ad
- 0x132fd9
I have various examples of totally full NVRAM.
Multiple memory configs + SecureBoot certificates (they are big) + IASInstallPhaseList (can be very long sometimes) can make a NVRAM full and a Mac practically non functional.
Btw, the first Mac that had the NVRAM totally full was a Mac mini late-2012 from @highvoltage12v. After I cleaned it up, I started to check MP5,1 NVRAM for the same problems too.
[doublepost=1554553883][/doublepost]
Yes, the intermediate NVRAM has the 1st and 2nd streams empty, one of my early decisions that proved to be totally correct, and this is totally resolved after flashing the reconstructed BootROM.
[doublepost=1554555285][/doublepost]This is probably a thing that Apple noticed very early:
- MP3,1 has 32KB NVRAM for everything on the NVRAM, with just 2MB FWB flash memory
- MP4,1/MP5,1 SPI flash is 4MB and changed the NVRAM to 192KB, 64KB for the 1st stream, 64KB for the 2nd.
- MP6,1 doubled the size of the SPI flash.
Does the memory configurations get deleted with zapping pram or doing a nvram -c ?
Explains why it is sometimes necessary to zap when upgrading.
Explains why it is sometimes necessary to zap when upgrading.
With a normal NVRAM, yes. It’s common to need to force the Mac Pro firmware re-do the memory config. It’s an habit of mine every time I change RAM or CPU-tray to clear the NVRAM 3 times.
When you already have multiple configs/full NVRAM, no. That's what intrigued me with the Mac mini dump that I talked about.
At least it's a relatively easy thing to prevent and repair. Btw, this is not something widespread, just some dumps have it. Until more evidence is found, I’m inclined to think this problem as an unfortunate confluence of events, more like the worst case and not the norm.
Last edited:
I've never changed CPU's in this machine. It came upgraded with 2x5675's, then upgraded from stock RAM (12 GB) to 64 GB RAM and then to 96 GB RAM. Never touched them after this time (probably about 4-5 years).
However I keep changing GPUs, PCI cards and SSDs.
However I keep changing GPUs, PCI cards and SSDs.
I have a 2009 4,1 that I upgraded to 5,1 via the usual firmware flash. I normally run Ubuntu on it, but I have a High Sierra disk that I can drop in for firmware updates.
I finally bought a Mojave compatible PC GPU (Nvidia GT 630 2 GB) so I could get on the NVMe train to perfomance!
I booted to HS and downloaded and ran the Mojave updater. It correctly says that I need to shutdown, hold the button until I see the lights flash or a long beep.
When I folllow these instructions, I wait and after a while (15-20s?) the power lights flash quickly, then more slowly, then stop and the CD-ROM opens. The beep never happens. But I've tried releasing as soon as the fast lights flash, or after.
In either case, the system sits with no video and no other apparent activity. I can wait 30-60 minutes and nothing happens. If I power it off and back on at this point, it boots twice and then I am back in the old OS and it still wants me to update the firmware.
Any ideas what might be happening? Thanks in advance.
I finally bought a Mojave compatible PC GPU (Nvidia GT 630 2 GB) so I could get on the NVMe train to perfomance!
I booted to HS and downloaded and ran the Mojave updater. It correctly says that I need to shutdown, hold the button until I see the lights flash or a long beep.
When I folllow these instructions, I wait and after a while (15-20s?) the power lights flash quickly, then more slowly, then stop and the CD-ROM opens. The beep never happens. But I've tried releasing as soon as the fast lights flash, or after.
In either case, the system sits with no video and no other apparent activity. I can wait 30-60 minutes and nothing happens. If I power it off and back on at this point, it boots twice and then I am back in the old OS and it still wants me to update the firmware.
Any ideas what might be happening? Thanks in advance.