Slashdot Mirror
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.
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!
/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.
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
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.
Using your sig line to advertise for friends is lame.
I didn't even read the entire byte article with exception to the first page. It read like one of those "Intel-Doesn't-Want-You-To-Know-" articles. Scuze me while I yawn.
This is an excerpt from Tom's Hardware
What is 'micro code update'? Well, all of Intel's 6th-generation processors have a little area that can store some software ('micro code') to deal with processor bugs right inside the CPU. Usually the motherboard BIOS loads this software into the processor right after boot-up. Each time Intel finds a new bug they try to create a new little software patch that is called 'micro code update'. These 'micro code updates' make the processor more reliable, but they always cost a bit of performance, because they basically turn off some internal features.
Let's go find a conspiracy somewhere else.
BOSTON SUCKS!
Quick show of hands here: who has the skills, time, and patience to analyze the performance of your TCP/IP stack and write, debug, and test code to improve it?
Now, how many have the time to download and install performance enhancing updates if a small number of skilled people make them?
Oh, I see, we don't all need to do all the work all the time.
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.
The enemies of Democracy are
Now I can talk to the midichlorians who live inside my CPU...
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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...
Obliteracy: Words with explosions
Seems like the Byte editor never tried an 2.3 or 2.4 kernel. /dev/cpu/microcode option is there for a long time now.
The
--
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
This is very frustrating for those of us who need to write deterministic-performance (i.e. real-time) code, since it makes it hard to formally derive any reasonable guaranteed upper bounds on the execution time of anything.
The microcode update thing discussed in the Byte article is a particularly glaring instance of this lack of documentation. Not too long ago, I was working on a special-purpose real-time OS, and had to look through the whole PII family documentation to make sure the OS was "doing the right thing" wrt all the registers on the PII. There is ONE mention of the "microcode update signature register" in the entire 3-volume processor manual, and the mention gives no clue as to what the register's function is, when it can be set (not in user mode, one hopes!), or how it interacts with anything else.
I emailed Intel's tech support about this, and the guy responding to the email had no idea what I was talking about. When I pointed him to the page number in the docs, he went and checked with the developers, and returned with a vague answer that gave me essentially the same information printed in the Byte article. In the end we figured out that as long as the OS left it alone, we didn't need to worry; but that was a lot of time wasted because of Intel's opacity.
In fairness to Intel, other processor docs aren't much better in the determinism/precision department. However, Intel's architecture is peculiarly byzantine, since it consists of layers and layers of backward compatibility kludges grafted clumsily on top of one another, so Intel ought to feel a special responsibility to document their rat's nest of a processor properly. On the other hand, maybe they're too embarrassed to do so.
Nick Weininger
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..
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.
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*
Obliteracy: Words with explosions
The article says: In technical terms, "BIOS Update" is a hidden (i.e. barely documented at all outside of Intel) feature.... I work for a company that sells Intel products (a small reseller, $2M a year), and we've known about the feature since the Pentium II's introduction. At trainings for "system integrators", Intel has waged a very aggressive campaign of making sure that, along with proper BIOS updates, we install processor "step updates".
Based on the low-level nature of microcode, I do not believe that anyone w/o intimate knowledge of the design of the processor hardware itself would be able to write workable microcode updates. Even if someone did, I also believe that it would be EXTREMELY difficult to get a "trojan horse" that could do anything useful. The microcode is _so_ low level, and accomplishing any kind of useful trickery would need to be done at a very high level.
No doubt, there'll be a lot of posts about how "sinister" this feature is-- especially given that Intel doesn't document the feature-- even though it's been publicly documented for years. Hit the Intel Developer Site and search for "Microcode update". I get 21 hits on that search, most of which are relevant. Intel doesn't give the stepping update utility out to the public, but if you update the BIOS on an Intel motherboard, you generally get some stepping updates loaded as well. Not sure about non-Intel boards.