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

[FlorisVN]

@Nick [D]vB ,

I can CONFIRM that the latest High Sierra security update 004, with did do an EFI update during the security update proces did BROKE the bootrom patch.
I presume I will have to make a new bootrom based of my newly patch updated bootrom now. ?

before the update I had older bootrom version : IM121,004D.B00 , after the security update it is now : 87.0.0.0.0

This iMac was running an older bootrom, since it was not used for more than a year.
And there I think a good test candidate.. ?

Anyway, I don't think any new bootrom versions for these 2011 iMac's will be released anymore by Apple.
At least I doubt they will soon..

So this boot ram patch breaking, will perhaps not be applied for everyone here I presume.. ?
Most of us will properly already have updated the bootrom to the latest version..
If not, I would recommend doing so first, and then applying the bootrom patch in the end...
So update/upgrade to High Sierra, and run all the available updates..

And if so, I think we will just have to patch our boot ram again with the updated one's.. ?
What do you think of my conclusion..?

Provided are some screenshots I took, before and after the bootrom update's.
before is the one that was modified with Nick's bootrom patch, after is the one that broke the bootrom patch from Nick and everything is updated and stock again..

Hope this info will be of some use for everyone out there..

 

[Nick [D]vB]

Well, that is very interesting!

I have never had a firmware auto update on my modded bootrom before, I tested it again yesterday and that update was "installed" but the rom update was not applied after a restart, I tried several times. I do have lots of other hardware / firmware changes in my system, USB3 etc, so maybe something else is blocking it??

I wonder if "eficheck" has been run first?

Did you see any different messages about the firmware update?

https://eclecticlight.co/2018/06/02/how-high-sierra-checks-your-efi-firmware/

https://eclecticlight.co/2018/10/31/which-efi-firmware-should-your-mac-be-using-version-3/

Anyway, it is not a big problem, as you said I don't think we will get many firmware updates from now on, and you can choose not to install them, or just re-patch as I said before. If you are going to do that maybe you can try the Beta2 bootrom files I posted (use the _MP6 versions). That would be very helpful to test, I am happy to mod it for you but I'm sure you can do it for yourself now. Let me know if you have any more issues. Thanks!

 

[Polydactyl]

Nick [D]vB, Or anyone who has successfully flashed a GTx765m (dell/alienware version):

I’m trying to flash 765m using flashrom on a raspberry pi and CH341a programmer. I can read the current vbios (flashrom —programmer ch431a_spi -r backup.bin) with no problems, but when I issue the following command:

sudo flashrom —programmer ch431a_spi -w 765M.rom​

I get the following:

Calibrating delay loop... OK.
Found Macronix flash chip "MX25L2005(C)/MX25L2006E" (256 kB, SPI) on ch341a_spi.
Error: Image size (209920 B) doesn't match the flash chip's size (262144 B)!
pi@raspberrypi:~/firmware $​

Any ideas? Thanks!

 

[FlorisVN]

Well, that is very interesting!

Did you see any different messages about the firmware update? I wonder if it runs eficheck first:

https://eclecticlight.co/2018/06/02/how-high-sierra-checks-your-efi-firmware/
https://eclecticlight.co/2018/10/31/which-efi-firmware-should-your-mac-be-using-version-3/

I have never had a firmware auto update on my modded bootrom before, I tested it again yesterday and that update was "installed" but the rom update was not applied after a restart. I tried several times, but I have lots of other hardware / firmware changes in my system, USB3 etc, so maybe something else is blocking it??

Anyway it is not a big problem, as you said I don't think we will get many firmware updates from now on, and you can choose not to install them, or just re-patch as I said before. If you are going to do that maybe you can try the Beta2 bootrom files I posted, using the _MP6 versions. That would be very helpful to test, I am happy to mod it for you but I'm sure you can do it for yourself now. Let me know if you have any issues.

Hi There,

Maybe it did not ran eficheck first, because of an older bootrom version that I was running.. ?
It was however running a clean High Sierra 10.13.6, with the missing updates for 004 security update/iTunes and Safari.

Nope I did not see any verbose text messages, if that is what you mean ?
Nor an EFI update progress bar was visible.

I do also want to note that I rearly see those short black verbose text screen messages at all..

I also think the change of bricking the bootrom patch this time, was very high.
Due too a complete change of the bootrom version, I think this was a big upgrade btw.
If you compare the original bootrom version and the new one.
Went from the old : IM121,004D.B00 to new : 87.0.0.0.0

I think it was completly overwritten with a new 87.0.0.0.0.. ?

I'm almost pretty sure that the latest bootrom 87.0.0.0.0 is the last, and the last few security updates proberly where already based on 87.0.0.0.0 perhaps..?
I think the formware which this test iMac had running, was very old, and 87.0.0.0.0 is also applied during the upgrade to High Sierra perhaps.. ?

Last time this imac was in use was back in 2016 with macOS Sierra, when the Original AMD card was still working..

But I indeed highly doubt a new bootrom version will be released soon or even at all, proberly 87.0.0.0.0 will be the last one.
I think intel is also about to quit cpu patches for older generation intel core cpu's atm.. ?
correct me if I'm wrong..

Anyway, I would sure test your new bootrom beta
I've seen it before in this thread, I thought it was only a new vbios beta 2 for the AMD cards..
But it also involves a new Vbios and or bootrom patches for Nvidia kepler cards.. ?
[doublepost=1567949437][/doublepost]

Nick [D]vB, Or anyone who has successfully flashed a GTx765m (dell/alienware version):

I’m trying to flash 765m using flashrom on a raspberry pi and CH341a programmer. I can read the current vbios (flashrom —programmer ch431a_spi -r backup.bin) with no problems, but when I issue the following command:

sudo flashrom —programmer ch431a_spi -w 765M.rom​

I get the following:

Calibrating delay loop... OK.
Found Macronix flash chip "MX25L2005(C)/MX25L2006E" (256 kB, SPI) on ch341a_spi.
Error: Image size (209920 B) doesn't match the flash chip's size (262144 B)!
pi@raspberrypi:~/firmware $​

Any ideas? Thanks!

I have flashed my Dell/Alienware GTX765m using nvflash with Bootcamp Windows 7.
I did not had these size errors at all, flashing went just fine..

If you want pm me, I can send you a Winclone image, you can use an External monitor with it or use RDP to enter Windows..

 

[Nick [D]vB]

I get the following:

Calibrating delay loop... OK.
Found Macronix flash chip "MX25L2005(C)/MX25L2006E" (256 kB, SPI) on ch341a_spi.
Error: Image size (209920 B) doesn't match the flash chip's size (262144 B)!
pi@raspberrypi:~/firmware $​

Any ideas? Thanks!

Sorry, that is my fault, I forgot to pad the Kepler roms (it's not needed for nvflash)

Just use these files instead and it will work now using Flashrom:

 

[Polydactyl]

Hi There,
I have flashed my Dell/Alienware GTX765m using nvflash with Bootcamp Windows 7.
I did not had these size errors at all, flashing went just fine..

If you want pm me, I can send you a Winclone image, you can use an External monitor with it or use RDP to enter Windows..

Thanks for the offer. I’m pretty bare bones at the moment...no external monitor, no windows, unless NVFLASH can be made to work from within VMWare Fusion (which i highly doubt it can). I’m going to go a few rounds with the pi / flashrom /ch341a before I resort to reassembling the iMac and installing a bootcamp partition.

Thanks.

 

[Nick [D]vB]

Nope I did not see any verbose text messages, if that is what you mean ?
Nor an EFI update progress bar was visible.

If eficheck has run you might see an "error report" type message in MacOS:

https://pikeralpha.wordpress.com/20...p-a-bios-region-of-your-ami-and-phoenix-bios/

I think it was completely overwritten with a new 87.0.0.0.0.. ?

Yes, it should have been completely over-written, but I would be interested to check if you can PM me a dump?

Anyway, I would sure test your new bootrom beta
I've seen it before in this thread, I thought it was only a new vbios beta 2 for the AMD cards..
But it also involves a new Vbios and or bootrom patches for Nvidia kepler cards.. ?

The Kepler vbios files are the same, just padded to work with Flashrom, but I would suggest most people use nvflash. The MP6 bootrom files in beta 2 might make the bootscreen work a little better now, and at least you get all the debug LEDs working, so you can quickly see if the card is properly seated in the MXM slot etc.

 

[Polydactyl]

see above

Thank you. That seems to have partly done the trick. Now I get a message that erase failed, but some data on the flash chip has changed.

 

[Nick [D]vB]

Check your clip is connected OK, and maybe carefully clean the chip legs, then re-flash it.

Flashrom must say VERIFIED when it has finished for something has gone wrong.

I strongly suggest most people just use nvflash for the graphics card if at all possible because it

is much harder to use the programmer clip properly on the smaller graphics card EEPROM chips.

 

[FlorisVN]

Thank you. That seems to have partly done the trick. Now I get a message that erase failed, but some data on the flash chip has changed.

I would suggest creating a few backup dumps first, in order to see if the connection between the clipper and the eeprom chip is good.

I would say make about 5 dumps or more, and check if they are all the same, using the command like :
shasum filename 1
shasum filename 2

After multiple dumps have been succesfull, and have the same size.
Then I would say the connection should be good, and try to flash the rom again...
[doublepost=1567952760][/doublepost]Sure,

I will send you a dump in a PM.
I'm also curious myself..

Anyway, great to see a beta 2 now of the bootrom patch !
Keep it going, I would love to test it aswell of course

I was windering you are mentioning that these .ffs files for the bootrom patch are now from a mp6.
You mean comming from a MacPro 6,1 ? instead of an iMac 2013/2014 in the beta 1 version.. ?
Just curious about this choice.. ?
Could mean that mp6 files are better somehow.. ?

 

[Nick [D]vB]

Thanks, but it is only a small change. Yes, the files are from MP6,1, it is the only CoreEG2 I found that makes all the debug LEDs work. Funny story, I didn't even realise I had bootscreens working for months because I assumed if LED3 was out then the graphics EFI had not loaded and so it could never work. I was wrong, doh!

I am wondering if it is better to have CoreEG2 more closely "matched" to the iMac bootrom firmware, or to the graphics EFI firmware? It is worth testing more deeply, but really I am starting to think the black screen delay problem is more related to the EDID Parser?? That is the other important part of this puzzle...

 

[FlorisVN]

Thanks, it is only a small change. Yes, the files are from MP6,1, it is the only CoreEG2 I found that makes all the debug LEDs work. Funny story, I didn't even realise I had bootscreens working for months because I assumed if the LED3 was out the graphics EFI had not loaded and so it could never work. I was wrong, doh!

I am wondering if it is better to have CoreEG2 more closely "matched" to the iMac bootrom firmware, or to the graphics EFI firmware? It is worth testing more deeply, but really I am starting to think the black screen delay problem is more related to the EDID Parser?? That is the other important part of this puzzle...

ok I see, thx for this explanation..
Funny story about these LED's..

Funny to know that the mp6,1 files give us all the LED lights on the logic board...

Anyway, I will send you a dump of the bootrom my test imac has now..
im also going to try to add the bootrom patch myself this time, will send you one to check if I did it right is that ok ?

let's hope the delay problem can also be solved one day..
the AMD cards won't have these delay problems, only nvidia related.. ?

 

[Polydactyl]

I would suggest creating a few backup dumps first, in order to see if the connection between the clipper and the eeprom chip is good.

I would say make about 5 dumps or more, and check if they are all the same, using the command like :
shasum filename 1
shasum filename 2

After multiple dumps have been succesfull, and have the same size.
Then I would say the connection should be good, and try to flash the rom again...

FlorisVN...that’s definitely the problem. Will keep trying to improve the connection. Also trying to find a way to slow down connection speed in flashrom in hopes that improves the situation.

Thanks.

 

[Nick [D]vB]

Do you always get flashrom errors at the same place, % complete?

If you post a screenshot of the errors I can try and help you.

You can try flashrom -E to fully erase the chip first, then re-flash.

Sometimes you need to reboot the Pi or reset the CH341 by replugging USB.

Also, laptops should have AC power connected, and do not use long USB extension cables.

Did you connect the programmer clip / cable the wrong way around at any time?

 

[Polydactyl]

Do you always get flashrom errors at the same place, % complete?

If you post a screenshot of the errors I can try and help you.

You can try flashrom -E to fully erase the chip first, then re-flash.

Sometimes you need to reboot the Pi or reset the CH341 by replugging USB.

Also, laptops should have AC power connected, and do not use long USB extension cables.

Did you connect the programmer clip / cable the wrong way around at any time?

Screenshot attached. “Failed at” locations are different every time.

 

[Nick [D]vB]

That does sound like a clip connection problem, can you clean the chip with a cotton stick + alcohol (iso)
Also check the clip contacts, they should all be level, but these cheap clips get chewed-up pretty fast.
I'd also inspect / test the clip's wires because I have had them break under the heat-shrink before.

On some cards there are tiny SMD parts very close to the EEPROM chip that stop the clip sitting properly,
the trick is to get the obstructed side under, then pivot the other side of the clip down, and give it a "wiggle".
I hope that makes sense, there is a knack to this! I'd only use the clip on a graphics card as a last resort.

 

[FlorisVN]

@Nick [D]vB ,

I am trying to make a new patched bootrom again, based on 87.0.0.0.0 on my test iMac.
But so far I have not been able to create several good dumps with bootrom tool from dosdude1.
the app crashes lot's of time, i made 5 bootrom dumps so far, and only 3 are te same.
(checking with shasum filename command)

make's me a little worried, why this is happening..
maybe this is normal after all.. ?

 

[Nick [D]vB]

I've never seen RomTool crash before! I think you are doing too many dumps & crashing the DirectHW driver.
I would reboot and do an SMC / NVRAM reset, disable SIP again, and check the correct chip number is selected.
You will see small changes in the dumps from RomTool, after MacOS reboots etc. That is totally normal.
But, you should never see checksum changes to "offline" dumps (made at the same time) using a programmer.

PM me the dumps and I'll take a look.

 

[FlorisVN]

Strange, I have not seen any crashes before. Everything else is the same as before the update, MacOS etc

I would reboot and do an SMC / NVRAM reset, disable SIP again, and check the correct chip number is selected.

You will see small changes in the dumps from RomTool, after MacOS reboots etc That is normal.

But, you should never see checksum changes with dumps all made at the same time using a programmer.

PM me the dumps and I'll take a look.

ok thx,
i have indeed disabled SIP again.
Will do and SMC and Nvram reset aswell.

I will send you some new dumps trough a PM, thx !

 

[Polydactyl]

That does sound like a clip connection problem, can you clean the chip with a cotton stick + alcohol (iso)
Also check the clip contacts, they should all be level, but these cheap clips get chewed-up pretty fast.
I'd also inspect / test the clip's wires because I have had them break under the heat-shrink before.

On some cards there are tiny SMD parts very close to the EEPROM chip that stop the clip sitting properly,
the trick is to get the obstructed side under, then pivot the other side of the clip down, and give it a "wiggle".
I hope that makes sense, there is a knack to this! I'd only use the clip on a graphics card as a last resort.

Finally! After reseating the clip a million times, multiple alcohol swabs, etc. it finally flashed and verified. Now on to the BootROM....

Thanks you Nick [D]vB and FlorisVn for the help and suggestions!

Edit: looks like it will be the same nonsense with the BootROM! Good times.

 

[Nick [D]vB]

Edit: looks like it will be the same nonsense with the BootROM! Good times.

Strange, I think maybe the clip is damaged? or the Pi can not send enough voltage??
If you see debug LED1 on the logic board go green then the clip contact should be ok.
Those clips can be a pain, I had to use one to recover a DFN type chip package once,
that was no fun at all...

 

[Polydactyl]

Strange, I think maybe the clip is damaged? or the Pi can not send enough voltage??
If you see debug LED1 on the logic board go green then the clip contact should be ok.
Those clips can be a pain, I had to use one to recover a DFN56 chip package once,
that was no fun at all...

If the clip wasn’t damaged before, it is now. It won’t hold on to the chip at all. I’ve resorted to removing the spring from the clip and putting rubber bands around the jaws so it doesn’t clamp down so tight that it pops off. I also have weight down the clip so it’s less liekly to move or spontaneously pop off the chip. It’s mostly working...It recognizes the BootROM chip, and can read from it, but it fails when trying to erase.

 

[FlorisVN]

Finally! After reseating the clip a million times, multiple alcohol swabs, etc. it finally flashed and verified. Now on to the BootROM....

Thanks you Nick [D]vB and FlorisVn for the help and suggestions!

Edit: looks like it will be the same nonsense with the BootROM! Good times.

If the clip wasn’t damaged before, it is now. It won’t hold on to the chip at all. I’ve resorted to removing the spring from the clip and putting rubber bands around the jaws so it doesn’t clamp down so tight that it pops off. I also have weight down the clip so it’s less liekly to move or spontaneously pop off the chip. It’s mostly working...It recognizes the BootROM chip, and can read from it, but it fails when trying to erase.

have you also tried with another machine, like a Mac or Windows PC to flash the chip.. ?
Also perhaps buy a new cliptool.. ?

Mine worked almost instanly when doing the bootrom patch.

 

[Nick [D]vB]

If the clip wasn’t damaged before, it is now.

If you are getting erase failures then a pin isn't making contact. But if your iMac still boots I'd probably call it a day and get another clip! The cheap ones are only good for a few uses on the smaller chips, then the tip goes. You can heat it with a flame to try and reform it but it's probably knackered. You can get better clips like the POMONA 5250, but they cost more. It was probably using it on the graphics card first that damaged it, but you really shouldn't have any problems with a new cheaper type clip on the larger bootrom chip. Good luck with it!

 

[Polydactyl]

If you are getting erase failures a pin isn't making contact. If your iMac still boots I'd probably call it a day and get another clip! The cheap ones are only good for a few uses, then the tip goes, you can heat it with a flame to try and reform it but it's probably knackered. You can get better clips like the POMONA 5250, but they cost more. It was probably using it on the graphics card that damaged it, you really should have problems with a new clip on the larger bootrom chip.

Yep, I’m calling it. I’ve already spent 5x the amount of time I originally expected on this. Will order a better clip and try again in a week or two. Thanks again for all your help. You’ve gone truly above and beyond.