![]() Flashed it using Balena Etcher to an SD card (which was formatted in GUID and named GRML before).Pulled the GRML full distribution iso from.Applied the patch to my iMac12,2 test system firmware dump and rewrote it using a (Pomona) CH341A clip programmer.Got all this information from directly, so all credits to him! 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.Ībout (using) the (patched) write protection: If you want to flash you eeprom, do it after a cold boot or restart. This is due to some security patches by Apple and I see no need to patch this. After a sleep/wake cycle the rom will be protected again. ![]() It you try it watch UEFIPatch output for clues. May work on other models and versions, but has not been tested. ![]() 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. Once unprotected you should be able to use any compatible OS flash programming tool to program it in the future (flashrom, Intel FPT). It can be easily applied to your bootrom using UEFIPatch.Īfter applying it to your previously backed up bootrom, you have to program it once back to eeprom chip with clip.Īlso you will need to use the patched rom as a base for all future modding (or you will re-protect it). So, I made this patch to remove all PRR and FLOCKDN protection. With a bit of reversing, we can find this protections mechanisms are setup during boot on UEFI module PchSpiRuntime: Once set, FLOCKDN can only be cleared by a system reset. Then the PR registers are protected against modification by the Flash Configuration Lock-Down (FLOCKDN) bit in the HSFS register. 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). So, we can see the PR (Protected Range) registers are used to define non-writeable ranges 0x181000 to 0圆D7FFF and 0圆FC000 to 0x1FFFFFF. SPI protected ranges write-protect parts of BIOS region (other parts of BIOS can be modified) PRx (offset) | Value | Base | Limit | WP? | RP? BIOS region write protection is disabled! SMM_BWP = 0 << SMM BIOS Write Protection # python3 chipsec_main.py -m common.bios_wp PASSED: SPI Flash Controller locked correctly. SPI Flash Controller configuration is locked FLOCKDN = 1 << Flash Configuration Lock-Down ![]() FDOPSS = 1 << Flash Descriptor Override Pin-Strap Status HSFS = 0圎008 << Hardware Sequencing Flash Status Register (SPIBAR + 0x4) [ Module: SPI Flash Controller Configuration Locks 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. Bad firmware checks for a specific processor model number and halts if it is not an exact match. Good firmware checks the processor family, and if it actually has specific code for multiple families, chooses the appropriate branch. When a firmware starts running one of the first things it does is calls CPUID (op code 0F A2). In some cases ( Dell) this is intentional. Processor compatibility is limited by badly written firmware. New processors models for any socket are always made fully compatible with older hardware. Besides, the operating system loads a newer version of microcodes anyway.Įxperience shows that adding microcodes to Mac firmware will make the system less likely to boot. No processor sold should need microcodes to boot. People erroneously think that upgrading a firmware's set of microcodes will make the computer support newer processors.
0 Comments
Leave a Reply. |