NAND Flash

NAND flash is non-volatile solid-state memory — storage that survives a power cycle — and on most ASIC control boards it holds the entire firmware stack: bootloader, Linux kernel, and root filesystem. When a miner “loads firmware” at power-up, the SoC is reading from on-board NAND (or its packaged successor, eMMC). On Zynq-based Antminer control boards — the S9-generation platform — that means a 256MB raw NAND part (commonly a Winbond W29N02GZ) sitting beside 256MB of DDR3, read by the Zynq SoC the moment power arrives.

How the storage is laid out

The NAND on Zynq-era boards is divided into eight MTD partitions totaling 256MB, and the layout matters to anyone flashing firmware. The first partition (mtd0, 40MB) holds BOOT.bin and the kernel, verified against an RSA signature at boot. The second (mtd1, 32MB) holds the ramdisk — the root filesystem image — verified by SHA-256, and it is the partition custom firmware replaces. A small 2MB signature partition (mtd3) participates in the verification chain, which is why firmware-unlock procedures target it. Understanding this layout is the difference between a clean reflash and a board that boot-loops: the verification chain means you cannot just overwrite one piece and expect the rest to accept it.

Why NAND failures brick miners

NAND is erased and rewritten in blocks, and a firmware update reprograms those blocks in place. If power is lost mid-write — the single most common cause of a bricked control board on our bench — the NAND is left partially written and unbootable. The SoC then halts in the bootloader or loops endlessly with no valid filesystem to load. NAND also wears: each block tolerates a finite number of program/erase cycles, and raw NAND ships with (and develops) bad blocks that the software must map around. A board that has been reflashed dozens of times, or that runs hot for years, accumulates errors until one lands somewhere the bootloader cannot tolerate. This is one reason not to reflash firmware needlessly, and why boards of a certain age fail with corrupted-filesystem symptoms even though nothing was changed.

Recovery paths on the bench

Recovery depends on the platform. Zynq-era control boards expose an SD-card slot: the SoC can boot from a recovery image on SD, which then rewrites the NAND with a known-good image — the standard unbrick procedure. Newer platforms based on Amlogic and CVITEK SoCs (S19-family and S21-era boards) typically use eMMC and often lack an SD socket, so recovery means reflashing the storage directly or dropping onto the serial UART console to intervene at the bootloader. In stubborn cases, technicians read or write the flash out-of-circuit, or use JTAG where the SoC exposes it. Whatever the path, two rules hold: flash from stable power — a UPS is cheap insurance against creating the exact failure you are trying to fix — and flash a known-good image for the exact board revision, because control boards of the same miner model ship with different SoCs and layouts.

For the boot console that shows you exactly where a NAND failure stops the boot, see UART; for the managed-flash successor found on newer boards, see eMMC.