How to update CPU microcode in an Award or Phoenix-Award BIOS with CBROM

Most Gigabyte LGA 775 boards, and plenty of boards from other makers, run Award firmware. Adding a microcode patch to one of those images is a different job from the AMI method: there is no friendly patch table, just a module tool called CBROM and a block of microcode you rebuild yourself. This guide walks through it for the usual case, a desktop board that needs the patch for a modded LGA 771 Xeon. Which patch your chip needs, and why the board lacks it, is covered in the LGA 771 Xeon microcode explainer.

Award, Phoenix-Award and Phoenix are not the same thing

Phoenix Technologies bought Award Software in 1998 and kept the Award code base going for desktop boards. That is why so many POST screens of the Core 2 years say Phoenix AwardBIOS: underneath it is still Award, and CBROM handles it.

Phoenix's own product lines are another matter. PhoenixBIOS, TrustedCore, SecureCore and Phoenix's later UEFI firmware store modules in their own formats, and CBROM does not read them. Community guides point to other tools for those: Phoenix BIOS Editor for older Phoenix legacy images, and UEFITool for anything UEFI. If your board shows a PhoenixBIOS or SecureCore banner rather than an Award one, this guide is not for your image.

Two more cases to set aside early. An AMI image (American Megatrends on the POST screen) goes to the MMTool guide. And Dell machines: the Win-Raid guide this procedure follows warns that Dell has special BIOSes that usually need a completely different method.

How CBROM sees microcode

An Award image is a set of modules: the main BIOS code plus extras such as logos, option ROMs and, on Intel chipset boards, a memory initialization module that CBROM lists as MINIT. CBROM can list those modules, add them and remove them.

Microcode usually lives in an uncompressed block that CBROM lists as NCPUCODE. It is simply the patches laid end to end. You do not edit it entry by entry; you build a new file with every patch you want and hand it to CBROM, which replaces the block. Some images can also carry microcode as a compressed module.

These are the only switches this guide uses. Each comes from the Win-Raid forum's guide to updating microcode on non-UEFI Award and Phoenix BIOSes (first posted in 2017), which shows them in full command lines:

The guide notes one hard limit: this method works on an existing NCPUCODE block. If your BIOS has none, it cannot create one for you.

Before you start

• The newest official BIOS for your exact board and revision. Gigabyte names its files after the board with an extension for the version; the GA-EP45-DS5 manual's example is EP45DS5.F1.
• CBROM. Like MMTool, it is a BIOS vendor's tool that circulates on enthusiast forums rather than being published for end users. We do not link it. Version matters (see the procedure).
• MC Extractor, open source, to list and extract the patches in an image.
• The patch files for your Xeon, one patch per file.
• A Windows PC with a command prompt opened in your working folder. The command prompt guide shows the quick ways to open one there.
• A FAT-formatted USB stick, or a floppy on boards that still want one, for flashing and backups.

The parts listed come from specifications and published reviews, not from our own testing. A programmer kit is a recovery tool; with luck it stays in its bag.

The procedure

1. Back up what is on the chip

On Gigabyte boards, open Q-Flash (the End key during POST, or F8 inside BIOS Setup, per the GA-EP45-DS5 manual) and use its option to save the main BIOS to a drive. The drive must be FAT32, FAT16 or FAT12. Classic AWDFLASH versions for DOS also ask whether to save the current BIOS before they program a new one. Use whichever your board offers, then copy the file to a second place.

Write down the file size. Q-Flash shows the flash chip type and size at the top of its screen; the manual's example is an 8 Mbit chip, which holds a 1 MB image. The backup, the official file and your edited file must all match it.

2. Start from the newest official image

Flash the newest official BIOS unmodified first if the board runs an older one, and check that it boots with the CPU you have. Then work on a copy of that same file. Editing an old release only means doing the job twice.

3. List the modules

cbrom155 MYBOARD.F9 /d

MYBOARD.F9 stands for your file name. Look for NCPUCODE in the listing. If it is not there, stop here: see the limit noted above.

4. See which patches the image already holds

Drag the BIOS file onto MC Extractor. It lists every patch with its CPUID, platform mask, revision and date, and writes each one out as a separate file. Keep that folder; the patches for the CPU in the board now come from it.

Write the list down and sort it into keep and drop:

• Keep every patch for the CPU in the board and for any chip you might fall back to.
• Drop only patches you can identify, by checking the CPUID against Intel's specification updates or the CPUID guide. Do not drop a patch just because you do not recognize it.

5. Collect the Xeon patches

For the 45 nm Xeons the pairs from Intel's tables are 10676 with mask 40 (Xeon 5400, C0), 10676 with mask 04 (Xeon 5200, C0) and 1067A with mask 44 (either family at E0). Take them from Intel's Linux microcode repository (files 06-17-06 and 06-17-0a, each holding several patches that MC Extractor splits apart) or from a newer official BIOS for a board that supports the chip. The Win-Raid guide's own copy /b example uses exactly these three.

Worked example, for an X5460 E0 (sSpec SLBBA, see the X5460 page) going into a board that already holds patches for a Core 2 Quad:

The block grows by 8 KB for the E0 patch alone, or 16 KB for all three.

6. Build the combined file

Join the patches into one file with copy /b, the binary mode of the Windows copy command. List the patches you keep first, then the new ones:

copy /b keep1.bin + keep2.bin + keep3.bin + x1067a_44.bin + x10676_40.bin + x10676_04.bin NCPUCODE.BIN
attrib +R NCPUCODE.BIN

The Win-Raid guide marks the combined file read-only, as in the second line, before handing it to CBROM. Check the size of NCPUCODE.BIN: it should equal the sizes of the parts added together.

7. Replace the block

cbrom155 MYBOARD.F9 /nc_cpucode NCPUCODE.BIN

On the CBROM version: the guide uses 1.55 on Gigabyte boards and says later versions may change, relocate or alter the checksum of the modules that come before MINIT, which can leave the image invalid. For other makers' boards the guide names 1.98 as an alternative, with the caveat that its author did not test newer versions on them. If a forum thread for your exact board names a version that worked, use that one.

8. Check the result before it goes anywhere near the chip

1. Run /d again. The guide uses this listing to check that all your microcode entries appear at the end of it.
2. Open the new file in MC Extractor. You want every kept patch, every new patch, and no warnings. If MC Extractor reports a patch as packed or badly extracted, do not flash.
3. Compare sizes. The image must be exactly as large as your backup and the chip.

One quirk is worth knowing. The guide reports that when the new block is smaller than the old one, CBROM leaves the old bytes behind instead of filling the space with FF, and MC Extractor then shows duplicate or broken patches. Its fix is to fill that leftover range with FF in a hex editor such as HxD and run the /nc_cpucode step again.

When CBROM runs out of room

The image is a fixed size and the space for modules is shared. If CBROM says there is not enough space:

1. Go back to Step 4 and drop more patches you can identify as unneeded, then rebuild the file.
2. As a fallback, the guide moves one patch out of NCPUCODE and adds it as a compressed module with /cpucode. Its author notes that such a patch may not show up in CBROM's listing or in MC Extractor, yet still works. Treat that as a forum report rather than a documented feature, and verify on the bench (the Linux check below) before you rely on it.

Flashing an Award board

Use the tool your board maker documents:

• Q-Flash (Gigabyte). Built into the BIOS. Gigabyte's manual has it read the file from a floppy, a USB stick or a hard drive formatted FAT32, FAT16 or FAT12, then asks for confirmation before it writes. Our pick on Gigabyte boards, since nothing else is running while it works. The same manual recommends loading optimized defaults afterwards.
• AWDFLASH. Award's DOS flasher, run from a boot stick. Its switches differ between versions, so follow the instructions that come with your board's BIOS package rather than a command copied from a forum.
• @BIOS (Gigabyte, Windows). It exists and Gigabyte supports it, but a Windows crash mid-write is one more way to lose the chip.

Whatever the tool, do not touch the machine until it reports that it has finished. After the flash, clear the CMOS, load defaults and boot once with your old CPU if you can. Then fit the Xeon.

To check that the BIOS loaded the patch, boot a Linux live stick with the kernel parameter dis_ucode_ldr, which stops the operating system from loading microcode itself, and read the revision:

grep -m1 microcode /proc/cpuinfo

The E0 patch from Intel's repository reports 0xa0b. If the board still misbehaves, page 5 of the LGA 771 to 775 guide goes through the symptoms in order.

Recovery: DualBIOS and programmers

Many Gigabyte boards of this era have DualBIOS. The GA-EP45-DS5 manual describes it as a main BIOS plus a backup BIOS on a second chip: if the main BIOS is corrupted, the backup takes over at the next boot and copies itself to the main chip. The same page says users cannot update the backup BIOS manually, so it stays a factory copy while you experiment on the main one. That makes these boards a comparatively forgiving place to learn, but check your own board's manual, since not every Gigabyte model has the second chip.

Without DualBIOS, the fallback is a programmer. Many boards of this era use an 8-pin SPI flash chip, and a CH341A with a SOIC8 clip can write your backup straight back. The walkthrough in reading a BIOS chip with a CH341A programmer covers the clip, the voltage check and the read-verify habit. Boards with a square PLCC chip need a different programmer.

Quick answers

Can I paste patches in with a hex editor instead?

The Win-Raid thread describes a hex-editor method as an alternative, but CBROM also takes care of checksums and module references. A hand edit that gets one of those wrong produces an image that looks fine and does not boot. Use CBROM unless you know exactly what you are doing.

Do I need the 65 nm patches too?

Only if you plan to run a 65 nm Xeon such as an E5345 or a 5160. Those have their own CPUIDs (6F6, 6F7 and 6FB) and patches; the explainer lists them. Adding patches you will never use just eats space.

Will the next official BIOS update keep my patch?

No. A new official image replaces the whole chip, NCPUCODE included. Keep your patch files and a note of the keep list from Step 4, and repeat Steps 3 to 8 on the new file before you flash it.