@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?

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.

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

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.