Avalon ASIC users thread

[server]

Thanks Aseras ... I know.. too late

I strongly believe that people want to show their appreciation for development but they just don't know who does what in this project.

If there was an option in Avalon's miner settings to donate X% hashes to the dev-team, I think a lot of the Avalon users would have used this.

[kano]

How to add "4th,5th pool" under "More Options" ?


Edit: Found it... add: "-o ip:port -O user:pass" for each pool

It even works with more than 5 pools...

Can different pools mine different coins, e.g., bitcoin and bytecoin?

No
(line 3 of the cgminer README)

[spiccioli]

Thanks Aseras ... I know.. too late

Yeah,

too little, but having an address where to send some tips would help as well, I mean, if each Avalon user sends 1 BTC per owned Avalon 100 BTCs are easily collected!

spiccioli

[Aseras]

Thanks Aseras ... I know.. too late

I strongly believe that people want to show their appreciation for development but they just don't know who does what in this project.

If there was an option in Avalon's miner settings to donate X% hashes to the dev-team, I think a lot of the Avalon users would have used this.

I actually spoke to ckolivas about adding this option to the finished cgminer with full usb code.

[-ck]

Thanks Aseras ... I know.. too late

I strongly believe that people want to show their appreciation for development but they just don't know who does what in this project.

If there was an option in Avalon's miner settings to donate X% hashes to the dev-team, I think a lot of the Avalon users would have used this.

I actually spoke to ckolivas about adding this option to the finished cgminer with full usb code.

The donation feature in cgminer previously was much maligned by the miners, and only ever amounted to a tiny amount of hashrate. I know there are a few generous people that would be happy with such a feature, but I'm not sure it would amount to very much. Do you think there'd be something different this time around?

[flyonwall]

Question: I have done some USB driver work on Windows. How difficult would it be to remove the serial port driver and go directly to USB? The USB protocol is more complicated than that for UART, but I imagine in cgminer high-level interfaces should look very similar to those for a UART?

[-ck]

Question: I have done some USB driver work on Windows. How difficult would it be to remove the serial port driver and go directly to USB? The USB protocol is more complicated than that for UART, but I imagine in cgminer high-level interfaces should look very similar to those for a UART?

This is what I'm currently working on, as most other drivers in cgminer are direct USB. To complete the work I need extended access to hardware and doing it remotely is proving problematic.

[yxt]

The donation feature in cgminer previously was much maligned by the miners, and only ever amounted to a tiny amount of hashrate. I know there are a few generous people that would be happy with such a feature, but I'm not sure it would amount to very much. Do you think there'd be something different this time around?

It's worth a try. Make donating as easy as possible.

[kaerf]

Question: I have done some USB driver work on Windows. How difficult would it be to remove the serial port driver and go directly to USB? The USB protocol is more complicated than that for UART, but I imagine in cgminer high-level interfaces should look very similar to those for a UART?

This is what I'm currently working on, as most other drivers in cgminer are direct USB. To complete the work I need extended access to hardware and doing it remotely is proving problematic.

Con, how much time do you think you need on the machine?

Is it difficult to do remotely because you sometimes need a hard reboot?  I could potentially set up access for you with the ability to remotely power cycle the machine.

[opentoe]

Oh stop it. All you guys that have Avalons have been making a TON of money here in the last few months. Literally thousands and thousands if you played your cards right, and to this day STILL raking in a good chunk of change. Yea, a little jealous. I would have loved to pay off some bills.

[flyonwall]

Question: I have done some USB driver work on Windows. How difficult would it be to remove the serial port driver and go directly to USB? The USB protocol is more complicated than that for UART, but I imagine in cgminer high-level interfaces should look very similar to those for a UART?

This is what I'm currently working on, as most other drivers in cgminer are direct USB. To complete the work I need extended access to hardware and doing it remotely is proving problematic.

Con, how much time do you think you need on the machine?

Is it difficult to do remotely because you sometimes need a hard reboot?  I could potentially set up access for you with the ability to remotely power cycle the machine.

The problem(s) maybe caused by the fact that, on the Avalon Control Unit, the USB serial I/O connects to a UART (FT232), instead of being deserialized and sent to the Spartan-6 chip. So to talk to the Spartan-6, you really need to use the UART protocol instead of the USB protocol. It seems to me that the USB protocol is transparent (or pass-through) in this case.

[-ck]

Question: I have done some USB driver work on Windows. How difficult would it be to remove the serial port driver and go directly to USB? The USB protocol is more complicated than that for UART, but I imagine in cgminer high-level interfaces should look very similar to those for a UART?

This is what I'm currently working on, as most other drivers in cgminer are direct USB. To complete the work I need extended access to hardware and doing it remotely is proving problematic.

Con, how much time do you think you need on the machine?

Is it difficult to do remotely because you sometimes need a hard reboot?  I could potentially set up access for you with the ability to remotely power cycle the machine.

Somewhere between 5 minutes and 5 weeks... 

No really I don't want to put a time on it because you can never tell. Half the problem has been that this direct usb work so far has been done on xiangfu's machine in China and sometimes via ssh it can take a minute to get a response from a keystroke. It's excruciating. The inability to do a hard reboot is also a major problem. It also is pretty much futile trying to do it directly on the avalon hardware, as there are far more tools you can use on a proper linux PC plugged into it via USB (specifically monitoring usb communications). A lot of this is just poking around to see what the serial driver converts into direct USB and trying to emulate that behaviour since it was never designed to be used in that way (which is a shame). There are other issues too, but they can be worked around.

[gyverlb]

Somewhere between 5 minutes and 5 weeks... 

No really I don't want to put a time on it because you can never tell. Half the problem has been that this direct usb work so far has been done on xiangfu's machine in China and sometimes via ssh it can take a minute to get a response from a keystroke. It's excruciating.

You probably can't easily install it on an Avalon but if by "xiangfu's machine" you mean a more powerful machine acting as a relay to connect to an Avalon, you could try to setup mosh.

I have some servers with unpredictable latencies and sometimes I have to work with a mobile connection with very unpredictable latencies. In practice its prediction algorithm is a game changer compared to ssh (the way it works is technically interesting too). You need to install it on both the server and the client and as long as the network lets you transmit UDP packets between your client and a port you can choose on the server (by default it's chosen by the server side between 60000 and 61000) you are set.

Currently you lose the multiplexing capabilities of ssh, but in your case this doesn't matter.

[flyonwall]

The next step is to chuck the usb-serial code and go direct usb and remove a lot of the hacks and work arounds that were used and improve it a lot more.

What is the issue with going through usb-serial code?  Is it a bottleneck?  Or is this to improve reliability?

I ask this question because I am currently trying to decide whether to design my own Control Unit and replace the way the USB on the Control Unit is grafted onto the Spartan-6. The USB connection to the Spartan-6 can be enhanced by replacing both the uPD720114 and the FT232 UART with a single CY7C68013A which serializes/deserializes to 16-bits.

EDIT:
It seems that the serial driver has to be used in cgminer because, on the Control Unit side, the USB goes through an offchip UART before connecting to the Spartan-6.

[-ck]

That's the effort involved in doing direct USB. We have to figure out what it is in the communication that is done and emulate it - as we do with a few other devices already in cgminer. Using direct USB uses a lot less CPU and should be far more reliable.

[kano]

...
EDIT:
It seems that the serial driver has to be used in cgminer because, on the Control Unit side, the USB goes through an offchip UART before connecting to the Spartan-6.

Incorrect - you do not have to use serial-USB - the linux kernel simply sits on top of the ftdi_sio driver which is, of course, usb.
You just need to know how to talk to it on USB (as the sio driver already does)

[-ck]

You probably can't easily install it on an Avalon but if by "xiangfu's machine" you mean a more powerful machine acting as a relay to connect to an Avalon, you could try to setup mosh.

I have some servers with unpredictable latencies and sometimes I have to work with a mobile connection with very unpredictable latencies. In practice its prediction algorithm is a game changer compared to ssh (the way it works is technically interesting too). You need to install it on both the server and the client and as long as the network lets you transmit UDP packets between your client and a port you can choose on the server (by default it's chosen by the server side between 60000 and 61000) you are set.

Currently you lose the multiplexing capabilities of ssh, but in your case this doesn't matter.

I've never heard of mosh before but I will definitely give it a try, thanks for the suggestion! (So many cool toys to play with on linux).

[flyonwall]

...
EDIT:
It seems that the serial driver has to be used in cgminer because, on the Control Unit side, the USB goes through an offchip UART before connecting to the Spartan-6.

Incorrect - you do not have to use serial-USB - the linux kernel simply sits on top of the ftdi_sio driver which is, of course, usb.
You just need to know how to talk to it on USB (as the sio driver already does)

Please clarify what you mean by "the linux kernel simply sits on top of the ftdi_sio driver".

My point is this: USB involves complex protocol, UART is simple. We can simulate a direct UART connection between any two systems through the Internet, as is being done as we speak. Now the Internet protocols are even more complex than USB. The easiest way to talk UART to another system through the Internet is NOT to muck with the Internet protocols (that would be crazy). The easiest way is to have another Internet appliance (similar to the one used on the other UART endpoint), and talk UART to that appliance. Similarly in the case of USB.

The simple topology seems to be [sio driver] <--> [usb driver] <-- usb wire --> [usb protocol hw] <--> [uart hw], with the [uart hw] on Avalon's control unit side dictating that the [sio driver] be used on the cgminer side. That's my point.

In other words, we may have to remove the [uart hw] on the Avalon control unit to get rid of the [sio driver] on cgminer.

[kano]

...
EDIT:
It seems that the serial driver has to be used in cgminer because, on the Control Unit side, the USB goes through an offchip UART before connecting to the Spartan-6.

Incorrect - you do not have to use serial-USB - the linux kernel simply sits on top of the ftdi_sio driver which is, of course, usb.
You just need to know how to talk to it on USB (as the sio driver already does)

Please clarify what you mean by "the linux kernel simply sits on top of the ftdi_sio driver".

My point is this: USB involves complex protocol, UART is simple. We can simulate a direct UART connection between any two systems through the Internet, as is being done as we speak. Now the Internet protocols are even more complex than USB. The easiest way to talk UART to another system through the Internet is NOT to muck with the Internet protocols (that would be crazy). The easiest way is to have another Internet appliance (similar to the one used on the other UART endpoint), and talk UART to that appliance. Similarly in the case of USB.

The simple topology seems to be [sio driver] <--> [usb driver] <-- usb wire --> [usb protocol hw] <--> [uart hw], with the [uart hw] on Avalon's control unit side dictating that the [sio driver] be used on the cgminer side. That's my point.

In other words, we may have to remove the [uart hw] on the Avalon control unit to get rid of the [sio driver] on cgminer.

ckolvias and I have already got the Lancelot working fine which uses the same chip.
Once he has more reliable access to an Avalon (or gets one) he'll sort out the Avalon USB also.
The USB for this is simple.
The ftdi_sio for this is simple.
The only difference between Avalon and what we have already done, is probably adding DSR/CTS (which was done but not working fully yet)

[abracadabra]

trying to compile avalon/cgminer on an extra linux box i had laying around.

using these instructions:

http://en.qi-hardware.com/wiki/Avalon#How_to_Compile_Your_Own_WR703N_Firmware_for_Avalon

ran the first

make -j4

result:

.... (lines removed)
 make[3] -C feeds/luci/contrib/package/luci compile
localhost - - [19/May/2013 16:04:37] code 404, message File not found
localhost - - [19/May/2013 16:04:37] "GET /cgminer-3.1.1.tar.bz2 HTTP/1.1" 404 -
make -r world: build failed. Please re-run make with V=s to see what's going on
make: *** [world] Error 1
user@ubuntu:~/avalon/openwrt$