![]() ![]() 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. +++ src.new/uefitool/uefitool.pro 09:30:49.People erroneously think that upgrading a firmware's set of microcodes will make the computer support newer processors. +++ src.new/uefitool/UEFIReplace/uefireplace.pro 09:48:56.813667286 -7,6 +7,8 -= app_bundleĭiff '-color=auto' -aur src.orig/uefitool/uefitool.pro src.new/uefitool/uefitool.pro +++ src.new/uefitool/UEFIPatch/uefipatch.pro 09:48:40.636851752 -7,6 +7,8 -= app_bundleĭiff '-color=auto' -aur src.orig/uefitool/UEFIReplace/uefireplace.pro src.new/uefitool/UEFIReplace/uefireplace.pro Adding '-lzstd' to the build configuration solves the undefined reference issue: diff '-color=auto' -aur src.orig/uefitool/UEFIPatch/uefipatch.pro src.new/uefitool/UEFIPatch/uefipatch.pro ![]() It turns out that either something is wrong with the currently packaged Qt5 or the upstream build configurations. I have had troubles building this package lately. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |