Topic: sgminer: Baikal Giant X10 / N / B - Open Source - Confirmed OC Giant B! - page 3. (Read 38414 times)

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

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

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. 

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

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.

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

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. 

Take a look:
https://bitcointalksearch.org/topic/m.33090927

It's a bug in sgminer. It should be something like
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.

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:


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


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.

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.

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

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.

OC only works on the Giant B with this mod.

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

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

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!

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.

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 [email protected]

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

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

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

lsusb | grep 0483 (with v1.2)
lsusb | grep 0483 (with your firmware)