This article is intended for advanced users who clearly realize all consequences of their actions. The material is given "As Is", and the author does not take any responsibility for any moral or material damage that can be caused after reading this article. The worst problem that can occur will be a necessity to update the flash-BIOS on the external programmer.

Having read the article "CPU errata correction", I followed the instructions loading a 2 KBytes block of program errata correction of the CPU's microcore in the DMI field. But my half-a-year-later attempt to get a new base of errata correction both from the processor manufacturer (Intel), and from the seller failed (PEP15.PDB, in the new versions of the utility the file is renamed as PEP.DAT; hereinafter "PEP15.PDB" is replaced with "PEP.DAT", since this article comes with a new version of the utility from Intel which works at default exactly with the PEP.DAT): the seller ("IQ Computers" company) said they had no access to the Intel base (it's strange and means that processors were selling illegally), and the Intel's technical support service said the following:

===

From: Intel Customer Support <support@mailbox.cps.intel.com>
Subject: RE: Latest version of P6+ ERRATA corrections base
Date: 10 06 1999. 0:52

01:44 PM
6/9/99

Hello Sergey,
The file is available here:
http://channel.intel.com /business/ibp/private/integration/downloads/p6bu.htm

The site is password protected. Your Intel(R) rep should be able to assist
you if you do not have the password.
--------
Joseph K
*All brands and trademarks are the property of their respective owners

===

When analyzing different ways and methods of receiving this base through unofficial channels, my eye was caught by the CPUCODE blocks in the Award-BIOS'es of different mainboard manufacturers. A more extensive analyses of the format of these blocks revealed that it either completely coincides with the PEP.DAT format (like in BIOS'es from A-Bit; the file name is CPUCODE.BIN), or the blocks from PEP.DAT are preceded by a header of an unknown (for me) format (like in BIOS'es from ASUS; the file name is CPUCODE.EXE, though it doesn't relate to executables of *.EXE format). Each 2-KB block (2048 bytes) of the PEP.DAT file (or CPUCODE.BIN) contains the header of the following format:

A word consists of 2 bytes, a double word - of 4 bytes, the information is recorded in a file in the reverse order, i.e. a low byte comes first followed by the high byte. The figure 1 in the file is recorded in the form of a double word as 0x01000000.

So, I marked these 2-KB blocks out of the original PEP.DAT base of January 1999 and recorded them in separate files under aaaabbcc.BIN names, where aaaa is the CPUID from the header (+C), bb is the PKG of the processor from the header (+18), cc is a version of the given CPUID from the header (+4). The date for files was also taken from the block headers (+8). After that I took the CPUCODE.EXE file ("CBROM file_name_with_firmware /CPUCODE EXTRACT", "CPUCODE.EXE" is without inverted commas) from the latest BIOS of ASUS (v1010 of 16.07.99 for P2B mainboards), received the CPUCODE.BIN by cutting off the header and conducted the same procedure with it in another directory. Then I added two more blocks found in the DMI field of the firmware into the same directory (for the ASUS -- 0x37000 and 0x37800 offsets relatively to the beginning of the file with the firmware). And then I combined these two directories in the third one, leaving only new files among those with the same "aaaabb" part (with the higher "cc" number).

2-KB *.BIN files left in the third directory were sorted according to their names and combined in one common base by a standard "COPY" instruction: "COPY /b xxx1+xxx2+...xxxN PEP.DAT" (without inverted commas, of course). This base should be used instead of the original base of January 1999. It was tested on the A-Bit i440BX-6 Rev1.0 mainboard with the Celeron-333 processor (CPUID 0x0660).

Note that the blocks correcting the microcode with the PEP.DAT base are recorded in the DMI field of the flash memory only for processors installed in the mainboard at the time of starting-up of the utility. After replacement of the processor with the one which has another CPUID the utility is to be started again. Besides, it should be restarted after clearing of the DMI (start of the AWDFLASH.EXE with /CD switch). But for 2-Mbit (256-KB) BIOS'es there is a way to record the whole base directly into the firmware file. In this case you have to rename the PEP.DAT file as CPUCODE.BIN and implement the following instruction: "CBROM file_name_with_firmware /CPUCODE CPUCODE.BIN", without inverted commas. Unfortunately, this method doesn't suit 1-Mbit (128-KB) BIOS'es, since the whole base don't suit this BIOS. You can't use this method for Award-BIOS'es from ASUS either, since the file should have a name not CPUCODE.BIN, but CPUCODE.EXE, and the base should be preceded with a header, the format of which is still unknown for me. The operability of this method as far as the original CPUCODE replacement is concerned is tested on the firmware file from the A-Bit i440BX-6 Rev2.0 mainboard. You can check the name of the file in your BIOS with the instruction "CBROM file_name_with_firmware /D".

Below you can see a table of processors supported (the table is to replace the analog one in the documentation for the microcode correction utility from Intel), sorted according to the Stepping/PKG.

Table 1.

Processor steppings (revisions) and microcode update revisions includes in current base

The "|" sign marks corrections appeared since my previous version (31/10/00). The changes are taken from the UPDATE.SYS of the OS Win-2000 SP1 (25/10/99), from the BIOS for the ASUS P3B-F 1008 Beta 01. Besides, Coppermine/D0 correction blocks from BIOS for the 815EP Pro mainboard of the 3.03 version from MSI were added. Plus, two mobile processors were added from BIOS'es of notebooks from the ASUS site. The notes of interrogation put instead of names mark those models which are absent in the Intel official bases, but which (core corrections) are present in BIOS'es of some mainboards and/or in the UPDATE.SYS modules of Win-9x/NT operating systems. The sign "(?)" marks parameters obtained empirically from hexadecimal numbers of the Stepping/PKG header of the corresponding block, since the help coming with the Intel v5.14 base lacks for references to these processors. The "#" sign marks models which are absent both in the Intel official bases and in the BIOS'es I studied, but the correction blocks for which are present in the UPDATE.SYS modules of Win-98SE and/or Win-2000 (Win-NT5) SP1 operating systems.

The article comes with the following files:

checkup5.zip (37.61 KBytes) -- Processor Update Utility for Intel(R) P6 Family Microprocessors v5.14 July 26, 2000. Copyright 1995-2000, Intel Corporation. (Only executables, without a base).

pep.zip (75.27 KBytes) -- based on the 5.14 base of 26 July 2000 (instead of the old archive pep15.zip). Put the PEP15.DAT in the same directory with the CHECKUP5.EXE

content.zip (141.64 KBytes) -- 2-KB blocks included in this base. You can use them for forming a new base according to an algorithm described above, when you get an access to a BIOS with a newer version of the CPUCODE.

modbin.zip (59.68 Kb) -- Award's utility for correction of a series of settings in the Award-BIOS'es up to the 4.50PG version (for 6.00 and higher versions it is inapplicable). The 4.50.77 version of 1999.

cbrom.zip (34.59 Kb) -- a new version of the CBROM utility sent by the A-Bit technical support service. The 2.07 version of 2000. It displays versions of errata correction blocks selecting them out of the DMI field and from the CPUCODE.BIN firmware file (but not the ASUS's CPUCODE.EXE). It operates on new versions of BIOS'es from A-Bit (BE6-II mainboard).

By the way, new A-Bit mainboards use a BIOS format incompatible with the old one, and old utilities from AWARD don't work with it (MODBIN, CBROM are not satisfied with the checksum). For these BIOS'es a new version of the AWDFLASH -- 7.52C - was released. That is why for working with these BIOS'es you are to use new versions of MODBIN and CBROM (you have to look for the MODBIN yourselves, and the CBROM's new version comes with this article).

I will appreciate if you send me a newer version of the MODBIN utility, but, please, write me by e-mail first, since I might already have this or a newer version.

And now the MODBIN utility can work only with those 2-Mbit (256-KB) BIOS'es where the BIOS (the "original.tmp" file or however it is renamed by mainboard developers) starts with the 0x20000 offset relatively to the beginning of the firmware dump (the header of the LHA-archive starts with this offset). If you want, you can make experiments with the BIOS BEH_QJ.BIN of the A-Bit BE6-II mainboard or with a newer BEH_QY.BIN according to the following algorithm: take all additional parts from the BIOS with the CBROM into separate files, delete all parts except the 0 one from the BIOS with the same CBROM (the zero part can't be deleted with this utility), after that remove the original BIOS (the 0 part) with the offset 0x0 to the offset 0x20000 from the beginning of the firmware file with the help of the HIEW or any similar utility, then restore all previously deleted components in this file with the CBROM (in the same order) and try to record what you have obtained into the flash of the BE6-II board. The MODBIN, we are giving, can see this firmware file, but I can't guarantee that new BIOS'es from A-Bit haven't received something new. Any way, all experiments described in this paragraph are made by you by your own risk, but if you still decided to conduct them, please, share your results with us...

So far I've seen only one mainboard, on which the start-up of the DMI update procedure (exactly the update and not check-out of this necessity) causes destruction of the BIOS -- this is the P3B-F. It should be noted that the DMI format in the flash of this board is not standard, and normal AWARD DMI correction procedures either do not see this DMI or refuse to make corrections. And in the Intel utility used for recording the ERRATA correction block into the DMI, this check-out is just absent, which causes BIOS's damage.

You can find the list of discovered errata of the Intel processors with marks whether they are corrected, will be corrected or are not planned to be, following the references on the Intel's official site at www.intel.com

Write a comment below. No registration needed!