Summary of Best Practices for Firmware Updates

A firmware update on an ASIC miner is a controlled operation, not a click-and-walk-away. Get it right and you gain security patches, better temperature handling, and cleaner autotuning. Get it wrong — wrong image, a power blip mid-flash, or a fleet-wide push with zero soak time — and you can soft-brick a control board or take a whole rack offline. This guide is the disciplined procedure: source the image correctly, verify it, back up your config, roll out in stages, confirm the result, and recover cleanly if a unit refuses to boot.

Rule zero: only official, signed images from the vendor

Every reputable miner firmware — Bitmain stock, and the major third-party firmwares — ships a cryptographically signed image. The control board checks that signature before it will run the new code. Download only from the manufacturer’s own portal (for Antminers, Bitmain’s support/download page), match the file exactly to your model and hardware revision, and never flash an image scraped from a forum, a reseller mirror, or a chat group. A mismatched or tampered image is the single most common way people brick otherwise-healthy hardware.

• Match the model precisely. An S19 image is not an S19 Pro image; an S17 is not an S17+. The chip and board layout differ, so the tuning tables inside the firmware differ.
• Verify the download. If the vendor publishes a checksum or the web UI reports a signature failure, stop — a truncated or corrupt download will fail the on-device signature check and can leave the unit half-written.
• Do not downgrade past an anti-rollback line. Newer secure-boot firmware sets an anti-downgrade flag; trying to flash an older image afterward is rejected and can hang the upgrade routine.

Pre-flight checklist

Before you touch a single miner, close out the variables that turn a routine update into an outage.

1. Confirm the units are healthy first. Never flash a miner that is already throwing hashboard, temperature, or PSU faults — you will not be able to tell whether the new firmware helped or the underlying hardware was the problem. Clear faults first; a bad update layered on a bad board just doubles the diagnosis.
2. Guarantee clean power. The flash writes to onboard flash memory; an interruption mid-write is the classic brick. Miners on shaky mains, a sagging circuit, or a marginal PSU should be stabilized before you start. On grid-tied setups, don’t run a fleet update during a period where a breaker trip is likely.
3. Record the current config. Note pool URLs, worker names, static IPs, and any tuning profile. Some updates preserve settings; others — especially ones that change the secure packaging policy or strip the old voltage-calibration data — wipe you back to defaults and you’ll re-enter everything.
4. Know your recovery path. For Antminer control boards that means having an SD-card recovery image and a card reader on the bench before you need them, plus Bitmain’s IPReporter (or an ARP scan of the subnet) ready to re-find a unit that comes back on a different address.
5. Read the release notes. Legitimate firmware notes tell you what changed: security/anti-virus hardening, sleep-mode or low-voltage gears, temperature-sensing accuracy, or removal of the old voltage-calibration step. If a release adds overclock/undervolt gears, that’s a signal you’ll want to re-tune afterward, not assume old numbers carry over.

Phased rollout: never flash the whole fleet at once

Testing at the vendor cannot reproduce every hashcenter’s power quality, ambient temperature, pool, and airflow. Treat your own site as the final test lab.

1. Flash a small pilot batch first — on the order of 10–30 units, or a representative slice of a small farm.
2. Soak them for at least 24 hours under normal load. Watch hashrate stability, hashboard temperatures, error/reject rates, and fan behaviour, not just the first five minutes after reboot.
3. Only then push the rest. If the pilot batch holds hashrate with no new faults across a full day and thermal cycle, roll out in waves — not all at once, so a bad surprise never takes the entire site down together.

Performing the update

1. Back up the config from the miner’s web dashboard if that option exists, or record it by hand.
2. Upload the signed image through the firmware/upgrade page in the web UI. Choose whether to keep settings; if the release changes the security packaging or tuning model, expect to reconfigure regardless.
3. Do not cut power and do not navigate away while it writes and reboots. The unit will drop off the network briefly — that is normal. Let it finish.
4. Wait for it to rejoin and start hashing before you consider the unit done.

Verify the result

An update isn’t finished when the miner reboots — it’s finished when it’s proven stable.

• Firmware version in the dashboard matches the image you flashed.
• Hashrate settles at or near the model’s expected rate; the autotuner recalculates frequency and voltage at runtime, so give it time to converge rather than judging the first minute.
• Temperatures are in range on every hashboard and the chip-to-chip spread looks even.
• Pool shows the worker submitting accepted shares with a low reject rate.
• No new fault codes in the miner log.

If a unit won’t come back

A miner stuck on a failed flash — no web UI, no hashing, or a boot loop — is usually recoverable, not dead.

1. Re-find it on the network. Use the manufacturer’s IP-reporter broadcast tool or scan the subnet’s ARP table; a reset unit often reappears on DHCP rather than its old static IP.
2. SD-card recovery. For Antminer control boards, write the vendor recovery image to a microSD, insert it, and boot from it to reflash the control board. This restores boards that no longer respond over the network.
3. Factory reset via the reset button if the unit boots but is misconfigured, then re-enter your pool and network settings.
4. Escalate hardware. If recovery flashing fails repeatedly, the fault is likely on the control board itself, not the firmware — that’s a bench-repair job, not another flash attempt.

Common mistakes to avoid

• Flashing the wrong model/revision image because the filenames looked similar.
• Updating a fleet in one shot with no pilot batch and no soak time.
• Cutting power or closing the browser mid-write.
• Assuming old tuning numbers survive a release that reset the calibration data.
• Chasing “performance” firmware from unofficial sources — unsigned images are how miners get bricked and how malware gets onto a farm.

Related: When an update surfaces an underlying hardware fault, work it through the ASIC fault finder, pull the model-specific procedure from the miner manuals library, and if a control board won’t recover after reflashing, start a repair rather than flashing it again.