Pages:
Author

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

sr. member
Activity: 462
Merit: 251
August 04, 2012, 12:44:10 PM
@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.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.

Yohan, would it be possible to provide either the Windows source code of SPIProg, or at least a detailed description of what it does? I'd be glad to support you with getting this part working with Linux. It might be even doable with a script on top of the xc3sprog tools.

Allowing you to concentrate on more important things (controller FW) is currently for sure the best contribution we could get.

Thanks.

Probably is the answer. I'll talk it through with the team on Monday to see if there are any issues in doing this e.g. partner IP that we can't release.
hero member
Activity: 648
Merit: 500
August 04, 2012, 12:42:09 PM
In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat


This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

I completely shut down, unplugged the usb, unplugged power to the CM1, plugged in the power again, turned on computer, plugged in usb. no-go
donator
Activity: 919
Merit: 1000
August 04, 2012, 12:40:40 PM
@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.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.

Yohan, would it be possible to provide either the Windows source code of SPIProg, or at least a detailed description of what it does? I'd be glad to support you with getting this part working with Linux. It might be even doable with a script on top of the xc3sprog tools.

Allowing you to concentrate on more important things (controller FW) is currently for sure the best contribution we could get.

Thanks.
sr. member
Activity: 462
Merit: 251
August 04, 2012, 12:39:48 PM
In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat


This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

Also if you had dip switches set for programming did you put them to the correct settings for running?
hero member
Activity: 648
Merit: 500
August 04, 2012, 12:31:53 PM
In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat
sr. member
Activity: 462
Merit: 251
August 04, 2012, 11:58:06 AM
...
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?
No.
cgminer has an API where you can ask it for information
You can then act on that information
(including telling cgminer to stop or even restart or many other commands as documented in API-README)

If we put support into the Controller and the array FPGA supports reset on a suitable pin (and uses it suitably internally) it's possible to do 2 things on CM1 for a frozen/under-performing FPGA issue. The first is we can apply a reset to an individual array FPGA or any combination of them. We can also switch off the 1.2V rails individually from the controller. The 3.3V can be turned off as well but that is across all 4 FPGAs.

The are several ways these things can be implemented. Anything from in-band messaging to using spare I/Os from the FTDI interface.
sr. member
Activity: 462
Merit: 251
August 04, 2012, 11:47:43 AM
@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.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 04, 2012, 07:05:09 AM
...
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?
No.
cgminer has an API where you can ask it for information
You can then act on that information
(including telling cgminer to stop or even restart or many other commands as documented in API-README)
hero member
Activity: 810
Merit: 1000
August 04, 2012, 04:51:57 AM
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?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 04, 2012, 04:13:05 AM
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
hero member
Activity: 810
Merit: 1000
August 04, 2012, 03:36:38 AM
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
legendary
Activity: 1379
Merit: 1003
nec sine labore
August 04, 2012, 03:27:46 AM
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.
legendary
Activity: 1379
Merit: 1003
nec sine labore
August 04, 2012, 03:04:07 AM
@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.
hero member
Activity: 648
Merit: 500
August 03, 2012, 04:55:50 PM
... and in case anyone was interested Smiley

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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 03, 2012, 04:40:26 PM
... and in case anyone was interested Smiley

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)
sr. member
Activity: 407
Merit: 250
August 03, 2012, 04:18:34 PM
@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)

hero member
Activity: 896
Merit: 1000
August 03, 2012, 04:07:01 PM
@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.
hero member
Activity: 648
Merit: 500
August 03, 2012, 03:11:10 PM
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?
sr. member
Activity: 462
Merit: 251
August 03, 2012, 02:51:47 PM
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.
hero member
Activity: 648
Merit: 500
August 03, 2012, 02:41:39 PM

How do I tell which controller version is loaded on my boards?
Pages:
Jump to: