@tokafondo
I looked if any differrences or new technology was introduced by the i3-550 over the i3-540 that could explain your problem. I did not find anything really significant. Only >thoses<:
- i3-540 has a stepping of 2 and i3-550 has a stepping of 5.
- i3-550 introduced only one new technology: “Process context identifiers”
- I3-540 use microcode 20652 and i3-550 use microcode 20655. Probably because of the last 2 differrences mentionned.
So in the end, i have a hard time understanding why your i3-550 doesn’t work. Maybe there is a clue in the fact that they don’t use the same microcode but it may also be irrelevant to your problem. Very hard to say at this point.
@tokafondo - you didn’t answer my question at #359, to me, for now, that is the most relevant thing to know the answer to
I think I did!!! 
-------------------
And now I found this HP brochure where is clearly stated that…
So I’m confused right now: Are HP sold Intel CPUs somehow different than retail ones?
Please edit your posts when you want to add more info. And no, you did not answer my question at all, only added info/report on more unsupported non-original CPU’s (ie more of the same, same problem, unsupported CPU’s)
Please test your modified BIOS with the original, or a known compatible CPU. This way we know your BIOS mod is OK, then further speculation or edits can be done/discussed.
Without this test done, we only know your mod BIOS does not work, but we do not know if this is due to your modifications being bad, or the CPU being incompatible.
To your second post. No, CPU’s are same, it sounds like your i3-550 may be faulty, can you test it on some other board to confirm it’s functioning? If not, then no point in continues messing around with this BIOS until you do and know the CPU is working.
Or, it’s possible your CPU is ES, does it say Confidential on it? If not, what is the SSPEC printed on the CPU (Should be SLBUD)? If it’s Q4DD, then that is ES CPU, and this may need different microcode than 20655 (usually this would be 20650 or 20651, which your BIOS has but not latest version)
I have three computers at home with a LGA1156 socket.
One with i3-550 (Asus).
One with i5-650 (Acer).
One with i7-860 (HP ML110 G6).
The three CPUs boots fine in the Asus and Acer boards. The HP board only boots fine (and I mean, once and once again with no beeps) with the i7-860.
My modded BIOS has been running in the HP board since I flashed it.
The original Xeon x3430 that this board came with, is not with me because I just had bought the board to be used with the i7-860 (I tested it before byuing it and it worked like a charm so I didn’t test any other cpu), and left the x3430 with the owner. The owner already sold the Xeon so that way is closed now.
So… I’ve ordered a x3440 so I’m able to make more tests.
What puzzles me is that the i7-860 is not in the CPUs supported list.
I do confirm it’s SLBUD.
I can link my modded BIOS so you can take a peek if you think it can help.
---------------------------
Well I think I have a theory for this: When the computer boots, it gets the CPUID for the installed CPU. Then, it looks for a table where there are listed the CPUIDs and the offset in the BIOS code where the microcodes are stored. If there are no microcodes for the installed CPU, then it won’t boot.
In my modded ROM, I had to move the microcode for the 20655 CPUID, because there was no room for the new one. But I did not move the 106E5, that belongs to the i7-860.
So… I’m searching for previous versions of the 20655 CPUID microcode that could fit in the space that the BIOS has for it and try to update them so it works.
@tokafondo - Please edit your posts when you want to add more info and no one has replied yet, thanks
Yes, your i7-860 would look same to BIOS in general if it was only comparing CPUID’s, and since it and X3430 (Stock CPU) runs, either they’ve approved that CPUID in some list, or it’s only going by CPUID in some list. If there is an allow/deny list
Some are restricted by CPU TDP too, so you need to look at that as well.
I don’t need to look at your BIOS mod, if you confirm it’s booting OK with generally compatible CPU. But yes, I guess to be sure, please upload it and the stock BIOS so I can check
Your theory can’t be the sum of what happens here, because in your images on previous page, stock BIOS in MC Extractor, I see 20655 CPU microcode is already there (not latest though, maybe an update on this will help?)
Your removal of 20655 explains all the issues now! Sorry, I didn’t notice that you did this until I was typing out this sentence! i3-550 wont boot without that CPU microcode!!
There is no need to find microcode same size as original. Upload stock BIOS for me and I will update all CPU microcodes to latest for you, size doesn’t matter to me 
Thanks. I didn’t remove the 20655 code but moved inside the flash area that belongs to the microcodes.
Here you have both original and SLIC’d roms. Read with linux’s flashrom.
https://easyupload.io/xqsvd2
pass: Lost_N_BIOS
You just said you removed 20655 above, and now you said you didn’t but moved it? Makes no sense to me, it’s a microcode, would already be where the microcodes are.
So probably something messed up in your edit, sounds strange so I suspect this is the issue. I checked both of these BIOS microcodes, and 20655 is there, and in same exact location, so I assume neither of these is your mod BIOS you discussed editing/moving 20655 (Correct)?
I will edit stock, you test your CPU’s etc, then once you see it’s working or not, you can SLIC again if needed. Please wait, edit coming with microcode updates
* Edit - @tokafondo - I did not update 106E3/20650 because I could not find newer than what’s in there, they are out there but I do not have a copy 
Rest updated to latest version - http://s000.tinyupload.com/index.php?fil…148834676160558
If that fails, recover, and I will send you new BIOS with microcode volume staying same size
First of all: thanks.
I didn’t remove but moved 20655. What I removed was 106E3 and 20650 because they seem to be some kind of beta or engineering CPUIDs.
I’m trying your BIOS now.
106E1/106E3/20650/20651 all likely are for ES CPU’s. How did you remove them, where/how did you move (and why) 20655?
Well. I opened in HxD the .rom file I dumped.
Then, with intelmicrocodelist.exe I found the offsets of every CPUID inside that file. In HxD, I went to every one of that offsets and saw the size of every CPUID code.
Then, I filled with zeros the CPUID code that didn’t wanted to keep.
Then, I copied and pasted, overwriting the code of the CPUID in the very same offset inside the file. So…
Look the offset of 20655: It’s 0xAD820 and size 800
Now it’s 0xA3020 and size 1000.
I did it all by hand. Flashed back the .rom file and at least it booted the i7-860 but not the others. Well… I will tell:
Every time I test the i7-860, then I shutdown the board, swap the CPU to the i3-550 and then… It boots. But, when I shutdown again with this cpu, the very next time with no change of hardware at all, it won’t boot and will beep.
UPDATE:
Flashed your BIOS. Cleared CMOS settings. Now it boots and get stuck here:
As I can’t boot to an OS, I’m debricking it.
UPDATE:
Why to move the 20655 code? because of this:
Just below the end of the 20655 microcode (red line), there are no zeros or padding or whatever: there is another module I have not been able to identify. If by some reason the BIOS expects that that code is there at that offset, overwriting it or moving it would make the system go nuts or something.
That’s why I tried to move the 20655 to another location with a known offset. But well… maybe the BIOS does expect certain microcodes to be in certains offsets. And if is there a table where that offsets locations are, related to certain CPUIDs, editing it should make the trick. What do you think?
Thanks for info, and test report on BIOS, may stick like that due to the rebuild or due to I changed file size of microcode volume
Please test both of these too, thanks. If both these fail too, I will edit it more similar to the way you are doing. But, what you show in second image, if working for other CPU’s, should be OK with 20655 CPU then too.
http://s000.tinyupload.com/index.php?fil…889095257435721
When it boots with CPU, but then on reboot wont, does clearing CMOS help at all?
Testing ML110G6MPBE268.ROM… It gets stuck in "Mouse Initialized", like the picture above. Now debricking.
No. Nothing. Clearing CMOS, or completely removing power does not help. It just boot the first time after swapping the i7 with the i3, and then nothing. And then, swapping back the i7, it boots again with no more messing.
I will see if I can find a table that holds the microcode offsets, I didn’t look earlier but I will tonight when I have more time. * Edit, quick look and no luck, I don’t see anything related in any modules or the internal settings/setup etc
@davidm71 @MiesMosel - I can’t remember all the rules, and where offset storage locations may be for Phoenix BIOS and ucodes, can you drop some info or take a look at the BIOS at post 367
Thanks 
Testing ML110G6MPBE264-1.ROM… Stuck at Mouse initialized. Debricking now.
UPDATE:
Testing ML110G6MPBE264-2.ROM… Stuck at Mouse initialized. Debricking now.
Thanks for report. I tagged a few users in an edit above, maybe they can advise.
Reading Notes on Intel Microcode Updates and searching for clues that leads us to go deeper in this.
Thanks.
UPDATE
I’m just trying to find the bytes of code that could be identified as executing the MSR_IA32_UCODE_WRITE instruction, because near it there is the offset that leads the CPU to read the microcode from, as seen in the link above.
Still working on this, because if discovered, it would lead to a better understanding of Phoenix BIOS microcode updates.
I’ve seen that the very first instruction any x86 cpu will run te code located at F000:FFF0 location in memory. (seen here). It seems to be that in that location, the instruction is always
1
JMP F000:E05B
The bytes of that instruction are EA 5B E0 00 F0. So I loaded ML110G6_SLIC.rom (my proliant's SLIC'd BIOS mod) file, loaded in HxD and tried to locate that sequence of bytes. Well... It seems that it isn't there, but... Maybe the code where this instruction is compressed, so I took the whole DUMP folder, loaded it in HxD and made a search in every file.
There are two matches: One in the BB.BIN file in another one in the BIOSCOD00.ROM file. It seems that the BB.BIN file contains the code that runs when the motherboard is set to recover a bad BIOS flash (that's what they say here).
Now I have just one file, that is BIOSCOD00.ROM. The EA 5B E0 00 F0 is there, but something is not right... the offset is not FFF0 at all. Is far less, so... false positive.
Now... How can I get a working dump of the BIOS? Well... It seems that with certain BIOSDUMP.BAT file that I found in the same website, I have been to dump the first megabit of memory, and I feed HxD with that.
Now yes... there is this EA 5B E0 00 F0 sequence there in the right offset. And what's most important now... several WRMSR, aka MSR_IA32_UCODE_WRITE instructions. I think they are part of the different subroutines that points the CPU to different offsets where to load the microcodes from...
Well… In all these days nobody replied or gave a clue. I keep trying to mod the BIOS until a point where I had to move the starting points where the microcodes were and finally softbricked my motherboard.
But this time I did messed something because the boot block of the rescue bios was moved and even the procedure didn’t work.
I ordered a CH341a programmer and a Intel Xeon X3440 CPU from Korea.
Now I’ve just finished to reflash the BIOS with the programmer and tested the X3440, that boots just fine, and is a supported CPU.
So… what now? I don’t know. Keep testing? Or just as I found the replacement CPU I was looking for (X3440 instead of i3-550), I should let this pass?
Sounds like you’re all set now, happy accident caused good CPU replacement and BIOS recovery
Plus, now you have flash programmer so can recover other boards in the future too, it’s a win-win!
The attempt to update microcodes on ga-ma770-ud3 r2 failed, system didnt boot after post. I used first guide with the amendment from "FAQ and Problems" for last problem with old and new microcodes mixing.