# flashrom, the utility that reads and writes firmware flash chips

> flashrom detects, reads, writes, verifies and erases flash chips, and it is the tool most firmware work depends on, from writing a coreboot image in system to programming a network card. The build is four meson commands, the chip support is a long list of parts and protocols, and the project asks you never to run it on a laptop.

**flashrom/flashrom** — Send patches to https://review.coreboot.org: https://www.flashrom.org/Development_Guidelines#GitHub

- Repository: https://github.com/flashrom/flashrom
- Website: https://review.coreboot.org/admin/repos/flashrom,general
- Stars: 1,187 · Forks: 511
- Language: C
- License: GPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/flashrom-flashrom

## One tool for the whole flash lifecycle

flashrom is a utility for detecting, reading, writing, verifying and erasing flash chips, and the list of verbs is the design. Detection comes first, because a tool that writes firmware has to know what it is talking to, and reading is separate from writing so that the contents can be inspected and backed up before anything is changed. Verification confirms that what was written matches what was intended, and erasing is available for the cases where a chip has to be cleared rather than overwritten. The common use is flashing BIOS, EFI, coreboot or firmware images in system on a supported mainboard, but the documentation also lists flashing of network cards, SATA controller cards and other external devices that can program flash chips. The audience is therefore two groups, a firmware developer working on a board and a systems administrator who has to restore or replace a chip image.

## Packages and protocols are the support matrix

The chip support is described in two dimensions, the physical package and the bus protocol. The packages named are SOIC8, DIP8, SOIC16, WSON8, PLCC32, DIP32, TSOP32 and TSOP40, which covers most of what a desktop or server board uses, and the protocols are LPC, FWH, parallel flash and SPI. The repository listing shows how that matrix becomes code. There is a flashchips/ directory for the chip database, jedec.c for the JEDEC identification flow, and a set of per family drivers, with s25f.c for the Spansion flash family, at45db.c for the Atmel DataFlash parts, en29lv640b.c for the EN29LV640B part, mcp6x_spi.c for the Microchip MCP series, and ichspi.c for the Intel chipsets that expose flash over SPI. A programmer can also bit bang the bus, which is what bitbang_spi.c is for. The practical consequence is that support is not a yes or no answer, it is a question about a specific part number in a specific package on a specific bus, and the project ships the list so you can check before you write.

## Four meson commands and a test suite

The build system is meson, and the summary in the README is four commands.

```bash
meson setup builddir
meson compile -C builddir
meson test -C builddir
meson install -C builddir
```

The third command is the interesting one. A tool that writes firmware is a tool where a bug destroys hardware, and running the test suite is part of the documented build sequence rather than an optional extra. The tree is set up for that kind of rigour. There is a meson_options.txt for build options, a meson_cross/ directory for cross compilation, a Doxyfile for API documentation, and a doc/ directory holding the developer guides for building from source and for development, plus the manpage sources and the release notes. The CLI itself has its own layer, with cli_classic.c, cli_common.c and cli_output.c, and the printing goes through print.c and printlock.c so that concurrent output does not interleave. The classic command line interface is documented in the flashrom(8) manpage, and the documentation for distributions that package the tool is found on repology.

## The laptop warning is the first thing to read

The README devotes a line to a warning that is not in the feature list, and it is the most operationally important sentence in the document. Do not use flashrom on laptops, because the embedded controller present in many laptops might interact badly with attempts to communicate with the flash chip, and may brick your laptop. The mechanism is plausible from the hardware side, an EC that also talks to the flash chip has no idea that a programmer has arrived, and a confused controller can write garbage over a firmware image. The second instruction is the one experienced users still repeat. Please make a backup of your flash chip before writing to it. The warning covers any attempt to talk to the chip, not just writes, since a confused controller can react badly to a read as well. The project also states that it is often used to flash images in-system on a supported mainboard, and the word supported is doing the work, since the tool has a board and chipset layer that enables or disables access to the chip on each platform.

## Programmers, boards and chipset enablement

Access to a flash chip is rarely a matter of connecting a cable. The repository shows the layers that make it work, and the file names describe them precisely. programmer.c and programmer_table.c with the programmers/ directory hold the programmer abstraction, which is the part that talks to a specific interface such as an external programmer or an on-board controller. board_enable.c, chipset_enable.c and known_boards.c handle the platform side, enabling and disabling access to the chip on a given mainboard, and ich_descriptors.c deals with the Intel flash descriptor layout. dmi.c reads system information, fmap.c and layout.c deal with the flash layout and the regions inside the chip, and cbtable.c and edi.c relate to firmware descriptor structures. The hardware access layer is separate, with hwaccess_physmap.c for physical memory mapping, hwaccess_x86_io.c and hwaccess_x86_msr.c for port and model specific register access, i2c_helper_linux.c for the I2C path used by some embedded controllers, and pcidev.c for PCI attached devices. Every one of those is a place where hardware differences turn into behaviour differences.

## A library underneath, and a development flow outside GitHub

The code is layered so that other programs can use it. libflashrom.c is the library entry point and libflashrom.map is the linker version script that defines the exported symbols, and the bindings/ directory provides the interfaces for other languages. The core functions in the tree, including flashrom.c and the chip drivers, are therefore reachable without going through the command line tool, which is what a vendor tool or an automated test rig needs. The other half of the picture is where the project is developed. The repository description says to send patches to the coreboot review system at review.coreboot.org, and the homepage given for the project is the review interface for the flashrom repository rather than a marketing site, so patches go through a Gerrit style review rather than a pull request. The official site is at flashrom.org, the list of distributions that package the tool is on repology, and there is a VERSION file and a release notes section in the documentation. The repository carries no GitHub releases, and the licence is GPL version 2 with the text in COPYING.rst, which matters for a tool that vendors into other firmware build systems.

## Conclusion

flashrom fits a firmware engineer writing a coreboot or BIOS image to a board, and it fits a systems administrator who has to read or restore the flash of a network card or a SATA controller. It does not fit a laptop user, since the project states plainly that the embedded controller in many laptops can interact badly with the flash chip and may brick the machine, and its releases are documented in the project's release notes rather than on a GitHub releases page. Verify three things first: that your board and programmer are in the supported list, that you have a working backup of the flash contents before any write, and that the version you install matches the hardware you have, because the write path is where mistakes become permanent.

## FAQ

### What does flashrom do?

It is a utility for detecting, reading, writing, verifying and erasing flash chips. It is often used to flash BIOS, EFI, coreboot or firmware images in system on a supported mainboard, and it also handles network cards, SATA controller cards and other external devices that can program flash chips.

### Can I use flashrom on a laptop?

No. The README states plainly that you should not use flashrom on laptops, because the embedded controller present in many laptops might interact badly with attempts to communicate with the flash chip and may brick your laptop. It also advises making a backup of the flash chip before writing to it.

### How do I build flashrom from source?

The project is built with meson, using meson setup builddir, then meson compile -C builddir, meson test -C builddir and meson install -C builddir. Detailed instructions are in the building from source guide in the documentation.

### Which flash chip packages and protocols does flashrom support?

The chip support covers packages such as SOIC8, DIP8, SOIC16, WSON8, PLCC32, DIP32, TSOP32 and TSOP40, over protocols including LPC, FWH, parallel flash and SPI. The repository keeps the chip database in the flashchips/ directory with per family drivers for parts from Spansion, Atmel, Microchip and Intel.

## Sources

- [flashrom/flashrom on GitHub](https://github.com/flashrom/flashrom)
- [Issues](https://github.com/flashrom/flashrom/issues)
- [License: GPL-2.0](https://github.com/flashrom/flashrom/blob/main/LICENSE)
- [Project website](https://review.coreboot.org/admin/repos/flashrom,general)
- [README](https://github.com/flashrom/flashrom/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flashrom-flashrom