 Show Posts
|
|
Pages: [1] 2 »
|
I vote for: #87, #31, #20, #7, #10 |
|
|
|
that's sounds great, i think the ESP32-S3 internal pull-up/pull-down resistors are usually 45k Ohms. How are you testing the BM1397 chip on the board ?
my bringup plan; 1. make sure I2C is working (done) 2. Make sure the DS4432U+ is alive (done) 3. Adjust the BM1397 core voltage to 1.5V with the DS4432U+ over I2C from the ESP32 4. Test the BM1397 with cgminer using the level shifted J6 debug header and a USB Serial cable 5. make some ESP32 FW to test the BM1397 from the ESP32 then.. 6. Make proper drivers for the DS4432U+, EMC2102, INA260, and LEDs 7. Make sure the ESP32 can connect over WiFi (done) 8. Get stratum work from ckpool 9. Format work for the BM1397, and send it to the BM1397 10. send stratum responses 11. Mine BTC! Great plan ! Finally my work is on point 6 (proper drivers, EMC2102 almost finished) and 9 (BM1397 driver). I am also working on 8/10 (stratum library). |
|
|
|
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. S9 have BM1387 chips, S9k is BM1393, and S17/Bitaxe are BM1397. I did started a reverse engineering job on the differents protocols in order to better understand BM1397 for Bitaxe driver in FW. S9 board (BM1387) have older and different commands from BM1397. But S9k (BM1393) are somehow similar. I did brough a broken S9k on ebay, but HashBoards are faulty so it would be nice to have good ones to see how Control Board is handling HB errors... I will contact you @iwantmyhomepaidwithbtc2 to see what can be done  thanks for the help. |
|
|
|
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. |
|
|
|
Beautifull ! Look very promising. About heatsink and fan, did you select any specific parts ? I brought a Noctua NF-A4x20 5V PWM for my testing with the EMC2101, and have some spare random heatsink. |
|
|
|
I know NebulaMiner is hard at work on a Rust implementation, but it sounds like it might be a bit. I think the best thing to do on that front is to get setup with the Espressif ESP-IDF SDK (it's C / FreeRTOS based). They have a bunch of cool examples for getting connected to WiFi and opening TCP sockets, etc. ESP-IDF has a cJSON library included which I think is the way to go for talking Stratum.
Sounds good; I've actually already played around with ESP-IDF on a regular old ESP32. Rust dev is going from bottom up, so i am working on low level drivers right now. No project from existing template yet. |
|
|
|
- Use Sn63/Pb37 no-clean, leaded, solder paste. I usually get MG Chemicals brand, in a syringe. Keep it in the refrigerator so it's nice and cold before you stencil it. (obvs don't maybe we will have some surprise with Sn63/Pb37 alloy, with its low melting temperature point and a relatively hot chip (ASIC miner).... |
|
|
|
Stratum V2 (S2) has ....
Totally off topic to be shilling V2 here. Requesting that the mods move/remove it. Actually, I think it is not offtopic here. xraid is someone I met on SV2 Discord doing my research for Bitaxe. He has great understanding of SV1/SV2 and current development. More he is very excited by Bitaxe project, that's why I asked him to join this thread. SV2 is quite a complexe architecture by itself, and it is a small part of Bitaxe project. I think this post is giving some context about SV2. I didn't feel any shilling personnaly (if I am allowed to express my opinion about that). Actually SV2 is very important for an embedded miner, has it avoid the hassle to manipulate string for JSON parsing/formatting (used in SV1). |
|
|
|
Hi, I am working on a BM13xx High Level Analyzer for Saleae Logic 2. You can find it on Saleae Logic 2 market place as an extension (and also in GH : https://github.com/GPTechinno/bm13xx-hla). Maybe you can have a use of it Currently, basic communicatin (FIL/VIL mode, R/W register, manage chip address, job/nonce) is well handled. I am digging into the register functions and fields now. I am sure your level of knowledge on the BM13xx serial protocol is higher han mine, but such a practical tool can be handy for your dev also. Let me know what you think about it. |
|
|
|
As concerns the actual bitcoin mining client on ESP32-S3 , Has anyone attempted to port the cgminer 4.12 code to rust so as to fit ESP32-S3 constraints . The Open Source Braiins OS is written in Rust supports using ARM Cortex CPU-based control boards like BeagleBone and has the drivers for all Bitamin S9, S17 & S19 Series Chips . i don't see it supporting ESP32-S3 which has a dual-core XTensa LX7.
Braiins OS requires at least 200 MB of storage ( 105 MB used for OS ) and i guess less than 512MB of RAM to run. All this are constraints for ESP32-S3 , Even if we strip down the code and rewrite it or use a different base as reference we will still need to have a fully fledged bitcoin mining client to avoid a lot of frustrations. I haven't come across any reference code online that has used ESP32-S3 / ESP32-WROVER (N16R8) with Rust as a control board for antminer BM13xx chips.
Any Ideas ? Skot has a good start ESP32-Miner repo created.
Rust FW for bitaxe is a big subject i am working on everyday. As I said in a previous post, it is better someone work on a standard C FW based on existing component (cgminer) instead of waiting for the Rust solution which will take longer time. There not such "cgminer porting in Rust", cgminer is heavyly dependant on C. The best I can do, is to use cgminer driver for BM1397 based HW, to understand the low level (undocumented) protocol. Then code a (Rust) driver for BM13xx (based on Rust Embedded-Hal abstraction). To update on my progress doing so, I received the broken T17 I brought on ebay (2 hashboard seems to be functional enough to be communicating) with stock FW, so I was able to log serial/i2c communication between ControlBoard and HashBoard using Saleae Logic2 (logic analyzer) and code a High Level Analyzer to parse the Serial Protocol (communication with BM13xx), it is available on https://github.com/GPTechinno/bm13xx-hla. Basic communication protocol is covered, I am into understanting the registers and their fields now. For this I do cross comparaison with S9k log (BM1393) with stock FW I also have on hand. I will also try different custom FW for the T17 (including BraiinsOS+) to learn how these differents flavor handle the same HW. I would be also very interested to have more log from other miner (S17...). So a lot of work need to be done in this direction... For the ESP32-S3 selection, it is the most ESP32 capable chip, that's why I guess Skot selected it. Its exotic architecture (Xtensa) make it less compatible with existing project. Nevertheless, esp-rs, which is the Rust support for ESP32 family seems to have active community and good result. Basically, there is 2 flavors : - one based on IDF (the framework supplied by Espressif, based on FreeRTOS, so a low level OS in C, that can handle all wifi/network layers) where Rust application can be run on top (so kind of a mixed C/Rust embedded). To my personal point of view, considering this approach, it is better to have a full IDF FW with existing cgminer C cross compiled to it, no need for Rust here, this is the "standard C FW" I was refering to earlier. - one based on plain Rust, but no wifi/network is available yet. IMHO wifi is not reliable enought for 24/7 mining device, copper wire (Ethernet) is much more prefered here. That's why I have close look also into W5500 SPI/Ethernet bridge from Wiznet (I used them a lot in many other project), that has a very good support in Rust Embedded enviroment ( https://github.com/newAM/w5500-rs). For the Rust embedded framework, there is mainly 2 solutions : - RTIC : Real Time Interrupt-driven Concurrency which I am not yet fully documented. Community seems very active. Alex (from w5500-rs) has a project example with it ( https://github.com/newAM/ambientsensor-rs). - Embassy : EMBedded ASYnc, which I start to love more and more. It has great support for STM32 and RP2040 (RPi PICO chip) but no ESP32 yet. w5500-embassy is not finish eyt, but Alex gave me access to its private repo where job is ongoing there. I will try to make progress on it. I tink a great HW for this, is the W5500-EVB-PICO, basically a RP2040 with a W5500 on a stick (brought 2 of them). RP2040 is a dual core Cortex-M0+ at 133MHz. Having a dual core look promising to have one core for the Network (Ethernet/W5500/StratumV2), and the second one for the BM13xx serial handling. Embassy seems to be able to deal with these 2 differents contexts (not tried yet). Finally, why I think Rust is way to go for a embedded miner, it is mainly because Stratum V2 Reference Implementation is done in Rust ( https://github.com/stratum-mining/stratum), I recently joined their weekly dev meeting and they seems to be interesting into a first embedded implementation. It can be done on the ESP32-S3 on top of IDF without the need to have actual BM13xx I think. And about others Bitaxe's chip driver, I have well debugged my EMC2101 rust driver, but it is not finished yet. |
|
|
|
I did some progress on the BM13xx serial protocol understanding. I just published the Saleae Logic2 High Level Analyzer extension : https://github.com/GPTechinno/bm13xx-hla. It should be also available in the Saleae Marketplace More need to be done.... |
|
|
|
OK, I just brought a T17 with only 1 hashboard fonctionnal on ebay... BM1397 serious reversing incoming... I also received an ESP32-S3 module and the EMC2101 adafruit board, will start working on it.... By the way, Skot, can you update this thread title, it not about 2x BM1387 (Antminer S9) anymore It is misleading for new people discovering the project. |
|
|
|
Great, did another check :
- for the CLKI signal directly on the ESP, please add a 0R (or a 33R as it is a clock) serial resistor to disconnect this signal by HW.
there is one already, it's on the BM1397 sheet. - on J3, maybe better to put 1V8 on this debug connector because all signals are on 1,8V level (and now the 3V3 is available on J6)
good idea. added. - maybe better using the 4th TSX0104 line for the CLKI signal instead of BI, and put BI on the voltage divider ? BI is low freq signal. Waht do you think about this ? I have the feeling high freq signal are better ont the TSX0104 (otherwise we should better use voltage divider for all signal from ESP to BM).
I added a SN74AXC1T45 for level shifting the BM1397 clock. If we're going to try this we should prolly do it right. the SN74AXC1T45 has a max freq of 500 Mbps (and is in stock!) - on the Fan design, I understad you plan to use a 5V FAN directly powered by our input VIN,
* Firstly, Fan usually generate lot of noise, we should consider filtering this noise.
I looked around for some thoughts on this and didn't find more more than "it's complicated". I think we might have to try this out and see where the noise is coming from. Then we can add some bypass caps, filters, etc. * Secondly, we will control this fan with a 3V3 level PWM, and the 5V TACH signal is directly on the EMC2101 pin. Maybe better using a TSX0102 for level converting 3V3/5V these 2 signals.
* Finnaly, as for this dual signal we are not sure yet of the final usage, I would do a more modular (optioal) HW design using 0R resistors. For exemple:
a/ 1 signal from the FAN TACH_3V3 (from J4 after going through TSX0102) connected to a dedicated ESP GPIO (with the 0R resistor so we can unconnect it)
b/ 1 signal from the FAN TACH_3V3 (from J4 after going through TSX0102) connected to the EMC2101 ALERT#/TACH pin (with another 0R resistor so we can unconnect it)
c/ 1 signal from the EMC2101 ALERT#/TACH pin connected to a dedicated ESP GPIO (diffeent from a/) (also with a 0R resistor so we can unconnect it)
this way we can choose by HW (some 0R resistor) the logic we want to try during the development phase.
These kinds of level conversions are exactly what the EMC2101 is supposed to solve. My hope in using it is that the ESP32 can control the fan and read the BM1397 temperature easily over I2C, without having to generate any specific timing signals. OK with current Schematic and your justifications. Another idea : can you add a couple of ESP GPIO with a pullup and a dual pin header to ground, so we can use jumper to switch SW into specific mode (for exemple, mining on a pool or with a local node RPC connection,... we will discuss these mode later when designing the SW), and a couple of LED on ESP to have status from SW also. |
|
|
|
Hey @Skot, have a look; GekkoScience just released a BM1397-based pod miner! https://bitcointalk.org/index.php?topic=5423227.0I'm trying to get my hands on one as soon as they're available to buy. I'd like to mine a bit on it, but would probably also be able to get some serial traces off it for our open-source project. I'd much rather buy this than an old, used S17 which may even arrive broken. I would also love to have Serial trace from your pod, when possible ! The offical S17 trace is also important as there may reveal some Antminer secret on the BM1397 (Antminer FPGA control board with secret Firmware, controling Antminer ASIC using Antminer undocumented protocol). The Gekko/Kano trace will not reveal more that the Kano cgminer sourcecode is already exposing. Thats why the Braiins OS+ trace is also interesting, Braiins may use some reverted secret on the control protocol, and not published the source code (except for the Braiins OS (without +) with less feature). I'm also excited to see these changes to cgminer by kano. We will have to look into individual chip tuning as well, once the single-chip device works and we try out the first multi-chip boards. [Kano] has been working on adding tuning features which include setting individual chip frequencies. Core voltage is adjustable in the range of 1.4V-1.6V per chip.
This will be very instructive indeed ! |
|
|
|
Here is my Schematic review :
- I see DS4432U+ OUT0 being used for TPS40305 control, but does the OUT1 being used somewhere ? (if not use, better not creating a signal out of the package to give ambiguity...)
- where the 5V is generated ? I see +3V3 (U11), 1V8 (U5) and 0V8 (U6) being generated from 5V, and BM1397 VDD (alias of TPS40305 VOUT) being generated from VIN_M (the monitored VIN), but nowhere the 5V beoing generated...
- on the ESP, I think you inverted TX/RX, please double check it
- can you add pin header and TP for debug purpose on the 3V3 RX/TX/RST, (additionnaly to J3), and add also I2C SDA/SCL signal on this debug pin header ?
- can you use an optional (with a serial 0R resistor) signal from a CLK_OUT of the ESP (pin 13/14/34/33/32 up to you) going to the BM1397 CLKI instead of the U1 one. I may want to try later if MCU can generate this clock by SW so we have control on the hashrate of the BM1397...
- on the BM1397 you pulled down BI (with R4) are you sure it will not being used ? on BM1385 datasheet it is noted as a Busy Input (internal schmit trugger and pull down). Maybe you can link it to a GPIO of the MCU, we will see later if needed. (and add the 3V3 signal to the debug pin header too).
- for the voltage level translators (U2/U3/U4), I used to use TSX0104 in my previous design, it is easy to use because bidirectionnal. Did you consider them ?
- for EMC2101, the ALTER#/TACH pin can be configured as input (TACH monitor to mesure Fan RPM) or output (ALERT# signal to trigger an IRQ on MCU when special temp/tach conditons are met). I see more value having an ALERT# signal from it to the MCU to trigger an interrupt for Temperature Critical exceeded (with hysteresis to deassert the signal). The FAN RPM is not very usefull for us. Also EMC2101 porpose a Look-up Table of 8 stages so we can control by hardware FAN speed accoding to BM1397 internal temperature. Maybe what you can do, is link the EMC2101 ALERT#/TACH pin to a MCU GPIO, and the FAN TACH to another MCU GPIO (be careful of voltage level here), and SW will be able to configure EMC2101 in TACH reading for some seconds, by propagating the FAN signal, then switch back to ALERT interrupt for a longer period (1h ?). So most of the time we use Interrupt monitor, and only once in a while do a fAN RPM measurement for UI needs...
- it would be usedfull to have the BM1397 VDD on a ESP ADC input to measure the BM voltage
- it would be usefull to have the TPS40305 PGOOD linked to a ESP GPIO to know if Power is Good
I checked in an update to the schematic on the max_v2 branch with all of these changes. I'm still a little iffy on the level shifting for the interface to CLKI and the fan ALERT. Great, did another check : - for the CLKI signal directly on the ESP, please add a 0R (or a 33R as it is a clock) serial resistor to disconnect this signal by HW. - on J3, maybe better to put 1V8 on this debug connector because all signals are on 1,8V level (and now the 3V3 is available on J6) - maybe better using the 4th TSX0104 line for the CLKI signal instead of BI, and put BI on the voltage divider ? BI is low freq signal. Waht do you think about this ? I have the feeling high freq signal are better ont the TSX0104 (otherwise we should better use voltage divider for all signal from ESP to BM). - on the Fan design, I understad you plan to use a 5V FAN directly powered by our input VIN, * Firstly, Fan usually generate lot of noise, we should consider filtering this noise. * Secondly, we will control this fan with a 3V3 level PWM, and the 5V TACH signal is directly on the EMC2101 pin. Maybe better using a TSX0102 for level converting 3V3/5V these 2 signals. * Finnaly, as for this dual signal we are not sure yet of the final usage, I would do a more modular (optioal) HW design using 0R resistors. For exemple: a/ 1 signal from the FAN TACH_3V3 (from J4 after going through TSX0102) connected to a dedicated ESP GPIO (with the 0R resistor so we can unconnect it) b/ 1 signal from the FAN TACH_3V3 (from J4 after going through TSX0102) connected to the EMC2101 ALERT#/TACH pin (with another 0R resistor so we can unconnect it) c/ 1 signal from the EMC2101 ALERT#/TACH pin connected to a dedicated ESP GPIO (diffeent from a/) (also with a 0R resistor so we can unconnect it) this way we can choose by HW (some 0R resistor) the logic we want to try during the development phase. |
|
|
|
Can you please push a PDF of the schematic so I can do a review.
yes, here you go; https://github.com/skot/bitaxe/blob/max_v2/bitaxeMax.pdfAbout the BM1393 voltage regulation, do you plan a voltage tuning from the MCU ?
Yes, that will be new for bitaxeMax v2. I'm using the Maxim DS4432U+ current DAC with the TPS40305 -> BM1397 core voltage adjustment will be over I2C. note on the current schematic there are a couple feedback resistor values TBD. Here is my Schematic review : - I see DS4432U+ OUT0 being used for TPS40305 control, but does the OUT1 being used somewhere ? (if not use, better not creating a signal out of the package to give ambiguity...) - where the 5V is generated ? I see +3V3 (U11), 1V8 (U5) and 0V8 (U6) being generated from 5V, and BM1397 VDD (alias of TPS40305 VOUT) being generated from VIN_M (the monitored VIN), but nowhere the 5V beoing generated... - on the ESP, I think you inverted TX/RX, please double check it - can you add pin header and TP for debug purpose on the 3V3 RX/TX/RST, (additionnaly to J3), and add also I2C SDA/SCL signal on this debug pin header ? - can you use an optional (with a serial 0R resistor) signal from a CLK_OUT of the ESP (pin 13/14/34/33/32 up to you) going to the BM1397 CLKI instead of the U1 one. I may want to try later if MCU can generate this clock by SW so we have control on the hashrate of the BM1397... - on the BM1397 you pulled down BI (with R4) are you sure it will not being used ? on BM1385 datasheet it is noted as a Busy Input (internal schmit trugger and pull down). Maybe you can link it to a GPIO of the MCU, we will see later if needed. (and add the 3V3 signal to the debug pin header too). - for the voltage level translators (U2/U3/U4), I used to use TSX0104 in my previous design, it is easy to use because bidirectionnal. Did you consider them ? - for EMC2101, the ALTER#/TACH pin can be configured as input (TACH monitor to mesure Fan RPM) or output (ALERT# signal to trigger an IRQ on MCU when special temp/tach conditons are met). I see more value having an ALERT# signal from it to the MCU to trigger an interrupt for Temperature Critical exceeded (with hysteresis to deassert the signal). The FAN RPM is not very usefull for us. Also EMC2101 porpose a Look-up Table of 8 stages so we can control by hardware FAN speed accoding to BM1397 internal temperature. Maybe what you can do, is link the EMC2101 ALERT#/TACH pin to a MCU GPIO, and the FAN TACH to another MCU GPIO (be careful of voltage level here), and SW will be able to configure EMC2101 in TACH reading for some seconds, by propagating the FAN signal, then switch back to ALERT interrupt for a longer period (1h ?). So most of the time we use Interrupt monitor, and only once in a while do a fAN RPM measurement for UI needs... - it would be usedfull to have the BM1397 VDD on a ESP ADC input to measure the BM voltage - it would be usefull to have the TPS40305 PGOOD linked to a ESP GPIO to know if Power is Good |
|
|
|
Do you think you could put together a ESP32-S3 Rust project? Maybe with a little guidance for others on how to setup the toolchain, IDE, etc? I’ve made some progress on bitaxeMax v2; https://github.com/skot/bitaxe/tree/max_v2 the schematic is pretty much done. I’ll keep working on this and hopefully we can get you some real HW soon! Yes of course, I just ordered a ESP32-S3 module to try a prototype of a project on it. Setup will be very easy, coding on Rust will need a little bit of adaptation (learning curve). I propose other people in this project to start a standard C project, and I will work on a Rust one in parrallel. I will teach anyone who want to try embedded Rust with me. Can you please push a PDF of the schematic so I can do a review. About the BM1393 voltage regulation, do you plan a voltage tuning from the MCU ? |
|
|
|
EMC2101 done in Rust https://github.com/Georges760/emc2101-rs, I need to get some HW and test/debug it now... BM13xx driver is ongoing, but I really need more log sample from Saleae Logic 2 to revert engineer the protocol (specially from a real S17). Wow, Looking good! A friend was telling me that you don’t really need a RTOS with Rust because the async libraries are so good.. does that seem right to you? I wish I had a S17 to poke around on. I’ve been watching them on eBay, but they seem so expensive still. Exactly, I plan to play around with RTIC (Real Time Interrupt-driven Concurrency) which should fit very well with our needs here : each "tasks" can be triggered by a hardware interrupt (the Alert signal from EMC2101 to trigger the shutdown for Temperature Critial reached, the Serial RX IRQ from BM1397 for a work result, etc...) |
|
|
|
EMC2101 done in Rust https://github.com/Georges760/emc2101-rs, I need to get some HW and test/debug it now... BM13xx driver is ongoing, but I really need more log sample from Saleae Logic 2 to revert engineer the protocol (specially from a real S17). |
|
|
|
I will buy a Compac F at some point, but seeing my drawers full of stuff "I will use somedays", I tend to first work on a project and then buy the hardware... So you also have a Saleae, great ! Can you provide me .logic files (Logic 2) of some serial communication ? Another great source of information was the Braiins OS that supported S17 miner, it was open source and written in Rust, but it look like Braiins did remove it from Github... I may have cloned it somewhere on my harddisk...
oooo that would be amazing to see. Found it, Github never forget ! https://github.com/xertSuns1/braiins/blob/bos-devel/open/hw/zynq-io-am1-s9/design/src/ip_cores/axi_bm13xx/hdl/bm13xx_S_AXI.vhdAlso, about the I2C temperature sensor NCT218, do you think we will keep this ref, and I can start working on a driver, or will you change the source ?
the NCT218 went out of stock. I just switched to the EMC2101. It does fan control too! Hooray integrated products from the PC motherboard world. Adafruit has some driver examples to work from; https://learn.adafruit.com/emc2101-fan-controller-and-temperature-sensorOK, let's go with EMC2101 then. About the Firmware source, I am working in Rust because : - the embedded abstraction is very well supported for ESP32-C3, and in the future, we can change the MCU easily - stratum v1 and v2 are already coded in Rust by Braiins https://github.com/braiins/braiins-open/tree/master/protocols/stratum and because v2 use Noise Protocol, it is better to not have to code it ourself - the cgminer source code is not very clean (many type mixing) and not very adapted to embedded system - will be booting/running very fast and very reliable From what I hear, embedded Rust is the new hotness. Are you pretty good at it? I'd love to learn. It seems like the ESP32-C3 modules are all lacking in RAM. We're going to need a lot to deal with the big stratum ASCII JSON messages. I was thinking about switching to the ESP32-S3 for the time being. I assume that's still decently supported in Rust? I hear you on the cgminer source. I feel like I'm going cross-eyed. In their defense, I think it's had a ton of authors over the years. All ESP32 are pretty well supported by Rust HAL https://github.com/esp-rs/esp-halThe good point is by using embedded-hal traits, we will be able to change HW easily. It will be possible for example to change for a Cortex-M + W5500 for Ethernet instead of Wifi (more reliable, quicker comm and easier to setup (no SSID connection, only DHCP needed)), or even better the W7500 (all in one chip for Ethernet). I am intermediary level at Rust, but I learn it every day, it is fascinating. My cgminer remark was not intended to be disrepectfull, but as you said, so many developer contributed over the year, it lost a bit of homogeneity... |
|
|
|
|
