 Show Posts
|
|
Pages: [1] 2 »
|
keep up the good work gents, still watching
why dont you join in and leave the sidelines? |
|
|
|
Hi guys ,
Pay 0.2 BTC for working tutorial how to OVERCLOCK Baikal x10
from 300MHz to 400 Mhz  How to claim 0.2 ? Must show me video on PM ESCROW I dont know if I win the 0.2 but the reason is simple, all giant a algo have a string lenght take and calculed by the baikal at the 300mhz clock so if you change the frequency the only think happen is a lot of invalid share that it ! I think you need to provide more details on how you accomplished overclocking it, not keeping the 300MHz the same |
|
|
|
I've tried flashing the Giant B firmware to an X10 and running the Giant B image on the Pi but no luck converting an X10 to GB or using that firmware image to overclock (so far).
Interesting that the controller boards are the same, but not surprising. I can't find the difference between those two STM model numbers anywhere online. Could the last couple lines just be batch numbers?
I DID take the heatsink off an X10 and the model number on the asic is this:
[Baikal Logo]
BK177280
ND33U
I'd upload a picture, but the chips are too small for my potato camera.
<Your move Giant-B owners!>
Yes. If chips on Giant B are different only way is to modify firmware to comunicate with x10 chips. Or B to X10 When you took off the heat sink, was there any thermal paste? And did you replace it? |
|
|
|
honestly the only way to truly know if they are different is if somebody has the balls to take the heat sinks off both the X10 and GB and see if the ASICs have model numbers on them
 hahaha, love it! I'm sure someone has done this before. TEST WAS ALLREADY DONE SIR #1 - INSTALLED SGMINER-A SGMINER-B SGMINER-2000 start in ssh all exec bin on each baikal reserve test all ... nothing add algo or give bonus #2 - put firmware 300mhz cube on x10 a - NOT WORKING COMPLETE BROKE THE ARM PLATE BLUE #3 - echange GIANT B on GIANT A AND REVERSE - NOT WORKING #4 - put firmware GIANT B on GIANT A - NOT WORKING Did you chang the STM firmware? Not just the SD card on the orange pi? On the Giants I EXTRACT THE FIRMWARE OF THE ARM WITH THE SCRIPT ON USR BIN AND I PUSH UP THE FIRMWARE ON THE GIANT B PLATE WITH THE SAME SCRIPT fw-upgrade.... He only other thing I would try is to swap the STM board + OrangePi of Giant A and Swap with Giant B. Leave original code as is. That would mean that we could order spare parts for each type and use hashboards |
|
|
|
honestly the only way to truly know if they are different is if somebody has the balls to take the heat sinks off both the X10 and GB and see if the ASICs have model numbers on them
hahaha, love it! I'm sure someone has done this before. TEST WAS ALLREADY DONE SIR #1 - INSTALLED SGMINER-A SGMINER-B SGMINER-2000 start in ssh all exec bin on each baikal reserve test all ... nothing add algo or give bonus #2 - put firmware 300mhz cube on x10 a - NOT WORKING COMPLETE BROKE THE ARM PLATE BLUE #3 - echange GIANT B on GIANT A AND REVERSE - NOT WORKING #4 - put firmware GIANT B on GIANT A - NOT WORKING Did you chang the STM firmware? Not just the SD card on the orange pi? On the Giants |
|
|
|
|
Your also assuming their imaged and ready to go.
Either way, lets see. I know we all want to know.
|
|
|
|
honestly the only way to truly know if they are different is if somebody has the balls to take the heat sinks off both the X10 and GB and see if the ASICs have model numbers on them
hahaha, love it! I'm sure someone has done this before. |
|
|
|
There are 3 parts inside the Bikal miner
1) OrangePi
2) Control Board
3) Hashing boards
Can you try swapping the OrangePi and Control Board and leaving the hashing boards the same between the x10 and Giant B? @ismurdegus, have you tried this yet? See if it's just the control board determining the algo's, if it works, then maybe all you need to do is clone the control board to switch between the X10 and Giant B. I will send you the link to the Giant B and X10 firmwares shortly. If you want to try and see if you can run the GB setup feel free. Obviously you do this and could risk damaging something. If you decide to do this, limit your risk. By using your spare board and spare Orange Pi to be safe - Download the GB Image from Baikal
- Flash a spare SDcard with the Giant b image
- Place the GB firmware bin file in the folder “/media/boot/“
- Inster SD Card in OrangePi
- Rebuild miner and boot up
If everything we understand about the miner is true, that they are the same hardware, just with different firmwares, you would have effectively been the first known individual that has successfully transitioned the miner if all goes well. |
|
|
|
|
I'm under the impression from reading the STM chip manufacturer documents that it is flashed via USB or through the OrangePI Zero in this case.
|
|
|
|
You are missing the crucial part when replacing the images of the OrangePI. The firmware bin file for the STM chip. The STM chip has a specific set of algorithms pre-coded into the firmware code. You cannot get around it. You will have to get the running bin file from a Giant B or X10's STM chip and place it in the "/media/boot/" folder and call it, "G*.bin" When the miner reboots on the new image of the miner it will compare versions and replace the existing flashed image by entering DFU Mode. Once updated, it will reenable the hash boards and being mining. It's doable. The reason behind that is that the file location and name is here, update_fw.py. Located in the \usr\bin folder. #!/usr/bin/env python
import subprocess
import os
import sys
from subprocess import Popen, PIPE
import fcntl
import time
import glob
tmpfile = '/home/baikal/tmp.bin'
path = '/media/boot/G*.bin'
fwfile = glob.glob(path)
if not fwfile:
print 'No firmware'
sys.exit()
USBDEVFS_RESET= 21780
# enter dfu mode
def enter_dfumode():
subprocess.call('echo 0 > /sys/class/gpio_sw/PA18/data', shell=True)
subprocess.call('echo 0 > /sys/class/gpio_sw/PA10/data', shell=True)
subprocess.call('echo 1 > /sys/class/gpio_sw/PA10/data', shell=True)
def exit_dfumode():
subprocess.call('echo 1 > /sys/class/gpio_sw/PA18/data', shell=True)
subprocess.call('echo 0 > /sys/class/gpio_sw/PA10/data', shell=True)
subprocess.call('echo 1 > /sys/class/gpio_sw/PA10/data', shell=True)
def reset_usb(driver):
try:
lsusb_out = Popen("lsusb | grep -i %s"%driver, shell=True, bufsize=64, stdin=PIPE, stdout=PIPE, close_fds=True).stdout.read().strip().split()
bus = lsusb_out[1]
device = lsusb_out[3][:-1]
f = open("/dev/bus/usb/%s/%s"%(bus, device), 'w', os.O_WRONLY)
fcntl.ioctl(f, USBDEVFS_RESET, 0)
except Exception, msg:
print ""
def update_firmware():
enter_dfumode()
reset_usb("DFU")
print 'Downloading... ' + fwfile[0]
cmd = 'sudo dfu-util -a 0 -d 0483:df11 -s 0x08000000:leave -D ' + fwfile[0]
subprocess.call(cmd, shell=True)
cmd = 'sudo rm -rf ' + path
subprocess.call(cmd, shell=True)
enter_dfumode()
reset_usb("STM32F407")
reset_usb("DFU")
update_firmware()
exit_dfumode()
print "Done"
|
|
|
|
The filename must start with G. The reason behind that is that the file, update_fw.py. Located in the \usr\bin folder. #!/usr/bin/env python
import subprocess
import os
import sys
from subprocess import Popen, PIPE
import fcntl
import time
import glob
tmpfile = '/home/baikal/tmp.bin'
path = '/media/boot/G*.bin'
fwfile = glob.glob(path)
if not fwfile:
print 'No firmware'
sys.exit()
USBDEVFS_RESET= 21780
# enter dfu mode
def enter_dfumode():
subprocess.call('echo 0 > /sys/class/gpio_sw/PA18/data', shell=True)
subprocess.call('echo 0 > /sys/class/gpio_sw/PA10/data', shell=True)
subprocess.call('echo 1 > /sys/class/gpio_sw/PA10/data', shell=True)
def exit_dfumode():
subprocess.call('echo 1 > /sys/class/gpio_sw/PA18/data', shell=True)
subprocess.call('echo 0 > /sys/class/gpio_sw/PA10/data', shell=True)
subprocess.call('echo 1 > /sys/class/gpio_sw/PA10/data', shell=True)
def reset_usb(driver):
try:
lsusb_out = Popen("lsusb | grep -i %s"%driver, shell=True, bufsize=64, stdin=PIPE, stdout=PIPE, close_fds=True).stdout.read().strip().split()
bus = lsusb_out[1]
device = lsusb_out[3][:-1]
f = open("/dev/bus/usb/%s/%s"%(bus, device), 'w', os.O_WRONLY)
fcntl.ioctl(f, USBDEVFS_RESET, 0)
except Exception, msg:
print ""
def update_firmware():
enter_dfumode()
reset_usb("DFU")
print 'Downloading... ' + fwfile[0]
cmd = 'sudo dfu-util -a 0 -d 0483:df11 -s 0x08000000:leave -D ' + fwfile[0]
subprocess.call(cmd, shell=True)
cmd = 'sudo rm -rf ' + path
subprocess.call(cmd, shell=True)
enter_dfumode()
reset_usb("STM32F407")
reset_usb("DFU")
update_firmware()
exit_dfumode()
print "Done"
|
|
|
|
|
I'm 99% sure, if we place the extracted firmware (*.bin) of an X10 in the SD card in the boot folder, it will reimage the firmware with the same image in the STM chip.
Same thing should apply to the GB.
Therefore if I get a X10 image with bin file in the boot folder and start up a GB with that SD card, it should reflash the STM chip with the coding of an X10 and in theory work.
|
|
|
|
Look in this folder \var\www\partials. There you will find the miner.html file.
This is where sgminer gets its names from on which algorithms to mine.
Obviously sgminer needs to have the matching name already programmed in it for it to connect to the pools.
I've tried it several times. But I did not do it anywhere. It must either be in sgminer or rather in FW STM. What was it that you tried? To add the algorithms to the drop down list? Yes exactly. Also change the algorithm and pool data in \opt\scripta\etc files miner.conf and miner.pools.json And Miner ran to default algo: Quarkcoin The only place I was able to find the list of Algorithms was in the miner.html page. I added all other possible algorithms supported on sgminer as of version 5.6.1. When I did that I was able to connect to some pools of those algorithms. Some others I could not. The ones that did connect to the pools, the devices kept defaulting to the Blakecoin algorithm, which I believe is the default for GB. |
|
|
|
Look in this folder \var\www\partials. There you will find the miner.html file.
This is where sgminer gets its names from on which algorithms to mine.
Obviously sgminer needs to have the matching name already programmed in it for it to connect to the pools.
I've tried it several times. But I did not do it anywhere. It must either be in sgminer or rather in FW STM. What was it that you tried? To add the algorithms to the drop down list? |
|
|
|
|
Look in this folder \var\www\partials. There you will find the miner.html file.
This is where sgminer gets its names from on which algorithms to mine.
Obviously sgminer needs to have the matching name already programmed in it for it to connect to the pools.
|
|
|
|
|
Yes, correct.
Top Layer is Orange Pi
Middle Layer is STM Chip on board
Bottom Layer is 3 hash boards
|
|
|
|
|
The list is coming from a static html file, called miner.html. You can add a complete list of algorithms that sgminer supports. However because the firmware on the chip doesn't have the library the miners will default to the base algorithm. On the Giant B it defaults to Blake. Not sure about the X10.
What I have done on my GB, I have added the list and noticed that many will connect to the pools correctly and will send data back and forth, and show as live on the status page of the miner. Those that do connect come back with 99.9% reject errors, not because sgminer didn't have the code, but because of the hardware is incorrectly hashing with the Blake algorithm instead of using the one selected by sgminer.
By telling sgminer to use cryptonight or nist5 for example, it works, as it passes along the commands to the hardware. However, the hardware level (STM Chip Firmware) is stopping us from reaching our goal of adding them and running those additional coins.
I'm very certain this can be accomplished, but its a bit beyond me at this point. We need a C Programmer with STM Chip programming experience.
|
|
|
|
|
Once you pay for hardware, it’s yours. You can do as you wish with it. If You create an image file that allow us to run new algo’s who’s going to stop that if it’s given free... no one. Also, they have no patents or anything of that nature in the US. And since they don’t respect the US’s patents.
Here’s my response to them getting rich off of us, Oh well...
|
|
|
|
|
Basically we need a hardware engineer/programmer to get this going in the direction we all want.
We don’t care to overclock, we care to mine coins on asic not yet available to the public. Which yield enormously higher daily revenues.
We want to beat Baikal and Bitmain to the punch.
If you all are in agreement let’s figure this out and make it happen.
|
|
|
|
|
