Read this before you flash anything. The first rule of beta firmware is recovery-first: never put experimental code on a board you cannot get back. DCENT_OS is D-Central’s open-source (GPL-3.0) Antminer firmware, currently in closed beta on the Antminer S9 family only, and it is experimental — it can brick your miner, cause downtime, and void the manufacturer warranty. This guide is the undo button: how to roll an S9 back to stock firmware, and how to rescue a flash that genuinely went wrong, including UART serial recovery. If you read only one DCENT_OS document before joining the beta, make it this one.
The good news the rest of this guide rests on: a DCENT_OS S9 install runs from the SD card, not the internal flash. That design choice is what makes recovery almost always trivial. In most “it bricked” moments, your miner is not bricked at all.
First, the calm truth: it is probably not bricked
On an S9, the Zynq SoC picks its boot source from a jumper. With jumper J3 open the board boots from internal NAND (stock firmware); with J3 shorted it boots from the SD card (DCENT_OS). Because a DCENT_OS install lives on the card, the stock firmware in NAND is never overwritten. That means your fastest recovery is also the simplest:
- Power off and unplug the miner. Let the PSU discharge for a minute.
- Pull the microSD card.
- Set J3 back to open (NAND boot).
- Power on. The miner boots its original stock firmware as if DCENT_OS had never been there.
If that works — and it usually does — you are done. You have rolled back to stock. The “failed flash” was almost certainly a bad SD card, a wrong jumper position, or a slow first boot you didn’t wait out. Re-image the card, verify the checksum, and try again when you’re ready.
The recovery decision tree
Work this top to bottom. Stop at the first step that gets your miner responding.
| Symptom | Most likely cause | What to do |
|---|---|---|
| No web UI off the SD card, but boots stock with the card out | Bad/corrupt SD image, wrong card, or wrong J3 position | Re-verify the image checksum, re-image a known-good card, confirm J3 is shorted for SD boot |
| Miner powers on, fans spin, no network at all | DHCP/network, not firmware | Check router client list, try a direct cable, scan the subnet; the S9 takes a DHCP lease on boot |
| Fans ramp to 100% and stay there | Normal early-boot fan behavior, or no hashboard comms yet | Wait two to three minutes; if it never settles, pull the card and boot stock to isolate firmware vs hardware |
| Nothing at all — no LEDs, no fans | Power, not firmware | Test the PSU and circuit before suspecting the flash — see the PSU note below |
| Boots stock fine, but a hashboard is dead/erroring | Hardware fault, not the flash | This is repair territory, not a recovery problem — see the repair note at the end |
| Will not boot stock even with the card out and J3 open | Rare — possible NAND/boot issue | UART serial recovery (below) |
Rule out power before you suspect the flash
A tired or undersized PSU makes a perfectly good flash look like a brick. The stock S9 pairing is the Bitmain APW3/APW3++ (1600 W at 220 V, 1200 W at 110 V) or the APW7 (1800 W at 220 V). If your PSU is near its rating, on a marginal circuit, or simply old, the miner can brown out during boot and never come up — which looks exactly like a brick but isn’t. Swap in a known-good PSU on a solid circuit before you go any further. This single check resolves a surprising share of “bricked after flashing” reports.
What is actually protected on the chip (why a true brick is rare)
It helps to know what an SD flash can and cannot touch. On the Zynq S9, the boot chain is layered, and the earliest, most critical layers are RSA-signed and effectively read-only:
- BootROM — hardcoded in the silicon. Nothing you flash can damage it. It reads the boot-mode pins and decides NAND or SD. This is your ultimate safety net.
- FSBL + FPGA bitstream + U-Boot (in mtd0, 40 MB) — RSA-verified, keys fused into the SoC. The FPGA bitstream cannot be replaced (RSA-protected by eFuse keys). An SD boot doesn’t write here.
- The ramdisk root filesystem (mtd1, 32 MB) — this is the replaceable layer, SHA-256 verified rather than RSA. A DCENT_OS SD install doesn’t overwrite your NAND copy of it at all — it runs from the card.
The practical takeaway: because the immutable boot stack lives in protected, RSA-signed flash and DCENT_OS runs from the SD card, a genuinely unrecoverable S9 from an SD flash is very rare. The BootROM will always try to boot; give it a valid source (NAND with J3 open, or a good card with J3 shorted) and it will.
UART serial recovery (the last resort)
If the miner truly will not boot stock — card out, J3 open, known-good PSU, and still nothing — the next tool is a serial console. UART recovery lets you watch the boot process directly and talk to the board’s bootloader, which turns “it’s dead” into “here’s the exact line where it stops.” This is advanced, hardware-level work; if you are not comfortable with a USB-to-serial adapter and a terminal, this is the point to stop and send it to a bench.
The S9 control board exposes a serial console on the CPU UART. (Note the architecture quirk: the FPGA handles the high-speed UART links to the hash boards, while the console you want is the Zynq’s own debug UART.)
- Get a 3.3 V USB-to-serial (TTL) adapter. The S9 console is 3.3 V logic — never connect a 5 V adapter, you will damage the board. A common FTDI or CP210x adapter set to 3.3 V is correct.
- Connect three wires: adapter GND to board GND, adapter RX to board TX, adapter TX to board RX. Do not connect the adapter’s VCC — the board powers itself. The closed-beta image ships with the exact console header location and pinout for your specific S9 control-board revision (XIL, BB, CV, AML); revisions differ, so use the note for your board, not a generic pinout.
- Open a terminal (screen, minicom, PuTTY) at 115200 baud, 8-N-1, no flow control — the standard Bitmain console setting.
- Power on and watch. A healthy board prints BootROM → FSBL → FPGA load → U-Boot → kernel. Where the log stops tells you what failed: no output at all points to power or the adapter wiring; output that halts at U-Boot points to a bad/missing boot source; a kernel that panics points to the filesystem.
- Re-image from the bootloader. If you reach a U-Boot prompt, you can re-flash a clean stock or beta image to NAND/SD over serial following the procedure shipped with the beta image. This is how a board that “won’t boot anything” gets a fresh, valid firmware written back.
UART recovery sounds intimidating and is genuinely the deep end — but it is also why open hardware like the Zynq S9 is so hard to permanently kill. There is always a serial console underneath the firmware, watching the boot, ready to be talked to. That is the same recoverability that made the S9 our first beta target.
When it is hardware, not firmware
Recovery only fixes software problems. If your S9 boots stock cleanly but a hash board is dead, a chain reads zero, or you see physical damage, no firmware — stock or DCENT_OS — can undervolt around a failed chip or a broken domain. That is a repair, not a recovery. Our ASIC repair bench handles dead domains, failed chips, and board-level faults; we have been doing exactly that since 2016, which is part of why we trust the S9 as a beta platform in the first place.
Frequently asked questions
How do I roll DCENT_OS back to stock on an S9?
Power off, pull the SD card, set jumper J3 back to open (NAND boot), and power on. The miner boots its original stock firmware because a DCENT_OS SD install never overwrites the stock firmware in NAND. That is the entire rollback — no re-flashing required for a standard SD install.
Did flashing DCENT_OS brick my miner?
Almost certainly not. The most common causes of a “bricked after flashing” S9 are a corrupt SD image, a wrong J3 jumper position, a marginal PSU, or impatience on a slow first boot. Work the decision tree above — pull the card and boot stock first. A genuinely unrecoverable S9 from an SD flash is rare because the boot stack is RSA-protected and the install runs from the card.
When do I need UART recovery?
Only when the miner will not boot stock even with the card removed, J3 set to NAND, and a known-good PSU — the rare case that points to a NAND or boot issue rather than the card. UART lets you watch the boot log and re-flash from the bootloader. It is advanced; if you are not comfortable with a 3.3 V serial adapter, send the board to a repair bench instead.
What baud rate and voltage for the S9 serial console?
115200 baud, 8-N-1, no flow control, at 3.3 V logic. Never use a 5 V adapter — it can damage the board. Connect GND, RX, and TX only; do not connect the adapter’s VCC. The exact console header location varies by S9 control-board revision, so use the pinout shipped with your beta image.
Does recovery void my warranty?
Flashing third-party firmware can void the manufacturer warranty regardless of whether you later roll back. Treat a flashed miner as out of manufacturer warranty for firmware-related issues. The full picture is in our beta safety & warranty guide.
Where do I get help if I’m stuck mid-recovery?
Join the community on Discord — build notes, tester chat, and the people who wrote the firmware: join the D-Central Discord. Watch github.com/DCentralTech/DCENT_OS for releases. We do not send newsletters; we reach out once, when your beta slot opens.
Next steps
Now that you know how to recover, the install procedure is here: Install DCENT_OS on the Antminer S9 (SD card). For the broader generic background on ASIC SD imaging and bricked-miner recovery, see our SD-card firmware flashing & recovery guide and Firmware update failed fix. The always-current status of what is flashable today is on the beta-status page.
Recovery-first, always. DCENT_OS is in closed beta on the Antminer S9 today — experimental, GPL-3.0, public beta planned for summer 2026 (an estimate). Flash only a miner you can recover. Join the waitlist to get on the S9 testing list; the waitlist is not a pre-order.
Space Heater Edition" width="80" height="80" loading="lazy" style="width:80px;height:80px;object-fit:contain;border-radius:6px;background:#1A1A1A;flex-shrink:0;">
When your miner retires: one more layer decentralized
Open-source firmware extends a miner's useful life. When a model retires from profitable mining, the power, cooling, and connectivity you built around it can still serve the distributed-compute layer — heat reuse, mesh comms, or freeing infrastructure for sovereign AI.
