If I use MMTool 4.50.0.23 with any version of topic’s BIOS and try to look at “CPU Patch” section MMTool immediately crushes. Same if I try to batch “MMTool BIOSFILE /p”.
If I try to replace EFI SataDriver with 12.x FFS I gen an error “Error in replacing file” (with Z77 Professional latest BIOS version 1.70 and 1.70b) or “file size exceeds the volume size” (with old versions up to 1.50) and no error with 1.60. But! When I use .cmd UBU there’s no MMTool crushes and no errors in replacing EFI IRST SATA (thus I understand that volume size actually enough).
Other modules replace works ok (GOP, EFI Netcard, Optional ROMs etc.). Z68 m/b BIOS doesn’t show such problems.
Why? Is it bug in MMTool and is there workaround? All BIOS versions could be found at Asrock, filenames “Fatal1ty Z77*ROM.zip”
‘CPU Patch’ crashes because first module (up to three are found in actual UEFI’s) which holds cpu patch data is an empty module .
Remark: NEVER EVER use MMTool to insert cpu ucode - something always breaks (only use to extract!)! ALWAYS do it witch a hex editor.
I must say the opposite: Please use MMTool and only it in case of uCode module located inside Boot Firmvare Volume (the last one(s), where PEI_CORE module is), unless you are capable to rebase all PE32 and TE images there to their new addresses and patch Volume Top File to point to PEI Core entry point with HexEditor. UEFITool 0.16.0 (will be released in 2-3 hours) will do it for you too, but right now there are no tools capable of doing all operations needed for modified BIOS to remain bootable, except MMTool.
Is there any chance that AMI will fix it? Any guru who has contact to them?
Is there any chance that AMI will fix it? Any guru who has contact to them?
There is nothing to fix. It is no recommended to add cpu ucode patches via MMtool (the whole module itself yes but not the individual ucodes - this can go wrong).
Edit: Try to recreate the ucode module that is included with this board using MMtool.
I don’t need to add, I only want to view (without crash) 
@off , if you are really from Moscow and know Russian, go read this topic on forums.overclockers.ru, at has all the answers you seek.
AMI has already fixed it on their newer versions of Aptio platform, but for any particular board is’t very unlikely, that platform version will be changed during normal BIOS update (it had happened back then on ASUS P67 and Z86 boards, and was very much pain in the a*s for both ASUS and it’s users).
MMTool crashes because of empty 17087572-… FFS file, which normally contains uCodes, but remains empty on that platform version (due to bug in AMI binary patching utilities, I think). You can extract this file as is from DXE volume (where, for example, IntelGopDrivers.ffs is located), change one byte of it’s GUID (first 16 bytes of extracted file) and replace old file with new one. MMTool will work on that modified BIOS, because now the first uCode module will be found not in DXE volume, but in first copy of boot volume, where this file not empty is.
After modification, revert the first file back to it’s original state, and you have a BIOS with updated uCodes now.
But, I must admit, that MMTool changes only one copy of boot volume, so now you have 2 different boot volumes with different uCode files, and if you don’t like this situation, you must manually update old uCode file in latest volume to new one.
Good explanation, thanks 