Control Board Architecture in ASIC Miners

How ASIC miner control boards work — SoC platforms, network interfaces, hashboard communication, firmware storage, and common failure modes explained.

Introduction

The control board is the brain of every ASIC miner. While hashboards do the heavy computational lifting of hashing, it is the control board that orchestrates every aspect of the mining operation — distributing work from pools, managing chip configurations, monitoring temperatures and fan speeds, and exposing a management interface to the operator.

Understanding control board architecture is essential for anyone diagnosing miner issues, replacing failed components, or developing custom firmware. Many common miner failures — network drops, hashboard detection problems, firmware corruption — originate from the control board rather than the hashboards themselves.

What the Control Board Does

At its core, the control board is a small embedded Linux computer with a very specific job: keep the miner hashing as efficiently as possible. It handles several critical functions simultaneously.

Job Management

The control board runs mining software (such as CGMiner, BOSminer, or proprietary firmware) that:

Connects to a mining pool via the Stratum protocol over TCP
Receives block header templates (jobs) from the pool
Distributes work across all connected hashboards and their ASIC chips
Collects valid nonces (solutions) found by chips and submits them back to the pool
Tracks share acceptance rates and adjusts difficulty as needed

Pool Server ←→ [Stratum TCP] ←→ Control Board ←→ [UART/SPI] ←→ Hashboards
                                      ↕
                              Web UI / SSH / API

Monitoring and Protection

The control board continuously monitors the health of every subsystem:

Temperature sensors on each hashboard (via I2C or the communication bus)
Fan speeds through tachometer feedback signals
Voltage and power draw (on models with onboard ADCs)
Chip response rates — detecting missing or malfunctioning chips
Network connectivity — reconnecting to pools after disconnections

When thresholds are exceeded, the control board takes protective action: ramping up fans, reducing clock speeds, or shutting down hashboards entirely to prevent damage.

The control board typically runs a stripped-down Linux distribution (often based on OpenWrt or Buildroot) with just enough userspace to run the mining daemon, a web server, and basic networking tools.

Pool Communication

The Stratum protocol is the standard communication method between miners and pools. The control board maintains a persistent TCP connection and handles:

Subscription: registering the miner with the pool
Job notification: receiving new block templates when the network finds a block
Share submission: sending valid nonces back to the pool
Difficulty adjustment: adapting to the pool's requested difficulty level

Most control boards support configuring up to three pool URLs — a primary, secondary, and tertiary — providing failover in case a pool goes offline.

CPU/SoC Platforms

Different miner manufacturers use different System-on-Chip (SoC) platforms for their control boards. The choice of SoC affects processing power, available peripherals, boot mechanisms, and firmware architecture.

Used by: Bitmain Antminer (S9, S17, S19, S21 series and most other models)

The Xilinx Zynq is a hybrid SoC that combines a dual-core ARM Cortex-A9 processor with FPGA fabric on the same die. This is a deliberate design choice by Bitmain — the FPGA fabric handles high-speed, timing-critical communication with hashboards, while the ARM cores run Linux and the mining software.

Feature	Specification
CPU	Dual ARM Cortex-A9 @ 667 MHz
FPGA	Artix-7 programmable logic
RAM	256–512 MB DDR3 (on board)
Peripherals	UART, SPI, I2C, GPIO, Ethernet MAC
Boot	NAND flash or SPI NOR flash

The FPGA fabric is particularly valuable because it can implement custom serial protocols with precise timing that would be difficult to achieve in software alone. Bitmain uses this to manage the high-speed UART communication with dozens of ASIC chips across multiple hashboards simultaneously.

The Zynq's FPGA bitstream is loaded during boot. Corrupted NAND flash can prevent the FPGA from initializing, which means the control board powers on but cannot communicate with any hashboard — a common misdiagnosis as a "dead hashboard" problem.

Used by: Some MicroBT Whatsminer models (M20, M30 series), various smaller manufacturers

The Allwinner H3 and H6 are application processors originally designed for media players and single-board computers (like the Orange Pi). They are cost-effective and well-supported by the Linux kernel.

Feature	Specification
CPU	Quad-core ARM Cortex-A7 (H3) / Cortex-A53 (H6)
Clock	1.2 GHz (H3) / 1.8 GHz (H6)
RAM	512 MB – 1 GB DDR3
Peripherals	UART, SPI, I2C, GPIO, Ethernet MAC, USB
Boot	SD card, SPI NOR, eMMC

Without dedicated FPGA fabric, these boards handle hashboard communication entirely in software through kernel drivers or userspace daemons. The quad-core design provides enough processing headroom to manage communication timing through dedicated CPU cores.

Used by: Some Whatsminer variants, Canaan Avalon (certain models)

The Amlogic S905 is another media-oriented SoC repurposed for mining control. It offers strong processing capability and flexible boot options.

Feature	Specification
CPU	Quad-core ARM Cortex-A53 @ 1.5 GHz
RAM	1–2 GB DDR3/DDR4
Peripherals	UART, SPI, I2C, USB, Ethernet MAC
Boot	eMMC, SD card, SPI NOR
GPU	Mali-450 (unused in mining)

The S905's higher clock speed and 64-bit architecture provide more headroom for running management software, web interfaces, and monitoring daemons concurrently. The GPU is typically unused in mining applications.

Regardless of the SoC platform, all control boards run some variant of embedded Linux. The differences lie in boot mechanisms, peripheral drivers, and how hashboard communication is implemented (FPGA-assisted vs. pure software).

Network Interface

Every ASIC miner needs a network connection to communicate with mining pools. The control board provides this connectivity.

Ethernet

Ethernet is the primary (and often only) network interface on ASIC miners. Most control boards include:

A dedicated Ethernet PHY chip (such as Realtek RTL8211 or Micrel KSZ9031) connected to the SoC's MAC
An RJ45 connector with integrated magnetics and status LEDs
Speed: 100 Mbps (Fast Ethernet) on older models, 1 Gbps (Gigabit) on newer ones

The Ethernet PHY converts between the SoC's digital MAC interface (typically RGMII or RMII) and the analog signals on the cable. PHY failures are a well-known control board issue — the miner powers on and appears to work, but cannot establish a network link.

SoC MAC ←→ [RGMII/RMII] ←→ Ethernet PHY ←→ [MDI] ←→ RJ45 Connector ←→ Network

WiFi (Select Models)

Some miner models include WiFi capability, usually through a USB or SDIO wireless module. WiFi is less common because:

Mining generates minimal network traffic (a few KB/s), so WiFi bandwidth is not the issue
Reliability is critical — a dropped connection means lost hashing time and revenue
Large mining farms use wired infrastructure exclusively

When WiFi is present, it is typically used for initial setup (the miner broadcasts an AP for configuration) rather than as the primary mining connection.

Never rely on WiFi as the primary network connection for production mining. Even brief disconnections cause stale shares, and in large deployments, WiFi congestion becomes a significant problem.

Network Configuration

Control boards typically support:

DHCP (default): automatic IP assignment from the network router
Static IP: manually configured through the web UI or configuration file
mDNS: some firmware versions advertise the miner via Bonjour/mDNS for easier discovery

Mining farm management tools (like Awesome Miner, Foreman, or custom scripts) scan IP ranges to discover and manage fleets of miners.

Communication Interfaces to Hashboards

The control board communicates with hashboards through dedicated serial interfaces. This is where jobs are dispatched, nonces are collected, and chip registers are read or written.

UART (Bitmain)

Bitmain's Antminer series uses UART (Universal Asynchronous Receiver/Transmitter) to communicate with hashboards. Each hashboard typically gets its own UART channel.

Parameter	Typical Value
Baud rate	115,200 – 3,000,000 bps
Data bits	8
Parity	None
Stop bits	1
Flow control	None

The UART lines connect through a multi-pin connector on the hashboard that also carries I2C (for temperature sensors and EEPROM), voltage enable signals, and sometimes additional GPIO lines.

Control Board                    Hashboard Connector
┌──────────┐                    ┌──────────────────┐
│ UART TX  │───────────────────→│ RX (to chips)    │
│ UART RX  │←───────────────────│ TX (from chips)  │
│ I2C SDA  │←──────────────────→│ SDA (EEPROM/temp)│
│ I2C SCL  │───────────────────→│ SCL              │
│ VEN      │───────────────────→│ Voltage Enable   │
│ RST      │───────────────────→│ Reset            │
│ GND      │←──────────────────→│ GND              │
└──────────┘                    └──────────────────┘

Damaged UART connectors are one of the most common control board failures. Bent pins, corrosion, or loose connections cause intermittent hashboard detection failures. Always inspect connectors carefully during troubleshooting.

SPI (Some Models)

Some miner designs use SPI (Serial Peripheral Interface) instead of or in addition to UART for hashboard communication. SPI offers higher throughput and a synchronized clock, which can be advantageous for high-chip-count boards.

Signal	Direction	Purpose
MOSI	Controller → Hashboard	Job data and register writes
MISO	Hashboard → Controller	Nonce responses and register reads
SCLK	Controller → Hashboard	Clock signal
CS	Controller → Hashboard	Chip/board select

Connectors and Cabling

The physical connection between the control board and hashboards varies by manufacturer:

Bitmain: Uses flat ribbon cables or direct board-to-board pin headers (18–20 pin)
MicroBT (Whatsminer): Ribbon cables with latching connectors
Canaan (Avalon): Ribbon cables, sometimes with multiple connectors per board

The connector carries power enable signals, serial data, I2C for EEPROM and sensors, and ground references. Cable quality and connector condition are critical — a single intermittent connection can cause a hashboard to drop in and out of detection.

For a deeper dive into these serial protocols, see UART, SPI & I2C Explained.

EEPROM and Configuration Storage

ASIC miners store configuration data in multiple locations, each serving a different purpose.

Hashboard EEPROM (AT24C02)

Each hashboard contains a small EEPROM — typically an AT24C02 (2 Kbit / 256 bytes) — connected via I2C. This chip stores board-specific identity and calibration data:

Data	Purpose
Serial number	Unique board identification
Chip count	Number of ASIC chips on the board
Voltage calibration	Per-domain voltage trim values
Frequency calibration	Optimal clock settings for this specific board
Manufacturing date	Production tracking
Hardware revision	PCB version identification

The control board reads this EEPROM during initialization to determine what type of hashboard is connected and how to configure it. This is the mechanism that allows a control board to automatically detect and adapt to different hashboard models.

Control Board I2C Bus
       │
       ├── Hashboard 1 EEPROM (0x50)
       ├── Hashboard 2 EEPROM (0x51)
       └── Hashboard 3 EEPROM (0x52)

The AT24C02 uses I2C addresses in the range 0x50–0x57. The specific address is set by tying the A0–A2 pins high or low on each hashboard. This allows the control board to distinguish between multiple boards on the same I2C bus.

Control Board Configuration

The control board stores its own configuration (pool URLs, fan settings, network config) in:

NAND flash: a dedicated partition on the same flash that holds the firmware
SD card: on models that boot from SD, configuration files live alongside the OS
NOR flash: a small SPI NOR chip may hold bootloader settings and MAC addresses

Configuration is typically stored as plain-text files (often JSON or custom key-value formats) in a writable filesystem partition that persists across reboots.

For more about hashboard identification and EEPROM usage, see How Hash Boards Work.

Firmware Storage

The firmware — comprising the bootloader, Linux kernel, root filesystem, and mining application — must be stored in non-volatile memory that survives power cycles.

Used by: Bitmain Antminer (most models), some Whatsminer models

NAND flash provides large capacity (128 MB – 1 GB) at low cost. The firmware is stored in multiple partitions:

Partition	Contents	Size
Boot	U-Boot bootloader	1–4 MB
Kernel	Linux kernel + device tree	4–8 MB
Root FS	Root filesystem (SquashFS)	16–64 MB
Data	Configuration, logs	16–64 MB
Recovery	Backup firmware image	16–64 MB

NAND flash has a limited number of write cycles (typically 100,000 per block) and requires wear leveling and bad block management. The Linux kernel's UBI/UBIFS layer handles this transparently.

NAND corruption is one of the most common control board failures. Power loss during a firmware update is the primary cause. Symptoms include boot loops, kernel panics on the serial console, or the miner refusing to start. Many control boards can be recovered by reflashing via SD card or TFTP.

Used by: Bootloader storage on most platforms, primary storage on some compact designs

SPI NOR flash is smaller (4–32 MB) but more reliable than NAND. It is often used to store the bootloader (U-Boot) even when NAND is the primary storage.

Advantage	Detail
Reliability	1,000,000+ write cycles
Speed	Fast random reads, suitable for XIP (execute in place)
Simplicity	No bad block management needed
Limitation	Small capacity, expensive per MB

On some compact miner designs, the entire firmware fits in a single SPI NOR chip, eliminating NAND flash entirely. This results in a more reliable system at the cost of limited storage space.

Used by: Some Whatsminer models, Avalon controllers, development/recovery scenarios

SD card boot provides the most flexible firmware management — swapping firmware is as simple as swapping cards. The SD card contains a standard partition layout:

FAT32 partition: bootloader and kernel
ext4 partition: root filesystem
ext4 partition: data and configuration

Some miners use SD cards as the primary boot medium, while others only support SD boot for firmware recovery when the onboard NAND is corrupted.

When using SD card boot for recovery, ensure you use a high-quality, industrial-grade SD card. Consumer-grade cards have much lower write endurance and can fail within months of continuous use in the high-temperature environment inside a miner.

Firmware Update Process

Firmware updates typically follow one of these paths:

Download: The new firmware image is downloaded to the miner via the web UI, or pushed via SSH/TFTP.

Verification: The firmware image's checksum (MD5 or SHA-256) is verified against the expected value to ensure integrity.

Flash: The new image is written to the target partition (NAND, NOR, or SD). On dual-partition systems, the inactive partition is written while the active one continues running.

Reboot: The system reboots into the new firmware. If the update fails, the bootloader may fall back to the recovery partition.

Web UI and Management Interface

Every modern ASIC miner includes a web-based management interface served by the control board. This is the primary way operators interact with their miners.

Mining Software Backends

The web UI sits on top of the mining software daemon that controls the actual hashing operation:

Software	Used By	License
CGMiner	Bitmain (stock), many others	GPL (modified forks)
BOSminer	Braiins OS	GPL
SGMiner	Some altcoin miners	GPL
BTMiner	Whatsminer (stock)	Proprietary

The web interface communicates with the mining daemon through a local API (typically a JSON-RPC socket) to read status and push configuration changes.

Common Web UI Features

Most miner web interfaces provide:

Dashboard: real-time hashrate, temperature, fan speed, and uptime
Pool configuration: setting pool URLs, worker names, and passwords
Network settings: IP configuration, DNS, hostname
System information: firmware version, hardware model, MAC address
Hashboard status: per-board hashrate, chip count, temperature readings
Fan control: manual or automatic fan speed profiles
Firmware upgrade: upload and flash new firmware images
System actions: reboot, reset to factory defaults, export/import configuration

Third-party firmware like Braiins OS, VNish, and LuxOS replace the stock web UI with enhanced versions that offer additional features such as autotuning, per-chip frequency control, and detailed performance analytics.

Accessing the Web UI

The web UI is typically accessible at:

http://<miner-ip-address>/ (default HTTP port 80)
Default credentials vary by manufacturer (e.g., root / root for many Antminers)

SSH access is also available on most miners for advanced troubleshooting and direct interaction with the mining daemon.

LED Indicators

Control boards include LED indicators that provide visual status information without needing network access. While exact patterns vary by manufacturer, common conventions exist.

LED State	Meaning
Solid green	Normal operation — mining actively
Blinking green	Booting or initializing hashboards
Solid red	Critical error — check web UI for details
Blinking red	Hardware fault detected (overtemperature, missing board)
Alternating red/green	Firmware update in progress
No LEDs	No power, dead control board, or blown fuse

Never power off a miner while LEDs indicate a firmware update is in progress (typically alternating red/green). Interrupting a flash write almost always corrupts the firmware and may require a recovery procedure to fix.

Some control boards also have per-hashboard LEDs or status LEDs for network link and activity. The Ethernet jack's built-in LEDs show link status (solid = link up) and activity (blinking = data transfer).

Fan Control

The control board manages all cooling fans through PWM signals and monitors their speed via tachometer feedback.

PWM Output

Fans are controlled using Pulse Width Modulation (PWM), where the duty cycle determines the fan speed:

Duty Cycle	Approximate Speed
0%	Fan off (not recommended)
25%	Minimum speed
50%	Medium speed
75%	High speed
100%	Maximum speed (full voltage)

The PWM signal is typically a 25 kHz square wave generated by a hardware timer on the SoC. The mining software adjusts the duty cycle based on the temperature readings from hashboard sensors.

Tachometer Input

Each fan provides a tachometer signal — a square wave whose frequency is proportional to the fan speed (typically 2 pulses per revolution). The control board reads this signal to:

Verify fans are spinning: a fan reporting 0 RPM triggers an immediate shutdown or alarm
Detect degraded fans: abnormally low RPM at a given duty cycle suggests bearing wear or obstruction
Log fan health: tracking RPM trends over time helps predict impending fan failures

Control Board                         Fan
┌──────────┐                    ┌──────────┐
│ PWM Out  │───────────────────→│ PWM In   │
│ TACH In  │←───────────────────│ TACH Out │
│ 12V      │───────────────────→│ +12V     │
│ GND      │←──────────────────→│ GND      │
└──────────┘                    └──────────┘

Automatic Fan Profiles

The firmware implements a temperature-to-fan-speed mapping, often called a "fan curve." A typical profile might look like:

Below 40C: 30% PWM (quiet operation)
40–60C: linear ramp from 30% to 70%
60–80C: linear ramp from 70% to 100%
Above 80C: 100% PWM + reduce chip frequencies
Above 90C: emergency shutdown of affected hashboards

Third-party firmware often provides more granular control over fan profiles, including the ability to set fixed speeds, custom temperature thresholds, and per-hashboard fan response curves.

Common Control Board Failures

Understanding common failure modes helps you diagnose problems faster and determine whether a repair or replacement is more cost-effective.

Corrupted NAND Flash

Symptoms: boot loops, kernel panic on serial console, miner stuck on boot screen, web UI inaccessible after power loss during update.

Cause: power interruption during firmware write, NAND wear-out on older boards, or failed firmware update.

Resolution:

Try SD card recovery boot if the model supports it
Reflash via TFTP using a serial console connection to U-Boot
Replace the NAND chip (requires BGA rework equipment)

Dead Ethernet PHY

Symptoms: no link LED on the Ethernet jack, miner boots but has no network connectivity, link LED solid but no data transfer.

Cause: ESD damage, power surge, or component failure. The PHY chip is often the most ESD-sensitive component on the control board.

Resolution:

Test with a known-good cable and switch port
Check PHY chip for physical damage (cracks, burn marks)
Replace the PHY chip if confirmed faulty (requires soldering skills)
Replace the entire control board if PHY replacement is not feasible

Damaged UART Connector

Symptoms: one or more hashboards not detected, intermittent hashboard dropouts, hashboard detected but showing 0 chips.

Cause: repeated insertion/removal of hashboard cables, physical damage, corrosion in humid environments.

Resolution:

Inspect connector pins for bending, breakage, or oxidation
Clean connectors with isopropyl alcohol and a soft brush
Resolder or replace damaged connectors
Check the ribbon cable for tears or kinks

SD Card Failure

Symptoms: (on SD-boot models) miner fails to boot, intermittent reboots, filesystem corruption errors in logs.

Cause: consumer-grade SD cards failing under continuous read/write in high-temperature environments.

Resolution:

Replace with an industrial-grade SD card rated for high endurance
Reflash the firmware image onto the new card
Consider enabling read-only root filesystem to extend card life

Other Common Issues

Failure	Symptom	Likely Cause
Clock crystal failure	Miner boots but all timings are wrong	Damaged 24/25 MHz crystal oscillator
RAM failure	Random crashes, kernel panics	Faulty DDR chip or poor solder joint
Voltage regulator failure	Board does not power on at all	Failed DCDC converter for SoC core voltage
Overheating SoC	Thermal throttling, slow web UI	Heatsink detached, thermal paste dried out

Before replacing a control board, always check the simplest things first: power supply voltage, cable connections, and network infrastructure. Many "dead control board" situations turn out to be a bad cable or a failed switch port.

Key Takeaways

The control board is the central coordinator of an ASIC miner, managing pool communication, job distribution, monitoring, and fan control.
Different manufacturers use different SoC platforms (Xilinx Zynq, Allwinner, Amlogic), each with distinct boot mechanisms and peripheral architectures.
Hashboard communication happens over UART (Bitmain) or SPI, through multi-pin connectors that also carry I2C, voltage enable, and reset signals.
Each hashboard has an AT24C02 EEPROM storing identity and calibration data that the control board reads during initialization.
Firmware is stored on NAND flash, SPI NOR flash, or SD cards — each with different reliability characteristics and recovery procedures.
The web UI (backed by CGMiner, BOSminer, or proprietary daemons) is the primary management interface for operators.
Fan control uses PWM output and tachometer feedback to maintain safe operating temperatures.
The most common control board failures are NAND corruption, Ethernet PHY death, damaged UART connectors, and SD card wear-out.

Apply This Knowledge

Now that you understand control board architecture, you can explore related topics to deepen your knowledge:

Understand hashboard communication in depth: Learn how the control board talks to ASIC chips at the protocol level in UART, SPI & I2C Explained.

Learn how hashboards work: See how the other half of the system operates — power delivery, chip arrays, and thermal management — in How Hash Boards Work.

Explore power delivery: Understand the voltage regulation that both the control board and hashboards depend on in Power Delivery Systems.

Study firmware and software: Learn about the mining software stack, custom firmware options, and how to safely update or replace firmware in Firmware & Software Overview.

Practice diagnostics: Apply your knowledge of control board architecture to real troubleshooting scenarios in Diagnostic Procedures.

Control Board Architecture in ASIC Miners

On this page