Actually, the original method, equipment and microcodes can be found (directly the AMI instruction), and in most cases the use of this method does not pose any problems and does not have pitfalls, but in my practice I regularly encountered this problem:
Those. there was a banal shortage free space inside the image. When you modify the BIOS for yourself for a specific processor, you can ignore this, because You can always load just one microcode specifically for your processor, or delete some old microcode to free up space, but when you modify it with a stream, you need to look for another compromise solution.
As a compromise, I chose the following solution - we take the latest microcode versions for all processors of the CORE generation in all constructs (Celeron E, Pentium E, Core 2 Duo, Core 2 Quad, Xeon * 3xxx / * 5xxx) and replace them with everything that came before ... The set of microcodes turned out as follows:
The volume of this set is only 76 kilobytes. This file was obtained by combining these files:
cpu00010676_plat00000001_ver0000060f_date20100929.bin
cpu00010676_plat00000004_ver0000060f_date20100929.bin
cpu00010676_plat00000010_ver0000060f_date20100929.bin
cpu00010676_plat00000040_ver0000060f_date20100929.bin
cpu00010677_plat00000010_ver0000070a_date20100929.bin
cpu0001067a_plat00000011_ver00000a0b_date20100928.bin
cpu0001067a_plat00000044_ver00000a0b_date20100928.bin
cpu000006f2_plat00000001_ver0000005d_date20101002.bin
cpu000006f6_plat00000001_ver000000d0_date20100930.bin
cpu000006f6_plat00000004_ver000000d2_date20101001.bin
cpu000006f7_plat00000010_ver0000006a_date20101002.bin
cpu000006f7_plat00000040_ver0000006b_date20101002.bin
cpu000006fb_plat00000001_ver000000ba_date20101003.bin
cpu000006fb_plat00000004_ver000000bc_date20101003.bin
cpu000006fb_plat00000010_ver000000ba_date20101003.bin
cpu000006fb_plat00000040_ver000000bc_date20101003.bin
cpu000006fd_plat00000001_ver000000a4_date20101002.bin
The modification procedure itself has also changed slightly and has become, if not simpler, then faster:
Step 1- open the BIOS image in the MMTool program: 
Step 2- to check, go to the last tab (CPU PATCH) and see the number of microcodes. Here, for example, there are 31 of them: 
Step 3- go to the Replace tab and look for the item "P6 Micro Code" on it: 
Step 4- by selecting the "P6 Micro Code" item, press the Ikschtsyu button, select the ncpucode.bin file described above and replace it with the Replace button: 
Step 5- to check, go to the last tab (CPU PATCH) and see the number of microcodes. After the replacement of microcodes, there are 17 left, the latest version: 
There is no fundamental difference with the modification order described on delidded.com. In most cases, the output is of course not the same, but the processor receives the required microcode. Of the subjective positive aspects, I would like to draw your attention only to the fact that the microcodes are guaranteed to be updated for all current processors, be they "civil" or "server" ones, and there is practically no risk of receiving a message about a lack of space. Although, in my practice, there was not enough space even for such a set of microcodes a couple of times, it was with the BIOS for the ECS P4M900T-M and ECS P4M900T-M2 boards, which are generally compatible with the Xeon E5450.
By tradition, I publish a link to the archive with tools - (zip, 234KB). The archive contains executable file MMTOL.exe(version 3.22 BKMOD), microcode file for all 45 / 65nm processors of the core / xeon generation ncpucode.bin, as well as two files 45nm.bin and 65nm.bin with microcodes only on 45nm processors and only on 65nm. The use of these files can be useful in cases where it is necessary to free up additional space in the BIOS, for example, for new firmware of some controller, network, disk, etc.
! NB: Neither ncpucode.bin file nor 45nm.bin / 65nm.bin files support Pentium 4, Celeron (without letter indices), Pentium D, Celeron D and Xeon W processors (Xeon 5080 for example). These are the NetBrust generation processors.
Since the beginning of January, it has been difficult to miss the news regarding Specter and Meltdown hardware vulnerabilities - the topic turned out to be so serious and pervasive. Although manufacturers have known about these problems since last summer, most seem to have begun to react only after the details were released by specialists. google teams Project Zero.
For example, Intel back in January among other patches released microcode updates against Specter for its Broadwell, Haswell, Skylake, Kaby Lake and Coffee Lake processors. But almost immediately it turned out that they lead to failures and. Intel initially stated that the problem only affected Broadwell and Haswell chips, but later acknowledged the existence of glitches on computers with Skylake, Kaby Lake and Coffee Lake processors and partners and users to refrain from installing patches for now. Finally, in early February, a revised microcode version, but only for mobile and desktop consumer Skylake chips.
Now, after a month of intensive tests and patches by Intel and its partners, the time has come for other more or less relevant processors: microcode updates have been released for chips based on Kaby Lake and Coffee Lake architectures, as well as Skylake-based platforms unaffected by the previous update. We are talking about 6th, 7th and 8th generation processors Intel Core i, as well as the latest Core X, Xeon Scalable and Xeon D families.
The new version of the microcode will be available in most cases through the release by OEMs of new firmware for motherboards and laptops. Intel continues to urge people to constantly update their systems to current versions, and also published a document in which it described the status of similar microcode fixes for its other products, including earlier chips, starting with 45nm Core 2. For some of these chips, patches are only planned, for others - are in the state early testing, for the third - they already exist in the form of a beta version. Generally, the older the architecture, the later it will receive Specter-protected firmware. However, microcode updates for the more or less current Sandy Bridge, Ivy Bridge, Haswell and Broadwell architectures are already in beta testing. Also, a number of Atom chips and even Xeon Phi accelerators have already received patches.
Intel recalled that there are other methods of fighting against the exposed vulnerabilities of the branch prediction unit in modern processors. For example, Retpoline, developed by Google against Specter CVE-2017-5715 (branch target injection). For those interested in more information about Retpoline and how it works, the company has published a special technical report.
Released Intel updates microcode against Specter in the coming days and weeks will begin to appear in the form of fresh firmware BIOS for various motherboards. I wonder if they will have an additional effect on the degradation of the performance of end systems?
I represent the donor BioStar A740G M2L + (AMD 740G / SB710) and the recipient BioStar A740G M2 + (AMD 740G / SB700). The motherboard with the letter "L" is more recent and officially supports AM3 processors, unlike the other, which is limited only by support for AM2 + processors. Begging for comparative analysis BIOS them.
From office. we load the site only Last update BIOS firmware for each of these motherboards:
- for A740G M2 + latest beta A74GM916.BSS for September 2009
- for A740G M2L + - file 74GCU511.BSS- for May 2010
Next, we arm ourselves with the MMTOOL utility (I used versions 3.22, 3.23 and 3.26 - I did not find any differences in work)... To work with MMTOOL, the BIOS firmware file extensions must be renamed to * .rom.
Now we launch two MMTOOL and load the firmware files from two mat into them. boards. Pay attention to the different sizes in the "Source size" column (and of course in the "Size in Rom" too) of the 11 "P6 Micro Code" module in each of the firmwares.
Go to the CPU PATCH section for a detailed comparison:
Donor file 74GCU511.rom - cpu_list contains 14 lines with CPURev.ID support + 1 empty (Fig. 1).
The beta version of the recipient A74GM916.rom - cpu_list contains 13 lines with CPURev.ID support + 1 empty (Fig. 2).
After analyzing the lists of these two BIOS, it becomes obvious that for the newer motherboard, the developers used more recent patches for AMD processors, where the microcode of two lines with CPURev.ID 1043 and 1062 is corrected (dated 2009/07/31) and one line with CPURev.ID 10A0 is added (dated 2010/02/17).
Method # 1 - modifying distinctive strings.
These three distinctive lines are extracted from the donor 74GCU511.rom - the actions "Extract a Patch Data" + "Apply" + 1 last empty line and saved to separate files.Previously, in the CPU PATCH section of the recipient file A74GM916.rom, two lines with numbers CPURev.ID 1043 and 1062 (whose microcode is older than we will insert further) and the last empty line - the actions "Delete a Patch Data" + "Apply" ( fig. 3).
After that, a newer microcode is inserted one by one from four previously received patch files for CPURev.ID 1043, 1062, 10A0 and an empty line (Fig. 4).
Pay attention to the sizes ("Source size" and "Size in Rom") of module 11 "P6 Micro Code" before and after applying these changes in the recipient file.
After application, these dimensions in the recipient (Fig. 6) will become identical to the dimensions of the same module in the donor file 74GCU511.rom (Fig. 5).
It is worth noting that it is easy to understand how the module size is formed (each line in the CPU PATCH section takes 2048 bytes).
It is better to save changes under a new file name.
Next, this file is checked so that MMTOOL opens again without errors.
Method # 2 - modification by replacing the entire module.
Actually, it is he who is described on the Internet (for example, partially).In MMTOOL we load the donor file 74GCU511.rom, go to the “Extract” tab and look for the line “P6 Micro Code”. Then we select it, in the “module file” field we give it the name ncpucode.bin and execute the Extract module “in uncompressed form”.
Now we load the recipient file A74GM916.rom into MMTOOL, go to the “Replace” tab and look for the line “P6 Micro Code” again. Select it, wait for Browse and select our donor module ncpucode.bin. Click Replase and then agree to replace this module.
We again pay attention to the sizes ("Source size" and "Size in Rom") of module 11 "P6 Micro Code" before and after replacing this module in the recipient file.
After application, these dimensions in the recipient (Fig. 7) will become identical to the dimensions of the same module in the donor file 74GCU511.rom (Fig. 5).
If we compare the results of both methods (Fig. 6 and Fig. 7), then there is a noticeable difference of 10 bytes in the RomLoc address of the “User Defined or Reserved” module following the updated “P6 Micro Code” module - perhaps these are the peculiarities of MMTOOL operation ...
Conclusion and afterword.
Thus, from different BIOS firmwares of various mat. boards on the AM2 + socket (and even AM3 for comparison), you can find the latest microcodes for each type of CPURev.ID, both in Award and AMI BIOSes, and then combine them into a single ncpucode.bin.As a result, it turned out for me with a size of 32768 bytes from 16 lines (microcodes) with the most recent dates from among the studied firmwares of various BIOS: with 15 different types processor revisions for the AM2 + socket (040A, 0413, 0414, 041B, 0433, 0680, 0C1B, 1000, 1020, 1022, 1040, 1041, 1043, 1062, 10A0) and the 16th line for RevID 0000 (apparently some universal microcode for revisions of processors not described in other lines - IMHO, for example, future ones).
When combining your own ncpucode.bin by importing the necessary patches (microcodes) for each required revision of processors, you can use absolutely any AMI BIOS firmware with the "P6 Micro Code" module as a laboratory one.
However, when saving the firmware file, an unpleasant feature of MMTOOL was noticed - the utility for some reason added 8 zero bytes to the end of the "P6 Micro Code" module - it turned out to be 32776 bytes in size. When extracting the same MMTOOL from the laboratory firmware, the ncpucode.bin file also became 32776 bytes in size at the output.
You can edit these things with simple editors available to all. But I also (accidentally) discovered an alternative way: when the universal utility BIOS_EXT.EXE extracted all modules from the laboratory firmware, the ncpucode.bin file was already obtained correct size 32768 bytes - BIOS_EXT.EXE utility correctly detected the end of the "P6 Micro Code" module when saving it to a file.
If the chipset and the LGA 775 motherboard can theoretically support the XEON 771, but the native BIOS does not support it, and the modified BIOS does not, then you can modify the BIOS yourself.
IMPORTANT
1. All changes in the BIOS firmware (.ROM file usually) you make at your own peril and risk. In case of an error, a guaranteed "brick" is obtained from the motherboard
2. The file size of the original firmware and the modified version must match up to a byte.
3. Firmware of the modified BIOS file back into the microcircuit is performed only with the proprietary utility from the motherboard developer (you must download it from the manufacturer's website).
4. Top motherboards in the BIOS itself have a built-in firmware update module (for example, EZ Flash 2 utility for ASUS P5Q in the Tools section) - the best option.
How to do it better:
1. Still looking for a ready-made version with XEON support on the Internet?
2. Download from the official site latest version firmware and add microcodes?
As you can see, the second option is safer, in any case you download the original firmware from the motherboard manufacturer's website, i.e. the latest version and the absence of errors are guaranteed (more precisely, the correction of all previously found errors). When downloading a ready-made version from third-party resources (for obvious reasons, it will not be on the original site) - you can get a crooked version and kill the BIOS.
Preliminary, you can evaluate the presence of XEON microcodes in the BIOS firmware.
- get the current AMI BIOS image via Universal BIOS Backup ToolKit 2.0
- look at the contents of the received ROM file through AMIBCP V 3.37
BIOS option AMI (American Megatrends Inc).
1. Download the latest version BIOS from the website of your motherboard manufacturer
3. Download microcodes for XEON 771 processors: lga771_microcodes
4. Find out the CPUID of your processor using AIDA64 or a similar program (it looks like cpu0001067Ah). If a BIOS will be sewn up before installing the processor, then we skip this item.
5. Unpack the archives MMTool and lga771_microcodes and leave from files with the extension .bin only those files beginning with the same CPUID of your computer (for example, cpu0001067a_plat00000044_ver00000a0b_date20100928.bin)
If we don't know what code, then we sew everything up.
A. Launch MMTool... Press the button (1) Load ROM and load the latest BIOS for your motherboard into the program. If you have the newest BIOS, then you can also merge the BIOS backup utility from the PC and edit it.
B. Go to the tab (2) CPU Patch, then with the button (3) Browse, open the file .bin corresponding to your CPUID.
C. Leave the default in options "Insert a Patch data" and press the button (4) Apply.
After updating with modified bios you need to do a factory reset through the reset button or jumpers, if the motherboard supports such a reset, or by pulling out the BIOS battery for a couple of minutes. Further, the processor is already correctly perceived by the computer and works as it should.
Basic Input Output System - basic input-output system, abbreviated BIOS. Small microcircuit on motherboard, which first receives control when the PC is turned on. Provided: basic PC settings check PC components at startup ...
Modern processors are complex devices that can have bugs. Furthermore, instead of executing x86 instructions directly, modern x86 processors contain internal code that implements support for the x86 instruction set. The internal code is called microcode. Microcode can be updated to fix or mitigate CPU bugs.
Some CPU bugs can make Firefox crash. For example, Firefox 57 and later is known to occasionally crash on Broadwell-U CPUs with old microcode in a manner not seen with newer Broadwell-U microcode versions.
Microcode updates can be loaded onto the CPU by firmware (usually called BIOS even on computers that technically have UEFI firmware instead of old-style BIOS) or by the operating system. Microcode updates do not persist across reboot, so in the case of a dual-boot system, if the microcode update isn "t delivered via BIOS, both operating systems have to provide the update.
On Mac, to have an up-to-date system, apply all OS X system updates and Apple firmware updates offered in the Updates pane of the App Store app.
To allow Windows to load updated microcode onto the CPU, make sure Windows Update is enabled and set to install updates.
To see the processor microarchitecture and which microcode revision is in use, run the command reg query HKEY_LOCAL_MACHINE \ HARDWARE \ DESCRIPTION \ System \ CentralProcessor \ 0 in the Windows command prompt. ( You can open the command prompt by pressing Windows + R, typing cmd and pressing Return.) The line labeled "VendorIdentifier" shows the CPU vendor (GenuineIntel for Intel or AuthenticAMD for AMD). The line labeled "Identifier" gives the microarchitecture as three numbers: "Family", "Model" and "Stepping". These are relevant in identifying if a particular CPU bug may be relevant to the CPU in your computer. The line labeled "Update Revision" shows the current microcode revision (for the particular microarchitecture) with zeros on both sides. For example, Update Revision REG_BINARY 000000001E000000 means that the revision is 1E (hexadecimal). The line labeled "Previous Update Revision" shows the microcode revision loaded from BIOS.
If the vendor is GenuineIntel, family is 6, model is 61 and stepping is 4, to avoid crashes with Firefox 57 or later, the microcode revision needs to be 1A or higher.
Whether microcode updates are in use by default depends on the Linux distribution and can differ for Intel and AMD CPUs.
- On Debian-based distributions, including Ubuntu, microcode updates for Intel processors are provided by the intel-microcode package and microcode updates for AMD processors are provided by the amd64-microcode package.
- On Arch, AMD microcode updates are installed by default, but Intel microcode updates require special steps.
- On Fedora, microcode updates are installed by default.
To see the processor microarchitecture and which microcode revision is in use, run the command less / proc / cpuinfo in terminal. The line labeled "vendor_id" shows the CPU vendor (GenuineIntel for Intel or AuthenticAMD for AMD). The microarchitecture is given as three numbers on lines labeled "cpu family", "model" and "stepping". These are relevant in identifying if a particular CPU bug may be relevant to the CPU in your computer. The line labeled "microcode" shows the microcode revision number (for the particular microarchitecture) in hexadecimal.