@karakarga :
1. If you want, that a specific Forum member will get notified about your post, you should use the @nickname1 addressing.
2. If you should continue posting into the wrong UBU thread, I will delete your related post (instead of splitting and merging again everything).
Thanks for all the good work with UBU
Updated my Uefi Bios IVB to microcode 1F and the SNB to microcode 2D flawlessly with “UBU_v1.69.15.2_incl-Update2_without-MMTool” (used MMTool v5.0.0.7). Now i’m waiting Microsoft to patch “mcupdate_GenuineIntel.dll” because it’s still the 2015 .dll with microcode 1C listed inside, so it does not match it anymore.
Thanks again to the developpers of UBU Tools.
My attempts to update my CPU microcode for my Sandy Bridge Z68 / i5-2500K were finally successful!
I ended up using UBU v1.69.15+Update2 resp. 1.69.15.2_incl-Update2 (3/7/18) along with MMTool 5.02.0024. I also used option “m” (User Select Microcode File) and browsed to the correct .bin file as opposed to using option “1” (Update CPU) like I have done in the past.
Here is the microcode list BEFORE the update:
Here is the microcode list as it appeared when I tried using option “1” (Update CPU) - this version caused boot looping:
This is the microcode list that was produced by using option “m” (User Select) - this version worked:
Here’s the proof! Note the newest “2D” microcode listed!
My working theory is that option “1” had worked (a long time ago) when I previously updated the microcode because the sizes matched, thus the offsets remained constant. These new microcodes (Ivy Bridge / Sandy Bridge) changed size; thus, I think my BIOS was trying to load whatever microcode it found at offset 0x347390. The option “1” update placed the Ivy Bridge mcode there, but option “m” user select update allowed me to only place the Sandy Bridge mcode, which placed it of course at 0x347390.
I’m not sure why my BIOS was previously OK with the Ivy mcode at 0x347390 and the Sandy mcode at 0x34CB90. My wild guess is maybe it was coded to look for mcode at specific offsets? In any case, I’m good to go! Hopefully this helps someone trying to update a similar platform.
Thanks to Fernando and SoniX for UBU!
Only for those CPU’S? My i5 3570K also has the CPUID 306A9.
@aiocr
I know there is a huge list…
3rd Generation Intel® Core™ Mobile Processor Family,
Intel® Pentium® Mobile Processor Family, and Intel®
Celeron® Mobile Processor Family
and
Socket 1155 processors got this code as well…
I have updated my post, thank you.
Yeah, i have exactly the same with newer UBU releases
Anyone can fill us in on this odd behavior?
@Sonix
I have long ago, (6-8 months) updated my Sony Vaio VPCF21Z1E with UBU_v1_69_5 to the Ivy Bridge "1C" and Sandy Bridge "29" microcodes.
But with "UBU_v1.69.15.2_incl-Update2_without-MMTool" it can not update to Ivy Bridge "1F" and Sandy Bridge "2D" microcodes,
it wrote:
Checksum correct.
Checksum correct.
Generate FFS Microcode
Preparing for replacement
Update Microcode Patch…
but waits, at the other window it said:
Invalid FFS File
I have used MMTOOL_v5.0.0.7, What can I do?
n/a
Thank you for reply,
But, I have Realtek ethernet on my notebook?
It said "Cannot install drivers. No Intel(R) Adapters are present in this computer."
I will try on my desktop, I have lately made a clean install and yet do not installed Driver Max, but I have done the previous update on my notebook as well. Interesting!
By the way, I have managed to manually replace and insert the new files with using old MMTOOL_v4.50
Both latest UBUs need updating to Intel Ethernet Adapter Complete Driver Pack v23.1 for everybody
https://downloadcenter.intel.com/search?..Adapter+windows
Image versions in BootIMG.FLB
Combo Image Version Name 1.1876.0
Combo Rules v4.67.00
Clp-Loader Option ROM v3.0.90
40G Interface Module v1.0.53
iSCSI Option ROM v3.1.30
iSCSI Setup Option ROM v3.1.30
FCoE Option ROM v1.8.29
Intel(R) Boot Agent FE v4.2.08
Intel(R) Boot Agent GE v1.5.85
Intel(R) Boot Agent XE v2.4.16
Intel(R) Boot Agent XE (X550) v2.4.16
Intel(R) Boot Agent I40E v1.0.66
Intel(R) Boot Agent CL v0.1.13
UEFI x64 PCI gigabit driver v3.5.22
> UEFI x64 PCI-E gigabit driver v8.3.04 <
> UEFI x64 10 gigabit driver v6.7.04 <
UEFI x64 40 gigabit driver v3.0.05
UEFI IA64 PCI gigabit driver v3.5.22
UEFI IA64 PCI-E gigabit driver v8.3.04
UEFI IA64 10 gigabit driver v6.7.04
UEFI IA64 40 gigabit driver v3.0.05
OCD Option ROM v0.9.04
UEFI x64 FCoE Driver v1.2.21
Thanks !
I understood what the problem is!
For such BIOS, when assembling FFS, it is required:
1
-s, --checksum Indicates to calculate file checksum.
Therefore, all who encounter this problem need to fix all strings:
1
%udk%\GenFFS -t EFI_FV_FILETYPE_RAW -g %cguid% %mc1% %mc2% %mpdt% -o tmp\mCode.ffs
add the '-s' switch
1
%udk%\GenFFS -s -t EFI_FV_FILETYPE_RAW -g %cguid% %mc1% %mc2% %mpdt% -o tmp\mCode.ffs
Add:
Fixed in UBU 1.70 a15/1.69.16
I made the following observation with UBU v1.16.15 Update 2:
Updated the bios for ASRock Z68Extreme3 Gen3 with latest microcode for Ivy/Sandy Bridge (2D/1F).
After flashing bios shows microcode revision 0.
The microcode isn’t recognized by bios
UBU itself shows that the microcode was updated (using latest microcode -> yes).
Anyone tested this on Z68 or Z77 platforms yet?
@mictlan :
Please see my post for a Z77 Platform : post #3742, everything went fine and it shows the right microcode revision 1f in UefiBios.
EDIT by Fernando: Unneeded fully quoted post replaced by directly addressing to the author (to save space)
@Sonix
I have run mmtool 5.0.0.7 click on load file, loaded the bios file (I have used “Windows Bios Utility Aptio 4” then click on AFUWINGUI.exe twice Save the bios file from notebook and Open) I have pressed CPU Patch button.
Now the problem is: It only allowed me to “Extract a Patched Data” the upper “Insert a Patch Data” and lower “Delete a Patch Data” options were grayed! I can not choosen them. Therefore mmtool 5.0.0.7 was rejecting the bios file that I want to manually insert.
Then I tried mmtool version 4.50.0.23 it allowed me to first “Insert a Patch Data” I have inserted:
cpu206A7_plat12_ver0000002D_2018-02-07_PRD_1BDB79EA and
cpu306A9_plat12_ver0000001F_2018-02-07_PRD_3023E347, (I have extracted those 2 files when modifying MSI Z77A-GD65’s bios before.)
I have choosen “Delete a Patch Data” and deleted 2 other old Ivy Bridge 1C and Sandy Bridge 29 microcodes.
Saved and again with “Windows Bios Utility Aptio 4” tool run AFUWINGUI.exe choosed “Save” tab with ticking option “Do not Check ROM ID” it flashed the bios file to my Sony Vaio VPCF21Z1E.
As a result, InSpectre_r7 now tells:
System is Meltdown protected: Yes
System is Spectre protected: Yes
Performance: SLOWER (Yes I know it!)
CPUID: 206A7
And HWiNFO v5.74-3363 informs:
μCU: 2D for my Intel Core i7-2860QM processor.
I have written down step by step for others to understand. At this example, the problem is “mmtool 5.0.0.7” won’t allowed me for “Insert a Patch Data” and “Delete a Patch Data” to tick!
I think: “Invalid FFS File” error is related with mmtool 5.0.0.7 running UBU_v1.69.15.2_incl-Update2
But, this summer, I am sure that, I have used “mmtool 5.0.0.7” making a similar modification. Why it currently rejects the task? Strange…
EDIT by Fernando: Unneeded blank lines removed (to save space)
“Invalid FFS file” error fixed with version “UBU_v1.69.16_without-MMTool”, thank you… 
It works for you because you have an Ivy Bridge cpu.
The microcode order seems to be important (I had the same as you’ve shown in your picture): If I choose option ‘m’ in UBU and manually select 2D microcode it works. Then only Sandy Bridge mc update is present.
@N6O7 ???
It doesn’t need to match!
yours now is newer, so the pached “mcupdate_GenuineIntel.dll” is not needed/used by Windows, verify by looking at HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
‘Previous Update Revision’ & ‘Update Revision’ now should match
@RvdH ,
yes indeed, it does now match the bios update in the registry settings.
Wish MS still update System OS those older processors as they did for Skylake with the KB4090007.
it’s better to install this update if the CPU is not a Skylake ?
Maybe for the update of the dll ?