Upgrade Your Pentium's Microcode

BugBBQ wrote to us regarding a a recent Byte column which talks about BIOS Update, a feature that Intel has built into their chips since the Pentium Pro. One of the interesting parts is that there's no checking to see if a code update is legit, according to the article.

Comments

How this works..

[molo]

The P6 processors have microcode that you can change at runtime. However, these changes DO NOT GET SAVED ACCROSS POWER CYCLES . This is used by Intel to fix some errata in the shipping microprocessor. The way it is implemented, since it is not written permanently, the system BIOS has to write microcode updates to the CPU at boot time, on every reboot. This enables Intel to make revisions take effect with simple BIOS updates that everyone is used to. This was very interesting for me, as I had no idea that BIOS updates held such weight with the P6 family of processors!

If you look at the PPro Processor Specification Update (the accompanying PDF), you will see that some of the erratum are marked as: "Workaround: It is possible for BIOS code to contain a workaround for this erratum." This indicates an erratum that can be fixed by microcode updates.

The advantage to having this is significant, in my opinion. You don't have to buy a new processor stepping to get erratum fixed. Granted, there will be plenty of erratum that can't be fixed with a microcode change, but this is at least a step in the right direction.

As was pointed out by another poster, Linux 2.4 has /dev/microcode support for P6 processors. What this allows you to do is update your microcode on boot. Why would you want to do this? Intel issues new microcode updates to the BIOS writers. If you get your hands on new microcode before there is a full flashable BIOS revision available, this will allow you to install the new microcode at bootup, removing one layer of your dependency on your BIOS writer.

Anyway, I think this shit is really cool, but not something I plan on using unless there is a serious errata found in my processor that can be fixed this way. It sounds like quite a bit of hastle for marginal benefit in most cases. However, its great that Linux provides us this option.

Anyone have any ideas about hacking microcode? I donno if Intel releases specs on it. Could be very interesting.

Re:Uh-huh.

[Chris Burke]

The purpose of it isn't to increase performance. The purpose is to work around buggy micro-ops by re-encoding the CISC instructions to use different ones (with an inevitable loss of performance). It's to prevent them from having to recall their chips in the event of some big bug. "Oh, don't worry, we'll just send you a microcode update."

At least, that was what was stated in the EE Times article I read, about 3 years ago. They (the article authors) were highly critical of the idea for secruity reasons, but Intel was swearing up and down that it would be strongly encrypted and all that rot. They were also acusing Intel of using the microcode as an excuse to be lazy. Heh.

Anyway, this news is so old it is virtually obscured by cobwebs and dust.

Cool!

[hey!]

Now I can talk to the midichlorians who live inside my CPU...

Re:Uh-huh.

[American AC in Paris]

I'd maintain that upgrading one's microcode is a fundamentally different task from upgrading one's TCP/IP stack, or most other tasks at higher abstraction levels.

As you step up abstraction levels, you begin to get into all sorts of possibilities for less than optimal performance, mainly because your code relise much more heavily on single-line commands that fire off larger blocks of less abstract code. The possibility for optimization comes in when coders can look at these layers of abstraction and find more efficient possibilities, either by selecting different procedure calls or by stepping down to the next lowest layer of abstraction (i.e. putting assembler code into a C program to dump graphics more quickly to the screen buffer.) Basically, the higher up the abstraction level you get, the more different coding paths you can take to get the same end result. Finding a more efficient one requires a bit of work, yes, but there are enough other possible routes that the programmer didn't follow that you can probably find one way around it, even if all it is is re-writing the higher level code in a lower level chunk to skip over a few cycles.

With microcode, though, there are no additional layers of abstraction between the code and the processor. Microcode is as close as you can get to the chip before you break out your oscilloscope and multiplexer. The only way you can improve microcode is by actually finding a faster/better way of sending the command through the chip; though this is mathematically less challenging than trying to optimize at higher levels of abstraction, it also means that the engineers that wrote the microcode in the first place had a lot fewer possibilities to consider than they would have had they been writing C code. You can't "drop down" to the next layer of abstraction with microcode, either, so that entire family of optimization tricks can't even be applied to microcode.

Finally, upgrading one's microcode works only within a very limited scope. You may find that Upgrade A does good things for your machine, because you run a particular mathematical operation over and over, but for your friend's machine, it actually degrades performance, because of a pipeline trick in Upgrade A that was designed specifically to speed your particular mathematical operation. A TCP/IP upgrade, on the other hand, relies on the lower abstraction layers to handle the finer points of chip tuning, making it's performance improvements much more likely to be universally applicable. (Note, too, that by stepping down to lower abstraction layers to improve performance, one runs the risk of creating greater usage-specific issues, much like in the example above.)

To successfully upgrade something like the TCP/IP stack, you need some pretty heavy understanding of the protocol, language, and current implementation to succeed in upgrading it. To improve the microcode, you need nothing short of a truly pedantic understanding of the Pentium architecture itself. There's a big leap in skill and opportunity between these two. If there are even a handful of non-Intel developers out there who feel comfortable enough tackling this problem, I'd still be surprised if they managed to yield a universally-applicable microcode patch for the Pentium. It would certainly be no small feat.

But again, I do ask that if somebody manages to do it, pretty please, let me know...

A bit more about P6 microcode patching

[Anonymous Coward]

1. Microcode viruses are highly improbable. The code is loaded by BIOS without checks, but the processor checks the code and won't use it unless it is valid. Further, the update is flushed out by every RESET.
2. There is no benefit to being able to patch microcode for performance, despite what this article states. There is only one decoder (out of three) on the P6 which will load the micro-ops from the patch area. So you get a third of your possible micro-op issue rate. About the only thing microops can do that you cant from macroops is 3 operand instructions (and a few more scratch registers, but those aren't handled by the shadow register table, so you'd have to be very careful).
3. update space is TINY, especially for the size of the microops themselves. There probably isn't enough space to implement a complicated algorithm even if someone wanted to. Most updates contain less than 10 microops per problem.
4. To do an update for a particular stepping would require the complete microcode listing for that stepping, because there is no jump table, just absolute offsets into the internal ROM. These are different by stepping, and of course family.
5. Reverse engineering microcode, aside from being a waste of time, isn't going to be particularly easy. Determining the decryption where the plaintext is just as incomprehensible is a complex task, and there is no observability except whether or not the patch got loaded.
6. This is not "secret", although hard to obtain now I suppose. The "P6 BIOS WRITERS GUIDE", which used to be available from an FTP site at Intel, had the complete mechanism for loading updates. Windows versions have some form of a microcode loader, to account for defunct bios vendors..

The update utility itself is here

[florin]

This is actually a very useful function. Suppose you have an older motherboard and you want to run a newer chip on it like a modern Celeron or Coppermine. For whatever reason, even the latest BIOS that your manufacturer has posted on their website does not support it. What can you do?

Well thanks to this update facility, you can add the relevant microcode updates to your BIOS yourself, and there's a little DOS utility from Intel that'll help you do it. Go to this web page and download at least the files pupdt513.zip and pep15.pdb (the other files may be of interest too). I'm linking directly to the download section as the rest of the site is in Cyrillic.

First a warning: never run checkup5 without the -u command line option or it will update your flash ROM without asking for confirmation! Typically one would start the program like this:
checkup5 -u -p pep15.pdb

Case in point: My very very old Abit BX6 rev 1, though recently provided with a fresh 21/02/00 BIOS, does not officially support Coppermine CPUs. It does have the proper voltage settings but Abit says: "BX6 Rev 1.00, 1.01, 1.02, etc. (BUT NOT BX6 Rev 2.0) do not support Coppermine CPUs due to the native design of power for the CPU core voltage probably not being sufficient. So to avoid instability, we advise that the afore mentioned boards do not support Coppermine CPUs".

I was aching for speed and Abit's advice wasn't very satisfying, so I put a PIII-700E in regardlessly and it worked fine even without the microcode support, but I wanted it anyway and so I ran an earlier version of the utility. This was the initial output:
------------------------------------------------ --------------------
Processor Update Utility for Intel(R) P6 Family Microprocessors
Version 5.01, 04/06/99
Copyright 1999-5, Intel Corporation.

Unannounced Intel processor detected (CPUID=x683)

Your system BIOS does not contain a microcode update for
this processor. Therefore, no microcode update was loaded.

This utility can load a microcode update (revision 10)
for your main processor.

The microcode update was successfully loaded.
You do not need to run this utility again, unless a new
processor is installed or a new version of the utility is used.
------------------------------------------------ --------------------

Now I get this:
------------------------------------------------ --------------------
Unannounced Intel processor detected (CPUID=x683)

Your processor contains a microcode update, revision 10.

The microcode update already loaded in your main processor is the
latest revision as of 04/06/99. No changes are needed.
Please make sure you have the latest database file.
No changes were made to the system.
------------------------------------------------ --------------------

Note how it says 04/06/99 because that's the release date of the program version I used (only supported up to Katmai), however the external pep15.pdb that I used has far more recent updates in it as this list shows:
------------------------------------------------ --------------------
Processor steppings (revisions) and microcode update revisions included in current base

Processor/Package/PKG Stepping/Microcode Update Rev

Pentium Pro Processor, PGA, 0x612/00, 0xC6
Pentium Pro Processor, PGA, 0x616/00, 0xC6
Pentium Pro Processor, PGA, 0x617/00, 0xC6
Pentium Pro Processor, PGA, 0x619/00, 0xD2
??????????????????????????????, PGA (?), 0x630/00, 0x13
??????????????????????????????, PGA (?), 0x632/00, 0x20
Pentium II Processor, SECC, 0x633/01, 0x34
Pentium II Processor, SECC, 0x634/01, 0x35
Pentium II Processor, SECC, 0x650/01, 0x40
Intel Celeron Processor, SEPP, 0x650/01, 0x40
Pentium II Processor (?), Mini-Cart (?), 0x650/02, 0x41
Pentium II Processor (?), MMC1/MMC2 (?), 0x650/08, 0x45
Pentium II Processor, SECC/SECC2, 0x651/01, 0x40
Intel Celeron Processor, SEPP, 0x651/01, 0x40
Pentium II Processor, SECC/SECC2, 0x652/01, 0x2A
Pentium II Processor (?), Mini-Cart (?), 0x652/02, 0x2C
Pentium II Xeon Processor, SECC, 0x652/04, 0x2B
Pentium II Processor (?), MMC1/MMC2 (?), 0x652/08, 0x2D
Pentium II Processor, SECC/SECC2, 0x653/01, 0x10
Pentium II Xeon Processor, SECC, 0x653/04, 0x0B
Intel Celeron Processor, SEPP, 0x660/01, 0x0A
Intel Celeron Processor, PPGA, 0x665/10, 0x03
Mobile Pentium II Processor, Mini-Cart, 0x66A/02, 0x0C
Mobile Pentium II Processor, MMC1/MMC2, 0x66A/08, 0x0D
Mobile Intel Celeron Processor, MMC1/MMC2, 0x66A/08, 0x0D
Mobile Pentium II Processor, Micro-PGA1, 0x66A/20, 0x0B
Mobile Intel Celeron Processor, Micro-PGA1 0x66A/20, 0x0B
Mobile Pentium II Processor, Micro-PGA1, 0x66D/20, 0x07
??????????????????????????????, SECC/SECC2 (?), 0x670/01, 0x06
??????????????????????????????, SECC/SECC2 (?), 0x671/01, 0x03
Pentium III Processor, SECC/SECC2, 0x672/01, 0x10
Pentium III Xeon Processor, SECC, 0x672/04, 0x38
Pentium III Processor, SECC/SECC2, 0x673/01, 0x0E
Pentium III Xeon Processor, SECC, 0x673/04,0x2E
??????????????????????????????, SECC/SECC2 (?), 0x680/01, 0x14
Pentium III Processor, SECC/SECC2, 0x681/01, 0x0D
Pentium III Xeon Processor, SECC, 0x681/04, 0x10
Mobile Pentium III Processor, MMC2, 0x681/08, 0x0F
Pentium III Processor, FC-PGA, 0x681/10, 0x11
Mobile Pentium III Processor, Micro-PGA2, 0x681/20, 0x0E
Pentium III Processor, SECC2, 0x683/01, 0x0C
Pentium III Xeon Processor, SECC, 0x683/04, 0x0F
Mobile Pentium III Processor, MMC2, 0x683/08, 0x08
Pentium III Processor, FC-PGA, 0x683/10, 0x10
Mobile Pentium III Processor, Micro-PGA2, 0x683/20, 0x07
Pentium III Processor, SECC2, 0x686/01, 0x07
Pentium III Processor, FC-PGA, 0x686/10, 0x08
Pentium II OverDrive Processor, PGA, 0x1632/00, 0x02
------------------------------------------------ --------------------

Lastly, from the Intel documentation:
------------------------------------------------ --------------------
System BIOS code on motherboards based on P6 family microprocessors contains microcode updates that are specific to each silicon stepping (revision) of the processor. Integrators must ensure the microcode update matches the processor stepping used. When the BIOS does not contain a microcode update that matches the processor stepping, integrators must install the latest microcode update in the BIOS before shipping the system. Historically, systems based on P6 family microprocessors have been updated by upgrading the entire system BIOS with a new revision of the system BIOS that contains the correct microcode update for the processor. However, such a process may be time consuming when assembling and configuring many systems.

Intel has worked closely with BIOS developers to implement a processor update Applications Programming Interface (API), which allows just the microcode update within the system BIOS to be
installed as needed. Motherboards that contain a system BIOS with the Intel-defined processor update API can be quickly and easily updated, if required, without need for a complete system BIOS upgrade.
------------------------------------------------ --------------------

Have fun, try not to break anything.

Uh-huh.

[American AC in Paris]

Upgrade Your Pentium's Microcode, indeed.

Quick show of hands here: who here has the skills, time and patience to analyze the performance of your computer and actually find a way to improve the microcode performance on their computer? Hell, that's one step removed from digging out your soldering iron and microsocpe to 'clean up' some of those slow pathways on your chip.*

Even with the complexity of Pentium chips, the odds of being able to successfully perform an "upgrade" of your Pentium's microcode is slim to none. Microcode is designed to be hella-fast, by people who do happen to know what they're doing and have access to every technical spec they could want on the chip.

Despite your potentially vast knowledge of microcode, the complexity of the Pentium chip is sure to present some major headaches, even if you have worked out the theory of what you need to do to improve the code.

Unless you have a very specific set of tasks you run on your computer (and then know exactly what changes you need to make to further improve on the existing microcode,) the odds of your writing a microcode upgrade that actually improves overall system performance is pretty low.

Having said that, do send me a copy if you manage to do it...

* BTW, this doesn't work. Learned that one the hard way... *grin*