@Haskeer
Ok, so i don’t understand why it is not working because the microcode for:
- T6400 = CPUID (SLGJ4) Production model = Microcode 1067A (Present in the Bios)
- Q9100 = CPUID (SLB5G) Production model = Microcode 1067A (Present in the Bios. Yes, the same one)
So in theory, it should work without problem… But there is one remote possibility that you can verify. Verify on the new CPU if you have this:
- Q9100 = CPUID (QGMU) ES/QS model = Microcode 067A (Not present in the Bios)
Those 2 also exist but sems even more rare:
- Q9100 = CPUID (QDRS) ES/QS model = Microcode unkown for sure but probably 067A (Not present in the Bios)
- Q9100 = CPUID (QAVK) ES/QS model = Microcode unkown for sure but probably 067A (Not present in the Bios)
For référence:
ES = Engeneering sample
QS = Qualification sample
So if you have one of those, that would explain why it does not boot because they don’t use the same microcode and this one is not in the Bios. Worth a try to check that.
@Phoenix48
Thanks for your fast answer.
My Q9100 isn’t an engeeniring sample.
On CPU PCB i read: 5834b430 slb5g over the DIE and aw80581q9100 2.26/12/1066 below the DIE
I also know that they have he same CPUID, but different stepping (R0 for T6500 and E0 for Q9100). I thinked that this could be a problem
@Haskeer
Well… That is at least one possibility that we eliminated. As for the same microcode, i can’t see why it would cause a problem. On top of that, the microcode 1067A is the latest version so it should be without problem with the new CPU. I know it may sound like some stupid basic questions but when everything else failed, i have to ask them: Are you sure your Q9100 CPU is a good one and working? No pins bent or missing or something like that? Also maybe a bad installation that prevent it from working like it is not well seated in its place? May worth a look also just in case.
@Phoenix48
The cpu seems to be fine, no pins are bend and no scratches on DIEs
But I cannot try the CPU on another MoBo
Official BIOS already has suitable microcode for these CPUs. But the motherboard in your laptop doesn’t support quad core CPU.
You can try to modify CPU by this way - http://abload.de/img/quadcore-pinsy1dm5.jpg
and a socket - http://abload.de/img/sockelt6126e71.jpg
(source)
@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
It can help. But success isn’t guaranteed.
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)