iM 4,1-14,4 iMac 2011 (see more) UEFI Firmware Mod

[StephN999]

This is a Wiki post with information collected from the entire thread. Before you post, please read this first.



This thread is for supporting iMac 2011 Firmware (BIOS) mods.

Some patches may work on other same era Macs. Look at description inside individual posts for detailed information.

Index of currently available patches:

• Remove eeprom flash protection.
• EnableGOP by @Bmju
• CPU Microcode updates.
• Enable PCIe 64bit address space (aka Windows audio ACPI patch).
• Disable iGPU (IGD).
• Disable DDR3 Memory Frequency Limit.
• native USB3 booting via TB dock or PCI card.
• CPU Turbo Overclocking Enable and Setup

You should be familiar with how to disassemble your system and hardware programming of the eeprom chip. While this patches have been extensively tested, there is always the risk of breaking some hardware parts. PROCEED AT YOUR OWN RISK!

You will need a hardware programmer like CH341A to apply this patches to your system bios eeprom chip.
It is recommended to apply first the patch to remove eeprom flash protection, so from then on you can use software flashing to apply or test other patches.

There is also a github repository where this patches and future ones will be stored.

---

---

Original post by @StephN999


Hello,

As I will soon receive my Ivy Bridge processor and test it on my iMac 2011, I made a simple modification of the intel Microcodes.

Since nothing is that simple (well, who knows), I think I need to make some other modifications.

By the way this code is in duplicate, I'll have to test with only one (capture of an original rom).

I thought it would be nice to see what we can do for that, but not only, make other modifications (see correction?)

I had thought for example to have the boot colors natively black like for a while on the higher machines or even more. 😅



Boot colors natively black mod Ok : Change your GUID 6A504489-884E-4465-A02F-03B248CDEF13,
by the iMac 16,1 GUID 6A504489-884E-4465-A02F-03B248CDEF13 file attached.

Correct the management of the wifi card when it's changed we can't use it directly at boot time.

And who knows other ideas about changes that could help for those who have changed their graphic cards etc...

I really like this kind of research but I know that my skills are very limited.

UEFI ROM (iMac 2011, 21"5 and 27") attachments of a motherboard out of service for those who want.

I count on you, thank you.

Wiki post, don't hesitate to correct my english mistakes.

 

[dosdude1]

Well, with the help of Coreboot, here it is... A 2011 17” MacBook Pro running with Core i7 3720QM and HM77 PCH!

 

[m0bil]

iMac 12,x DDR3 Frequency Limit disable

This firmware patch removes the 1333 MHz frequency limit Apple hardcoded in bios settings.
Faster DDR3 modules did work on iMac, but their speed was limited to 1333 MHz.
This patch removes such limit, allowing the use of 1600/1867/2133 MHz compatible modules at full speed.

Many thanks to @Ausdauersportler & @dfranetic for help in testing this!

Notes:

• Tested on iMac 12,x with bootrom 87.0.0.0.0.
• Not all ram modules tested seem to work. If they do not work at 1333 MHz for a start, they will probably not work at higher speeds. Please report if you get 1867/2133 modules to work at full speed with this patch.
• The "sweet spot" for Sandy Bridge seems 1600 MHz. Faster modules will bring very little (if any) performance increase.

I have started a Github repository to better keep track of firmware patches, this patch is there.

 

[m0bil]

iMac 12,2 & 12,1 UEFI Windows audio ACPI patch (64bit PCIe address space enabler)

This patch modifies firmware ACPI tables to enable 64bit PCIe address space. This fixes the well known UEFI Windows audio driver error, as well as other potential driver issues in UEFI Windows.

To apply use non-NE UEFITool 0.28, load your firmware file and replace "as is" volume with guid 7E374E25-8E01-4FEE-87F2-390C23C606CD with the .ffs file included below.

Since ACPI tables are platform dependent there are .ffs for the iMac 12,2 27'' (tested working) and iMac 12,1 21'' (not yet tested but should work), make sure to use the one intended for your model.
I have also included original DSDT files as well as the modified version.


In case you want to make your own ACPI mods, firmware volume 7E374E25-8E01-4FEE-87F2-390C23C606CD holds a Tiano compressed blob of ACPI tables, stored one after each other with a 4 bytes header prefix on each table. UEFITool can be used to extract and replace individual tables by right clicking in the "Raw section" (each Raw section is a table) inside the compressed section and using "Extract body..." or "Replace body..." options (that will skip or rebuild the required 4 bytes header as well as handle Tiano compression).
The extracted raw data will be the selected ACPI table in AML (ACPI Machine Language) format. You can use MaciASL to convert and edit them.

 

[m0bil]

iMac 12,2 bootrom flash protection bypass patch

One of the most painful tasks of firmware modding is having to open the iMac and clip eeprom chip to program it for every test.
This patch enables full write access to the eeprom, so it can be programmed from OS or UEFI shell.

Intended audience is people experimenting with UEFI firmware mods. Always make a full backup of you bootrom first and make sure you have the required skills/experience to program the eeprom with a clip and hardware programmer.


Let's take a look of how the eeprom is write protected on our iMacs using the tool chipsec:

# python3 chipsec_main.py -m chipsec.modules.common.spi_lock

[*] running module: chipsec.modules.common.spi_lock
[x][ =======================================================================
[x][ Module: SPI Flash Controller Configuration Locks
[x][ =======================================================================
[*] HSFS = 0xE008 << Hardware Sequencing Flash Status Register (SPIBAR + 0x4)
    [00] FDONE            = 0 << Flash Cycle Done
    [01] FCERR            = 0 << Flash Cycle Error
    [02] AEL              = 0 << Access Error Log
    [03] BERASE           = 1 << Block/Sector Erase Size
    [05] SCIP             = 0 << SPI cycle in progress
    [13] FDOPSS           = 1 << Flash Descriptor Override Pin-Strap Status
    [14] FDV              = 1 << Flash Descriptor Valid
    [15] FLOCKDN          = 1 << Flash Configuration Lock-Down
[+] SPI Flash Controller configuration is locked
[+] PASSED: SPI Flash Controller locked correctly.


# python3 chipsec_main.py -m common.bios_wp   

[*] running module: chipsec.modules.common.bios_wp
[x][ =======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
[*] BC = 0x00 << BIOS Control (b:d.f 00:31.0 + 0xDC)
    [00] BIOSWE           = 0 << BIOS Write Enable
    [01] BLE              = 0 << BIOS Lock Enable
    [02] SRC              = 0 << SPI Read Configuration
    [04] TSS              = 0 << Top Swap Status
    [05] SMM_BWP          = 0 << SMM BIOS Write Protection
[-] BIOS region write protection is disabled!

[*] BIOS Region: Base = 0x00181000, Limit = 0x007FFFFF
SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (74)     | 86D70181 | 00181000 | 006D7FFF | 1   | 0
PR1 (78)     | 9FFF06FC | 006FC000 | 01FFFFFF | 1   | 0
PR2 (7C)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR3 (80)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR4 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0

[!] SPI protected ranges write-protect parts of BIOS region (other parts of BIOS can be modified)

So, we can see the PR (Protected Range) registers are used to define non-writeable ranges 0x181000 to 0x6D7FFF and 0x6FC000 to 0x1FFFFFF. This means all of the bios region is write protected except a "hole" in the middle corresponding to the EfiSystemNvDataFvGuid volume (where nvram storage is located).

Then the PR registers are protected against modification by the Flash Configuration Lock-Down (FLOCKDN) bit in the HSFS register. Once set, FLOCKDN can only be cleared by a system reset.

With a bit of reversing, we can find this protections mechanisms are setup during boot on UEFI module PchSpiRuntime:

So, I made this patch to remove all PRR and FLOCKDN protection. It can be easily applied to your bootrom using UEFIPatch.

After applying it to your previously backed up bootrom, you have to program it once back to eeprom chip with clip.
Also you will need to use the patched rom as a base for all future modding (or you will re-protect it).

Once unprotected you should be able to use any compatible OS flash programming tool to program it in the future (flashrom, Intel FPT). I use Intel FPT (Flash Programming Tool) for Windows, it takes under 15 seconds to program the full eeprom, while using a clip it takes from 5 to 7 minutes.

Notes:

- Tested on iMac 12,2 with bootrom 87.0.0.0.0. May work on other models and versions, but has not been tested. It you try it watch UEFIPatch output for clues.
- After a sleep/wake cycle the rom will be protected again. This is due to some security patches by Apple and I see no need to patch this. If you want to flash you eeprom, do it after a cold boot or restart.
- If you brick your iMac due to further changes you make to the bios, you will of course need the clip to recover, but for simple "low risk of brick" modding and testing this is huge time saver.

 

[m0bil]

iMac 12,x iGPU (IGD) Full Disable patch

This firmware patch removes the Integrated Graphics Device (IGD, Bus 0 Device 2 Function 0) from the PCI bus.
The iGPU will not be initialized, will not be seen by OS nor use any hardware resources.

Behavior is the same as selecting "Disable Integrated Graphics" or "Disable onboard video" in other vendors bios.
As a side effect, it fixes the Windows BSOD when loading Intel Graphics Kernel Mode driver (igdkmd64.sys).

Notes:

• Tested on iMac 12,x with bootrom 87.0.0.0.0. May work on other Mac models and versions. If you try it watch UEFIPatch output for clues.
• Sleep works after applying patch.

I have started a Github repository to better keep track of firmware patches, this patch is there.

 

[dosdude1]

Thank you @m0bil for your patch!. I don't use Windows, but if I need I'll use it.
And @dosdude1 , Are the autoport files correct?

Yes, all looks fine. Sorry for the wait on this, I’ve had other things to work on and haven’t had a chance to mess with this yet. I’ll update again once I have a good Coreboot build done.

 

[m0bil]

People erroneously think that upgrading a firmware's set of microcodes will make the computer support newer processors. This is false. Microcodes are errata. No processor sold should need microcodes to boot. Besides, the operating system loads a newer version of microcodes anyway.

Experience shows that adding microcodes to Mac firmware will make the system less likely to boot.

New processors models for any socket are always made fully compatible with older hardware. Features are added, not deleted. Processor compatibility is limited by badly written firmware. In some cases (Dell) this is intentional.

When a firmware starts running one of the first things it does is calls CPUID (op code 0F A2). Good firmware checks the processor family, and if it actually has specific code for multiple families, chooses the appropriate branch. Bad firmware checks for a specific processor model number and halts if it is not an exact match.

To fix the firmware you should do the same kind of disassembly and analysis as I have done for the Mac Pro 2,1 firmware. Start reading from this post:

updating a Mac (Pro)s CPU Microcode

In the seven years the DELL Precision 690 microcode update thread has been up on the bios-mods.com site no one has figured out how to run Harpertowns or even to boot with quad-core Clovertowns on the wrong motherboard revision. User DeathBringer has however posted this insightful piece of code...

forums.macrumors.com

The Mac Pro 2,1 firmware accepts Clovertowns (CPUID 06F0h), but rejects Harpertowns (CPUID 0670h).



The processor-specific parts of the firmware are in the Pre-EFI Initialization section. It contains the PEI modules. The most important is the SEC core module, as it is the first one to be executed.

The EFI drivers in the .DXE modules are not processor specific. They do not need to be changed, unless you want to add new functionality to your Mac, like support for NVMe and APFS booting.



Upgrading a 2011 iMac with a Ivy Bridge CPU would be a great idea. The 2011 iMac is far more upgradable than the slim 2012 models. There is another thread on processor upgrades.

CPU Upgrade iMac Mid 2011

This is a Wiki post with information collected from the entire thread. Before you post, read this first. The difference between Mid 2011 21.5" and 27" concerning CPU upgradability is mainly caused by the available power from the power supply. --- The 21.5" has 210W power supply, the 27" has...

forums.macrumors.com

The GPU also needs to be upgraded to run modern versions of macOS.

2011 iMac Graphics Card Upgrade

iMac 2009 to 2011 MXM3 graphics card upgrade (Lastest update 10/13/2023 - this is the official documentation page - you found it finally!) This is the single and only documentation post. During the last years we constantly updated this post to reflect the lastet development of vBIOS and OCLP...

forums.macrumors.com

Update September 14, 2021:

I extracted the SEC-core module from the 27 inch firmware file provided by @StephN999 using UEFITool. I then opened it using Hopper Disassembler V4. I found three places where the code looks at the CPUID. Two of these are at the start of the module, where the code loads the microcode.

In the first case the code loads the CPUID into the EAX registers and scans the section of memory containing the microcodes for a match. If it finds a match, it does another check to see if the CPU is an Arrandale (0x20650), or an "Auburndale" (0x106F0). If so, it does some additional processing.

The last part of the code (wrmsr) writes the start address of the microcode into Model Specific Register 0x79, causing the processor to load the microcode from memory.

View attachment 1830886

I cannot see why the firmware code would reject an Ivy Bridge processor, not even when no microcode is present.

Hello, thanks for research on this! I'll try to continue pushing this a bit further.

For now my tests have been around microcode changes on the iMac 12,2. Since @dosdude1 Microcode tool does not work properly on our bios, I have made all changes to bios microcode volume manually, then fixed volume CRCs, flashed bios with clip and tested results.

Tests done on iMac 2011 12,2 with an i7-2600 (CPU ID 206A7), bootrom 87.0.0.0.0 originally with microcode for 206A3 (rev. 8), 206A5 (rev. 7), 206A6(rev. 28) and 206A7 (rev. 2F)

Summary of tests and results:

Remove all microcode	No POST
Remove 206A7 microcode, leave all others	No POST
Move 206A7 microcode to 1st place, remove all others	POST
Add Ivy Bridge 306A9 microcode, leave all others	POST
Remove all SB microcodes and add Ivy Bridge 306A9	No POST
Downgrade 206A7 microcode to revision 14	POST
Use just 206A7 rev 14 and Ivy Bridge 306A9	POST

So, every time I removed 206A7 microcode iMac did not POST (no chime, fans at full speed after a short time). As soon as a 206A7 microcode is present (revision or position inside microcode list does not matter), the iMac POSTs fine.
Removing or adding other CPU microcodes does not change results.

It seems clear the 2011 iMac bios needs the CPU microcode present on the bootrom to POST, otherwise it halts boot process.

It would be nice for further testing if we could have this check removed, so the iMac would boot without cpu microcode at all.

 

[m0bil]

I have recently found out the reason of some "duplicated" sections inside the firmware images and what's their intended use. Using UEFITool to look inside firmware images you'd have noticed some sections appear duplicated:

While this sections share the same GUID, notice the Base and Data Address are slightly different:

This is due to a "recovery mechanism" implemented in the PCH, called "Top-Block Swap".

I think during a firmware update a register is used on the CMOS "ram" to indicate the PCH which top-block should be used to boot from the spi flash so, in case of flashing failure, the alternate Boot Block would be used on next boot.
So, in normal boot only the first of the duplicate section is used, and the second is a backup to attempt some kind of recovery in case of failed firmware update.

When modding firmware I guess it's a good idea to keep both the same, but anyway this old macs won't see any more official firmware updates that would make use of this feature.

 

[m0bil]

iMac 12,x Turbo Overclocking

This firmware patch enables CPU Turbo Overclocking and allows setting the Max Turbo Multipliers of the CPU.

Background​

After working for some months in my own overclocking code, I found out that large parts of the Intel reference code to setup Turbo Overclocking were already included in the iMac firmware. While some parts are missing, it's way better to use this code and patch the missing bits.

How it works​

Turbo Overclocking allows the CPU to reach core multipliers above its rated Processor Base Frequency.
The number of Turbo Bins (Intel terminology for a 100MHz multiplier) is fused at manufacture time, and the CPU will not run above its fused value.
For Sandy Bridge non-K cpus Turbo Overclocking is limited to 4 Bins above the Processor Base Frequency.
For -K CPUs the number of Bins is unlimited. For Xeon CPUs the number of Bins is 0.
Also, on standard setup the Turbo Bins depend on the number of active physical cores: 4 Bins are used when only one core is used, 3 Bins when 2 cores are used, 2 Bins when 3 cores are used and 1 Bin when all 4 cores are used.
As an example, an i7-2600 CPU with Processor Base Frequency rated at 3400 MHz will Turbo run at 3500 MHz when 4 cores are used and at 3800 MHz when just one core is used.

This patch allow independently setting the Max Core multipliers depending on the number of physical cores used. You will mostly always set the four max core multipliers to the same value.

For ease of use I have provided two version of the patch, one sets the 4 max multipliers to x40, and another that sets them to x44, otherwise they are identical. You can also look inside the patch and set your own max multiplier values.

This patch also works for non-K cpus. Setting the max multiplier to the same value on a non-K cpu will allow all four cores to run 4 Bins above the Processor Base Frequency (instead of just one Bin). This means an i7-2600 can run 4 cores at 3800 MHz instead of 3500 MHz without the patch, a nice ~8% speed increase in multi-core use.
For non-K cpus you can set the max multiplier higher than the cpu supports, but it will not run faster than the fused value, so you can use the x40 patch for non-K cpus safely.

Expected speed increase​

Sandy Bridge is one of the most overclock-friendly CPUs intel made, the -K CPUs can reach above 5GHz when properly cooled and setup. In an iMac 12,2 with standard cooling 4x44 up to 4x46 speeds have been tested and proved stable without the need of overvolting the CPU (We are lucky that the iGPU is not used in the iMac).
Real world speed increase can range from around 8% for an i7-2600 when using 4 cores, up to above 20% when using an i7-2700K. Higher speed ram may also help there.

Possible improvements​

While setting the max multipliers at firmware level is not ideal, it would be possible to develop an UEFI firmware module that reads values from NVRAM and sets them at runtime, but I currently have no time for it.

I have also tried to delay setup of the max multipliers after bios init, to see if they could be setup using an Opencore module, but for some reason Intel put a watchdog timer that resets the PCH if all power management of the CPU is not done early enough after boot. This means the max multipliers have to be setup at a very precise moment during EFI boot.

Notes​

Many thanks to all people who have helped testing this!!!

• Tested on iMac 12,2 with bootrom 87.0.0.0.0.
• May work on other macs with Sandy Bridge CPUs, pending to be tested.
• Not all CPUs are made the same. To be sure yours is stable after patching, run a stress/torture test, using Prime95 or similar, around one hour to be sure the iMac does not hang. Keep an eye on temperatures, according to Intel TJuncMax for Sandy Bridge is 98°C, so I'd try to keep temps in the low 80s at most.

​

How to apply patch​

I have started a Github repository to better keep track of firmware patches, this patch is there.

 

[Ausdauersportler]

About (using) the (patched) write protection:

Got all this information from @m0bil directly, so all credits to him!

1. Applied the patch to my iMac12,2 test system firmware dump and rewrote it using a (Pomona) CH341A clip programmer.
2. Pulled the GRML full distribution iso from grml.org
3. Flashed it using Balena Etcher to an SD card (which was formatted in GUID and named GRML before).
4. Booted the GMRL distro (it will be shown on the OpenCore boot Picker as GRML)
5. Used the Start ssh command to enable remote ssh access
6. setup a password using the passwd command
7. started access from my local work station and moved the modded new firmware file named modded.bin over
8. flashed it using flashrom --programmer internal -w modded.bin
9. (optional) try again using the chip type flashrom --programmer internal -c MX25L6405 -w modded.bin

The flash may fail on the first attempt when flashrom cannot identify the correct flash chip type, but the software will print out all available options, four in my particular case.

Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F"

Please specify which chip definition to use with the -c <chipname> option.

Pick one and try again as shown in step 9. Normally it does not matter which chip definition you pick, on all my tests the read attempts got identical binary files using all different chip types listed.

Read the output of the flashrom command, it should come up with an success message!

Creating a new flash utility based on GRML (full):

Using the GRML tool grml2usb one can write the distribution is to a normal USB Stick adding boot-options. This tool works only within GRML and so I started the Balena Etcher generated tool, started ssh and copied the distribution iso file to the /root folder via scp.

In the next step I formatted an SD card/USB Stick using the macOS disk utility FAT32/GUID and named it FLASH. Using a particular name is necessary to identify the device in the next step.

From the GRML command line it is not hard to find the correct device, in my case it was /dev/sdc2, just try devices a, b, c like this (we are searching for a media named FLASH of type vfat)

% mount /dev/sdc2
% mount | grep sdc2
/dev/sdc2 on /media/FLASH type vfat .....

Here we are ready to copy the files....

grml2usb --bootoptions="keyboard=de ssh=flash persistence" --skip-bootflag grml64-full_2021.07.iso /dev/sdc2

Just to confuse you all, the keyboard=de sets keyboard type to German, which I usually have around here. You can either delete the setting or adapt it to your local needs.

Fine tuning:

Later you can create a folder named flash on the USB Stick from macOS to copy and keep your persistent files. Within the flash folder I created two more folders Video and Firmware to keep all vBIOS files and tools in the Video folder and iMac firmware files in the Firmware folder.

Now we have a single USB utility to flash iMac firmware and iMac vBIOS - download the Swiss army knife of BIOS hackers...

 

[Petri Krohn]

As I will soon receive my Ivy Bridge processor and test it on my iMac 2011, I made a simple modification of the intel Microcodes.

People erroneously think that upgrading a firmware's set of microcodes will make the computer support newer processors. This is false. Microcodes are errata. No processor sold should need microcodes to boot. Besides, the operating system loads a newer version of microcodes anyway.

Experience shows that adding microcodes to Mac firmware will make the system less likely to boot.

New processors models for any socket are always made fully compatible with older hardware. Features are added, not deleted. Processor compatibility is limited by badly written firmware. In some cases (Dell) this is intentional.

When a firmware starts running one of the first things it does is calls CPUID (op code 0F A2). Good firmware checks the processor family, and if it actually has specific code for multiple families, chooses the appropriate branch. Bad firmware checks for a specific processor model number and halts if it is not an exact match.

To fix the firmware you should do the same kind of disassembly and analysis as I have done for the Mac Pro 2,1 firmware. Start reading from this post:

updating a Mac (Pro)s CPU Microcode

In the seven years the DELL Precision 690 microcode update thread has been up on the bios-mods.com site no one has figured out how to run Harpertowns or even to boot with quad-core Clovertowns on the wrong motherboard revision. User DeathBringer has however posted this insightful piece of code...

forums.macrumors.com

The Mac Pro 2,1 firmware accepts Clovertowns (CPUID 06F0h), but rejects Harpertowns (CPUID 0670h).

I replaced as planned :

CpuIoDxe BAE7599F-3C6B-43B7-BDF0-9CE07AA91AA6
CpuInitDxe 62D171CB-78CD-4480-8678-C6A2A797A8DE
PchInitDxe DE23ACEE-CF55-4FB6-AA77-984AB53DE823
PchS3Peim 271DD6F2-54CB-45E6-8585-8C923C1AC706
AppleMemoryTest 60A14F6F-55B9-47A3-B067-01A93027F3FE
PowerMgmtDxe F7731B4C-58A2-4DF4-8980-5645D39ECE58
CpuInitPei x2 01359D99-9446-456D-ADA4-50A711C03ADA
MemoryInit x2 3B42EF57-16D3-44CB-8632-9FDB06B41451
PchInitPeim x2 FD236AE7-0791-48C4-B29E-29BDEEE1A838
S3ResumePei x2 8BCEDDD7-E285-4168-9B3F-09AF66C93FFE
CpuS3Pei x2 C866BD71-7C79-4BF1-A93B-066B830D8F9A

The processor-specific parts of the firmware are in the Pre-EFI Initialization section. It contains the PEI modules. The most important is the SEC core module, as it is the first one to be executed.

The EFI drivers in the .DXE modules are not processor specific. They do not need to be changed, unless you want to add new functionality to your Mac, like support for NVMe and APFS booting.

The socket can be used for IvyBridge, the firmware not. This is all this thread is about.

Upgrading a 2011 iMac with a Ivy Bridge CPU would be a great idea. The 2011 iMac is far more upgradable than the slim 2012 models. There is another thread on processor upgrades.

CPU Upgrade iMac Mid 2011

This is a Wiki post with information collected from the entire thread. Before you post, read this first. The difference between Mid 2011 21.5" and 27" concerning CPU upgradability is mainly caused by the available power from the power supply. --- The 21.5" has 210W power supply, the 27" has...

forums.macrumors.com

The GPU also needs to be upgraded to run modern versions of macOS.

2011 iMac Graphics Card Upgrade

iMac 2009 to 2011 MXM3 graphics card upgrade (Lastest update 10/13/2023 - this is the official documentation page - you found it finally!) This is the single and only documentation post. During the last years we constantly updated this post to reflect the lastet development of vBIOS and OCLP...

forums.macrumors.com

Update September 14, 2021:

I extracted the SEC-core module from the 27 inch firmware file provided by @StephN999 using UEFITool. I then opened it using Hopper Disassembler V4. I found three places where the code looks at the CPUID. Two of these are at the start of the module, where the code loads the microcode.

In the first case the code loads the CPUID into the EAX registers and scans the section of memory containing the microcodes for a match. If it finds a match, it does another check to see if the CPU is an Arrandale (0x20650), or an "Auburndale" (0x106F0). If so, it does some additional processing.

The last part of the code (wrmsr) writes the start address of the microcode into Model Specific Register 0x79, causing the processor to load the microcode from memory.

I cannot see why the firmware code would reject an Ivy Bridge processor, not even when no microcode is present.

 

[dosdude1]

Problem in the iMac is not really the Z68 PCH, which supports Ivy Bridge, but the fact that Intel integrated what used to be the North Bridge inside the CPU.

This North Bridge is, from Sandy Bridge on, part of the CPU (and called now SA - System Agent) and includes the Memory Controller, PEG (PCI Express Graphics), DMI (the bus used to communicate the CPU and the South Bridge) and the iGPU.

The code that initializes and configures all System Agent devices (MRC/PEG/DMI/iGPU) is part of the UEFI bios and largely different between Sandy Bridge and Ivy Bridge, as on Ivy Bridge the Memory Controller supports faster and lower voltage memory, PEG is upgraded from 2.0 to 3.0 and also some DMI features were upgraded. The iGPU is the least problem as it can be fully disabled on the iMac. The iMac bios just knows nothing about Ivy Bridge SA and hangs midway at boot, probably trying to initialize memory.

Sadly there seems not to be an easy fix for that...

Coreboot is probably the only way. If someone could grab a copy of their stock 2011 iMac's ACPI (just use MaciASL, and save the system DSDT), I can create a port of Coreboot that should work on the machine, with both Sandy Bridge and Ivy Bridge CPUs. It'll have to be flashed initially externally via an EEPROM programmer.

 

[dosdude1]

Yeah, but what about the iMac GPU ??? As far as I know coreboot's libgfxinit only supports Intel's integrated graphics (iGPU), and on the iMac there is no muxer and the iGPU is not even connected to the display, so it needs 100% the dGPU to drive the display...

I know there are some options in coreboot to add a discrete vga bios from a file, would this work and be enough?

I don’t use libgfxinit, in fact if you do, OS X won’t work properly. You can tell Coreboot to run option ROMs of PCIe video cards, so that’s exactly what I’d do.

 

[m0bil]

I've been testing former patch with a couple of 1600 MHz CL11 (average latency) dimms on the iMac 12,2 vs the stock 1333 MHz CL9 memory. CPU used on testing was a slightly overclocked i7-2700k @ 4GHz.

I did not expect much gain due to slower latency on the 1600 MHz memory, but at least the synthetic benchmarks show good performance.

Geekbench 5 @ 1333 MHz CL9 (Windows):

Geekbench 5 @ 1600 MHz CL11 (Windows):

Note that some individual scores like clang compiler are slower on the 1600 MHz memory, probably due to slower latency, but overall there is a nice gain.

Also 3DMark Time Spy shows a nice 3411 CPU Score:

On real gaming with a 2023 released AAA game (RE4 Remake, which is well optimized) I'm getting consistent 60fps at native 2560x1440 resolution, while I was getting around 54 fps with the 1333 MHz memory. CPU temp was high, around 75ºC with fan at full speed.

 

[m0bil]

The problem is probably due to a bug in the MRC code (the one in the MemoryInit module, responsible for the initialization of the Memory Controller). The MRC code in the iMac seems to be an early release from Intel and probably was not well tested with higher speed ram modules. It is also possible Memory Controller needs a bit of overvolting to support 2x1867 memory, I'll take a look to see if that is possible.

While the official specifications from Intel state that the i7 only supports up to 1066/1333 MHz memory, the Memory Controller is basically the same used on Ivy Bridge, and capable of supporting up to 2133 MHz memory. This has been tested on other OEMs like Asus with same Z68 chipset as the iMac.

 

[m0bil]

Hi guys,

Would someone be able to outline the benefits of the "iGPU (IGD) full disable" patch?
Does this help with CPU temperatures?
Free up CPU processing power?
Or is there another reason?

Cheers
Andrew

It will free some hardware resources: 128MB or 256MB shared ram (don't recall exactly) and a few irq/dma/dmi resources, but I doubt it will have any impact in cpu temp or processing power. The reason I did this patch is to avoid the annoying Windows BSOD when loading Intel Graphics Kernel Mode driver (igdkmd64.sys) after a windows install.

 

[Maggehagge]

I DID IT! Well goal achieved but i dont know if i actually did much but still: IMAC 2010 OVERCLOCKING SUCCESSFUL!

Turbo ratio changed and turbo power limit changed to allow boosting on all cores all the time. I could reach more than x28 stable. Only 1x higher than 1 core turbo. But still big increase. Standard max Watt is 95 W and if you look at the bottom of my screenshot you see that i am at 125 W currently.

I will post how to do it here:

https://forums.macrumors.com/threads/imac-2010-11-x-successful-overclocking-achieved.2456616/

 

[dosdude1]

Although not directly related to the topic of this thread, I figured I'd post about this here to see if anybody had any ideas. Recently, I replaced both the CPU and PCH on a 2011 17" MacBook Pro logic board with those from an Ivy Bridge Mid-2012 15" MacBook Pro, upgrading the PCH from the original HM65 chipset (which does not support Ivy Bridge CPUs) to HM77, and the CPU to a Core i7 3720QM. With that done, utilizing an SPI-ROM dump from a MacBookPro9,1 flashed onto the 2011 board, I actually got it to boot, but it has many issues, mainly due to the fact that Apple repurposed many of the GPIO pins of the PCH on the 2012 MBPs. As such, running an unmodified BootROM for a Mid-2012 MBP does not work well (as it, of course, assumes the GPIO pins are connected as they are on a 2012 MBP logic board). Along with other things, the integrated video did not work, so the only way I was able to access the machine and confirm it booted was via Remote Desktop. (The AMD GPU is defective and is fully disabled using DeMux firmware).

With that said, I think the only good solution here is to somehow add support for the newer HM77 PCH, along with of course support for the Ivy Bridge CPU, into the original MacBookPro8,3 BootROM. I have already attempted adding the correct 306A9 CPU microcode, as well as replacing the ME region with ME8.0 (for HM77 chipset), neither of which made any difference. I do plan to look into this more myself, but for now I figured I'd post here to see if anyone else had any ideas. I should also note, that when attempting to boot with the MBP8,3 original BootROM, it seems to kind of work (the optical drive initializes, which means PCH is at least being initialized), but it doesn't chime or POST.

EDIT: I have attached the SPI-ROM dumps of both machines (the MBP8,3 board shown here, as well as the MBP9,1 board I took the CPU and PCH from).

 

[m0bil]

Awesome, thanks for the info, that may just be the solution.

Also, one thing to be aware of is that the HM65 and HM/QM67 chipsets do NOT support Ivy Bridge in any capacity. Only HM61 does (with correct BIOS support), which is... Odd. So if the iMac 12,x has HM65/HM67/QM67 (I can’t remember off the top of my head, but I think it does), a PCH replacement will be required in order to get an Ivy Bridge CPU working.

The 2011 iMacs have a Z68 chipset that should support Ivy Bridge (at least the 3770 cpu).

On my tests with updated ME8 and 306A9 microcode, the boot stalls somewhere on the early PEI phase, most probably the MemoryInit module (SEC phase is very short, I have fully disassembled it and there's nothing in it that would prevent IB booting).

Big problem is not having a mean of debug, as I've tried some patching but don't know if either it's working and stalling at a later bios module, or not working at all.

Besides very expensive JTAG equipment I don't have access to, I found there is a "Frank" J5100/J6100 connector on the logic board that routes LPC port 80 debug codes, connecting that to a debug card would be enough to at least know where boot is stalling and make patching way easier. I think this connector is populated in MacBooks, but on the iMac I have to solder it to the logic board, that's what I'm (slowly) working on now...

 

[dosdude1]

does it use gmux dual gpu? you using libgfxinit? what payload are you using? if grub2 payload it need a patch first else it hangs?
so its different in dual vs not changing the ads file? this machine have your solder mods? does it show screen in retail bios? does caps lock toggle off and on or external usb keyboard connected can toggle caps lock?

the line is maybe grub2 hanging but i dunno your payload or what u using libgfxinit

you can try get flashconsole log to see if panel resolution is detected and if it jumped to payload
or usb ft232 logging (try find_debug.sh script in the utils dir) I didn't try which port for macbookpro8

(the macbookpro10,1 its on the right side usb with laptop face you normal use), but need disable usb 3.0 in devicetree.cb


edit
i think the ch1p builds is using mbp8,2 which have gmux. you might have to remove the code with gmux in devicetree.cb and other place and also there is a some early_init.c iirc that inside set to disable the dgpu or enable and also accidently disable the root hub switch (due to some logic error that applied to the levono where it was copied from and that when apply will cause thunderbolt to not init properly. i have fix for that and efi-properties- injection fix for eprom thunderboltdrom later if you get to that part too

I've finally gotten back to working on this, and so far I have now been able to get Coreboot working successfully on my testing 2011 13" MBP8,1. However, using the same build on a completely stock, unmodified 17" MBP8,3 won't boot, it seems to hang (not just show no video). I checked all the GPIO configs, device tree, etc. and all looks good (and matches up exactly with that of MBP8,1 according to schematics). The only difference is the AMD GPU (which I've already disabled via DeMux), and gMux IC (which of course is set to always use iGPU with DeMux). Hopefully I can get some sort of UART or console output from it for debugging, and figure out what the issue is.

 

[m0bil]

Could you also run Coreboot autoport under Linux on the machine as well? That'll provide me a good starting point, and get me a decently accurate PCH GPIO layout. Info can be found here.

Here are my autoport files. Also iMac 12,2 but since it's my "lab" one has iGPU disabled at hardware level, cleaned Intel ME 8 and Nvidia Pascal dGPU. Also a "lspci -nnv" with all PCI devices/vendor/subsytem ids.

 

[StefanAM]

well, it is a standard Macronix MX25L3205D 3.3v 32M-BIT eeprom chip, should be easily flashable with the CH341A.

You can try manually selecting the model (instead of auto recognize by software). BTW, which software are you using for flashing ??? I've seen some weird cases where AsProgrammer fails but flashrom succeeds on flashing (I've seen this happen on SST chips in 2010 iMacs, but never on Macronix).

Also you can try disconnecting all cables and from logic board before flashing, maybe that helps too.

I finally did it. I changed the CH341A programmer and computer and used SigeriaProg v1.45. Auto set and everything OK. After I put all the harware back, at boot, series of 3 beeps, non stop. I turned it off manually 2 times. The third time I heard the lovely chime and all is well. I want to say a big thank to those who tried to help me! I really apreciate!

 

[m0bil]

Hehhehehehehh! Strange, but nice!

With current CPU power configuration the only limiting factor is CPU temperature, as long as it stays below 80ºC it should be quite safe (and also the cpu has temperature throttling protection).
I've been running my 2700k at 4x41 without problems for some months, and have tested it up to 4x44 but temps got a bit too hot for my liking.
Above 4x44 it may be needed to overvolt the CPU a bit for stability (I know where this setting is), but I think it's not a good idea to hardcode that into firmware... and the cooling capabiities of the CPU fan/heatsink would be at it's limit anyway, so I'm not including that on the patch for now (maybe as a comment in the final release).

Inside the patch I sent you the CPU core multipliers are explained in the comments, so you can change (raise) them to your liking if want to test higher speeds.

Will release the patch to the public in the coming days, as soon as I find some time to write instructions/readme.

 

[tsialex]

I asked a special question - if I delete the pointer on socket 1155, and insert the processor, will it work at all??? I know it won't physically happen. But the shape is the same.

Already answered that, it's not compatible electrically or logically - different pin-out, different voltage levels, different PCH.

In a 2011 iMac you can't even use a 1155 gen3 Intel processor, while physically compatible, it's not firmware (and probably also PCB design) compatible.