ASIC Control-Board Recovery Playbook — Cross-Board Unbrick Index

A bricked ASIC is recovered by its control-board family, not its model — a dozen Antminer models can share one board and one recovery method. This playbook indexes each family’s default boot, how to force a recovery boot, serial-console access, the reflash method, and where to source a legitimate image. It is the how-to companion to the control-board reference.

Quick answer

A bricked ASIC is recovered by its control-board family, not its model — a dozen Antminer models can share one board and one recovery method. The recovery ENTRY is the fact that matters: a Xilinx Zynq board (S9 through S19-gen) recovers from an SD card via the J3 jumper; a BeagleBone AM335x board from an SD image; an Amlogic board only through its micro-USB OTG port; a Cvitek or WhatsMiner board from a model-specific SD/USB image; and an open ESP32 Bitaxe over USB in the browser. This playbook indexes each family's default boot, recovery entry, serial console, reflash method, and where to source a legitimate image — grounded in the D-Central Bible for the Bitmain boards and flagged "verify against the manual" where the procedure is model-specific.

Identify the family, confirm the recovery entry, back up before you write, use the correct PSU and the exact-model image, and check firmware-lock status FIRST — Amlogic Antminers shipped after March 2024 are locked and are a different job from a merely-bricked board. Do not touch the RSA-verified / eFuse-locked Zynq boot stages; those are not the recoverable parts.

🔴 Recovery can permanently brick a board. Back up NAND/flash first if the board still responds, use the correct power supply and input voltage, never interrupt a write, and never flash a different model\'s image. Confirm firmware-lock status before you start.

This is a recovery index, not a datasheet. This is a recovery INDEX, not a hardware datasheet. Its companion — the control-board reference — tells you which board is inside a given miner and how it boots; this playbook tells you how to bring one back when it will not boot. It is organized by control-board FAMILY rather than by miner model, because a dozen Antminer models can share one board and one recovery method. Find your board family (from the model list or the control-board reference), then follow that family's entry. For the board hardware spec and boot architecture, see the control-board reference; for lock status, the firmware-lock tracker; for a bricked Bitaxe, D-Central\'s own web flasher.

Xilinx Zynq (S9 → S19-gen, L7)

Bible-grounded

Models: S9/S9i/S9j/T9+/R4 · S17/S17+/T17/T17+ · S19/S19 Pro/S19a · L7 · SoC: Xilinx Zynq-7010 (dual Cortex-A9 + Artix-7 FPGA)

Boots from: NAND (256/512MB). Boot chain: BootROM → FSBL → FPGA bitstream → U-Boot → kernel → ramdisk.
Recovery entry: Set jumper J3 to SHORT to boot from a prepared SD card (J3 OPEN = normal NAND boot). This is the sanctioned firmware-install/recovery path on Zynq boards.
Serial console: Debug UART header on the control board (3.3V TTL, commonly 115200 8N1 — confirm the header pinout for your board before connecting). Note the ASIC-chain UART is separate (driven by the FPGA), not the CPU console.
Reflash: Boot from SD (J3 short), then rewrite NAND from the stock image. mtd0 (BOOT.bin: FSBL+FPGA bitstream) is RSA-verified and the FPGA bitstream is eFuse-locked — do NOT try to replace those; the recoverable/replaceable parts are the ramdisk (mtd1, SHA256) and configs.
Image source: Stock recovery images: the manufacturer's firmware download page for the exact model. Open alternative: BraiinsOS+ install media. Never flash a mismatched-model image.

Open tooling this builds on: polprog/antminer_zynq and braiins/zynq-io (open Zynq FPGA/boot work). Credit to the community that mapped the Zynq boot chain.

BeagleBone-style AM335x (BBCtrl / BB18)

Bible-grounded

Models: L3+/L3++ (Scrypt) · late-2021 S19j/S19j Pro stock-BB (BB18) · SoC: TI AM335x Sitara (single Cortex-A8, no FPGA — software ASIC comms)

Boots from: Reads boot-mode pins (NAND or SD). SD card sits inside the enclosure cover.
Recovery entry: Prepare an SD card with the model's recovery image and boot from it (boot-mode pins select SD). The AM335x will boot the SD U-Boot + kernel + rootfs.
Serial console: AM335x debug UART header (3.3V TTL, commonly 115200 8N1 — verify the header). Standard BeagleBone-class serial-console access.
Reflash: SD-card image (U-Boot + kernel + rootfs); reflash internal NAND from the booted recovery environment where the model supports it.
Image source: The manufacturer's firmware page for the exact model. BeagleBone-class boards are the simplest to re-image because the SD path is well understood.

Builds on the open BeagleBone (BeagleBoard.org) ecosystem and community re-imaging work.

Amlogic AXG (AMLCtrl; C76/C81/C83/CBE)

Bible-grounded

Models: S19j Pro/S19 XP/S19k Pro · S21/S21 Pro/S21 XP/S21+ · L9 · SoC: Amlogic A113D (quad Cortex-A53, originally an audio SoC; no FPGA, NO SD slot)

Boots from: Internal NAND ONLY — there is no SD-card boot path on these boards.
Recovery entry: Recovery is via the micro-USB OTG port: you need a USB-OTG adapter + a USB drive (or host tool) with the recovery image. This is the only external recovery entry on Amlogic boards.
Serial console: Per-hashboard UARTs are /dev/ttyS1–S3 with GPIO reset/detect lines; the CPU debug console is a separate UART header (3.3V TTL, verify pinout). PSU is on I2C /dev/i2c-1 addr 0x10.
Reflash: USB-OTG recovery flash to internal NAND. There is no jumper SD shortcut — the OTG path is mandatory.
Image source: Manufacturer recovery image for the exact model. 🔴 Units shipped after March 2024 carry FIRMWARE LOCKS requiring a specific unlock procedure — check the lock status FIRST (see the firmware-lock tracker) before attempting recovery.

Builds on skot/amlogic-cb-tools (open Amlogic control-board tooling) — the project that mapped the AXG serial/GPIO layout.

Cvitek CV1835 (CVCtrl; C88/CB8/CB4)

verify vs manual

Models: S19k Pro/S19 XP/S19j Pro/S19j XP · S21/T21 · KS3/KS5/X5/L9 (C88/CB8/CB4 boards) · SoC: Cvitek CV1835 (RISC-V/ARM SoC)

Boots from: Internal flash (NAND/eMMC) per board.
Recovery entry: Recovery method varies by board revision — typically an SD-card or USB recovery image per the model's service procedure. ⚠️ Confirm the exact entry (SD vs USB, any button/jumper) against the model manual before proceeding.
Serial console: Board debug UART header (3.3V TTL, commonly 115200 8N1 — verify).
Reflash: Re-image internal flash from the model's recovery media.
Image source: Manufacturer recovery image for the exact model. Cross-check the manuals library for the model's documented recovery steps.

Newer Bitmain control-board generation; community tooling is still maturing — treat the exact procedure as model-specific.

ESP32-S3 (Bitaxe-class open hardware)

Bible-grounded

Models: Bitaxe Ultra/Supra (BM1366), BitSupra (BM1368), Bitaxe Gamma (BM1370), and similar open single-board miners · SoC: Espressif ESP32-S3 (self-contained; runs AxeOS / ESP-Miner)

Boots from: Flash on the ESP32-S3; the miner IS the controller (no separate control board).
Recovery entry: The easy case: put the ESP32-S3 into download mode (hold BOOT while resetting on boards with the buttons) and flash over USB. Because it's open hardware, recovery is fully supported.
Serial console: USB-serial (CP210x/native USB, 115200) — the standard ESP32 console. Web Serial works in-browser.
Reflash: Flash AxeOS / ESP-Miner over USB with esptool, or use a browser Web-Serial flasher. D-Central hosts a web flasher for exactly this.
Image source: Open firmware: the AxeOS / ESP-Miner releases (open source). Use D-Central's own web flasher at /flash/ to recover a Bitaxe-class board in the browser.

Bitaxe and AxeOS/ESP-Miner are open-source (skot / the open-miner community) — the whole point is that recovery is never locked. Credit to the open-hardware predecessors.

Allwinner H-series (WhatsMiner / MicroBT)

verify vs manual

Models: WhatsMiner M1–M3 / M8–M12 / M19–M20S / M50–M60S / D-series · SoC: Allwinner H3/H6/H616 (ARM)

Boots from: Internal flash; MicroBT control boards use a documented SD-card upgrade/recovery flow.
Recovery entry: MicroBT's standard path is an SD-card recovery/upgrade image booted on the control board. ⚠️ Use the exact image for the control-board revision and follow MicroBT's documented steps.
Serial console: Board debug UART header (3.3V TTL — verify pinout/baud).
Reflash: SD-card recovery image per MicroBT's procedure; some generations also support a network/USB upgrade.
Image source: MicroBT's official firmware/recovery image for the exact WhatsMiner model + control-board revision.

MicroBT-specific; follow the manufacturer's documented SD recovery. Confirm the board revision first.

Kendryte K210 / K230 (Avalon / Canaan)

verify vs manual

Models: K210 bare-metal: A1346/A14x/A15x (industrial) · K230 Linux: Avalon Nano 3/3S/Mini 3 (home) · SoC: Kendryte K210 (bare-metal, no Linux) or K230 (Linux, home-class)

Boots from: K210 industrial boards are bare-metal (no OS); K230 home boards run Linux from internal flash.
Recovery entry: Canaan's path is the Avalon management tooling + a model-specific recovery image; K210 bare-metal boards recover differently from K230 Linux boards. ⚠️ Follow Canaan's documented procedure for the exact model.
Serial console: Board debug UART header (3.3V TTL — verify). K210 exposes a serial console for the bare-metal firmware.
Reflash: Canaan recovery/upgrade image via the Avalon tooling; method differs between the K210 and K230 lines.
Image source: Canaan's official firmware/recovery image for the exact Avalon model.

Canaan/Avalon-specific; K210/K230 recovery is model-dependent — verify against Canaan's service docs.

Firmware locks. 🔴 Firmware locks change the game. Amlogic-based Antminers shipped after March 2024 (and some Cvitek boards) carry vendor firmware locks that must be cleared with a specific unlocking procedure before a normal recovery will take. Always check a unit's lock status BEFORE you start — a locked board is a different job from a merely-bricked one.

Standing on open shoulders. This index stands on open-source shoulders: polprog/antminer_zynq and braiins/zynq-io mapped the Zynq boot chain, skot/amlogic-cb-tools mapped the Amlogic control board, and the Bitaxe / AxeOS / ESP-Miner projects keep open-hardware recovery unlocked by design. D-Central compiles and cross-references that work into one vendor-neutral recovery map; we credit the people who did the reverse-engineering.

Open data (CC BY 4.0): CSV · JSON · API: /wp-json/dc/v1/control-board-recovery

Related products, repair, and setup paths

Last reviewed July 18, 2026.