Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
The App Store date sorting bug has been resolved in High Sierra 10.13.6 17G5019. Purchased/downloaded apps no longer sort alphabetically.
It's not a 17G5019 correction, but something with the MAS backend. I had 17G5019 already installed into my home MP5,1 when I noticed, sometime later in the past week Apple corrected it.
 
It's not a 17G5019 correction, but something with the MAS backend. I had 17G5019 already installed into my home MP5,1 when I noticed, sometime later in the past week Apple corrected it.

Was not reporting 17G5019 was responsible for "fixing" this issue - just reporting where it was observed. Sorry for the confusion, if any.
 
  • Like
Reactions: tsialex
My experience so far with the 141 rom:

- Speed improvement (almost instantly) in recognizing and unlocking of APFS encrypted drives either during installation, filevault booting or mounting of encrypted APFS volumes/partitions within Mojave.
- Not sure if this is related but since updating to 141, I am no longer seeing fan errors in TG Pro under diagnostics.
- Stopped seeing intermittent 'bluetooth not available' errors

Anyway to verify this @tsialex?
 
My experience so far with the 141 rom:

- Speed improvement (almost instantly) in recognizing and unlocking of APFS encrypted drives either during installation, filevault booting or mounting of encrypted APFS volumes/partitions within Mojave.
- Not sure if this is related but since updating to 141, I am no longer seeing fan errors in TG Pro under diagnostics.
- Stopped seeing intermittent 'bluetooth not available' errors

Anyway to verify this @tsialex?
I don’t use encrypted disks or TG Pro, so I’m the wrong person to confirm this, sorry.

I have serious BT problems with Magic Mouse but I don’t think it’s related to BootROM in any way, nothing changed with 141.0.0.0.0.
 
  • Like
Reactions: w1z
After updating my cMP 5,1 (2 x 2,93 GHz 6-Core Intel Xeon) to Bootrom 140.0.0.0.0 and 10.14.3 no CD`s and DVD`s are mounted in my optical drives (Superdrive + BD-RE BH16NS40). Before the update it worked in any case. Does anyone else have any experience?
 
After updating my cMP 5,1 (2 x 2,93 GHz 6-Core Intel Xeon) to Bootrom 140.0.0.0.0 and 10.14.3 no CD`s and DVD`s are mounted in my optical drives (Superdrive + BD-RE BH16NS40). Before the update it worked in any case. Does anyone else have any experience?
This is unrelated to the BootROM. I mount and write CD/DVDs frequently to upgrade firmwares, did one yesterday.
 
Did yesterday a full row on a Single MP5.1 from
MP51.007F.B03, MP51.0089.B00 to 140.0.0.0
on a new built up MP and tested the Optical Drive of course without issues
 
Hi,

How big issue this really is? And do you know, how to possible fix it? I checked by MP 4.1 > 5.1 and found the same like you have :

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

1181901 0x1208CD Certificate in DER format (x509 v3), header length: 4, sequence length: 986

1247437 0x1308CD Certificate in DER format (x509 v3), header length: 4, sequence length: 986

1343538 0x148032 bzip2 compressed data, block size = 100k

1376256 0x150000 UEFI PI firmware volume



It's not a common occurrence, but again two IASInstallPhaseList.plists into a NVRAM:

View attachment 823480

Code:
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>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Software Update Post Logout</string>
        <key>InstallPhasePercentageKey</key>
        <integer>5</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Boot 1</string>
        <key>InstallPhasePercentageKey</key>
        <integer>8</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Language Chooser</string>
        <key>InstallPhasePercentageKey</key>
        <integer>2</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>OS Installer</string>
        <key>InstallPhasePercentageKey</key>
        <integer>3</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Boot 2</string>
        <key>InstallPhasePercentageKey</key>
        <integer>8</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Language Chooser 2</string>
        <key>InstallPhasePercentageKey</key>
        <integer>2</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>OS Installer 2</string>
        <key>InstallPhasePercentageKey</key>
        <integer>67</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Boot 3</string>
        <key>InstallPhasePercentageKey</key>
        <integer>5</integer>
    </dict>
</array>
</plist>

Code:
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>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Software Update Post Logout</string>
        <key>InstallPhasePercentageKey</key>
        <integer>5</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Boot 1</string>
        <key>InstallPhasePercentageKey</key>
        <integer>8</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Language Chooser</string>
        <key>InstallPhasePercentageKey</key>
        <integer>2</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>OS Installer</string>
        <key>InstallPhasePercentageKey</key>
        <integer>3</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Boot 2</string>
        <key>InstallPhasePercentageKey</key>
        <integer>8</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Language Chooser 2</string>
        <key>InstallPhasePercentageKey</key>
        <integer>2</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>OS Installer 2</string>
        <key>InstallPhasePercentageKey</key>
        <integer>67</integer>
    </dict>
    <dict>
        <key>ConclusionDelay</key>
        <integer>0</integer>
        <key>InstallPhase</key>
        <string>Boot 3</string>
        <key>InstallPhasePercentageKey</key>
        <integer>5</integer>
    </dict>
</array>
</plist>

This Mac Pro 1st/2nd streams of the NVRAM volume are almost full, even have GFXVENDOR setting and the binary blobs that block TITAN GPUs to work. I'd really like to understand what causes this.
 
Hi,

How big issue this really is? And do you know, how to possible fix it? I checked by MP 4.1 > 5.1 and found the same like you have :

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

1181901 0x1208CD Certificate in DER format (x509 v3), header length: 4, sequence length: 986

1247437 0x1308CD Certificate in DER format (x509 v3), header length: 4, sequence length: 986

1343538 0x148032 bzip2 compressed data, block size = 100k

1376256 0x150000 UEFI PI firmware volume

If you ever install a BootROM without microcodes, like MP51.0087.B00, it will brick your Mac, but this is a rare occurrence - probably an Apple error. Another problem is the space that the SecureBoot certificates use, NVRAM full volume is just 192KB, with a little less than half of that dedicated to store parameters and settings. Some people here got it totally full, but this happened at around 5 to 7% of the dumps I checked. So, to most people is relatively innocuous.

We can remove SecureBoot Certificates with BootROM reconstruction, but it's useless if you continue to use UEFI Windows.
 
Last edited:
DON'T FLASH 142.0.0.0.0 IF YOU HAVE A W3xxx XEON, ONLY WORKS WITH X5xxx, E5xxx and L5xxx XEONS.


With todays 10.14.4 DP4, Apple released MP5,1 BootROM 142.0.0.0.0:

  • Build date is 20190214,
  • BootBlock version is APLEFI1.88Z.0005.I00.1902142048,
  • CRC32 is 64e8f5ea,
  • Updated APFSJumpStart EFI module,
  • same microcodes as 138.0.0.0.0,
  • same NVMe EFI module as 140.0.0.0.0.
Code:
$IBIOSI$ MP51.88Z.F000.B00.1902142049
‰Apple ROM Version
  Model:        MP51
  EFI Version:  142.0.0.0.0
  Date:         Thu Feb 14 20:43:08 2019
  Build Type:   Release

MP51.142.microcodes.png
 
Last edited:
DON'T FLASH 142.0.0.0.0 IF YOU HAVE A W3xxx XEON, ONLY WORKS WITH X5xxx, E5xxx and L5xxx XEONS.

I already reconstructed 142.0.0.0.0 for my Mac Pro and it works, took a lot more time to do the first boot, normal after that.

Now it's time to try to find what Apple changed with this new release of the Mac Pro firmware.
MP51.142.HardwareOverview.edited.png
 
Last edited:
The bricked Mac Pro is a mid2012 and the user has another backplane to replace the bricked one, so in time he will get it back working.

What caused the brick is a mystery for now. That’s why you don’t upgrade to beta BootROMs, leave to the people that have spare backplanes or can desolder/reprogram the SPI flash memory/solder it back.

Be smart, don't risk your Mac Pro with beta BootROMs.
 
Last edited:
Trying to understand what caused the brick and so far I already:
  1. Flashed back 140.0.0.0.0 and upgraded to 142.0.0.0.0, worked
  2. Flashed my reconstructed 142.0.0.0.0 BootROM, worked.
So, I can't brick doing the normal upgrade path or the reconstruction one, so continues to be a mystery until the user send me a dump.
Blank_00.JPG
Blank_01.JPG
Blank_02.JPG
Blank_03.JPG
Blank_04.JPG
Blank_05.JPG
Blank_06.JPG
Blank_07.JPG
Blank_08.JPG
Blank_09.JPG
 
Trying to understand what caused the brick and so far I already:
  1. Flashed back 140.0.0.0.0 and upgraded to 142.0.0.0.0, worked
  2. Flashed my reconstructed 142.0.0.0.0 BootROM, worked.
So, I can't brick doing the normal upgrade path or the reconstruction one, so continues to be a mystery until the user send me a dump.View attachment 824593View attachment 824594View attachment 824595View attachment 824596View attachment 824597View attachment 824598View attachment 824599View attachment 824600View attachment 824601View attachment 824602

So, he try to upgrade from 140.0.0.0.0 (but not 141.0.0.0.0) to 142.0.0.0.0?
 
So, he try to upgrade from 140.0.0.0.0 (but not 141.0.0.0.0) to 142.0.0.0.0?
He flashed a 142.0.0.0.0 reconstruction over 141.0.0.0.0, but since it’s not an upgrade, don’t matter the previous installed version. I’ll check the dump after he gets the Mac Pro working, he is changing backplanes now.
 
Last edited:
  • Like
Reactions: w1z and h9826790
I checked the reconstruction that bricked the mid2012 and seems correct to me - everything are in the correct places and all checksums are correct. So, user error is not the smoking gun.

Could be SPI cell exhaustion, flashrom problems or something with 142.0.0.0.0. Since I didn't had any problems with the new BootROM, first and second options seems more plausible at the moment.
 
Last edited:
I checked the reconstruction that bricked the mid2012 and seems correct to me - everything are in the correct places and all checksums are correct. So, user error is not the smoking gun.

Could be SPI cell exhaustion, flashrom problems or something with 142.0.0.0.0. Since I didn't had any problems with the new BootROM, first and second options seems more plausible at the moment.

I just test that with my cMP. Use native Apple way to update from 141.0.0.0.0 to 142.0.0.0.0.

Firmware update looks normal. Super drive tray open, after a few seconds, self shutdown, and auto power up again. But unable to POST, so cMP bricked.

So, something wrong with 142.0.0.0.0. Recommend all users avoid that (unless have a way to recover).

N.B. I have no intention to fix my cMP this time, my Hackintosh is fully ready to take over. So, finally, it's time to move on :D
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.