Cairnsmore1 - Quad XC6SLX150 Board

[steamboat]

I cannot for the life of me get cgminer to compile, or figure out what i did wrong. anyone around to help?

If you are using Linux, have you tried what I wrote some pages ago:

Code:

./autogen.sh
./configure --disable-opencl --disable-cpumining --enable-icarus
make clean
make

For Win, it is a lot more complicated. There is a dedicated Readme in the sources for that, I personally don't use it.

If you have still problems, jump over to #cm1 for interactive support.

its windows for now, and kano's holding my hand in #cgminer cuz i'm too sleep deprived to figure out the basic stuff 

[1714207855]

1714207855

[1714207855]

1714207855

[1714207855]

1714207855

[yohan]

Yohan: now that Enterpoint is quite a bit further down the road than when we started out, has there been any further progress into using bitinstant as a zero-risk BTC to USD payment gateway?

Or, even better: accepting bitcoins yourself directly?

We are still looking at this but to be honest we are just struggling to keep up with the things we have to do like buying parts to make boards, testing boards, shipping and support and so on without adding another variable to deal with. Glasswalker's recent bad experience is also something we are looking at and that's something that we are cautious of.

 

I'm having bad luck.


after a power cycle I`ve got this error in one of the boards (all the 4 COM's)
Do not have user privileges required to open \\.\COMXX

I un installed coms ports and turn off the boards?  but it still persists could it be a usb issue?

Edit:After reseting my pc now have two boards with this error ?¿?¿  both boards have been worked fine before.

This might not be the problem but we have seen cases where the USB gets screwed up in Windows and once it does the com port is never seen again. However if this is the problem all is not lost. Basically there is a FTDI utilility to do a driver removal and cleanup after which a clean install of the driver usually sorts the issue. If anyone things this is their problem send an email to our bitcoin support email "bitcoin.support" AT "enterpoint.co.uk" and the relevant person will see it early next week when they are back in. Once I have the full details of how to do this myself I will try and get the recovery process listed on one of our webpages so it is easy to find.

On a different point if we do happen to have a DCM issue with power noise then we already have a tested fix. That's what we used to test a Glasswalker2 variant last week at 200MHz operation on an early board and it's very stable. It's not the same as the Controller build as publically available but because we built in a very flexible clocking system into Cairnsmore1 we don't actually have to use DCMs within array FPGAs. Simply we can direct supply a 200MHz clock, or anything similar 0-300MHz , straight to the FPGA to run the logic on. If this looks the way to go we will expand testing of this technique over a larger board sample.

Over the last 2 days we have been running Makomk's 190 build on rig of 20+ boards and we have very good results on our testing.

[Isokivi]

Yohan would you be able and/or willing to supply us with the schematics for cm1 ?

..were still confused as hell about a lot of the hardware issues and this could help.
If that is not possible could you simply state wether or not the controller chip is powered through USB ?

[yohan]

Yohan would you be able and/or willing to supply us with the schematics for cm1 ?

..were still confused as hell about a lot of the hardware issues and this could help.
If that is not possible could you simply state wether or not the controller chip is powered through USB ?

Controller chip will take power from either 12V or USB. It's a simple diode OR of the 2 supplies. It can even be a share in some cases. It depends on the exact voltage 5V on the USB, and the tolerance of the regulator in the 12V feed, which will input lead in supplying current although typically we would expect that to be the 12V if it is available.

[spiccioli]

Yohan would you be able and/or willing to supply us with the schematics for cm1 ?

..were still confused as hell about a lot of the hardware issues and this could help.
If that is not possible could you simply state wether or not the controller chip is powered through USB ?

Isokivi,

read here

https://bitcointalk.org/index.php?topic=78239.msg1028756#msg1028756

spiccioli

[testconpastas2]

I'm having bad luck.


after a power cycle I`ve got this error in one of the boards (all the 4 COM's)
Do not have user privileges required to open \\.\COMXX

I un installed coms ports and turn off the boards?  but it still persists could it be a usb issue?

Edit:After reseting my pc now have two boards with this error ?¿?¿  both boards have been worked fine before.

This might not be the problem but we have seen cases where the USB gets screwed up in Windows and once it does the com port is never seen again. However if this is the problem all is not lost. Basically there is a FTDI utilility to do a driver removal and cleanup after which a clean install of the driver usually sorts the issue. If anyone things this is their problem send an email to our bitcoin support email "bitcoin.support" AT "enterpoint.co.uk" and the relevant person will see it early next week when they are back in. Once I have the full details of how to do this myself I will try and get the recovery process listed on one of our webpages so it is easy to find.

On a different point if we do happen to have a DCM issue with power noise then we already have a tested fix. That's what we used to test a Glasswalker2 variant last week at 200MHz operation on an early board and it's very stable. It's not the same as the Controller build as publically available but because we built in a very flexible clocking system into Cairnsmore1 we don't actually have to use DCMs within array FPGAs. Simply we can direct supply a 200MHz clock, or anything similar 0-300MHz , straight to the FPGA to run the logic on. If this looks the way to go we will expand testing of this technique over a larger board sample.

Over the last 2 days we have been running Makomk's 190 build on rig of 20+ boards and we have very good results on our testing.

Well after losts of pc reboots  . board power cycles and uninstalled Com ports in w7. i didn't fix anything with that weird card.
This morning when i went to work I left my card powered but no hashing. Now I'm back at home and without reboot i unpluged usb cable and board responded again ?¿?¿? ( last night i did that hundreds of times...)
 I suspect my usb hub is crap because after rebooting sometimes the board/s that doesnt work is different ( so is not a cable problem) because each board has always the same cable .

or as you have said some kind of issue usb-driver /motherboard/w7. ( i thought about temp too but yesterday i had A/A all time.)

I'm going to send you an email to the given address, so next time it happens try to see if that "uninstall driver tool" helps in any way.

PS: d-link 7 port usb hub have  nice price in amazon .uk now . anyone  has got it and is working well with their cm1?

Thank you yoham for your support.

[toxicocean]

Board 0005 with controller v1.3

ran the Makomk shortfin 160 stable for 70 hours, cgminer output:

 cgminer version 2.3.4 - Started: [2012-07-30 22:37:47]
--------------------------------------------------------------------------------
 (5s):573.3 (avg):733.2 Mh/s | Q:13024  A:37148  R:184  HW:0  E:285%  U:8.96/m
 TQ: 2  ST: 3  SS: 5  DW: 952  NB: 413  LW: 83348  GF: 0  RF: 0
--------------------------------------------------------------------------------
 CM 0:                | 457.6/368.2Mh/s | A:18511 R:95 HW:0 U:4.47/m
 CM 1:                | 240.4/365.0Mh/s | A:18637 R:89 HW:0 U:4.50/m
--------------------------------------------------------------------------------

pool reported a hashrate of 640 Mhash/s

Since it ran stable, I decided yesterday to upgrade the board to the makomk shortfin 190oc version.
That one has been running stable now for the last 20 hours:
 cgminer version 2.3.4 - Started: [2012-08-02 20:52:14]
--------------------------------------------------------------------------------
 (5s):858.4 (avg):735.3 Mh/s | Q:3881  A:12827  R:77  HW:0  E:331%  U:10.53/m
 TQ: 2  ST: 3  SS: 2  DW: 325  NB: 150  LW: 25767  GF: 0  RF: 0
--------------------------------------------------------------------------------
 CM 0:                | 244.3/367.4Mh/s | A:6475 R:30 HW:0 U:5.32/m
 CM 1:                | 436.8/367.9Mh/s | A:6352 R:47 HW:0 U:5.22/m
--------------------------------------------------------------------------------

pool currently reports a hashrate of 756 Mhash/s

my experience is that after programming etc, it's best to power down the board completely (unplug power and usb), and restart the pc you want to mine on (if it's the same one you did the programming on).
Power on the board, wait about 3 minutes, plug in the USB in the pc, and start mining.

[yohan]

Anyone with 10 or more boards and without problems could tell me which usb hub model, is/are he using?

Thank you.

We are using http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 for our big test rigs. Fired up in the correct sequence, i.e. hit the USB hub on switch after 12V is up and runing, they are working well here. I imagine these are available, with suitable power adaptor, in most counties. The ones on Ebuyer come with a UK plug/brick so not very suitable for other markets directly. I believe have seen the same one on Ebay as well.

[steamboat]

How do I tell which controller version is loaded on my boards?

[yohan]

Anyone with 10 or more boards and without problems could tell me which usb hub model, is/are he using?

Thank you.

We are using http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 for our big test rigs. Fired up in the correct sequence, i.e. hit the USB hub on switch after 12V is up and runing, they are working well here. I imagine these are available, with suitable power adaptor, in most counties. The ones on Ebuyer come with a UK plug/brick so not very suitable for other markets directly. I believe have seen the same one on Ebay as well.

How do I tell which controller version is loaded on my boards?

At the moment you can't. I will look at getting in some sort of flash code on the LED into the controller but it's not there yet.

[steamboat]

Anyone with 10 or more boards and without problems could tell me which usb hub model, is/are he using?

Thank you.

We are using http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 for our big test rigs. Fired up in the correct sequence, i.e. hit the USB hub on switch after 12V is up and runing, they are working well here. I imagine these are available, with suitable power adaptor, in most counties. The ones on Ebuyer come with a UK plug/brick so not very suitable for other markets directly. I believe have seen the same one on Ebay as well.

How do I tell which controller version is loaded on my boards?

At the moment you can't. I will look at getting in some sort of flash code on the LED into the controller but it's not there yet.

I have my dip switches set to flash the controller as per the Cairnsmore1_Controller_Upgrade_Procedure.pdf instructions. When I flash the rev. 1.3v4 I get

SPIProg V1.0 Copyright Enterpoint Ltd ⌐ 2012
Cairnsmore Control FPGA Loader

Bitfile OK
NumPages: 207

and then it stops. does this mean I already have that version on the board so it's not rewriting it?

[gyverlb]

@yohan : upgrading controller with a Linux system ? This is the 4th time I ask this here, I'm beginning to wonder what's going on.

[Glasswalker]

@yohan : upgrading controller with a Linux system ? This is the 4th time I ask this here, I'm beginning to wonder what's going on.

Considering the intructions for doing this the "official" way are in a linux VM running on windows, and earlier in this thread full instructions for using the spi programming utility natively in linux or windows (with speed improvements too) I would imagine taking the same commandline arguments for the official steps and combining it with the native version of the same tool in linux should do the trick. Unfortunately I don't have the time to dig into this right now.

Also in theory, you can install virtualbox on your linux host, and use the same VM based instructions to do it that way (of course substituting anything that's linux specific as appropriate).

Hopefully that helps.

If not, perhaps some of the others on here who contributed some of the native steps earlier can chime in and help?

Also have you tried the IRC channel? (freenode.net #cm1)

[kano]

... and in case anyone was interested

cgminer 2.6.2 contains the new --icarus-options

I created a cgminer-2.6.2a.exe for windows that only has ICA + BFL in my git downloads
(so you don't need opencl installed or an ATI driver installed on windows)
https://github.com/kanoi/cgminer/downloads
(along with the cgminer-2.6.2a for Xubuntu 11.04)

I suspect that the most use here would be:
--icarus-options 57600
To change the baud

If you are running one of the older problems where you get one out of two FPGA's then the option would be:
--icarus-options 57600:2:1
(or --icarus-options :2:1 if you don't need to change the baud)

If anyone does actually use it - please let me know how it goes for you.
The --icarus-timing option will still be relevant if the boards aren't hashing at 380MH/s per pair of FPGA (or 190MH/s on a single FPGA)
As mentioned before, if your board is running about ~1% faster or more, it may be being slowed down by the default timing (idle at the end of each work item that doesn't find a share)

[steamboat]

... and in case anyone was interested

cgminer 2.6.2 contains the new --icarus-options

I created a cgminer-2.6.2a.exe for windows that only has ICA + BFL in my git downloads
(so you don't need opencl installed or an ATI driver installed on windows)
https://github.com/kanoi/cgminer/downloads
(along with the cgminer-2.6.2a for Xubuntu 11.04)

I suspect that the most use here would be:
--icarus-options 57600
To change the baud

If you are running one of the older problems where you get one out of two FPGA's then the option would be:
--icarus-options 57600:2:1
(or --icarus-options :2:1 if you don't need to change the baud)

If anyone does actually use it - please let me know how it goes for you.
The --icarus-timing option will still be relevant if the boards aren't hashing at 380MH/s per pair of FPGA (or 190MH/s on a single FPGA)
As mentioned before, if your board is running about ~1% faster or more, it may be being slowed down by the default timing (idle at the end of each work item that doesn't find a share)

note: I had to download the windows driver package and put em in the directory (replacing at least one) to get cgminer to load. As soon as I manage to flash one of my CM1's i'll be able to give you more information.

flashed the first board with makomk's shortfin190, using kano's latest cgminer build w/ the windows driver pack on the git:

Summary of runtime statistics:

 [2012-08-03 20:12:13] Started at [2012-08-03 19:57:00]
 [2012-08-03 20:12:13] Pool: http://mine3.btcguild.com:8332
 [2012-08-03 20:12:13] Runtime: 0 hrs : 15 mins : 13 secs
 [2012-08-03 20:12:13] Average hashrate: 759.8 Megahash/s
 [2012-08-03 20:12:13] Solved blocks: 0
 [2012-08-03 20:12:13] Queued work requests: 262
 [2012-08-03 20:12:13] Share submissions: 152
 [2012-08-03 20:12:13] Accepted shares: 152
 [2012-08-03 20:12:13] Rejected shares: 0
 [2012-08-03 20:12:13] Reject ratio: 0.0%
 [2012-08-03 20:12:13] Hardware errors: 0
 [2012-08-03 20:12:13] Efficiency (accepted / queued): 58%
 [2012-08-03 20:12:13] Utility (accepted shares / min): 10.05/min

 [2012-08-03 20:12:13] Discarded work due to new blocks: 6
 [2012-08-03 20:12:13] Stale submissions discarded due to new blocks: 0
 [2012-08-03 20:12:13] Unable to get work from server occasions: 9
 [2012-08-03 20:12:13] Work items generated locally: 0
 [2012-08-03 20:12:13] Submitting work remotely delay occasions: 0
 [2012-08-03 20:12:13] New blocks detected on network: 4

 [2012-08-03 20:12:13] Summary of per device statistics:

 [2012-08-03 20:12:13] ICA0                | (5s):0.0 (avg):380.5 Mh/s | A:78 R:0 HW:0 U:5.2/m
 [2012-08-03 20:12:13] ICA1                | (5s):379.3 (avg):379.3 Mh/s | A:74 R:0 HW:0 U:4.9/m

will test more as soon as I flash the other cards.

[spiccioli]

@yohan : upgrading controller with a Linux system ? This is the 4th time I ask this here, I'm beginning to wonder what's going on.

Considering the intructions for doing this the "official" way are in a linux VM running on windows, and earlier in this thread full instructions for using the spi programming utility natively in linux or windows (with speed improvements too) I would imagine taking the same commandline arguments for the official steps and combining it with the native version of the same tool in linux should do the trick. Unfortunately I don't have the time to dig into this right now.

Also in theory, you can install virtualbox on your linux host, and use the same VM based instructions to do it that way (of course substituting anything that's linux specific as appropriate).

Hopefully that helps.

If not, perhaps some of the others on here who contributed some of the native steps earlier can chime in and help?

Also have you tried the IRC channel? (freenode.net #cm1)

Glasswalker,

I'm not aware of a linux spiprog, the official instructions require a windows host pc.

We're talking about programming the controller FPGA, not flashing permanently FPGA0-3 with xc3sprog.

Please tell us where to find a spiprog built for linux and/or its source code.

spiccioli.

[spiccioli]

Hi,

36 hours after this is what I get with the 190MH/s bitstream

Code:

 cgminer version 2.6.1 - Started: [2012-08-02 21:43:02]
--------------------------------------------------------------------------------
 (5s):9337.7 (avg):6996.7 Mh/s | Q:345542  A:191061  R:1349  HW:0  E:55%  U:87.1/m
 TQ: 20  ST: 21  SS: 66  DW: 7131  NB: 248  LW: 9725  GF: 3090  RF: 50
 Connected to http://pool.abcpool.co with LP as user ....
 Block: 0000065e317d52e913f469c332bd8117...  Started: [10:03:05]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 353.5/355.3Mh/s | A:10690 R:69 HW: 255 U: 4.87/m
 ICA  1:                | 360.3/354.2Mh/s | A:10681 R:70 HW: 333 U: 4.87/m
 ICA  2:                | 360.0/355.5Mh/s | A:10884 R:79 HW: 244 U: 4.96/m
 ICA  3:                | 360.0/347.6Mh/s | A:10314 R:69 HW: 836 U: 4.70/m
 ICA  4:                | 373.6/354.7Mh/s | A:10736 R:78 HW: 299 U: 4.89/m
 ICA  5:                | 355.8/355.5Mh/s | A:10746 R:76 HW: 210 U: 4.90/m
 ICA  6:                | 370.2/357.2Mh/s | A: 5500 R:43 HW:  69 U: 2.51/m
 ICA  7:                | 354.7/355.5Mh/s | A:10688 R:83 HW: 224 U: 4.87/m
 ICA  8:                | 371.9/337.9Mh/s | A:10133 R:56 HW:1128 U: 4.62/m
 ICA  9:                | 358.2/354.0Mh/s | A:10491 R:67 HW: 386 U: 4.78/m
 ICA 10:                | 363.6/357.1Mh/s | A: 5351 R:36 HW: 129 U: 2.44/m
 ICA 11:                | 362.5/347.6Mh/s | A: 4885 R:37 HW: 746 U: 2.23/m
 ICA 12:                | 336.9/336.3Mh/s | A: 8928 R:52 HW: 238 U: 4.07/m
 ICA 13:                | 339.8/335.6Mh/s | A: 9138 R:77 HW: 227 U: 4.16/m
 ICA 14:                | 356.1/341.7Mh/s | A: 9709 R:68 HW: 220 U: 4.42/m
 ICA 15:                | 338.4/341.5Mh/s | A: 9697 R:77 HW: 245 U: 4.42/m
 ICA 16:                | 341.3/343.2Mh/s | A: 9989 R:72 HW: 867 U: 4.55/m
 ICA 17:                | 370.0/355.6Mh/s | A:11011 R:81 HW: 230 U: 5.02/m
 ICA 18:                | 353.9/355.1Mh/s | A:10712 R:83 HW: 270 U: 4.88/m
 ICA 19:                | 349.8/355.6Mh/s | A:10780 R:76 HW: 203 U: 4.91/m
--------------------------------------------------------------------------------

A high number of invalid shares, even on ICA14/15 which now is running the 170 MH/s bistream.

The best performing couple, ICA17, has around 2% of invalids while ICA8 has more than 11% of invalids!

Maybe it's the high ambient temperature, we reach 30°C during the afternoon, I'm going to try to add a fan blowing on them to see if things get better.

BTW, ICA6 seems to have a stuck FPGA.

spiccioli.

[Cranky4u]

software improvement thoughts...

1. is it possible to monitor an FPGA, or set, and if it drops below a particular average U value (preferably user defined value) then the FPGA set is "reset"

2. monitor FPGA status so when the orange stand by / shit itself light comes on, then the FPGA set is reset

P.S.Spicolli...great post with an even better explination of waht ppl are seeing...it has helped me a lot just o get my head around some key figures

[kano]

software improvement thoughts...

1. is it possible to monitor an FPGA, or set, and if it drops below a particular average U value (preferably user defined value) then the FPGA set is "reset"

2. monitor FPGA status so when the orange stand by / shit itself light comes on, then the FPGA set is reset

P.S.Spicolli...great post with an even better explination of waht ppl are seeing...it has helped me a lot just o get my head around some key figures

Well if you are using cgminer - you can check on the FPGA's with the API (I wrote the API)

But that only tells you info from what cgminer knows, it won't know about the leds on the CM1
(NFI if you can even get that info from a CM1)

However, relying on U is not ideal ...
U is random - and can drop and rise - however, it should normally stay within 10% of the expected value after an hour or more runtime.
But there is no guarantee it will (independent of MH/s)

Really you should be tuning the parameters (--icarus-timing and --icarus-options) to cgminer and make sure the MH/s value is correct.
"--icarus-timing long" would keep the performance correct as long as the machine it's running on isn't CPU starved in any way

I'd go as far as saying that there is actually no reason that MH/s should be wrong any more if you use the correct parameters
... though, even that takes a while to settle, since the device reports results back at a different timing to the MH/s calculations so it takes a while

[Cranky4u]

software improvement thoughts...

1. is it possible to monitor an FPGA, or set, and if it drops below a particular average U value (preferably user defined value) then the FPGA set is "reset"

2. monitor FPGA status so when the orange stand by / shit itself light comes on, then the FPGA set is reset

P.S.Spicolli...great post with an even better explination of waht ppl are seeing...it has helped me a lot just o get my head around some key figures

Well if you are using cgminer - you can check on the FPGA's with the API (I wrote the API)

But that only tells you info from what cgminer knows, it won't know about the leds on the CM1
(NFI if you can even get that info from a CM1)

However, relying on U is not ideal ...
U is random - and can drop and rise - however, it should normally stay within 10% of the expected value after an hour or more runtime.
But there is no guarantee it will (independent of MH/s)

Really you should be tuning the parameters (--icarus-timing and --icarus-options) to cgminer and make sure the MH/s value is correct.
"--icarus-timing long" would keep the performance correct as long as the machine it's running on isn't CPU starved in any way

I'd go as far as saying that there is actually no reason that MH/s should be wrong any more if you use the correct parameters
... though, even that takes a while to settle, since the device reports results back at a different timing to the MH/s calculations so it takes a while

Kano,

My intent was to suggest an option to software reset the CM1 boards when they stop performing as expected. Can cgminer reset cards mid-mining? If so, can we automate this for when they crash?