@SoniX:
Motherboard is ASRock Z68 Extreme3 Gen3 using last Beta Bios L2.31A
https://www.asrock.com/MB/Intel/Z68%20Ex...dex.us.asp#BIOS

Edit: Removed incorrect assumptions.

Edit2+4: I think I found the solution:
Microcode always (Z68 Gigabyte and ASrock) has to start at offset x0xx or x8xx.

Microcode locations from my original microcode file:
50 / 2018 / 5018 / 7818 / A018 / C818 / E818

So if we generate microcode file with Ivy Bridge mc first we need to add 400 bytes of 'ff' padding. Next microcode address would be then 3818.

Edit 3:
Simply then add Sandy Bridge mc first and THEN Ivy Bridge.
Sandy Bridge mc has length of 3000 -- we are at the right start offset of 3018 then for the next microcode!

If we add Ivy Bridge mc first we need to add a fixed padding of 400 bytes -- we are at the right start offset of 3818 then for the next microcode!

@Nemo1985
On Asus MAXIMUS-IX-APEX problems did not arise.

@mictlan
You are thinking right. But in any case, you need to check everything.

Edit:
@SoniX:
The simplest fix would be this one liner:
uefifind all count %scguid%^..AA..........F80100 bios.bin>nul && %udk%\GenFFS -t EFI_FV_FILETYPE_RAW -g %cguid% %mc2% %mc1% %mpdt% -o tmp\mCode.ffs || %udk%\GenFFS -s -t EFI_FV_FILETYPE_RAW -g %cguid% %mc2% %mc1% %mpdt% -o tmp\mCode.ffs

mc1 == Ivy Bridge
mc2 == Sandy Bridge

Edit2:
You are right: I just checked the Asus P8Z68V. This seems to have an offset of 0x400
Microcodes use 2C18 / 5418 / 7818 / 9C18
So usable offsets should be x0xx / x4xx / x8xx / xcxx

@mictlan
Will not be. You swapped the IVB/SNB -> SNB/IVB, and if someone uses IVB, then he will get the same problem.
The correct solution is:
1) Check for Offset 0x800
2) If "Yes", then during the generation, add 2 more files

 %mc1% %padd% %mc2% %padd%
 

where "%padd% is files with 'FF'. of the desired length.

Yes - we must check for offset 0x400 (Asus) and 0x800 (ASrock and Gigabyte)

Edit:
Something I'm already confused. %(
Okay, let's think.

Zitat von SoniX im Beitrag #3732

---

Zitat von ricktendo im Beitrag #3728

---

I get error: Invalid FFS File

---

Very old BIOS, even MMTool of the 4th version does not want to work with this file.
Use the UEFITool to replace the microcode.
Attached the archive, there are 2 FFS, one with IVB, the second only the SNB.
GUID 17088572-377F-44EF-8F4E-B09FFF46A070 - "Replace as is"

---

@SoniX
Thank you for the additional information. I assume each mcode then has a "header" or similar to match the current CPU with the corresponding mcode.

@mictlan
You took the extra insight provided by SoniX and really ran with it. Great work!

@Iken
Unfortunately for us Haswell was the first platform to receive the INVPCID processor feature, which is the instruction to invalidate the earlier feature PCID (process-context identifiers). Both of these are needed to mitigate Meltdown without a significant performance hit. We just barely made the cut for PCID even, as a few Westmere platforms were the first to receive it with Sandy Bridge being the first platform with wide adoption of the feature. You're probably already doing so, but you could always overclock the 2500K a bit to help compensate for the performance hit. FYI, also make sure to reboot between using InSpectre to turn Meltdown protection on/off.

The only problem currently is the microcode 1F for Ivy Bridge because of it's size of 0x3400. And this is only a problem for boards which require a microcode offset of 0x800.
There is no problem for boards which have microcode offset of 0x400.

Let's think again: If we add Sandy Bridge 2D microcode first, size 0x3000 we should never encounter any errors with board offsets 0x400 and 0x800. Next possible microcode location would always be 30xx!
If we always put the Ivy Bridge 1F microcode second there should be no offset problem because we are at location 30xx.
Even if we use an older Sandy Bridge microcode with size 0x2800 (28 oder 29) there will no problem because we are at offset 28xx --> This is also why we never encountered any problems till now ;-)

So first snb 2d (loc. 1) and then ivy 1f (loc. 2) and all should be fine.

@mictlan
And what will you do if both microcodes are odd?

Add:
In general, so.
If the file size of the microcode is even, that is, 2, 4, 6, etc KB then pad is not needed.
If the file size of the microcode is odd, that is, 1, 3, 5, and so on KB, then you need to add a 1KB pad.

@SoniX

Confirmed to be working on my Z68 Sandy Bridge system! Using 1.70.a16 Dev, I successfully updated my BIOS image using the standard auto update feature. Gigabyte GA-Z68XP-UD4 (rev. 1.0) spec reference. No boot loops as before with auto update in 1.70.a15.

For comparison (all using patched MMTool 5.02.0024):


Using 1.70.a15 Dev in auto mode (result: BIOS loop, did not load #2 Sandy Bridge mcode):




Using 1.69.15 + Update 2 in manual mode (result: worked, only Sandy Bridge mcode):




Using 1.70.a16 Dev in auto mode (result: worked, loads #2 mcode properly for Sandy Bridge):

Good evening, I just want to leave my feedback, I finally tried to update the bios with updated modules and microcodes, despite of the different offstes and sizes everything works like a charm on my Asrock z170 extreme4.
Now the system seems fully protected from spectre vulnerability.

Zitat von lordkag im Beitrag #1392

---

I did found a few months ago a Nec-Renesas uPD720201-202 USB3 Firmware 2.0.2.6 (K2026090.mem) in a Lenovo BIOS. It has a full header, which means it can be used with NEC flashers.

---