DCENT_OS install routes by control board

Your route is chosen by the control board, not by the model on the sticker

This is the single most useful thing to know before you try to put DCENT_OS on an Antminer, and almost nothing published anywhere says it: one model name maps to several different control boards, and DCENT_OS treats each of them as a separate target with its own capabilities. Two miners with the same badge on the front can be in completely different positions — one with a published signed artifact, one that will not energize a hash board at all.

So the question is never “is the S19j Pro supported?”. It is which board is in this particular machine. The table below is the full answer, generated directly from board_desc.rs in the public GPL-3.0 source rather than written by hand — locate it with grep -n "pub const fn am1_s9" in dcentrald/dcentrald-common/src/board_desc.rs.

So how do you find out which one you have? Not from the badge, and not from the model number. Work through the Antminer control-board identifier — it starts by asking whether the miner still boots, then falls back to a board photo match and finally to the SoC part marking, so it still returns an answer on a machine that is dark or off the network. dcent doctor below needs the miner up and reachable; this does not.

The three states, and there are only three

Read that middle row carefully. “Can dispatch work” is not “there is a download”. Ten targets can mine and have no public artifact. One target has an artifact. Those are different axes and we will not collapse them, because collapsing them is exactly how somebody ends up flashing a machine that was never going to hash.

Every board target DCENT_OS knows about

What that means per machine, stated plainly

Antminer S9 (Zynq/XIL). The only target whose board record authorises a public-beta package for a first install from vendor firmware — public_beta_install is true for am1-s9 and for nothing else. Read that as permission, not as a finished route: the public repository still lists the witnessed first-install, boot, soak and recovery capstone as an open evidence gap, and the S9’s own policy record carries recovery_maturity: NotImplemented. Sustained cold-boot mining with accepted pool shares is documented, and a signed artifact is published. The S9 is also the cheapest and most abundant machine to experiment on, with dual-copy A/B boot slots and a UART header. If you want to see DCENT_OS run without writing to your miner at all, take the reversible S9 SD trial instead — it boots from the card and never writes to NAND, so pulling the card puts you back exactly where you started.

Antminer S19j Pro (Zynq/XIL). Mining achieved, and a signed artifact exists — but read what that artifact is. It is a guarded DCENT_OS-source self-update: an update you can only run if the machine is already on DCENT_OS. First install from vendor firmware is an open evidence gap. That is not a flash, and we are not going to call it one.

Antminer S21 (Amlogic). Mining achieved on the bench — accepted pool shares, roughly 66 TH/s sustained. There is no packaged public artifact, and in-place install over the stock Amlogic controller is still blocked. Compile from source if you know what you are doing; otherwise wait.

Antminer S19 Pro and S19. They share one board target, so they take the same route: a build from source plus an operator-edited config. Cold-boot hashing with clean nonce flow is recorded on the S19 Pro; accepted shares are untested on current binaries. Not a stock image, and not an install route.

Antminer S17, S17 Pro, T17 — and the S17e / T17e. There is no route. The daemon refuses these targets before it touches the hardware, deliberately, because nobody has validated a safe first write on them. The BM1397 driver work is in the tree and the S17 shares the S9’s Zynq control-board class, and neither of those facts makes it installable. Run BraiinsOS+ or VNish on your S17 today. We will say so here the day that changes, and not before. (Note the chip canon while you are here: BM1397 is the S17, S17 Pro, T17, S17+ and T17+; the S17e and T17e are BM1396, a distinct silicon family, not a “plus” variant.)

Before you write anything to a miner

dcent doctor <miner-ip>
dcent install --dry-run <miner-ip>

You should see doctor report the vendor, the firmware and the control-board family it fingerprinted, and install --dry-run either name the exact route it would take or refuse with the reason. Both are read-only. If --dry-run refuses, that is the answer — the route gates exist to be used before the write, not after.

Keep a known-good recovery path ready regardless. DCENT_OS is a public beta and it can brick a miner. Model-by-model evidence and the release record · Getting back to stock · Which boards the Toolbox can fingerprint

---

Related: Model-by-model evidence and the release record · Which boards DCENT_Toolbox can fingerprint.