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

---

If you insulate pins, no need to mod socket too, correct? To me that looked like do one way, or the other, both would = same/same
For the pins, you could use electric tape maybe, or find tiny wire to pull of plastic sleeving, I think that is what's used there

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

Ohh, sorry, I didn't notice that, and assumed the sleeving was small enough to fit, and it was an "either or" type of situation.
I think you may be correct! Unless, you can find small enough sleeving, or coat only those pins with lacquer etc maybe?

@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

Maybe find cheap similar alternative CPU to test cutting off pins with, if possible?

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.

Hello All,
It seems I landed in the right place this time - got to repair an old laptop (Clevo W76TH) currently running some Celeron, and a Q9100 that fits into the socket but makes the laptop power off in a couple of seconds after being powered up.
I'm not sure if that's a mobo limitation (ICH9) or just a matter of microcode flash? There's not much info on this model and no list of supported CPUs so I can just guess.
I extracted a list of microcodes from the original BIOS and the needed one (1067A) is there but it's outdated.
If I get the idea right, now I should download all updated microcodes .bin files, collate them to a single file and replace it within the BIOS so that I could flash it and give another try, right?

@DriVE654

Basically, all that is required is to change the ones that are outdated and restore the checksum after. But the method or software you can use to do that may require you to collate them all (like CBROM) and the methods or software you can use depends on what type of Bios you have (AMI, PHOENIX, AWARD, Dell, etc)

@DriVE654
Read this - [Guide] How to update the CPU microcodes on a non-UEFI Award/Phoenix BIOS (27)