IceRiver KS0 Overclocking Crash Recovery (xyys/tswift Firmware)

Hard power-cycle for 60 seconds at the wall plug. Not a soft reset — full mains kill for a full minute. Any half-written volatile state from the failed OC commit clears here. About 15% of OC-crash tickets recover at this step alone, especially when the crash was a wedged web-server thread on the OC firmware after a too-aggressive voltage step. Always try this before anything destructive.

If the web UI is reachable after the power cycle: open the OC firmware dashboard, set frequency back to the documented stock value for your model (KS0 stock `~1100 MHz` / KS0 Pro stock `~1180 MHz` — verify against `rdugan/iceriver-oc` README for current numbers), set voltage to stock (KS0 Pro stock `~770 mV`), commit, and reboot. If the unit holds stock cleanly for `30 minutes`, your OC simply exceeded silicon-lottery ceiling — proceed to Tier 2 to rebuild OC slowly. If the web UI is dead, skip to Step 4.

Catalogue the crash trigger before you touch anything else. Was it (a) mid-flash of the OC firmware itself, (b) a voltage / frequency commit that hung the web UI, (c) a reboot under hashing load after a successful commit, or (d) progressive crash that took hours to manifest? Each maps to a different recovery branch — mid-flash crashes need stock reflash, commit hangs usually recover with reset, load-induced reboots need OC backed off, and progressive crashes hint at marginal silicon that no reflash recovers.

Hold the reset button for the full `20 seconds` until the red status LED starts flashing, then release. Wait `5 minutes` untouched. The KS0 / KS0 Pro factory reset copies the factory-baked firmware partition over the active partition and reboots, wiping any OC profile. If your crash was config-level rather than rootfs-level, this returns the unit to stock and you can re-flash the OC firmware *carefully*. If nothing happens within 5 min, the active partition was already too corrupt to land the reset — go to Step 6.

Once back at stock and reachable, confirm network identity: check your router DHCP table for the unit's MAC, log into the IceRiver stock web UI on the assigned IP, verify firmware version matches the latest from `iceriver.io/firmware-download/` for your exact KS0 / KS0 Pro hardware revision. If you're more than two versions behind, update to current stock first — old stock plus aggressive OC is a brick magnet. Document the working config before any further OC retry.

Stock-firmware reflash via web UI: download the matching `KS0` or `KS0 Pro` stock firmware image from `iceriver.io/firmware-download/` for your exact hardware revision (revision printed on the chassis label — wrong revision bricks further). Upload via the standard firmware-update tab. Do NOT power-cycle or close the browser during the flash. The unit reboots once after a successful flash and returns at DHCP within 90 seconds. If the unit is unreachable after this, the active partition was too damaged for a stock OTA to land — proceed to Step 7.

Verify line voltage stability before any further flash retry. Multimeter on AC at the wall under load. KS0 / KS0 Pro `19 V 9.5 A 180 W` brick PSU expects clean `100-240 V` AC input. If line voltage sagged below `190 V` during your previous OTA attempts, that's why the flash bricked — and trying again on the same circuit will brick it again. Move to a stable circuit, ideally UPS-protected, before any flash retry. Residential evening-peak voltage sag is the silent cause of half the 'mid-OTA brick' tickets we see.

Re-flash the OC firmware ONLY after stock is confirmed working. Choose the right image: `pbv*` for KS0, `pbv*pro` for KS0 Pro, and NEVER cross-flash. The `rdugan/iceriver-oc` README explicitly states 'DO NOT install over the xyys (including tswift branded) firmware on KS0 Ultras or KS5* models' — KS0 Ultra is a different SoC and partition layout. Cross-flashing those is a guaranteed bench-only recovery.

Rebuild OC from stock with engineering discipline. The OC firmware applies clock changes in 25 MHz steps every 30 s, and voltage in 2 mV increments. Start at stock V/F. Raise frequency by 25 MHz, hold for `15 minutes`, watch hashrate, error count, and chassis temp. If stable, raise another 25 MHz. If hashrate plateaus or errors spike, hold at the previous step — that's this chip's silicon-lottery ceiling for that voltage. Raise voltage `10-20 mV`, retry the next clock step. Stop when temp exceeds `~70 °C` or wattage exceeds `~125 W` regardless of stability.

SD-card recovery boot if web UI never returns after stock reflash attempt. Download the official KS0 / KS0 Pro recovery image from `iceriver.io/firmware-download/` for your exact hardware revision. Write to a microSD card with `balenaEtcher`. Power off, insert SD, hold the reset button while powering on, keep holding for `5 seconds` after power-on, release. The bootloader detects the SD and reflashes from it over `3-8 minutes`. Don't power-cycle during this. Status LED behaviour during recovery is documented in the IceRiver firmware-download FAQ — match what you see against the FAQ before assuming failure.

Inspect for permanent damage if SD recovery fails. Phillips #2 to open chassis. Photograph the control board top and bottom under good lighting. Look for: scorched components near the PMIC (KS0 Pro at aggressive voltage is the highest-risk failure mode), swollen / leaking capacitors, lifted IC corners, PCB discolouration around the eMMC, brown / black around any of the 19 V / 5 V regulators. If anything visual is wrong, stop — this is hardware damage, not firmware corruption, and reflashing will not help. Ship to D-Central.

Get UART access to the KS0 / KS0 Pro control board for bootloader-level diagnostics. USB-to-TTL adapter (`CH340`, `CP2102`, or `FTDI`, `3.3 V` logic). Locate the 4-pin debug header near the Ethernet jack on the control board. 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. No output = BootROM or PMIC fault — Tier 4.

Interrupt U-Boot autoboot and inspect eMMC. Press any key during the 3-second countdown to drop to the U-Boot prompt. `mmc info` should report eMMC detected with capacity (`4 GB` typical on KS0). `mmc part` reads the partition table. If `mmc info` fails, the eMMC chip is damaged — common after sustained over-voltage on KS0 Pro — and reflash will not help. Ship to D-Central. If eMMC is fine, you can `loadx` (Y-modem) or `tftpboot` the recovery rootfs into RAM and `mmc write` it to the rootfs partition. Partition layout differs between KS0 and KS0 Pro — verify against the `rdugan/iceriver-oc` documented map for your exact revision before issuing `mmc write`.

Verify firmware integrity post-recovery. After any successful reflash, run the unit at stock V/F for a full hour and watch hashrate stability, chassis temp, and the `mining_daemon` log for `mmc` or `eMMC` write errors. A 'successful' reflash that produces I/O errors during normal operation means eMMC has marginal blocks — the brick will return, plan for control-board replacement at Tier 4. A unit that holds stock cleanly for 1 h is recovered. *Then* you can attempt OC again, slowly, with the lessons from this brick fresh.

Stop DIY and ship to D-Central when (a) the 20 s reset produces no red LED at all, (b) you see PMIC scorching or swollen caps, (c) UART produces no output at 115200 8N1 with verified wiring, (d) `mmc info` from U-Boot fails, (e) reflash succeeds but unit reboots under hashing load within 24 hours, (f) you flashed xyys / tswift on a KS0 Ultra by mistake, or (g) you've attempted SD-card reflash twice without success. Past those points, time and risk of further DIY exceed repair cost.

D-Central bench process for OC-bricked KS0 / KS0 Pro: UART access with stable bench power, full eMMC dump and analysis, eMMC chip desolder + external programmer reflash for irrecoverable cases, control-board swap with image transfer when chip replacement is uneconomic, full PMIC continuity testing for over-voltage damage, and post-repair 24-hour burn-in at stock hashrate before sign-off. Western retail bench — no shipping to China, no Zeus-style trust gap, Canadian quality control.

Ship the unit (or just the control board if you can pull it cleanly) in anti-static bags, double-boxed with ≥5 cm foam on every side. Include a printed crash history: original firmware (stock or `xyys` or `tswift` and which version), OC settings at time of crash (V/F values), trigger (mid-flash / commit hang / load reboot / progressive), recovery steps already attempted, highest tier reached. Saves D-Central 30+ minutes of diagnostic time per unit and that savings passes back directly in the repair quote.

Prevention: once recovered, document a *safe* OC profile and a hard ceiling. Write down the V/F that gave you stable hashing for 24 h. Set the ceiling 25 MHz / 10 mV below the highest stable point you tested. Don't chase the last 5% of hashrate — KS0 / KS0 Pro silicon-lottery ceilings vary so much per unit that the same image that gave one chip 160 Ghs will brick the chip next to it on the same shelf. Stable mining at 140 Ghs forever beats 160 Ghs for two days then a $250 repair.