@DeathBringer
Hi and thank you!
Can I just cut off those 5 pins from my q9100? In this way I don't have to modify the mainboard. Also beacouse I don't have the material to insulate the pins and to mod the socket.
I read some replyes of the thread you linked, but they speack about some motherboard mod and I'd prefere to don't mess with it

Zitat von Haskeer im Beitrag #406

---

Can I just cut off those 5 pins from my q9100?

---

@DeathBringer
ok thx
@Lost_N_BIOS
If I wrap around something on a pin, it will not fit inside its hole into the socket, for this reason you have to make the hole bigger. Or, at least, this is what I understood from the pics posted by DeathBringer. Correct me if I'm wrong.

@Lost_N_BIOS
Maybe, but pins fit without any chance to put somethings among pins itself and the surrounding hole, for this reason I asked about cut the pins

Hello Guys, hello @Lost_N_BIOS

I tried a BIOS CPU microcode update today, but I am not sure if I did it correctly and don't want to brick the board of a friend.

First, here are the basic information:
Mainboard: GIGABYTE GA H67A-UD3H-B3 Rev. 1.1
BIOS version: F8 (h7aud3h3.f8)
Tools used: cbrom155.exe and MCE 1.52.6 r176 with current database

First strange thing: with original bios cbrom only shows a partial list of the microcode (command /d), while MCE shows them all.
After replacing initial NCPUCODE.BIN with empty file and then with newly concatenated file, cbrom shows none, while MCE shows them all (new versions).
After forcing a recalculation of checksums by extracting, releasing and adding a module (i tried logo and last romfile), cbrom output doesn't improve, but now also MCE shows no microcodes.

What I am doing wrong?

Wrong CBROM version?
Or another idea might be, that the bios gets corrupted because I use one microcode less. The total file size of the new NCPUCODE.BIN is larger than the original, though. So I thought it would overwrite any old residues, but I might be wrong.

Any hint is appreciated!

@ Skorbin

The partial list is normal. CBROM is not able to display them all.

The rest is not normal, at least not after the checksum is fixed, but it is often happening. CBROM is often a tricky thing. I remember that i had sometimes to do the exact same command twice for it to work. Other times i had put my microcodes in a different order and it worked for no apparent reason. Also, sometimes it is simply an incompatibility between the Bios and CBROM to release the microcodes. It is one thing you can try: Try to add a "/nc_cpucode Release command with CBROM 1.98 just before you put in your empty ncpucode.bin and all the rest normally with CBROM 1.55. See if that makes a difference.

If that does't work, open your Bios with HxD after each command and see what happened to the microcodes. That usually gives a clue to what the problem is.

I tried the Release command with CBROM 1.98 before adding the empty ncpucode.bin, but the results stay exactly the same (all microcodes visibly before recalculation, none after) :-(

As I haven't open a hex editor for a few years, I need to polish up some almost forgotten knowledge ... ;-)

I'll keep you updated.

A side note: Cbrom 155_1 produced the exact same result as Cbrom 155 for this BIOS file.

When comparing unmodified BIOS with the updated one (just the NCPUCODE.BIN), I see only a few differences:
- the microcode area is now overwritten with the new codes and is slightly longer, but ends at the exact same address
- at 3EBFFE two byte are changed (0C 22 -> CC A1)
- at 3EBEF5 one byte is changed (B2 -> 71)
- at 3EBEBB three bytes have changed (DF 83 FC -> E0 3F FE)
- The area from EE010 to EE0CF is changed from FFs only to (CA 01 00 00 FE FF 00 00 FE FF 00 00 ....)

I am not very good with the code itself, but I would assume that we have maybe changed offsets and changed checksum(s), but the last part seems strange to me: why is a whole area changed?

Actually I initially wanted just to update the codes for the Ivybridge CPUs to allow for the E3-12xx V2 XEONs. But the microcode is longer than the old included one, so just overwriting it with HxD wouldn't do it and so I went deeper into the whole matter. But now I start to get to my limits ...

@Skorbin

Maybe you can try this method instead: Open you Bios with HxD and replace your microcodes with the new ones. If it is bigger than the original one, use the command "copy and insert" instead to be sure to not overwrite anything. When your microcodes are all done, use CBROM 155 to restore the checksum by replacing one of the last modules. Then verify if CBROM and MCE accept it. This method usually work for microcodes.

Also, with this method, if you are in no rush, you can do this one by one with each microcode you want to replace. At first, try replacing only the one you use, verify it, if everything is fine, try to flash it. If the flash is accepted, then go on with the next. If only one of them is causing the trouble, you will find it this way when you do the verify phase with MCE and CBROM (mostly MCE). I know it is the long road but it is the sure road.