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

[Skot]

Skot, NebulaMiner or N0nce , Has any of you managed coding the ESP_Miner and got to it to where it can be used for testing BM1397 boards ?. I am just starting on it.

Not yet.. it’s certainly on the to do list though!

[n0nce]

Skot, NebulaMiner or N0nce , Has any of you managed coding the ESP_Miner and got to it to where it can be used for testing BM1397 boards ?. I am just starting on it.

Unfortunately, had no time for that yet; I'm very busy right now (as maybe noticeable by my lack of posting), but that will change soon and I'll post here (or in Skot's new thread when he makes one) as soon as I have something.

[NebulaMiner]

Skot, NebulaMiner or N0nce , Has any of you managed coding the ESP_Miner and got to it to where it can be used for testing BM1397 boards ?. I am just starting on it.

Unfortunately, had no time for that yet; I'm very busy right now (as maybe noticeable by my lack of posting), but that will change soon and I'll post here (or in Skot's new thread when he makes one) as soon as I have something.

Same for me, difficult end of year. I will find some time soon hopefully.

[developeralgo]

Phew!!! My 4-chip board is assembled now and at least it didn't go up in flames . So its time bring out the Oscilloscope and start debugging and tracing , its going to be fun i hope

[Skot]

Phew!!! My 4-chip board is assembled now and at least it didn't go up in flames . So its time bring out the Oscilloscope and start debugging and tracing , its going to be fun i hope

Wow, Looking good!! Is that four BM1397s??

[developeralgo]

Wow, Looking good!! Is that four BM1397s??

Yes it is, 4 x BM1397 chips

[n0nce]

Phew!!! My 4-chip board is assembled now and at least it didn't go up in flames . So its time bring out the Oscilloscope and start debugging and tracing , its going to be fun i hope

Be careful about temps / cooling! Especially when you start attempting sending those chips commands. Don't want them to start hashing and immediately going up in flames. But Skot knows much more than myself about this (how / when they start hashing / getting hot).

It's just that I've experienced (as a customer) finished mining products hashing even when not getting supplied any data at all (not sure what they were doing - again: as a customer).
Just saying I've encountered it and I'm not sure whether that was just the 'idle behavior' of those chips (older stuff, not BM1397 for sure) or firmware-related.

[developeralgo]

Be careful about temps / cooling! Especially when you start attempting sending those chips commands. Don't want them to start hashing and immediately going up in flames. But Skot knows much more than myself about this (how / when they start hashing / getting hot).

It's just that I've experienced (as a customer) finished mining products hashing even when not getting supplied any data at all (not sure what they were doing - again: as a customer).
Just saying I've encountered it and I'm not sure whether that was just the 'idle behavior' of those chips (older stuff, not BM1397 for sure) or firmware-related.

Great advice. Coding an ESP Miner to test it correctly, is a pain. I hope to use ESP-IDF Version 5 (std) with ESP-Rust 1.66 (std) and code some minimal rust-based ESP Miner for testing.

The biggest problem i have encountered is the support and community for xtensa-esp32s3 using rust is minimal or non-existent at best. i have tested some simple ESP miner code on my ESP32-S3-WROOM-2-N32R8V Dev board that i have  and it runs fast but that is without it communicating or mining on BM1397 chips. Next step will be to try adapt this minimal testing code to communicate and mine on BM1397 chips and use it on the onboard ESP32-S3-WROOM-1-N16R8V on my ESP mining board.

that's a lot of grunt work to be done.

[n0nce]

Great advice. Coding an ESP Miner to test it correctly, is a pain.
[...]
that's a lot of grunt work to be done.

For sure; it was never going to be easy! But I'm sure we can get it done as a group. I will have lots more free time pretty soon. All the components are already here, except BM1397. I had troubles finding them at a reasonable price and shipping speed and now I have none.

The biggest problem i have encountered is the support and community for xtensa-esp32s3 using rust is minimal or non-existent at best. i have tested some simple ESP miner code on my ESP32-S3-WROOM-2-N32R8V Dev board that i have  and it runs fast but that is without it communicating or mining on BM1397 chips. Next step will be to try adapt this minimal testing code to communicate and mine on BM1397 chips and use it on the onboard ESP32-S3-WROOM-1-N16R8V on my ESP mining board.

I think I'll start with the Stratum connection and that side of things (using regular ESP-IDF), since again: I don't have ASIC chips yet.

[paid2]

Great advice. Coding an ESP Miner to test it correctly, is a pain.
[...]
that's a lot of grunt work to be done.

For sure; it was never going to be easy! But I'm sure we can get it done as a group. I will have lots more free time pretty soon. All the components are already here, except BM1397. I had troubles finding them at a reasonable price and shipping speed and now I have none.

The biggest problem i have encountered is the support and community for xtensa-esp32s3 using rust is minimal or non-existent at best. i have tested some simple ESP miner code on my ESP32-S3-WROOM-2-N32R8V Dev board that i have  and it runs fast but that is without it communicating or mining on BM1397 chips. Next step will be to try adapt this minimal testing code to communicate and mine on BM1397 chips and use it on the onboard ESP32-S3-WROOM-1-N16R8V on my ESP mining board.

I think I'll start with the Stratum connection and that side of things (using regular ESP-IDF), since again: I don't have ASIC chips yet.

Hey !

I can send you a lot of old S9 / S9k hashboard if needed ! 
For free, I juste don't want to pay the shipping but I don't care about the boards

[n0nce]

Great advice. Coding an ESP Miner to test it correctly, is a pain.
[...]
that's a lot of grunt work to be done.

For sure; it was never going to be easy! But I'm sure we can get it done as a group. I will have lots more free time pretty soon. All the components are already here, except BM1397. I had troubles finding them at a reasonable price and shipping speed and now I have none.

The biggest problem i have encountered is the support and community for xtensa-esp32s3 using rust is minimal or non-existent at best. i have tested some simple ESP miner code on my ESP32-S3-WROOM-2-N32R8V Dev board that i have  and it runs fast but that is without it communicating or mining on BM1397 chips. Next step will be to try adapt this minimal testing code to communicate and mine on BM1397 chips and use it on the onboard ESP32-S3-WROOM-1-N16R8V on my ESP mining board.

I think I'll start with the Stratum connection and that side of things (using regular ESP-IDF), since again: I don't have ASIC chips yet.

Hey !

I can send you a lot of old S9 / S9k hashboard if needed ! 
For free, I juste don't want to pay the shipping but I don't care about the boards

Hey there, thanks for the offer! I believe NebulaMiner wants to / started reverse engineering ASIC communication / protocol of Bitmain S17.
The S9 have older chips, but since protocols may stay the same between miner generations, it could be interesting for him to look at the S9 boards.

[o_solo_miner]

I used the Odroid-GO for development, but in c.
or the Arduino Platform:
https://github.com/espressif/arduino-esp32

Maybe that is a usefull for you.

[n0nce]

I used the Odroid-GO for development, but in c.
or the Arduino Platform:
https://github.com/espressif/arduino-esp32

Maybe that is a usefull for you.

Those are the ESP32's (plain 32, not 32-C3 or 32-S3), but what exactly did you develop for them? Mining firmware? That could indeed be useful; especially the Stratum v2 part, since that should be completely independent from the mining hardware (ASIC chips) used.

C code for ESP32 should also compile for ESP32-S3.

[cygan]

Wow, Looking good!! Is that four BM1397s??

Yes it is, 4 x BM1397 chips

holy shit!
what would be the complete hash performance in the best case, if all 4 chips were running properly?

[n0nce]

Wow, Looking good!! Is that four BM1397s??

Yes it is, 4 x BM1397 chips

holy shit!
what would be the complete hash performance in the best case, if all 4 chips were running properly?

My new GekkoScience R909 with 6 BM1397 chips at 600MHz and proper cooling (review is coming) is pushing out around 2.2TH/s, so around 370GH/s per chip. I believe 400GH/s per chip is definitely realistic, so that's 2.4TH/s on a R909 or 1.6TH/s on the Bitaxe with 4 chips.

[developeralgo]

Those are the ESP32's (plain 32, not 32-C3 or 32-S3), but what exactly did you develop for them? Mining firmware? That could indeed be useful; especially the Stratum v2 part, since that should be completely independent from the mining hardware (ASIC chips) used.

C code for ESP32 should also compile for ESP32-S3.

The hard part is figuring out an optimized and efficient communication between ESP32-S3-WROOM-1 chip and the BM 1397 chips and coding it in a stripped down embedded format so that it fits into tiny 16 MB Flash with additional 8 MB PSRAM on the ESP32-S3

Either C or Std Rust or NoStd Rust, we will still come very close to the memory threshold being completely utilized. i guess the goal is to strip down everything and have only bare-bone code but with standard ESP-IDF Version 5.0 / 5.1 to handle a lot of the headaches from std code

Good candidates is to use Cgminer (Kanoi version (C/C++)) , Braiins OS code base (Rust) as a Reference plus stratum V2 (Rust) code base and strip everything to the bone. Rust has few advantages when running on Microcontrollers compared to pure C code.

[n0nce]

The hard part is figuring out an optimized and efficient communication between ESP32-S3-WROOM-1 chip and the BM 1397 chips and coding it in a stripped down embedded format so that it fits into tiny 16 MB Flash with additional 8 MB PSRAM on the ESP32-S3

Agreed.

Rust has few advantages when running on Microcontrollers compared to pure C code.

Which advantages exactly? (specific to microcontrollers)

[developeralgo]

Which advantages exactly? (specific to microcontrollers)

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.

[n0nce]

Which advantages exactly? (specific to microcontrollers)

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.

[developeralgo]

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.

Agreed , nothing  really special about MCU and Rust.