Goldshell ST-BOX – Firmware 2.2.0 Update Brick

Confirm you are actually on `2.2.0` and not a different release that shipped a similar progress-bar UI. From the LAN, browse to `http://<miner-ip>`, log in with `admin` / `123456789` (or your custom password), open `Settings` → `System Info`, and read the `Firmware Version` field. If it starts with `2.2.0` or shows a `2.2.0`-family hash, you are on the regressed build. If it shows `2.1.x` or older, this page does not apply — your hashrate-drop or web-UI issue is a different cause and you should check the [Goldshell ST-BOX cross-issue index](https://d-central.tech/asic-troubleshooting/goldshell-firmware-update-fails-stuck/).

Cold-boot once before assuming the regression. Pull AC at the wall, wait `60` seconds, replug, wait `5` minutes for the miner to fully boot (the `2.2.0` boot is `30`-`45 s` slower than `2.1.x` because of the new Hub-registration retry loop). Re-load the dashboard and let it sit for `15` minutes. A subset of `2.2.0` units recover from the dashboard hang and reach steady-state hashrate after the second cold boot — Goldshell hasn't documented why, but the bench data shows roughly `1 in 5` units self-correcting.

Disable the Goldshell Hub registration if your firmware exposes the toggle. On `2.2.0` the Hub-registration daemon retries aggressively and can starve the miner daemon of CPU on the BOX-series single-core SoC. In the web UI navigate to `Settings` → `Cloud` (or `System` → `Hub` depending on the build), uncheck `Enable Goldshell Hub`, save, and reboot. If the toggle isn't present, skip to Step 5 — your `2.2.0` build has the daemon hard-coded on and the only fix is rollback.

Re-enter pool credentials manually before declaring the rollback necessary. On the `Pool` page, delete the existing pool entry, add it back from scratch with the full URL (`stratum+tcp://<host>:<port>`), worker name (`<address>.<workername>`), and password (`x` or whatever your pool requires). `2.2.0` has a known credential-corruption bug that wipes the worker string but keeps the URL; manual re-entry restores it `~50%` of the time. Save, reboot, and watch the pool dashboard for share submissions over the next `30` minutes.

Decide on rollback to `2.1.x`. If after Steps 2-4 the hashrate is still `>10%` below nameplate, the dashboard is still hanging, or the Hub-registration daemon is still pegging the SoC, the only documented fix as of `2026-04` is downgrade to the last-known-good `2.1.x` build for the ST-BOX. Goldshell has not shipped a `2.2.1` patch at the time of writing — track the [official firmware page](https://www.goldshell.com/upgrade-firmware/) and the [GitHub firmware issues](https://github.com/goldshellminer/firmware/issues) for the patch release, but plan for rollback now.

Acquire a `2.1.x` ST-BOX firmware image. Goldshell's official firmware page typically only hosts the *current* version — once `2.2.0` shipped, the `2.1.x` images were pulled. Workable archive sources, in order of preference: (a) your own backup if you saved the `.zip` before upgrading (the prevention rule for next time); (b) the [VoskCoin community firmware mirror](https://github.com/VoskCoin/firmware) which archives older Goldshell releases; (c) email `hello@goldshell.com` and request the previous ST-BOX release explicitly, citing the `2.2.0` regression — response time `24`-`72 h`, occasionally `1`-`2` weeks during peak. Verify the `.zip` filename matches your exact model variant (`ST-BOX`, not `ST-BOX II`) before flashing.

Switch to ethernet for the rollback flash — every time, no exceptions. WiFi packet loss during a Goldshell firmware write is the single most common path from a recoverable downgrade to a red+green-LED brick (covered in detail at [Goldshell — Firmware Update Fails / Stuck at X%](https://d-central.tech/asic-troubleshooting/goldshell-firmware-update-fails-stuck/)). Plug a known-good ethernet cable from the ST-BOX directly to your router. In the miner UI go to `Settings` → `Network` and delete any saved WiFi configuration so the miner cannot fall back mid-flash.

Power-condition the miner with a UPS for the rollback. A `500 VA` consumer UPS (~`CAD $120`-`$180` at any Canadian retailer — APC Back-UPS, CyberPower CP685, or equivalent) carries the ST-BOX through a `15`-minute flash window even during a line sag. The eMMC write phase of any Goldshell upgrade is the single highest-risk moment in the miner's life, and a downgrade is *more* dangerous than the original upgrade because the firmware version is older than the bootloader expects.

Perform the rollback flash. In the web UI go to `Settings` → `System Update` (or `Firmware`), click `Upload Firmware`, select the `2.1.x` `.zip`, click `Confirm`. Watch the progress bar but do *not* interact with the page or close the tab. Expected total time: `8`-`15` minutes. The progress bar will sit silently between `60%` and `95%` for `5`-`12` minutes during the eMMC write — this is normal, see the cross-linked guide. If the bar advances to `100%` and the miner reboots automatically, log back in and verify `System Info` reports `2.1.x`. If the bar hangs past `25` minutes without progress, you have a separate problem — go to the [stuck-upgrade guide](https://d-central.tech/asic-troubleshooting/goldshell-firmware-update-fails-stuck/) for the controlled cold-recovery procedure.

Verify the rollback worked. After the post-flash reboot, run `find.goldshell.com` from a laptop on the same subnet to relocate the miner (the IP may have changed via DHCP). Log in at `http://<new-ip>` with `admin` / `123456789`, navigate to `System Info`, confirm `Firmware Version` is `2.1.x`. Re-enter pool credentials from scratch on the `Pool` page (do not assume the rollback preserved them). Watch the dashboard for `30` minutes and the pool's accepted-share counter for `60` minutes — realized hashrate should return to `~1 TH/s` ±5% on a known-good ST-BOX. If it stays below `~850 GH/s` after rollback + burn-in, the hardware itself has a fault unrelated to `2.2.0` and you escalate to Tier 4.

Pin the working `2.1.x` version. Calendar-block any further upgrades on this miner until Goldshell ships `2.2.1` or `2.3.x` and the community has verified it on the GitHub issues page and in `voskcointalk.com` threads for `30+` days. Set a quarterly reminder to re-check the firmware status — but the pleb mining motto applies hard here: *if it ain't broke, don't OTA it*. Save the working `2.1.x` `.zip` plus a `sha256` text file to your file server; archive the `burn-st-box.img` recovery image too if Goldshell sends it. The two-minute archival step today saves you a `2`-week response-window panic next time.

If the OTA-based rollback in Step 9 fails (progress bar hangs at the same percentage on `3+` retries with ethernet plugged, WiFi deleted, UPS in line, and the verified `2.1.x` `.zip`), the eMMC partition layout from `2.2.0` may be incompatible with the OTA downgrade path. Move to SD-card recovery. Email `hello@goldshell.com` for the `burn-st-box.img` recovery image (subject: `burn-st-box.img recovery request — 2.2.0 regression rollback — SN: <serial>`). Acquire a quality microSD card (Samsung EVO Plus or SanDisk Industrial, `8`-`16 GB`, Class `10` / `U1`, ~`CAD $15`-`$25`) plus a microSD-to-USB adapter (~`CAD $10`).

Flash the `burn-st-box.img` to the microSD card with [balenaEtcher](https://etcher.balena.io/). Open Etcher, click `Flash from file`, select the image Goldshell sent, click `Select target`, *triple-check* you've picked the SD card and not your laptop's SSD, click `Flash`. Etcher auto-verifies the write — if you see a red X on verification, the SD card is bad, get a different one. Total time: `2`-`5` minutes for an `8 GB` image.

Insert the SD card into the ST-BOX microSD slot, cold-boot with ethernet *unplugged*, wait `15` minutes. The slot is under the rear rubber flap on the ST-BOX; some early units need `4` Phillips screws to expose it. The bootloader prefers SD over eMMC and will rewrite the eMMC from the SD image — this resets the miner to whatever firmware version Goldshell shipped on the recovery image (typically a `2.1.x`-family build, but verify with Goldshell which version their current `burn-st-box.img` carries). LED activity during the recovery: slow blink or alternating pattern for `5`-`15` minutes, then the miner powers down or reboots into the recovered state. Do *not* interrupt — pulling power mid-recovery turns a fixable brick into a control-board swap.

Post-recovery verification and hardening. Remove the SD card, cold-boot one more time, find the miner via `find.goldshell.com`, log in with `admin` / `123456789`. Immediately change the default password (`Settings` → `System` → `Password`). Verify the firmware version. Re-enter pool credentials from scratch. Run a `24`-hour burn-in at nameplate hashrate — accepted shares should track within ±5% of the pool's expected hashrate for a `1 TH/s` ST-BOX. If burn-in passes, archive the working firmware version locally and pin it. If burn-in fails, you have a hardware issue independent of `2.2.0` and the next stop is the D-Central bench.

Stop DIY and ship to D-Central when: (a) the OTA rollback hangs at the same percentage on `3+` retries with all variables controlled; (b) the SD-card recovery completes the LED activity but the post-recovery miner cannot reach the dashboard or stays below `70%` of nameplate hashrate after `24 h`; (c) red+green LED brick state appears at any point during the downgrade; (d) the unit was port-forwarded to the public internet during the `2.2.0` window — pre-rollback malware injection is possible on any `2.2.0` miner with WAN exposure (see [Goldshell pool-hijack botware](https://d-central.tech/asic-troubleshooting/goldshell-botware-pool-hijack-infection/)) and you want clean-room reflash tooling; (e) you don't own a microSD adapter and don't want to source one for a single miner. Book through the [D-Central ASIC Repair service](https://d-central.tech/services/asic-repair/) — Canadian shop, no China-ship lottery, no `6`-week turnaround, real bench-validated `burn-*.img` archive for the BOX series.