Antminer S9 SD Trial — First Boot of DCENT_OS

Flight check — 60 seconds

Before you start

The trial

1. Download the SD image and its checksum ledger

   curl -O https://d-central.tech/downloads/dcent-os/beta-20260709/DCENTOS_XIL1_S9_SD_beta20260709.img
   curl -O https://d-central.tech/downloads/dcent-os/beta-20260709/SHA256SUMS.txt

   You should see

   Both files in your working directory. The .img is the bootable SD image for the S9 XIL lane, from the beta-20260709 release set. The release page is the checksum ledger of record.

   Proves nothing yet — step 2 does. Undo delete the files.

2. Verify before you write

   sha256sum -c SHA256SUMS.txt --ignore-missing

   You should see

   DCENTOS_XIL1_S9_SD_beta20260709.img: OK. Anything else: stop, re-download, and if it still mismatches, report it — never flash a file that fails its checksum. For the SD image, the SHA-256 line is the check you can run yourself; the sysupgrade .tar packages additionally embed a signed manifest. Full walkthrough: the verification guide.

   Proves the bytes you hold are the bytes we published. Undo nothing to undo.

3. Write the image to the SD card

   Open balenaEtcher → select the .img → select the card → Flash.

   You should see

   Etcher report "Flash complete" with its own verification pass. This is a raw image write, not a file copy — dragging the .img onto the card produces nothing bootable. Etcher's post-write verification closes out "bad write" as a failure cause before the card ever meets the miner.

   Proves you have bootable trial media. Undo reformat the card.

4. Power off, insert the card, select SD boot

   Power the unit fully OFF first. Insert the card, then select SD boot by one of the two supported routes — pick ONE:

   • JP4 jumper, SD position on the control board, or
   • the stock Bitmain uEnv.txt override — the jumper-less route via Bitmain's own boot-environment override mechanism.
   Bench note: jumper labels differ across Zynq boards — read your silkscreen

   The DCENT_OS S9 runbook names JP4 for the S9 board's SD-boot position. On the Zynq C55/C71 control boards used in later S19-family units, the boot-select jumper is documented as J3 (open = NAND, short = SD). Different PCBs, different silkscreen — verify the label on your board before moving anything, and photograph the original position so you can put it back.

   Evidence gap — honest note

   We don't yet publish a photograph of the JP4 header location, and the public repo names the uEnv.txt override route but not the file's contents or placement. If you can't confidently identify the jumper on your board revision, stop here rather than guess — and if you capture photos, open a platform bring-up issue; that's exactly the evidence that closes this gap. We'd rather you bounce than guess.

   Proves the board will take a boot path you control. Undo power off, remove card, restore the jumper — stock NAND boots.

5. First boot: confirm management-only

   Power on. Find the miner's IP (your router's client list, or the IP Reporter guide), then open http://<MINER_IP>/.

   You should see

   The DCENT_OS dashboard and SSH come up in management-only mode: interface live, hash power off. No fan roar, no hashing. A correct first boot is therefore quiet. If the dashboard is up and mining is off, the trial is working exactly as designed — confirm this state before enabling mining; that's the runbook's own acceptance step.

   Proves DCENT_OS boots your S9 and the safety default holds — before a single watt has gone to the hashboards. Undo power off, pull the card — previous NAND firmware boots.

   Evidence gap — LED patterns during a DCENT_OS SD boot

   The repo install docs do not document front-panel LED behavior under DCENT_OS, so this page doesn't either. The success signal on this procedure is the dashboard and SSH, not the lights. If you capture LED behavior on your bench, report it — that's how these gaps close.

STOP-GATE: no dashboard?

6. Set your pool, then enable mining — when you're ready

   Finish the setup wizard, point it at your pool (the configuration reference covers every field), and explicitly enable mining. Fans and power draw come up now — on a home bench, mind the noise settings before you flip it. The card stays in for the entire session.

   You should see

   Hashboards enumerate, then accepted shares appear on your pool's worker page — the only success metric that counts. Connected ≠ mining — accepted shares on the pool side are the proof. On the project's own evidence scale this is the "mining achieved" bar: accepted pool shares, not just boot.

   Proves DCENT_OS mining on your S9, end to end — with stock firmware still sitting intact in NAND one card-pull away. Undo disable mining in the dashboard, or step 7.

7. End the trial — the whole point

   1. Power the miner off.
   2. Remove the SD card and undo the boot-select you set on the way in — JP4 jumper back to its original position, or remove the uEnv.txt override.
   3. Power on. The previous NAND firmware boots, exactly as you left it — the trial never wrote to NAND.

   You should see

   Your previous firmware, untouched: "Pulling the SD card returns the unit to its previous NAND firmware." That's what "reversible" means here — demonstrated, not promised.

   Proves the exit door works. Undo re-insert the card to run DCENT_OS again — the card is now a bootable trial you can re-run, and a recovery tool. Want to keep running DCENT_OS instead? Leave the card in — the trial IS the system.

After the trial

Tune it: S9 tuning protocol · quiet home mining. Exit doors for every lane: uninstall / restore stock.

Report what happened

Worked or didn't, the project wants the datapoint: model, board family, and a pool screenshot (redact your wallet) if it mined; the daemon log if it didn't. Use the platform-bring-up issue template on GitHub.