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

[tsialex]

So my CPU is a W3565, my currentBoot ROM Version is 138.0.0.0.0.

Can I update to 144.0.0.0.0 using the guide on Post #3402 without any problems?
I'm a little bit confused about the problems with bricking my Xeon reported in this thread.

Thanks in advance

Yes. Only 142.0.0.0.0 don't work with W3xxx Xeons.

 

[LucMac]

Yes. Only 142.0.0.0.0 don't work with W3xxx Xeons.

Ok, I'm downloading it rn via Appstore / System Update function. When i proceed it, i will not see anything because of my RX 580 right?

 

[tsialex]

Ok, I'm downloading it rn via Appstore / System Update function.

Read the first post MP5,1: What you have to do to upgrade to Mojave (BootROM upgrade instructions).

When i proceed it, i will not see anything because of my RX 580 right?

Since MP51.0089.B00 to 138.0.0.0.0 upgrade; efiflasher shows only a blank screen during upgrade, no more progress indicator.

 

[jscipione]

So my CPU is a W3565, my currentBoot ROM Version is 138.0.0.0.0.

Can I update to 144.0.0.0.0 using the guide on Post #3402 without any problems?
I'm a little bit confused about the problems with bricking my Xeon reported in this thread.

You may update to the 144.0.0.0.0 ROM in 10.14.5 with a W3565 Xeon and not brick your Mac Pro, just not 142.0.0.0.0 which was only available on beta releases.

 

[MisterAndrew]

People who worry too much about hyper-threading flaw or the newly discover intel vulnerabilities should probably take a look at this article

That's interesting, but I think it belongs in the Politics, Religion, Social Issues forum.

 

[flowrider]

So my CPU is a W3565, my currentBoot ROM Version is 138.0.0.0.0.

Can I update to 144.0.0.0.0 using the guide on Post #3402 without any problems?
I'm a little bit confused about the problems with bricking my Xeon reported in this thread.

Thanks in advance

Yes, you can. The bricking issue involving W3XXX cpus was only associated with BootROM V142.0.0.0.0 which was never released into the wild. It was Beta only. FW144.0.0.0.0 is safe and you should upgrade.

Lou

 

[Woof Woof]

What the ever loving cluck!

I had posted earlier that I had installed Win 10 accidentally as UEFI (later reinstalled as legacy boot) and got two boot certificates in the boot rom. Recently I have been tinkering with Ubuntu, and installed it on another drive. This morning I decide to check and see if Ubuntu added anything...

The certs are gone. Both of them. Did installing Ubuntu clean up the certificates????

 

[bsbeamer]

What the ever loving cluck!

I had posted earlier that I had installed Win 10 accidentally as UEFI (later reinstalled as legacy boot) and got two boot certificates in the boot rom. Recently I have been tinkering with Ubuntu, and installed it on another drive. This morning I decide to check and see if Ubuntu added anything...

The certs are gone. Both of them. Did installing Ubuntu clean up the certificates????

Did you install/use Bionic Beaver (18.04) or Disco Dingo (19.04)? Not sure it would make a difference, but may help with people trying to replicate.

 

[Woof Woof]

Did you install/use Bionic Beaver (18.04) or Disco Dingo (19.04)? Not sure it would make a difference, but may help with people trying to replicate.

I was messing with thunderbolt, and wanted the latest patches. I installed 19.10 daily (Eoan Ermine) http://cdimage.ubuntu.com/daily-live/current/

I burned the ISO as a DVD from Windows (Disk Utility refused to burn it even after doing the ISO->CDR trick). Here is where my memory gets fuzzy. When you option boot the mac to pick a voume, that DVD shows two partitions, EFI and Windows (just like the Win 10 DVD). I can't remember what I picked... I think I picked Windows (It thinks Linux is Windows as far as option boot is concerned)

I am not a Linux expert by any means, but one thing I would warn against is to remove any other drives from the system before installing. The Ubuntu installer may go on the hunt for an EFI partition to put grub on, and one time it tried to use my High Sierra NVME EFI partition to put it on.

Also, installed ukuu, and then replaced the kernel with 5.2rc6 (you have to enable the options to show and install test versions) I have no idea when the certs disappeared, and installing the later kernel may have nothing to do with it.

I am not sure, but when I tried the shareware version of ukuu, it refused to install. I suspect that since the author has gone to a paid model, installing the shareware version might fail on newer/test versions of Ubuntu. The reddit r/macpro mod had used the shareware ukuu to install 5.2rc6 kernel on 18.04 without problems

Here is the dump from binwalk before installing Ubuntu:

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
1183976       0x1210E8        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1249512       0x1310E8        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

And here it is after Ubuntu/ukuu

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

 

[Darkvader75]

Just went from 138 to 144 with new full download no problem.

 

[tsialex]

I was messing with thunderbolt, and wanted the latest patches. I installed 19.10 daily (Eoan Ermine) http://cdimage.ubuntu.com/daily-live/current/

I burned the ISO as a DVD from Windows (Disk Utility refused to burn it even after doing the ISO->CDR trick). Here is where my memory gets fuzzy. When you option boot the mac to pick a voume, that DVD shows two partitions, EFI and Windows (just like the Win 10 DVD). I can't remember what I picked... I think I picked Windows (It thinks Linux is Windows as far as option boot is concerned)

I am not a Linux expert by any means, but one thing I would warn against is to remove any other drives from the system before installing. The Ubuntu installer may go on the hunt for an EFI partition to put grub on, and one time it tried to use my High Sierra NVME EFI partition to put it on.

Also, installed ukuu, and then replaced the kernel with 5.2rc6 (you have to enable the options to show and install test versions) I have no idea when the certs disappeared, and installing the later kernel may have nothing to do with it.

I am not sure, but when I tried the shareware version of ukuu, it refused to install. I suspect that since the author has gone to a paid model, installing the shareware version might fail on newer/test versions of Ubuntu. The reddit r/macpro mod had used the shareware ukuu to install 5.2rc6 kernel on 18.04 without problems

Here is the dump from binwalk before installing Ubuntu:

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
1183976       0x1210E8        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1249512       0x1310E8        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

And here it is after Ubuntu/ukuu

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

Your binwalks are from the same day, or you did install 144.0.0.0.0 in between?

 

[Woof Woof]

Your binwalks are from the same day, or you did install 144.0.0.0.0 in between?

The ROM captures were 10 days apart, I just did the binwalks today. 144 was on the machine before the first ROM capture.

I do need to correct one thing... I believe the first ROM capture was right BEFORE I installed Windows 10 1903 as MBR (formerly UEFI).

So, I guess there is the possibility that installing Windows 10 MBR could have cleaned up the certs?

 

[atonaldenim]

When you install W8.1 EFI or W10 EFI, Microsoft signs your EFI firmware. It's a security measure, to detect modifications into your BootROM. This is done by a X509 certificate, Microsoft Windows Secure Boot Variable Signer, stored into one of the private parts of the NVRAM.

Now that the dust has settled a little bit, I wanted to clarify the current situation with BootROM 144.0.0.0.0 and Windows UEFI corruption. I've read and searched through most of this thread and haven't been able to find a definitive answer...

Is it still the case that Windows 8.1 and Windows 10 are considered "unsafe" to use in UEFI mode, with BootROM 144.0.0.0.0? I'm assuming so, but just wanted to confirm since I saw some posts that suggested it might have been an issue specific to pre-Mojave BootROM versions.

What's the most recent version of Windows that can be considered "safe" to run in UEFI mode, if any? Windows 8, Windows 7? Any specific Service Pack versions etc?

I've successfully installed Windows 10 in legacy BIOS mode from DVD on my MP 2010 (144.0.0.0.0) with Radeon HD 7950 Mac edition, no Boot Camp. However my MP 2009 4,1 > 5,1 (144.0.0.0.0) with Radeon HD 5770 Mac edition doesn't seem to work at all with Windows 10 in legacy BIOS mode. It seems like this Mac EFI card doesn't have any PC BIOS support? I can't even get the message "Press any key to boot from CD..." to appear when trying to boot off the Win10 DVD in legacy BIOS mode. However if I boot from "EFI BOOT" on the same DVD, the Windows installer appears and everything works normally with the HD 5770 Mac edition. (Putting the Radeon 7950 into that 4,1 > 5,1 does make legacy BIOS Windows work on that machine.) I also tried a Windows 8.1 DVD, same thing.

So I'm wondering if there's a "safe" way to boot into Windows (in UEFI mode or otherwise) with the Radeon HD 5770 Mac edition, without endangering my EFI. I saw in post #1973 @tsialex suggest Windows installed via Boot Camp Assistant would not have this EFI corruption issue? Would Boot Camp Assistant be a "safe" way to install Windows 8.1 / 10 with the Radeon 5770 Mac? (Nevermind the many other problems with Boot Camp!)

Thanks everyone and especially @tsialex for all your hard work on this problem!

 

[tsialex]

Now that the dust has settled a little bit, I wanted to clarify the current situation with BootROM 144.0.0.0.0 and Windows UEFI corruption. I've read and searched through most of this thread and haven't been able to find a definitive answer...

Is it still the case that Windows 8.1 and Windows 10 are considered "unsafe" to use in UEFI mode, with BootROM 144.0.0.0.0? I'm assuming so, but just wanted to confirm since I saw some posts that suggested it might have been an issue specific to pre-Mojave BootROM versions.

What's the most recent version of Windows that can be considered "safe" to run in UEFI mode, if any? Windows 8, Windows 7? Any specific Service Pack versions etc?

I've successfully installed Windows 10 in legacy BIOS mode from DVD on my MP 2010 (144.0.0.0.0) with Radeon HD 7950 Mac edition, no Boot Camp. However my MP 2009 4,1 > 5,1 (144.0.0.0.0) with Radeon HD 5770 Mac edition doesn't seem to work at all with Windows 10 in legacy BIOS mode. It seems like this Mac EFI card doesn't have any PC BIOS support? I can't even get the message "Press any key to boot from CD..." to appear when trying to boot off the Win10 DVD in legacy BIOS mode. However if I boot from "EFI BOOT" on the same DVD, the Windows installer appears and everything works normally with the HD 5770 Mac edition. (Putting the Radeon 7950 into that 4,1 > 5,1 does make legacy BIOS Windows work on that machine.) I also tried a Windows 8.1 DVD, same thing.

So I'm wondering if there's a "safe" way to boot into Windows (in UEFI mode or otherwise) with the Radeon HD 5770 Mac edition, without endangering my EFI. I saw in post #1973 @tsialex suggest Windows installed via Boot Camp Assistant would not have this EFI corruption issue? Would Boot Camp Assistant be a safe way to install Windows 8.1 / 10 with the 5770? (Nevermind the many other problems with Boot Camp!)

Thanks everyone and especially @tsialex for all your hard work on this problem!

Windows 8.1 + 10 when installed with UEFI mode have Secure Boot signing.

If you do a CSM install you won't have Secure Boot signing and can use iMac Pro BootCamp drivers to go back to and from macOS, read here how to install: https://forums.macrumors.com/thread...ut-a-boot-screen.2114788/page-9#post-26689280

 

[startergo]

If you do a CSM install you won't have Secure Boot signing and can use iMac Pro BootCamp drivers to go back to and from macOS

So far the only difference I see between the UEFI and CSM boots are the secure boot certificates, which are on purpose. Whether they protect the boot or not is a different question.
"This is because all Secure Boot does, really, is establish trust that the files you are booting from have not been maliciously altered... which you can pretty much establish yourself if you validated the checksum of the ISO and ran your media creation from an environment that you trust."
" Microsoft have arbitrarily decided that they would not sign anything that is GPLv3 under the false pretence that it would force them to relinquish their private signing keys.
Of course, this is hyperbolic nonsense since all the GPLv3 mandates is that your system cannot lock users out from running their own code if they choose so, which, as long as you follow the UEFI guidelines, Secure Boot should never do, as it has clear provisions for allowing users to install their own keys."
"Instead, Secure Boot should more accurately have been called Bootloader Signature Enforcementbecause that is really what (and only what) it does, which is different from trying to protect your computer's security."

 

[tsialex]

So far the only difference I see between the UEFI and CSM boots are the secure boot certificates, which are on purpose. Whether they protect the boot or not is a different question.
"This is because all Secure Boot does, really, is establish trust that the files you are booting from have not been maliciously altered... which you can pretty much establish yourself if you validated the checksum of the ISO and ran your media creation from an environment that you trust."
" Microsoft have arbitrarily decided that they would not sign anything that is GPLv3 under the false pretence that it would force them to relinquish their private signing keys.
Of course, this is hyperbolic nonsense since all the GPLv3 mandates is that your system cannot lock users out from running their own code if they choose so, which, as long as you follow the UEFI guidelines, Secure Boot should never do, as it has clear provisions for allowing users to install their own keys."
"Instead, Secure Boot should more accurately have been called Bootloader Signature Enforcementbecause that is really what (and only what) it does, which is different from trying to protect your computer's security."

One of the users here, that works for MS, opened a bug report about Secure Boot signing EFI Macs when it shouldn't since it's a UEFI resource. This report was accepted but not answered yet, AFAIK.

From my perspective, MS shouldn't sign EFI firmwares at all. Let's see what will be the answer from MS.

 

[atonaldenim]

Windows 8.1 + 10 when installed with UEFI mode have Secure Boot signing.

If you do a CSM install you won't have Secure Boot signing and can use iMac Pro BootCamp drivers to go back to and from macOS, read here how to install: https://forums.macrumors.com/thread...ut-a-boot-screen.2114788/page-9#post-26689280

Thank you, yes I did follow that exact guide which worked pretty well using my Radeon 7950 Mac ed. However I can’t proceed past step 3 of that guide with a Radeon 5770 Mac ed, just get a black screen when booting from the DVD, no Windows installer. Only by booting the Windows DVD with “EFI Boot” can I get any video to see the Windows installer with the 5770 Mac EFI card. That’s why I was wondering if I could safely use Windows “EFI Boot” mode with a version prior to 8.1. Would Windows 8 be okay to use in “EFI Boot” mode if it doesn’t use Secure Boot? Thanks again!

EDIT: added screenshot for clarification

 

[tsialex]

Thank you, yes I did follow that exact guide which worked pretty well using my Radeon 7950 Mac ed. However I can’t proceed past step 3 of that guide with a Radeon 5770 Mac ed, just get a black screen when booting from the DVD, no Windows installer. Only by booting the Windows DVD with “EFI BOOT” can I get any video to see the Windows installer with the 5770 Mac EFI card. That’s why I was wondering if I could safely use Windows “EFI BOOT” mode with a version prior to 8.1. Would Windows 8 be okay to use in “EFI BOOT” mode if it doesn’t use Secure Boot? Thanks again!

You should ask on the How to: Boot Camp without a Boot Screen, people there will have better suggestions than here.

Anyway, find what's the problem you have with W10 CSM mode and correctly install it. Windows 7 64 EFI mode don't work with MP5,1, AFAIK. Windows 8 will be upgraded to 8,1 and you will have the same problems down the road.

 

[watakoola]

So my CPU is a W3565, my currentBoot ROM Version is 138.0.0.0.0.

Can I update to 144.0.0.0.0 using the guide on Post #3402 without any problems?
I'm a little bit confused about the problems with bricking my Xeon reported in this thread.

Thanks in advance

Simple answer: Yes!
Thanks to Alex and others in this thread - especially when I read about NOT using the 142.0.0.0. firmware update on my W3565 processor. That would have been rather…awkward!

I upgraded my (Mac Pro 5.1 running 10.4.5 with Radeon RX 580 graphics card) firmware from 138.0.0.0.0 to 144.0.0.0.0 by disabling the ‘Automatic Downloads’ in System preferences and downloading the full Mojave installer and then installing the firmware. All done and dusted in a few minutes.

Boot does appear to be marginally faster!

 

[krishnaM]

I upgraded the firmware to 144 and installed osx Mojave and was able to disable hyper threading. I can see that hyper threading is disabled in 'About this mac/system report' in Mojave but when I log in to drive with osx High Sierra the 'system report doesn't show info about hyper threading. Is that normal? I just want to make sure that hyper threading is disabled while I am using HS. Is there any other way to confirm hyper threading is disabled?

 

[tsialex]

I upgraded the firmware to 144 and installed osx Mojave and was able to disable hyper threading. I can see that hyper threading is disabled in 'About this mac/system report' in Mojave but when I log in to drive with osx High Sierra the 'system report doesn't show info about hyper threading. Is that normal? I just want to make sure that hyper threading is disabled while I am using HS. Is there any other way to confirm hyper threading is disabled?
View attachment 845706

Lot's of ways. The easiest is just to open Activity Monitor>Cpu Usage. With just one hexa core Xeon and with HT disabled, you will see just six cores.

 

[krishnaM]

Sorry, where to look for the cores?? I am not a computer expert

 

[tsialex]

Sorry, where to look for the cores?? I am not a computer expert

View attachment 845733

Activity Monitor, menu Window, CPU Usage. With just one hexa core Xeon and with HT disabled, you will see just six cores. With HyperThreading active, 12 cores.

 

[krishnaM]

Thanks

 

[kais58]

So I'm trying to upgrade my Mac Pro to latest firmware, ahead of going to Catalina later this year, I've got my 4.1 to MP51.007F.B03 but I'm already running Mojave, so the high sierra installer won't run to update to the next one, can I go direct to 144 using the Mojave installer ? I have a W3XXX series CPU but don't think that matters for 144 and can use either my GT120 or RX560 for installs.