Toggle sidebar Toggle sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MP 1,1-5,1 cMP 5,1 - diagnose power-on-self-test OR no POST with Nvidia M40 Tesla

D

dizco

macrumors newbie
Original poster
good morning y'all,

as the title suggests, I try to run an Nvidia Tesla M40 GPU accelerator in my cMP 5,1. The card is not supposed to work in macOS, but should work in Linux, after the boot issue is fixed.

The main issue: With the M40 card installed, the MacPro does not POST at all. No "chime".

This is what I have and what I tried so far:
  • cMP 5,1 with 144.0.0.0.0 vanilla firmware
    • minimal setup, 1 RAM stick, 1 HDD, boots High Sierra, OC installed on main disk in DEBUG mode
  • PCIe slot 1: GT120 GPU (alternative: Radeon HD 6770)
  • PCIe slot 2: Nvidia Tesla M40, Pixlas-Mod applied with 8-pin CPU power connector
    • M40 with vanilla vBIOS
    • M40 with updated GOP part in vBIOS via GOPupd
    • M40 with w/o the GOP part (see this German thread)
    • PCIe pins 5&6 for SMBus "disabled" as shown in this video
Any combination of the variants above will result in the same behavior:
  • MacPro turns on, diagnose LED "SYS PG" comes on, stays on all the time
  • diagnose LEDs "GPU OK" and "EFI DONE" light up shortly
  • 10 seconds, disk seeking, quiet
  • diagnose LEDs "GPU OK" and "EFI DONE" light up shortly
After this sequence, nothing happens. No boot loop, no chime. Without the M40 card, the chime will go off and system starts booting the EFI part from disk.
Unfortunately, even if the failing POST gets recorded, I can not access the result. The next time I boot the system w/o the M40, the POST result is "passed" in system information diagnostic.

I dumped the MacPro bootrom and also had a look at the bootrom templates from this thread: Guide: How to rebuild/update Mac Pro 4.1/5.1 bootrom with template files.

Is there a way to diagnose the power-on-self-test part of the internal bootrom, so I get an idea what's blocking the boot process? Any custom DXE driver, like EnableGop, which will record the POST failure, or ignore the M40 card during POST?
 
  • Like
Reactions: keksikuningas
Thanks Borowski, this is very interesting.
Here is my new train of thoughts:

I'm still very mich interested in the process of
diagnose the power-on-self-test part of the internal bootrom
Click to expand...

However, I understand the risk of modifying the MacPro's bootrom with the chance of bricking it. I followed the guide linked above and flashed a virgin firmware with EnableGop embedded. This worked like a charm, but the system still does not come up with the M40 installed.

the solution for the non-posting MP4.1+5.1 if a Navi-card is installed
Click to expand...
This seems the much better approach. The M40 can flashed easily in my Windows workstation, even with experimental firmware ;-)

Here is what I did:
  • Load the M40 firmware into ImHex and applied this pattern file (reddit post).
    • This shows all the different parts of the firmware
  • Extract the compressed EFI rom part from the M40 firmware
    • EFIRomHeader struct 0xFA00 to 0x2135E
  • Extract/Decompress the EFI part from the compressed output with UEFIRomExtract
  • I used Ghidra to load the uncompressed EFI part and Ghidra detected it as a x86/64 binary. It produces what looks like a sane listing of x86 instructions.
Here is where my expertise ends and following are my questions:
  • is the "problem" I'm looking for (M40 rom blocking the boot process) part of the EFI rom dump at all?
  • Does the M40 expect a UEFI 2.x environment and tries to query UEFI 2.x protocols, like in the linked example?
  • Where would I look for the calls to the UEFI 2.x protocols in the M40 rom dump?
Extended questions:
  • I found this discussion, regarding a
    Code: 
    FakeEdk2Driver ... to hack the EFI version to be 2.x
    .
    • Can this be integrated into the MacPro's bootrom, like EnableGop, if I know no other component would query EFI 2.x and fail in the process?
    • This moves me closer to a bricked bootrom, but sounds tempting 😀
Thanks for everyone reading and I hope you folks have some more input for me.
 
dizco said:
However, I understand the risk of modifying the MacPro's bootrom with the chance of bricking it. I followed the guide linked above and flashed a virgin firmware with EnableGop embedded. This worked like a charm, but the system still does not come up with the M40 installed.
Click to expand...

If the card prevents the Mac Pro to start with removed GOP driver (you already flashed a modified rom without GOP), it'll be an issue with the VGA-bios. No need to inject EnableGOP to your bootrom, this will change nothing at all.
 
  • Like
Reactions: dizco
I have a new observation to add:

Out of desperation and after good discussion with my friend Waldo (beer was involved), I force-flashed the vBIOS of an Nvidia Titan X onto the M40. Some forums suggested, it might come close.
Here we go: the M40 with Titan X rom boots the MacPro. Chime, boot picker and under Linux, an "lspci" shows the card.
The system is super unstable however*. But this proves, the Titan X vBIOS has what it takes to make the combo POST.

If I concentrate on the VGA part of the BIOS, is there a know way of "combining" both roms? There are plenty of offsets and pointers in the BIT section which might need adoption. Any hints if this is the right direction?

*) the nvidia drivers (version 580) recognize see the card, but fail to initialize. Which I find not unusual, I think the card gets initialized with some unhealthy parameters...
 
Difficult project.
To my knowledge, nVidia started w/ Maxwell using the "Falcon" security co-processor, which will protect the firmware from modifications. Imho there is zero chance for a working mod, if you're not an engineer from nVidia, since we still don't know the exact reason why the MP can't POST.
dizco said:
Chime, boot picker and under Linux, an "lspci" shows the card.
Click to expand...
Bootpicker without video connectors? 😉
 
Success!
In the end, it was easy to get the card running in the cMP 5,1. This thread on LinusTechTips suggests to either flash a Titan X vBIOS (as I did before) OR to flash a Quadro M6000 vBIOS. The later has 2 advantages over the Titan X:
  • The Quadro M6000 also comes in a 24GB variant (as is my Tesla M40)
  • It works 😉
I flashed this Quadro M6000 vBIOS from TechPowerUp using OMGflash on a Windows box using the follwowing command:

Code: 
OMGflash.exe -i1 -p --overridesub Quadro.M6000.rom

  • -i1 for the 2nd Nvidia GPU in the system
  • -p to ignore the not connected additional 8-pin CPU power
  • --overridesub to allow overriding the mismatching subsystem ID
The MacPro starts up and Linux loads all Nvidia drivers (version 580.159.03) for the M40. nvidia-smi then shows the M40 correctly with all 24GB detected.
Subsequent ollama install and running qwen3.6:27b utilizes the card quite well.

I learned a lot along the way, spent way too much time in HEX editors and learning (U)EFI basics. Fun times 😀
 
  • Like
Reactions: keksikuningas, reader50 and Borowski
dizco said:
Success!
In the end, it was easy to get the card running in the cMP 5,1. This thread on LinusTechTips suggests to either flash a Titan X vBIOS (as I did before) OR to flash a Quadro M6000 vBIOS. The later has 2 advantages over the Titan X:
  • The Quadro M6000 also comes in a 24GB variant (as is my Tesla M40)
  • It works 😉
I flashed this Quadro M6000 vBIOS from TechPowerUp using OMGflash on a Windows box using the follwowing command:

Code: 
OMGflash.exe -i1 -p --overridesub Quadro.M6000.rom

  • -i1 for the 2nd Nvidia GPU in the system
  • -p to ignore the not connected additional 8-pin CPU power
  • --overridesub to allow overriding the mismatching subsystem ID
The MacPro starts up and Linux loads all Nvidia drivers (version 580.159.03) for the M40. nvidia-smi then shows the M40 correctly with all 24GB detected.
Subsequent ollama install and running qwen3.6:27b utilizes the card quite well.

I learned a lot along the way, spent way too much time in HEX editors and learning (U)EFI basics. Fun times 😀
Click to expand...
nice! how many t/s in qwen3 ?
 
qwen3.6:27B on ollama:
  • consumes 20GB, 100% GPU
  • prompt eval rate: 17.48 t/s
  • eval rate: 6.8 t/s

qwen3.6:35b on ollama:
  • consumes 24GB, 91% GPU, 9% CPU*
  • prompt eval rate: 44.2 t/s
  • eval rate: 23.92 t/s

*) 2x Quad-Core Xeon E5620@2.4GHz and 96GB ECC RAM
 
dizco said:
qwen3.6:27B on ollama:
  • consumes 20GB, 100% GPU
  • prompt eval rate: 17.48 t/s
  • eval rate: 6.8 t/s

qwen3.6:35b on ollama:
  • consumes 24GB, 91% GPU, 9% CPU*
  • prompt eval rate: 44.2 t/s
  • eval rate: 23.92 t/s

*) 2x Quad-Core Xeon E5620@2.4GHz and 96GB ECC RAM
Click to expand...
...wow this is pretty damn good for the age of the hardware. and that's on ollama which is afaik worse than llama.cpp. I really want to try this on my cMP5,1 but sadly would need to sit down and do Pixlas mod first. Would be sick to have 2 of these or even P40 in such an ancient tower for local LLM (oh god the heat)
 
Thanks for the detailed input — very helpful.
Good to know that 2xxx-series cards didn't require HII and worked with factory pre-boot config. That changes my working theory a bit; I was assuming an HII/UEFI 2.3.1 incompatibility was the main blocker, but if Turing as a generation doesn't need that, the cause might be elsewhere.

A few more details and follow-up questions, since my symptom is a bit different from the M40 case in the thread you linked:
In my case the system actually chimes and boots normally — the only issue is the display itself stays completely black, even at the OpenCore picker stage (no hang, no failed POST, just no video output). I already have EnableGOP1.4 (the version from Macschrauber) flashed to the Mac Pro's mainboard ROM, so the board side should be covered — this points more toward a GPU vBIOS or OpenCore-config issue rather than a board-firmware one.

I also checked OCLP's "Nvidia GOP Injection" option, but it's documented as Kepler-specific (and OCLP's Legacy Nvidia patching generally only covers Tesla through Fermi/Maxwell/Pascal) — so that doesn't apply to a Turing card like mine. I checked through the current 2.4.1 release and changelog history, no Turing GOP support listed anywhere. Just wanted to confirm there's no equivalent path for Turing in OCLP before ruling it out.

Questions:
Would a Titan RTX cross-flash address this kind of "chime but no GOP/no picture" symptom, or is that a different failure mode than the M40's "no POST at all" problem?
For the Titan RTX firmware route — do you know of a source/version that's a good match for a Quadro RTX 6000 Founders Edition specifically (24GB GDDR6, same TU102 die)? WantIto avoid a memory or power-table mismatch like happened with the M40/Titan X combo before the M6000 vBIOS worked better.

Appreciate you taking the time to weigh in — this thread (and the M40 story) has been a great reference.
 
Thanks Borowski!
Good point — that's actually the cleaner first step before going down the cross-flash route.
For the PC UEFI-boot test I'll need to borrow a friend's machine anyway, so I'll do both at once: check if the card outputs anything in UEFI mode, and verify the VBIOS at the same time.
On the VBIOS check: I know GPU-Z can save the current BIOS and TechPowerUp has reference ROMs — but what's the most reliable way to confirm it's truly unmodified? Is a direct MD5/SHA hash comparison against the TechPowerUp reference ROM for my specific card (Quadro RTX 6000 FE, P/N 699-5G150-0510-506E) sufficient, or is there anything else worth checking?
 
You must disable CSM to avoid loading any legacy roms. Or use secureboot, on modern hardware usually only UEFi-compatible roms will be loaded. If GOP works correctly, you'll get video signal before the Windows driver takes over.

TRex_2024 said:
but what's the most reliable way to confirm it's truly unmodified? Is a direct MD5/SHA hash comparison against the TechPowerUp reference ROM for my specific card (Quadro RTX 6000 FE, P/N 699-5G150-0510-506E) sufficient, or is there anything else worth checking?
Click to expand...
Compare the dumped and reference rom with a hexeditor.
 
Thanks Borowski, understood!
Will disable CSM for the UEFI boot test and do a proper hex comparison of the dumped ROM against the TechPowerUp reference. Planning to run both tests this weekend and will report back.
 
Hi Borowski,
quick update: I ran the first test today on a separate PC testbed (ASUS Prime A320M-K, Ryzen 3 2200G, InWin 850W PSU) with CSM disabled — pure UEFI mode. The Quadro RTX 6000 (TU102 FE, P/N 699-5G150-0510-506E) posts and outputs video correctly via DisplayPort. So GOP appears to be working fine on the PC side.
Next step: dump the VBIOS with GPU-Z and do a hex comparison against the TechPowerUp reference ROM for this card. Will report back asap.
Thanks for the pointer!
Tobias
 
Hi Borowski,


following up on your suggestion to verify the VBIOS before going down the cross-flash route.


Setup recap:Quadro RTX 6000 FE (TU102, P/N 699-5G150-0510-506E), BIOS Version 90.02.30.00.02, Subvendor: NVIDIA, UEFI flag set in GPU-Z.


PC UEFI test (CSM disabled):Ran the card in a separate PC testbed (ASUS Prime A320M-K, Ryzen 3 2200G, InWin 850W PSU) with CSM disabled — pure UEFI mode. Card posts and outputs video correctly via DisplayPort. GOP appears functional on the PC side.


VBIOS comparison:Dumped VBIOS with GPU-Z and compared against the TechPowerUp reference ROM for this card (NVIDIA.QuadroRTX6000.24576.190111.rom, version 90.02.30.00.02).


SHA256 hashes differ:


  • dump: 6F3D4FD538F92E704A8FDC01161FADD93B3B86B5D26C592B2C4EEDEFA13C9AEB
  • reference: 1B1A2B0DD15885922839B3F206D047F78F068F904ECF96B341A7C530852E3F29
I askec Claude to suppoet me in the process and try to interprete the data.....

Ran a byte-level diff — 25,345 differences total. The first 15 offsets (0x0F3188–0x0F31F0) look like normal OEM serial/board-ID variance. However, from 0x0F4000 onward, the reference ROM shows solid FF bytes (empty/unflashed flash space) while the dumped VBIOS contains actual data — calibration tables, temperature data or similar. The same pattern repeats around 0x0FDF00.


Question:Is the TechPowerUp reference ROM for this card simply an incomplete or early dump that has unprogrammed regions, making the diff meaningless for these areas? Or does the presence of data in those regions in my dump indicate a modified VBIOS that could explain the black screen on the Mac Pro 5,1 with EnableGOP1.4?


Happy to share the full diff.txt if useful.


Thanks,Tobias
 

Attachments

All fine, the bios is untouched and matches to the reference type NVIDIA.QuadroRTX6000.24576.190111.rom from techpowerup.
The differences at the end are related to flashing process: from Kepler generation and up, every flashing, even same bios, will change/add entries. Additional, for Quadros the serial number and factory bios version is written.
 
Okay, that aligns with what the seller I messaged on eBay this morning said. He stated that he hadn't altered the card in any way—meaning he didn't modify or flash the BIOS.
 
Hi Borowski,
thanks for the quick analysis — good to know the VBIOS is untouched.

Given that:
  • Mac Pro 5,1 chimes and boots normally with the Quadro RTX 6000 installed
  • Display stays completely black throughout — no output at OpenCore picker stage or beyond
  • GOP confirmed working on a PC testbed with CSM disabled

Two follow-up points:

First, EnableGOP 1.4 (Macschrauber version) was flashed previously but is not currently active — I would reflash it before the next Mac Pro test. Would you recommend doing that first before anything else?

Second, another user suggested trying all DisplayPort outputs on the Quadro to rule out a port-specific issue. I'll do that as well, though I suspect it won't change anything given the card outputs fine on the PC side.

Main question remains: is a Titan RTX VBIOS cross-flash the right approach for this "chime but no video" symptom on a Turing card, and if so — is there a known-good Titan RTX ROM version that's a safe match for the Quadro RTX 6000 FE (same TU102 die, 24GB GDDR6)?

And I must find a sytem with two PCIe slots for flashing ;-)


Thanks,Tobias
 
I have no experience w/ flashing modern cards, but for safety reasons mods or crossflashes are very restricted. You'd better opt for a SPI programmer like CH341 and flash the whole image directly with clip.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back