This lowered my yoli evo power usage by alot! Im about .93w per gig after setting it to 550/830.
Since im having issues with the firmware compiling i wanted to ask if anyone else has or can build the later firmware updated from hashfast?? My cards are running 0.6.0 and the latest is 0.8.0 but i cant compile the firmware or bootloader. I installed all the packages and built the hashfast tools folder without issues on ubuntu and only found some steps not mentioned in the read me listed in the comments of the source code which allowed me to finish compiling the tools to flash the firmware but i hit a brick wall when it comes to the firmware.
If someone can make the updates i will pay $25 for each one.
Topic: HF - Tool to set voltages (Read 8961 times)
Hey everyone we are able to release a tool that allows you to adjust your voltage settings for your Evo and Habanero boards.
HF has provided us with a python 3 script that we are allowed to distribute.
Basically in a nutshell this is good to use ONLY if your trying to push your boards past 900Mhz because you will need to increase the voltage on the board in order to give the chip more power.
USE AT YOUR OWN RISK, please read the LICENSE FILE first before using this tool.
This only works with one miner plugged in at a time!
The hftool.py utility is used to query and manipulate hashfast module settings.
Requirements:
Python 3.x
pip for Python 3.x
Pyusb
Installing pip for python 3 on most unix systems (command for ubuntu below)
sudo apt-get install python3-pip
hftool requires pyusb. To install it:
pip3 install --pre pyusb
Put these into a file /etc/udev/rules.d/01-hashfast.rules:
You will need root access to create this file and also when done its recommended you reboot in order for these rules to take effect.
RUNNING
Start the tool by with:
Read die frequencies and voltages:
Write die frequencies and settings:
example would be setting all dies to .930 volts at 875Mhz
You can grab it from Bitbucket Git depo here https://bitbucket.org/gateway69/hf-tool
AND no I dont work for HF, we pushed them to get a tool released so our customers of our Habanero boards could tweak and push their boards.
Order your Habanero from Batch 2 today for $850 here
HF has provided us with a python 3 script that we are allowed to distribute.
Basically in a nutshell this is good to use ONLY if your trying to push your boards past 900Mhz because you will need to increase the voltage on the board in order to give the chip more power.
USE AT YOUR OWN RISK, please read the LICENSE FILE first before using this tool.
This only works with one miner plugged in at a time!
The hftool.py utility is used to query and manipulate hashfast module settings.
Requirements:
Python 3.x
pip for Python 3.x
Pyusb
Installing pip for python 3 on most unix systems (command for ubuntu below)
sudo apt-get install python3-pip
hftool requires pyusb. To install it:
pip3 install --pre pyusb
Put these into a file /etc/udev/rules.d/01-hashfast.rules:
You will need root access to create this file and also when done its recommended you reboot in order for these rules to take effect.
Code:
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="0001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev”, ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="8001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff6", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="8001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff6", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"
RUNNING
Start the tool by with:
Code:
$ ./hftool.py -h
Read die frequencies and voltages:
Code:
$ ./hftool.py -r
Write die frequencies and settings:
Code:
$ ./hftool.py -w 0:VLT@FRQ,1:VLT@FRQ,2:VLT@FRQ,3:VLT@FRQ
example would be setting all dies to .930 volts at 875Mhz
Code:
$ ./hftool.py -w 0:930@875,1:930@875,2:930@875,3:930@875
You can grab it from Bitbucket Git depo here https://bitbucket.org/gateway69/hf-tool
AND no I dont work for HF, we pushed them to get a tool released so our customers of our Habanero boards could tweak and push their boards.
Order your Habanero from Batch 2 today for $850 here
Thanks for sharing this informative post...building it and doing it great!
Sorry for the Xpost (Habanero thread), but the latest cgminer supports:
https://bitcointalksearch.org/topic/m.9431142
Built it and it's looking good so far!
Quote
- Hashfast voltage support for Yoli/Habanero/Bitcrane etc. boards (see ASIC-README)
https://bitcointalksearch.org/topic/m.9431142
Built it and it's looking good so far!
Got it working on 12.04 LTS...
Code:
sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
Then install the python3 from source code:
wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz
tar xvf Python-3.4.0.tar.xz
cd Python-3.4.0
./configure
make
make test
sudo make install
sudo pip3.4 install --pre pyusb
(or sudo pip3.4 install pyusb I can't remember now)
python3.4 hftool.py -r
Then install the python3 from source code:
wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz
tar xvf Python-3.4.0.tar.xz
cd Python-3.4.0
./configure
make
make test
sudo make install
sudo pip3.4 install --pre pyusb
(or sudo pip3.4 install pyusb I can't remember now)
python3.4 hftool.py -r
followed this and worked perfect
debian 7.5.0 on BBB
Does anyone have a windows build for this? 4.4.1 didn't include the voltage options for --hfa-options 
JakeTri, does your fork of cgminer still contain this functionality?
Yes, my fork still have the changes to set same voltage value for all ASIC cores.
The syntax is
Code:
name:clock@voltage,name2:clock2@voltage1, ....
The latest code first read current device voltage settings and set voltage to device only if voltage is not matching to avoid flash writing when it is not needed.
Thanks!
JakeTri, does your fork of cgminer still contain this functionality?
Yes, my fork still have the changes to set same voltage value for all ASIC cores.
The syntax is
Code:
name:clock@voltage,name2:clock2@voltage1, ....
The latest code first read current device voltage settings and set voltage to device only if voltage is not matching to avoid flash writing when it is not needed.
JakeTri, does your fork of cgminer still contain this functionality?
A simplified version of my voltage adjustment was merged yesterday into cgminer. This version set same voltage for all cores/dies and use following new syntax for --hfa-options:
name:clock@voltage,name2:clock2@voltage1, ....
I noticed it was pulled back out because it doesn't support stock hashfast devices. I am going to grab it in any case and give it a shot..
Running 4 Habaneros here, I may have missed the earlier commentary but does it support multiple devices? I assume so due to naming, I didn't have much luck setting multiple devices names at once in cgminer so I think I need to sort that out.
All the voltage changes were reverted from cgminer because they have issues with chained Hashfast devices like Sierras.
The scope of my change was to support single ASIC Hashfast devices like Habanero (Yoli Evo or standard Baby Jet boards) because I do to have access to any Sierras or other chained Hashfast devices.
It works with multiple devices connected to one system using one cgminer instance. I used 2 Habanero boards on one system and I have different settings for each board. The key part is to use the device name to identify each device.
A simplified version of my voltage adjustment was merged yesterday into cgminer. This version set same voltage for all cores/dies and use following new syntax for --hfa-options:
name:clock@voltage,name2:clock2@voltage1, ....
I noticed it was pulled back out because it doesn't support stock hashfast devices. I am going to grab it in any case and give it a shot..
Running 4 Habaneros here, I may have missed the earlier commentary but does it support multiple devices? I assume so due to naming, I didn't have much luck setting multiple devices names at once in cgminer so I think I need to sort that out.
so.. do we have to raise a bounty to get this going? what sized bounty?
I can only think of 2 people who could do this, conman or gateway. oh and JakeTri maybe..
What would it take to sway you guys to look into look at the code to do voltage and clock control over individual dies?
Just thinking out loud here...
QG
I can only think of 2 people who could do this, conman or gateway. oh and JakeTri maybe..
What would it take to sway you guys to look into look at the code to do voltage and clock control over individual dies?
Just thinking out loud here...
QG
I've installed a new 13.10 ubuntu and set my card with hf-tool to 980@950, 980@950, 980@925, 980@925. So I want two dies to run at 950, and two at 925.
When I run cgminer with hfa-hash-clock 1, all the dies are running at 925?
Am I misunderstanding how --hfa-hash-clock 1 works?
No, and this could just be a bug in cgm.. just to be clear nobody has released the stuff we have so this is still new, and with multi die settings their are bound to be things that cgm isn't accounting for.
OK. I thought I had read that die-level tuning was possible, just making sure I'm not the only one who has tried unsuccessfully.
Understood about the unreleased stuff, I'm very appreciative of all that has been done, and is being worked on. I jumped on the habaneros in batch one because I could see the development and participation on the Chili. You guys are definitely not disappointing on the Habaneros!
I've installed a new 13.10 ubuntu and set my card with hf-tool to 980@950, 980@950, 980@925, 980@925. So I want two dies to run at 950, and two at 925.
When I run cgminer with hfa-hash-clock 1, all the dies are running at 925?
Am I misunderstanding how --hfa-hash-clock 1 works?
No, and this could just be a bug in cgm.. just to be clear nobody has released the stuff we have so this is still new, and with multi die settings their are bound to be things that cgm isn't accounting for.
I can confirm JakeTri method works fine with a two-board setup on latest cgminer 4.3.4 built from git. (Prior to the code being reverted).
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
When you say lowest speed, that would be the speed that was set with the hf-tool.. so if you set your volts to lets say 940, and freq to 900, --hfa-hash-clock 1 as *we* understand it would then run it at 900Mhz.. I could be wrong and I haven't had enough coffee yet to wake up my brain cells.
Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time.
When I say preexisting issue and lowest speed, I'm referring to per die tuning. I get the same result whether I set the speeds with the jaketri method or hf-tool. When I start cgminer with the hfa-hash-clock to 1, here's what I get with these settings.
.980@950/.980@950/.975@925/.975@925 = all dies hash at 925.
.970@925/.980@950/.950@900/.970@925 = all dies hash at 900.
I'm stumped, and taking the controller offline to upgrade ubuntu is a last resort for me.
I've installed a new 13.10 ubuntu and set my card with hf-tool to 980@950, 980@950, 980@925, 980@925. So I want two dies to run at 950, and two at 925.
When I run cgminer with hfa-hash-clock 1, all the dies are running at 925?
Am I misunderstanding how --hfa-hash-clock 1 works?
Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time.
It is very easy to check if the updated settings are written to flash:
Set the value to something different that default (for Habanero default is 875MHz @ 930 mV) and power cycle the board by powering down the PSU and also disconnect the USB. After powering up the board start mining using --hfa-hash-clock 1 and see what settings are used.
If you get back to default values 875MHz @ 930 mV then you can safely assume that settings are not saved to flash.
If your custom settings are preserved than settings are saved to flash and you need to set them only once for the board.
I'll try to do this easy check later today.
I just check and I can confirm that voltage settings are written to flash so it is safer to set the voltage only once for the device.
I'll see if I can improve the logic from cgminer by reading first the current voltage settings and set the voltage only when is really usefull.
I updated cgminer logic to first read current voltage settings and store the new voltage settings only when value are different.
New pull request was created for con with the updated logic.
Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time.
It is very easy to check if the updated settings are written to flash:
Set the value to something different that default (for Habanero default is 875MHz @ 930 mV) and power cycle the board by powering down the PSU and also disconnect the USB. After powering up the board start mining using --hfa-hash-clock 1 and see what settings are used.
If you get back to default values 875MHz @ 930 mV then you can safely assume that settings are not saved to flash.
If your custom settings are preserved than settings are saved to flash and you need to set them only once for the board.
I'll try to do this easy check later today.
I just check and I can confirm that voltage settings are written to flash so it is safer to set the voltage only once for the device.
I'll see if I can improve the logic from cgminer by reading first the current voltage settings and set the voltage only when is really usefull.
A simplified version of my voltage adjustment was merged yesterday into cgminer. This version set same voltage for all cores/dies and use following new syntax for --hfa-options:
name:clock@voltage,name2:clock2@voltage1, ....
+1
I can confirm JakeTri method works fine with a two-board setup on latest cgminer 4.3.4 built from git. (Prior to the code being reverted).
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
When you say lowest speed, that would be the speed that was set with the hf-tool.. so if you set your volts to lets say 940, and freq to 900, --hfa-hash-clock 1 as *we* understand it would then run it at 900Mhz.. I could be wrong and I haven't had enough coffee yet to wake up my brain cells.
Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time.
It is very easy to check if the updated settings are written to flash:
Set the value to something different that default (for Habanero default is 875MHz @ 930 mV) and power cycle the board by powering down the PSU and also disconnect the USB. After powering up the board start mining using --hfa-hash-clock 1 and see what settings are used.
If you get back to default values 875MHz @ 930 mV then you can safely assume that settings are not saved to flash.
If your custom settings are preserved than settings are saved to flash and you need to set them only once for the board.
I'll try to do this easy check later today.
A simplified version of my voltage adjustment was merged yesterday into cgminer. This version set same voltage for all cores/dies and use following new syntax for --hfa-options:
name:clock@voltage,name2:clock2@voltage1, ....
I can confirm JakeTri method works fine with a two-board setup on latest cgminer 4.3.4 built from git. (Prior to the code being reverted).
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
When you say lowest speed, that would be the speed that was set with the hf-tool.. so if you set your volts to lets say 940, and freq to 900, --hfa-hash-clock 1 as *we* understand it would then run it at 900Mhz.. I could be wrong and I haven't had enough coffee yet to wake up my brain cells.
Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time.
When I say preexisting issue and lowest speed, I'm referring to per die tuning. I get the same result whether I set the speeds with the jaketri method or hf-tool. When I start cgminer with the hfa-hash-clock to 1, here's what I get with these settings.
.980@950/.980@950/.975@925/.975@925 = all dies hash at 925.
.970@925/.980@950/.950@900/.970@925 = all dies hash at 900.
I'm stumped, and taking the controller offline to upgrade ubuntu is a last resort for me.
I can confirm JakeTri method works fine with a two-board setup on latest cgminer 4.3.4 built from git. (Prior to the code being reverted).
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
When you say lowest speed, that would be the speed that was set with the hf-tool.. so if you set your volts to lets say 940, and freq to 900, --hfa-hash-clock 1 as *we* understand it would then run it at 900Mhz.. I could be wrong and I haven't had enough coffee yet to wake up my brain cells.
Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time.
I can confirm JakeTri method works fine with a two-board setup on latest cgminer 4.3.4 built from git. (Prior to the code being reverted).
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card.
I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer?
I extensively audited the code and have reverted it sorry, but have given you plenty of comments as to what needs to be fixed if you wish to resubmit.
Thank you for considering the change in the first place!
I agree that change need more work so I'll rework the change and resubmit.
Very interested in seeing how this progresses and interested in picking it up this week in whatever form it is in for some work I am doing, be sure to drop a BTC address, a donation is definitely coming your way..
I extensively audited the code and have reverted it sorry, but have given you plenty of comments as to what needs to be fixed if you wish to resubmit.
Thank you for considering the change in the first place!
I agree that change need more work so I'll rework the change and resubmit.
I extensively audited the code and have reverted it sorry, but have given you plenty of comments as to what needs to be fixed if you wish to resubmit.
JakeTri, any word or feedback on your pull request?
Has anyone compiled this fork that can comment on any successes, or problems (other than the board reset and hotplug that is noted)?
Has anyone compiled this fork that can comment on any successes, or problems (other than the board reset and hotplug that is noted)?
Edit: My pull request was merged to cgminer today.
I would like to get comments on successes (or failures) from anyone who tried it but nothing yet.
On a side note I notice another issue/limitation related to the clock offsets part of my change.
If you use more than one clock offset then only the offset from the die with higher index is used. All other dies use the base clock. I have not spend much time on this issue but so far I think this is caused by the firmware interface that allow only frequency to be send to the board. It seems that all dies not selected to use that frequency are set to the default frequency for the board.
JakeTri, any word or feedback on your pull request?
Has anyone compiled this fork that can comment on any successes, or problems (other than the board reset aand hotplug that is noted)?
Has anyone compiled this fork that can comment on any successes, or problems (other than the board reset aand hotplug that is noted)?
Maybe im tired today but what does the -50 mean?
Also maybe a small change but easier to read would be
name:die/s:mV@freq
so to do all dies it would be
hab1:*:930@875
?
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
Also maybe a small change but easier to read would be
name:die/s:mV@freq
so to do all dies it would be
hab1:*:930@875
?
I'm trying to keep backward compatibility with existing option so I have to start with "name:clock".
You need to set all the 9 values only if you need different clock/voltage for each die.
To set same clock/voltage for all dies you just need "name:freq:mV".
Your example with the default freq/voltage would be:
hab1:875:930
For my boards one die is about 10 degree hotter (I guess I need to re-seat again the water pump) so I try to keep it at lower clock and lower voltage.
The first number after "name" is the "clock" (same as stock cgminer) -> 950Mhz in my example.
After the "base clock" next 4 values are voltage values (for each die) -> 970, 940, 970, 970
After the 4 voltage values you can add 4 "clock offset" (from base clock) for each die -> 0, -50, 0 , 0 that means the following clocks 950, 900, 950, 950 (second die use 50Mhz lower clock)
Maybe im tired today but what does the -50 mean?
Also maybe a small change but easier to read would be
name:die/s:mV@freq
so to do all dies it would be
hab1:*:930@875
?
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
Also maybe a small change but easier to read would be
name:die/s:mV@freq
so to do all dies it would be
hab1:*:930@875
?
Cool, well I say send it over to con so he can pull it in, prob should add something to a readme and maybe a warning, experimental feature for now.. this will give windows users maybe the ability to change voltages, lets just hope they dont make it 1000mV, I have no idea what might happen..
Change send to con https://github.com/ckolivas/cgminer/pull/609
How do you plan to address if a person has more than one board on their system, and what about sierras that are changed, granted this is more for habaneros that don't have the chain up or down.
For now the "new" settings are applied only if board have 4 dies ... that should cover habaneros and yoli.
I think the change to cgminer can be expanded to support chained boards (like sierras) but I don't have any way to test it. For chained boards it would be tricky to find a way to provide the settings (voltage and clock value/offset) for individual dies in the command line.
cgminer already support individual (per board) settings based on board name (set with cgminer using --hfa-name) when multiple boards are connected to one system.
Here is the command line that I used on my system where I have connected 2 habaneros (one is named "pepper1" and the other one is "pepper2"):
Code:
cgminer --hfa-options "pepper1:925:950:920:950:950:0:-50:0:0,pepper2:950:930:960:970:970:-50:0:0:0"
Similar hftool command line for the system with "pepper1" connected would be
Code:
./hftool.py -w 0:950@925,1:920@875,2:950@925,3:950@925
and for the second system with "pepper2"
Code:
./hftool.py -w 0:930@900,1:960@950,2:970@950,3:970@950
And to use hftool I have to use 2 systems instead of one
How do you plan to address if a person has more than one board on their system, and what about sierras that are changed, granted this is more for habaneros that don't have the chain up or down.
For now the "new" settings are applied only if board have 4 dies ... that should cover habaneros and yoli.
I think the change to cgminer can be expanded to support chained boards (like sierras) but I don't have any way to test it. For chained boards it would be tricky to find a way to provide the settings (voltage and clock value/offset) for individual dies in the command line.
cgminer already support individual (per board) settings based on board name (set with cgminer using --hfa-name) when multiple boards are connected to one system.
Here is the command line that I used on my system where I have connected 2 habaneros (one is named "pepper1" and the other one is "pepper2"):
Code:
cgminer --hfa-options "pepper1:925:950:920:950:950:0:-50:0:0,pepper2:950:930:960:970:970:-50:0:0:0"
Similar hftool command line for the system with "pepper1" connected would be
Code:
./hftool.py -w 0:950@925,1:920@875,2:950@925,3:950@925
and for the second system with "pepper2"
Code:
./hftool.py -w 0:930@900,1:960@950,2:970@950,3:970@950
And to use hftool I have to use 2 systems instead of one
@JakeTri
How do you plan to address if a person has more than one board on their system, and what about sierras that are changed, granted this is more for habaneros that don't have the chain up or down.
python on windows.. blah hahaha
How do you plan to address if a person has more than one board on their system, and what about sierras that are changed, granted this is more for habaneros that don't have the chain up or down.
python on windows.. blah
hahaha For us Windows people, do you plan to release a Windows build of your edited version of cgminer?
I might be able to work through the read me to setup and build, but my Linux skills are sub-par.
I might be able to work through the read me to setup and build, but my Linux skills are sub-par.
I do not plan to release any Windows or Linux build of cgminer.
You can follow the standard windows building instructions for cgminer from windows-build.txt file.
For us Windows people, do you plan to release a Windows build of your edited version of cgminer?
I might be able to work through the read me to setup and build, but my Linux skills are sub-par.
I might be able to work through the read me to setup and build, but my Linux skills are sub-par.
BTW, to run the hf-tool on Gentoo Linux you just need to install python3 and pyusb using:
then add the udev rules as described in the OP and run the tool
Code:
emerge dev-lang/python:3.3 dev-python/pyusb
then add the udev rules as described in the OP and run the tool
Code:
./hftool.py -r
You are right, the change just overwrite the default voltage used by the board and issue a reset. The python script is doing exactly the same so from my point of view both methods (python script or modified cgminer) are at same risk level.
I added a separate change to enable it only for devices with 4 dies so it is ready for a pull request upstream. I'll wait to get confirmation that solution works for others and after that I'll see if I create a pull request.
I'm not sure if the python solution works on windows.
I started getting python set up a on Windows box, but got pulled away for higher priority things. I believe it should, but python on Windows with pyusb 1.0.x is not a fun thing to set up.I added a separate change to enable it only for devices with 4 dies so it is ready for a pull request upstream. I'll wait to get confirmation that solution works for others and after that I'll see if I create a pull request.
I'm not sure if the python solution works on windows.
Not discounting your work either, I think it's great. I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
You are right, the change just overwrite the default voltage used by the board and issue a reset. The python script is doing exactly the same so from my point of view both methods (python script or modified cgminer) are at same risk level.
I added a separate change to enable it only for devices with 4 dies so it is ready for a pull request upstream. I'll wait to get confirmation that solution works for others and after that I'll see if I create a pull request.
I'm not sure if the python solution works on windows.
I added a separate change to enable it only for devices with 4 dies so it is ready for a pull request upstream. I'll wait to get confirmation that solution works for others and after that I'll see if I create a pull request.
I'm not sure if the python solution works on windows.
I'd be careful about using this method. What you're basically doing is overwriting the default voltage stored on the flash of the device and then resetting it.
If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.
If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.
True..
I'd be careful about using this method. What you're basically doing is overwriting the default voltage stored on the flash of the device and then resetting it.
If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.
If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.
I'll check for the test points tonight when I get back home and let you know the measurements results.
I plan to push the change to con but I was thinking to clean it up a little before pushing it upstream. As it is right now it will brake any Sierra or any other Hashfast device with more than 4 dies ...
Not that I'm thinking of it ... the easiest fix would be to enable this code only when device have 4 dies
I'll fix that and push it to con today.True.. hmm you mean chained boards right?
Also note that some dies fail, crack or what ever so we use the hf tool to disable a die because w/o doing this you cant mine and it spits our crazy errors.
So a die#:0 is set to turn it off, this allows the board to continue hashing with 3 dies for example.
Also prob should put some sort of limiting factor so someone doesn't put in a huge number, which im not sure what would happen but prob a few checks an balances.. or a --i-agree-to-use-this-expirmental-feature option
Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970:970:970:980"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970"
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.
Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?
So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer.
I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage.
Where the chip is, on the edge of the board are a few test areas one for each die.. I forget the names off the top of my head.
btw you should push this change to con to see if he accepts it..
cheers!
I'll check for the test points tonight when I get back home and let you know the measurements results.
I plan to push the change to con but I was thinking to clean it up a little before pushing it upstream. As it is right now it will brake any Sierra or any other Hashfast device with more than 4 dies ...
Not that I'm thinking of it ... the easiest fix would be to enable this code only when device have 4 dies
I'll fix that and push it to con today. Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970:970:970:980"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970"
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.
Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?
So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer.
I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage.
Where the chip is, on the edge of the board are a few test areas one for each die.. I forget the names off the top of my head.
btw you should push this change to con to see if he accepts it..
cheers!
Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970:970:970:980"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970"
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.
Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?
So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer.
I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage.
Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970:970:970:980"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970"
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.
Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?
Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.
Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.
Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:
Code:
cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970:970:970:980"
- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):
Code:
cgminer --hfa-options "hab1:950:970"
Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb
Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.
Board #1 has all dies at .975v/950MHz
Both boards hashing stable with .975/950MHz settings. (clocking at 925MHz)
Code:
cgminer version 4.3.4 - Started: [2014-06-06 22:50:16]
----------------------------------------------------------------------------------------------------
(5s):1.136T (1m):1.290T (5m):1.371T (15m):1.396T (avg):1.404Th/s
A:14260992 R:44032 HW:3972 WU:19617.1/m | ST: 176 SS: 0 NB: 75 LW: 14958907 GF: 0 RF: 0
Connected to xxxxxxxx 1.02K with stratum as user xxxxx
Block: c0e29fcd... Diff:11.8G Started: [11:05:05] Best share: 18.4M
----------------------------------------------------------------------------------------------------
[U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
0: HFB Dabs : 925MHz 99C 100% 0.90V | 722.1G / 700.6Gh/s WU: 9787.2/m A:7135104 R:28160 HW:2104
1: HFB Chip : 925MHz 101C 100% 0.90V | 569.0G / 703.6Gh/s WU: 9829.9/m A:7125888 R:15872 HW:1868
----------------------------------------------------------------------------------------------------
[2014-06-07 11:05:15] Accepted 0acf8627 Diff 6.06K/1024 HFB 0 pool 0
[2014-06-07 11:05:15] Accepted 01a3e358 Diff 40K/1024 HFB 0 pool 0
[2014-06-07 11:05:18] Accepted 16f68815 Diff 2.85K/1024 HFB 0 pool 0
[2014-06-07 11:05:18] Accepted 28e32c95 Diff 410K/1024 HFB 1 pool 0
[2014-06-07 11:05:32] Accepted 20eb99a9 Diff 1.99K/1024 HFB 1 pool 0
[2014-06-07 11:05:34] Accepted 297d0612 Diff 1.58K/1024 HFB 0 pool 0
Just awesome - thanks Peppermining!
YMMV.
Just added a post about pushing your Habanero on our blog, this includes proper cooling and using this tool.
Post: https://peppermining.com/pushing-your-habanero
Post: https://peppermining.com/pushing-your-habanero
awesome good news.. prob should start a little faq for various linux versions..
btw not sure if you need these..
Code:
libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
I blindly followed a guide from Stackoverflow.
Got it working on 12.04 LTS...
Code:
sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
Then install the python3 from source code:
wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz
tar xvf Python-3.4.0.tar.xz
cd Python-3.4.0
./configure
make
make test
sudo make install
sudo pip3.4 install --pre pyusb
(or sudo pip3.4 install pyusb I can't remember now)
python3.4 hftool.py -r
awesome good news.. prob should start a little faq for various linux versions..
btw not sure if you need these..
Code:
libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
Got it working on 12.04 LTS...
Code:
sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
Then install the python3 from source code:
wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz
tar xvf Python-3.4.0.tar.xz
cd Python-3.4.0
./configure
make
make test
sudo make install
sudo pip3.4 install --pre pyusb
(or sudo pip3.4 install pyusb I can't remember now)
python3.4 hftool.py -r
First of all our dev boxes are running ubuntu desktop 13.04 or .10 64 bit .. so if you have an image of that try that out.
secondly, their are a few things to check since this requires python 3 and the running python by default is usually 2.7 or something close not 3
so u need some flavor or python 3...
You could try running the command like so..
Please make sure you also have pip3 and pyusb installed for python 3.
secondly, their are a few things to check since this requires python 3 and the running python by default is usually 2.7 or something close not 3
Code:
netcom@chromy2:~/Documents/firmware/tools$ python --version
Python 2.7.5+
Code:
netcom@chromy2:~/Documents/firmware/tools$ python3 --version
Python 3.3.2+
so u need some flavor or python 3...
You could try running the command like so..
Code:
python3 hftool.py -r
Please make sure you also have pip3 and pyusb installed for python 3.
Getting the same error when I try to read current freq and voltages.
Any thoughts on this error? I'm getting it on 12.04 LTS, and Debian 7.4 on the beaglebone black. Stumped.
Code:
jack@jack-nT-A3000-series:~/hf-tool$ ./hftool.py -r
HFBulkDevice Found!
ConfigurationValue 1
InterfaceNumber 0,0
EndpointAddress 131
InterfaceNumber 1,1
EndpointAddress 129
EndpointAddress 2
EndpointAddress for writing 2
EndpointAddress for reading 129
Generic exception handler: (, 'list' object has no attribute 'copy', )
Traceback (most recent call last):
File "/home/jack/hf-tool/hf/load/routines/settings.py", line 50, in one_cycle
self.transmitter.send([])
File "/home/jack/hf-tool/hf/load/hf.py", line 83, in send
mybyteslist = byteslist.copy()
AttributeError: 'list' object has no attribute 'copy'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./hftool.py", line 67, in
main(sys.argv[1:])
File "./hftool.py", line 55, in main
while setter.one_cycle():
File "/home/jack/hf-tool/hf/load/routines/settings.py", line 129, in one_cycle
self.end()
File "/home/jack/hf-tool/hf/load/routines/base.py", line 304, in end
self.transmitter.send(op_usb_shutdown.framebytes)
File "/home/jack/hf-tool/hf/load/hf.py", line 83, in send
mybyteslist = byteslist.copy()
AttributeError: 'list' object has no attribute 'copy'
Oh, yea I should mention only use this with one miner plugged in at a time
Just wanted to throw this out. There is no Python 3 package of pip for Ubuntu 12.04 LTS. So I installed this way...
sudo apt-get install python3-setuptools
sudo easy_install3 pip
Got it installed but can't test it remotely since it crashes with two miners connected. Will report back later.
edit: See post below.
sudo apt-get install python3-setuptools
sudo easy_install3 pip
Got it installed but can't test it remotely since it crashes with two miners connected. Will report back later.
edit: See post below.
Hey everyone we are able to release a tool that allows you to adjust your voltage settings for your Evo and Habanero boards.
HF has provided us with a python 3 script that we are allowed to distribute.
Basically in a nutshell this is good to use ONLY if your trying to push your boards past 900Mhz because you will need to increase the voltage on the board in order to give the chip more power.
USE AT YOUR OWN RISK, please read the LICENSE FILE first before using this tool.
This only works with one miner plugged in at a time!
The hftool.py utility is used to query and manipulate hashfast module settings.
Requirements:
Python 3.x
pip for Python 3.x
Pyusb
Installing pip for python 3 on most unix systems (command for ubuntu below)
sudo apt-get install python3-pip
hftool requires pyusb. To install it:
pip3 install --pre pyusb
Put these into a file /etc/udev/rules.d/01-hashfast.rules:
You will need root access to create this file and also when done its recommended you reboot in order for these rules to take effect.
RUNNING
Start the tool by with:
Read die frequencies and voltages:
Write die frequencies and settings:
example would be setting all dies to .930 volts at 875Mhz
You can grab it from Bitbucket Git depo here https://bitbucket.org/gateway69/hf-tool
AND no I dont work for HF, we pushed them to get a tool released so our customers of our Habanero boards could tweak and push their boards.
Order your Habanero from Batch 2 today for $850 here
HF has provided us with a python 3 script that we are allowed to distribute.
Basically in a nutshell this is good to use ONLY if your trying to push your boards past 900Mhz because you will need to increase the voltage on the board in order to give the chip more power.
USE AT YOUR OWN RISK, please read the LICENSE FILE first before using this tool.
This only works with one miner plugged in at a time!
The hftool.py utility is used to query and manipulate hashfast module settings.
Requirements:
Python 3.x
pip for Python 3.x
Pyusb
Installing pip for python 3 on most unix systems (command for ubuntu below)
sudo apt-get install python3-pip
hftool requires pyusb. To install it:
pip3 install --pre pyusb
Put these into a file /etc/udev/rules.d/01-hashfast.rules:
You will need root access to create this file and also when done its recommended you reboot in order for these rules to take effect.
Code:
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="0001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev”, ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="8001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff6", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"RUNNING
Start the tool by with:
Code:
$ ./hftool.py -h
Read die frequencies and voltages:
Code:
$ ./hftool.py -r
Write die frequencies and settings:
Code:
$ ./hftool.py -w 0:VLT@FRQ,1:VLT@FRQ,2:VLT@FRQ,3:VLT@FRQ
example would be setting all dies to .930 volts at 875Mhz
Code:
$ ./hftool.py -w 0:930@875,1:930@875,2:930@875,3:930@875
You can grab it from Bitbucket Git depo here https://bitbucket.org/gateway69/hf-tool
AND no I dont work for HF, we pushed them to get a tool released so our customers of our Habanero boards could tweak and push their boards.
Order your Habanero from Batch 2 today for $850 here
Jump to: