Hello Bugger Vance,
this bios is very special - yes.
1. Did you tried my edited version (HxD + patch64) from post #138?
2. Here is checksum patcher (patch64) - I don’t know, where I found this!
3. Did you tried to let the last old microcode 20655h @ 0x7E27DF inside & … then add the new with command /cpucode?
4. You could also try old cbrom232 (Asus Award CBROM v1.15) for MC-insertion - link.
5. On JC-Electronic I found BIOS Version F6a, so at the end there are my last tries…
Best regards, MiMo
H55NUSB3_F5+F6a.rar (5.06 MB)
checksum_patcher64.zip (39.1 KB)
I decided I would try the 199 version (not hex corrected) and it worked, checksum was something like A1600h IIRC this was with QFLASH.
Microcode updated to 2D as expected, passed SPECTRE vulnerability test.
Given that flashing NVRAM can cause issues when working OK and repeat flashing may lead to lack of future success I stopped the experiment on the home run.
We may need to revisit it when the first wave of SPECTRE-NG microcode updates are released in a few days/weeks.
Because i was talking about QFlash in my last post (# 139), i thought about posting the latest version of the QFlash module i have for those who wish to update it. So you can now download the module QFlash v2.24 (Usually named SBF.bin in the Bios) at the end of the first post.
I know nearly all owner manuals online shows images of a QFlash v2.25 but i was never able to find this module version anywhere. So if you find it, please post it.
To know, which version you have, open the SBF.bin module with HxD editor and look for a version number not too far up from the end of the codes (around 100 lines up).
@MiesMosel
Thanks!
1. No, I’ll have to dig out the board again and try later when I have time, but I’m sure outcome will be same as all my previous attempts unless Patcher64 is magic (And hopefully it is!)
2. Thank you, thank you! 
Is there any /switches or -flags that can be used with the program? I tried help and ? but no joy given
3. Yes, I have tried like that and many variants that way as well.
4. I have tried MANY Cbrom versions, I have about 30+ I think
5. Thanks for looking further, I had that BIOS already too.
I will try your BIOS mod soon as I can find time, and if no luck I’ll see what I can get done with Patcher64, thanks again for sharing it!
@winactive
You must use the “hex Corrected” version of any BIOS I posted. Without that the first microcode is corrupted and duplicated!
I only uploaded those uncorrected in case someone wanted to look at/compare with other BIOS edits while we discussed that issue/modification methods (ie which cbrom and what happens etc.).
None of those without hex correction should be flashed at all, all contain corrupted first microcodes (badly packed, half of previous left at beginning after initial cbrom insertion of NCPUCode).
If you open with MCE (MC_Extractor) you will get warning and see what I mean about that
Please reflash hex corrected version, or you could have issues later on possibly. Not sure what those would be, but probably some CPU errors or bugs etc at minimum.
Thanks for the info Qflash @Phoenix48 - If I see 2.25 anywhere I will come back and post here for you.
Ok understood.
I don’t think it will be an issue in the interim. Maybe the 2D is not the first microcode so it should be irrelevant for the CPU in the mainboard at the moment. I will be sure to flash the hex corrected variant of the BIOS if I am required to produce a modified image after the microcode update due later this month. I have opened a support ticket with Gigabyte but their response time is quite random.
I’m not sure I follow all the process correctly yet but I will be watching the thread particularly with instruction on how to use the patch64.exe
IANAP, so a hex editor does not feel like home either
I checked to be which was first for you, and it’s CPUID 206A1 which is some ES CPU’s. I’m not sure which all ES CPU’s series that covers, but as long as you don’t use ES later on then it will probably be OK.
Although, it could possibly be causing some hang-up or delay during boot, when BIOS reads all the microcodes and only finds a duplicated partial code, but that may not even be noticeable(?)
The 206A7 2D microcode is 6th in the properly fixed file, but it’s 7th in the one not hex-corrected due to first microcode being partially duplicated occupying 2 leading entries.
Next update, if you need one, I 'll only post a single mod BIOS file so there wont be any confusion on which to use
which cbrom did you insert with? So I don’t use that one
You’re welcome and thanks, I grabbed your NCPUCode before I replied. You may have to try a bunch of version to find right one for this model, I checked your modified BIOS and it looks OK.
Is Qflash giving you error when trying to flash? If not, what are you trying to flash with? Try the attached one (used 196) and your NCPUCODE.BIN
The NCPUCODE.BIN might be the issue? It looks OK to me, useable at least anyway and no error in MCE when opened.
If you don’t get it by tonight, and attached file doesn’t work, I can make new NCPUCODE tonight for you from scratch.
G41MC.zip (470 KB)
I used your microcode. What’s the result, video seems to cut off right at flash complete so not sure how reboot went.
If failed you’ll have to manually kick in dual BIOS recovery if it does not itself.
If that failed, then 196 and 155 fail at inserting NCPUCODE on this BIOS, so does 115 I tested and it doubled the size so it’s a fail.
Have to try some others next, that or the NCPUCODE you posted isn’t good to use modified in tht way.
I see what you mean now, in MCE. That’s the microcode you attached. And I see it has 37 in when put in BIOS, but only 34 before that, very strange!
I can make all new ncpucode tonight, and BIOS if you want, but I have to leave right now. Hope you can get recovered before tonight if that’s a bad flash above!
If you guys are using that checksum patcher called Patch64 I posted in another thread use it with caution because I have found that depending on the option rom it sometimes works and sometimes does not work correctly. Ethaniel in another thread about building a custom nvme option rom driver posted his own checksum patching utility that produced different results though his utility also changes the device vendor ids and was specific to his driver.
No, I did not use patch64 @davidm71 , since I see it does something but can’t tell what that is I do not use. I saw it say inserting something once when I tested I think, not sure what it said, but whatever it was didn’t look like checksum related to me so I don’t use.
As for the corrupted microcode, just that one that is doubled or corrupted will fail to load if that CPU is used (CPUID F34 it looks like)
I’ll make a new BIOS later tonight, with corrected microcode, that way any CPU you use in the future will work as expected.
* I tested a bunch of cbroms, all that work give that same microcode packing error, so I think maybe it’s due to that NCPUCODE.BIN.
I’ll make a new one tonight without the editing you mentioned and see if that works better,
@Bugger Vance and @MiesMosel and @winactive
The ‘Patch64.exe’ utility you guys were talking about and shared couple pages back is the same one (checked byte by byte) I had compiled from Pinczakko’s source code over here: https://github.com/pinczakko/PCI-Expansi…/master/utility
The way you use it is ‘Patch64 option.rom’ however I have discovered mixed results and would not use it at all for microcode files (though I never tested that out).
Recommend using a bosch emulator or Qemu to test the checksum corrected roms before flashing.
Just a public service announcement.
As you were… Carry on…
Thanks for the link and info on that, I’ll have to read about it’s intended use. I asked you for a copy while back, I remember that, but never used other than a test to see what it did and since not knowing how it was supposed to work it looked off to me so I set aside.
I’ll read about it now, thanks! Normally I don’t run into issues where checksums are a problem, but always good to have tools to check things when possible and when there is problems.
I see, it’s for fixing PCI Rom checksums, so nothing we really need when doing these kind of BIOS mods.
Thanks @konstantiniyyr1 I download it once from your previous post, that’s the code I inserted on the BIOS. I was thinking earlier today, maybe the way you modified it, cbrom saw that and didn’t like so tried to correct it maybe? And maybe that’s how it gets corrupted on insert?
I’ll build a new one myself, and hopefully not have this issue. BIOS coming once I make new NCPUCODE.BIN
@konstantiniyyr1 I see what you mean now, even with new NCPUCODE I made, same happens with MANY Cbroms (Duplicated microcode entry @ 13 > 37)
I tested following cbroms - 140, 149, 151 & 1551, 180, 182, 195, 196, 198, 199 << all do the duplicated code from middle to end
These cbroms fail to insert, or insert poorly and crash or corrupt etc
115 (Doubles code size), 124, 208, 602, 132, 214, acebrom, ACBROM208, 201, 130, 201b, 205, 207, 215, 217A, 219, 220, 606
Now I see why you did the Hex editing! There will be dupes in this BIOS 1067A (x2) and 10676 (x3), but on purpose, only due to separate codes for different platforms.
This way you can use this BIOS for any 771 CPU too, if you want. These dupes are not same as cbrom created dupes due to this bug, I insert these on purpose to all 775/771 mods
So I think best is what method I mod for you earlier (Cbrom196 for insert of NCPUCODE), I did same now and used my NCPUCODE.BIN and then hex edited (entire BIOS), and remove the dupe cause by cbrom @ last entry only.
So possibly same mod you did initially, but maybe I did better way, so should flash and does not have dupes.
After all that I extracted a PCI ROM with cbrom115 and reinserted post hex edit.
I’m not sure if that’s required or not, but I think it’s best that way and maybe what cause your initial mod to fail, unless the hex edit/dupe issue caused it
BIOS Attached
G41M-Combo MOD F3.zip (468 KB)