Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 147. (Read 5806015 times)

legendary
Activity: 1274
Merit: 1004
With my Chilis I find that they tend to go out in groups as well. I need to start logging to confirm, but they'll run for a week or more without issue and then 4 seem to go out at the same time.
sr. member
Activity: 486
Merit: 262
rm -rf stupidity
Yup these units all have the USB port still.  And awesome news!  I have a BB Black that will be here Tuesday.  Though I built a i5 4670k with 16 gigs to be my R&D box.  I have Ubuntu server but was going to switch to Arch because this thing was built to be headless after OS install.  I'll have to try it out tonight and see if I can get it to work.

Going to use the BB Black on a few other projects.  The PI is nice but you are right the USB faults blow!

So when I get home I will read a few of the threads.  When it plugs in the system should detect the Avalon control unit and its two blades.  It will still control the fans and such (water cooling hopefully in next week).  Then just setup cgminer for Avalon support as always, etc.  If so will this be viable at with 7 boxes at 1.5 TH/s?  Of course each would be on powered USB hubs connected to the Asus Premium mobo.

If you and anyone else would think this would work I would love you very very long time lol!!

Thank you both!  I was walking in dentist do I didn't get to finish my post till now.

New project tonight before I go wire the car some more!
sr. member
Activity: 486
Merit: 262
rm -rf stupidity
Yup these units all have the USB port still.  And awesome news!  I have a BB Black that will be here Tuesday.  Though I built a i5 4670k with 16 gigs to be my R&D box.  I have Ubuntu server but was going to switch to Arch because this thing was built to be headless after OS install.  I'll have to try it out tonight and see if I can get it to work.

Going to use the BB Black on a few other projects.  The PI is nice but you are right the USB faults blow!

So when I get home I will read a few of the threads.  When it plugs in the system should detect the Avalon control unit and its two blades.  It will still control the fans and such (water cooling hopefully in next week).  Then just setup cgminer for Avalon support as always, etc.  If so will this be viable at with 7 boxes at 1.5 TH/s?  Of course each would be on powered USB hubs connected to the Asus Premium mobo.

If you and anyone else would think this would work I would love you very very long time lol!!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
ckolivas I know you don't manage the TP-Link hardware and software but I do know you have done the builds to update CGminer (Much much love man on that one).  Have you heard of anyone dropping the TP-Link and using another piece of hardware like a PI or a BB Black to run CGMiner?  I am trying to find a solution to monitor 7 Avalon 2 clones remotely and the TP-Link WRT Ports are very limited.  My shop I host from is 15 minutes away but I would like to be able to set it up where I can just login remotely and see how things are going.

I know there are solutions like CGRemote but it has to be run locally on the network and I can't broadcast it where I can pick it up at home.  Any idea from anyone else that has tried something would be awesome!
Sure you can run any USB device that cgminer supports off any device that you can build cgminer for (even with windows). I ran the avalon for 3 months off my regular PC rig's USB when I broke my tp link router. Open it up, pull the usb cable out and plug in a (printer type) usb cable that goes to your pc. It's actually more reliable that way too since the tplink is so woefully low power.
legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
Using 3.10.0 for about 3 hours now and I just got a cluster of four AMU zombies. No big deal, but I should probably have mentioned that for the last few versions, on the rare occasions that I still get zombies, they almost always come in clusters of four.


Seems like your hub is the one to blame. Lsusb -v?

Thanks. Could be, for sure. It happens on several hubs, but they are all the same kind (Anker). I'm running Win 7 so can't do the lsusb check. Another Win7 tester was getting cluster USB AMU zombies a while back but I haven't seen him post of late.
hero member
Activity: 1246
Merit: 501
ckolivas I know you don't manage the TP-Link hardware and software but I do know you have done the builds to update CGminer (Much much love man on that one).  Have you heard of anyone dropping the TP-Link and using another piece of hardware like a PI or a BB Black to run CGMiner? 

If the Avalon clones have a USB port you can mine through like the originals, then just plug them in to a hub and run them off a BeagleBone Black.  I'm suggesting the Black because it's USB is much more stable than the RaspPi's USB, and the 2GB flash on the BBB is much more stable than the SD cards on the Pi.

I'm running Debian on my BeagleBone Black, with cgminer or bfgminer (your choice), Apache, php, which I can access using the normal miner.php page.  I've got about 100Gh going through it, soon to be 150GH.  I use bfgminer as I also use it as a getwork proxy.
sr. member
Activity: 486
Merit: 262
rm -rf stupidity
ckolivas I know you don't manage the TP-Link hardware and software but I do know you have done the builds to update CGminer (Much much love man on that one).  Have you heard of anyone dropping the TP-Link and using another piece of hardware like a PI or a BB Black to run CGMiner?  I am trying to find a solution to monitor 7 Avalon 2 clones remotely and the TP-Link WRT Ports are very limited.  My shop I host from is 15 minutes away but I would like to be able to set it up where I can just login remotely and see how things are going.

I know there are solutions like CGRemote but it has to be run locally on the network and I can't broadcast it where I can pick it up at home.  Any idea from anyone else that has tried something would be awesome!

Thanks!
legendary
Activity: 1610
Merit: 1000
Using 3.10.0 for about 3 hours now and I just got a cluster of four AMU zombies. No big deal, but I should probably have mentioned that for the last few versions, on the rare occasions that I still get zombies, they almost always come in clusters of four.


Seems like your hub is the one to blame. Lsusb -v?
legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
Using 3.10.0 for about 3 hours now and I just got a cluster of four AMU zombies. No big deal, but I should probably have mentioned that for the last few versions, on the rare occasions that I still get zombies, they almost always come in clusters of four.

newbie
Activity: 16
Merit: 0
Raspberry PI Make Error:
...

...
  CCLD     cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2

Confirmed building on a Beaglebone as well:

Code:
autogen.sh && ./configure --enable-bflsc && make
That will fail when linking as shown in netfun2000's dump. Adding --enable-bitfury to the configure command will workaround the bug and build successfully.
Code:
autogen.sh && ./configure --enable-bflsc --enable-bitfury && make
It would seem that without --enable-bitfury, there is some partial libbitfury leakage into the build process.
member
Activity: 109
Merit: 10
Unofficial Mac binaries have been updated for v3.10.0 and are available here.

These are universal precompiled binaries that support Mac OS X 10.5.8 through 10.9+.
member
Activity: 115
Merit: 10
ROTFL - thanks for it. I don't have an ice one. Maybe they should put a text on it "just look, don't touch"  Cool
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Please add one parameter for it. With 54 bits the nanofury runs outside usb2.0 specs. I was able to melt a psu of a cheap hub. I expect users having problems with nanofurys because the hub is to weak for 54 bits.

I think the default should be at 50 with a parameter to change it.
Will consider when I get back from holiday thanks. It's a one line change if you wish to alter it for your build in driver-bitfury.c line 417. When I almost burnt myself on one, I did think whoever called the devices I received "ice" was seriously smoking something.
member
Activity: 115
Merit: 10
Please add one parameter for it. With 54 bits the nanofury runs outside usb2.0 specs. I was able to melt a psu of a cheap hub. I expect users having problems with nanofurys because the hub is to weak for 54 bits.

I think the default should be at 50 with a parameter to change it.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I tried on debian and it worked. The nanofury are running fine. Thanks for the work :-)

I am looking for the parameter to set the speed of the nanofury. Something like the "--hexmineru-frequency" of Martos patch or the "--bitfury-osc6-bits" of bfgminer. Is there some?
No there is not, as I have seen it is virtually always best to leave it at 54, so I have added no command line option for now.
member
Activity: 115
Merit: 10
I tried on debian and it worked. The nanofury are running fine. Thanks for the work :-)

I am looking for the parameter to set the speed of the nanofury. Something like the "--hexmineru-frequency" of Martos patch or the "--bitfury-osc6-bits" of bfgminer. Is there some?
legendary
Activity: 1610
Merit: 1000
Raspberry PI Make Error:
make  all-recursive
make[1]: Entering directory `/home/minepeon/cgminer'
Making all in lib
make[2]: Entering directory `/home/minepeon/cgminer/lib'
  GEN      arg-nonnull.h
  GEN      c++defs.h
  GEN      warn-on-use.h
  GEN      signal.h
  GEN      stdint.h
  GEN      string.h
make  all-recursive
make[3]: Entering directory `/home/minepeon/cgminer/lib'
make[4]: Entering directory `/home/minepeon/cgminer/lib'
  CC       dummy.o
  AR       libgnu.a
make[4]: Leaving directory `/home/minepeon/cgminer/lib'
make[3]: Leaving directory `/home/minepeon/cgminer/lib'
make[2]: Leaving directory `/home/minepeon/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/minepeon/cgminer/compat'
Making all in jansson-2.5
make[3]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in src
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
  CC       dump.lo
  CC       error.lo
  CC       hashtable.lo
  CC       load.lo
  CC       memory.lo
  CC       pack_unpack.lo
  CC       strbuffer.lo
  CC       strconv.lo
  CC       utf.lo
  CC       value.lo
  CCLD     libjansson.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in libusb-1.0
make[3]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
Making all in libusb
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-descriptor.lo
  CC       libusb_1_0_la-io.lo
  CC       libusb_1_0_la-sync.lo
  CC       os/libusb_1_0_la-linux_usbfs.lo
  CC       os/libusb_1_0_la-linux_udev.lo
  CC       libusb_1_0_la-hotplug.lo
  CC       os/libusb_1_0_la-threads_posix.lo
  CCLD     libusb-1.0.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Entering directory `/home/minepeon/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/minepeon/cgminer/compat'
make[2]: Leaving directory `/home/minepeon/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/minepeon/cgminer/ccan'
  CC       opt/libccan_a-helpers.o
  CC       opt/libccan_a-opt.o
  CC       opt/libccan_a-parse.o
  CC       opt/libccan_a-usage.o
  AR       libccan.a
make[2]: Leaving directory `/home/minepeon/cgminer/ccan'
make[2]: Entering directory `/home/minepeon/cgminer'
  CC       cgminer-cgminer.o
  CC       cgminer-util.o
  CC       cgminer-sha2.o
  CC       cgminer-api.o
  CC       cgminer-logging.o
  CC       cgminer-usbutils.o
  CC       cgminer-libbitfury.o
  CC       cgminer-driver-icarus.o
  CCLD     cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2
./autogen.sh?
member
Activity: 66
Merit: 10
Raspberry PI Make Error:
make  all-recursive
make[1]: Entering directory `/home/minepeon/cgminer'
Making all in lib
make[2]: Entering directory `/home/minepeon/cgminer/lib'
  GEN      arg-nonnull.h
  GEN      c++defs.h
  GEN      warn-on-use.h
  GEN      signal.h
  GEN      stdint.h
  GEN      string.h
make  all-recursive
make[3]: Entering directory `/home/minepeon/cgminer/lib'
make[4]: Entering directory `/home/minepeon/cgminer/lib'
  CC       dummy.o
  AR       libgnu.a
make[4]: Leaving directory `/home/minepeon/cgminer/lib'
make[3]: Leaving directory `/home/minepeon/cgminer/lib'
make[2]: Leaving directory `/home/minepeon/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/minepeon/cgminer/compat'
Making all in jansson-2.5
make[3]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in src
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
  CC       dump.lo
  CC       error.lo
  CC       hashtable.lo
  CC       load.lo
  CC       memory.lo
  CC       pack_unpack.lo
  CC       strbuffer.lo
  CC       strconv.lo
  CC       utf.lo
  CC       value.lo
  CCLD     libjansson.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in libusb-1.0
make[3]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
Making all in libusb
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-descriptor.lo
  CC       libusb_1_0_la-io.lo
  CC       libusb_1_0_la-sync.lo
  CC       os/libusb_1_0_la-linux_usbfs.lo
  CC       os/libusb_1_0_la-linux_udev.lo
  CC       libusb_1_0_la-hotplug.lo
  CC       os/libusb_1_0_la-threads_posix.lo
  CCLD     libusb-1.0.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Entering directory `/home/minepeon/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/minepeon/cgminer/compat'
make[2]: Leaving directory `/home/minepeon/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/minepeon/cgminer/ccan'
  CC       opt/libccan_a-helpers.o
  CC       opt/libccan_a-opt.o
  CC       opt/libccan_a-parse.o
  CC       opt/libccan_a-usage.o
  AR       libccan.a
make[2]: Leaving directory `/home/minepeon/cgminer/ccan'
make[2]: Entering directory `/home/minepeon/cgminer'
  CC       cgminer-cgminer.o
  CC       cgminer-util.o
  CC       cgminer-sha2.o
  CC       cgminer-api.o
  CC       cgminer-logging.o
  CC       cgminer-usbutils.o
  CC       cgminer-libbitfury.o
  CC       cgminer-driver-icarus.o
  CCLD     cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2
hero member
Activity: 630
Merit: 501
Miner Setup And Reviews. WASP Rep.
Great work thanks Ckolivas.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version: 3.10.0, 9th January 2014

Mainly new drivers.

Human readable changelog:

- Minion driver courtesy of Kano. (More info about this from him hopefully).
- Nanofury driver. These are set up the same as every other USB device is on cgminer. Tested on both windows and linux (sorry no osx to test). Note the hashrate is once again based on only valid shares so may appear lower than other software using this device. No HW errors are currently counted (though they're most definitely there in abundance due to bitfury design). This is a driver based on all the other ones out there with a completely rewritten model to suit how cgminer drivers work.
- Hashfast driver fixes (no I still don't have one).
- Fixed BXF devices slowing down over time.


Full changelog:

- Set the mcp2210 transfer setting only when it changes.
- Buffer sizes in nanofury device data are unnecessarily large.
- Only perform spi reset on init, not with each transaction.
- Remove spi_detect_bitfury at nanofury startup and fix incorrect refresh time.
- Use a simple serialised work model for nanofury
- Use bitfury_checkresults to avoid hashing results twice in nanofury.
- Export bitfury_checkresults in libbitfury
- Pass extra parameters for later use in libbitfury_sendHashData
- Avoid double handling bswap of the nonce value in nanofury
- Avoid unnecessary rehashing in nanofury nonce checking.
- Remove the unused portions of atrvec in the nanofury driver
- Age work in nf1_scan to avoid risk of losing a work item and leaking memory.
- bitfury_work_to_payload is double handling the data unnecessarily
- Default bitrate on nanofury should be 200kHz
- localvec should be only 80 bytes not 80 words
- Wrong init value for nanofury
- Remove unused rehash values from nanofury driver.
- Only update info work in nanofury driver when it's empty.
- Fill the appropriate type of usb transfer when we know if it's an interrupt
transfer instead of a bulk one.
- Use the internal knowledge of the usb epinfo to determine whether we should be
doing an interrupt instead of a bulk transfer, and do not send a ZLP if so, and
limit read transfer to expected size automatically.
- Avoid bin2hex memleak when we start getting nanofury nonces
- Set atrvec only once and use a local array for each device's work.
- Cancel any spi transfers on nf1 close
- Add bitfury detection loop to nanofury startup
- Move spi init code to libbitfury
- Remove inappropriate extra config reg in nanofury setup.
- Status 0x30 should never happen with spi transfers.
- Fix spi transfer data size transmission mistakes.
- Minor correctness change in spi_add_data
- spi_txrx should always send and receive the same size message
- Random libbitfury changes.
- Set value of gpio pins to low on closing nanofury.
- Fix more init sequence for nanofury.
- Add basic initialisation for nf1 devices
- Add basic nf1_scan function.
- Basic import of libbitfury functions from nanofury branch
- Import functions from nanofury fork for libbitfury
- Meter out spi sends to only 2 bytes at a time, offsetting according to how
much data returns.
- Use the usb read limit function for mcp2210 reads.
- Provide a way for usb reads to just read the size asked for with a limit bool.
- Get pin value after an nf1 spi reset.
- Make sure what we send in the buffer doesn't change during spi reset for
nanofury
- Remove all standalone gpio setting change functions in mcp2210 and just use
the one global setting function.
- Set gpio values in the one function with all values for nanofury.
- Provide a helper function for setting all mcp2210 gpio settings.
- Add a helper function for getting all mcp2210 gpio settings.
- Set all pin designations and directions in one call for nanofury and don't
bother storing their values in the info struct.
- Provide helper functions for setting all pins and dirs on mcp2210
- Set all nanofury pin designations in one call
- Provide a helper function for setting all pin designations on mcp2210
- Store the spi settings in a struct for nanofury devices.
- Check the received status in mcp2210 spi transfers and repeat a zero byte send
if it's in progress.
- Set the bytes per spi transfer prior to each mcp2210 transfer.
- Separate out the send and receive functions for mcp2210 and check response
value in return.
- Check that mcp2210 spi settings have taken and check the value of the pin
during nanofury setup.
- Don't set GPIO pin designations after initial setting in nanofury since the
direction and values will be changed.
- Provide an mcp 2210 set gpio input helper function that sets a pin to gpio and
input.
- Move the set gpio output function to a generic mcp2210 version from nanofury
which also sets the pin to gpio.
- Implement a nanofury txrx with a larger buffer and cycling over data too large
to send.
- Implement magic spi reset sequence for nanofury.
- Add more spi magic to the nanofury init sequence.
- Add lots of magic spi initialisation to nanofury.
- Export reused components of bitfury management into a libbitfury and use for
bab and bitfury drivers.
- More init sequence for nanofury and implement a close function that sets all
pins to input.
- Reword offset header handling in hfa_get_header
- Sanity check in hfa_get_header
- Add more checks in hashfast driver for lost devices.
- Change spimode and send more data in nanofury setup.
- Add basic setup  comms to nanofury.
- Implement an mcp2210 spi transfer function.
- Set the initial spi settings for nanofury driver.
- Provide a helper function for gettings mcp2210 spi settings.
- Implement an mcp2210 set spi transfer settings function.
- Cancel any SPI transfers in progress in nanofury after initial setup.
- Implement an mcp2210 spi cancel function.
- Return only binary values for mcp2210 GPIO values.
- Set GPIO LED and power to high in nanofury driver.
- Implement initial part of nanofury init sequence for GPIO pin settings and add
output debugging of set values.
- Add helper functions for getting and setting mcp2210 gpio pin designations.
- Don't return an error in usb read if we've managed to get the whole read
length we've asked for.
- Use correct endpoint order for nanofury devices and read with a short timeout
on return loop from send_recv.
- Add mcp2210 helper functions for getting and setting one GPIO pin val and
direction.
- Create a generic gpio pin struct and add helpers for mcp get pin val and dirs.
- Check the receive msg of a send/receive cycle on mcp2210 matches the send
message.
- Add a set of usb commands to the usbutils defines for mcp2210 comms, and use
the same command name for send and receive.
- Create a generic mcp2210 send_rcv function.
- Include mcp header for bitfury and fix extra params in macro.
- Add basic SPI comms defines for mcp2210 and build rules for bitfury.
- Minion set some core defaults similar to final requirements
- minion compile warnings
- move driver-minion.c to main directory
- Minion with ioctl() stats, settings to attempt to emulate 21TH/s
- minion driver with results interrupt working
- tested working driver-minion.c without interrupts
- Working driver-minion.c v0.1
- driver-minion.c compilable untested
- minion driver - incomplete
- Add minion driver into cgminer
- Add basic device detection and updated udev rules for nanofury devices.
- Remove GPU from share logging example.
- Don't keep resetting BXF clockspeed to default.
- If no pools are active on startup wait 60s before trying to reconnect since we
likely have the wrong credentials rather than all the pools being out.
- Discard bad crc packets for hashfast driver instead of trying to process them.
- Update documentation for modified avalon options syntax and document relevant
55nm details.
- Modify the auto tuning sequence to work with the 50MHz changes required to
work with 55nm Avalon.
- 55nm avalon requires the delays between writes reinstated for stability.
- Use an equation instead of a lookup table to set the frequency for 55nm avalon
allowing arbitrary values to be used.
- Make the result return rate low detection on avalon less trigger happy.
- Always send the bxf device a clockspeed after parsing the temperature in case
the device has changed the clockspeed itself without notification.
- Fix BXF being inappropriately dependent on drillbit.
Jump to: