Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 21. (Read 308577 times)

NEW VERSION 4.6.0, AUGUST 2 2014

Human readable changelog:

• avalonmm: New driver for both Avalon2 and Avalon3 rigs.

Full changelog:

• avalonmm: Even if no fans report speed, display set %
• Bugfix: avalonmm: Fix fan speed setting
• Bugfix: avalonmm: Actually read the result needed to get the correct module id
• README.ASIC: Document AvalonMM driver usage with Avalon 2/3 rigs
• Bugfix: Makefile.am: Remove reference to non-existent driver-avalonmm.h
• avalonmm: Safely handle an improper job id that is within the last 2 sent
• avalonmm: Include asserted fan speed in RPC
• avalonmm: Include asserted fan speed in ManageTUI
• avalonmm: Silence warning about detect ack at runtime
• avalonmm: Make fan speed an option (both RPC and TUI)
• avalonmm: Allow changing clock speed and voltage from Manage TUI
• Bugfix: avalonmm: Show proper units for fans & voltage
• avalonmm: Support for disabling the entire chain
• Implement broad_udevrules for avalonmm
• avalonmm: Show extranonce1, module id, temperatures, fans, clock, and voltage in Manage TUI
• avalonmm: Include Module Id and ExtraNonce1 in RPC devdetails
• avalonmm: Add Temperature0/1 and Fan Percent 0/1 to RPC
• avalonmm: Add Frequency and Voltage to RPC
• avalonmm: Add voltage setting (defaults to 0.6625 V)
• avalonmm: Add clock setting and try to autodetect it if not provided
• avalonmm: Implement hashmeter
• avalonmm: Adjust device target up to pdiff 32 when possible
• avalonmm: Update job when current pool changes
• Bugfix: avalonmm: MM flips the xnonce2, so we need to do the same
• avalonmm: Implement mining logic
• lowl-spi: Move bit order reverse to bitflip8 function in util
• avalonmm: Treat multiple chained modules as slaves rather than processors
• avalonmm: Probing for devices using Avalon Miner Manager (Avalon2/3 rigs)
• littlefury: Move crc16 logic to util
• Use BUILT_SOURCES to ensure version.h is always built first
• configure option --with-udevrules-group to allow customising the group name used
• Bugfix: zero_stats: Only call cgpu function if it exists
• Remove FPGA-only bitforce-firmware-flash tool (now located at https://github.com/luke-jr/bitforce-fpga-firmware-flash )

Hy Bronan.

I hear ya.  Unfortunately, unplugging the device only kills the hashing for me on the other board in the g-blade that is hashing away.  The funky stuff is that it happens randomly to other miners on every reboot.  It's never the same gridseed twice.
I've sort of settled with the idea that out of 8 G-blade miners I can live with 7.5 G-blades mining.

Thanks nwoolls , i try to install the new firmware but the old firmware has ssh acces locked so the only way is to load the new firmware from the user interface but it isn't recognised as valid. This evening i will try with the serial interface to gain the boot sequence and force system access.

Thankds W_M

The factory.bin is for doing an install of OpenWrt while the sysupgrade.bin is for upgrading an existing installation. If you are able to SSH into the 703n, you can SCP the sysupgrade.bin file into the /tmp directory and then run sysupgrade on it. More info here:

http://wiki.openwrt.org/doc/howto/generic.sysupgrade

If you are not able to SSH into the device you can follow these instructions to reset it:

http://wiki.openwrt.org/toh/tp-link/tl-wr703n

Hi, I have a TP Link 703N (with LAv 3 Firmware) and I want to upgrade the firmware with the latest 703N BFGMiner 4.5 firmware, which firmware I have to load bfgminer-ar71xx-generic-tl-wr703n-v4.5-r1-squashfs-factory.bin or bfgminer-ar71xx-generic-tl-wr703n-v4.5-r1-squashfs-sysupgrade.bin.

Thanks in advance W_M

I have a handful of miscellaneous old mining hardware (10 block erupters, 1 Jalapeno, and 2 BE Blades) with a total of about 30GH running in one instance of BFGMiner (pulled from git a few days ago, version visible in the screenshot below), and this morning I noticed that the mining rate was displaying in TH, instead of the usual GH.  I have seen this before once, when I solo-mined a block with this same HW about 15 hours after starting to mine - but in this case, no block was mined.  I figured that maybe one of the devices had submitted a very high-diff share that got rejected, but this does not seem to be the case either.

In the screen shot below, taken some time after the 'event', you can see that the BES7 device is apparently the one that generated a high share (its rate is displayed in TH while all the others are in GH or MH), but looking at the log, I don't see ANY indication of that device generating a big share, neither accepted nor rejected:




LOG SNIPPET -  All it shows is a share of 55/32 by PXY 1 (a BE Blade), then the rate changes to EH from GH with no indication on any share generated by BES 7:

 [2014-07-31 05:45:19] 5s:25.49 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104175/3.9%
 [2014-07-31 05:45:24] 5s:25.24 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104175/3.9%
 [2014-07-31 05:45:29] 5s:29.01 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104176/3.9%
 [2014-07-31 05:45:34] 5s:27.39 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104176/3.9%
 [2014-07-31 05:45:35] Accepted 049e34be PXY 1  pool 2 Diff 55/32
 [2014-07-31 05:45:39] 5s: 1.43 avg: 0.00 u: 0.00 Eh/s | A:51984 R:926+15(1.3%) HW:104177/3.9%
 [2014-07-31 05:45:44] 5s:873.2 avg: 0.05 u: 0.00 Ph/s | A:51984 R:926+15(1.3%) HW:104178/3.9%
 [2014-07-31 05:45:49] 5s:534.7 avg: 0.05 u: 0.00 Ph/s | A:51984 R:926+15(1.3%) HW:104180/3.9%
 [2014-07-31 05:45:52] Accepted 0325d931 PXY 0  pool 2 Diff 81/32
 [2014-07-31 05:45:54] Accepted 0083bd86 BFL 0  pool 2 Diff 497/32
 [2014-07-31 05:45:54] 5s:327.4 avg: 0.05 u: 0.00 Ph/s | A:51985 R:926+15(1.3%) HW:104182/3.9%
 [2014-07-31 05:45:59] 5s:200.5 avg: 0.05 u: 0.00 Ph/s | A:51986 R:926+15(1.3%) HW:104182/3.9%

Can anyone explain to me how this can happen?  Did I lose a potentially block-solving share due to a bug?

Hi! i get errors when i tried with stratum+tcp:// pool,i get  Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers
,
 i just upgrade from ubuntu 12.04 (here work fine) to ubuntu 14.04, and compile on it the latest version from github.

any idea why stratum don't work on ubuntu 14.04 (http works fine)

Thanks dude,

Will take your hint, any further initialization info is appreciated!  

How do i get these red fury's to work with bfg miner?

Hi, NF2 and/or NF6 owners!

I'm currently running some Antminer U2s and in the .BAT or .Conf file I can auto-initialize them at BFGminer start up to whatever speed I want them to run (overclock).  From what info I've run across, it appears as though that doesn't work with Nano Fury, instead it's necessary to wait for them to warm up for perhaps five minutes and then enter 'M'anage devices and manually adjust the two digit speed setting.  I just want to verify this is the case, specifically for the NF6 (expecting some to arrive shortly), but I'm supposing it's the same for NF2.  Is there a way to auto set them at BFGminer startup?

Thanks for any help! 

Just a heads up you need to keep all the chips in a NF6 at the same speed or you'll melt it

I've had that problem too. Sometimes switching hubs helps.

I have only 2 g-blades running but i seen this often before, the only way i could get the 0 hashing away was after i turned power off on the failing one and power it back up.
But i am not sure if it would work for you, my gridseeds was from early batches and allways been a pain in the behind to get and keep them running.

I stopped buying from zeusminer and gridseed since i do not really like how these companies handle problems they caused.
A defect gridseed blade blew up a 1500 dollar pc and they simply stay silent nor respond to this issue.
Zeusminer send me some small miners which are crap because of the brutal handling by packaging or transport but they act exactly like minereu indeed nothing.

At least from my diggings on an S1 the ASICS are "hidden" behind a PIC uC connected via USB that is programmed by Linux at boot up. The code for the uC isn't available afaik. Just a binary blob

And each blade is chained off of that uC via serial protocol (UART if I remember correctly)

And the mining software communicates with the pick to send and receive results


Bm1380 datasheet: https://raw.githubusercontent.com/AntMiner/AntGen1/master/datasheet/BM1380_Datasheet.pdf

Controller board altium files:

https://github.com/AntMiner/AntGen1/tree/master/PCB

FWIW I am in discussions with Bitmain again trying to get proper documentation from them. I'll post an update once I have something.

They have code, but it isn't useful - besides being poorly written and hard to read, it's just code, and doesn't tell you the underlying logic in the chips and controller.
Documentation and/or interaction with someone who knows these things is somewhat necessary, else there are many days of reverse engineering work to be done.
Note that if you're making your own boards with their chips, that's mostly unrelated to S1-S3 driver support; even if S1-S3 were supported, it's not necessarily going to "just work" with any other PCB using the same chips.
On the other hand, that may be a good thing for you: you don't need their driver either. But we'd still need some kind of documentation for the chips...

They have a Github acct. and were supposed to have posted the open code somewhere for people who bought chips, access to S1 controller boards was also stated as part of the chip deal. One thing holding me back from buying S1/S3 is I would prefer to use BFG Miner. Maybe a request sent thru the github repo would get a response from Bitmain.

They did send a dev S1, but no docs, and the source is essentially useless

Just no dev unit? Or no source to go off?

If I can get a MIPS compiler setup in a Linux VM tonight I would be willing to at least start poking around

This is all kinda pending waiting on Bitmain since the S1... :/