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.
That sounds like it should be crafted into a well written bug report.

I would but I avoided 0087 on all 3 Mac pros. If @tsialex indicated there was an issue with my ROM I would have submitted a copy as well as a full write up to Apple's bug reporter. Im just happy tracing the apple logo of my 2010 with lambs blood saved me from the curse of 0087.

My past suggestion for you to enter bugs were more of an inspirational message vs a perspiration oriented empowerment. LOL
 
I would but I avoided 0087 on all 3 Mac pros. If @tsialex indicated there was an issue with my ROM I would have submitted a copy as well as a full write up to Apple's bug reporter.

My past suggestion for you to enter bugs were more of an inspirational message vs a perspiration oriented empowerment. LOL
The mid-2010 BootROM 138.0.0.0.0 that you sent me was a clean one, with nothing to report.
 
  • Like
Reactions: handheldgames
I would but I avoided 0087 on all 3 Mac pros. If @tsialex indicated there was an issue with my ROM I would have submitted a copy as well as a full write up to Apple's bug reporter. Im just happy tracing the apple logo of my 2010 with lambs blood saved me from the curse of 0087.

My past suggestion for you to enter bugs were more of an inspirational message vs a perspiration oriented empowerment. LOL

I’ve actually written a plethora of bug reports. Apple has responded to some of them and (to my surprise) corrected an issue on one I filed a few weeks ago. I wish I had the technical knowledge that many people here have. I think the average user-submitted bug report gets dismissed as fluff.

I could be wrong, but I think that reports that contain substantial, and well described technical detail of the problem, speaks more directly to the engineer responsible for investigating the bug, and said bug is more likely to be properly addressed, instead of being passed over. The credibility and weight of the report (I would think) is greater when a written by someone whose knowledge obviously exceeds that of a user-drone such as myself.

The squeaky wheel DOES get the grease, but it has to squeak at the proper pitch to be heard.
 
Last edited:
No more swapping old video cards, this is too neat. Any chance we can flash the ROM on an RX 580 to get boot screens? Or with the current firmware this problem is solved?

Congrats.

My new 580 should be here tomorrow by noon.

There is absolutely no ROM you can flash onto this card for bootscreens at the moment. However, some very talented people on this very forum are working on the problem, and it many happen REASONABLY soon.u
 
Does this work with APFS? In the process of upgrading my 2009 with a Samsung SM951 AHCI.
Code:
sudo trimforce enable

Your mac pro deserves a much faster SSD. ;)
[doublepost=1534991685][/doublepost]
I’ve actually written a plethora of bug reports. Apple has responded to some of them and (to my surprise) corrected an issue on one I filed a few weeks ago. I wish I had the technical knowledge that many people here have. I think the average user-submitted bug report gets dismissed as fluff.

I could be wrong, but I think that reports that contain substantial, and well described technical detail of the problem, speaks more directly to the engineer responsible for investigating the bug, and said bug is more likely to be properly addressed, instead of being passed over. The credibility and weight of the report (I would think) is greater when a written by someone whose knowledge obviously exceeds that of a user-drone such as myself.

The squeaky wheel DOES get the grease, but it has to squeak at the proper pitch to be heard.

In an Irish accent....

I'm MORE than happy to help with any engineering technical mumbo jumbo to preserve the integrity of the Mac Pro's dilithium crystals.

tumblr_oz27hhT0cA1vbu4glo1_1280.gif
 
Last edited:
:) I miss Scotty... second officer and "miracle worker" chief engineer.

Agreed. A great inspiration for all. When I lived in Redmond WA, Mr. Duhan, aka Scotty, was a frequent shopper at my local grocery store. Coincidentally, before moving to WA, I used to run into Q, from the next-gen continuum shopping for groceries in South Pasadena.
 
Does a PRAM reset have any effect on a corrupted firmware?

zap-PRAM removes old logs and all the trash in the public area of the NVRAM. Nothing on the private part. The most serious problems, like SSN_HWC_SON block out of place or missing data, can't be resolved with zap-PRAM.

We need to extract the good data and insert that in the LOCKED.fd files. I "automated" the extraction/insertion process with UEFITool, but the cleanup of the SSN_HWC_SON block has to be done manually at the moment.

We need FD44Editor for Macs. FD44Editor is multiple platform and has a version that run on macOS, but for ASUS ROMs.
 
zap-PRAM removes old logs and all the trash in the public area of the NVRAM. Nothing on the private part.

So, not a bad idea to do PRAM reset once in a while just to clean things up. Maybe after an OS install

The most serious problems, like SSN_HWC_SON block out of place or missing data, can't be resolved with zap-PRAM.

We need to extract the good data and insert that in the LOCKED.fd files. I "automated" the extraction/insertion process with UEFITool, but the cleanup of the SSN_HWC_SON block has to be done manually at the moment.

We need FD44Editor for Macs. FD44Editor is multiple platform and has a version that run on macOS, but for ASUS ROMs.
 
So, not a bad idea to do PRAM reset once in a while just to clean things up. Maybe after an OS install

Bad won't do, but look at this binwalk from a MP61, 8 dupes of the same log/plist.
[doublepost=1535005505][/doublepost]I have a candidate, with triple log plist, to flash on my MP51. I'll zap-PRAM and do a dump to check if anything changes.
 

Attachments

  • Screen Shot 2018-08-23 at 02.56.26.png
    Screen Shot 2018-08-23 at 02.56.26.png
    572.6 KB · Views: 236
It’s ridiculous that this is so bad, it’s like we need a RomCleaner Utility for Mac.
I'm still trying to understand why this happens/what causes this. Maybe it's intentional, to preserve it.

8 times…
[doublepost=1535006112][/doublepost]I'm using binwalk a lot, it's easy to spot trouble with it. But binwalk definitively don't understand how to extract the NVRAM area. Every dump starts at the correct point but ends at the end of the BootROM.
 
Actually now that I think hard, I used the 10.13.6 updater for one flash, then ROMTool 1.0 for the second flash, then switched up to ROMTool 2.0 for 0138 if that helps any.

I still have another 2012 MP that I so far have only done 10.13.6, 0089, and DXE injected, want me to upload that too? And I'm pretty sure I only used ROMTool 1.0 on it.

Maybe switching versions of ROMTool did something?
 
Actually now that I think hard, I used the 10.13.6 updater for one flash, then ROMTool 1.0 for the second flash, then switched up to ROMTool 2.0 for 0138 if that helps any.

I still have another 2012 MP that I so far have only done 10.13.6, 0089, and DXE injected, want me to upload that too?
Yes, I want to disprove the twin factor that I thought earlier.
 
I'm still trying to understand why this happens/what causes this. Maybe it's intentional, to preserve it.

8 times…

I was thinking that too. Like a permanent DTC code in a vehicle ECM. A permanent code is stored for diagnostics until the error is resolved, and it remains in place for predetermined amount of cycles after error is cleared. This prevents the tech. from manually clearing the code after the repair of a long term error. That way if the error returns shortly afterwards, we know the actual problem wasn’t fixed, only the symptom of the current DTC trigger.

Possible something along those lines? Diagnostics?
 
  • Like
Reactions: highvoltage12v
Diagnostics?
It's definitively possible, but how macOS interacts with the dupes? On the MP6,1, seems a full NVRAM dupe.

What's start a dupe? Maybe at every BootROM upgrade the efiflasher duplicate the NVRAM? I need more trashcan dumps to check this, I've asked @CodeJingle to try to read the removed SPI memories from his delayered logic boards, if he still has any.
 
Hmmm... well earlier today I was thinking about Apple's coding of the check for FV2 being disabled before installing Mojave. I was wondering if they actually prevented it from being turned on after the install is complete. Sure enough, they absolutely do (as of PB6)--both via the GUI (System Preferences>Security & Privacy>FileVault) and via the "diskutil apfs encrypt" terminal command.

View attachment 777308
View attachment 777313
If they don't figure out a way to enable boot screens for the 560 & 580 then those blocks are almost 100% going to stay in place for the GM. If so, that will be a real hindrance to people who own a "Mac Edition" 7950 or GTX 680 (or one of the unofficial flashed versions of those cards), in addition to people like myself who paid big bucks for a MVC-flashed Maxwell card. Even though we *will* have boot screens on Mojave, it seems Apple will prevent us from using FileVault2 as well.

Just in case, can someone who is using a 7950 or GTX 680 with Mojave try enabling FileVault (if it even lets you--which I doubt--you can immediately cancel if you don't want to use it) just to make sure that Apple isn't somehow checking the installed GPU? I mean I really doubt they coded the block that specifically, but I am not able to test it since my only EFI card is a 750 Ti and there are no web drivers for Mojave yet.

Assuming users of those cards are also blocked from enabling FV, then I think this is yet another bug that should be reported. Apple should not be restricting that feature from users who have cards perfectly capable of using it.

There may be workarounds (like encrypting the drive on another Mac and then moving it back over to the cMP), but who knows if that could raise other issues as well.

This is really bad news for me. Looks like they are just going to leave FileVault2 off the table for cMP's.
 
It's definitively possible, but how macOS interacts with the dupes? On the MP6,1, seems a full NVRAM dupe.

What's start a dupe? Maybe at every BootROM upgrade the efiflasher duplicate the NVRAM?

This is a wild and probably stupid thought, but is it possible that it stores a copy to ensure a good flash, then upon success it’s supposes to clear the dupe but for some reason isn’t?

Or,

It keeps the last 2 copies, and when a newer flash is done, it pushes out oldest copy.

Just a thought...
 
If that's the probable intention, why 8 dupes?

Well, 8 copies of an entry, not the entire NVRAM right? Symptom of a different cause I would think. Along the lines of a stored DTC.

If either scenario is correct, it’s two different reasons.

This case may not be corruption at all, but something by design, but not yet understood.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.