Sleep over it a couple days, deleted everything that I had downloaded.
Read back what I wrote, see that I sound like a complete entitled POS, I’m so sorry for being so damm stupid, sorry @Fernando , and thanks for your patience to put over my tirades.
tried my MMTool 5.0.0.2 or something near that, and it was kinda buggered, maybe corruption due to being uploaded and downloaded a lot of times from my GDrive, hunted another copy, it was hard to find one 
Downloaded all the UBU files again, this time from the Mega links, disabled Win AV, unpacked, put MMTool in its place, and it worked!
AFUWIN didn’t want to flash the updated bin, grabbed fptw and it happily flashed the modded BIOS.
Do a couple runs with ATTO and Crystal Disk Bench, my RAID0 seems a bit slower now LOOOL, but the last bench I did it was at 29% usage and now it sits at 50%, serves me good for being so arrogant.
I still don’t want to flash the micro-code, because it says that the size/offsets are different and I wont risk that.
Thanks for the all the work put up, it works when you make sure all the tools are working.
Latest microcode revision guidance March 06 2018 released!
Horrah! Ivy Bridge and Sandy Bridge CPU’s patched this time…
Ivy Bridge:
CPUID 306A9 → 0x1F new microcode for i7-4960X, i7-4820K, i7-4930K and Socket 1155 processors i3, i5, i7, Pentium and Celeron group + notebook processor serie
CPUID 306E4 → 0x42C new microcode for Xeon E5 v2 serie (instead & update for buggy 42A)
CPUID 306E7 → 0x713 new microcode for Xeon 4 CPU serie
Sandy Bridge:
CPUID 206A7 → 0x2D new microcode for E3-1200 serie including desktop i3, i5, i7, Pentium and Celeron group + notebook processor serie
CPUID 206D6 → 0x61C new microcode for Xeon 26xx serie
CPUID 206D7 → 0x713 new microcode for Xeon E5 serie
Note: I can not see i7-3820, i7-3930K, i7-3960X and i7-3970X desktop x79 processors inside Sandy Bridge update explanation yet. But,
CPUID indentifier for the:
i7-3820 is 206D7,
i7-3930k is 206D7,
i7-3960x is 206D6,
i7-3970x is 206D7.
Possibly they get covered as well!
https://newsroom.intel.com/wp-content/up…te-guidance.pdf
A heads up for everyone:
Be aware that the recent CPU microcodes patching Spectre/Meltdown vulnerabilities have a flaw which causes endless boot loops after flashing. Intel has acknowledged the problem and fixes will be forthcoming.
I found out the hard way by trying these microcodes on my Sandybridge platform. All is well - I recovered from my secondary BIOS. Normally I don’t touch microcodes, but this latest patch was tempting enough to try.
See http://www.zdnet.com/article/meltdown-sp…sudden-reboots/ or search for “Spectre Meltdown boot loop” - there are many articles out there.
Thanks to SoniX and Fernando for the continued support on UBU!
Dated Jan 12 2018… thats not new, that is the reason for these new microcodes coming out now.
do this happen with the patch version of 5.2.0.24?
Thanks in advance.
think i will go back to verson 5.0.0.7
@ygbsm
These microcodes are latest and build for stability knowing the problem of endless boot and performance degradation. Those are the final builds and there will no re-production unless new types of flaws arise. Shortly, those are safe. At least, Intel tried to make it’s best this time! 
You can surely add those latest builds inside of your bios, if you do not want to see flaw specific behaviors!
If you are making animation, video production, film conversion, etc. the patch also provides better, correct calculation results, because it fixes wrong calculation algorithm either!
If you look at web, you will see a proof of a re-calculated, cat picture with buggy black doted result, without the patch applied. The re-calculation of image is buggy. Means, re-calculation makes error when checking. This is like using a damaged ECC memory, every proof of re-calculation gives wrong results one after another.
By the way, I have used the buggy 42a version with my Xeon E5-2658 v2 CPU with two X79 and C602 chipset based Asus mainboards, Rampage IV Black Edition, X79-Deluxe and Z9PE-D8 WS. I have run memtest 86 with DDR3, ECC and non-ecc memory at 32GB sizes for 4 runs. It took as long as 25 hours and 45 minutes with ECC-registered 1866MHz, and roughly 18 hours with non-ECC 2666MHz. All of my test’s finished without reset, and error. The resetting issues are also, possibly related with aged, bad, cheap or failing mainboards origined too. (I assume, according to my personal test.) But there are many other various stability and stress tests, I do not check them all, of course…
Hello,
i have an i5 8400 (coffe-lake). Can I update its mCode via UBU?
Thx.
I get error: Invalid FFS File
When using patched MMTool I get error: The input image is not Aptio V.
My PC is a VPCL22DFX with core i3 Sandy Bridge and the cpuid is 206A7
Bios Download: https://esupport.sony.com/US/p/swu-downl…8&os_group_id=6
Which FFS file did you try to update/replace?
This is a known issue of the MMTool v5.2.0.24, when being used with certain Aptio4 BIOSes.
My advice: Take the MMTool v5.0.0.7.
Both:
1F Version 1F Date 07-02-2018
2D Version 2D Date 07-02-2018
Here is my extracted bios: https://mega.nz/#!69pBCY6L!uowOQ3IEQMC0H…6Jn_FtI84Io_gpQ
@ricktendo :
You are right - the latest UBU tool is not able to update the SandyBridge and IvyBridge MicroCodes of your BIOS (no matter which MMTool version you are using). I have just tested it.
@SoniX :
Can you help?
* Very old BIOS, even MMTool of the 4th version does not want to work with this file.
Edit:
* Fixed in UBU 1.69.16/1.70 a15
Thank you Fernando, do you think I can still update it manually and are these instructions valid?
https://www.delidded.com/how-to-update-c…de-in-ami-bios/
I keep getting the same error, Invalid FFS File
I was able to use MMTool v4.50 to manually insert the cpu patch
I did then extract my FFS file and compare it to yours and I saw only a difference at the beginning (hope this is not a showstopper)
Edit: seems to be fine
@Sonix
Can you please add – 1.70.xxx’s LGA2011 206D6 - 61C, 206D7 - 713, 306E4 - 42C microcode info data to 1.69.xxx version please?
@karakarga :
Please post your requests or comments into the correct “UBU Discussion” thread (= this one). The other UBU thread is exclusively designed for the UBU “maker” SoniX and his Update announcements.
Yes I know, I consciously put it there to immediately catch your attention.
There is also CPUID 306A9 → 0x1F new microcode for i7-4960X, i7-4820K, i7-4930K has to be added for socket 2011 too.
Waiting for new 1.69.xxx version, have a successful good work on it, there are lots of work to do.
Thank you…
I have come across some odd behavior. I can update Sandy Bridge microcodes without issue using UBU 1.69.15 or UBU 1.70.a14 DEV. However, Haswell microcodes appear to show twice and update twice, throwing an incompatible file size error. But if I go back to UBU 1.69.14, then the Haswell microcodes only show once and microcode updates OK.
@Sonix,
UBU v1.70.a14_DEV_incl-Update2 → Can not successfully initialize and add 42C version, still inserts 42A!
UBU_v1.70.a15-DEV_without-MMTool → Problem fixed. Thank you again! 