Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iM 4,1-14,4 EnableGop: Pre-OpenCore GOP support for EFI-era iMacs and Mac Pros
- Thread starter Bmju
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Tesla P40 in classic Mac Pro — need it to not hang at POST; running Linux (Ubuntu), not macOS**
Trying to get a Tesla P40 24GB (GP102, stock, unmodified) working in a classic Mac Pro (4,1/5,1), booting Ubuntu from a USB flash drive — not macOS, so no OpenCore/GOP requirement in play. Posting here because the actual blocker looks like it needs the same category of fix as EnableGop — a driver injected directly into the Mac's own BootROM, running before any bootloader — just aimed at PCI BAR negotiation instead of GOP.
Confirmed by direct testing: with the P40 EPS-powered and seated, the machine never boots at all — no chime, nothing reaches a bootloader, USB boot media never gets a chance to run. So this is a pure firmware/POST-level failure, before Linux (or anything else) ever starts. That rules out leaning on Linux's `pci=realloc` post-boot reallocation as a fallback — there's no "boot partially, let the kernel finish it" option here, since the kernel never loads. Whatever fix exists has to happen entirely in the Mac's own firmware or on the GPU's own vBIOS.
**The problem:**
With the P40 properly EPS-powered and seated, the Mac Pro fails to POST at all — fans spin, no chime, only the 5V STBY and PSU PWROK diagnostic LEDs light. No video output, nothing. This is consistent with the Mac's firmware failing to allocate PCI resources for the card during enumeration — the P40's BAR1 defaults large (sized to match its 24GB VRAM), and the Mac's legacy PCI resource allocator can't fit it.
**What I know from research so far:**
1. A Mac Pro requires resizable/large BAR negotiation to happen *during PCI enumeration in firmware*, before any bootloader gets control. Per a technical explanation from joevt on a related MacRumors thread (Enabling Resizable BAR via OpenCore on a 7,1): "UEFI boot loaders (OpenCore, etc.) and UEFI drivers load too late (after the PCI devices get enumerated) to modify BAR settings." So OpenCore-level or WhateverGreen-level fixes can't reach this — confirmed, not theoretical.
2. There's a real, working precedent for exactly this GPU: a build log ("X99-E-10G WS POST issues - 3x P40 LLM inference rig," Level1Techs forum, NCMcClure, June 2024) where 3x stock/unmodified Tesla P40s + a Quadro P6000 failed to POST on an ASUS X99 board for the identical reason (large BAR1). The fix was patching the **motherboard's own UEFI firmware** with ReBarUEFI (via UEFITool/MMTool, following Mak3rde's DIY guide — github.com/xCuri0/ReBarUEFI/issues/13), then setting the BAR size via `ReBarState.exe` in Windows (set to 32 = "Unlimited" for 96GB total VRAM across 4 cards). All cards POSTed and enumerated with full VRAM afterward. No vBIOS modification on any of the GPUs — they stayed completely stock.
3. ReBarUEFI's actual patching mechanism is AMI/Insyde-specific (it targets a "Priebus" module inside a standard UEFI PEI/DXE volume structure via MMtool) — doesn't translate directly to Apple's BootROM, which has a different, closed structure.
4. EnableGop (this community's own tool) already proves the *general* technique — injecting a custom driver into a classic/EFI-era Mac Pro's own BootROM, running early enough to matter before OpenCore — is possible and working, just currently scoped to GOP/console output (via ForgeUefiSupport + ProvideConsoleGop) rather than PCI BAR sizing.
**What I'm asking:**
Has anyone here looked at (or would know the feasibility of) adapting the EnableGop injection mechanism — or building an equivalent — to carry a BAR-negotiation payload instead, so a specific PCI device (Tesla P40, device ID 10DE:1B38) gets a workable BAR1 allocation during the Mac's own PCI enumeration at POST, instead of the whole boot hanging? Given the machine never gets far enough to boot anything at all right now, this needs to happen fully in firmware — there's no later OS-level stage to lean on.
Also open to hearing whether this is even the right diagnosis. The only diagnostic LEDs that light are the power-supply-good ones (5V STBY, PSU PWROK) — none of the POST-progress LEDs light further than that. If that means the machine isn't reaching PCI enumeration at all (rather than reaching it and failing to allocate the BAR), this might be a power-sequencing problem instead of a BAR-sizing one, and I'd rather find that out than chase the wrong fix.
Card is confirmed otherwise healthy (stock firmware backed up and verified, `nvflashk --version` reads cleanly: Version 86.02.23.00.01, Board ID 0xEE0B, Subsystem 10DE:11D9). Happy to test any experimental EFI driver build on real hardware if someone has something to try — I have the Mac Pro and card in hand right no
Trying to get a Tesla P40 24GB (GP102, stock, unmodified) working in a classic Mac Pro (4,1/5,1), booting Ubuntu from a USB flash drive — not macOS, so no OpenCore/GOP requirement in play. Posting here because the actual blocker looks like it needs the same category of fix as EnableGop — a driver injected directly into the Mac's own BootROM, running before any bootloader — just aimed at PCI BAR negotiation instead of GOP.
Confirmed by direct testing: with the P40 EPS-powered and seated, the machine never boots at all — no chime, nothing reaches a bootloader, USB boot media never gets a chance to run. So this is a pure firmware/POST-level failure, before Linux (or anything else) ever starts. That rules out leaning on Linux's `pci=realloc` post-boot reallocation as a fallback — there's no "boot partially, let the kernel finish it" option here, since the kernel never loads. Whatever fix exists has to happen entirely in the Mac's own firmware or on the GPU's own vBIOS.
**The problem:**
With the P40 properly EPS-powered and seated, the Mac Pro fails to POST at all — fans spin, no chime, only the 5V STBY and PSU PWROK diagnostic LEDs light. No video output, nothing. This is consistent with the Mac's firmware failing to allocate PCI resources for the card during enumeration — the P40's BAR1 defaults large (sized to match its 24GB VRAM), and the Mac's legacy PCI resource allocator can't fit it.
**What I know from research so far:**
1. A Mac Pro requires resizable/large BAR negotiation to happen *during PCI enumeration in firmware*, before any bootloader gets control. Per a technical explanation from joevt on a related MacRumors thread (Enabling Resizable BAR via OpenCore on a 7,1): "UEFI boot loaders (OpenCore, etc.) and UEFI drivers load too late (after the PCI devices get enumerated) to modify BAR settings." So OpenCore-level or WhateverGreen-level fixes can't reach this — confirmed, not theoretical.
2. There's a real, working precedent for exactly this GPU: a build log ("X99-E-10G WS POST issues - 3x P40 LLM inference rig," Level1Techs forum, NCMcClure, June 2024) where 3x stock/unmodified Tesla P40s + a Quadro P6000 failed to POST on an ASUS X99 board for the identical reason (large BAR1). The fix was patching the **motherboard's own UEFI firmware** with ReBarUEFI (via UEFITool/MMTool, following Mak3rde's DIY guide — github.com/xCuri0/ReBarUEFI/issues/13), then setting the BAR size via `ReBarState.exe` in Windows (set to 32 = "Unlimited" for 96GB total VRAM across 4 cards). All cards POSTed and enumerated with full VRAM afterward. No vBIOS modification on any of the GPUs — they stayed completely stock.
3. ReBarUEFI's actual patching mechanism is AMI/Insyde-specific (it targets a "Priebus" module inside a standard UEFI PEI/DXE volume structure via MMtool) — doesn't translate directly to Apple's BootROM, which has a different, closed structure.
4. EnableGop (this community's own tool) already proves the *general* technique — injecting a custom driver into a classic/EFI-era Mac Pro's own BootROM, running early enough to matter before OpenCore — is possible and working, just currently scoped to GOP/console output (via ForgeUefiSupport + ProvideConsoleGop) rather than PCI BAR sizing.
**What I'm asking:**
Has anyone here looked at (or would know the feasibility of) adapting the EnableGop injection mechanism — or building an equivalent — to carry a BAR-negotiation payload instead, so a specific PCI device (Tesla P40, device ID 10DE:1B38) gets a workable BAR1 allocation during the Mac's own PCI enumeration at POST, instead of the whole boot hanging? Given the machine never gets far enough to boot anything at all right now, this needs to happen fully in firmware — there's no later OS-level stage to lean on.
Also open to hearing whether this is even the right diagnosis. The only diagnostic LEDs that light are the power-supply-good ones (5V STBY, PSU PWROK) — none of the POST-progress LEDs light further than that. If that means the machine isn't reaching PCI enumeration at all (rather than reaching it and failing to allocate the BAR), this might be a power-sequencing problem instead of a BAR-sizing one, and I'd rather find that out than chase the wrong fix.
Card is confirmed otherwise healthy (stock firmware backed up and verified, `nvflashk --version` reads cleanly: Version 86.02.23.00.01, Board ID 0xEE0B, Subsystem 10DE:11D9). Happy to test any experimental EFI driver build on real hardware if someone has something to try — I have the Mac Pro and card in hand right no