IceRiver Firmware Downgrade / Rollback Guide

Verify the unit is on a stable circuit and wired to Ethernet on the same subnet as the upload machine. Wi-Fi rollback is the most common cause of mid-flash failures — don't. If wired access to the miner location isn't immediate, run a `25 m` Cat6 patch cable temporarily for the rollback duration. Cable cost is a fraction of brick recovery cost.

Power-cycle the miner at the breaker for `60 seconds` before starting rollback to clear any wedged daemon state from the current firmware. Power on, wait `5 minutes` for clean boot, verify the web UI loads, verify pool-side hashrate is at expected level for current firmware. Establish a known-good baseline before flashing.

Open the web UI, navigate to `System` → `Upgrade`, select the archived `.bin` or `.tar` rollback image. Verify file size matches the published value from your archive source — a mismatched size means corrupted download and a guaranteed `Error 802`. Click `Upload`. Don't close the tab, navigate away, or let the machine sleep. Upload takes `2-5 minutes` on residential connections.

Wait for post-upload signature verification. The miner displays 'Verifying' or similar. If verification fails with `Error 801`, signed-bootloader anti-rollback is active — Tier 2 / Tier 3 only path. Stop, do not retry. Each retry adds wear and increases risk of corrupting both partition slots simultaneously. Move to Tier 3 directly.

If verification passes, the unit reboots into older firmware. Watch front-panel LEDs for full `D1`-`D4` startup cycle. After `5 minutes`, verify web UI loads, version string in `Status` → `System Info` matches the rolled-back version, hashrate climbing toward expected level for that firmware, and no `8xx` codes in `Status` → `Miner Log`. Soak-test 1 hour at default OC before declaring rollback successful.

If Tier 1 step 4 failed with `Error 801`, signed-bootloader anti-rollback blocks OTA. SD-card recovery is the supported escape because the bootloader's recovery routine has different signature handling than the OTA daemon. Tier 2 also handles cases where you don't trust OTA after a unit has already triggered `8xx` codes.

Download the recovery `.img` for your exact model AND hardware revision. If your archive provides only an upgrade `.bin` or `.tar`, you may need to wrap it — some KS models accept the upgrade image as recovery payload directly; others require a specific recovery format. Check IceRiver Discord `#firmware-archive` for model-specific guidance. Do not improvise — only use a documented format.

Write the recovery image to a microSD with `balenaEtcher`. Class 10 or higher, `8-16 GB`, freshly FAT32-formatted. Etcher will validate after writing — do not skip validation. A bad SD write produces a brick attempt that doesn't recover, and then you have nothing.

Power off at the breaker, wait `30 seconds`, insert microSD into the control-board slot (location varies by model — `KS3` family is on the long edge, `KS5L`/`KS5M` near Ethernet jack). Hold reset button. Power on while holding reset for `5 seconds`, release. Bootloader detects SD and begins recovery flash. LEDs cycle through full recovery sequence over `3-8 minutes`.

Do NOT power-cycle during recovery flash. Most common Tier 2 brick cause: operators get nervous because recovery looks slow, power-cycle to 'try again,' and corrupt eMMC mid-write. Wait the full `8 minutes` even if LEDs look stuck — reflash is happening even when front panel doesn't show progress. After 8 minutes, if no improvement, then power-cycle and inspect — but not before.

Get UART access. USB-to-TTL adapter (`CH340`, `CP2102`, or `FTDI`, `3.3 V` logic). Locate model-specific debug header. Connect `GND-GND`, `TX (board) → RX (adapter)`, `RX (board) → TX (adapter)`. Do NOT connect VCC — board has its own power. Open `PuTTY` / `screen` at `115200 8N1`. Power on. U-Boot output should appear within `3 seconds`.

Interrupt U-Boot autoboot by pressing any key during the 3-second countdown. At the `=>` prompt: `mmc info` to verify eMMC detected, `mmc part` to read current partition layout (save the output), `printenv` to dump U-Boot environment including `bootargs` and any version/anti-rollback variables (save that output too). This is your reference state before any modification.

Identify whether anti-rollback is enforced at bootloader level. In `printenv` output, look for variables like `bootcount`, `version_check`, `min_version`, `rollback_index`, or any version monotonic counter. If present and non-zero, bootloader is enforcing anti-rollback. Override depends on SoC and firmware: some allow `setenv min_version 0` + `saveenv`; others write to OTP / eFuse and override is impossible. Verify before attempting override — wrong `setenv` here can permanently lock bootloader into a bad state.

Manual partition reflash via U-Boot. Load the rollback image into RAM via `loadx` (Y-modem) or `tftpboot` (network), then `mmc write <RAM addr> <partition offset> <size>` for each partition (kernel, rootfs, recovery) at its expected eMMC offset. Reference the partition layout from the TARGET firmware version (the one rolling back TO), not current — offsets may differ between versions. Takes 10-20 min; UART link must stay connected throughout. Power-cycle when complete.

Verify post-rollback integrity. Run the unit `4 hours` at nameplate hashrate. Check `Status` → `Miner Log` for any `mmc` errors, partition-mount warnings, or kernel-side signature complaints about firmware components. Clean rollback = zero unusual log entries. A 'successful' rollback that nags about signatures or partitions is borderline — running but next firmware update from this state may behave unpredictably. Plan to re-flash forward to a clean state at next maintenance window.

Stop DIY and ship to D-Central when (a) `Error 801` persists across both OTA and SD-card recovery (eFuse-level lockout — past software recovery), (b) UART produces no output during Tier 3 (control-board fault), (c) rollback attempt bricks the unit and the bricked-firmware-recovery procedure doesn't recover it, (d) the unit is your sole production miner and bench-level work risk exceeds your tolerance.

D-Central bench process: UART-level eMMC dump and analysis, manual partition reflash with bench-stable power and verified-source archived images for every KS model and revision in our library, eFuse anti-rollback diagnosis (we don't always recover from eFuse lockout, but we identify it before further work), control-board-level firmware programming via external eMMC programmer when OTA and SD paths both fail, post-repair `24-hour` burn-in at nameplate hashrate before sign-off. Western retail bench in Quebec — no shipping to China, no Zeus-style trust gap.

Ship safely. Pack the control board (or whole unit) in anti-static bags, double-boxed with at least `5 cm` foam on every side. Include printed history: original firmware version, target rollback version, what triggered the rollback need (regression details), recovery steps already attempted, highest tier reached, result of each attempt. This shaves 30-45 min off our diagnostic time per unit, and we pass that savings directly into the repair quote.