@Dagal
A microcodes update can fix many things or just a few. Among those, the most common or known reasons are:
- Fix errors in some specific kind of calculations done by the CPU (Most common reasons)
- Improve the speed of some tasks or calculations done by the CPU (Common reasons)
- Fix some specific situations were this would cause a crash from the CPU, usually causiing a reboot or a blue screen of death (Rare)
- Fix a vulnerability of the CPU like Spectre (Very rare)
Hey,
The Nick say all, my englisch is very bad.
Thx vor the Thread and other Threads for BiosMods.
I have a problem to find the microcode
MoBo: Gigabyte EX-58 EXTRME
CPU: Intel Xeon X5660 Westmere-EP
the Microcode is 206C2 in programm InSpectre
Ƥhm how i can post Screenshots?
-------------------------------
CPU-Z say:
Family 6 | Model C | Stepping 2
Ext. Family 6 | Ext. Model 2C | Revision B1
thnx
Edit
i have not Found the microcode in the microcode.dat from Intel Webseite ā¦last download from Intel Webseite 
Hello G-A and welcome to this forum!
The CPUID (cpu identification number) is 206C2.
The newest microcode for this CPUID is Version 0000001E from 2018-01-23.
Do you need help to implement it in the last BIOS-file of your mainboard?
Best regards, MiMo
Hello MiesMosel,
Thanks for link to microcode.
Microsoft simply deleted the microcode in the database.
Have now installed the BIOS F13j plus microcode on the motherboard.
Thank you for the super instructions.
All the instructions for Mod Bios are incredibly cool
Had a bad microcode in the ModBIOS in it but for another CPU.
I probably deleted the screenshots because of the bad microcode in the mod BIOS file.
Because I have completely reinstalled the newest windows 10
Have used the Google Translate tool to go through step by step the Mod BIOS instructions.
greetings
Text Translated with google
Iāve read and re-read the instructions about merging the updated microcode into the new (empty) NCPUCODE.BIN but I just donāt follow. The filenames I have arenāt the same as the example and Iām simply not confident of the CL command
I only want to update the 206A7 ucode from 25 to 2D, so Iāve copied all the extracted ucodes minus the 25 and included the 2D.
Am I correct so far?
I think I understand the CBROM command to program the new NCPUCODE.BIN back to the BIOS file but I just donāt get the merge instruction.
EDIT: I believe I have done it, I have checked the new file with MCE.exe and it lists correctly.
Hello,
which mainboard (manufacturer, model, revision)?
Not every version of cbrom could correctly insert the ncpucode.bin.
Maybe no of the cbrom-versions could do to merge the MCs, they only add these.
Thatās why I mostly exchange the microcodes directly with HxD.
After that most BIOSes need to actualise the checksum (maybe by re-inserting an Option ROM ā¦ or with the little program āchecksum patcherā).
Best regards, MiMo
Edit: checksum patcher ā patch64 | CRC=43DCCCA8
I canāt find any instruction to run this patch64. Does it run with CL argument?
Okay, your mb could be GA-H61M-S2V-B3 rev1.0 or rev1.1.
The new MC ā2Dā is bigger than the old "25"
Thatās a problem for exchanging this MC.
I startet it ones (patch64 h61ms2v.f8), and I got ācalculated cheksum = 0ā as result.
The CRC checksum has changed, but I donāt know, if it helps.
I could exchange MC with HxD to ā2Dā. MCE shows new MC, but the āMicro Code Informationā of cbrom199 shows no MCs in Slot1.
So I donāt know, if this bios-file could be flashed without a problem.
Here is completed mod @winactive - in case you didnāt confidently get it done yet
Removed x 2 - Revision 25 (10/11/2011) & Revision 1B (7/14/2011)
Inserted 206A7 Revision 2D (2/7/2018)
https://nofile.io/f/M3QKnkUe0fA/h61m-s2v-b3_f8-MOD.zip
Thank you! I will try to understand my misstep! I did not remove 1B; I wondered why 206A7 was listed twice but figured the code I needed was 2D as the board reported 25 in the System Info.
I will be a short while before I can report back.
I got āInvalid BIOS imageā when I last tried. I believe the rev 1.0 and 1.1 have the same BIOS image. Gigabyte do not fill in the revision information in the image all fields are āTo be filled by OEMā.
I also noted that the 25 ucode is 8Kb and the 28 ucode is 12Kb.
@Bugger Vance
Your bios-file seams to be valid. Cbrom199 shows the MCs in Slot1.
Which version of cbrom & which commanmds did you used?
@winactive
Please delete your last two ādirect fullquotesā in post #127 and #130 - itās not necessary.
Yes, bios versions are the same for both revisions.
Because of the different sizes, I couldnāt do it with HxD.
Youāre welcome! Removing those old ones may not be necessary, that may or may not have been what caused you problems, I think there is room in there for a few more so probably other issue.
See below, that may be the issue you had, but didnāt notice it was the problem if not checking edited BIOS with MCE post-edit.
I only removed both of those because I always remove all older microcodes for same CPUID when putting in newer version
@MiesMosel (Edited below, thought I used 115 but noticed this morning I did not use 115 (used 155 or 195), testing 155, 195, 198, 199 now)
Often different Gigabyte BIOS versions you have to use different cbrom version (per chipset series usually, but sometimes BIOS version too, and probably same for other brands sometimes too.)
For this mod I used cbrom 195 to do everything including the /nc_cpucode NCPUCODE.BIN command, 198 also works fine for H61 chipset I think, probably 199 too (if >>) Issue described below is maybe why you maybe did not see MCās in slot 1?
Iām not sure, I will redo as test for you later today with 199 and see if I can tell you what happens with it.
I compiled new NCPUCODE.BIN from blank with all same microcodes in same order as past (removing the two old 206A7 and putting in new version), then /nc_cpucode NCPUCODE.BIN. I did not remove both old MC due to size, only did because I always remove any old when putting in new (SOP)
After above NCPUCODE inserted, then hex edit out partial remaining old microcode that causes MCE error (packed or badly extracted) via hex edit on entire BIOS (as described in FAQ on page #1 of this thread)
Then redo /nc_cpucode NCPUCODE.BIN on edited BIOS once more to ensure checksums all OK
Iāll do it again later today with 199 and let you know if itās OK and same process needed for that cbrom version
@MiesMosel
155, 195, 199 all edit this file the same, well similar and usable I think. 155 does not show mem init block, so some sizes and MC count looks different in 155 before and post mod, but if check in other cbrom and MCE same 155 edited file in 195-199 after all looks the same.
198 and 115 cannot integrate NCPUCODE.BIN
Checksum from post cbrom edit same for a 195+199, before and after below MC corrections (varies for 155 edit, and some other anomalies with 155 sometimes too but it should be OK once hex corrected as mentioned below)
Above described issue from the FAQ on page 1 is the only issue I see when modifying this BIOS with any of the 3 cbromās mentioned (155/195/199).
All files are same after cbrom edit look ok/same in 195/199 Cbrom, then all ok/same after same hex MC dupe fix from FAQ #1
I do not have this board on hand, so cannot be sure all three would flash OK or not, so please know how to do BIOS recovery if flash fails.
Below are my test edits with 155, 198, 199 if you want to look at each - 3 x copies of post NCPUCODE.BIN insertion and then 3 x copies of each post hex edit correction to fix leftover dupe as mentioned above from FAQ #1 on page #1
https://nofile.io/f/wBWavChMrSy/Testing+Cbrom.zip
I compared all these edits (checksum) with the mod I posted yesterday, none match, so I am not sure which cbrom I used yesterday or why checksum doesnāt match one of these three from today test?
Maybe names or date modified, or I used some other cbrom and forgot?
Please be familiar w/ dual BIOS recovery options before flashing anything since I am not 100% certain on these now and cannot test!
All look OK to me for flashing (Post hex edit correction), pass all pre-look-over tests, and should either flash and be OK or give qflash error and not allow to flash so should be OK
Final summary after post below, I believe I used 155 yesterday and itās similar to todays mod checksum-wise, so I believe the original mod I posted is correct and will flash fine!
For CBROM, be aware that v1.80 and higher will try to rearrange and/or reajust the checksum or your modules that are before MINIT. This can render your bios invalid and unflashable.
For example: If you have a Gigabyte motherboard, chances are your bios wonāt be valid and Q-Flash wonāt accept to flash it if you use anything higher than the 1.55 versions.
@Phoenix48
Thanks, thatās probably why the 155 edit is different after all is said and done! Itās hard to keep track of it all even with my notes, since sometimes between same board BIOS versions outcome differs with different cbroms.
Sometimes 198 & 219 OK for gigabyte too, depending on chipset and depending on what you are doing
And my edit from yesterday and today with 155 look similar, but not at all like 195 or 199 checksums, probably only mod date difference making checksum not be same from today and yesterdays 155 edit.
That also makes me conclude I used 155 yesterday too, so thank you! First mod I posted originally should be fine!
Do you know how to edit and update H55N-USB3? Aside from hex edit, since I am not sure how to re-correct internal checksums post hex)
@Bugger Vance
For the microcodes, it would be to follow the guide with ncpucode.bin file inside the bios. The only problem i can see is that, for some unknown reasons, ONLY the ncpucode.bin file is showing up and nothing else. This cause a problem to correct the checksum once all the modifications are done. Usually, you just replace the last module in the bios to force cbrom155 to recalculate the checksum as the last step but there is no module showing up in this Biosā¦ I admit it is the first time i see that. All i can say for now is that you must find a way to correct the checksum somehow or the bios wonāt flash even if all the microcodes are updated correctly. Maybe you can find another Bios program to do that last step? Maybe Phoenixtool can do that, not sure about it.
I came to the same result.
New MCs are inside, but checksum couldnāt updated by cbrom155 or phoenixtool v273.
Itās an Award bios file.
I patched it with checksum patcher (patch64), but I donāt know, if this help to flash it.
@Phoenix48
Could you check this file?
ga-h55n-usb3_f5.zip (5.23 MB)
From my experience, the best way to know if the checksum is correct with Gygabyte is to try to flash it. If QFlash accept it then all is good. If not, QFlash will refuse to flash it and give the reason "Invalid checksum" on the screen. So no danger in trying and you will know if it is OK or not.
Thanks for the comments, and trying to help both of you!
@Phoenix48 & @MiesMosel
I have been modifying BIOS for many years, and have tried to modify the H55N-USB3 many different times over the years, with all known available methods.
I asked thinking maybe you had some trick method for this specific BIOS, and was hoping maybe you had learned about how to mod this BIOS somewhere that I hadnāt come across yet.
Iāve found no way to mod that will flash or work properly, itās made differently than most other BIOS by Gigabyte, even back during H55/P55/P67 era when all other boards BIOS right then can be easily edited.
Even bypassing Qflash by jumping BIOS chip w/ tool or desolder/flash/resolder does not work, the BIOS doesnāt work once modified (Iāve literally tried probably 30+ edits forced in all fail to work).
No big deal, Iām not stuck working on that right now, only hoped maybe you possibly knew some secret Iāve missed.
Thereās only a few mentions on the internet of people trying to mod it too, all with no luck.
@MiesMosel - where is this checksum patcher (patch64) you mention? I tried looking for it the other day when I saw you mentioned somewhere too but could not find in Google.
Unless you used some trick or non-usual method like I mention above, meaning not usual methods to modify BIOS like this tools mentioned by Phoenix48, that BIOS will not work (Either fail Qflash check, or if forced/programmed on it will not boot the board)
I did not check, but assume from past attempts as Iāve tried modifying it 100+ ways before, all fail. I even tried using a few of the āSLICā type tools that allow you to modify modules in place (maybe the Phoenix tool you reference, I tried with a few of those too)
and modify without SLIC insertion just to modify the MCās and recompile but no luck that way either. Hex edit directly in place, fails too, 20+ Cbroms fail, etc
Maybe that Patch64 is the missing key? I canāt test right now, but always run into this boards BIOS few times a year and each time I do I give it another try to mod without luck, so I asked while it came to mind the other day.
I think itās due to unique BIOS structure/programming, right when Gigabyte started to combine UEFI and Award and then later went all UEFI, itās some strange combo of both and I believe this is why we canāt figure it out.