Every Antminer hashboard carries a small I²C EEPROM that answers one question for the control board: which board is this, and how was it tuned? When that chip can’t be read — or its contents don’t match what the firmware expects — the miner reports an “EEPROM error” and refuses to hash the board. This reference explains what actually lives in that EEPROM across the S19 and S21 generations, why the data is encrypted, why boards aren’t freely interchangeable, and what that means when you’re diagnosing a repair.
The structural detail here comes from our own reverse-engineering of the on-device EEPROM parsers, cross-checked against live board dumps on our bench. We publish the layout and field structure — not encryption keys or key-derivation routines, which remain the property of their authors. Credit where due: this understanding stands on the open-source mining-firmware ecosystem (the BraiinsOS lineage and the wider community that documented these boards).
What the EEPROM stores — and what it doesn’t
The single most useful fact for a repair tech: the headline numbers you see in a miner’s UI — chip type, voltage, frequency, hashrate — are not stored verbatim in the EEPROM. What the EEPROM holds is board identity and factory calibration; the firmware computes the operating parameters by looking up the board name in an internal SKU table and applying a voltage/frequency curve.
The fields that are stored (varying slightly by generation) include:
- Serial number — the 17-character ASCII board serial.
- Board name (B-NAME) — e.g. a BHB-series designator that maps to a chip generation.
- Chip identity — die revision, chip marking, and the factory bin grade.
- Feature/tuning string (FT) and a V/F curve descriptor — the per-board calibration.
- PCB version and BOM version.
- Factory job code — the fixture batch the board was tested in.
- On S19j-class boards, explicit sensor rows: temperature-sensor part types and their I²C addresses, including the PIC-based sensor.
Because calibration is per-board, two visually identical hashboards are not data-interchangeable — a point that connects directly to the role of the EEPROM in Antminer devices and to the PIC microcontroller that co-stores calibration on S19-series boards.
Four parser families, by generation
Antminer hashboard EEPROMs are not one format — they’re a family that evolved with the silicon. Firmware dispatches to one of four parsers based on a short preamble at the start of the chip:
| Parser family | Encryption | Hashboard generations | Chips |
|---|---|---|---|
| x19_plain | XXTEA | Early BHB42xxx (S19 / early S19j Pro / T19) | BM1398 / BM1362 |
| x19_J | XXTEA (structured PT1/PT2) | S19j class (BHB428xx) | BM1362-era |
| x21_aes | AES-128 | BHB56xxx / BHB68xxx / A3HB7xxxx (S19k Pro, S21 family) | BM1366 / BM1368 / BM1370 |
| braiinsminer | (magic-prefixed) | Braiins BMM100 / BMM101 boards | — |
The two things that changed over time: the cipher (the S19-era boards use XXTEA; the S19k Pro and S21 generation moved to AES-128) and the structure (the S19j and later formats split the data into two independently CRC-protected sections — board info and parameter info — instead of one flat blob).
The preamble dispatch
The first one or two bytes of the EEPROM select the parser. In practical terms: an S19-generation board opens with a layout byte of 0x04, while the S19k Pro / S21 generation opens with 0x05. Braiins’ own boards carry a distinct magic prefix. This is why firmware can tell a BM1398 board from a BM1370 board before it decrypts a single field — the family is legible from the header alone.
Why two CRC-protected sections matter (S19j and later)
On S19j-class and newer boards the payload carries two checksum-protected regions: a board-info section (board identity, sensors, chip data) and a parameter-info section (the tuning). Each has its own CRC and expected length. A repair consequence follows directly: corruption localized to one section produces a different failure than corruption in the other, and a valid clone requires both sections to check out — not just a byte-for-byte copy that happens to include a stale CRC.
What actually triggers an “EEPROM error”
The firmware rejects a board’s EEPROM for several distinct reasons, each a different repair path:
- Read failure on the I²C bus — the chip doesn’t answer at all. Suspect the EEPROM itself, its power rail, or the I²C lines. This overlaps with the “board not recognized” family in our EEPROM error fix guide.
- Version/layout mismatch — the preamble byte isn’t what the parser expects (a board flashed with the wrong data, or a genuinely different generation).
- Decrypt failure / bad magic — the encrypted payload doesn’t decode, usually meaning corrupted or wrongly-written contents.
- CRC failure — the data decrypts but a section checksum is wrong; classic sign of a partial or mismatched write.
- Board-name mismatch — the stored B-NAME doesn’t match the SKU family the firmware expects, which is exactly what happens when you mix boards from different miners.
The repair-bench takeaways
Three things this architecture tells you at the bench. First, EEPROM data is board-specific — you cannot simply move a hashboard between two miners and expect it to hash; the stored identity and calibration have to be consistent with the set. Second, an “EEPROM error” is a diagnosis prompt, not a verdict: it separates into I²C/hardware faults, write-corruption, and mismatch — and each is handled differently. Third, because the operating parameters are computed from stored identity rather than stored directly, a board with corrupted calibration can still enumerate but run wrong — which is where voltage-domain measurement and the hashboard test-fixture method earn their keep.
A note on tooling and ethics: reading and re-writing these EEPROMs on hardware you own is ordinary repair work. Redistributing a manufacturer’s encryption keys or key-derivation code is not, and we don’t do it — our published references cover structure and method only. For the broader board context, see our ASIC control-board reference and the Antminer S19 family owner hub.
If a board is throwing an EEPROM error and you’d rather not chase it down the I²C bus yourself, that’s daily work at our Montreal repair bench — EEPROM, PIC, and full board-level diagnosis included.
Bitaxe GT" width="80" height="80" loading="lazy" style="width:80px;height:80px;object-fit:contain;border-radius:6px;background:#1A1A1A;flex-shrink:0;">



