Your S21 Nameplate Is Not Enough

A miner family name can start the search, but it cannot finish the route decision. Before installing firmware, identify the exact machine, board, build, archive, checksum, power condition and recovery path.

Two miners arrive with familiar names on their cases. Both belong to the S21 family. One is an air-cooled S21 XP. The other is an S21 XP Hyd. The words overlap, but the official manuals describe different machines, different cooling systems and different supporting hardware.

That is the practical reason a nameplate is the beginning of firmware identification, not the end.

This does not mean that every base S21 has several control-board routes. The point is narrower: a family name alone does not prove the exact artifact, version, checksum, installation readiness or recovery readiness for the machine in front of you.

A route is not correct because its filename contains a familiar family label. It is correct only when the exact model, control-board platform, current software state, supported installation method, exact archive, published checksum and recovery plan all point to the same machine.

Think of device identity as a stack

The machine has more than one identity field. Read the stack from top to bottom before downloading anything.

1. Exact model string

Record the full model exactly as the machine and manufacturer documentation present it. Do not shorten a suffix because it looks familiar. S21, S21 Pro+, S21 XP and S21 XP Hyd. are not interchangeable labels.

Official BITMAIN manuals identify S21 XP as air-cooled and S21 XP Hyd. as hydro-cooled with different supporting hardware. Similar family words do not establish one firmware route.

2. Control-board family or platform

VNISH currently organizes supported routes across four high-level control-board families: AML for Amlogic, XIL for Xilinx, CV for CVITEK and BB for BeagleBone. These codes describe the control platform. They are not performance grades.

The safest first check is the machine's web interface when it exposes the platform clearly. A readable board label or an existing, approved asset photo can provide a second clue. Physical inspection should be reserved for cases where it is necessary, permitted, electrically safe and performed by qualified personnel under the site's shutdown procedure. If the evidence is incomplete, ask support to confirm the route from the exact model and clear board evidence.

Do not infer that every machine called S21 ships with several board families. In the live VNISH catalog snapshot checked for this article, the base S21 name was not one of the model names mapped to more than one control-board route. The discipline still matters because operators handle mixed fleets, adjacent S21 variants, replacement controllers and machines with incomplete records.

3. Current firmware and build state

Capture the version and build shown by the web interface before changing it. Save a screenshot or export that includes the exact label and timestamp. The BITMAIN S21 XP manuals show where the current firmware version appears in the management interface. That record helps support distinguish a clean current state from an interrupted update, an older build or an unknown image.

4. Supported installation method

NAND, SD-card recovery, web upgrade and other documented methods are not synonyms. The exact route page should state the supported method for the exact model and board combination.

Keep three stages separate:

1. Installation changes the software image by a documented route.
2. Autotuning searches for an operating point after the software is running.
3. Stabilization is the observation period used to decide whether that operating point is acceptable.

A successful upload does not prove successful tuning. A completed tune does not prove long-term stability. Combining these stages into one green check hides useful failure information.

5. Exact archive name and size

Write down the full archive name as published. Also record the byte size when the official source provides it. A filename copied into a chat message can be truncated or attached to the wrong file. A size mismatch is a reason to stop before installation, even before computing a checksum.

6. Live SHA-256

Compute SHA-256 on the file that will actually be installed. Compare it character for character with the value displayed on the live official route or release manifest for that exact artifact. Store the value, source URL, access time, filename and size together.

Do not copy a hash from an old article, screenshot, search result, translated help page or another model's route. If the artifact details do not align, there is no tie-break by intuition. Stop, preserve the URLs and timestamps, then confirm the current exact route.

7. Board-specific recovery route and responsible person

Recovery belongs in the plan before installation. Record the method appropriate to the exact board and machine, the required files or media, the support path and the person authorized and qualified to execute it. Confirm that the recovery materials can be reached during the maintenance window.

The official S21 XP manuals warn that power must remain available during a firmware upgrade. One manual notes that a power failure before completion may leave the machine needing manufacturer service. Treat stable power as an installation prerequisite, not an afterthought.

Do not promise a one-click rollback or a universal recovery time. A route that exists in documentation can still depend on board state, access, media, site procedure and qualified hands.

The evidence card

If a field contains "probably," it is not resolved. Evidence is a value plus its source, not a confident memory.

How much ambiguity is actually in the catalog?

The live VNISH control-board catalog checked on August 21, 2026 listed 47 supported model names and 75 build routes across four board families. Fourteen of those 47 model names appeared on more than one board. Those repeated names accounted for 42 of the 75 builds.

This is a catalog measurement, not a claim that every miner family is ambiguous. It explains why a workflow designed for a mixed fleet should always include the board field. The control-board page lists the exact repeated names and current route count. Those numbers can change as support expands, so the live catalog remains the authority on publication day.

A current S21 example: keep the artifact tuple intact

The VNISH 1.3.5 release manifest checked for this guide lists a base S21 route as AML, NAND, version 1.3.5. It names the archive vnish-s21-aml-nand-v1.3.5.tar.gz and reports 21,541,929 bytes, displayed as 20.5 MB.

That evidence does not authorize generalizing the route to every product whose name begins with S21. It also does not authorize using a checksum remembered from another page.

The verification page uses a worked example for vnish-s21-aml-nand-v1.3.4.tar.gz, reported as 21,541,837 bytes. The 1.3.4 example and current 1.3.5 release are different versioned files with different byte sizes. Each correctly has its own checksum. An older hash is not an alternative value for a newer artifact.

Treat the record as one tuple: version, exact filename, byte size, SHA-256, source URL and access time. If any one element belongs to a different artifact, stop the comparison and rebuild the record from the current exact route. This guide does not print a literal hash so that readers must retrieve it from the live source at download time.

The current VNISH install page for S21 Pro+ AML NAND is explicitly for S21 Pro+, AML and NAND. Its sequence can inform the workflow, but the page must not be relabeled as an installation route for the base S21.

The seven-step canary protocol

1. InventoryAssign one canary and one comparable untouched peer. Record asset ID, exact model, serial where policy permits, control board, PSU, cooling context, network, pool and responsible technician. Do not begin with a whole row.
2. BaselineCapture the current build, profile, wall power, inlet condition, device temperatures, fan state, local hashrate, pool-accepted work, rejects, stale shares, errors, resets and uptime over a useful matched window. A baseline must be long enough to show ordinary variation. Use the related S21 thermal baseline guide before changing a power profile.
3. IdentifyComplete the identity stack. Confirm the exact model string, board family and current build from direct evidence. If the interface, label, asset record and route page do not align, hold the machine and escalate the evidence to support.
4. Resolve the live routeOpen the current control-board map, firmware catalog and 1.3.5 release page. Select the route that names the exact machine and platform. Use an exact install page only when its model, board, method and current release all match. Do not navigate from a search snippet alone.
5. Download and verifyDownload the archive from the resolved official route. Record its version, exact name, byte size, source URL and access time. Compute SHA-256 locally. Use the verification guide for command syntax and the meaning of the result, not as the current 1.3.5 route catalog. Compare the result with the value published for the same exact artifact on the current release or build route.
6. Prepare recovery, then installConfirm stable power, access, maintenance authority, board-specific recovery materials, the support route and the named recovery owner. Only then use the documented installation method for the exact route. Installation ends when the intended image boots and its identity can be confirmed. Autotuning and stabilization have not yet been proven.
7. First boot, tune and observe before scaleConfirm the reported model, board state, build, expected hashboards, fans, temperatures, errors and network connection before raising operating targets. Apply only site-approved limits. Observe wall power, accepted work, rejects, stale shares, thermals, errors, resets and uptime alongside the untouched peer.

Record the decision as GO, HOLD or STOP. GO means the canary may proceed to the next approved observation stage, not that the entire fleet is cleared. HOLD means evidence is incomplete or still stabilizing. STOP means a defined limit, fault, identity conflict or recovery concern has been reached.

The useful outcome is a repeatable decision

VNISH Global is the official distribution, documentation and support ecosystem for VNISH firmware. That makes current route documentation central to the decision, but it does not replace site responsibility or qualified technical judgment.

Aftermarket firmware and profile changes can alter power draw, temperature, stability, component stress, hardware life and manufacturer warranty or support conditions. Results vary with the exact model, control board, PSU, machine silicon and condition, cooling, ambient environment, power quality, network, pool, settings and workload. No compatibility, performance, savings, uptime, recovery or financial result is guaranteed.

The right first action is small. Choose one machine. Complete its identity card. Resolve the exact live build and checksum. Prepare a board-specific recovery route with a responsible person. Then run one measured canary inside site-approved limits and compare it with an untouched peer before scaling.

The nameplate starts the question. The evidence stack answers it.

Compare this guide with six dated, source-linked VNISH field reports before turning one operator result into a fleet assumption. Open the independent field reports.

Published by VNISH Global. This field guide does not promise a compatibility, performance or financial result.