# CPUMicrocodes: A Mirror of Production Microcode for Four Processor Vendors > CPUMicrocodes collects the latest production CPU microcode for Intel, AMD, VIA and Freescale parts, gathered only from official BIOS updates, Linux microcode packages, distribution updates and Windows updates that the manufacturers made public. Every file is named so that its CPUID, platform support, revision, release date and checksum are readable from the filename. **platomav/CPUMicrocodes** — Intel, AMD, VIA & Freescale CPU Microcode Repositories - Repository: https://github.com/platomav/CPUMicrocodes - Stars: 1,106 · Forks: 125 - Language: Unknown - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/platomav-cpumicrocodes ## A Mirror of Microcode Nobody Else Will Ship CPUMicrocodes is a collection of the latest production Intel, AMD, VIA and Freescale CPU microcodes, and the repository tree is four directories named after the vendors: ```text AMD/ Freescale/ Intel/ VIA/ ``` That is the whole project. There is no code, no build and no tool here, just the binary microcode blobs, organised by the vendor that published them. The README states the motivation plainly, and it is not a casual one. Collecting CPU microcodes is important for upgrading purposes, for creating universal tools that help people understand what microcode they use, for research on how the general technology works, and for developers with no vendor representative who want to work on a given platform. The disclaimer is the part that defines the project. All the microcodes come only from official BIOS and UEFI updates, Intel and AMD Linux microcode updates, Linux distributions and Windows updates, and all of it was provided and made public by various manufacturers. So the collection is a mirror of what vendors shipped, not a set of modifications, which is the thing that would make it a different project entirely. ## The File Name Is the Metadata Every microcode in the collection follows one naming scheme, which is what makes the repository usable with a script rather than by hand: ```text cpu[CPUID]_plat[PlatformID]_ver[Revision]_[Date]_[Release]_[Checksum].bin ``` The examples show how the same pattern serves four vendors: ```text Intel: cpu906EB_plat02_ver0000007C_2017-12-03_PRD_5046D998.bin AMD: cpu00800F11_ver08001129_2017-07-14_4F426450.bin VIA: cpu10690_ver00000001_sig[BJ_10690.020]_2017-01-09_A8B24DC2.bin Freescale: soc8360_rev2.1_sig[Soft-UART]_3725F40B.bin ``` The field descriptions explain each part. The CPUID encodes the family, generation, model and stepping, with Intel 0x000906EB, AMD 0x00810F10, VIA 0x00010690 and Freescale 0x8323 as examples. The Revision is a microcode update revision counter, increased when fixes are applied, with 0xA0B less than 0xA0E as the illustration. The Date is the date of its public release in ISO 8601 format, and the Checksum is used for quick integrity validity checks during transmission to system manufacturers. Two of the fields are vendor specific. The Release or Type field is Intel only, and the Signature field appears for VIA and Freescale only, where it carries a human readable CPUID and update revision such as BJ_6FE_0205 or MPC8569 QE Microcode Rel_B6900155. ## The Platform Bitfield Is the Field That Bites The Platform field is described as Intel only, and it is the most consequential part of the name, because it encodes which sockets and platform types the microcode supports. The value is a bitfield of up to eight supported platforms in little endian binary form. The examples decode it: 0xC0 is 0b11000000 which is platforms 6 and 7, 0x03 is 0b00000011 which is 0 and 1, and 0x76 is 0b01110110 which is 1, 2, 4, 5 and 6. The platform numbers map to sockets such as LGA775 and LGA1366, or to platform types such as Desktop and Mobile, depending on the CPU generation. The guidance that follows is a set of rules for comparing two microcodes, and it is worth reading closely before you swap one in. When updating, ensure that at least the same or more platforms are supported. To not risk losing socket or platform support, avoid reducing the supported platforms: changing from 0x5C, which covers 2, 3, 4 and 6, to 0x5D, which covers 0, 2, 3, 4 and 6, is fine because it adds platform 0, but changing from 0x5C to 0x58, which covers only 3, 4 and 6, might not be, because platform 2 is missing. There is also an explanation for a confusing case. If you cannot find the exact CPUID and Platform combination you currently have, it might be because a microcode with the same CPUID but more supported platforms exists. The example given is CPUID 0x906E9 with platform 0x22, covering 1 and 5, being superseded by CPUID 0x906E9 with platform 0x2A, covering 1, 3 and 5, in order to add LGA2066 socket and HEDT platform type support at KBL(-X). And a null platform of 0x00 is implicitly the same as a single platform of 0x01, since at least one platform must be supported, so at CPUID 0x633 platform 0x00 equals 0x01 equals 0. ## PRD, PRE and Why Only Production Microcode Is Kept The Release or Type field is Intel only, and it records the status of the microcode as either Production, PRD, or Pre-Production, PRE. The rule that follows is direct: PRD microcodes are to be valued higher than PRE due to stability and testing, and only PRD microcodes are included in this repository. So the collection is already filtered, and the naming makes the filter visible. That matters when you are comparing a file here with something your distribution shipped, because a PRE build that a developer pulled from a test channel would never appear in this tree, while a PRD build that matches what you have would. The Revision field has a related rule for the other vendors. For Intel and AMD, only the latest microcodes of each CPUID are included in the repositories, so you will not find the history of a given CPUID, only the current production one. Taken together, the filtering rules make the repository a current state rather than an archive. If you need an older microcode for a specific part, this is not where you will find it. ## Verification with MC Extractor and the Checksum Caveat Every microcode in the collection is checked by MC Extractor to verify its health, size and similar properties, and the README points at that project's own documentation for what the tool can do. The sibling project is worth knowing about, since it is the tool that turns a directory of binary blobs into something you can query. The README also suggests using MC Extractor to check instantly whether a microcode is already in the repository, so a user who finds a microcode somewhere else can check whether it is already here. And if a microcode appears to be missing, the instruction is to report it at the discussion topic rather than opening an issue in this repository. The checksum field needs a caveat. It is used for quick integrity validity checks during transmission to system manufacturers, but all Freescale and AMD microcodes with a CPUID of 0x00500F00 or above lack an official checksum, and in that case MC Extractor generates its own. The practical difference is that an official checksum is a value the manufacturer published, while a generated one is a value computed by the tool, so a mismatch means something different in the two cases. The project also runs a news feed and a discussion topic, both linked from the README, which is where the community side of the collection lives. ## When to Use This and When to Wait for Your Vendor The README's own advice is the first thing to read, and it is a recommendation to be careful. It is generally advised to request or wait for your OEM or OS vendor to release newer fixes, and the reason is stated: latest is not always better or tested. Manufacturers and OS maintainers usually have insider and confidential information from microcode vendors on what got changed and fixed in a newer release, so if they ship older microcodes it could be that newer versions have not been thoroughly tested, have been retracted or downgraded by the microcode vendor, or do not contain anything important enough to warrant an update. That is a real argument. A microcode is firmware that runs before the operating system, it is matched to a part stepping, and a vendor who ships an older revision is usually making a decision rather than being behind. The stated purpose of the collection is therefore narrow and explicit. The microcodes here are gathered and provided with the sole purpose of helping people who are out of other viable solutions, and they can be extremely helpful to those who have major problems with their systems for which their manufacturer refuses to assist due to indifference or system age. So the decision rule is simple. If your vendor still ships updates, use theirs. If they do not, and the README's platform rules let you match a file to your part without reducing socket support, this is where you will find one. The repository publishes no GitHub releases, the licence is not stated in the metadata, the repository is not archived, and the last push was on 2026-09-03. ## Conclusion CPUMicrocodes fits a Linux user whose manufacturer has stopped shipping microcode updates, or a developer working on a platform where the vendor updates are hard to find, since the collection is organised by the identifiers you need to match a file to a part. It is a poor fit for a supported machine, because the README is explicit that it is generally advised to request or wait for your OEM or OS vendor to release newer fixes, since latest is not always better or tested. Before using a file from here, check the platform support in the filename does not shrink, check the revision is higher than what you have, and verify the file with MC Extractor, since the AMD and Freescale entries in the tree do not carry an official checksum. The repository publishes no releases, states no licence, and the last push was on 2026-09-03. ## FAQ ### What is in the CPUMicrocodes repository? A collection of the latest production CPU microcodes for Intel, AMD, VIA and Freescale processors, split into the AMD, Freescale, Intel and VIA directories. The files come only from official BIOS and UEFI updates, Intel and AMD Linux microcode updates, Linux distributions and Windows updates made public by the manufacturers. ### How are the microcode file names structured? They follow cpu[CPUID]_plat[PlatformID]_ver[Revision]_[Date]_[Release]_[Checksum].bin. The CPUID encodes family, generation, model and stepping, the revision is a counter increased when fixes are applied, the date is the public release date in ISO 8601, and the checksum is used for integrity checks during transmission to system manufacturers. ### What does the Platform field mean for Intel microcode? It is a little endian bitfield of up to eight supported platforms, encoding sockets such as LGA775 and LGA1366 or platform types such as Desktop and Mobile depending on the generation. When updating you should ensure at least the same or more platforms are supported, so changing from 0x5C to 0x5D is fine while changing from 0x5C to 0x58 might not be, because platform 2 is missing. ### Why are only production microcodes included? The Release or Type field is Intel only and records the status as Production, PRD, or Pre-Production, PRE. PRD microcodes are valued higher due to stability and testing, and only PRD microcodes are included in the repository. For Intel and AMD, only the latest microcode of each CPUID is kept. ### Should I install the newest microcode from this repository? The README advises requesting or waiting for your OEM or OS vendor to release newer fixes, since latest is not always better or tested, and says manufacturers often have information about retractions or downgrades. The collection is gathered for people out of other viable solutions, so it is a fallback rather than a first choice. ## Sources - [Issues](https://github.com/platomav/CPUMicrocodes/issues) - [platomav/CPUMicrocodes on GitHub](https://github.com/platomav/CPUMicrocodes) - [README](https://github.com/platomav/CPUMicrocodes/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/platomav-cpumicrocodes