PiAxe – BM1366 Serial UART Communication Error

Run `sudo raspi-config`. Go to Interface Options -> Serial Port. Answer NO to `Would you like a login shell over serial?` then YES to `Would you like the serial port hardware to be enabled?`. Exit and reboot. This single move disables the serial-getty login prompt that otherwise holds `/dev/ttyAMA0` exclusive and blocks pyminer from opening it. Covers the majority of fresh-install failures on Pi 2 and older models.

Verify the boot result with `ls -l /dev/serial0` and `cat /proc/device-tree/model`. On Pi 2 or Pi 1 the symlink points at `/dev/ttyAMA0` and you are done. On Pi 3/4/5/Zero 2 W it usually points at `/dev/ttyS0` (mini-UART) because Bluetooth has the PL011. Note which Pi model you have - Tier 2 steps diverge by model.

Add your user to `dialout`. Run `groups $USER`. If `dialout` is missing, run `sudo usermod -aG dialout $USER` then log out fully and log back in (or run `newgrp dialout` in the current shell). This grants non-root access to `/dev/serial0`. Without it, pyminer hits PermissionError on open even when the port is otherwise free.

Start pyminer and watch logs: `sudo systemctl start pyminer && sudo journalctl -u pyminer -f`. Within 10 seconds you should see `BM1366 serial open OK` and `BM1366 chip response OK`. If it still fails, the port is contended by Bluetooth or an overlay - proceed to Tier 2. If it opens but you see intermittent framing errors, you are on mini-UART and need the Pi 3/4/5 fix in Tier 2.

Power-cycle the PiAxe cleanly: shutdown with `sudo shutdown -h now`, unplug Pi USB-C or barrel jack AND the BM1366 carrier 12V input, wait 30 seconds, plug Pi in first, wait for boot, then plug the BM1366 12V. This guarantees the ASIC sees a clean reset sequence before pyminer attempts to talk to it, avoiding stale-state init failures.

Reclaim the PL011 UART from Bluetooth on Pi 3/4/5/Zero 2 W. Edit `/boot/firmware/config.txt` (Bookworm) or `/boot/config.txt` (Bullseye) with `sudo nano`. Add the line `dtoverlay=disable-bt` (removes Bluetooth entirely, cleanest) OR `dtoverlay=miniuart-bt` (keeps Bluetooth on mini-UART, PiAxe gets PL011). Save. Run `sudo systemctl disable hciuart`. Reboot. Re-run `ls -l /dev/serial0`; it should now resolve to `/dev/ttyAMA0`.

Disable any lingering serial-getty services manually. Run `sudo systemctl disable --now serial-getty@ttyAMA0.service` and `sudo systemctl disable --now serial-getty@ttyS0.service`. raspi-config on early Bookworm releases occasionally leaves these active even after answering No to the login-shell prompt. Confirm with `systemctl list-units --type=service | grep serial-getty` - should be empty.

Audit your overlays. Run `grep -E '^dtoverlay|^dtparam' /boot/firmware/config.txt`. Any overlay that touches GPIO14/15 (camera overlays, certain GPS/LoRa HATs, `dtoverlay=uart0,txd0_pin=14,rxd0_pin=15` variants) preempts the UART. Comment out the conflicting line with a `#`, save, reboot. You cannot use a HAT that needs GPIO14/15 and run PiAxe on the same Pi - pick one.

Verify pyminer config uses `/dev/serial0` and NOT a hardcoded `/dev/ttyAMA0` or `/dev/ttyS0`. `cd ~/piaxe-miner && cat config.yaml` (or whatever config file your branch uses). Edit if hardcoded. `/dev/serial0` is a stable symlink that follows your disable-bt / miniuart-bt config - hardcoded paths break silently when you change overlays.

Fix the Bookworm pip PEP 668 trap if you hit `error: externally-managed-environment` during `pip3 install -r requirements.txt`. Create a virtualenv: `python3 -m venv ~/piaxe-venv && source ~/piaxe-venv/bin/activate && pip install -r requirements.txt`. Update your systemd unit `ExecStart` to use `~/piaxe-venv/bin/python pyminer.py`. Do NOT use `--break-system-packages` - it contaminates system Python and bites you six months later.

Stabilize baud rate on mini-UART deployments where you cannot use PL011. Set the CPU governor to performance: `sudo cpufreq-set -g performance`, persist with `echo 'GOVERNOR="performance"' | sudo tee -a /etc/default/cpufrequtils`. Mini-UART derives its baud from the VPU core clock, so CPU throttling drifts the baud and produces framing errors at 115200. Performance governor locks the clock and stabilizes the UART.

Capture a UART-level logic trace. Connect a USB logic analyzer (Saleae Logic 8 or $15 clone) to Pi GPIO14 (TX) and GPIO15 (RX), sample at 1 MHz, decode as serial at 115200 baud 8N1. Record pyminer boot and first ASIC init exchange. A healthy trace shows `55 aa` preamble bytes on TX from Pi, response frames with `aa 55` preamble on RX from BM1366 within ~1 ms. Silent RX = chip unresponsive. Garbled RX = baud drift or noise.

Build a custom dtoverlay if you are running a multi-PiAxe farm on a single Pi with UART multiplexing. Copy `/boot/overlays/disable-bt.dtbo` as reference, write a custom overlay that explicitly pins GPIO14/15 to PL011 and enables flow control on GPIO16/17 if you have that wired. Compile with `dtc -@ -I dts -O dtb -o custom-piaxe.dtbo custom-piaxe-overlay.dts`. Install to `/boot/overlays/` and reference in config.txt.

Harden the systemd unit against boot-order races. Edit `/etc/systemd/system/pyminer.service`: set `After=network-online.target systemd-udev-settle.service`, `Wants=network-online.target`, `Restart=on-failure`, `RestartSec=10s`. This prevents pyminer from starting before `/dev/serial0` is actually created by udev, a surprisingly common cause of 'works on manual restart but not on boot' reports. `sudo systemctl daemon-reload && sudo systemctl enable pyminer`.

Escalate to D-Central's open-source / pleb-mining queue when Tier 1-3 passes every gate but the BM1366 still produces zero RX. We triage PiAxe failures weekly, can confirm whether the ASIC is dead vs whether a subtle config issue remains, and have BM1366 chips in stock for replacement. Email support with: Pi model, OS version, config.txt contents, pyminer log, and logic-trace snippet if you captured one. Half an hour of preparation saves billable bench time.

Ship the PiAxe to D-Central for bench work if the chip is suspected dead. Pack in an anti-static bag, double-box with 3 cm of foam on every side. Include a printed note with: Pi model, Raspberry Pi OS version and kernel, `config.txt` contents, last 200 lines of `journalctl -u pyminer`, whether you tried 5V-logic adapters, any known electrical events. Ship to the D-Central address on the Repair Service page.

D-Central bench process: visual inspection for burn/cap damage, continuity test on 12V and 3.3V rails, BM1366 response test on a known-good Pi 4 + reference config, chip replacement with graded BM1366 from stock if unresponsive, reflow + reassembly, 4-hour burn-in at target 500 GH/s on solo.ckpool.org. Turnaround 3-7 business days Canada-wide, 5-10 days international. We return the PiAxe with a printed test report.