Bitcoin Forum
December 04, 2016, 10:33:03 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251142 times)
Isokivi
Hero Member
*****
Offline Offline

Activity: 924


Items flashing here available at btctrinkets.com


View Profile WWW
August 01, 2012, 06:23:22 PM
 #1721

This is a make-shift guide for windows users for faster, permanent flashing. I have not yet tested it, but apparrentley Slipbye has had succes with it. It also gets us out of the virtual machine (for good ?)

21:13] <TheSeven> http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe/download
[21:14] <TheSeven> install that, make sure the board to be flashed is plugged, start the libusb filter wizard
[21:14] <TheSeven> select the USB composite device which shows an ID of 0403 8350
[21:14] <TheSeven> install the filter driver for that
[21:14] <TheSeven> download this: https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog/trunk/xc3sprog.exe
[21:14] <TheSeven> create a new file called cablelist.txt in the same directory
[21:15] <TheSeven> put this line inside that file:
[21:15] <TheSeven> cm1 ftdi 20000000 0x0403:0x8350:
[21:15] <TheSeven> open a command prompt in the directory where the files are and run these commands:
[21:15] <TheSeven> set CABLEDB=cablelist.txt
[21:15] <TheSeven> xc3sprog -c cm1
[21:15] <TheSeven> it should detect the fpgas
a this point you want to copy the .bit files you'll be using to the same folder as xc3sprog is in.
[21:16] <TheSeven> if that worked, you can go ahead with flashing like usual
[21:16] <TheSeven> xc3sprog -c cm1 -p 0 -Ixc6lx150.bit file_to_be_flashed.bit

Enjoy your 1-3hours of spare time per day Smiley

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
1480847583
Hero Member
*
Offline Offline

Posts: 1480847583

View Profile Personal Message (Offline)

Ignore
1480847583
Reply with quote  #2

1480847583
Report to moderator
1480847583
Hero Member
*
Offline Offline

Posts: 1480847583

View Profile Personal Message (Offline)

Ignore
1480847583
Reply with quote  #2

1480847583
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 01, 2012, 07:52:36 PM
 #1722

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working Smiley
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli
hm
Member
**
Offline Offline

Activity: 106


View Profile
August 01, 2012, 08:01:18 PM
 #1723

board 62-0017 using cgminer
no problems with flashing, no lost usb-connections.

shipping_build.bitdon't know how well it worked
twin_test.bitsometimes stable at around 380mh/s for up to two days, but most of the time between 40 and 200mh/s after some hours or minutes at around 380mh/s, never 0mh/s
makomk_icarus_cm1_140_test.bit0mh/s after 2 to 4 "Accepted" messages
glasswalkers fpgaminer_top.bit0mh/s
glasswalker2.bit (current)running >1d21h, pool reports between 100 and 300mh/s, cgminer output see below

disabling usb power by taping the 5v connector insibe the host-side usb plug did not resolve the stability issues.

=> unstable board

latest cgminer output (glasswalker2.bit):
Code:
cgminer version 2.6.1 - Started: [2012-07-31 00:28:42]
--------------------------------------------------------------------------------
 (5s):1509.8 (avg):948.9 Mh/s | Q:5119  A:10827  R:70  HW:0  E:212%  U:4.0/m
 TQ: 6  ST: 6  SS: 2  DW: 635  NB: 260  LW: 89625  GF: 108  RF: 13
 Connected to http://us2.eclipsemc.com:8337 with LP as user hm_worker
 Block: 000003525bdd224714873325e187e633...  Started: [21:44:19]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 187.7/186.7Mh/s | A:3542 R:21 HW:0 U:1.30/m
 ICA 1:                | 189.3/188.7Mh/s | A:3621 R:21 HW:0 U:1.33/m
 ICA 2:                | 194.7/193.8Mh/s | A:3664 R:28 HW:0 U:1.34/m
 ICA 3:                | 380.0/379.7Mh/s | A:   0 R: 0 HW:0 U:0.00/m
--------------------------------------------------------------------------------

testconpastas2
Full Member
***
Offline Offline

Activity: 199



View Profile
August 01, 2012, 08:06:33 PM
 #1724

well after 24h testing one board with  makomks 160  it worked well for  a while but after 8-10h (in the morning)  ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.

Are ICA 0 allways the same 2 fpgas? 0-1? 0-3?  or they are randomly assigned ?

can you detect wich fpga is frozen apart from watching which fpga green led is not blinking?  ( my boards are too high and i need to use a ladder).

I think my issues can be temperature ones. Here in Seville  40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)

I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop

Bitmessage: BM-2DAetLWJBKWHZoPbNCgg5z8jwaPpDYWwd4
gpg key id:C6EF5CE3
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 01, 2012, 08:07:48 PM
 #1725

Update on latest bitstreams after 17 hours:
Total 40 FPGA's = 10 boards SN#400+.

Makomk's oc bitstreams:
14x 200Mh, 22x 190Mh, 1x 180Mh, 3x 150Mh. That means 90% of all fpga's running @190Mh+ with <2.8% invalids!

Working bitstreams in percent:
200Mh oc = 35%
190Mh oc = 90%
180Mh oc = 90%
170Mh oc = 90%
160Mh = 100%
150Mh = 100%
140Mh = 100%

Next update with non oc'd bitstreams Wink


Update Glasswalker's bitstreams:
not changed will update when new bitstream is out

eb
Entropy-uc
Hero Member
*****
Offline Offline

Activity: 560


View Profile
August 01, 2012, 08:11:50 PM
 #1726

well after 24h testing one board with  makomks 160  it worked well for  a while but after 8-10h (in the morning)  ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.

Are ICA 0 allways the same 2 fpgas? 0-1? 0-3?  or they are randomly assigned ?

can you detect wich fpga is frozen apart from watching which fpga green led is not blinking?  ( my boards are too high and i need to use a ladder).

I think my issues can be temperature ones. Here in Seville  40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)

I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop

In windows ICA 0 will always be the com port that you point CGminer to with -S first.  I think linux might swap port assignments around if you restart.

40C is probably hot enough that you are overheating the FPGAs.  Enterpoint's thermal solution is very good, but it's constrained by cheap packaging of the Spartan-6.  With 8-9W I think you would be above the rated t-j for this device.
testconpastas2
Full Member
***
Offline Offline

Activity: 199



View Profile
August 01, 2012, 08:23:38 PM
 #1727

well after 24h testing one board with  makomks 160  it worked well for  a while but after 8-10h (in the morning)  ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.

Are ICA 0 allways the same 2 fpgas? 0-1? 0-3?  or they are randomly assigned ?

can you detect wich fpga is frozen apart from watching which fpga green led is not blinking?  ( my boards are too high and i need to use a ladder).

I think my issues can be temperature ones. Here in Seville  40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)

I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop

In windows ICA 0 will always be the com port that you point CGminer to with -S first.  I think linux might swap port assignments around if you restart.

40C is probably hot enough that you are overheating the FPGAs.  Enterpoint's thermal solution is very good, but it's constrained by cheap packaging of the Spartan-6.  With 8-9W I think you would be above the rated t-j for this device.

Thank you.

there isn't 40º at home, maybe 25-27 .
After resetting it seems it's working ok, maybe was bad luck I'll keep an eye on it. twin_test sometimes give me problems so maybe  is not a bitstream issue. if it last more than two days then I'll think about using makomks'.

 

Bitmessage: BM-2DAetLWJBKWHZoPbNCgg5z8jwaPpDYWwd4
gpg key id:C6EF5CE3
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 01, 2012, 08:30:14 PM
 #1728

Update on working miner soft with the new bitstreams:
Makomk's bitstreams:
  • latest MPBM git testing branch with icarus worker
  • latest cgminer
  • latest bfgminer

Glassworker's bitstream
  • latest MPBM git testing branch with glasswalkers worker
  • latest cgminer should work as Kano wrote it supports 57600 baud with the new options

If other miner soft works with one of the bitstreams, please info to me and i will update this.

eb
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 01, 2012, 08:54:45 PM
 #1729

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working Smiley
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli
It is enabled.
I don't filter anything out of the return data.
If I understand the Icarus bitstream source correctly (though I'm not sure), the only invalids I should get are if the share value is something like less than 256
Thus you should find ... on average ... around one HW: per 8 to 10 blocks you find.
I've actually never had any HW: in the months I've been mining on 2 Icarus boards (I just searched all my logs)
In cgminer a HW: is when the device returns a share, but it's not actually a share according to a re-hash of it.
All shares are checked that way in cgminer (i.e. Icarus also)

Having seen the recent problems with BFL - I suspect it's either a case of the Serial/USB driver queues data to avoid overwriting, or discards corrupt data before it gets back.
However, MPBM accesses the device via USB so I'm not sure exactly why it shows regular HW errors.

For anyone curious:
... and if you did actually add my pull request to the compile, the new option (as per the changed FPGA-README) is --icarus-options
Normally people would just specify --icarus-options 57600 to change the baud rate for all boards to 57600 instead of 115200
It also has a 'work_division' value which would normally be the default 2 (meaning the board divides the work in half for the FPGAs - you can specify 1, 2, 4 or even 8 Smiley )
And lastly 'fpga_count' which would normally be the same as work_division (but defaults to 2), however the earlier bitstreams had the issue where only one of 2 FPGA were hashing and thus setting that to 1 (instead of 2) will give back the correct MH/s
i.e. as per the example in FPGA-README --icarus-options 57600:2:1 would match a CM1 that hashes at standard icarus speed but only uses 1 of the 2 FPGA - and thus should display the MH/s correctly (and I/O at 57600 instead of 115200)
Of course, anyone specifically using --icarus-options please say so, so I can be sure if it actually is working correctly Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
August 01, 2012, 09:47:31 PM
 #1730

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working Smiley
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli

Hi spiccioli,

that bothered me too, since the information about invalids is missing completely in the Icarus stats.

What you can do with the original cgminer is enable verbose output. Do this either by adding --verbose to cgminer command line parameters or enable it interactively:
a) press D for display menu
b) press V for verbose
c) press <return> to get back to main menu

Invalid shares will be displayed with 'Share below target'. That helps to see if a board / bitstream combination is instable.

To track invalids long term, I use the following patch:
Code:
diff --git a/driver-icarus.c b/driver-icarus.c
index 5f2c78a..82d06f3 100644
--- a/driver-icarus.c
+++ b/driver-icarus.c
@@ -563,7 +566,12 @@ static int64_t icarus_scanhash(struct thr_info *thr, struct work *work,
        nonce = swab32(nonce);
 #endif
 
-       submit_nonce(thr, work, nonce);
+       if (!test_nonce(work, nonce)) {
+               applog(LOG_INFO, "%s%d: Share below target", icarus->api->name, icarus->device_id);
+               thr->cgpu->hw_errors++;
+               return 0;
+       }
+       submit_work_sync(thr, work);
 
        hash_count = (nonce & 0x7fffffff);
        if (hash_count++ == 0x7fffffff)

It will add those invalid shares to the HW counter displayed in the stats, quite useful to see how well a board did overnight with a given bitstream.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 01, 2012, 10:15:12 PM
 #1731

Yep - looks like I'm wrong.
I thought the hash check was automatically called inside test_nonce()
(well there is certainly no reason I can think of why it shouldn't for all devices Tongue)
I'll chase up getting that fixed ...

Edit: oh it is called in there, just the HW counter isn't incremented generically, the driver code has to ...
Well ... don't I look stupid Cheesy
Meh, I guess I shouldn't have assumed the original code (back when I started changing it) did that properly.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
August 01, 2012, 10:27:16 PM
 #1732

Yep - looks like I'm wrong.
I thought the hash check was automatically called inside test_nonce()
(well there is certainly no reason I can think of why it shouldn't for all devices Tongue)
I'll chase up getting that fixed ...

Edit: oh it is called in there, just the HW counter isn't incremented generically, the driver code has to ...
Well ... don't I look stupid Cheesy
Meh, I guess I shouldn't have assumed the original code (back when I started changing it) did that properly.
I was not sure if it would be semantically right to increment the hw_error counter in submit_nonce() generally without adding side effects. Just searching the code for places that modify it shows that some drivers do it privately, so adding it to the generic function might account events twice.

Anyhow, it was meant to be a temporary hack helping us to tackle down the problems with CM1. If you think it is correct to use it for Icarus in general (which IMHO is, since a wrong share is a HW error), I can submit it as pull request, or I'm also fine if you just add it to one of your staging patch sets.

Thanks, zefir

tenzor
Sr. Member
****
Offline Offline

Activity: 316


View Profile
August 01, 2012, 10:30:20 PM
 #1733

Can I pay for my order in BTC? If not, what are the options?
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 01, 2012, 10:31:39 PM
 #1734

No, the problem has been there since luke-jr first wrote the bitforce code (xiangfu copied the original bitforce code and then we rewrote ... most of it Tongue)
I suspect bitforce has the same problem - I'll check later.

It should be done in cgminer.c in my opinion and I'll discuss with ckolivas if he can think of a reason why it shouldn't
(i.e. yes all the drivers will need changing)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 01, 2012, 10:32:28 PM
 #1735

Can I pay for my order in BTC? If not, what are the options?

Here are some informations about this board -> http://www.enterpoint.co.uk/cairnsmore/cairnsmore1.html

Payment options are also shown on it, just scroll down a bit.

eb
Keninishna
Hero Member
*****
Offline Offline

Activity: 551



View Profile WWW
August 01, 2012, 11:31:14 PM
 #1736

This is a make-shift guide for windows users for faster, permanent flashing. I have not yet tested it, but apparrentley Slipbye has had succes with it. It also gets us out of the virtual machine (for good ?)

21:13] <TheSeven> http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe/download
[21:14] <TheSeven> install that, make sure the board to be flashed is plugged, start the libusb filter wizard
[21:14] <TheSeven> select the USB composite device which shows an ID of 0403 8350
[21:14] <TheSeven> install the filter driver for that
[21:14] <TheSeven> download this: https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog/trunk/xc3sprog.exe
[21:14] <TheSeven> create a new file called cablelist.txt in the same directory
[21:15] <TheSeven> put this line inside that file:
[21:15] <TheSeven> cm1 ftdi 20000000 0x0403:0x8350:
[21:15] <TheSeven> open a command prompt in the directory where the files are and run these commands:
[21:15] <TheSeven> set CABLEDB=cablelist.txt
[21:15] <TheSeven> xc3sprog -c cm1
[21:15] <TheSeven> it should detect the fpgas
a this point you want to copy the .bit files you'll be using to the same folder as xc3sprog is in.
[21:16] <TheSeven> if that worked, you can go ahead with flashing like usual
[21:16] <TheSeven> xc3sprog -c cm1 -p 0 -Ixc6lx150.bit file_to_be_flashed.bit

Enjoy your 1-3hours of spare time per day Smiley

GLORIUS, thank you sir! I was hating spending so much time flashing my boards.
bitcowok
Jr. Member
*
Offline Offline

Activity: 48


View Profile
August 02, 2012, 01:41:27 AM
 #1737

Here's a little write-up on my efforts last night with CM1 serial 62-0023.

Fired it up for the first time (been sitting gathering dust waiting for some worthwhile bitstreams etc), used my gaming pc (windows) to update controller to 1.3

Connected to the mining PC (gentoo), compiled xc3sprog with some help from arne and others in the IRC channel, and programmed makomk's 190 bitstream.

Configured MPBM, and mucked around with baud rates and dip settings till it was all working, again with more help from ebereon and others (thanks) on IRC. Note with controller 1.3, SW6 #1 dip controls 50/100mhz clock, which also sets 115200/57600 baud. This needs to be reset in the miner worker if changed. At one point the dip switch looked like it was off but hadnt properly "clicked" into the position somehow. It took me a while to realise, a click on and off (and powercycle board) fixed it. You can see the red flashing light next to the controller flashes at half the speed in 50mhz mode quite clearly.

Results for 190mhz: 100% invalids.

Reprogrammed with 150 makomk bitstream:
Results for 75mhz (hadnt quite figured out the dip setting problem above at this stage) : 30% invalids

Reprogrammed with 140 makomk bitstream:
Results for 140mhz: 80% invalids
Results for 70mhz: ~25% invalids

Thats how it stands currently, at 70mhz I get 280MH/s for the whole board, with 25% of that being invalid.

Well its no wonder Enterpoint had difficulties initially and limited the shipping test bitstream to 50mhz.

I've sent an email to Enterpoint asking about the possible capacitor fix that applies to the first 50 boards, or complete RMA.
Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
August 02, 2012, 02:54:33 AM
 #1738

0   ICA   0   Y   Alive   0.00°C   379.81   379.73   14,494   22   0   U5.33/m   
1   ICA   1   Y   Alive   0.00°C   379.81   379.62   14,317   33   0   U5.27/m   

SUMMARY   1day 21h 17m 27s

So far so good with makomk's 190 bitstream, getting to that 48h Mark.

spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 02, 2012, 07:26:08 AM
 #1739

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working Smiley
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli

Hi spiccioli,

that bothered me too, since the information about invalids is missing completely in the Icarus stats.

What you can do with the original cgminer is enable verbose output. Do this either by adding --verbose to cgminer command line parameters or enable it interactively:
a) press D for display menu
b) press V for verbose
c) press <return> to get back to main menu

Invalid shares will be displayed with 'Share below target'. That helps to see if a board / bitstream combination is instable.

To track invalids long term, I use the following patch:
Code:
diff --git a/driver-icarus.c b/driver-icarus.c
index 5f2c78a..82d06f3 100644
--- a/driver-icarus.c
+++ b/driver-icarus.c
@@ -563,7 +566,12 @@ static int64_t icarus_scanhash(struct thr_info *thr, struct work *work,
        nonce = swab32(nonce);
 #endif
 
-       submit_nonce(thr, work, nonce);
+       if (!test_nonce(work, nonce)) {
+               applog(LOG_INFO, "%s%d: Share below target", icarus->api->name, icarus->device_id);
+               thr->cgpu->hw_errors++;
+               return 0;
+       }
+       submit_work_sync(thr, work);
 
        hash_count = (nonce & 0x7fffffff);
        if (hash_count++ == 0x7fffffff)

It will add those invalid shares to the HW counter displayed in the stats, quite useful to see how well a board did overnight with a given bitstream.

Hi zefir,

thanks for the info and patch, I'm seeing several share below target now!

This explains also while a few fpgas have U: lower than others.

spiccioli
Cranky4u
Hero Member
*****
Offline Offline

Activity: 770



View Profile WWW
August 02, 2012, 10:23:07 AM
 #1740

I get the same error as Ebereon I have 62-0013. The xc3sprog –c cm1 –p 0 twin_test.bit works, but loading to SPI Flash with xc3sprog –c cm1 –p 0 –I xc6lx150.bit twin_test.bit gives me the error below. 

JEDEC: ff ff 0xff 0xff
unknown JEDEC manufacturer: ff
ISF Bitfile probably not loaded

Also looking forward to programming these in Linux.

Thanks!


trying to flash 2 * FPGA boards and get this same problem on my Win 7 64 bit PC...any help on solving?

Pages: « 1 ... 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!