Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 21. (Read 286370 times)

If you only have one board, i.e., you are not daisy chaining, then only two of the ports are 'mining' ports with makomk's bitstream.

I expect those to be /dev/ttyUSB2 and /dev/ttyUSB3 for you.

If you're seeing about an effective 400mhs from each of the ports which are 'detected', then all is fine. You are now mining and on the path to easy money.

-- edit --

BTW, you're running cgminer? I've not been able to get that running on a Debian 7 release yet. Do you have any advice / observations about how you got it going?

Ok, next step The only DIP switch that's off now is switch 1 on SW6.

I did a and I can now see 4 extra /dev/ttyUSB entries. When I start cgminer, Icarus Detect fails on 2 of those. The other start to mine...

Bad flash? Should I flash a lower bitstream?

Search in this thread with keyword "udev".

You probably need to issue a modprobe command. (You might also search with that as a keyword.)

You can also search for posts by "spiccioli". He has helped me a lot.

Also check to see that the FTDI service is enabled. iirc, it wasn't on my vanilla installation of Debian.

-- edit --
Also, if still having problems getting the /dev/ttyUSBx's to show up.
1) Unplug USB
2) remove power from boards
3) ensure that only *one* switch is off on the DIPS next to power/USB connections
4) power up boards, wait until orange shows on all FPGAs.
5) plug in USB
6) use "dmesg" to see that the devices are seen
7) manual modprobe or set up spiccioli's udev rules

-- edit again --
"orange" and "yellow" are probably the same color. 

I have a problem getting my Cairnsmore1 up and running...

- I flashed the 1.5 controller in Windows using the Enterpoint documentation. This worked fine and verify was ok.
- I then flashed shortfin_dcmwd4e_ed_test_200_overclock.bit to each chip. This also worked fine.
- I then set the switch settings as defined here: https://bitcointalksearch.org/topic/m.1073047 and tried to do the last part ("Unplug the cable on the board.", "Move SW1 switch 3 to ON (labeled mine), so it's like all the others next to it.", "Move SW1 switch 1 to OFF (labeled reset) then after a few seconds to ON again" & "When just the yellow leds next to the 4 chips are on all, plug the board again") but the leds stay amber and the blue leds also stay on...

Does anyone know whether everything was successfull or not? I'm mining on Linux, but do no see any related ttyUSBx devices...

Any help is appreciated

Thanks a lot LazyOtto,

it is very appreciated since every Satoshi counts!

spiccioli.

Thanks, spiccioli.

I'm starting my bitcoind / wallet now to send a trivial amount of BTC in appreciation of your quite non-trivial amount of help. ty

BTW, my personal amount sent is trivial. I'm hoping though that the idea is *lots* of people send small amounts and they add up.

--

Also sent 1 BTC to:
Glasswalker: 17RQ9weR551AijNniuC7QRLp6Ff2WAjbc9

--
makomk, I turned on 'show sigs' but still don't see your address, please post or PM it to me and you get a BTC also. And my thanks.

Hi LazyOtto,

no need to search anymore!

16CtsQsV6bPrtzc3DaYvDHjsHS5MwXL476    

spiccioli

Is it possible to flash the 1.5 controller in Linux (via xc3sprog?)? If so, how exactly do I do this? The documentation only mentions Windows.

You are correct, I am pretty sure that a glitching worker FPGA can in fact make the FTDI appear unresponsive (for example by asserting tx/rx for example). I'm not exactly sure how the FTDI reacts in that situation.

If that's the case, the bitstream again isn't "responsible" but the worker "locking up" (as it has in the past and still does occasionally) may cause the FTDI to freak out.

If you're experiencing this with the faster bitstreams, I suggest testing with the first HashVoodoo 175 release that I put out. It's proven extremely stable for most (and it's what I'm running on the linux host I mentioned has been up for like 26 days non stop).

I know it's a 12% or more hit to your hashrate, but it could be a valuable test to confirm if it's still stability in the bitstream.

If it does work for you, I hope to have a new version out soon with dynamic overclocking and a faster overall clock speed. (provided smartxplorer cooperates, so far it's been having a hard time closing timing...) anyway...

But yes there are SEVERAL points of failure in this chain, and unfortunately it's a tricky thing to really isolate them in a large cluster.

I've decided that once I get a "faster" release out with dynamic clocking, I am going to work on a "temp" protocol which will allow use of the up/down link. My hope is that I'll be able to chain 16+ fpgas on a single UART. I'll need to crank the FTDI baud rate for this though, so there are a bunch of variables to consider.

The icarus setup currently sends 512bits of data in a "packet" so that means a 250K baud rate can handle about 488 packets per second. With my setup, you would send one packet per up to 16 FPGAs. (they would "share" the packet). But they would send independant responses (32bit). so without adding more than .1 second of delay, that means you should be able to chain upwards of a couple hundred FPGAs on a single chain without major problems. Mind you transmission latency might become a problem at that point. Anyway, even with 100 FPGAs in a chain, that would allow for 25 boards per single USB connection. Which is why I was bringing this up at this point, ie: that feature may help alleviate this problem that some are experiencing.

The "final" solution will be a from-scratch protocol, using raw USB bandwidth to communicate, allowing for theoretically VERY large clusters. But that one is a ways away. I hope this "temporary" feature will be good enough for now. (also this feature alone is still at least a few weeks away, I'm doing my best).

Hope that helps.

Glasswalker, please look at this:
https://bitcointalksearch.org/topic/m.1177532

And comment on my thoughts / sanity.

I am now up for 46 hrs continuous operation versus the first two failures within 24 hrs.

I don't think this is all related to USB cables and hubs. (But I'm sure they do play a part. Multiple possible points of failure here, after all.)

-- edit --
Although this is not gonna help the guy with his Ubuntu problem.

All I can suggest, is try different cables, different hubs, or different ports.

If none of the above help, try a clean install of windows, with clean drivers. And possibly try a different motherboard.

I can say there is nothing wrong with the FTDI chip that Enterpoint used. Those USB->UART chips are used in MILLIONS of devices, and are very well supported. Also there is nothing in the bitstream which directly controls any kind of firmware for the FTDI. It just does it's job.

The only possible thing to consider is possibly something is electrically slightly out of spec. (Ie: a voltage, or some line noise, or impedance somewhere, or whatever). The result would be that certain other devices which are out of spec in the other direction (just slightly) might not be stable with it. So in this kind of situation a *slightly* bad cable that works on 90 other devices (That are all either 100% in spec, or out of spec in the "right" way) could fail miserably with this particular board. Same goes for hubs, and motherboard chipsets (and even differences between different ports on your motherboard).

Unfortunately if there is an issue with the cairnsmore. It's not something that is likely to be "fixed" by enterpoint. Or by the bitstream developers. It's likely going to be something parasitic and lowlevel which gets (hopefully) fixed on a future product. But requiring hardware troubleshooting to work around currently. I can say that my boards mine perfectly fine on both my windows and linux mining hosts for plenty of time. (my dev board on my windows machine has been mining now for at least 36 hours without incident, and my linux board is mining for the past 26 days without incident. But several have reported "odd" usb behavior. So I don't doubt you're experiencing some frustrating problems (I've had to fight with similar issues before myself, and it's a huge pain). But I think unfortunately it's going to boil down to a combination of "environmental" issues (your cables, computer, ports, software, power supplies, power noise, rf noise in the house, and whatever else).

I hope that helps some.

I use Ubuntu 12.04 (64bit) to run my CM1 boards. Not that long ago I run an pretty usual update of various files, as it had been bugging me.
After restarting I found that every time I plugged either of the boards via usb, the system would kinda go through a system crash, everything would slowly stop working.
Commands wouldn't work in the terminal, the GUI would slowly start disappearing and eventually it would do nothing, even though it still responded to basic input, even if it didn't respond with what it should.
It left me no choice but to restart. Everything is fine upon restart as long as I don't plugin the boards back in. It still works fine as a HTPC (XBMC).

I figured one of the USB or FTDI drivers, lib files etc cause the problem, like it got corrupted or one hell of a bad bug. They were just updated but I had no luck tracking down what exactly was the fault, a lot of files were updated and doing my best to revert back didn't work. No one else seems to be reporting a similar bug so assumed it was just an isolated event.

So I backed everything up to my storage unit that was needed and rebuilt Ubuntu, to pretty much the same configuration I had before. That seems to go fine, I didn't remember all of it, but search feature is very useful on these boards, think I got everything.

Problem is, same issue occurred once I got everything redone on a new usb stick. So it's no longer looking like a corrupted file, can't imagine it happening twice in a row like that, on a fresh 8Gb usb stick.
It happens with both CM1 boards, either one can trigger it to happen. I've done a gentle clean of dust off it and they appear to be operating fine.
It has not effected the use of my wireless mouse or usb pen in any of the slots, so I am still assuming it is a software issue, not hardware.

Anyone came across something like this happening before?
Yes it's frustrating I've not been able to mine for a few days, but I get frustrated more when there is something I can't fix.

To be honest we are still looking at technology options of what we might do if anything. So there isn't a definate yes or no on that so far. We do want to do any new project in a very different way and any new design would be much more developed before we announce it. We are aware that a lot of Bitcoiners would like us to do a product and if it is viable for us to do it we will. We have learned a massive amount about Bitcoin mining and Bitcoins in general since we started and that knowledge is highly valuable to us in doing a more advanced project.

We also still have a lot of staff time going into the CM1 build and other supporting things that is a limit to what we can do currently on a CM2 project. That will throttle back in September but then we will be into designs and prep for our only exhibition show that we will do this year. Until that is past mid-November everything else will be on slow motion. So even if we go ahead on one of our concepts as a production item we are likely to be behind the competition in time unless they happen to slip a lot or we somehow work some magic.

 

WEll after  3 days working my 12 cm1 OK. This morning  half ot them was off  


and most anoying is that trying to wake up them, making power cicles, makes randomly  others   "half" fails.  I have them in pairs whit up/down cables and  half of the ports of some  are  failing with my old error.

I have seen one post with something about sudo "COM"   i think its the same error

please fix that USB issue. this is unbearable


ç

2-09-11 06:35:30] Do not have user privileges required to open \\.\COM34
2-09-11 06:35:30] Do not have user privileges required to open \\.\COM35


Edit: I had to make several power cycles  and unisntall problematic devices and COMS in w7 to get them running again.

Heh that reminds me - I should add that to the README FAQ so I can tell people to read the manual when they ask in IRC
... done.

Yohan, with the new Asic Competitors announced and suggesting that there might be Product around Nov till the end of the year has Enterpoint looked again at making an Asic board? I know you mentioned something a few posts back but I was wondering if with these new announcements if anything had changed.

Id like to buy my Asic from Enterpoint is what I’m saying!

Thanks,

Doff

... and after the guide is finished, don't forget to use my cgminer options --icarus-timing and --icarus-options as documented in the cgminer API-README

Challenge accepted

spiccioli, yep, thank you very much. (I should'a seen that.)

root@dinky:~# ls -la /dev/ttyUSB*
crw-rw-rwT 1 root dialout 188, 0 Sep 10 16:56 /dev/ttyUSB0
crw-rw-rwT 1 root dialout 188, 1 Sep 10 16:56 /dev/ttyUSB1
crw-rw-rwT 1 root dialout 188, 2 Sep 10 16:56 /dev/ttyUSB2
crw-rw-rwT 1 root dialout 188, 3 Sep 10 16:56 /dev/ttyUSB3
crw-rw-rwT 1 root dialout 188, 4 Sep 10 16:56 /dev/ttyUSB4

I'll send you a, trivial but they add up, tip next time I bring bitcoind up in order to send Glasswalker and makomk their, also deserved, dues from me.

-- edit --

Edit, assuming I can find your address.
(I routinely run with signatures disabled. Cuts out a lot of 'noise'. But I'll re-enable and search for your's.)

LazyOtto,

to access them I had to add the group ubuntu adds to every ttyUSB device to the list of secondary groups of the user running cgminer


So I issued a


to add user my_login_name to the dialout group.

This made all /dev/ttyUSB* devices fully accessible to the user running cgminer.

spiccioli.