UEFI/BIOS limitations regarding Intel CPU upgrades

[Calbris]

If your newly installed processor doesn't boot, it could be likely due to a UEFI or BIOS limitation. First, I suggest checking your motherboard's firmware type. A simple modification such as adding CPU microcode may allow your processor to boot, but this generally applies to motherboards with a BIOS and might be difficult for motherboards with a UEFI. If you are not familiar with any UEFI or BIOS editing tools and lack any backup options such as an EEPROM programmer or something similar to Gigabyte's DualBIOS, do not edit the UEFI or BIOS image. Please understand this is not intended to be a UEFI or BIOS modification guide, it's intended to be a guide to find out the reason why your processor doesn't boot up.

A rough approximation I can provide is that most Ivy Bridge motherboards and newer motherboards are generally UEFI-based, while Sandy Bridge motherboards and older motherboards are BIOS-based. There are a few exceptions, however. For example, the MSI P45D3 Platinum is a UEFI-based Wolfdale/Yorkfield motherboard. This is not normal and is extremely unusual, so expect most Sandy Bridge motherboards and older motherboards to be BIOS-based.

All of the information provided in this post is mostly speculation and might be incorrect.

UEFI & BIOS code modules
• UEFI or BIOS reference code (Intel's equivalent of AMD's AGESA)
• CPU microcode
• CPU reference or initialization code
• CPU PPM reference code (PPM = Processor Power Management)
• CPU memory reference code
• Chipset memory reference code
• Chipset or PCH reference code (PCH = Platform Controller Hub)
• QPI reference code (QPI = QuickPath Interconnect)
• SA reference code or SA PCIE code (SA = System Agent)
These are written in C and x86-64 assembly, although the source code is only available to Intel employees. All code 'modules' are Intel's and are publicly available in executable machine code if extracted from a BIOS or UEFI image; the UEFI/BIOS vendor only handles the UEFI revision or BIOS core. In Intel's documentation, the BIOS reference code may sometimes be referred to as the UEFI reference code or vice-versa.

The UEFI and BIOS reference code is a set of reference code 'modules', as far as I know I'm not sure what exactly does it contain since it isn't public information. According to a few BIOS changelogs, it appears to address the PCH which suggests that it might be for the PCH or contain code for the PCH.

The CPU microcode is loaded after the CPU reference code. From what I've seen, the CPU reference code determines if a processor is able to boot. For example, if a matching CPU reference code exists but the CPU microcode doesn't match or exist, it might boot up with some issues present such as a missing instruction set extension. However, this may only apply to desktops as I rarely see laptops booting up with missing CPU microcode. Note that in some UEFI and BIOS changelogs, the CPU reference code is not explicitly mentioned. It's always something similar to 'added <CPU codename> support' or 'updated <CPU codename> framework reference code>', sometimes it's not even mentioned in the changelog. CPU microcode updates in UEFI and BIOS changelogs are generally mentioned as 'updated the Intel microcontroller unit (MCU) to <version>' or 'updated the <CPUID> microcode to <version>'. Note the term MCU stands for MicroCode Update according to Intel, but some changelogs refer to it as the microcontroller unit.

The CPU PPM reference code isn't necessary for a processor to boot at the bare minimum, since it only handles power management features such as SpeedStep and ACPI C states. Still, I could be wrong as the PPM reference code is rarely ever mentioned in a BIOS changelog. If it is mentioned, it will show up as 'updated PPM RC' or 'updated processor power management reference code'.

The CPU memory reference code loads alongside the CPU reference code to initialize installed system RAM. In a BIOS changelog, this is referred to as the 'MCH reference code' or '<CPU codename> MRC'. Newer processors with an integrated memory controller require a matching CPU memory reference code to boot, older processors without an integrated memory controller require Intel's BIOS specification updates and the chipset memory reference code to boot. If a matching CPU memory reference code is not found in the UEFI or BIOS, the processor will not boot. Note that the chipset memory reference code seems to handle FSB:RAM ratios. Assuming this is true, it may explain why a few laptops with the 865PE are unable to use the 1:1 FSB:RAM ratio. Additionally, I have no idea if Timna, 486SL, and the 386SL requires CPU memory reference code or chipset memory reference code to boot.

The chipset reference code seems to handle the integrated DMI and PCI Express controller in newer processors, but is rarely mentioned in BIOS and UEFI changelogs. Generally, the chipset reference code is normally addressed as the PCH reference code in most changelogs. For older processors, this is handled by BIOS specification updates. These BIOS specification updates are meant for northbridges and southbridges, which I assume might affect processor upgrades as some old laptops are equipped with a daughterboard containing a northbridge and a processor. BIOS specification updates for northbridges and southbridges are rare sightings in UEFI and BIOS changelogs, so I have no idea if they affect the success rate of a processor upgrade.

The QPI reference code appears to handle the QPI controller's speed and power management. I believe this doesn't affect processor upgrades, except for Socket H1 and G1 motherboards. If a Socket H1 or G1 motherboard does not include any sort of QPI reference code, all processors based on the Clarkdale/Arrandale architecture will not be able to boot on that particular motherboard. This is due to Clarkdale/Arrandale's usage of QPI controllers for its core and on-package GPU + northbridge.

The SA PCIE code likely handles the PCI Express controller, but I'm not sure if this is correct. The SA PCIE code is only present on Sandy Bridge and newer processors. Whether if this plays a role in affecting processor upgrades is unknown, since I rarely see system agent PCIE updates mentioned in UEFI and BIOS changelogs. However, I do see system agent reference code updates which may be the same as SA PCIE code updates. BIOS and UEFI changelogs generally mention this as 'updated SA RC to <version>' or 'updated Intel system agent reference code to <version>'.

Miscellaneous UEFI & BIOS components
• CSME or ME firmware (CS = Converged Security, ME = Management Engine)
• SPS firmware (SPS = Server Platform Services)
• TXE or TXT firmware (TXE = Trusted Execution Engine, TXT = Trusted Execution Technology)
• IGFX VBIOS option ROM (IGFX = Integrated Graphics)
• IGFX UEFI GOP driver (GOP = Graphics Output Protocol)
• BIOS ACM (ACM = Authenticated Code Module)
• SINIT ACM (SINIT = Secure Initialization)
• USB module
• LAN UEFI driver
• LAN PXE option ROM
• SATA RAID option ROM
All of these components can't be updated through conventional means via Intel's update utilities as far as I know, with the exception of the CSME/ME, SPS, and TXE/TXT firmware. To update option ROMs, EFI/DXE drivers, and other modules, you must use your UEFI/BIOS vendor's tools to modify the UEFI/BIOS image as they know the address ranges containing these modules. Look here if you'd like to know more - https://winraid.level1techs.com/c/bios-uefi-modding/7/none

The Management Engine and Server Platform Services have the ability to prevent certain engineering sample processors excluding thermal samples from booting up, sometimes it enforces a 30-minute timer on 'invalid' retail sample processors. Once the timer runs out, the ME or SPS initiates a forced shutdown. The only known fix is to use me_cleaner or flash an outdated ME or SPS firmware. Note that Active Management Technology and the Dynamic Application Loader are intended to be software running in the OS to interface with ME or SPS firmware, they are not software that runs in the UEFI or BIOS. Platform Trust Technology however, runs in the UEFI or BIOS as a part of ME or SPS firmware. If you need an older version of PTT firmware, you must flash older ME or SPS firmware.

The IGFX VBIOS option ROM and the IGFX UEFI GOP driver shouldn't be able to prevent an unsupported processor from booting if it's disabled, assuming that all it does is initialize the integrated graphics core. If it's enabled, chances are the processor won't boot.

The BIOS and SINIT ACM are part of Trusted Execution Technology, I doubt it has any ability that could prevent a processor from booting up unless TXT itself is enabled and the BIOS ACM is non-existent or corrupted.

Generic situations that can prevent a processor from booting up:
• The matching CPU microcode does not exist or the microcode's revision is outdated, or the microcode's platform ID does not match the processor's platform ID
• The matching CPU reference code does not exist
• The matching CPU memory reference code does not exist
The first is the most common problem that I've encountered, but sometimes adding the right CPU microcode might not be enough. This leads to the second and third situation, which is a pain to deal with because these BIOS code 'modules' are not standardized in such a way that you can easily update or add them with HxD. Extracting them seems to be possible under certain conditions - https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html

Updating or adding CPU microcode is not that difficult, generally HxD or a combination of UEFITool and HxD would do the trick assuming no UEFI/BIOS checksum routines are present. In most cases, the UEFI/BIOS update utility will complain about a checksum mismatch but allow you to flash the UEFI/BIOS image anyway. Whether if the motherboard boots after the flash is another question, as a checksum routine that fails could prevent boot-up. If you want to fix this problem, you have to find out where exactly is the checksum value stored in the UEFI/BIOS and then recalculate the entire UEFI/BIOS image's checksum to change the value so that it passes the checksum routine.

Here are some examples that happened in my experience which are related to the first, second, and third situation respectively:
• An 865PE motherboard boots up with a D1 stepping Northwood 3.0C SL6WK installed, but doesn't boot with a D1 stepping Northwood 3.4C SL793 installed. I believe this was caused by an outdated microcode revision.
• An 855PM motherboard boots up with a B1 stepping Banias 1.7 SL6N5 installed, but doesn't boot with a B1 stepping Dothan 2.1 SL7V3 installed. BIOS analysis leads me to think that a combination of a non-existent microcode and reference code for Dothan prevented the processor from booting up.
• A QM57 motherboard boots up with a K0 stepping Arrandale i7-640M SLBTN, but doesn't boot with a B1 stepping Clarksfield i7-840QM SLBMP. This is an extreme example of what happens when all three possibilities are happening at once. BIOS analysis and changelogs tells me that the microcode, reference code, and memory reference code for Clarksfield didn't exist. Another possibility is the VRM can't supply enough current during the boot-up stage, which hardly happens when it comes to processor compatibility scenarios but it could happen.

Specific situations that can prevent a processor from booting up:
• The matching IGFX VBIOS option ROM and/or UEFI GOP driver does not exist
• The matching QPI reference code does not exist or is outdated
• The SA PCIE code is outdated
The first and third typically happens with Sandy Bridge to Ivy Bridge processor upgrades, although there is a possibility that the second and third could apply but I'm not exactly sure since I lack the tools and hardware to test this out. There is a very high chance that the earlier three BIOS code 'modules' are missing as well, but again I don't have the tools to confirm that.

The second happens on Socket G1 or H1 motherboards supporting only Clarksfield/Lynnfield, though in practice I've only seen one such motherboard in a quad-core Lenovo ThinkPad W510. That motherboard just doesn't boot with Arrandale installed, only Clarksfield. I suspect that since Clarksfield lacks a QPI controller, there wasn't a need to include the QPI reference code into its BIOS.

Not related to the UEFI & BIOS, but may limit your options for processor upgrades:
• Chipset - PCH in newer platforms, northbridge and southbridge in older platforms
• Socket - pin-out
• VRM - VRD/IMVP (Voltage Regulator Down/Intel Mobile Voltage Positioning)
Consider these factors if you are absolutely sure that a hardware limitation is giving you problems with your processor. I can't provide much information since motherboard schematics and VRM specifications tend to be confidential information.

Generic hardware limitation examples:
• The chipset does not support dual-core processors due to a motherboard design limitation
• The chipset does not support certain processors due to an artificial restriction in its firmware
• The socket is physically identical but the pin-out is completely different
• The socket is physically identical but the pin-out is slightly different
• The VRM does not support the processor's voltage requirement
Chipset: 915 series and older chipsets officially did not support dual core processors such as the Pentium D, which seems to be a motherboard design limitation rather than a chipset limitation. This seems to be true as the ASRock ConRoe865PE and ConRoe865GV are able to boot with any Pentium D processor installed. I'm not sure what exactly makes them work with a chipset that old as I don't have the schematics for both motherboards, though I suspect the 865 series chipsets' ability to support Hyper-Threading has something to do with it. It could possibly be the I/O APIC, which would mean the 845 series chipsets could theoretically boot with a Pentium D as well.

The HM70 was known to have a restrictive Management Engine firmware preloaded from the factory, which prevented all Core i3, i5, and i7 processors from working for no real reason other than to stop processor upgrades from working. If anyone were to attempt an upgrade from a Celeron or a Pentium to the aforementioned processors, an 'Invalid CPU and PCH combination' error will be shown and 30-minute timer will be activated as soon as the processor boots up. After 30 minutes, the Management Engine will issue a shutdown command to the system. To bypass this restriction, you have to flash an outdated version of the Management Engine firmware - https://github.com/corna/me_cleaner/issues/186#issuecomment-1848402928. This is probably the only known way to deal with it, as far as I know.

Socket: Socket P and Socket B had a problem with two series of processors sharing the same socket despite utilizing different electrical pin-outs. For Socket P, Sossaman and Merom/Penryn shares the same socket but Sossaman will not function on a Socket P motherboard with a 965 or 4 series chipset. For Socket B, Jasper Forest and Bloomfield/Westmere shares the same socket, but has the same issue that Sossaman has. The only way to get them to work is to use a motherboard that supports these special processors, although I believe Sossaman could work on Socket M with a custom-built interposer.

Most Socket P motherboards do not support mobile Core 2 Quad processors by default, only a few do and those tend to be in desktop replacement laptops. These motherboards also support mobile Core 2 Duo processors as the pin-out is similar, excluding pin D8, AA7, AA8, AC8, AE8 and D22's differences in function. To get a mobile Core 2 Quad to work on a Socket P motherboard that doesn't support it, you must modify the motherboard - https://thinkpad-forum.de/threads/core2-quad-mit-coreboot-libreboot-auf-t500-wahrsch-auch-t400-benutzen-beta.199129/

VRM: Generally, most Socket 478 motherboards that support Prescott do not support Willamette due to a VRM limitation, likely due to the VRM's inability to provide the correct core voltage that Willamette requires. There is no solution to this problem apart from buying a motherboard that supports Willamette out of the box, which isn't difficult as motherboards like the ASUS P4P800 Deluxe are not hard to find. Laptops are much worse as only a few had support for Willamette, such as the Toshiba Satellite 1905-S277.

If you have something that could improve, correct, or add on to this post, please post it here. People with older hardware could benefit from it.

[wren4777]

Thanks! This is a really good resource