Topic: Avalon ASIC users thread - page 177. (Read 438600 times)

My avalon unit has  the exactly same issue as yours. I'd like to ask if the test firmware posted by xiangfu related to this issue?

I am using firmware 20130419. Unfortunately, I don't recall the previous firmware version I was using.

Prior to the upgrade on May 5, the Avalon unit ran without any problems.

However, after the upgrade, the miner has stopped hashing twice, and the only way to recover is with a cold reset. Is this a know issue?

Cheers!

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!

Well that worked..almost. I could enter failsafe-mode. Here's the instruction:
--
To get into failsafe mode, power up the device and wait until the LED starts flashing (about 2Hz). Once it starts flashing (within about 4 seconds) then quickly press the button. The LED will then flash much faster and the device will be in failsafe mode.
--

Failsafe IP is 192.168.1.1. I could telnet to the router. I checked

root@(none):/# cat /etc/config/network

config 'interface' 'loopback'
        option 'ifname' 'lo'
        option 'proto' 'static'
        option 'ipaddr' '127.0.0.1'
        option 'netmask' '255.0.0.0'

config 'interface' 'lan'
        option 'ifname' 'eth0'
        option 'type' 'bridge'
        option 'proto' 'static'
        option 'netmask' '255.255.255.0'
        option 'ipaddr' '192.168.0.100'
        option 'gateway' '192.168.0.1'
        option 'dns' '8.8.8.8'

Everything seems fine. Anyway, after rebooting I'm not able to ping or ssh 192.168.0.100.

Edit: Fixed it!
After making the filesystem writeable with "mount_root" /etc/config/network looked differently:

config interface 'lan'
        option ifname 'eth0'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.0.100'
        option dns '8.8.8.8'
        option gateway '192.168.0.101'
        option netmask '0.0.0.0'

Changed it. Reboot. Problem solved.
(And back to my original problem. Will probably talk about that later..)

Thanks for your great and fast help!

mtd -r erase rootfs_data

make -j4

.... (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$

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.

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)

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.

...
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.

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.

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.

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.

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.

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.

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?

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?