#ygbsm Most likely the CPUID is the same for the board but one is for the the gaggle of 2 core cpus; while the other is for the 4 core cpus which includes a bunch of E3 version Xeons.
Performance as per Passmark ~ 96th percentile which isn’t too bad for an “ancient” Asus Z87-Deluxe with i7-4770K
Cheers
I wasn’t talking about that. Although I’d also like to know why does UBU wipe all of the microcodes except for the ones it’s updating - let’s add this to my previous question.
I was talking about a chance of getting a bootloop after updating both microcodes in the BIOS with support for Sandy/Ivy. Isn’t that what you were talking about in your own post? That would mean that UBU can brick a motherboard through something that is supposed to be normal operation.
Isn’t the whole purpose of UBU is to extend the lifetime of older platforms by letting users to apply updates that weren’t provided officially?
This is a pretty bad workaround, because it requires you to reflash the BIOS every time when you want to swap a CPU with the one from a different generation. This is not normal.
Just registering to say modded MMTool 5.02.0024 worked perfectly with 1.70.a15-DEV on my P8Z77-V Pro.
Started with…
SHA1: FBA82BD83C603700E6763ED8A9C5633980822C21
and ended up with
SHA1: 8E54AC68DE355E1031527B89C0560AE1C9C8C508
@hancor
Thanks for the “twin” CPUID explanation. That’s a really good Passmark score - my i5-2500k / Z68 system is only around 3700. My 2D score is very low for some reason; the only reason I’ve found so far is that MS introduced a patch to Windows 8 that tanked Direct2d performance and said update made its way into Windows 10. That said, this system still serves me well and I have no immediate plans to upgrade.
The bootloop and the wiping of mcodes are presumably related since the rearranging of offsets along with wiping out whatever mechanism preceded FIT to enable selective mcode execution is causing the wrong or an invalid mcode to be loaded.
I agree it’s a bug, but my point is that we must be respectful of SoniX’s time - it’s up to him whether or not to pursue it. He has a valuable skillset working with some pretty low abstraction layers… when the guys working on lower levels all work at semiconductor manufacturers that tells you something. We’re not compelled to pay for the use of UBU, so it’s not reasonable to make any demands of him.
Perhaps it will end up being an “easy” fix or one that is interesting enough to pursue for the intellectual challenge. The bottom line is that it’s up to him; for example, disabling option 1 for Sandy/Ivy boards and/or adding instructions in the guide to use the manual update would be perfectly reasonable “resolutions” to this issue if the decision is made not to pursue a full fix. The current architecture seems to have diverged enough from Sandy/Ivy that any fix developed would not likely be useful to current gen platforms - meaning that any system without a Fit is more of an edge case at this point, as unfortunate as that is.
Yes, and we already know how to apply the mcode update via manual mode. Further mcode updates are not very likely, so the future value of a Ivy/Sandy mcode auto update fix for UBU is questionable. The only reason Ivy/Sandy got an update this time was to address a very large flaw at a foundational level of CPU architecture - a problem that goes back to 1992 at the very least and was already pretty well understood by some in 1995; think about it, DOS was still the dominant OS back then. Ivy/Sandy were barely included in this round, and they don’t even have the feature set (INVPCID specifically) required to implement the full efficient solution. As for oroms - I don’t know about you, but there were maybe one or two LAN updates for my BIOS in the last year and that’s about it. There will be even fewer in the future.
It’s not normal to be changing CPUs often enough to make that a “bad” workaround and those few who do should be using dual BIOS boards, know alternate methods of resetting the BIOS, and be reading before proceeding; thus, they would learn that manual mode works in this case.
Thx @SoniX for your info.
I checked the original cpu microcode file of my bios and noticed that between microcodes there must be a padding of 400 bytes ‘FF’.
How can I create a valid microcode file with matching padding?
Thx
@SoniX
Sorry to bother you, do you think I can safely flash the bios with updated microcodes?
[Discussion] UBU Tool related Questions, Reports and Suggestions (254)
Thank you.
@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!
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%
Yes - we must check for offset 0x400 (Asus) and 0x800 (ASrock and Gigabyte)
Edit:
Something I’m already confused. %(
Okay, let’s think.
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.