Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iM 4,1-14,4 iMac 2011 (see more) UEFI Firmware Mod
- Thread starter StephN999
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Intel Management Engine?
I had a look at Intel® Desktop Boards with Intel® Z68 Express Chipset to see what changes were made to the firmware to enable Ivy Bridge CPUs. I found a valuable tip on a Tom's Hardware forum: Ivy Bridge CPUs need ME version 8 firmware.
The Management Engine sits in the Z68 Platform Controller Hub. The firmware for the Management Engine shares the same SPI ROM with the EFI boot ROM. To enable Ivy Bridge processors we may need to replace version 7 ME code with version 8 code made for the Z68 chipset. One possible source for the ME code is version 0040 (or newer) BIOS update for the Intel DZ68DB motherboard.
More on the Intel Management Engine here:
I had a look at Intel® Desktop Boards with Intel® Z68 Express Chipset to see what changes were made to the firmware to enable Ivy Bridge CPUs. I found a valuable tip on a Tom's Hardware forum: Ivy Bridge CPUs need ME version 8 firmware.
The Management Engine sits in the Z68 Platform Controller Hub. The firmware for the Management Engine shares the same SPI ROM with the EFI boot ROM. To enable Ivy Bridge processors we may need to replace version 7 ME code with version 8 code made for the Z68 chipset. One possible source for the ME code is version 0040 (or newer) BIOS update for the Intel DZ68DB motherboard.
More on the Intel Management Engine here:
Intel Management Engine?
I had a look at Intel® Desktop Boards with Intel® Z68 Express Chipset to see what changes were made to the firmware to enable Ivy Bridge CPUs. I found a valuable tip on a Tom's Hardware forum: Ivy Bridge CPUs need ME version 8 firmware.
The Management Engine sits in the Z68 Platform Controller Hub. The firmware for the Management Engine shares the same SPI ROM with the EFI boot ROM. To enable Ivy Bridge processors we may need to replace version 7 ME code with version 8 code made for the Z68 chipset. One possible source for the ME code is version 0040 (or newer) BIOS update for the Intel DZ68DB motherboard.
More on the Intel Management Engine here:
Thanks! I tried this when it was clear that microcode update alone would not work, in fact I've been running version 8 ME (me_cleaned) on my Z68 test iMac (using Sandy bridge) for months without issues.
I copied all ME settings from an Asus Z68 bios that supports Ivy Bridge just in case it makes a difference. I also tried coping the iMac version 7 ME configuration to version 8 ME, it worked but I noticed no differences.
Big problem still seems the CPU System Agent init code, specifically the Integrated Memory Controller, which checks cpu steppings and forks code depending on them. Steppings are very different on SB and IB, and iMac firmware MemoryInit code is unaware of IB steppings.
I think the IMC configuration is different on SB and IB, as IB supports low voltage and faster memory, but code may be backwards compatible up to some point. I also have pending to investigate if PCI Express bus configuration is done differently on SB and IB...
Last edited:
Hello. iMac 21 2011 when updating Mac OS, the computer rebooted and when turned on, it began to emit signals: 3 short, 3 long, 3 short and starts to reboot, and then everything starts over again. After searching the Internet, I realized that this is an SOS signal - damage to the memory of the EFI firmware. Can you dump the firmware ? Will flashing with a programmer help ?
Just take OUT RAM and re-insert. Clean contacts. This has nothing to do with firmware.
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.
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.
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.
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.
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.
Well, with the help of Coreboot, here it is... A 2011 17” MacBook Pro running with Core i7 3720QM and HM77 PCH!
Awesome!!!
Wonder if coreboot could be made to work on the 12,x 2011 iMacs (no iGPU, only dGPU).
Hi @dosdude1 - If it's okay to ask, is the firmware driver/mod/patch which you used for this available anywhere?
I've tried disabling the dGPU on a MacBookPro10,1 using NVRAM
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-power-prefs=1, and also tried using NVRAM GfxMode=0 and GfxMode=4. These all do seemingly disable it, but the machine is unbootable. I've been assuming the issue is _something like_: the machine powers up in dGPU always, for EFI and onwards into the next OS; and it is only in macOS that it swaps over to using the iGPU for low power features. Therefore, if you disable the dGPU early, the machine won't start, or rather hangs very early in the boot sequence. I am happy to have any of this corrected/clarified, by anybody who knows better.I don't actually have a broken dGPU, I bought this machine for testing, I was just trying to investigate how to do this cleanly, for people who do have broken dGPUs, but only got this far.
- https://github.com/acidanthera/OpenCorePkg/pull/390
- https://github.com/acidanthera/OpenCorePkg/pull/338
- https://github.com/acidanthera/bugtracker/issues/928
PS Amazing work on the Sandy Bridge to Ivy Bridge upgrade!
It is, but it's not compatible with Retina machines. Only 2011 and 2012 non-Retina machines. Not sure if it would make any difference in this case, but the NVRAM command I know works is:Hi @dosdude1 - If it's okay to ask, is the firmware driver/mod/patch which you used for this available anywhere?
I've tried disabling the dGPU on a MacBookPro10,1 using NVRAMFA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-power-prefs=1, and also tried using NVRAMGfxMode=0andGfxMode=4. These all do seemingly disable it, but the machine is unbootable. I've been assuming the issue is _something like_: the machine powers up in dGPU always, for EFI and onwards into the next OS; and it is only in macOS that it swaps over to using the iGPU for low power features. Therefore, if you disable the dGPU early, the machine won't start, or rather hangs very early in the boot sequence. I am happy to have any of this corrected/clarified, by anybody who knows better.
I don't actually have a broken dGPU, I bought this machine for testing, I was just trying to investigate how to do this cleanly, for people who do have broken dGPUs, but only got this far.
- https://github.com/acidanthera/OpenCorePkg/pull/390
- https://github.com/acidanthera/OpenCorePkg/pull/338
- https://github.com/acidanthera/bugtracker/issues/928
PS Amazing work on the Sandy Bridge to Ivy Bridge upgrade!
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
Thank you very much for the reply and info. Yes, I just spotted in the Linux code that the whole setup for retina machines is completely different! (Which means I really don't have the right machine for testing this. :-( )
That is really awesome work! Like always, you do not fail to impress!
But like you said many times in the comments on yt, it was essential to replace the HM65 as it cannot support Ivy Bridge CPUs. The iMac with its Z98 PCH should though... The Macbook is a lot of work to upgrade, sourcing a faulty ligic board, desoldering cpu and pch and soldering them back up... That requires godly skills like yours! The iMac on the other hand has a socketed cpu and a pch that "should" work but doesn't.
Do you by any chance own a 2011 iMac?
Thanks for all the incredible things you bring to this community.
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 IMC (Integrated Memory Controller), PEG (PCI Express Graphics), DMI (the Intel 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...
Last edited:
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.
Here you go!
@m0bil already found a way to software flash the iMac12,2 (okay to apply this patch it needs at least one clip flash).
Ready to help!
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?
@m0bil - I assume @dosdude1 must have proceeded by using coreboot to set up the CPU, and then continuing into some/most of the native BIOS to get ready for macOS.
@dosdude1 - Is that correct, or were you able to completely replace the existing BIOS with coreboot + appropriate config? If it's okay to enquire into the trade secrets of getting this impressive stuff working!
EDIT: Actually, I _think_ I can answer - @dosdude1 I think you already answered - my question: I think you used _just_ coreboot, and then OpenCore to turn the Mac back into a Mac again? In which case ofc @m0bil's question still applies, and it is (just?!) a matter of finding the right driver(s) in the iMac firmware
@dosdude1 - Is that correct, or were you able to completely replace the existing BIOS with coreboot + appropriate config? If it's okay to enquire into the trade secrets of getting this impressive stuff working!
EDIT: Actually, I _think_ I can answer - @dosdude1 I think you already answered - my question: I think you used _just_ coreboot, and then OpenCore to turn the Mac back into a Mac again? In which case ofc @m0bil's question still applies, and it is (just?!) a matter of finding the right driver(s) in the iMac firmware
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.
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.
Attached you will find the logs - guess you were asking for these files?
Code:
install@install-iMac:~/Documents/Development/CoreBoot/coreboot/util/autoport$ sudo ./autoport --input_log=logs --make_logs --coreboot_dir=../..
WARNING: The following tool MAY cause your system to hang when it attempts to probe for graphics registers. Having the graphics registers will help create a better port. Should autoport probe these registers?. (y/yes/n/no) Default:y
PCH sound card is card0
Unsupported PCI device 8086:1c2c
Unsupported PCI device 8086:1c27
Unknown PCI device 1002:6821, assuming removable <--- AMD GPU
Unknown PCI device 1002:aab0, assuming removable <--- Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series]
Unknown PCI device 14e4:16b4, assuming removable <--- NetXtreme BCM57765 Gigabit Ethernet PCIe
Unknown PCI device 14e4:43ba, assuming removable <--- BCM43602 802.11ac Wireless LAN SoC
Unknown PCI device 11c1:5901, assuming removable <--- FW643 [TrueFire] PCIe 1394b Controller
Unknown PCI device 8086:1513, assuming removable <--- CV82524 Thunderbolt Controller [Light Ridge 4C 2010]
Unknown PCI device 8086:1513, assuming removable
Unknown PCI device 8086:1513, assuming removable
Unknown PCI device 8086:1513, assuming removable
Unknown PCI device 8086:1513, assuming removable
Unknown PCI device 8086:1513, assuming removable
Unknown PCI device 8086:1513, assuming removable
install@install-iMac:Edit: Added scr folder and lspci logs.
Last edited:
It should also produce a directory containing some configuration files for Coreboot. I'll need those as well.
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.
Last edited: