Hammer Thor X1 and P2 firmware fixes Bitcoin pool compatibility
Source report: 2026-09-09 · Editorial analysis published: 2026-09-18
Official September 9 releases are now documented on the site, with local firmware downloads and practical checks before updating.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
Two releases, two specific device families
HammerMiner published Thor X1 v1.0.5 and Thor P2 v1.0.2 on September 9, 2026. Both official release notes describe fixes for compatibility issues with some Bitcoin pools. The tags contain September 8, while GitHub records publication on September 9; we use the actual release date. This is a newly added site report about an earlier update, not a claim that firmware was launched today. The notes do not identify every affected pool or promise a hashrate increase.
Local downloads retain source and SHA-256
The site’s existing archive contains the official X1 and P2 files, including these releases and earlier versions. Open the matching miner’s firmware page and use its local download button; verify the filename, version and SHA-256 shown beside it. Our archived copies were checked against official release assets when imported. A checksum verifies that a file matches the recorded copy; it is not a guarantee that every controller or hardware revision accepts it. Read the source release before installation.
Save a baseline before making changes
Our preparation checklist records the current firmware, exact device identity, pool addresses, worker name, network settings and measured operating behavior. Preserve configuration through the manufacturer-supported method if available. A photograph of a label and a copy of the existing settings help distinguish two similar machines. Choose a maintenance interval with stable power and access to the device. Do not assume a downgrade is supported merely because an older binary is downloadable; recovery requirements depend on the product and firmware.
Check accepted shares on one compatible device
Our suggested pilot uses one compatible device while holding pool, operating profile and observation interval as consistent as possible. After the manufacturer’s installation procedure, check connectivity, accepted and rejected shares, reconnections and displayed uptime. The fact that a dashboard opens is not evidence that the pool accepts useful work. Compare both device logs and pool-side records. If operating conditions changed during the test, label the comparison accordingly instead of attributing every difference to the firmware.
Pool compatibility is different from higher hashrate
The release description supports a compatibility claim, not new rated performance or a profit forecast. Our practical interpretation is that fixing a connection or submission problem can restore usable operation on an affected setup; it does not change a model’s published TH/s by itself. Keep catalogue specifications unchanged until the manufacturer publishes a new configuration or measured evidence is clearly scoped. Observe temperatures, power and stability too, and record unexpected behavior before considering a broader rollout.
Document the rollout and keep the original dates
For a farm, record which device received which file, when it restarted, whether configuration was retained and what the observation showed. Expand only after a useful pilot, using the product’s supported procedure. Our archive provides version history and downloads; it cannot decide compatibility for an unidentified board. The credited archival photos illustrate computing hardware, not the appearance of Thor X1/P2 or an update performed today. September 9 remains the official release date; September 18 is when this report was published here.
Keep file identity separate from a marketing name
A useful maintenance record includes the exact release tag, downloaded file and checksum rather than only the phrase “latest firmware.” The latest label changes when a new version appears, while a recorded file identity remains traceable. Keep X1 and P2 histories separate even when their release descriptions are similar. If a later update supersedes this report, preserve the earlier version’s date and add the new entry. This prevents an older service record from silently pointing to a different binary.
Source: HammerMiner / GitHub ↗ · Hammer Thor P2 v1.0.2 official release ↗
Mining calculator ↗
