MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0

[MuNLoK]

Maybe I can also help you to get more data.

I’ve also been running Windows 10 Pro for years, upgrading it without issue, with HS on the main disk.

Last month, following your guide to update to 138.0.0.0.0, I updated directly from MP51.0084.B00 to MP51.0089.B00 , so I never updated to MP51.0087.B00.

Now I'm waiting to update to 140.0.0.0.0.

I've not exported the BootROM yet, but I can do it.

Ok, let's check yours. I'll PM you.

Thanks and sorry for late response (I have not had time to dump the rom until now).

Here is my binwalk. It's appears to be normal, but it's curious that it does not have any certificate, using windows 10 for years. What do you think?.

Considering that I never installed the 0087 firmware, this may be another example that this firmware may be related with the problem.

I also see that I have Base_17, is this a problem?

PD: What do you think about my builddate 090215090215p ?

cMP (Early 2009) 4,1 > 5,1 138.0.0.0.0
builddate 090215090215p
override-version Base_17

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
1343538       0x148032        bzip2 compressed data, block size = 100k
1376256       0x150000        UEFI PI firmware volume

 

[tsialex]

Thanks and sorry for late response (I have not had time to dump the rom until now).

Here is my binwalk. It's appears to be normal, but it's curious that it does not have any certificate, using windows 10 for years. What do you think?.

Considering that I never installed the 0087 firmware, this may be another example that this firmware may be related with the problem.

I also see that I have Base_17, is this a problem?

PD: What do you think about my builddate 090215090215p ?

cMP (Early 2009) 4,1 > 5,1 138.0.0.0.0
builddate 090215090215p
override-version Base_17

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
1343538       0x148032        bzip2 compressed data, block size = 100k
1376256       0x150000        UEFI PI firmware volume

You don't have neither SecureBoot X509 certificates or InstallPhaseList plist into your NVRAM volumes.

Your build date is a early one and Base_17 is the first descriptor installed into retail Mac Pros. I can update it to Base_21 and you will have the same ports configuration and sensor resolution as the mid-2012. I'll PM you.
[doublepost=1540033317][/doublepost]

I wonder what kind of information is stored in the fourth part of the NVRAM.
It seems to be that it consists of only 4 values. Any ideas what 'Gaid' 'tsth' 'tsty' and 'tstc' stand for?

Don't know for what this "part/stream" of the NVRAM is used, but this values are the same for a lot of Mac Pros, seems to change between years/HWC. Gaid is the header of the stream, and you have to interpret it in hexa.

Newer Macs have it too. My rMBP and mini have it too.

 

[startergo]

my binwalked dump from 139 contains 2 x509 certificates:

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
1181776 0x120850 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1247312 0x130850 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
1418584 0x15A558 Microsoft executable, portable (PE)

I have upgraded "the Apple way" to 140. Now my binwalked dump contains only one x509 certificate + xml:

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
1181486 0x12072E Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1197249 0x1244C1 XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume

@tsialex is this OK?

 

[tsialex]

my binwalked dump from 139 contains 2 x509 certificates:

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
1181776 0x120850 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1247312 0x130850 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
1418584 0x15A558 Microsoft executable, portable (PE)

I have upgraded "the Apple way" to 140. Now my binwalked dump contains only one x509 certificate + xml:

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
1181486 0x12072E Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1197249 0x1244C1 XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume

@tsialex is this OK?

Just one SecureBoot certificate is normal, but I think that is better to change your install to BootCamp/CSM and use iMac Pro BootCamp drivers to have APFS access (read #7). The InstallPhaseList seems to be saved by Mojave Recovery and/or Mojave installer, but it's weird some people don't get it saved into the NVRAM. I started to track this.

 

[startergo]

Just one SecureBoot certificate is normal, but I think that is better to change your install to BootCamp/CSM and use iMac Pro BootCamp drivers to have APFS access (read #7). The InstallPhaseList seems to be saved by Mojave Recovery and/or Mojave installer, but it's weird some people don't get it saved into the NVRAM. I started to track this.

I have 2 separate disks with HS on them and 2 separate disks with WIN10 on them, I have installed WIN10 through DVD EFI mode and then copied the WIN10 to another drive. I wonder if those certificates are created during install or during the boot to that WIN10? I can try and log on to both WIN10 installations and examine the dump again.

 

[tsialex]

I have 2 separate disks with HS on them and 2 separate disks with WIN10 on them, I have installed WIN10 through DVD EFI mode and then copied the WIN10 to another drive. I wonder if those certificates are created during install or during the boot to that WIN10? I can try and log on to both WIN10 installations and examine the dump again.

Microsoft documentation is not clear if SecureBoot certificates are saved during install, updated or just booting for the first time.

If you have time, you could you please track this for us? Thx!

 

[w1z]

Microsoft documentation is not clear if SecureBoot certificates are saved during install, updated or just booting for the first time.

If you have time, you could you please track this for us? Thx!

They are checked and recreated on every boot - I can confirm this after flashing my reconstructed bootrom and booting into my Windows EFI installation.

 

[tsialex]

They are checked and recreated on every boot - I can confirm this after flashing my reconstructed bootrom and booting into my Windows EFI installation.

Thanks, I'll check later if is (re)created just one time or at every boot. It's easy to check this with X509 certificates.

 

[startergo]

Thanks, I'll check later if is (re)created just one time or at every boot. It's easy to check this with X509 certificates.

Ok I have just booted to both WIN10 EFI disks and back to HS and here is the binwalked dump:

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
1181430 0x1206F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1189221 0x122565 XML document, version: "1.0"
1246966 0x1306F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1254757 0x132565 XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
I guess Windows creates 2 x509 cert and 2 XML for both EFI OS's

 

[tsialex]

Ok I have just booted to both WIN10 EFI disks and back to HS and here is the binwalked dump:

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
1181430 0x1206F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1189221 0x122565 XML document, version: "1.0"
1246966 0x1306F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1254757 0x132565 XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
I guess Windows creates 2 x509 cert and 2 XML for both EFI OS's

I'm not so sure about your conclusion.

The XML is the InstallPhaseList created by Mojave Recovery when you boot it or the USB Installer. It's the first time that I saw it twice, more than 80 Macs until now, Recovery/installer just add to the first one when needed.

What's worrying me more it's the address, 0x132565 is in the in second part of the NVRAM (starts with 0x130030) and this plist shouldn't be there. Something is wrong.

 

[startergo]

I'm not so sure about your conclusion.

The XML is the InstallPhaseList created by Mojave Recovery when you boot it or the USB Installer. It's the first time that I saw it twice, more than 80 Macs until now, Recovery/installer just add to the first one when needed.

What's worrying me more it's the address, 0x132565 is in the in second part of the NVRAM (starts with 0x130030) and this plist shouldn't be there. Something is wrong.

Strange I don't have Mojave recovery

 

[tsialex]

Strange I don't have Mojave recovery

What macOS version you are running? How you are disabling SIP?

 

[startergo]

What macOS version you are running? How you are disabling SIP?

I have 2 HS and their recovery partitions. I wonder if any of the recovery partitions is replaced by Mojave
Edit: both my RecoveryHD's are 10.13.6

 

[tsialex]

What we know so far:

• Windows installed with UEFI mode and with SecureBoot detects some BootROM changes, like when updated from MP51.0085.B00 to MP51.0087.B00, and resigns the BootROM inserting multiple SecureBoot certificates. Found three into two bricked Mac Pros and the problem could be caused by the crashes when running Windows without microcodes (@h9826790 speculated this and I think that has a lot of merit and explain the bricks)
• SecureBoot signs unsigned BootROMs at the first boot. (@W1SS observed it earlier today).
• Documentation from Microsoft don't say if it's signed again at every boot. Seems totally stupid to me if it is done this way - you have finite flash memory cycles, the SPI flash memory is not a SSD and don't have the same endurance or wear levelling and its sectored, change a bit and have to rewrite 512KiB. I'll check this tracking X509 certificates.
• Mojave Recovery saves two things into a reconstructed BootROM or after zap-PRAM, a little plist with the language that you selected the first time you run it and the InstallPhaseList. This have multiple confirmation (I, @crjackson2134 and @expede observed this behaviour in the last days).
• High Sierra Recovery saves a little plist with the language that you selected the first time you run it with a reconstructed BootROM or after zap-PRAM.
• Some people got every BootROM and macOS version installed and don't have InstallPhaseList present into the NVRAM.

 

[bookemdano]

Great summary. What would probably be useful to try to figure out next: are only certain MP51 bootroms triggering the dupe certificates, or do people who skipped 0087 still get two sometimes? And just speculating, but maybe the people with three had one from pre 0087, one written while 0087 was installed, and one written after 0089 or 138 was installed. Or, like startergo above, do dupe certificates come from multiple EFI Windows installs? I dunno, just some possibilities. But I don't think we have enough info yet to say that Windows should never be installed in EFI mode on the cMP. It's probably just unadvisable until this issue can be isolated further.

There is also the possibility to investigate that newer versions of Win10 have also changed signing behavior--and as has already been said, MS does not have adequate documentation on this. So caution is warranted but we do not have nearly enough information to blame Win10 for bootrom corruption (though it is a suspect).

I will try Win10 in EFI mode next week (with non-modded 138 installed) and will see what a binwalk looks like afterwards.

 

[tsialex]

Great summary. What is probably useful would be to try to figure out next is: are only certain MP51 bootroms triggering the dupe certificates, or do people who skipped 0087 still get two sometimes?

I was not tracking this issue before, just what causing the bricks and the descriptor. Talking with @h9826790 brought the Windows question to my attention.

I have enough data to get closer to an answer but I need time to recheck and add more data to my control spreadsheet, since some things can't be parsed and have to be checked manually.

And just speculating, but maybe the people with three had one from pre 0087, one written while 0087 was installed, and one written after 0089 or 138 was installed.

I'm not so sure. I think that the Mac Pros with three SecureBoot certificates are bricks and both died with MP51.0087.B00.

I found more than three into MP6,1 - but MP6,1 has so much problems that I don't want to bring them to this research and could be caused by different motives as with MP5,1.

Or, like startergo above, do dupe certificates come from multiple EFI Windows installs

I think that @UCDHIUS had 2 SecureBoot certificates and just one Windows UEFI install, he can confirm this. Maybe this again could be caused by crashes, he was overclocking his Mac Pro.

I dunno, just some possibilities. But I don't think we have enough info yet to say that Windows should never be installed in EFI mode on the cMP. It's probably just unadvisable until this issue can be isolated further.

There is also the possibility to investigate that newer versions of Win10 have also changed signing behavior--and as has already been said, MS does not have adequate documentation on this. So caution is warranted but we do not have nearly enough information to blame Win10 for bootrom corruption (though it is a suspect).

Botched 1809 may caused some havoc here, people reported un-bootable Windows installs and, now speculating, the crashes could contribute to this.

I will try Win10 in EFI mode next week (with non-modded 138 installed) and will see what a binwalk looks like afterwards.

More data/test is always useful.

 

[tu2thepoo]

@tsialex , could I send you a firmware dump to see if there's anything funky with my CMP? Currently running 10.13.6, FW 138. I think I've installed every firmware (incl 87), and it's had multiple EFI/legacy installs of Windows 10. No boot issues or anything but I'm paranoid after reading this thread

 

[Spacedust]

I wonder why Apple doesn't update the SMC. It still got PCI and PS fan noise issue even with genuine GTX680 Mac Edition. I have to use Macs Fan Control to set the fans properly both under macOS and Windows. It only works well with Apple HD5770 and HD5870 cards. I don't know how about latest RX580 Radeons.

 

[LightBulbFun]

I wonder why Apple doesn't update the SMC. It still got PCI and PS fan noise issue even with genuine GTX680 Mac Edition. I have to use Macs Fan Control to set the fans properly both under macOS and Windows. It only works well with Apple HD5770 and HD5870 cards. I don't know how about latest RX580 Radeons.

if this is happening on a Genuine MP5,1 then please do submit a bug report about

with any luck we can get an SMC update and retroactively apply it to Flashed 4,1s and unify everything

 

[startergo]

I wonder why Apple doesn't update the SMC. It still got PCI and PS fan noise issue even with genuine GTX680 Mac Edition. I have to use Macs Fan Control to set the fans properly both under macOS and Windows. It only works well with Apple HD5770 and HD5870 cards. I don't know how about latest RX580 Radeons.

I use macsfancontrol and it always spins the fans at highest speed at login and 10-20 seconds later it calms down. Without macsfancontrol I can't even hear them, but I am trying to keep down the IOH temp (65c)

 

[tsialex]

Never saw this before, look at this BootROM dump:

I have a suspect of why this happened, microcodes again, but in a different way. I'll confirm with the owner and report back.

 

[cdf]

I wonder why Apple doesn't update the SMC. It still got PCI and PS fan noise issue even with genuine GTX680 Mac Edition. I have to use Macs Fan Control to set the fans properly both under macOS and Windows. It only works well with Apple HD5770 and HD5870 cards. I don't know how about latest RX580 Radeons.

Perhaps the bug goes beyond the SMC. For the RX 580, you can also try AirOut.

 

[TheIguana]

Perhaps the bug goes beyond the SMC. For the RX 580, you can also try AirOut.

AirOut is an admirable solution, but the more folks that submit bug-reports to (https://bugreport.apple.com) on this the more likely we can get a permanent complete solution from Apple. Particularly those who have genuine 5,1 Macs that exhibit this problem.

 

[handheldgames]

AirOut is an admirable solution, but the more folks that submit bug-reports to (https://bugreport.apple.com) on this the more likely we can get a permanent complete solution from Apple. Particularly those who have genuine 5,1 Macs that exhibit this problem.

Hmmmm. Sounds like users digging for Apple to release a SMC update for the 5,1 that could be applied to all the 4,1's out there. Considering there's never been an update to the unique dual SMC in the 4,1/5,1 platform, perhaps there is a physical / hardware design issue that prevents both SMC's from being updated?

 

[cdf]

AirOut is an admirable solution, but the more folks that submit bug-reports to (https://bugreport.apple.com) on this the more likely we can get a permanent complete solution from Apple. Particularly those who have genuine 5,1 Macs that exhibit this problem.

I agree 100%. I was suggesting that perhaps the racing fan bug can't be resolved with only a firmware fix and that's why we haven't seen a solution from Apple. (Maybe there's also a hardware issue at play; otherwise all 5,1's would be affected.) In the interim we have solutions like Macs Fan Control and (for the RX 580) AirOut.

Edit: Just noticed @handheldgames alluded to something similar.