Open Source Bitcoin ASIC miner project that uses 2x BM1387 (Antminer S9)

[Skot]

Assuming that someone is competent in both C and Rust , IMHO ,  multithreaded/concurrent code that is correct and produces no undefined behavior is better.  Also memory safety is a key feature that Rust brings to the table. In C you are on your own with concurrency and God help you if you are new to C programming. You will get baptism by fire.
C / C++ and Python are my go-to languages but C tends to be a little messy to code sometimes but gets better with age i guess.

Okay, so those are general advantages that come with Rust. I thought there was something specific about MCUs. Do we need a lot of multithreading for this application, though? You request a block candidate over Stratum v2, build a packet for your miner and send it. Then wait for it to respond. As far as I know, that's the rough big picture.

I really like the idea of Rust. I just haven't seen anything convincing about support on the ESP32. Or really any MCU other than the STM32, which is hard AF to source these days.

Concurrency in C isn't too bad if you have a RTOS like FreeRTOS that ESP-IDF uses. I put together a first pass at a (ESP-IDF based) firmware architecture here; l https://github.com/skot/ESP-Miner . I'm sure this will need some refinement, but the basic idea is what n0nce said; get the work over stratum, build a packet and send it to the BM1397. Wait for a response and if you don't get one in time, roll extra nonce and send another!

Braiins has taken down the source to their "community edition" S9 firmware. I'm kicking myself for not cloning it back when they had it up. That would have been a good resource.

Check this out though; Someone did a research paper and posted code for a stratum implementation and CPU mining on ESP32 (and Playstation!) https://www.researchgate.net/publication/360353621_Implementation_of_an_efficient_portable_and_platform-agnostic_cryptocurrency_mining_algorithm_for_Internet_of_Things_devices

[developeralgo]

I'm sure this will need some refinement, but the basic idea is what n0nce said; get the work over stratum, build a packet and send it to the BM1397. Wait for a response and if you don't get one in time, roll extra nonce and send another!

Check this out though; Someone did a research paper and posted code for a stratum implementation and CPU mining on ESP32 (and Playstation!) https://www.researchgate.net/publication/360353621_Implementation_of_an_efficient_portable_and_platform-agnostic_cryptocurrency_mining_algorithm_for_Internet_of_Things_devices

i had posted that same research earlier in previous posts and had tried it out but it had a few issues and also it still needs to communicate with BM1397 chip, will look at it later  . Also we need a way of finding out the status of work on chip then roll extra nonce and send another as you said. Is using the a timer to wait for response from the chip good enough considering all the constraints we are facing?

[Skot]

i had posted that same research earlier in previous posts and had tried it out but it had a few issues and also it still needs to communicate with BM1397 chip, will look at it later  . Also we need a way of finding out the status of work on chip then roll extra nonce and send another as you said. Is using the a timer to wait for response from the chip good enough considering all the constraints we are facing?

Ah! Maybe that's how I found it. Interesting paper. I like the breakdown of the mining algorithm.

As far as the status of work on the chip, I'm sure Kano knows more. My understanding is that the BM1397 does not send any response unless it finds a hash below the target. That means it is the job of the mining software to know when the chip has exhausted the 2^32 bit nonce space. It's unclear what the BM1397 does after hashing the entire nonce space, but I don't think it's productive. Using a ESP32 timer and the configured hashing frequency, we should be able to know when the chip is ready for new work.

I think it makes sense to have a separate RTOS thread/task listening to, parsing and acting on BM1397 responses. Low latency with good hashes seems important!

[developeralgo]

I think it makes sense to have a separate RTOS thread/task listening to, parsing and acting on BM1397 responses. Low latency with good hashes seems important!

I have been running into issues flashing the ESP32-S3 modules using the ESP-PROG board and Tag-Cable 2030 NL cable. For some reason all my FTDI serial connections on UBUNTU 20.04 are ok and double checked all pins, Voltages and everything is working correctly but for some reason i can't flash it. Opened up an issue on esptool Repo on github  https://github.com/espressif/esptool/issues/741

Keep getting this error: " Invalid head of packet (0x66): Possible serial noise or corruption. " . Any suggestions

[GizmoMiner]

i had posted that same research earlier in previous posts and had tried it out but it had a few issues and also it still needs to communicate with BM1397 chip, will look at it later  . Also we need a way of finding out the status of work on chip then roll extra nonce and send another as you said. Is using the a timer to wait for response from the chip good enough considering all the constraints we are facing?

Ah! Maybe that's how I found it. Interesting paper. I like the breakdown of the mining algorithm.

As far as the status of work on the chip, I'm sure Kano knows more. My understanding is that the BM1397 does not send any response unless it finds a hash below the target. That means it is the job of the mining software to know when the chip has exhausted the 2^32 bit nonce space. It's unclear what the BM1397 does after hashing the entire nonce space, but I don't think it's productive. Using a ESP32 timer and the configured hashing frequency, we should be able to know when the chip is ready for new work.

I think it makes sense to have a separate RTOS thread/task listening to, parsing and acting on BM1397 responses. Low latency with good hashes seems important!

You would not happen to have a stl, obj 3d model of the complete assembled Bitaxe would you? With heatsink and fan? Exact size of the completed Bitaxe in stl file format?

[Skot]

You would not happen to have a stl, obj 3d model of the complete assembled Bitaxe would you? With heatsink and fan? Exact size of the completed Bitaxe in stl file format?

Sorta; The KiCad project can export a stl 3d model of the PCB and all of the parts in their positions. Press option-3 on Mac. It just won't have the heatsink and fan. I'd love to have these complete models, but I'm miserable at MCAD.

[Skot]

I think it makes sense to have a separate RTOS thread/task listening to, parsing and acting on BM1397 responses. Low latency with good hashes seems important!

I have been running into issues flashing the ESP32-S3 modules using the ESP-PROG board and Tag-Cable 2030 NL cable. For some reason all my FTDI serial connections on UBUNTU 20.04 are ok and double checked all pins, Voltages and everything is working correctly but for some reason i can't flash it. Opened up an issue on esptool Repo on github  https://github.com/espressif/esptool/issues/741

Keep getting this error: " Invalid head of packet (0x66): Possible serial noise or corruption. " . Any suggestions

Ooo that's annoying. I just got my ESP-Prog in the mail. I'll give it a try tonight with the bitaxeMax v2 and see if I can sort it out.

[xraid]

I really like the idea of Rust. I just haven't seen anything convincing about support on the ESP32. Or really any MCU other than the STM32, which is hard AF to source these days.

here is esp32s3 rust hal if You have not seen it already
https://github.com/esp-rs/esp-hal/tree/main/esp32s3-hal

myself is targeting rp2040 = pico and are using "embassy" that has great async using a task executor,
https://github.com/embassy-rs/embassy
"embassy" has some esp32 in pipeline as i understand is "work in progress"
https://github.com/embassy-rs/embassy/issues/745

[n0nce]

I think it makes sense to have a separate RTOS thread/task listening to, parsing and acting on BM1397 responses. Low latency with good hashes seems important!

Oh yes, you want to get those out immediately. Would definitely work with threads / tasks / listeners (whatever fits the framework or programming language used). On the other hand, I don't think the main task needs to do much while the ASIC is hashing, no?

In that case, it would be possible to do the ASIC comms on main thread and periodically / on background thread fetch new block templates from the pool. Whatever is most performant, I'd suggest.

You would not happen to have a stl, obj 3d model of the complete assembled Bitaxe would you? With heatsink and fan? Exact size of the completed Bitaxe in stl file format?

Here's the .obj; I just exported from KiCAD, then converted it using Blender.
You will need to find or model the heatsink & fan yourself, as I don't have those models.

[developeralgo]

Ooo that's annoying. I just got my ESP-Prog in the mail. I'll give it a try tonight with the bitaxeMax v2 and see if I can sort it out.

Finally got it sorted out. My USB power alone was not enough , i did have to juice it up with bench power to have the ESP32-S3 in bootloader mode

[Skot]

Finally got it sorted out. My USB power alone was not enough , i did have to juice it up with bench power to have the ESP32-S3 in bootloader mode

Did you have to load the bootloader on the ESP32-S3-WROOM-1 before you could program over serial?

I'm getting;

Code:

A fatal error occurred: Failed to connect to ESP32-S3: Wrong boot mode detected (0x14)! The chip needs to be in download mode.

[Skot]

Did you have to load the bootloader on the ESP32-S3-WROOM-1 before you could program over serial?

I'm getting;

Code:

A fatal error occurred: Failed to connect to ESP32-S3: Wrong boot mode detected (0x14)! The chip needs to be in download mode.

Ahh dang, I just noticed this gem from the ESP32-S3 datasheet;

GPIO46 must also be either left unconnected/floating, or driven Low, in order to enter the serial bootloader.

And of course I picked GPIO46 for I2C SDA, so it's pulled high.

https://github.com/skot/bitaxe/issues/18

After removing the SDA I2C pull-up resistor I can program the ESP32 with ESP-Prog, so that's good news!

[developeralgo]

GPIO46 must also be either left unconnected/floating, or driven Low, in order to enter the serial bootloader.

And of course I picked GPIO46 for I2C SDA, so it's pulled high.

https://github.com/skot/bitaxe/issues/18

After removing the SDA I2C pull-up resistor I can program the ESP32 with ESP-Prog, so that's good news!

Yes, GPIO3 = Pin 15 is  floating by default and is one of the strapping pins which includes ( GPIO0=Pin27, GPIO045=Pin26, GPIO46=Pin16, GPIO3=Pin15) . But GPIO0=Pin27, GPIO045=Pin26 and GPIO46=Pin16 are connected to the Chip's internal weak pull-down/pull-up during chip RESET and if they are unconnected or the connected external circuit is high-impedance, then the internal weak pull-up/pull-down will determine  the default input level of these strapping pins. So GPIO3 = Pin 15 should work.

[GizmoMiner]

You would not happen to have a stl, obj 3d model of the complete assembled Bitaxe would you? With heatsink and fan? Exact size of the completed Bitaxe in stl file format?

Sorta; The KiCad project can export a stl 3d model of the PCB and all of the parts in their positions. Press option-3 on Mac. It just won't have the heatsink and fan. I'd love to have these complete models, but I'm miserable at MCAD.

If you have a couple minutes. Could you give me the specs of the Bitaxe with heatssink  and fan? Would like to make a 3d rendering of it.In It's most complete form.  Made a Discord channel for Bitaxe. If everyone wants a place to work on this in real time. Here is the  discord invite.

[GizmoMiner]

I think it makes sense to have a separate RTOS thread/task listening to, parsing and acting on BM1397 responses. Low latency with good hashes seems important!

Oh yes, you want to get those out immediately. Would definitely work with threads / tasks / listeners (whatever fits the framework or programming language used). On the other hand, I don't think the main task needs to do much while the ASIC is hashing, no?

In that case, it would be possible to do the ASIC comms on main thread and periodically / on background thread fetch new block templates from the pool. Whatever is most performant, I'd suggest.

You would not happen to have a stl, obj 3d model of the complete assembled Bitaxe would you? With heatsink and fan? Exact size of the completed Bitaxe in stl file format?

Here's the .obj; I just exported from KiCAD, then converted it using Blender.
You will need to find or model the heatsink & fan yourself, as I don't have those models.

Thanks.  Yea I got the export done yesterday with KiCAD. Hoping for a complete 3d render of the Bitaxe with heatsink and fan. Going to get the specs hopefully and make one.
If everyone wants a place to work on Bitcaxe in real time. Here is the  discord invite. With the ability to search discord chat threads for keywords . Might be a good tool for people to troubleshoot and find answers about Bitaxe.

[n0nce]

Thanks. Yea I got the export done yesterday with KiCAD. Hoping for a complete 3d render of the Bitaxe with heatsink and fan. Going to get the specs hopefully and make one.

I had a bit of time on my hands today so I made this.. Suggestions are welcome! I do think it looks quite good in Bitcoin-orange.
FYI: I used the exported bitaxeMax.wrl from KiCAD and a random chipset heatsink STL, then assigned materials.

[Skot]

I had a bit of time on my hands today so I made this.. Suggestions are welcome! I do think it looks quite good in Bitcoin-orange.
FYI: I used the exported bitaxeMax.wrl from KiCAD and a random chipset heatsink STL, then assigned materials.

that looks awesome!! I'm going to have to figure out how to get orange soldermask for the next boards

[developeralgo]

Thanks. Yea I got the export done yesterday with KiCAD. Hoping for a complete 3d render of the Bitaxe with heatsink and fan. Going to get the specs hopefully and make one.

wow!!!, that's nice

[hZti]

I had a bit of time on my hands today so I made this.. Suggestions are welcome! I do think it looks quite good in Bitcoin-orange.
FYI: I used the exported bitaxeMax.wrl from KiCAD and a random chipset heatsink STL, then assigned materials.

This looks very awesome! What I was thinking is, that I would love also a version that does not need active cooling, since this would lower the noise and power draw. When I have the time I will maybe try to design something with liquid cooling or one big passive cooler that can maybe used to cool many of these miners at once. Other people can obviously also design something with this idea also.

[n0nce]

I had a bit of time on my hands today so I made this.. Suggestions are welcome! I do think it looks quite good in Bitcoin-orange.
FYI: I used the exported bitaxeMax.wrl from KiCAD and a random chipset heatsink STL, then assigned materials.

This looks very awesome! What I was thinking is, that I would love also a version that does not need active cooling, since this would lower the noise and power draw. When I have the time I will maybe try to design something with liquid cooling or one big passive cooler that can maybe used to cool many of these miners at once. Other people can obviously also design something with this idea also.

A liquid cooling loop that can cool e.g. 500W would be convenient since it could cool multiple miners quietly, I agree.

But passive cooling reducing power draw is actually wrong. A fan uses almost no energy at all, meanwhile passively cooled, the chip would run hotter, causing it to again draw more power. These chips like being as cool as possible.
You can even get into thermal runaway because of this: too hot > more power draw > gets hotter > even more power draw > even hotter...