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

m0bil · Dec 9, 2021

Hi @StephN999 !

now that @FlorisVN has asked about this, I see you made some testing with updating Intel ME from version 7 to version 8 on the 2011 iMac. Did that work ? If so, what IME 8 did you use ? I don't know if IME is fully generic (depending only on chipset), or Apple has made some adaptations to it on the iMacs.

I'm thinking of doing some IME tests for GPUs that don't POST on the 2011 iMac, and testing an IME 8 may be a good idea (I saw on other forums, some laptops required upgrading IME 7 to 8 for some GPUs to POST).

vmbl · Feb 16, 2022

Hi,

I don't think this is the solution to unlock support for Ivy Bridge processors, but I figured this would be interesting info in the future maybe...

Ausdauersportler · Feb 16, 2022

vmbl said:
Hi,

I don't think this is the solution to unlock support for Ivy Bridge processors, but I figured this would be interesting info in the future maybe...

Basically @StephN999 did exactly this using a different flasher and different modules. He took modules from iMac13,x firmware supporting IvyBridge and tried to replace the SandyBridge parts within the iMac12,x firmware.

Nevertheless an interesting video!

protocold · Feb 17, 2022

Petri Krohn said:
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.

Many thanks for your detail investigation!

I am quite confused with this thread, I saw mod attempts on logo and stuff but did someone actually tried to install an Ivy Bridge processor with the stock firmware? What happened?

m0bil · Feb 18, 2022

protocold said:
Many thanks for your detail investigation!

I am quite confused with this thread, I saw mod attempts on logo and stuff but did someone actually tried to install an Ivy Bridge processor with the stock firmware? What happened?

There is another thread about it. In short, people tried to put an Ivy Bridge processor on stock firmware iMac 2011, but the iMac wont boot. Exact reason is unknown, most probably Intel ME needs to be upgraded from version 7 to 8, but there may be additional firmware changes needed.

Ausdauersportler · Feb 18, 2022

m0bil said:
There is another thread about it. In short, people tried to put an Ivy Bridge processor on stock firmware iMac 2011, but the iMac wont boot. Exact reason is unknown, most probably Intel ME needs to be upgraded from version 7 to 8, but there may be additional firmware changes needed.

If you read the comments @Petri Krohn posted there could be a decent chance to get it run without any firmware changes. Lately Ivy Bridge CPU became affordable and I am willing to test it on an iMac with a pretty old firmware version (just in case Apple did something to block it intentionally as Dell for some systems with an firmware upgrade).

Of course I have no idea who is right about it. I will buy an i7-3770 and make a quick test next. The iMac is on it‘s way to my lab ….

m0bil · Feb 18, 2022

Ausdauersportler said:
If you read the comments @Petri Krohn posted there could be a decent chance to get it run without any firmware changes. Lately Ivy Bridge CPU became affordable and I am willing to test it on an iMac with a pretty old firmware version (just in case Apple did something to block it intentionally as Dell for some systems with an firmware upgrade).

Of course I have no idea who is right about it. I will buy an i7-3770 and make a quick test next. The iMac is on it‘s way to my lab ….

Nice! I still suspect Intel ME upgrade to version 8 may be required, as the ME has a BUP (Bring UP) module responsible for initializing chipset. On laptops with Z68 chipset a bios update was required for Ivy Bridge support and there may be some Ivy Bridge specific initialization code on the ME8 not present in the ME7 (just a guess).

I'll try to take a look to see if it's possible to replace ME7 on iMacs firmware with a stripped down ("cleaned") ME8 containing just the ROMP and BUP modules. Maybe @StephN999 can share his experience with this, as I think he tried that too.

m0bil · Apr 19, 2022

Petri Krohn said:
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 · Apr 20, 2022

For reference, a quick guide on how to manually add, remove or modify microcodes on the iMac bios:

Microcodes are stored at UEFI volume with GUID 153D2197-29BD-44DC-AC59-887F70E41A6B
There are two identical copies of this on the bios, probably just one is used, but better modify both of them in the same way.

Size of volume is fixed 20000h (131072) bytes. Header size is 48h (72) and body size is 1FFB8h (131000).

Microcode starts at offset 100h from start of volume. Microcode blobs are stored one after the other and then FF padding is added until the end of the volume.

When changing volume contents, you have to update the CRC32 of the whole volume body (from offset 48h to end of volume). This CRC32 is stored at offset 8h of header, which is also offset 8h of ZeroVector. After updating this you have to recalculate header checksum at offset 32h.

You can use UEFITool NE to take a look at volume, as it shows microcode blobs and offsets inside the UEFI volume, and also to dump full volume contents. Note that UEFITool NE as of version 59 thinks wrongly that header size is 100h, so body extraction is done wrong. This is specially bad for body CRC32 calculation.
UEFITool is also useful to calculate and verify header checksum after updating body CRC32.

There is also a very convenient shortcut to all of this: if you ZERO the CRC32 value of the body checksum, volume body will be skipped by UEFI integrity tests (still need correct header checksum), so you can just edit header values like this and then freely modify body microcodes without having to recalculate any checksums:

This can be done with hex editor like Hex Fiend. Microcode volume is not compressed, so you can directly edit the bios file.

A full archive of all Intel microcodes can be found here.

jay508 · Apr 20, 2022

Prepared i7 2600 i7 2700k i7 3770 i7 4790 for testing

The epidemic control reason can not just go out, convenient for the test feedback results.

simie · Apr 22, 2022

Here is the tool you mention

Releases · LongSoft/UEFITool

UEFI firmware image viewer and editor. Contribute to LongSoft/UEFITool development by creating an account on GitHub.

github.com

a minimAluminiumalism · Apr 22, 2022

jay508 said:
Prepared i7 2600 i7 2700k i7 3770 i7 4790 for testing

The epidemic control reason can not just go out, convenient for the test feedback results.

View attachment 1994412

View attachment 1994415

Base 上海？Hope everything get better soon...Though it's really tough situation,waiting for your test

m0bil · May 9, 2022

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:

Code:

# 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.

Ausdauersportler · May 12, 2022

About (using) the (patched) write protection:

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

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

Code:

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)

Code:

% 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...

kocoman · Jun 27, 2022

I want to thank this thread for helping me "unlock" the spi on macbookpro10,1/2...
I tried to patch the jz to jmp etc but it didn't work, and the system would brick if i del the pchspi dxe..

so instead i patch the pr0 pr1 to the lower (me engine) range that I won't write anyway to fix it

the chipsec output is use the VALUE to encode the Base and limit

8 66F 0 190 | 00190000 | 0066F FFF

8 6D7 0 181 | 00181000 | 006D7 FFF

9 FFF0 692 | 00692000 | 01FFF FFF

9 FFF 0 6FC | 00 6F C0 00 | 01FFF FFF

9 is 01

XXXX0BCD | 00ABCD (last 2 always 0)

8 002 0 001 | 00001000 (end always 0) | 00002FFF (end always fff)

8 004 0 003 | 00003000 | 00004fff

so for me I want to set mines to
PR0: Warning: 0x00001000-0x00002fff is read-only.
PR1: Warning: 0x00003000-0x00004fff is read-only.
so I would just use this uefipatch

C194C6EA-B68C-4981-B64B-9BD271474B20 10 P:90016F86:01000280

C194C6EA-B68C-4981-B64B-9BD271474B20 10 P:9206FF9F:03000480

should work for other machines if you change the values out

the bios usually starts at 181000 or 190000, the region before that is the ME

this method can also apply to other pc that uses the spi pr0 lock method..? just search the value (chipsec) in reverse endian in uefitool and put your lower address to replace it

or can (havent test yet) change it to some region in 9mb area (for 8mb flash) etc or zero them out

m0bil · Aug 16, 2022

kocoman said:
I want to thank this thread for helping me "unlock" the spi on macbookpro10,1/2...
I tried to patch the jz to jmp etc but it didn't work, and the system would brick if i del the pchspi dxe..

so instead i patch the pr0 pr1 to the lower (me engine) range that I won't write anyway to fix it

the chipsec output is use the VALUE to encode the Base and limit

8 66F 0 190 | 00190000 | 0066F FFF
8 6D7 0 181 | 00181000 | 006D7 FFF
9 FFF0 692 | 00692000 | 01FFF FFF
9 FFF 0 6FC | 00 6F C0 00 | 01FFF FFF
9 is 01
XXXX0BCD | 00ABCD (last 2 always 0)
8 002 0 001 | 00001000 (end always 0) | 00002FFF (end always fff)
8 004 0 003 | 00003000 | 00004fff

so for me I want to set mines to
PR0: Warning: 0x00001000-0x00002fff is read-only.
PR1: Warning: 0x00003000-0x00004fff is read-only.
so I would just use this uefipatch

C194C6EA-B68C-4981-B64B-9BD271474B20 10 P:90016F86:01000280
C194C6EA-B68C-4981-B64B-9BD271474B20 10 P:9206FF9F:03000480

should work for other machines if you change the values out

the bios usually starts at 181000 or 190000, the region before that is the ME

this method can also apply to other pc that uses the spi pr0 lock method..? just search the value (chipsec) in reverse endian in uefitool and put your lower address to replace it

or can (havent test yet) change it to some region in 9mb area (for 8mb flash) etc or zero them out

Just setting PR registers to 0 is enough if patching the jump does not work. In fact the init code executed during an Apple firmware update just sets them to zero before the update.

kocoman · Aug 16, 2022

m0bil said:
Just setting PR registers to 0 is enough if patching the jump does not work. In fact the init code executed during an Apple firmware update just sets them to zero before the update.

View attachment 2043754

can this “apple fw update init code of setting to 0” be added to flashrom linux to unlock the pr for everyone?

m0bil · Aug 16, 2022

kocoman said:
can this “apple fw update init code of setting to 0” be added to flashrom linux to unlock the pr for everyone?

Not directly. Firmware updates are done by Apple using "scap" format, some kind of signed efi capsule, so existing uefi firmware checks digital signature of the firmware update before "unlocking" the eeprom write protection and starting the update.

I've been long thinking that maybe a manually forced firmware downgrade can re-introduce the very well known sleep/wake protection bug on Apple and other Intel platforms, where the eeprom protection (PR registers) are not restored after a sleep/wake cycle and allows the flashing of the eeprom using a pure software method.

This is yet to be tested, I'm not even sure we can force a firmware downgrade (in fact it looks like you can't).

kocoman · Aug 16, 2022

m0bil said:
Not directly. Firmware updates are done by Apple using "scap" format, some kind of signed efi capsule, so existing uefi firmware checks digital signature of the firmware update before "unlocking" the eeprom write protection and starting the update.

I've been long thinking that maybe a manually forced firmware downgrade can re-introduce the very well known sleep/wake protection bug on Apple and other Intel platforms, where the eeprom protection (PR registers) are not restored after a sleep/wake cycle and allows the flashing of the eeprom using a pure software method.

This is yet to be tested, I'm not even sure we can force a firmware downgrade (in fact it looks like you can't).

the ch1p mmga method does work. i tried before to convert retail bios to coreboot.(and shrunk intel me in the process). but then when trying to use coreboot with osx boot i think the full intel me is needed for the imei hdcp some playback protection check to fully enable hd4000 metal/opengl acceleration. now i got coreboot/tianocore to work with montery (with oclp) or big sur without oclp

protocold · Aug 16, 2022

sorry did you mean you got coreboot on iMac 2011?

kocoman · Aug 16, 2022

protocold said:
sorry did you mean you got coreboot on iMac 2011?

i got monteney working on 3rd gen systems (some with autoport). (you need to use tianocore as the payload not seabios) to get some hd4000 and dsdt ssdt fixes that would cause kernel panics. now i am trying sd card boot.. i am able to disable uhs but got the waiting for root device. for other devices i have 4th and 6th gen but have not got time to work on getting coreboot on those yet. so while i am still around anyone who want to try or have questions can ask me while i still can tell you the answers instead of forgetting

Borak · Aug 28, 2022

Ausdauersportler said:
About (using) the (patched) write protection:

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

Applied the patch to my iMac12,2 test system firmware dump and rewrote it using a (Pomona) CH341A clip programmer.

Pulled the GRML full distribution iso from grml.org

Flashed it using Balena Etcher to an SD card (which was formatted in GUID and named GRML before).

Booted the GMRL distro (it will be shown on the OpenCore boot Picker as GRML)

Used the Start ssh command to enable remote ssh access

setup a password using the passwd command

started access from my local work station and moved the modded new firmware file named modded.bin over

flashed it using flashrom --programmer internal -w modded.bin

(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.

Code:

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)

Code:

% 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.

View attachment 2007622

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

downloaded grml64-full_2021.07.iso and balenaEtcher and when creating the pendrive the iMac does not recognize the pendrive.

In my case, which step should I follow?

m0bil · Aug 29, 2022

Borak said:
downloaded grml64-full_2021.07.iso and balenaEtcher and when creating the pendrive the iMac does not recognize the pendrive.

In my case, which step should I follow?

maybe try another pendrive?

m0bil · Aug 29, 2022

kocoman said:
i got monteney working on 3rd gen systems (some with autoport). (you need to use tianocore as the payload not seabios) to get some hd4000 and dsdt ssdt fixes that would cause kernel panics. now i am trying sd card boot.. i am able to disable uhs but got the waiting for root device. for other devices i have 4th and 6th gen but have not got time to work on getting coreboot on those yet. so while i am still around anyone who want to try or have questions can ask me while i still can tell you the answers instead of forgetting

I'd like to give this a try on the iMac 12,2 at some time, and definitely will need some advice. With coreboot/tianocore Ivy Bridge support should not be a problem I guess...

kocoman · Aug 29, 2022

m0bil said:
I'd like to give this a try on the iMac 12,2 at some time, and definitely will need some advice. With coreboot/tianocore Ivy Bridge support should not be a problem I guess...

you need to extract the vbios from the csm first, if you use libgfxinit on the 4000/3rd gen, it gives an assert panic. then there is a mysterious nvram problem that is sometimes causing wierd panics before gui.. but I am able to solve some after a lot of trail and error.
First thing is to get a soic clip because you would brick your machine sometimes for reasons. then try to get grub2 to show first to verify vbios is working, set framebuffer to 1024x768. (in xeon p4000 for some reason need to use different video bios). then a bunch of dsdt fix (you can ask me and I tell you what to add etc when you get to that point) and processor PR00 fix so it won't get stuck at 800mhz. you can try autoport (see motherboard porting guide coreboot IIRC). since mmga ch1p didn't make one for imac12,2.. that part maybe autoport work I don't know. I am still stuck with my macbookpro8,2 I can't get screen to show even though resolution is detected, but linux just reboots when it starts so I am trying a debug kernel.. then I have to use grub2 with serial ftdi to boot the linux. hopefully if you successful you can write up the things for me.

does the imac12,2 use dual video? mux? I disable my dGPU and use internal only for my method.

for the grub just use 2.04, the newer version HEAD need a patch to the makefile or else it hangs

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

macrumors 6502

macrumors newbie

macrumors 603

macrumors member

macrumors 6502

macrumors 603

macrumors 6502

macrumors 6502

macrumors 6502

macrumors regular

macrumors 65816

macrumors newbie

macrumors 6502

Attachments

macrumors 603

macrumors 6502

macrumors 6502

macrumors 6502

macrumors 6502

macrumors 6502

macrumors member

macrumors 6502

macrumors member

macrumors 6502

macrumors 6502

macrumors 6502

Our Staff