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

[Auerexport]

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?)

lsusb | grep 0483 (with v1.2)

Code:

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

lsusb | grep 0483 (with your firmware)

Code:

Bus 007 Device 014: ID 0483:5740 STMicroelectronics STM32F407

[1714171985]

1714171985

[1714171985]

1714171985

[1714171985]

1714171985

[tboy32c]

lsusb | grep 0483 (with v1.2)

Code:

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

lsusb | grep 0483 (with your firmware)

Code:

Bus 007 Device 014: ID 0483:5740 STMicroelectronics STM32F407

At least the STM shows up for you! That's better than the problem chup has.

Is 0483:5740 STMicroelectronics STM32F407 the result you have currently? If so, are you also saying you do not see the blue LED at all? IF the STM has my firmware, AND it is in RUN mode (as your last result would indicate), AND sgminer is not running (as indicated by your previous post where you ran the miner-stop script), then the blue LED should be flashing (especially if you also ran the reset_stm script as previously indicated).

Try this next if you would:

• Put the desired .bin firmware file in /media/boot
• Make sure the filename starts with a capital G
• Run md5sum /media/boot/G*.bin    -what is the result?
• Run python /usr/bin/update_fw.py   & please post the entire output of that command

[MiningKH]

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

any one already got a solution to get the sgminer running?

[Auerexport]

Is 0483:5740 STMicroelectronics STM32F407 the result you have currently? If so, are you also saying you do not see the blue LED at all? IF the STM has my firmware, AND it is in RUN mode (as your last result would indicate), AND sgminer is not running (as indicated by your previous post where you ran the miner-stop script), then the blue LED should be flashing (especially if you also ran the reset_stm script as previously indicated).

Try this next if you would:

• Put the desired .bin firmware file in /media/boot
• Make sure the filename starts with a capital G
• Run md5sum /media/boot/G*.bin    -what is the result?
• Run python /usr/bin/update_fw.py   & please post the entire output of that command

Bus 007 Device 002: ID 0483:5740 STMicroelectronics STM32F407 is the current result, blue LEDs are up, sgminer is running (with your firmware).

root@Baikal:~# md5sum /media/boot/G*.bin
d806968a965a7499b026ee558073af54  /media/boot/GX10.bin

root@Baikal:~# python /usr/bin/update_fw.py

Downloading... /media/boot/GX10.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 16616
Download        [=========================] 100%        16616 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Done

[tboy32c]

Bus 007 Device 002: ID 0483:5740 STMicroelectronics STM32F407 is the current result, blue LEDs are up, sgminer is running (with your firmware).

root@Baikal:~# md5sum /media/boot/G*.bin
d806968a965a7499b026ee558073af54  /media/boot/GX10.bin

root@Baikal:~# python /usr/bin/update_fw.py

Downloading...
Done

That all looks good except for the checksum of the bin file you're using. I'm getting b7ee4ca88a190fb086655761e1f55c6c for the stock v1.2 file. I'd try pulling the file from the v1.2 OrangePi image and try again. Remember to revert back to the stock v1.2 sgminer too.

[Auerexport]

Bus 007 Device 002: ID 0483:5740 STMicroelectronics STM32F407 is the current result, blue LEDs are up, sgminer is running (with your firmware).

root@Baikal:~# md5sum /media/boot/G*.bin
d806968a965a7499b026ee558073af54  /media/boot/GX10.bin

root@Baikal:~# python /usr/bin/update_fw.py

Downloading...
Done

That all looks good except for the checksum of the bin file you're using. I'm getting b7ee4ca88a190fb086655761e1f55c6c for the stock v1.2 file. I'd try pulling the file from the v1.2 OrangePi image and try again. Remember to revert back to the stock v1.2 sgminer too.

Seems like i really had a broken GX10.bin file... i extracted the bin file again from trhe v1.2 img and ran md5sum again. result: b7ee4ca88a190fb086655761e1f55c6c
python /usr/bin/update_fw.py worked, miner is up normal state.

Thanks a lot, tboy32c - good job! :-)
Now i can confirm rollback is working!

[MiningKH]

Hi guys, sgminer runs. OC does not work with my experiment.

https://s15.directupload.net/images/190106/jgwdnl4v.jpg

[astraleureka]

OC only works on the Giant B with this mod.

[MiningKH]

OC only works on the Giant B with this mod.

AAmmmm.... no. I think you should read the thread right times.  


OK guys. Realy good news. After hours....and hours....and hours..... I can confirm OC at BK-X 

Stock Clock

https://s15.directupload.net/images/190106/587w6mmn.jpg

OC Clock

https://s15.directupload.net/images/190106/anc9gdxn.jpg

A big thanks to cod3gen and toby32c. You've done an awesome job.

[PS3Miner]

Hey MiningKH,

could you finally compile the source code from github of cod3gen?
Is the compiled SW recognizing the hasboard?
If no which FW are you using right now?

Are you tested other coins regarding the OC?

It would be great if you could provide a brief guide on how to get it done.

Cheers

[MiningKH]

Hey MiningKH,

could you finally compile the source code from github of cod3gen?
Is the compiled SW recognizing the hasboard?
If no which FW are you using right now?

Are you tested other coins regarding the OC?

It would be great if you could provide a brief guide on how to get it done.

Cheers

Hi, FW from toby32c. Sgminer of cod3gen from github. I'll put a downloadlink here in the next few days. Because the sgminer of github does not work right away. I checked all the files individually and changed them if necessary.

And unfortunately it is not possible to clock the miner over 390Mhz. no idea why.

[tboy32c]

For clarification to anyone who is thinking their miner is overclocked or underclocked by looking only at the hash rate sgminer reports:

As defined by the baikal_hash_done() function in sgminer:driver-baikalu.c:

Code:

[Displayed Hash Rate (in GHz)] = [clock (in MHz)] * [ASIC count] * [ALGO modifier] / 1000000

Note: clock is hardcoded in sgminer (see #define BAIKAL_CLK_DEF in sgminer:driver-baikal.h)

Code:

[ALGO modifier] (defined by Baikal in sgminer) =
X11/QUARK/QUBIT/NIST/MYRIAD_GROESTL/GROESTL: 120
SKEIN2: 62
X11GOST: 16

example (single hashboard):
clock = 300MHz
ASICs = 64
ALGO = Groestl, so modifier = 120
therefore 300 * 64 * 120 / 1000000 = 2.304 (GHz)

Note that the hash rate value you see reported by sgminer is not based on what the hash rate actually is, but rather what it should be (given all your ASICs are working and everything is stock). Imagine you did a 200% hardware overclock without any software changes - sgminer would still report the original hash rate because it would still be using the same hardcoded BAIKAL_CLK_DEF, see the same number of ASICs, and be on the same algorithm (i.e. the only inputs to the hash rate calculation as explained above). If you want, it's trivial to modify the web interface code or sgminer to display an arbitrary hash rate but it does not mean you're actually getting that hash rate. sgminer does not get any direct feedback from the STM controller regarding the actual hash rate. If you really want to know your true hash rate, check the pool you're mining at. They'll use the number of accepted shares vs. time & difficulty to calculate your actual hash rate.

BAIKAL_CLK_DEF is sent to the STM, but it does not actually set the hashing speed.

[tboy32c]

And unfortunately it is not possible to clock the miner over 390Mhz. no idea why.

Take a look:
https://bitcointalk.org/index.php?topic=2790982.msg33090927#msg33090927

It's a bug in sgminer. It should be something like

Code:

((clk - 200) / 10) + 2

instead. However it doesn't really matter (for the reasons mentioned in my last post) so I didn't bother correcting it in the version I posted.

[MiningKH]

For clarification to anyone who is thinking their miner is overclocked or underclocked by looking only at the hash rate sgminer reports:

As defined by the baikal_hash_done() function in sgminer:driver-baikalu.c:

Code:

[Displayed Hash Rate (in GHz)] = [clock (in MHz)] * [ASIC count] * [ALGO modifier] / 1000000

Note: clock is hardcoded in sgminer (see #define BAIKAL_CLK_DEF in sgminer:driver-baikal.h)

Code:

[ALGO modifier] (defined by Baikal in sgminer) =
X11/QUARK/QUBIT/NIST/MYRIAD_GROESTL/GROESTL: 120
SKEIN2: 62
X11GOST: 16

example (single hashboard):
clock = 300MHz
ASICs = 64
ALGO = Groestl, so modifier = 120
therefore 300 * 64 * 120 / 1000000 = 2.304 (GHz)

Note that the hash rate value you see reported by sgminer is not based on what the hash rate actually is, but rather what it should be (given all your ASICs are working and everything is stock). Imagine you did a 200% hardware overclock without any software changes - sgminer would still report the original hash rate because it would still be using the same hardcoded BAIKAL_CLK_DEF, see the same number of ASICs, and be on the same algorithm (i.e. the only inputs to the hash rate calculation as explained above). If you want, it's trivial to modify the web interface code or sgminer to display an arbitrary hash rate but it does not mean you're actually getting that hash rate. sgminer does not get any direct feedback from the STM controller regarding the actual hash rate. If you really want to know your true hash rate, check the pool you're mining at. They'll use the number of accepted shares vs. time & difficulty to calculate your actual hash rate.

BAIKAL_CLK_DEF is sent to the STM, but it does not actually set the hashing speed.

Aarrg. F****k. You´r right toby32c. The sgminer shows 390Mhz and 9Gh Hashrate. But on Poolside shows only 7Gh (stock with you FW).
Now i have only change the hash-done value from 120 to 190. Sgminer shows 12.4GH at 340Mhz. But not on the poolside. Only 7GH. 

[astraleureka]

Thanks tboy32c, very succinct explanation as to why this is the case.

[cod3gen]

OC only works on the Giant B with this mod.

AAmmmm.... no. I think you should read the thread right times.  


OK guys. Realy good news. After hours....and hours....and hours..... I can confirm OC at BK-X 

Stock Clock



OC Clock



A big thanks to cod3gen and toby32c. You've done an awesome job.

Like tboy32c says, does not mather what you change on definitions in code, the hashrate output is only "static"/estimated value based on compiled clock speed.

[bittawm]

selling baikals Giant Bs and G28s much cheaper than baikal themselves and immediate shipping

[chup]

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.

Well, Baikal was faster than me trying to reroute USBs. They managed to send control board right after the holiday and I received it two days later. BK-X is happily mining again. 

[MiningKH]

Hi,
here is the downloadlink of sgminer there works on BK-X. Have fun and share all new knowleg.

https://drive.google.com/open?id=1az2RBtF_6189UQahAr0iZIh_4fHrjN3p

[astraleureka]

There is no data in any of the files included in your zip