sgminer: Baikal Giant X10 / N / B - Open Source - Confirmed OC Giant B!

[cod3gen]

Nice work! How long have you guys had these running? 

Personally since about May, on a single hash board. At that time I needed to transition to another unrelated project and promptly forgot all about crypto for a few months. flexmeister wasn't the collaborator I was originally referring to and I'm guessing only for a few days for them since their solution seems to use the same firmware & sgminer that I posted, if I'm not mistaken. Here's a screenshot of the Groestlcoin network hash rate around that time:

Sure thing: https://drive.google.com/open?id=1c6klf2gfuawZqOiOC7cHuWijc_iUxqXc . I apologize for not having the time to do this earlier.

Too bad you did not share.... 

Updated github with tboy branch and changed code. Let me know if any is wrong as i will not be checking functionality to verify.
https://github.com/cod3gen/sgminer-baikal/tree/tboy32c

No luck on Keecak? I guess you would answer no anyhow.. 

[1714607685]

1714607685

[1714607685]

1714607685

[flexmeister]

Thanks for sharing the code, I'll make the changes to support MBC tomorrow

Someone must have made a lot of $$$ on groestlcoin lol

If I may ask, how did you change the STM32 firmware?

[PS3Miner]

Hello flexmeister,
in your package is a file "mbx10" included. I can imagine for further support you should explain, why the file was as "elf" compiled?
It seems, you could find out a way, to inject somehow a code at runtime, in order to increase the hash rate. Unfortunaely you implemented an IP Checker to ensure the usage of your mining pool. It's not serous work. Please provide the scource code for more trust in your work / behaviour.
Cheers

[MiningKH]

If I may ask, how did you change the STM32 firmware?

That would also interest me very much.

Updated github with tboy branch and changed code. Let me know if any is wrong as i will not be checking functionality to verify.
https://github.com/cod3gen/sgminer-baikal/tree/tboy32c

Hi cod3gen,

in the file "algorithm.c" there is a mistake. Can´t create the sgminer file.
Line >>>1607 and 1611<<< there is a double.

And in file "driver-baikal.h" line >>>56<<< is missing a ")"
After fix that, it works and create the sgminer file.


Goes on  ..... sgminer does not work .... after 2-3 sec the miner always crashes.

best regards

[belaweb2]

Hi guys,
Do I understand it correctly that DiamondGroestl is added, not Groestl and not SKEIN2.
Did I miss something?

Thanks and good work!!! :-)

[Auerexport]

Rollback is working.

Same here, "No devices running" can you please explain how to rollback proper? ty

[PS3Miner]

Store the backup file into media/boot and reboot your device. Ensure the filename begins with "G"...bin
Cheers

[Auerexport]

Store the backup file into media/boot and reboot your device. Ensure the filename begins with "G"...bin
Cheers

unfortunately didn't work. so i decided to reflash sd card with org. image v1.1 and/or v1.2 - still not working. hashboards are showing only red leds :-(
i've already trieded to change sd cards and orange pi - doesn't matter, hashboards don't work- leds red.

[chup]

Store the backup file into media/boot and reboot your device. Ensure the filename begins with "G"...bin
Cheers

unfortunately didn't work. so i decided to reflash sd card with org. image v1.1 and/or v1.2 - still not working. hashboards are showing only red leds :-(
i've already trieded to change sd cards and orange pi - doesn't matter, hashboards don't work- leds red.

Wellcome to the club of bricked X10s.

If You put GX10.bin in /media/boot folder and execute

sudo update_fw.py

are You getting

dfu-util: No DFU capable USB device available

message?

[cod3gen]

If I may ask, how did you change the STM32 firmware?

That would also interest me very much.

Updated github with tboy branch and changed code. Let me know if any is wrong as i will not be checking functionality to verify.
https://github.com/cod3gen/sgminer-baikal/tree/tboy32c

Hi cod3gen,

in the file "algorithm.c" there is a mistake. Can´t create the sgminer file.
Line >>>1607 and 1611<<< there is a double.

And in file "driver-baikal.h" line >>>56<<< is missing a ")"
After fix that, it works and create the sgminer file.


Goes on  ..... sgminer does not work .... after 2-3 sec the miner always crashes.

best regards

Updated. Feel free to apply fixes and create pull requests.

[flexmeister]

Found the same, tried adding support for diamond-grs but sgminer fails with segmentation fault when running

Goes on  ..... sgminer does not work .... after 2-3 sec the miner always crashes.

best regards

[MiningKH]

Found the same, tried adding support for diamond-grs but sgminer fails with segmentation fault when running

Goes on  ..... sgminer does not work .... after 2-3 sec the miner always crashes.

best regards

Yes, i don´t know what is the failure. The Miner dont´t start with other algos too.

[Auerexport]

Store the backup file into media/boot and reboot your device. Ensure the filename begins with "G"...bin
Cheers

unfortunately didn't work. so i decided to reflash sd card with org. image v1.1 and/or v1.2 - still not working. hashboards are showing only red leds :-(
i've already trieded to change sd cards and orange pi - doesn't matter, hashboards don't work- leds red.

Wellcome to the club of bricked X10s.

If You put GX10.bin in /media/boot folder and execute

sudo update_fw.py

are You getting

dfu-util: No DFU capable USB device available

message?

witch GX10.bin? original one? and witch update_fw.py ? meanwhile i've changed psu, sd card, hashboard.... looks like control board is defective

[PS3Miner]

Hey cod3gen,
which fw.bin must be used for the compiled "sgminer_sw"?
The SW starts but the connection to the hasboards are not established.
Cheers

[tboy32c]

If I may ask, how did you change the STM32 firmware?

That would also interest me very much.

Spending a lot of time poking at the miner. You'll need to have a decent background in software & hardware.

Nice work! How long have you guys had these running? 

Personally since about May, on a single hash board. At that time I needed to transition to another unrelated project and promptly forgot all about crypto for a few months.

Too bad you did not share.... 

I had just spent several months of my free time reverse engineering with the collaborator so a few months of slightly higher profit mining helped make me feel a little better about trading a small part of my life away for it.

No luck on Keecak? I guess you would answer no anyhow.. 

Looks like I have a comment in the firmware for keccak saying "experimental" so I don't think I got it working, although I don't remember putting much time into figuring out why not.

Do I understand it correctly that DiamondGroestl is added, not Groestl and not SKEIN2.

I can only vouch for Groestl with the software I posted.

Rollback is working.

Store the backup file into media/boot and reboot your device. Ensure the filename begins with "G"...bin
Cheers

unfortunately didn't work. so i decided to reflash sd card with org. image v1.1 and/or v1.2 - still not working. hashboards are showing only red leds :-(
i've already trieded to change sd cards and orange pi - doesn't matter, hashboards don't work- leds red.

Wellcome to the club of bricked X10s.

witch GX10.bin? original one? and witch update_fw.py ? meanwhile i've changed psu, sd card, hashboard.... looks like control board is defective

From these quotes I'm not sure if there are actual "bricking" problems or if people are just having trouble with the steps to change firmware. I will confirm that I am able to rollback firmware from the firmware image I posted. If ONLY the red LEDs are showing, then that should mean the control board is in firmware update mode. If the red LEDs are on and you see a blue flashing LED, then the control board is in RUN mode but sgminer has not given it work to do (either sgminer died or the pools are all down, etc). If you see blue solid LEDs then it's hashing. If you don't see any LEDs then your device is not powered .

If you run update_fw.py and get:

Code:

dfu-util: No DFU capable USB device available

you can try editing the update_fw.py script by commenting out (adding a "#" at the start of the line) the last couple lines:

Code:

#update_firmware()
#exit_dfumode()

Run the modified script and it should have reset the STM and left it in firmware update mode. Then run:

Code:

lsusb | grep 0483

And the result sholuld be this:

Code:

Bus 007 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

(the "device" number will vary)
If instead you get:

Code:

ID 0483:5740 STMicroelectronics STM32F407

we'll have to go from there.

[chup]

If you run update_fw.py and get:

Code:

dfu-util: No DFU capable USB device available

you can try editing the update_fw.py script by commenting out (adding a "#" at the start of the line) the last couple lines:

Code:

#update_firmware()
#exit_dfumode()

Run the modified script and it should have reset the STM and left it in firmware update mode. Then run:

Code:

lsusb | grep 0483

And the result sholuld be this:

Code:

Bus 007 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

(the "device" number will vary)
If instead you get:

Code:

ID 0483:5740 STMicroelectronics STM32F407

we'll have to go from there.

Here is what I get after commenting exit from DFU Mode in update_fw.py and running it with v1.2 GX10.bin:

Code:

Done
root@Baikal:/usr/bin# lsusb | grep 0483
root@Baikal:/usr/bin# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@Baikal:/usr/bin#

[Auerexport]

From these quotes I'm not sure if there are actual "bricking" problems or if people are just having trouble with the steps to change firmware. I will confirm that I am able to rollback firmware from the firmware image I posted. If ONLY the red LEDs are showing, then that should mean the control board is in firmware update mode. If the red LEDs are on and you see a blue flashing LED, then the control board is in RUN mode but sgminer has not given it work to do (either sgminer died or the pools are all down, etc). If you see blue solid LEDs then it's hashing. If you don't see any LEDs then your device is not powered .

If you run update_fw.py and get:

Code:

dfu-util: No DFU capable USB device available

you can try editing the update_fw.py script by commenting out (adding a "#" at the start of the line) the last couple lines:

Code:

#update_firmware()
#exit_dfumode()

Run the modified script and it should have reset the STM and left it in firmware update mode. Then run:

Code:

lsusb | grep 0483

And the result sholuld be this:

Code:

Bus 007 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

(the "device" number will vary)
If instead you get:

Code:

ID 0483:5740 STMicroelectronics STM32F407

we'll have to go from there.

I can not confirm rolling back to 1.2. If i try to, controler board stays in DFU mode (red LEDs). With your custom firmware the device is running fine, but with lower hashrate. (3,5Gh @skein).

I did those steps:

Code:

./opt/scripta/startup/miner-stop.sh
python /usr/bin/update_fw.py
python reset_stm.py
lsusb | grep 0483

[tboy32c]

Here is what I get after commenting exit from DFU Mode in update_fw.py and running it with v1.2 GX10.bin:

Not getting any STM devices in that list is pretty odd. Obviously if you haven't tried you should completely power cycle the miner and try again. In order to determine if the problem lies with the OrangePi or STM you could do this:

• Remove the OrangePi from the controller board (important). Leave the Ethernet connected.
• Use a USB cable to connect the USB device connector on the controller board with the USB A host port on the Orange Pi
• Use another USB cable to connect the Orange Pi's micro USB port to any other powered device's USB host port (to power the Orange Pi)
• Run the lsusb | grep 0483 command again.

A working setup will show the STM device on Bus 006 (not 007 like when the OrangePi is seated on the controller board directly). If this time you DO get something, then the USB port on the Pi pin headers isn't working, but the STM probably is. If you still get nothing, you could swap controller boards with another Baikal Giant miner (if you have another) and try again.

What was the last firmware you successfully flashed (the one I posted? flexmeister's? One of the stock images?)

[tboy32c]

I can not confirm rolling back to 1.2. If i try to, controler board stays in DFU mode (red LEDs).

I did those steps:

Code:

./opt/scripta/startup/miner-stop.sh
python /usr/bin/update_fw.py
python reset_stm.py
lsusb | grep 0483

What does this command show when you run it?

Code:

lsusb | grep 0483

Either there's nothing, or something with "STMicroelectronics" in it.

Same question as to chup: What was the last firmware you successfully flashed (the one I posted? flexmeister's? One of the stock images?)

[chup]

Not getting any STM devices in that list is pretty odd. Obviously if you haven't tried you should completely power cycle the miner and try again. In order to determine if the problem lies with the OrangePi or STM you could do this:

• Remove the OrangePi from the controller board (important). Leave the Ethernet connected.
• Use a USB cable to connect the USB device connector on the controller board with the USB A host port on the Orange Pi
• Use another USB cable to connect the Orange Pi's micro USB port to any other powered device's USB host port (to power the Orange Pi)
• Run the lsusb | grep 0483 command again.

A working setup will show the STM device on Bus 006 (not 007 like when the OrangePi is seated on the controller board directly). If this time you DO get something, then the USB port on the Pi pin headers isn't working, but the STM probably is. If you still get nothing, you could swap controller boards with another Baikal Giant miner (if you have another) and try again.

What was the last firmware you successfully flashed (the one I posted? flexmeister's? One of the stock images?)

I'm getting same result after power cycling the X10, sending v1.2 GX10.bin in /media/boot and running modified update_fw.py.
Thank You for Your time trying to help me unbrick X10. I will try to find time today to make tests with USB rerouting. If not today, it will be my first task in New Year. 
Last I flashed flexmeister mistakenly published "blank" (with zeroes) GX10.bin. Flexmeister later reuploaded correct firmware. Flash was on unit previously running Your Groestl GX10.bin.