iM 4,1-14,4 2011 iMac Graphics Card Upgrade

[JohnPascololo]

What a fail! I recieved the second GTX880M today. This time from China. It is pre-flashed with the nickkey bios. This card is broken too. It has the green line artifacts which i guess are dying VRAM? So again I will have to discuss about refund and so on. This is so annoying...

 

[edwardgeo]

@edwardgeo
This is what I do to locate the shadowed vbios in an imac.
Let's take a look at all of our devices in our computer and locate your GPU entry:

devices -b

result:

34 R - -  -  1 31 Acpi(PNP0A03,0)
A5 D - -  4  -  - Primary Console Input Device
A6 D - -  1  -  - Primary Console Output Device
F9 D - -  1  -  - Acpi(PNP0A03,0)/Pci(0|0)
FA D - -  1  -  - Acpi(PNP0A03,0)/Pci(3|0)
FB B - -  1  5  1 ATI Radeon Blackcomb Video Adapter     <-- what we want
FC D - -  1  -  - Acpi(PNP0A03,0)/Pci(3|0)/Pci(0|1)
FD D - -  1  -  - Acpi(PNP0A03,0)/Pci(8|0)
FE D - -  1  -  - Acpi(PNP0A03,0)/Pci(8|1)
FF D - -  1  -  - Acpi(PNP0A03,0)/Pci(8|2)
100 D - -  1  -  - Acpi(PNP0A03,0)/Pci(8|3)

Next, let's look at the device handles in the EFI environment:

dh -b FB

Result:

   ConOut (0)
   PciIo (BEB41D28)
     Segment #.....: 00
     Bus #.........: 01
     Device #......: 00
     Function #....: 00
     ROM Size......: 1BA00                         <--what we want
     ROM Location..: BDF50018                      <--what we want

now, dump the entire vbios into a file:

dmem BDF50018 1BA00 > imac_vbiosdump.rom

Result:

  Memory Address 00000000BDF50018 200 Bytes
  BDF50018: 55 AA 80 E9 3D 02 00 00-00 00 00 00 00 00 00 00  *U...=...........*
  BDF50028: 00 00 00 00 00 00 00 00-F0 01 00 00 00 00 49 42  *..............IB*
  BDF50038: 4D 42 00 00 00 00 00 00-00 00 00 00 00 00 00 04  *MB..............*
  BDF50048: 20 37 36 31 32 39 35 35-32 30 00 00 00 00 00 00  * 761295520......*
  BDF50058: 35 02 00 00 00 00 00 00-CC 01 00 00 00 00 00 00  *5...............*
  BDF50068: 30 36 2F 30 37 2F 31 31-2C 31 32 3A 33 36 3A 30  *06/07/11,12:36:0*
  BDF50078: 36 00 00 00 E9 D0 03 00-E9 DF 03 00 00 00 A8 00  *6...............*
  BDF50088: 00 00 00 00 00 16 00 80-00 02 00 00 00 00 00 00  *................*
  BDF50098: D6 20 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *. ..............*
  BDF500A8: 00 00 00 00 00 00 00 00-00 00 00 00 20 67 00 00  *............ g..*
  BDF500B8: 00 00 00 00 00 00 00 00-31 31 33 2D 43 32 39 36  *........113-C296*
.......
....
...
..

Can be done with any of the devices onboard

That is strange in my case. Look at this:

RESULTS (EFISHELL64):

devices -b

devices -b > devices.log

T D
Y C I
P F A
CTRL E G G #P #D #C Device Name
==== = = = == == === =========================================================
AB R - - 0 1 25 PciRoot(0x0)
2AD D - - 7 0 0 Primary Console Input Device
2AE D - - 1 0 0 Primary Console Output Device
2D1 D - - 1 0 0 PciRoot(0x0)/Pci(0x0,0x0)
2D2 D - - 1 0 0 PciRoot(0x0)/Pci(0x1,0x0)
2D3 D - - 1 1 0 AMD Radeon BAFFIN Graphics
2D4 B - - 1 1 1 AMD Buffin HD Audio Controller
2D5 B - - 1 1 1 Intel(R) Graphics Controller

dh -b 2D3 //Gpu AMD Radeon BAFFIN Graphics

dh -b 2D3 > 2D3.log


2D3: FirmwareManagement(FirmwareManagement) LoadFile2 PCIIO DevicePath(..0)/Pci(0x1,0x0)/Pci(0x0,0x0))

 

[nikey22]

dh -b 2D3 //Gpu AMD Radeon BAFFIN Graphics

show me full 2D3.log, hopefully HP hasn't restricted unsupported vbioses in the ACPI?

 

[edwardgeo]

show me full 2D3.log, hopefully HP hasn't restricted unsupported vbioses in the ACPI?

Here is all log:

FirmwareManagement(FirmwareManagement) LoadFile2 PCIIO DevicePath(..0)/Pci(0x1,0x0)/Pci(0x0,0x0))

I don’t think that this security or non supported gpu. Maybe that’s different way to work with option rom then before

 

[Alex W.]

Well if anyone here’s has a triple heat sink and a card that’s preflashed, let me know; I’m looking to get my 2011 metal capable so it can run WOW when the step brothers kids come over.

figured it’s a better machine for them to play one vs my 5000+ dollar work stations.

I looked on eBay but it ads a $100 to the cost when an 880m is already 350CAD

expensive, but maybe I’ll try my luck if anyone on this thread has extra parts they don’t have active currently.

cheers and thanks for all the help!

 

[joevt]

Don't need -b when piping to a text file. -b is used to pause the output after a page of text.

Use -v to get more info from a handle.
Use -d to get driver related info (child/parent relationships) from a handle.

To get info on all PCI devices, do this:
dh -v -d -p PciIo > dh_v_d_p_PciIo.txt

If the driver is not in a PCI option rom, then may be search all LoadedImage
dh -v -d -p LoadedImage > dh_v_d_p_LoadedImage.txt

You can see the contents of the text file like this:
type -b dh_v_d_p_LoadedImage.txt
but the text coloring will be gone so maybe redo the commands without piping to a text file.
dh -b -v -d -p PciIo
dh -b -v -d -p LoadedImage

You could try looking for the Gop (-p GraphicsOutput). The parent or grand parent may have the PciIo protocol with the rom. The GraphicsOutput protocol address points to a pointer to the QueryMode function which probably exists inside a LoadedImage.
Might be nice if the dh command would output the protocol function addresses and what loaded image they are pointing to.

For example, my Parallels Desktop VM is like this:
dh -d -v -p GraphicsOutput

92: ConsoleOut(0)
 SimpleTextOut(7DEE4430)
   Address: 7DEE4430 Attrib 07
 GraphicsOutput(7DEE51B8)
   Managed by         : 
     Drv[50]          : Platform Console Management Driver
     Drv[54]          : Console Splitter Driver
     Drv[59]          : Graphics Console Driver
   Parent Controllers : 
     Parent[86]       : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
   Child Controllers  : 
     Child[57]        : Primary Console Output Device

dmem 7DEE51B8

Memory Address 000000007DEE51B8 200 Bytes
  7DEE51B8: 34 52 F2 7C 00 00 00 00-37 55 F2 7C 00 00 00 00  *4R.|....7U.|....*

So you want to search for 7CF25234.
You can get info on all the handles
dh -d -v > dh_d_v.txt
Then look at all the loaded images that contain 7CF25234.

find_address_in_dh () {
	local theaddress="$1"
	local thefile="$2"
	IFS=$'\n'
	for theimage in $(
		iconv -f UCS-2 -t UTF-8 "$thefile" | perl -0777 -nE 'while ( / +ImageBase.....: (\w+)\r\n +ImageSize.....: (\w+)/g ) { print $1 . " " . $2 . "\n" }'
	) ; do
		if (( theaddress >= 0x${theimage% *} && theaddress <= 0x${theimage% *} +  0x${theimage#* } )) ; then
			iconv -f UCS-2 -t UTF-8 "$thefile" | perl -0777 -nE '/(^\w+.*\r\n( .*\r\n)* +ImageBase.....: '"${theimage% *}"'\r\n( .*\r\n)*)/mg && print $1' | tr -d '\r'
		fi
	done
}

find_address_in_dh 0x7CF25234 /Volumes/UEFITEST/shell_udk2018/dh_d_v.txt

Result:

79: 2E3044AC-879F-490F-9760-BBDFAF695F50(0)
 ComponentName2(7CF27E50)
 ComponentName(7CF27F60)
 DriverBinding(7CF27E80)
 ImageDevicePath(7DEFB998)
  MemoryMapped(0xB,0x7EC10010,0x7F0D000F)/FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
 LoadedImage(7DEFB1C0)
  Name..........: BiosVideoDxe
  Revision......: 0x00001000
  ParentHandle..: 7E348F98
  SystemTable...: 7E7E8018
  DeviceHandle..: 7E33FE18
  FilePath......: FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
  PdbFileName...: /home/integrator/jenkins/workspace/PDFM-17.0.0-rc/edk2/Build/PrlEfi-X64/DEBUG_GCC5/X64/IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe/DEBUG/BiosVideoDxe.dll
  OptionsSize...: 0
  LoadOptions...: 0
  ImageBase.....: 7CF22000
  ImageSize.....: 62C0
  CodeType......: EfiBootServicesCode
  DataType......: EfiBootServicesData
  Unload........: 0 
   Driver Name [79]   : BIOS[INT10] Video Driver
   Driver Image Name  : FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
   Driver Version     : 00000003
   Driver Type        : Bus
   Configuration      : NO
   Diagnostics        : NO
   Managing           : 
     Ctrl[86]         : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
       Child[92]      : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100)

In this case, the GOP (Graphics Output Protocol) is provided by a driver in the firmware called BiosVideoDxe.
This is probably because the option rom of the GPU contains a BIOS driver instead of a GOP driver.
BiosVideoDxe is a GOP driver that calls the BIOS driver.

It would be cool if Macs could use a BIOS driver the same way. Has that ever been attempted before? It would probably require some work to make it work in the Mac EFI.

 

[edwardgeo]

Don't need -b when piping to a text file. -b is used to pause the output after a page of text.

Use -v to get more info from a handle.
Use -d to get driver related info (child/parent relationships) from a handle.

To get info on all PCI devices, do this:
dh -v -d -p PciIo > dh_v_d_p_PciIo.txt

If the driver is not in a PCI option rom, then may be search all LoadedImage
dh -v -d -p LoadedImage > dh_v_d_p_LoadedImage.txt

You can see the contents of the text file like this:
type -b dh_v_d_p_LoadedImage.txt
but the text coloring will be gone so maybe redo the commands without piping to a text file.
dh -b -v -d -p PciIo
dh -b -v -d -p LoadedImage

You could try looking for the Gop (-p GraphicsOutput). The parent or grand parent may have the PciIo protocol with the rom. The GraphicsOutput protocol address points to a pointer to the QueryMode function which probably exists inside a LoadedImage.
Might be nice if the dh command would output the protocol function addresses and what loaded image they are pointing to.

For example, my Parallels Desktop VM is like this:
dh -d -v -p GraphicsOutput

92: ConsoleOut(0)
SimpleTextOut(7DEE4430)
   Address: 7DEE4430 Attrib 07
GraphicsOutput(7DEE51B8)
   Managed by         :
     Drv[50]          : Platform Console Management Driver
     Drv[54]          : Console Splitter Driver
     Drv[59]          : Graphics Console Driver
   Parent Controllers :
     Parent[86]       : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
   Child Controllers  :
     Child[57]        : Primary Console Output Device

dmem 7DEE51B8

Memory Address 000000007DEE51B8 200 Bytes
  7DEE51B8: 34 52 F2 7C 00 00 00 00-37 55 F2 7C 00 00 00 00  *4R.|....7U.|....*

So you want to search for 7CF25234.
You can get info on all the handles
dh -d -v > dh_d_v.txt
Then look at all the loaded images that contain 7CF25234.

find_address_in_dh () {
    local theaddress="$1"
    local thefile="$2"
    IFS=$'\n'
    for theimage in $(
        iconv -f UCS-2 -t UTF-8 "$thefile" | perl -0777 -nE 'while ( / +ImageBase.....: (\w+)\r\n +ImageSize.....: (\w+)/g ) { print $1 . " " . $2 . "\n" }'
    ) ; do
        if (( theaddress >= 0x${theimage% *} && theaddress <= 0x${theimage% *} +  0x${theimage#* } )) ; then
            iconv -f UCS-2 -t UTF-8 "$thefile" | perl -0777 -nE '/(^\w+.*\r\n( .*\r\n)* +ImageBase.....: '"${theimage% *}"'\r\n( .*\r\n)*)/mg && print $1' | tr -d '\r'
        fi
    done
}

find_address_in_dh 0x7CF25234 /Volumes/UEFITEST/shell_udk2018/dh_d_v.txt

Result:

79: 2E3044AC-879F-490F-9760-BBDFAF695F50(0)
ComponentName2(7CF27E50)
ComponentName(7CF27F60)
DriverBinding(7CF27E80)
ImageDevicePath(7DEFB998)
  MemoryMapped(0xB,0x7EC10010,0x7F0D000F)/FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
LoadedImage(7DEFB1C0)
  Name..........: BiosVideoDxe
  Revision......: 0x00001000
  ParentHandle..: 7E348F98
  SystemTable...: 7E7E8018
  DeviceHandle..: 7E33FE18
  FilePath......: FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
  PdbFileName...: /home/integrator/jenkins/workspace/PDFM-17.0.0-rc/edk2/Build/PrlEfi-X64/DEBUG_GCC5/X64/IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe/DEBUG/BiosVideoDxe.dll
  OptionsSize...: 0
  LoadOptions...: 0
  ImageBase.....: 7CF22000
  ImageSize.....: 62C0
  CodeType......: EfiBootServicesCode
  DataType......: EfiBootServicesData
  Unload........: 0
   Driver Name [79]   : BIOS[INT10] Video Driver
   Driver Image Name  : FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
   Driver Version     : 00000003
   Driver Type        : Bus
   Configuration      : NO
   Diagnostics        : NO
   Managing           :
     Ctrl[86]         : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
       Child[92]      : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100)

In this case, the GOP (Graphics Output Protocol) is provided by a driver in the firmware called BiosVideoDxe.
This is probably because the option rom of the GPU contains a BIOS driver instead of a GOP driver.
BiosVideoDxe is a GOP driver that calls the BIOS driver.

It would be cool if Macs could use a BIOS driver the same way. Has that ever been attempted before? It would probably require some work to make it work in the Mac EFI.

What a great way! I will try this evening and report! Thank you!

 

[m0bil]

I've been lately pushing to the limit my 780M under heavy windows gaming. Setup is 780M with overclocked 780M_BR2.rom and disconnected odd temp sensor to enable odd fan to spin up to 3800 rpm. To make things worse ambient temperature here is over 30ºC.

Last night I experienced two hard shutdowns (computer turns off suddenly while gaming). After the second it won't turn on, no chime, nothing.
Removed display to see that only diagnosis led #1 lights. When pressing power button fans spin up, first slowly and after a while full speed, so SMC is kind if working but still only led #1.
First tried removing RAM, all the same, not even the beep indicating ram is missing.
Then removed GPU, and got the second led light and beep indicating ram is missing. Added ram modules and iMac booted without the GPU fine. Then mounted GPU and got the endless chime loop, so removed it again and did the three PRAM resets, then mounted GPU again and all is working fine since.

I find it strange that the iMac can hold a *persistent* no boot status until GPU is removed (I did all kind of resets, removed battery, kept it unplugged for 1 day, etc.), but until I removed GPU it refused to boot and only led #1 stayed on. Note that this is different from the endless chime loop, where CPU is already working.

What subsystem can be responsible for this? Not BIOS as CPU was not even started, so it must be either SMC or the Intel Management Engine which I guess run on their own without using system RAM or CPU.

 

[Ausdauersportler]

Then removed GPU, and got the second led light and beep indicating ram is missing. Added ram modules and iMac booted without the GPU fine. Then mounted GPU and got the endless chime loop, so removed it again and did the three PRAM resets, then mounted GPU again and all is working fine since.

Obviously the iMac can leave some settings in the PRAM preventing the system to boot until you wiped it with your 3x PRAM reset. When I am not completely mistaken some information of a crash is written to the PRAM in some cases before stopping the system.

 

[internetzel]

Don't need -b when piping to a text file. -b is used to pause the output after a page of text.

Use -v to get more info from a handle.
Use -d to get driver related info (child/parent relationships) from a handle.

To get info on all PCI devices, do this:
dh -v -d -p PciIo > dh_v_d_p_PciIo.txt

If the driver is not in a PCI option rom, then may be search all LoadedImage
dh -v -d -p LoadedImage > dh_v_d_p_LoadedImage.txt

You can see the contents of the text file like this:
type -b dh_v_d_p_LoadedImage.txt
but the text coloring will be gone so maybe redo the commands without piping to a text file.
dh -b -v -d -p PciIo
dh -b -v -d -p LoadedImage

You could try looking for the Gop (-p GraphicsOutput). The parent or grand parent may have the PciIo protocol with the rom. The GraphicsOutput protocol address points to a pointer to the QueryMode function which probably exists inside a LoadedImage.
Might be nice if the dh command would output the protocol function addresses and what loaded image they are pointing to.

For example, my Parallels Desktop VM is like this:
dh -d -v -p GraphicsOutput

92: ConsoleOut(0)
SimpleTextOut(7DEE4430)
   Address: 7DEE4430 Attrib 07
GraphicsOutput(7DEE51B8)
   Managed by         :
     Drv[50]          : Platform Console Management Driver
     Drv[54]          : Console Splitter Driver
     Drv[59]          : Graphics Console Driver
   Parent Controllers :
     Parent[86]       : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
   Child Controllers  :
     Child[57]        : Primary Console Output Device

dmem 7DEE51B8

Memory Address 000000007DEE51B8 200 Bytes
  7DEE51B8: 34 52 F2 7C 00 00 00 00-37 55 F2 7C 00 00 00 00  *4R.|....7U.|....*

So you want to search for 7CF25234.
You can get info on all the handles
dh -d -v > dh_d_v.txt
Then look at all the loaded images that contain 7CF25234.

find_address_in_dh () {
    local theaddress="$1"
    local thefile="$2"
    IFS=$'\n'
    for theimage in $(
        iconv -f UCS-2 -t UTF-8 "$thefile" | perl -0777 -nE 'while ( / +ImageBase.....: (\w+)\r\n +ImageSize.....: (\w+)/g ) { print $1 . " " . $2 . "\n" }'
    ) ; do
        if (( theaddress >= 0x${theimage% *} && theaddress <= 0x${theimage% *} +  0x${theimage#* } )) ; then
            iconv -f UCS-2 -t UTF-8 "$thefile" | perl -0777 -nE '/(^\w+.*\r\n( .*\r\n)* +ImageBase.....: '"${theimage% *}"'\r\n( .*\r\n)*)/mg && print $1' | tr -d '\r'
        fi
    done
}

find_address_in_dh 0x7CF25234 /Volumes/UEFITEST/shell_udk2018/dh_d_v.txt

Result:

79: 2E3044AC-879F-490F-9760-BBDFAF695F50(0)
ComponentName2(7CF27E50)
ComponentName(7CF27F60)
DriverBinding(7CF27E80)
ImageDevicePath(7DEFB998)
  MemoryMapped(0xB,0x7EC10010,0x7F0D000F)/FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
LoadedImage(7DEFB1C0)
  Name..........: BiosVideoDxe
  Revision......: 0x00001000
  ParentHandle..: 7E348F98
  SystemTable...: 7E7E8018
  DeviceHandle..: 7E33FE18
  FilePath......: FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
  PdbFileName...: /home/integrator/jenkins/workspace/PDFM-17.0.0-rc/edk2/Build/PrlEfi-X64/DEBUG_GCC5/X64/IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe/DEBUG/BiosVideoDxe.dll
  OptionsSize...: 0
  LoadOptions...: 0
  ImageBase.....: 7CF22000
  ImageSize.....: 62C0
  CodeType......: EfiBootServicesCode
  DataType......: EfiBootServicesData
  Unload........: 0
   Driver Name [79]   : BIOS[INT10] Video Driver
   Driver Image Name  : FvFile(0B04B2ED-861C-42CD-A22F-C3AAFACCB896)
   Driver Version     : 00000003
   Driver Type        : Bus
   Configuration      : NO
   Diagnostics        : NO
   Managing           :
     Ctrl[86]         : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
       Child[92]      : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100)

In this case, the GOP (Graphics Output Protocol) is provided by a driver in the firmware called BiosVideoDxe.
This is probably because the option rom of the GPU contains a BIOS driver instead of a GOP driver.
BiosVideoDxe is a GOP driver that calls the BIOS driver.

It would be cool if Macs could use a BIOS driver the same way. Has that ever been attempted before? It would probably require some work to make it work in the Mac EFI.

I've actually been looking into something similar last week.
And I discovered something interesting: while the EFI 1.10 firmware of our old iMacs needs a UGA driver for video output, it does seem to install a UGA protocol on top of GOP drivers loaded from the VBIOS EEPROM - but unfortunately it doesn't register that driver for console output.
OpenCore does have the "ProvideConsoleGop" and "UgaPassThrough" quirks (made by @vit9696 )that deal with similar problems, and I had already ported that code to a standalone EFI driver to be flashed into the VBIOS EEPROM some months ago but wasn't able to debug the driver by that time. But now I've got the idea of using a (volatile) EFI variable in order to be able to see which steps the driver actually managed to do successfully, where it failed and so on.

Being able to use the GOP driver for EFI console output would enable us to use have native boot screens by just providing the correct Object_Info ATOM (and setting the backlight control bit in the FirmwareInfo ATOM).

 

[m0bil]

Obviously the iMac can leave some settings in the PRAM preventing the system to boot until you wiped it with your 3x PRAM reset. When I am not completely mistaken some information of a crash is written to the PRAM in some cases before stopping the system.

Yes, but this PRAM content I thought it was read or used by the CPU. Before I removed the GPU, it seemed clear the CPU was prevented from even starting (had ram modules removed and only led #1 lighted), and no PRAM reset was possible (I think PRAM reset is done by the CPU).

I know a part of flash chip is used by Intel Management Engine (even has it's own file system), maybe that was the one preventing the iMac to boot...

By the way, how is it with RX cards not POSTing on iMac 2011 (where fans spin up a bit and then all stops)? Does second led light or stays dark ?

 

[Ausdauersportler]

Yes, but this PRAM content I thought it was read or used by the CPU. Before I removed the GPU, it seemed clear the CPU was prevented from even starting (had ram modules removed and only led #1 lighted), and no PRAM reset was possible (I think PRAM reset is done by the CPU).

I know a part of flash chip is used by Intel Management Engine (even has it's own file system), maybe that was the one preventing the iMac to boot...

By the way, how is it with RX cards not POSTing on iMac 2011 (where fans spin up a bit and then all stops)? Does second led light or stays dark ?

The second LED remains dark - as far as I remember. Recently (a few posts or pages back) a user posted a video about his failed attempts to boot with an RX480 installed in an iMac12,2. Check it yourself. A single LED all the time.

 

[joevt]

I've actually been looking into something similar last week.
And I discovered something interesting: while the EFI 1.10 firmware of our old iMacs needs a UGA driver for video output, it does seem to install a UGA protocol on top of GOP drivers loaded from the VBIOS EEPROM - but unfortunately it doesn't register that driver for console output.
OpenCore does have the "ProvideConsoleGop" and "UgaPassThrough" quirks (made by @vit9696 )that deal with similar problems, and I had already ported that code to a standalone EFI driver to be flashed into the VBIOS EEPROM some months ago but wasn't able to debug the driver by that time.

Right. BiosVideoDxe is basically GOPonbBIOS. There are UGAonGOP and GOPonUGA drivers (UgaPassThrough is one of those). I've got a UGA Mac (MacPro3,1) with UGA GPU (GTX 680 Mac Editition). I want to make a standalone UGAonGOP that will work with newer GOP GPUs. Install it via Driver#### and get the Apple Startup Manager to load on it (bypassing current RefindPlus or OpenCore solutions).

But now I've got the idea of using a (volatile) EFI variable in order to be able to see which steps the driver actually managed to do successfully, where it failed and so on.

That requires you to be able to boot into an OS to get the EFI variable? Or you hope the driver doesn't crash and you can get the variable in the same EFI Shell that you launched the driver from? Can you use the EFI Shell on one GPU + display while testing a GOP driver for another display? Should be doable. Might be nice to do serial output for debugging purposes. A hackintosh might have a COM serial port but that doesn't help with Mac testing. Macs usually don't have serial ports. I wonder if something could be down with USB or FireWire or Ethernet for logging? There is a FtdiUsbSerialDxe driver if you can't get Ethernet or FireWire logging from UEFI.

 

[internetzel]

Right. BiosVideoDxe is basically GOPonbBIOS. There are UGAonGOP and GOPonUGA drivers (UgaPassThrough is one of those). I've got a UGA Mac (MacPro3,1) with UGA GPU (GTX 680 Mac Editition). I want to make a standalone UGAonGOP that will work with newer GOP GPUs. Install it via Driver#### and get the Apple Startup Manager to load on it (bypassing current RefindPlus or OpenCore solutions).

That Driver#### approach is quite interesting and nice. But having the GOPonUGA driver loaded directly from the VBIOS would be even nicer, don't you agree?
I think I should be able to easily create a VBIOS for your card that has your GOPonUGA driver loaded immediately before or after the GOP driver.
My driver does already load and execute - but maybe it's too early, as it doesn't make any difference yet (the ConOut handle still returns 0 display modes)?

That requires you to be able to boot into an OS to get the EFI variable? Or you hope the driver doesn't crash and you can get the variable in the same EFI Shell that you launched the driver from?

One problem during development is the fact that in case the driver makes the firmware crash I have to either take out the card (disassembling the iMac ...) and have the EEPROM flashed or at least erased using a clip programmer or I need to short circuit two pins of the flash EEPROM (my preferred way) so it appears empty and reflash it from Linux or Windows (EFI shell does also work for AMD cards).
In that situation having that same driver loaded by the Driver#### technique would indeed help - but I fear the firmware might already be in a different state at the time the driver is loaded then.
I might even use a non-volatile variable for logging so it survives even a reboot.

Can you use the EFI Shell on one GPU + display while testing a GOP driver for another display?

Not in an iMac unfortunately.

Should be doable. Might be nice to do serial output for debugging purposes. A hackintosh might have a COM serial port but that doesn't help with Mac testing. Macs usually don't have serial ports. I wonder if something could be down with USB or FireWire or Ethernet for logging? There is a FtdiUsbSerialDxe driver if you can't get Ethernet or FireWire logging from UEFI.

Well, there's not much space in the VBIOS left for a complex driver (less than 13 kB), so I hope I won't need more than some flags indicating which part executed successfully.

 

[m0bil]

The second LED remains dark - as far as I remember. Recently (a few posts or pages back) a user posted a video about his failed attempts to boot with an RX480 installed in an iMac12,2. Check it yourself. A single LED all the time.

ok, seen the video. Has anyone tried RX480 boot on 2011 iMac without ram modules inserted??

If it makes the same behavior as seen on video (and not the beep error indicating ram is missing), maybe it's not UEFI/BIOS what's preventing the iMac to start, but another pre-boot subsystem...

this is of course pure speculation, I know nothing about iMac start sequence.

 

[m0bil]

That Driver#### approach is quite interesting and nice. But having the GOPonUGA driver loaded directly from the VBIOS would be even nicer, don't you agree?
I think I should be able to easily create a VBIOS for your card that has your GOPonUGA driver loaded immediately before or after the GOP driver.
My driver does already load and execute - but maybe it's too early, as it doesn't make any difference yet (the ConOut handle still returns 0 display modes)?

One problem during development is the fact that in case the driver makes the firmware crash I have to either take out the card (disassembling the iMac ...) and have the EEPROM flashed or at least erased using a clip programmer or I need to short circuit two pins of the flash EEPROM (my preferred way) so it appears empty and reflash it from Linux or Windows (EFI shell does also work for AMD cards).
In that situation having that same driver loaded by the Driver#### technique would indeed help - but I fear the firmware might already be in a different state at the time the driver is loaded then.
I might even use a non-volatile variable for logging so it survives even a reboot.

Not in an iMac unfortunately.

Well, there's not much space in the VBIOS left for a complex driver (less than 13 kB), so I hope I won't need more than some flags indicating which part executed successfully.

One question about the boot screen emulation using Opencore: I've been playing around with the idea of testing a windows-only Maxwell card setup on a 2011 iMac, but the complete lack of boot screen is refraining me (specially for the windows boot part before loading display driver, as I don't see how I would do recovery in case it's needed).

How does Opencore boot screen emulation work? I mean, what does the vbios need in order to have an emulated boot screen by opencore ? If I can find a Maxwell card I could have emulated boot screen, I could give it a go

thanks!

 

[edwardgeo]

Well, there's not much space in the VBIOS left for a complex driver (less than 13 kB), so I hope I won't need more than some flags indicating which part executed successfully.

512 kB of space on spi and for vrom 80x512bytes, Gop and everything you need to. You can store more then one pci option rom on one spi. I done some weird but fun test on my ASUS pc hack, I added bios of usb 3.0 expansion card to gpu and erase the spi on expansion card. But results was shocking: the card was working fine with gpu, but when I disconnect gpu from mb, the expansion card stop working. So in uefi there is some program that connects all pci oproms to devices.

 

[nikey22]

For AMD ATOM bioses, the PCI ROM BAR will only map up to 128kB unfortunately regardless of EEPROM size.

 

[dfranetic]

ok, seen the video. Has anyone tried RX480 boot on 2011 iMac without ram modules inserted??

If it makes the same behavior as seen on video (and not the beep error indicating ram is missing), maybe it's not UEFI/BIOS what's preventing the iMac to start, but another pre-boot subsystem...

this is of course pure speculation, I know nothing about iMac start sequence.

I didn’t try this with the RX480, but I’m pretty sure I forgot to insert RAM modules more than once in my ‘HP WX4150 experiments’. I don’t recall hearing those ‘missing RAM beeps’ a single time. (I cannot confirm this now, give me a week or more…)

What I observed with non-POSTing AMD cards is: After plugging in the power cord LED1 flashes shortly before becoming solid green, after the press of the power button LED1 remains lit, fans spin, then stop, then spin, then stop, … meanwhile LED1 remains solid green, LED2 remains off.

 

[idenis42]

ok, seen the video. Has anyone tried RX480 boot on 2011 iMac without ram modules inserted??

If it makes the same behavior as seen on video (and not the beep error indicating ram is missing), maybe it's not UEFI/BIOS what's preventing the iMac to start, but another pre-boot subsystem...

this is of course pure speculation, I know nothing about iMac start sequence.

1-The computer turns on without a video card.
2-I erased the bios. The computer does not turn on.

 

[m0bil]

I didn’t try this with the RX480, but I’m pretty sure I forgot to insert RAM modules more than once in my ‘HP WX4150 experiments’. I don’t recall hearing those ‘missing RAM beeps’ a single time. (I cannot confirm this now, give me a week or more…)

What I observed with non-POSTing AMD cards is: After plugging in the power cord LED1 flashes shortly before becoming solid green, after the press of the power button LED1 remains lit, fans spin, then stop, then spin, then stop, … meanwhile LED1 remains solid green, LED2 remains off.

That's interesting, may indicate non booting is not related to UEFI/BIOS.

I still suspect Intel ME may play some part on specific cards not booting on the 2011 iMacs, as I described here. It is something different on 2011 iMacs from previous generations, but it also could be hardware or SMC related.

If I get same behavior again (persistent non booting iMac after hard shutdown), I'll try to program system flash with the "removed" (stripped down) ME to see if it makes any difference.

 

[unclemiltie]

"If I get same behavior again (persistent non booting iMac after hard shutdown), I'll try to program system flash with the "removed" (stripped down) ME to see if it makes any difference."

For what it's worth, I have been having odd behavior with non POST on my 2011 iMac with a K3100m. If I shut it down from the MacOS Menu all is good. But I've had a couple of power failures in the last month and the system does NOT want to re-start when it comes back on line. I have found that pushing the power button a couple of dozen times and waiting 3-4 seconds between will get it to chime and then boot.


you might want to try a lot of power button pushes to see if you're having the same issue.

 

[joevt]

That Driver#### approach is quite interesting and nice. But having the GOPonUGA driver loaded directly from the VBIOS would be even nicer, don't you agree?

Agreed. EFI is so powerful that it's easy to put the driver anywhere and load it. Maybe having the driver on the GPU makes it load earlier which removes the need to fix up stuff later.

Driver#### happens before the Apple Startup Manager starts. It's probably the same for Target Disk Mode. So at least it's earlier than all the stuff you might want to do at startup (at least all the UI bits that the user can interact with).

I think I should be able to easily create a VBIOS for your card that has your GOPonUGA driver loaded immediately before or after the GOP driver.
My driver does already load and execute - but maybe it's too early, as it doesn't make any difference yet (the ConOut handle still returns 0 display modes)?

So you might need some fix up stuff even for your method.

One problem during development is the fact that in case the driver makes the firmware crash I have to either take out the card (disassembling the iMac ...) and have the EEPROM flashed or at least erased using a clip programmer or I need to short circuit two pins of the flash EEPROM (my preferred way) so it appears empty and reflash it from Linux or Windows (EFI shell does also work for AMD cards).
In that situation having that same driver loaded by the Driver#### technique would indeed help - but I fear the firmware might already be in a different state at the time the driver is loaded then.

Right, if something goes wrong with Driver####, you just need to zap the PRAM (Command-Option-P-R). As for the firmware state, that's where the fixup stuff comes in. Needs investigation.

I might even use a non-volatile variable for logging so it survives even a reboot.

Not sure you want to stress the NVRAM of an old Mac like that. Well, maybe the iMac doesn't have the problem of the MacPro4,1 and MacPro5,1. https://forums.macrumors.com/threads/mp5-1-bootrom-thread-144-0-0-0-0.2132317/

Not in an iMac unfortunately.

A 2011 iMac has Thunderbolt. If it can boot from Thunderbolt, then it means it can see a eGPU at EFI time so maybe it could work.
https://egpu.io/forums/builds/imac-...-sc-4gb-akitio-thunder2-macos-and-windows-10/

Well, there's not much space in the VBIOS left for a complex driver (less than 13 kB), so I hope I won't need more than some flags indicating which part executed successfully.

I suppose a few flags won't hurt.

One question about the boot screen emulation using Opencore: I've been playing around with the idea of testing a windows-only Maxwell card setup on a 2011 iMac, but the complete lack of boot screen is refraining me (specially for the windows boot part before loading display driver, as I don't see how I would do recovery in case it's needed).

How does Opencore boot screen emulation work? I mean, what does the vbios need in order to have an emulated boot screen by opencore ? If I can find a Maxwell card I could have emulated boot screen, I could give it a go

Does 2011 iMac boot Windows with UEFI or BIOS?

I have a Maxwell Titan X. In my MacPro3,1, the driver does not load. I made a EFI driver called ReloadPCIRom that I can load from the EFI Shell that will try to load the EFI image of any option rom that has not been loaded. For the Maxwell card, this gives an error (Unsupported or something like that). The Maxwell EFI image is looking for EFI version 2.x but my MacPro3,1 has EFI 1.x. So I made a EFI driver called FakeUEFI2 which modifies the version in the system table and adds some missing UEFI 2.1 functions that don't exist in EFI 1.x. With this driver loaded first, the ReloadPCIRom driver will load the Maxwell driver. Put both of those in Driver####, then RefindPlus will display on the Maxwell connected display instead of my Kepler connected display (which is still the startup display). But this doesn't work for Startup Manager because I didn't add UGAonGOP or other fixup stuff that may be required for switching the boot screen from the Kepler to the Maxwell. This maybe also why the first stage of macOS boot does not appear on the Maxwell. Anyway most of the code for my two drivers is in RefindPlus and OpenCore now (in OpenCore, search for ForgeUefi and ReloadOptionRoms). There may be unforeseen consequences for messing with the EFI version in the system table. There are still things that need fixup.

 

[dfranetic]

That's interesting, may indicate non booting is not related to UEFI/BIOS.

I still suspect Intel ME may play some part on specific cards not booting on the 2011 iMacs, as I described here. It is something different on 2011 iMacs from previous generations, but it also could be hardware or SMC related.

If I get same behavior again (persistent non booting iMac after hard shutdown), I'll try to program system flash with the "removed" (stripped down) ME to see if it makes any difference.

I just realized that the flash of LED1 after plugging in the power cord is the more curious part. Normal behavior is LED1 becoming solid green after a second or so after plugging in the power cord. (This is probably the charge time of the PSU input capacitors.) In the case of non-POSTing AMD cards however LED1 will turn on after that ‘second or so‘, turn off for a second, and only then turn on to solid green. In my observations this happened with all 21.5’ or 27’, 2009-2011 iMacs. To me it was a dead giveaway of a non-POSTing 2011 system, or (sometimes) weirdly behaving 2009-2010 system.

Unfortunately, I lack the knowledge of the power-up process of a Mac, but it seems to me too that this cannot be related to iMac’s EFI or GPU’s VBIOS - especially since that flash of LED1 happens before the press of the power button. Could this be related to / controlled by SMC?

 

[internetzel]

Does 2011 iMac boot Windows with UEFI or BIOS?

Both methods do work on 2009-2011 iMacs, but with an upgraded AMD graphics card UEFI booting is often the only way to boot into Windows.
The 2011 will additionally need an SSDT fix for the audio device to work in Windows.

I have a Maxwell Titan X. In my MacPro3,1, the driver does not load. I made a EFI driver called ReloadPCIRom that I can load from the EFI Shell that will try to load the EFI image of any option rom that has not been loaded. For the Maxwell card, this gives an error (Unsupported or something like that). The Maxwell EFI image is looking for EFI version 2.x but my MacPro3,1 has EFI 1.x. So I made a EFI driver called FakeUEFI2 which modifies the version in the system table and adds some missing UEFI 2.1 functions that don't exist in EFI 1.x. With this driver loaded first, the ReloadPCIRom driver will load the Maxwell driver. Put both of those in Driver####, then RefindPlus will display on the Maxwell connected display instead of my Kepler connected display (which is still the startup display). But this doesn't work for Startup Manager because I didn't add UGAonGOP or other fixup stuff that may be required for switching the boot screen from the Kepler to the Maxwell. This maybe also why the first stage of macOS boot does not appear on the Maxwell. Anyway most of the code for my two drivers is in RefindPlus and OpenCore now (in OpenCore, search for ForgeUefi and ReloadOptionRoms). There may be unforeseen consequences for messing with the EFI version in the system table. There are still things that need fixup.

Quite interesting all that - knowledge spread in many different hard to find places.