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

[tsialex]

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

Wow, sorry for that. Seems something is wrong somewhere, but what?!?

 

[handheldgames]

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

Sounds like a great subject for a new post. I'm sure many people are interested in an early 2019 jump to a hackintosh .

 

[tsialex]

Anyone has a MATT card and a W3680 or W3690 to do a quick test?

 

[crjackson2134]

I’m going to order a MATT Card next payday for all new firmware flashing. Yes, it costs more than a logicboard, but in the long run I think it’s a good idea.

 

[tsialex]

Tested 142.0.0.0.0 with:

X5680:

X5677:

E5520:

 

[startergo]

Anyone has a MATT card and a W3680 or W3690 to do a quick test?

I got a matt card but I have X5690. That will be a different test. I can do the test when I come back from the field. Off topic: Is it possible to run type 1 hypervisor like ESXI on HS to get direct access to the hardware? Clients like Windows and HS?

 

[tsialex]

Off topic: Is it possible to run type 1 hypervisor like ESXI on HS to get direct access to the hardware? Clients like Windows and HS?

ESXI and if I remember correctly, Xen, but I’m not the right person to ask.

 

[tsialex]

Seems I already found what's going on with 142.0.0.0.0, I hope.

I need to do some more tests to confirm, but seems that the bricks are easily repairable.

 

[jbarley]

This just showed up on my Mac Pro 4,1/5,1 running Mojave 10.14.4 beta (18E194d)
current boot rom (140.0.0.0.0)

My question is, is it safe to allow the update to proceed?

 

[crjackson2134]

Seems I already found what's going on with 142.0.0.0.0, I hope.

I need to do some more tests to confirm, but seems that the bricks are easily repairable.

Once confirmed, I’ll updat my firmware bug report to include the details.
[doublepost=1551757167][/doublepost]

This just showed up on my Mac Pro 4,1/5,1 running Mojave 10.14.4 beta (18E194d)
current boot rom (140.0.0.0.0)

My question is, is it safe to allow the update to proceed?

View attachment 824757

Should be fine as long as you avoid firmware updates for now.

 

[tsialex]

Confirmed and totally reproducible. =)

I'll write up after I eat something.

 

[crjackson2134]

@tsialex has identified the problem.

I’ll make a detailed update to the firmware bug report in the ‘marrow.
[doublepost=1551758481][/doublepost]

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

No need to throw in the towel just yet, easy fix.
[doublepost=1551759755][/doublepost]I made a detailed report on the developers portal against firmware 142.0.0.0.0. I decided not to wait

 

[tsialex]

So I was intrigued how the first Mac Pro bricked. I have the exact, yes identical, Mac Pro config to the SPI flash model of the first brick EXCEPT that my Mac Pro have a X5680 Xeon and the one bricked by 142.0.0.0.0 have a W3680.

When the supposed bricked backplane was replaced and the Mac Pro booted again, the user sent me his reconstructed BootROM. I checked it fully, found nothing wrong. Flashed it to my single Mac Pro, if something was wrong I shouldn't boot from now on, but it booted perfectly. This didn't got me anything as where to start to investigate what was causing the bricks, just more questions.

Then @h9826790 "bricked" his Mac Pro and almost instantly I remembered that he has a single CPU Xeon too, a W3690. Maybe it's something related to the type of processor / or model related.

Hummmm, lets see if my Mac Pro boots with E5520.



E5520 boots 142.0.0.0.0. Jet plane sounds as expected with mismatched SMCs.

Let's test a X5677, maybe it's a multiplier thing.




Boots, so no big multiplier problem. If X5677 and X5680 boots, X5690 will boot too. Dual CPU Xeons are working fine.

Now it's time to test single CPU Xeons. I have just one here, the one that came from Apple with my 2009 single CPU, a W3540. Installed it on my 2009 single tray, no boot with 142.0.0.0.0. Ops, something is wrong here. Since I don't have another W3xxx Xeon at home, let's test if downgrading to 140.0.0.0.0 with another tray makes my Mac Pro working correctly with W3540 tray.



Yes! W3540 boots 140.0.0.0.0!

So, my W3540 Xeon and tray combo are correctly working, no fluke here. Now, just to confirm, let me upgrade from 140.0.0.0.0 to 142.0.0.0.0 with EfiFlasher method. Drumroll…

Brick.

Confirmed, W3xxx Xeons can't make POST with 142.0.0.0.0 BootROM. It's not really bricked, but can't work. Change the single CPU Xeon to a Dual CPU model like X5xxx/E5xxx/L5xxx and the Mac Pro resurrects again.

Apple probably made a mess with W3xxx initialisation code with 142.0.0.0.0.

 

[h9826790]

@tsialex has identified the problem.

I’ll make a detailed update to the firmware bug report in the ‘marrow.
[doublepost=1551758481][/doublepost]

No need to throw in the towel just yet, easy fix.
[doublepost=1551759755][/doublepost]I made a detailed report on the developers portal against firmware 142.0.0.0.0. I decided not to wait

Yeah, I know. Thanks for the info. I sold my dual CPU tray few months ago. So, need some time to get a X5690.

Update 1: Just found a E5520 for $1.2. Seems a better "recovery CPU" than X5690. I don't need that performance anyway. Once recovered, my W3690 will work again.

 

[tsialex]

I already changed the name of the thread to warn everyone that 142.0.0.0.0 bricks with W3xxx Xeons. I bet that people will flash 142.0.0.0.0 anyway…

 

[startergo]

Yeah, I know. Thanks for the info. I sold my dual CPU tray few months ago. So, need some time to get a X5690.

Update 1: Just found a E5520 for $1.2. Seems a better "recovery CPU" than X5690. I don't need that performance anyway. Once recovered, my W3690 will work again.

We can hope that if Apple (most probably) watch this thread will correct this issue in the official release of the Mojave and the boot ROM.

 

[crjackson2134]

I already changed the name of the thread to warn about W Xeon "bricks" with 142.0.0.0.0.

I bet that people will flash 142.0.0.0.0 anyway…

Perhaps not... It’s an inconvenience when it happens but not too hard to recover from.
[doublepost=1551762165][/doublepost]

We can hope that if Apple (most probably) watch this thread will correct this issue in the official release of the Mojave and the boot ROM.

Apple don’t need to watch the thread, they already have a very detailed developer bug report. I get responses on nearly a weekly basis. Someone has to make it happen, hopes and dreams don’t work.

 

[jbarley]

I already changed the name of the thread to warn about W Xeon "bricks" with 142.0.0.0.0.

Does the "W" in this post relate to the "W3520" in the following - 2.66 GHz Quad Core 45-nm Xeon W3520?
Trying to figure out what I've got here.

 

[tsialex]

Does the "W" in this post relate to the "W3520" in the following - 2.66 GHz Quad Core 45-nm Xeon W3520?
Trying to figure out what I've got here.

Yes, any W35xx or W36xx, Quad or Hexa.

 

[jbarley]

Yes.

Thank you, guess I'll wait a bit then.

 

[crjackson2134]

Thank you, guess I'll wait a bit then.

To be honest, NOBODY, regardless of processor, should upgrade to this firmware, unless you are beta testing, reporting, and prepared to recover from a bricked machine.

Even though you can use this firmware with X class XEONS, it’s proven to be buggy already and not worth the effort except for testing. This won’t be released as is, no worries.

 

[w1z]

Would be interesting to see which W intel processor family initialization code was pushed to the 5,1's bootrom... perhaps it was intended for the 7,1?

 

[tsialex]

To be honest, NOBODY, regardless of processor, should upgrade to this firmware, unless you are beta testing, reporting, and prepared to recover from a bricked machine.

Even though you can use this firmware with X class XEONS, it’s proven to be buggy already and not worth the effort except for testing. This won’t be released as is, no worries.

Works with any dual CPU Xeon, so X5xxx, E5xxx and L5xxx. I tested 142.0.0.0.0 with X5677, X5680 and E5520 earlier tonight.

142.0.0.0.0 don't work with any W35xx, W36xx and probably no i7 too.

 

[flowrider]

Yes, any W. Quad or Hexa. W35xx or W36xx.

Alex, be careful with that statement. Intel's numbering system changed when they went from the 35XX (55XX) to the 36XX (56XX) series. I posted the below 4½ years ago:

Well, Intel has changed what the leading Alpha means. The change happened when going from the 35XX (55XX) to the 36XX (56XX) series.

In the older series it meant:

E = Enterprise and CPUs with a TDP of 80 Watts
X = Accelerated and CPUs with a TDP of 95 Watts
W = Workstation and CPUs with a TDP of 130 Watts

and in every case the leading numeric after the alpha meant:

3 = for single CPU use only (1 x I/O Bus)
5 = for dual CPU use, but will work in single CPU applications (2 x I/O Bus)

With the later series, the above nomenclature rules stayed constant EXCEPT - The "X" prefix means accelerated (95 or 130 watt TDP) and is only used on CPUs with a 2 x I/O bus. The "W" prefix is now used only in the single CPU series (1 X I/O Bus).

In any case in both series, the meaning of leading numeric after the alpha has remained the same. A "3" for CPUs with a 1 x I/O bus and a "5" for CPUs with a 2 X I/O Bus.

I hope this makes sense to you. It took me awhile to figure it out.

From what I have been reading, Let's discount the leading "X" or "W" and concentrate on the leading numeric. It appears that the "5" CPUs are OK and the "3" CPUs are not.

Lou

 

[tsialex]

Alex, be careful with that statement. Intel's numbering system changed when they went from the 35XX (55XX) to the 36XX (56XX) series. I posted the below 4½ years ago:



From what I have been reading, Let's discount the leading "X" or "W" and concentrate on the leading numeric. It appears that the "5" CPUs are OK and the "3" CPUs are not.

Lou

W3540, W3680, W3690 don't work.

E5520, X5677, X5680 all confirmed working by me earlier tonight. Dual or Single CPU tray don't make difference. I bet L5xxx works too.

So, yes can be just a 3 thing. Someone with an i7 installed needs to confirm it.