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

[tsialex]

@tsialex Can you please point me where to seek for the dimm slot config?
View attachment 835392
Here is a difference between the two roms with the MemoryConfig explicitly defined.
googling for module description I have only found out that SaveMemoryConfig is responsiblefor writing the config to nvram, while MemorySubClass reads the currently installed DRAM config. So the only possible MemoryConfig -aware module in the firmware is the UncoreInitPeim. But inside the module is the hex config which I barely able to understand as you might see.

Since MP5,1 ROM successfully boots up on XS3,1 with the only issue being the 8 out of 12 RAM slots operational, I suppose that is easier fixing that isuue rather then trying adding the microcode etc. I currently have two quadcore logicbords to test with, and a dualcore logicboard on the way, and since I recently purchased a CH341a I am not afraid of bricking at least on of the mobo during such severe tests...

Sorry, but I'm not going to help with Xserve, this is non-negotiable.

I know that it's not fair with other Xserve people, but one bad Xserve user spoiled the bunch.

 

[tsialex]

Hi @tsialex, i couldnt send you a DM so ill try here.
i have a MP6,1
3,5 GHz 6-Core Intel Xeon E5

and MP5,1 Mid 2010
2 x 3.33 GHz 6-Core Intel Xeon
(which have win 7 and 10 on it (bios mode)) and wanted to share SPI dumps with you.

my SPI is MX25L3205D on cMP and dumped to a bin file.

but for MP61 where is this chip located? which one is right one?

flashrom MXIC multiple identification is not a problem for reading, you can use any of the three for reading the SPI flash. When writing it's best to identify the correct one, but it's not critical for Mac Pros (4,1/5,1/6,1). The problem with wrong MXIC happens with MacBooks and MacBooks Pro where you can brick with the wrong choice.

I'll send you a PM, then you can upload the dumps.

 

[LightBulbFun]

Sorry, but I'm not going to help with Xserve, this is non-negotiable.

I know that it's not fair with other Xserve people, but one bad Xserve user spoiled the bunch.

ohh thats a shame

I have an Xserve3,1 myself that I do plan to experiment with (I already got it running windows which was fun )

sadly its a bit of a big bastard and as im disabled, it means its quite hard for me to drag it out for experiments (first thing I really should do is install a socket for the BootROM EEPROM LOL)

 

[Mac Hammer Fan]

Does the 144.0.0.0.0. solves the 300 MHz clock speed problem of the Radeon RX 580 Sapphire Pulse in a MacPro 5,1?
GPU Clock should be 1257 MHz like in High Sierra.
Anyway, I am glad the firmware is now compatible with my W3680 Processor.

 

[tsialex]

Does the 144.0.0.0.0. solves the 300 MHz clock speed problem of the Radeon RX 580 Sapphire Pulse in a MacPro 5,1?
GPU Clock should be 1257 MHz like in High Sierra.
Anyway, I am glad the firmware is now compatible with my W3680 Processor.

Why a BootROM should solve this? BootROM can’t control GPU clocks or anything GPU related. This is a driver problem.

BootROM just do the POST and then transfer the control to the OS.

 

[zipgs]

@tsialex Can you please point me where to seek for the dimm slot config?
View attachment 835392
Here is a difference between the two roms with the MemoryConfig explicitly defined.
googling for module description I have only found out that SaveMemoryConfig is responsiblefor writing the config to nvram, while MemorySubClass reads the currently installed DRAM config. So the only possible MemoryConfig -aware module in the firmware is the UncoreInitPeim. But inside the module is the hex config which I barely able to understand as you might see.

Since MP5,1 ROM successfully boots up on XS3,1 with the only issue being the 8 out of 12 RAM slots operational, I suppose that is easier fixing that isuue rather then trying adding the microcode etc. I currently have two quadcore logicbords to test with, and a dualcore logicboard on the way, and since I recently purchased a CH341a I am not afraid of bricking at least on of the mobo during such severe tests...
[doublepost=1557061222][/doublepost]
According to this, it is the second option you might chose

This is just a display problem, all the RAM should be recognized and usable. At least it seems to be in ESXi which is what I have running, and from the terminal commands in macOS. With that said, this is not the only issue with the 5,1 firmware on an xserve.

 

[tsialex]

Continuing from #3307, #3308, #3311, #3314, #3355, #3360 and #3364.

Did some improvements with the MemoryConfig detection and removed the active/superseded indication. Some dumps have more complex MemoryConfigs and I have to investigate this more.

Now binwalk shows exactly where the 1st and 2nd streams of the NVRAM start, this is useful to know when you are checking for multiple MemoryConfigs. I'll implement the same for Fsys (3rd stream/store) and Gaid (4th stream/store) streams.

I'll probably gonna remove the MLB/LBSN and BD from the report, it's a security problem to upload it to the internet.
[doublepost=1557234121][/doublepost]Btw, more info about the matt clones here: #19

 

[tsialex]

Apple just released 10.14.5 DP5, I'm already downloading it to check the BootROM version.
[doublepost=1557250157][/doublepost]MP6,1 stil has 130.0.0.0.0:

$IBIOSI$ MP61.88Z.F000.B00.1904121119
Copyright (c) 2005-2019 Apple Inc.  All rights reserved.
Apple ROM Version
  Model:        MP61
  EFI Version:  130.0.0.0.0
  Built by:     root@saumon
  Date:         Fri Apr 12 11:19:25 PDT 2019
  Revision:     130 (B&I)
  ROM Version:  F000_B00
  Build Type:   Official Build, Release
  Compiler:     Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)

[doublepost=1557251203][/doublepost]Still 144.0.0.0.0 for MP5,1:

$IBIOSI$ MP51.88Z.F000.B00.1904121248
Apple ROM Version
  Model:        MP51
  EFI Version:  144.0.0.0.0
  Date:         Fri Apr 12 12:43:00 2019
  Build Type:   Release

 

[tsialex]

10.14.5 DP5 don't have updated BootROMs, same as 10.14.5 DP4, this table does not include BridgeOS Macs:

Mac:	EFI version:
IM13,1	285.0.0.0.0
IM14,1	137.0.0.0.0
IM14,2	137.0.0.0.0
IM14,3	137.0.0.0.0
IM14,4	197.0.0.0.0
IM15,1	228.0.0.0.0
IM16,1	227.0.0.0.0
IM16,2	227.0.0.0.0
IM17,1	166.0.0.0.0
IM18,1	172.0.0.0.0
IM18,3	172.0.0.0.0
IM19,1	220.260.170.0.0
MB10,1	175.0.0.0.0
MB8,1	181.0.0.0.0
MB9,1	181.0.0.0.0
MBA5,1	257.0.0.0.0
MBA6,1	115.0.0.0.0
MBA7,1	186.0.0.0.0
MBP10,1	255.0.0.0.0
MBP10,2	278.0.0.0.0
MBP11,1	153.0.0.0.0
MBP11,2	153.0.0.0.0
MBP11,4	192.0.0.0.0
MBP12,1	184.0.0.0.0
MBP13,1	233.0.0.0.0
MBP13,2	256.0.0.0.0
MBP13,3	256.0.0.0.0
MBP14,1	194.0.0.0.0
MBP14,2	194.0.0.0.0
MBP14,3	194.0.0.0.0
MBP9,1	226.0.0.0.0
MM6,1	278.0.0.0.0
MM7,1	242.0.0.0.0
MP5,1	144.0.0.0.0
MP6,1	130.0.0.0.0

 

[misanthrophy]

@tsialex Is there any advantage security/performance/reliability wise with the latest BootROM versions compared to 140? Or can people ignore these updates, as you will not experience any difference with the newer versions?

 

[flehman]

@tsialex Is there any advantage security/performance/reliability wise with the latest BootROM versions compared to 140? Or can people ignore these updates, as you will not experience any difference with the newer versions?

The latest BootROMS are “risky” to say the least because they are still associated with developer and public betas. Security-wise some past BootROMs have cleared CPU microcode. Performance/reliability wise - if flawed they have the potential to utterly hose the board unless the user has very specialized equipment to restore.

Consequently I am very thankful for Tsialex’s efforts to vet these updates - otherwise we might have no idea what is in them. They are a minefield and best to wait for them to be released as part of a public release.

 

[misanthrophy]

@flehman I have no intention to update now to the latest versions so far, exactly due to the risks of bricked MP's. I am just interested, if I should keep an eye on that topic, because it "makes my cMP better", or if the changes are so minor, that I can safely stay on 140 under High Sierra and do not need to think about an update in the near future. It is really just a matter of interest, not a matter of urge to update my BootROM.

 

[tsialex]

@tsialex Is there any advantage security/performance/reliability wise with the latest BootROM versions compared to 140? Or can people ignore these updates, as you will not experience any difference with the newer versions?

Cupertino firmware developers have been busy, they have been implementing minor corrections here and there with every BootROM release, but when you compare 140.0.0.0.0 to 144.0.0.0.0 a lot of things changed.

One of the things that seems corrected with 144.0.0.0.0 is the unbootable situation that some people here had once in a while but hit really hard @crjackson2134 and other user. A benign collateral effect of this bug correction seems to be a little bit faster boot times for some people, probably from the APFSJumpStart and SATA improvements.

10.14.5 final will be released soon, everyone then should download the full installer and run it to get the 14(4-5).0.0.0.0 firmware upgrade, but no one should install until the final release.

144.0.0.0.0 seems to be very stable with my Macs, but 142.0.0.0.0 was too and you already know about the bricks. Like I always say, don't install beta BootROMs if you don't have a way to reprogram the SPI flash or replace the backplane.
[doublepost=1557271409][/doublepost]Btw, Apple usually releases the 10.x.5 around the second week of May to the first week of June.

https://robservatory.com/a-useless-analysis-of-os-x-release-dates/

 

[tsialex]

I had to boot a UEFI W10 install today, to flash a GPU. I dumped my BootROM before and after.

With just two W10 boots, W10 asked for a restart to install a SecurityUpdate, I got two SecureBoot certificates after I got back to macOS:

Btw, I improved the VSS streams identification, now binwalk shows clearly where the first and second VSS stream starts.

Little steps

 

[Macschrauber]

A little bit off topic, but I use a FreeDos Installation on Mac. I copied the .iso to a spare spinner with DD to flash GPUs with Dos. Gives a very small partition so any Sata spinner will run...

 

[tsialex]

A little bit off topic, but I use a FreeDos Installation on Mac. I copied the .iso to a spare spinner with DD to flash GPUs with Dos. Gives a very small partition so any Sata spinner will run...

Sure, you can do the FreeDOS way too and it's a lot simpler.

I should posted that I wanted to check the SecureBoot certificates with 144.0.0.0.0 too, it's the first 144.0.0.0.0 dump with SecureBoot certificates, so I did the flashing with my Mac Pro knowingly that I would get the SecureBoot signing after booting my W10 UEFI install.

Btw, I usually flash GPUs with my PC, easier than disconnecting all my Mac Pro drives and installing my UEFI W10 disk.

 

[Spacedust]

It only happens with Windows 10 in UEFI mode. Windows 8.1 is not causing such issues.

So Windows 10 is not only a crappy OS, but also deadly for Mac Pro users. Future Windows versions might only have UEFI mode ;-)

Also it's not possible to flash GPU's in UEFI mode if there is no EFI rom on the card. Disabling the driver = no display.

As I've said instead of messing with bootrom, Apple should fix the SMC controller as PCI and PSU fans goes crazy with non-Apple graphics (flashed or non-flashed and even Mac Editions like HD7950 or GTX680).

 

[tsialex]

Apple should fix the SMC controller as PCI and PSU fans goes crazy with non-Apple graphics (flashed or non-flashed and even Mac Editions like HD7950 or GTX680).

This problematic behaviour of the fans is more common with 1.39f5, I doubt that Apple will change anything SMC related for MP4,1. They don't even look at radar reports for MP4,1 related problems.

If eventually Apple releases a new SMC version for MP5,1 or the 1.39f11 dump leaks, I bet that we can update MP4,1>5,1 too with ease.

 

[Spacedust]

That would be nice. One more software (MacFansControl) to remove on boot.

 

[Macschrauber]

I have the racing FAN issue with 140.0.0.0 / 1.39f11 and a flashed GTX680 on a Single W3670 CPU Board every few hours.

 

[macsforme]

If I swap my RAM modules into different slots (I’m trying to diagnose a bad RAM stick, or maybe a bad CPU, or something in between), does that have the potential to fill up the NVRAM with memory configurations and corrupt it? The sticks are all identical, and the RAM stick serial numbers do not appear to be passed through to macOS.

 

[crjackson2134]

If I swap my RAM modules into different slots (I’m trying to diagnose a bad RAM stick, or maybe a bad CPU, or something in between), does that have the potential to fill up the NVRAM with memory configurations and corrupt it? The sticks are all identical, and the RAM stick serial numbers do not appear to be passed through to macOS.

I wouldn't worry about the memory configuration entries in the NVRAM right now. We don't even know what their effect is just yet. I just flashed a clean, reconstructed, BootROM a few days ago. I've made NO changes to my system, and I now have 18 memory configuration files in my NVRAM.

Just troubleshoot your RAM and move on. That's all you can do for now...

 

[tsialex]

If I swap my RAM modules into different slots (I’m trying to diagnose a bad RAM stick, or maybe a bad CPU, or something in between), does that have the potential to fill up the NVRAM with memory configurations and corrupt it? The sticks are all identical, and the RAM stick serial numbers do not appear to be passed through to macOS.

No, the full NVRAM cases that we saw always had more than one problem. It's like 29 MemoryConfig entries + 2 SecureBoot certificates + very long IASInstallPhaseList logs. It's never just one thing.

For now, we are trying to understand what makes one Mac to have multiple entries and another one not. I have a practically identical Mac Pro as @crjackson2134, even to the same W3680 Xeon now, and I don't have his 18 memory config entries. Something is triggering this and that is what we want to find.

 

[MIKX]

... "We want to find out WHAT IS CAUSING THIS "

 

[Spacedust]

Does switching graphics cards, adding new PCI-express cards cause this? Mine should be dead already.