flashrom 2.0 Will Ask Your Chip for Its Papers

Three days ago, flashrom 1.8.0 shipped.

There won’t be a 1.9.0. The next release is flashrom 2.0.0, landing in January 2027, exactly 25 years after the first commit. A project doesn’t get a quarter-century birthday twice. Skipping a version number is the least we can do for it.

So here’s the roadmap. Three plans.

Plan One: Ship the Receipts¶

If you read the last post, you know I own about 1Tb of SPI ROM and a verification process that involves two programmers arguing with each other until they agree. The goal for 2.0.0 is to ship that verified chip database in the tree: real silicon behavior, tested in hardware, on record.

I have a lot of chips. I don’t have all the setups. A chip verified on one bench is a data point; the same chip verified on two different benches, in two different countries, on two different programmers, is a fact.

So contributions are welcome, and the bar is low on purpose. If you have any chip lying around that flashrom 1.8.0 can’t identify, test it. Push a change to Gerrit, or just send a mail to the list with your results. There’s a step-by-step howto that assumes nothing, written for people doing this for the first time. Since I have the chips, I can re-run your part number in hardware here and cross-validate. You confirm it works on your setup, I confirm it works on mine, and the database stops depending on my bench being the single source of truth for the planet. That’s a bus factor of one, and I’ve read enough flashrom code to know what happens to buses.

This is not hypothetical. The day after 1.8.0 shipped, Anastasia merged five of these in a single afternoon: Harry Sung sent the ISSI IS25LP01GJ, IS25WP01GJ, IS25LP512MG and IS25WP512MG, and mathewb64 sent the AT25FF041A, the AT25EU0041A and the PUYA PY25Q16HB. Seven chips in one day, from people who owned the part and took an evening to prove it works. Alexander Clouter did the same with a PUYA P25D32SH earlier this month, Rafael Franco with the Boya BY25D20/40 in July.

None of them asked permission first. That’s the entire process. You have the chip, you run the test, you push the result, and some stranger at 2 AM three years from now stops getting a warning about it.

Plan Two: The Eviction¶

In the last post I said I decided to become flashrom’s first negative contributor. Deciding is free. Here comes the invoice.

flashrom’s oldest party trick is using hardware you already own as a programmer. Random PCI cards, mostly. A 3Com network card. A Realtek NIC. An Nvidia graphics card. SATA controllers from Silicon Image and Marvell. Hardware designed to move packets and pixels, drafted into flashing chips because it happened to expose a path to the flash bus, back when a dedicated programmer cost real money and RAM was cheap. We flipped the variables since: today a CH347 costs a few dollars, RAM costs a kidney, and the devices these programmers were rescued from only boot old flashrom versions anyway.

So thirteen programmers are candidates for eviction in 2.0.0:

rayer_spi, atavia, atapromise, nic3com, gfxnvidia, satasii, nicrealtek, nicnatsemi, satamv, drkaiser, atahpt, it8212, developerbox_spi

1.8.0 is the last release that carries all of them. The deletion commits are already sitting on Gerrit under the topic delete-prog-in-v2.0.0, one per programmer, each commit message carrying the research on what the hardware was and why it’s on the list. Each one that merges pushes my line count further below zero. Nothing is erased from history: every flashrom release up to and including 1.8.0 keeps every programmer forever.

If one of these is load-bearing for your workflow, you can send a rescue helicopter. Though let’s be honest about the word “workflow” here. This is 32-bit era hardware, old enough to have rust on it. The oxide kind. The language doesn’t even know these boards exist. Either way, the terms are public and simple:

1. Double-check which flashrom version you actually need. If it’s 1.8.0 or older, you’re not affected and the helicopter can stay in the hangar.
2. Adopt the programmer: send a patch adding yourself to the MAINTAINERS file for it. The commitment is keeping it in working condition. No meetings, no other duties.
3. Prove you actually have the card. Before the end of this year, run a read, a write, and an erase on current flashrom head, and send the log. If flashrom prints warnings during that run, they get fixed properly, not silenced.

No adoption, no log, deleted from tree.

Step three is the one that matters, and it isn’t bureaucracy. Putting your name in MAINTAINERS next to hardware you’ve never powered on doesn’t preserve anything, it just moves the corpse to a nicer plot. These are two-dollar PCI cards from the era when capacitors were a lottery. Half the surviving units have bulged caps, and the drivers underneath them are broken in different ways on Linux, on the BSDs, and on Windows. A MAINTAINERS entry backed by nothing means the next person who hits a bug gets routed to someone who can’t reproduce it, which is worse than having no entry at all. It converts a clean deletion into a permanent open ticket.

A read, a write, an erase, and a clean log. If the hardware is real and the driver works, that’s one evening. If it takes longer than one evening, that is the answer.

Three helicopters are already in the air. Petr Cvek put his name on the ATA VIA, 3Com, and Realtek NIC entries within days of the announcement, which is exactly the outcome the deadline was designed to produce. That’s step two done on three of them. Step three is still owed on all three, and on anything else that shows up between now and December. Ten have nobody at all. And the moment the remaining deletions merge, the negative contributor title stops being a plan and becomes arithmetic.

Plan Three: The Model¶

It will be 2027. Everything needs AI now, that’s the law.

I recently found a washing machine with AI. Brother, you spin laundry. In a drum. Why do you need WiFi and a persistent connection to a server in Germany or China to rotate wet socks. What is the model predicting. The socks are in there. I put them there, I know.

flashrom will not be left behind. flashrom 2.0.0 will have AI.

We evaluated the usual candidates. Claude, GPT and Deepseek were rejected early: they need an API key and a network connection, and flashrom’s core user is someone at 2 AM with a dead board, a clip, and no network. Cloud inference does not recover your BIOS.

So we went bigger. The model we’re implementing is JESD216H.

The Model Card¶

JESD216H is the August 2025 revision of JEDEC’s Serial Flash Discoverable Parameters standard, SFDP. As a model, its specs are hard to argue with:

• Hallucinations: zero, by design
• Chip identification benchmark: 100%, saturated since 2011
• Inference: fully on-device. Not edge computing. Inside the actual chip.
• Inference cost: one 0x5A command at whatever your SPI clock is. No tokens, no GPU, no monthly invoice.
• Weights: fit in a PDF, free download from JEDEC

Here’s what it actually is, because this part is real. Since 2011, JEDEC has defined a way for a serial flash chip to describe itself. The chip carries a small parameter table in a reserved address space: density, erase block sizes, address byte count, supported fast-read commands, the quad-enable procedure. You send the SFDP read command, 0x5A, and the chip hands over its own spec sheet. The silicon self-reports.

Papers, Please¶

In flashrom 2.0.0, flashrom walks up to the chip and asks for its papers.

If the papers are in order, most of the interrogation is over. No passing the chip name by hand, no guessing between three different parts that happen to share a JEDEC ID, no forum thread asking which -c value to use. The chip declares itself at the border, the glorious flashrom inspector stamps it, next in line.

Most of the interrogation, not all of it. The papers are thorough about some things: density, erase geometry, address width, every fast-read opcode, the exact dummy cycle count at each frequency. Then you reach the status register, and JESD216H defines exactly two bits of it. Bit 0 is BUSY. Bit 1 is Write Enable Latch. Everything else is marked Reserved (section 6.17.6, page 142, and you can go read it yourself). The block protect bits, the top/bottom select, the complement bit, the register lock: all the machinery that decides which regions of the chip you are allowed to write is simply not in the standard, and fourteen years of revisions never added it.

So the papers state the chip’s name, its address, and whether it happens to be busy right now. There is no field for what it’s allowed to touch. SFDP alone gets you read, erase, and write, and no write-protect support at all, which is why the flashchips table isn’t going anywhere even for chips that answer 0x5A perfectly. The one question a recovery tool actually needs to ask at 2 AM is the one the border guard can’t answer.

Then there are the refugees: the chips that never implemented SFDP. Pre-2011 silicon, the budget parts, the parallel flash. They show up at the border with no papers at all, and they still need their name passed manually. Twenty-four years of hand-written entries is the asylum system, and nobody gets turned away over paperwork.

The Model Doesn’t Hallucinate. The Fine-Tunes Do.¶

Now the part that justifies the whole chip-buying spree.

JESD216H itself is exact. The vendors implementing it are vendors. Chips ship with SFDP tables copy-pasted from a different part in the same family. Erase sizes that don’t match the silicon. Quad-enable procedures the chip doesn’t actually honor. The Linux kernel carries a pile of SFDP fixups for exactly this reason: the papers are forged often enough that the border needs a fraud department.

Which is why Plan One and Plan Three are the same plan. Every SFDP table I read gets checked against measured behavior on real silicon: write a pattern with one programmer, read it back with another, compare what the chip claims to what the chip does. The last post had a section called Datasheets Lie. The chip’s own papers lie too, just less often, and now there’s a database that knows which ones.

So the January release notes write themselves. flashrom 2.0.0: AI-powered, 100% on identification benchmarks, zero hallucination, full on-device inference, no cloud dependency. Every word of it true. That’s the most 2027 sentence I’ll ever write.

Papers, please.