A BIOS chip has a fixed size, and a file written to it must fit exactly. Yet the files technicians handle come in many sizes: a vendor update might be 9 MB, a dump from the chip 16 MB, a "BIOS region" file 6 MB, and a download for a two-chip board 12 MB. Writing the wrong one, or padding a file to fit without understanding it, is a common way to turn a recoverable board into a dead one. This guide explains why sizes differ and how to make sure the file matches the chip.
Chip sizes on laptop boards
| Chip capacity | Size in bytes | Typical use |
|---|---|---|
| 32 Mbit (4 MB) | 4,194,304 | Older boards; second chips on two-chip boards |
| 64 Mbit (8 MB) | 8,388,608 | Older and simpler boards; EC or second chips |
| 128 Mbit (16 MB) | 16,777,216 | Very common on recent laptops |
| 256 Mbit (32 MB) | 33,554,432 | Newer and larger platforms |
The capacity comes from the chip's marking; SPI Flash Size Calculator (BIOS Chip Mbit to MB) converts a marking to bytes.
What a full chip image contains
On Intel-based laptops, a full SPI image is divided into regions:
| Region | Content |
|---|---|
| Flash descriptor | The map of regions and access permissions, at the start |
| ME region | Management Engine firmware |
| GbE region (if present) | Wired network settings including the MAC address |
| BIOS region | The UEFI firmware itself |
| Others (some boards) | EC firmware, platform data |
The descriptor defines where each region starts and ends, so the image only works at the chip's exact size. The descriptor is explained in The Intel Flash Descriptor: Regions, Locks and Why It Matters. AMD platforms use a different layout but the same principle: the full image must match the chip.
Why files come in different sizes
Vendor update files
Updates downloaded from a laptop manufacturer are designed for the manufacturer's flashing tool, not for a programmer. They may be:
- a single region, typically the BIOS region only;
- wrapped in a capsule with a header in front of the data;
- packed inside an executable;
- several images for different boards in one package.
Their size rarely equals the chip size, and writing them raw with a programmer usually makes things worse. File types are compared in BIOS File Formats: .bin, .rom, .cap and .fd Explained.
Region-only files
A file that contains only the BIOS region is smaller than the chip. It is useful for replacing that region inside a full image, not for writing directly.
Full dumps
A dump read from the chip by a programmer is exactly the chip size. It is the only kind of file you can write back directly — preferably the board's own dump. Such files are described under bios dump.
Two-chip images
Some boards split the firmware across two chips, for example 8 MB plus 4 MB. A download for such a board may be one 12 MB file that must be split before writing. This is covered in Laptops with Two BIOS Chips: When the Dump Is Split.
Checking a file before writing
- Compare the size with the chip exactly, in bytes — not just "about 16 MB".
- Look at the start — a full Intel image typically has the descriptor signature near the beginning; a capsule header or an executable header means it is not a raw image.
- Check for blank areas — a file full of 0xFF where code should be may be incomplete.
- Compare with the original dump of the board, region by region, if you have it.
Units that cause confusion
Sizes are quoted in several ways. Chip capacities are given in megabits, file sizes in bytes, and many tools say "MB" when they mean mebibytes (1,048,576 bytes). A "16 MB" chip holds 16,777,216 bytes, not 16,000,000. Always compare the exact byte count of the file with the exact byte count of the chip; rounding hides the very differences that matter.
Why padding is dangerous
It is tempting to pad a smaller file with 0xFF to the chip size and write it. Without a valid descriptor and regions in the right places, the board will not start. Padding is only correct when you know exactly where the file belongs in the image — for example placing a BIOS region at the offset the descriptor specifies, using a tool that understands the layout.
Building a correct image
The safe approach, when the original chip is corrupted:
- Read and save the original, even if corrupted — it may still contain the board's unique data.
- Obtain a clean full image for the exact board, or build one by placing a vendor BIOS region into a known-good full image.
- Transfer the board's unique data — serial number, UUID, MAC address — from the original.
- Check the result's size and structure, then write and verify.
AMD platforms
On AMD-based laptops the firmware image has a different internal structure, with directories for the platform security processor's firmware instead of an Intel descriptor and ME region. The rule is the same: a raw image written with a programmer must be the full chip size and have the platform's expected layout. Vendor updates for AMD laptops are equally unsuitable for raw writing, and the same care with board-specific data applies.
Keeping a library of verified images
Over time, keep a library of images you have verified on real boards:
- the board code and revision;
- the chip size and part number;
- whether the image is an original dump or a cleaned one;
- what unique data was removed or needs to be added.
A verified, correctly sized image for a board you see often turns a dead-board recovery into a routine job, while an unverified download from an unknown source can cost hours.
Example: a 9 MB file for a 16 MB chip
A technician has a dead board with a 16 MB chip and a downloaded "BIOS file" of just over 9 MB. Written directly, it would leave the descriptor and ME region missing and the BIOS in the wrong place. Opening the file in a firmware analysis tool shows a capsule header followed by a BIOS region. The technician reads the board's own corrupted chip, which still has an intact descriptor and ME region, replaces only the BIOS region with the one extracted from the capsule, checks the size — exactly 16,777,216 bytes — and writes it. The board starts, with its own serial and MAC intact.
FAQ
Can I write a smaller file to a bigger chip?
Not as a raw file. A full image must match the chip size exactly.
Why is the manufacturer's update file not the chip size?
It is made for the manufacturer's flashing tool and often contains only part of the image, wrapped in a header.
What happens if I pad a file with FF?
Usually the board will not start, because the descriptor and regions are missing or misplaced.
How do I know if a file is a full image?
It matches the chip size exactly and, on Intel platforms, starts with a valid flash descriptor.
What about two-chip boards?
The image is split across chips. Split the file at the right point and write each part to its chip.
Bottom line
A file written with a programmer must match the chip exactly and contain a valid layout. Vendor updates, region files and capsules are not raw images. Check sizes in bytes, inspect the start of the file, never pad blindly, and build a correct image by combining a clean region with the board's own descriptor and unique data.