LGA 771 Xeon microcode: CPUIDs, platform IDs and why an LGA 775 BIOS needs the patch

You can do the tab cuts and the sticker perfectly, drop an E5450 into a P45 board, and still get a complaint about an unknown processor at power-on. Or the board boots, Windows starts installing, and the machine freezes halfway. A common cause is not the adapter at all. It is a missing entry in a small table inside the BIOS: the microcode patch for that exact chip.

This page explains which patch a modded Xeon needs, why a desktop BIOS usually does not carry it, and where the official files come from. The editing itself happens in two companion guides, one for AMI images and one for Award and Phoenix-Award images. The physical side of the mod lives in the LGA 771 to 775 guide.

Microcode in one paragraph

Microcode is the processor's own low-level firmware. It sits under the x86 instruction set, turns some instructions into internal steps, and carries fixes for errata (Intel's word for documented bugs). Every chip leaves the factory with a version built in, and Intel publishes update patches that replace parts of it. A patch does not stick: Intel's microcode repository notes that the microcode state resets on a power reset, so the update must be loaded on every boot. The usual place for that is the BIOS, which applies the matching patch before anything else runs. The longer story is in what CPU microcode actually does.

Two numbers pick the patch

A BIOS does not choose a patch by model name. It compares two values that the chip reports about itself.

The CPUID signature

The CPUID signature is a 32-bit number the processor returns when software runs the CPUID instruction with EAX set to 1. It packs the family, the model and the stepping (the silicon revision) into hex digits. Here is an E0-stepping E5450, whose signature is 0x0001067A:

The model that tools display is the extended model times 16 plus the model: 1 x 16 + 7 = 23, which is 17 in hex. So Linux reports this chip as family 6, model 23, stepping 10, and Intel's Linux file for it is named 06-17-0a. Stepping names such as C0 and E0 map onto those stepping IDs, and the CPUID, stepping and sSpec guide shows how to read them off the chip.

The platform ID

One silicon design often ships in several packages: desktop, dual-socket server, mobile. Intel tells them apart with a 3-bit Platform ID in model-specific register 17h, enough for eight platform types. Each microcode patch carries an 8-bit field in its header, which Intel's documentation calls the processor flags. Every bit that is set means "this patch is for platform N". A patch applies only when the CPUID matches exactly and the chip's own platform bit is set in that mask.

Two masks, decoded by hand:

• 0x44 is binary 0100 0100. Bits 6 and 2 are set, so the patch serves platforms 6 and 2.
• 0x11 is binary 0001 0001. Bits 4 and 0 are set, so it serves platforms 4 and 0.

A chip that reports platform 6 finds nothing to load in the 0x11 patch, even though both carry the label 1067A. That is the LGA 771 microcode problem in one line. The Win-Raid guide to Award microcode updates puts it this way: "sometimes CPUID are the same but platform are not" (Win-Raid).

The CPUIDs that matter for this mod

The CPUIDs and sSpec numbers below come from Intel's specification updates (the December 2010 editions for the Xeon 5400, Xeon 5200 and 45 nm Core 2 Quad lines). The platform masks for the 45 nm chips come from Intel's Microcode Revision Guidance of March 2018, which lists a platform value for each product group.

Look at the platform masks. The desktop groups are 91 (bits 0, 4 and 7) and B1 (bits 0, 4, 5 and 7). The Xeons sit on bits 2 and 6. No overlap, so no amount of desktop microcode helps a Harpertown. Database pages such as the E5450 list both steppings of a model with their sSpecs.

One correction to lists you may find elsewhere: Intel's 45 nm Core 2 Quad spec update gives the C1 and M1 steppings as 10677, not 10676. No LGA 771 chip in the Xeon 5200 or 5400 spec updates uses 10677, so for the mod you deal with two 45 nm signatures only.

The 65 nm parts

The 6FD signature belongs to desktop M0 chips such as the E4500. None of the Xeons in Intel's 5100 and 5300 spec updates use it, so it only matters when that is the chip you are taking out of the board and might want to put back. Intel's 2018 table does not cover the 65 nm parts, and its Linux files for them carry several patches each (the 6F7 file holds two, with masks 10 and 40). We have not found an Intel document that says which 65 nm product reports which bit, so for these chips read the value from your own processor, as shown below.

Why the desktop BIOS does not have it

A board maker fills the BIOS microcode table from its own CPU support list. For a P45 desktop board that list is Core 2, Pentium Dual-Core and Celeron chips for LGA 775, so the table holds patches with desktop masks. Patches with masks 04, 40 and 44 belong on boards with LGA 771 sockets, and there was never a reason to spend ROM space on them in a desktop image.

Here is what Intel's repository holds for the 45 nm signatures, read from the patch headers:

For a Harpertown or Wolfdale-DP build, the patches you want are 10676 with mask 40 (Harpertown C0), 10676 with mask 04 (Wolfdale-DP C0) and 1067A with mask 44 (either family at E0). Carrying all three takes 4 + 4 + 8 = 16 KB of table space, which is why the how-to guides spend time on freeing room.

When the Xeon boots without its patch, the CPU simply runs the microcode it was built with. What happens next depends on the board. Owners commonly report a POST message about an unknown or unsupported CPU, a prompt to press F1, random freezes under load, or Windows installs that fail partway through. Page 5 of the LGA guide sorts those symptoms by cause.

Find your chip's numbers

1. Read the sSpec on the heat spreader and look it up in the tables above or in Intel's spec update. SLBBM, for instance, is an E0 E5450, so CPUID 1067A and mask 44.
2. In Windows, CPU-Z shows the same thing in its CPU tab: for an E0 chip, Ext. Family 6, Ext. Model 17, Stepping A and Revision E0. PowerShell gives the raw signature as the last eight hex digits of ProcessorId (the first eight are feature flags and vary). An E0 Xeon ends in 0001067A:

PS> (Get-CimInstance Win32_Processor).ProcessorId
BFEBFBFF0001067A

3. On Linux, a live USB stick tells you the signature, the loaded microcode revision and the platform bit:

grep -m4 -E '^(cpu family|model|stepping|microcode)\s+:' /proc/cpuinfo
cat /sys/devices/system/cpu/cpu0/microcode/processor_flags

The second command prints the chip's platform bit as a mask. Going by Intel's table, a Harpertown should show 0x40. For a 65 nm Xeon this is the number you were missing.

4. To see what your BIOS already contains, open the image in MC Extractor, an open-source tool that lists every patch it finds with CPUID, platform, revision and date. It also tells you whether your board's current chip has a patch, which you must keep.

Where official microcode comes from

There are two official sources, plus one community reference.

• Intel's Linux repository. The intel-ucode folder holds binary files named family-model-stepping. They are in the format BIOS tools expect, but one file can hold several patches back to back, so you split out the one you need. For these chips the files still carry the 2010 revisions in the table above.
• A newer official BIOS. Board makers sometimes shipped later revisions than the Linux repository has. Intel's 2018 table lists revision 612 for 10676 and A0E for 1067A as the production versions for these Xeons. A BIOS update for a board that officially supports the chip is the place such revisions turn up.
• The CPUMicrocodes collection. The platomav/CPUMicrocodes repository gathers patches pulled from official BIOS updates, Intel's Linux packages and Windows updates, with file names that spell out CPUID, platform mask, revision and date. It is community-run, so use it as a reference and check every file you take from it in MC Extractor. Its own readme warns that the latest revision is not always the best tested one.

We do not host or link microcode files or BIOS images here. Take them from the sources above, and keep note of where each file came from.

Can the operating system load it instead?

Partly. Linux applies microcode very early in boot from the initramfs (the kernel looks for kernel/x86/microcode/GenuineIntel.bin), and distributions fill it from packages such as intel-microcode or microcode_ctl. Since Intel's 1067A file includes the mask 44 patch, a current distribution on an E0 Xeon can bring the CPU up to A0B even when the BIOS has nothing. Windows does something similar with its own file, mcupdate_GenuineIntel.dll, though which patches it carries is Microsoft's choice.

It does not replace BIOS support, for three reasons:

• The BIOS sets up the CPU before any operating system exists. Its CPU checks, power management setup and any "unknown CPU" stop happen without the patch.
• An installer only gets a patch if its own boot files carry one, so a crash during setup may not be helped by the microcode package of the system you are trying to install.
• Intel's own repository notes that microcode is best loaded from the BIOS and that some updates are only meant to be applied there.

Treat OS loading as a useful second layer. It is also a fair test: if a Linux live stick runs stable with the patch loaded early, the BIOS edit is worth doing.

AMI or Award: which guide you need

Find out what your BIOS is before you collect tools.

• The first POST screen usually names it. AMI images say American Megatrends; Award images say Award Modular BIOS or Phoenix AwardBIOS.
• In Windows, Get-CimInstance Win32_BIOS shows the BIOS maker, and CPU-Z's Mainboard tab shows the BIOS brand.
• On Linux, sudo dmidecode -s bios-vendor gives the same answer.

ASUS boards of the P35 to P45 years are mostly AMI. Gigabyte boards of that period mostly use Award and many carry a second BIOS chip. An AMI image (AMIBIOS 8, the legacy kind on these boards) goes to the MMTool guide. Award and Phoenix-Award images go to the CBROM guide, which also explains why a Phoenix SecureCore image is a different animal. OEM machines from Dell, HP, Lenovo or Intel itself often use their own image formats and update tools; check them against page 2 of the LGA guide before you start.

One last thing to plan for: the next official BIOS update you flash replaces the whole image, patch table included. Keep your edited file, and redo the edit on any new official release before you flash it.