feat: native Windows support for Bitaxe mining#76
Open
IxTechCrypto wants to merge 4 commits into
Open
Conversation
Forward-port Windows support onto current main so mujina-minerd builds and runs on Windows (MSVC) and drives a BitAxe over USB serial: - transport/usb/windows.rs (new): map nusb devices to COM ports by VID:PID:serial, ordered by USB interface number (Windows COM numbers don't follow interface order); retry + settle for hotplug open races. - transport/serial_windows.rs (new): Windows SerialStream over tokio-serial matching the Unix serial.rs public API (new/with_config/split, reader/ writer/control). - transport/mod.rs, transport/usb.rs: cfg-swap serial and wire the Windows platform arm. - Cargo.toml: move nix/rustix to cfg(unix); on Windows enable serialport usbportinfo-interface and the nusb tokio feature. - daemon.rs: Ctrl-C graceful shutdown on Windows. - board/bitaxe.rs: match BitAxe by VID:PID c0de:cafe (Windows reports a generic "Microsoft" manufacturer for CDC ACM). Verified on Windows 11 against a BitAxe Gamma: discovers, mines, and serves the full /api/v0/miner state tree (read by the Nexus app). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The BM1370 needs time to boot its UART after nRST is released. The previous sequence waited only 200ms and ran discovery once, so a cold ASIC that had not finished booting stayed silent, the single 500ms discovery window elapsed with no reply, and the whole board failed with "no chips discovered". This showed up intermittently on Windows: USB, I2C, power and VCORE all came up correctly, but the data UART returned nothing. Wait 500ms after releasing reset (matching the reference firmware) and retry the version-mask + discovery up to five times before giving up, so a slow boot no longer fails the board permanently. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The BM1370 is ramped to a fixed 525 MHz during init. Expose that as a named constant (TARGET_FREQUENCY_MHZ) and add an optional frequency_mhz field to BoardTelemetry so the REST API and clients can display the operating frequency. Populated by the Bitaxe board monitor. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The board monitor incremented a single counter for both an over-temperature reading and an I2C read failure, tripping a full THERMAL EMERGENCY shutdown after 3 consecutive of either. A transient control-bus desync (off-by-one Response ID mismatch on the CDC control channel) would exhaust that budget in ~6s and shut down a board that was running at a safe temperature. Split the counter in two: - over_temp_count: genuine readings >= 80C, still trips fast (3). - sensor_fault_count: I2C errors / out-of-range values, tolerated for 10 cycles (~20s) so a transient desync can re-sync, but still shuts down if the sensor stays unreadable. A valid normal reading resets both. Fail-safe behavior for real heat is unchanged; a comms hiccup no longer misfires as an over-temp shutdown. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Collaborator
|
Hey @IxTechCrypto, this is great! I'll take a look shortly. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds native Windows support so Mujina can drive a Bitaxe over USB on Windows, plus two related fixes.
Windows transport: COM-port discovery + interface ordering, a tokio-serial SerialStream mirroring the Unix serial API, cfg wiring, and Ctrl-C shutdown handling.
Chip discovery: wait 500ms after ASIC reset and retry BM1370 discovery up to 5× so a cold board doesn't fail with "no chips discovered".
Frequency telemetry: new frequency_mhz field on BoardTelemetry exposing the 525 MHz clock.
Tested on Windows 11 with a Bitaxe Gamma (BM1370): mines end-to-end at ~1.25 TH/s, submits shares, serves the REST API. cargo fmt --check, cargo clippy --release -- -D warnings, and cargo test pass on each commit. Supersedes the stale #75.
Shoutout to @aadhi1014 for his work on #75 and getting us 80% there