Avalon 1566 – Bootloader Stuck

Hard-power-cycle at the PDU / breaker for a full `60` seconds. Wait for PSU bulk caps to discharge fully — not a Web UI reboot, not a power-button press. Power back up and watch the controller LED. If the controller now boots cleanly past U-Boot to a working Linux userland, you had a transient wedged-state event; log the cause and proceed to Prevention. Cheapest possible fix; sometimes a single AC cycle clears a stuck U-Boot retry counter on the 1566's MM3+ controller.

Confirm the `microSD` slot is empty before further triage. A leftover card from a previous recovery attempt — or a card with a wrong-model image such as a 1246, 1166 Pro, or 1466 recovery — may be holding the boot ROM in a bad state. Eject any card present, then retry power-up. If the controller now boots from `eMMC` cleanly, the leftover card was the entire problem.

Check your network. Confirm your router shows the miner's MAC requesting DHCP, even briefly, during the boot attempt. If the MAC appears for `5 – 10 seconds` then disappears, the kernel partially started and panicked (a category 4 partial-image signature). If the MAC never appears, the kernel never reached its network-init phase. Either way the next step is UART — the network signature alone narrows the fault category.

Inspect the controller board under bright light. Look for: blackened silkscreen near the `eMMC` package, swollen electrolytic capacitors, cracked SMT package faces, melted connectors. Visible damage near the `eMMC` chip points directly at chip-level (Tier 3) failure and saves DMM-probing healthy components.

Connect a USB-TTL adapter (FT232 / CH340 / CP2102) to the controller's UART header at `115200 8N1`. Verify pinout against your specific 1566 controller revision's silkscreen — the A13/A14/A15 controller has had pinout shuffles across revisions. Open a serial terminal (`screen`, `minicom`, `PuTTY`, `tio`) and start logging to a file before powering up. AC-cycle the chassis. Capture every byte from cold-boot to silence. The serial log is your single most valuable diagnostic artifact and tells you which root-cause category is active.

Read the U-Boot output and classify by signature: `Bad Magic Number` / `Bad Header Checksum` / `CRC error` after `Loading kernel from MMC` = kernel image corruption. `MMC read error` / `Failed to load partition` / `Bad block` = partition table damage. `Starting kernel ...` followed by silence = partial kernel image from interrupted flash. Signature verification error or model-identifier reject = wrong-model cross-flash. Intermittent `MMC` errors (sometimes boots, sometimes doesn't) = `eMMC` chip end-of-life (jump to Tier 3).

If U-Boot drops to the `=>` interactive prompt instead of auto-booting, type `env default -a` followed by `saveenv` and then `reset`. This restores default U-Boot environment variables and reboots. If the controller now auto-boots into a healthy Linux userland, U-Boot environment corruption was the cause — log the event and move to Prevention. If still stuck, continue to step 8.

Flash a 1566 / A15-specific `microSD` recovery image. Verify the model identifier on the image **before flashing** — cross-flashing a 1246, 1166 Pro, or 1466 image to a 1566 controller is a documented brick path via Canaan signature mismatch. Insert the card into the controller's `microSD` slot, power up, and watch UART for the recovery image's kernel coming up from card. The recovery userland reflashes `eMMC` automatically. This single procedure resolves categories 1, 2, 4, and most of 5 without any bench tooling.

If UART output indicated a wrong-model image was previously flashed, re-download the 1566 / A15 recovery image from a known-good source — `Canaan-Creative/avalon10-docs` references the official distribution path. Verify the image's model header before flashing. Reflash via `microSD` (step 8). The 1566 boot ROM accepts the correctly-signed image and completes recovery.

Keep a flashed `microSD` recovery card on the shelf labelled `1566 / A15` for the next event. A `$5` card per chassis revision is the cheapest insurance in the toolbox and turns a `5-day` ship-to-bench-and-back into a `30-minute` recovery. Every 1566 operator running more than two miners should have prepared cards per revision, labelled with model identifier and image build date.

From the U-Boot prompt (UART), run `mmc info` to query `eMMC` chip health. Low life-time / wear estimate values, repeated `mmc fail to send stop cmd` errors, or the chip not enumerating at all = `eMMC` is at end-of-life. The fix is chip replacement, not software recovery — every reflash attempt against a dying `eMMC` will succeed temporarily then fail again within hours to days. Stop DIY here unless you have BGA rework experience.

Source a matching `eMMC` chip — typical package is `153`-ball BGA, exact part graded against the 1566 controller revision (verify against silkscreen and donor 1346/1366/1446/1466/1566 boards). `eMMC` replacement is hot-air rework on a fine-pitch BGA — possible at home with a Quick 861DW or equivalent station, preheat plate, and steady hands, but tolerances are tight. Misalignment is a one-shot mistake on this package size.

After `eMMC` chip replacement, re-flash the 1566 / A15 image via `microSD` recovery (step 8). The new `eMMC` chip ships blank; the recovery image populates the partition table, kernel, MM3+ userland, and U-Boot environment in a single boot.

As a last DIY step, swap to a donor controller from a parts-graded 1346/1366/1446/1466/1566 board. The A13/A14/A15 generation shares controller topology, but Canaan's signed firmware checks chassis identifier and certain harnesses differ across revisions. A donor controller from a sibling A14 chassis (1446 / 1466) is the cleanest swap; A13 (1346 / 1366) usually works but verify firmware revision compatibility first. Do NOT drop in an A11/A12 (1166 Pro / 1246) controller — silicon differs.

Verify post-swap that the donor controller's MM3+ image matches the 1566's chassis identifier. If U-Boot rejects the donor on signature grounds, you may need to reflash the donor with the correct 1566 / A15 image via `microSD` recovery before it accepts the chassis. Document the donor's board-rev string from the silkscreen against the chassis it came from for future reference.

Stop DIY when `microSD` recovery succeeds but the controller fails again within hours or days — `eMMC` end-of-life requires chip replacement against a graded part, and most operators don't have the matching `eMMC` part on hand. D-Central's bench keeps graded `eMMC` chips, donor controllers, and matched parts across the A13/A14/A15 family specifically for this fault category, and can do the chip swap or controller swap in a single bench session rather than parts-chasing across forums.

Stop DIY when UART output suggests fuse-blow / signature-lock issues that prevent the correct 1566 image from being accepted. Canaan's signing chain is opaque from the operator side; bench-level diagnosis with a programmable load and a known-good reference 1566 controller is the only reliable path. Ship.

Stop DIY when you see physical damage on or near the `eMMC` package — cracked package, burnt pad, missing decoupling capacitor adjacent to the chip. Chip-level rework on damaged surrounding circuitry doubles the difficulty and is tight-tolerance hot-air work; the bench's preheat plate, magnification, and graded-parts inventory turn it into a routine repair instead of a `50/50` shot.

Ship safely. Pack the controller (or full chassis if you're not sure where the fault is) double-boxed with `5 cm+` of foam on every side. Include: serial number, observed symptoms, the UART capture log (text file printout), photos of any visible damage, service history (last open, last firmware flash, recent power events), and contact info. The UART log alone often saves an hour of bench reproduction time, which translates directly into lower repair cost.