Isokivi
|
|
August 01, 2012, 06:23:22 PM |
|
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
|
Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 01, 2012, 07:52:36 PM |
|
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 https://github.com/ckolivas/cgminer/pull/283Anyone 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
Activity: 107
Merit: 10
|
|
August 01, 2012, 08:01:18 PM |
|
board 62-0017 using cgminer no problems with flashing, no lost usb-connections. shipping_build.bit | don't know how well it worked | twin_test.bit | sometimes 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.bit | 0mh/s after 2 to 4 "Accepted" messages | glasswalkers fpgaminer_top.bit | 0mh/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): 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
|
|
August 01, 2012, 08:06:33 PM |
|
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
|
|
|
|
ebereon
|
|
August 01, 2012, 08:07:48 PM |
|
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 Update Glasswalker's bitstreams:not changed will update when new bitstream is out eb
|
|
|
|
Entropy-uc
|
|
August 01, 2012, 08:11:50 PM |
|
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
|
|
August 01, 2012, 08:23:38 PM |
|
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'.
|
|
|
|
ebereon
|
|
August 01, 2012, 08:30:14 PM Last edit: August 01, 2012, 09:13:20 PM by ebereon |
|
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
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 01, 2012, 08:54:45 PM |
|
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 https://github.com/ckolivas/cgminer/pull/283Anyone 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 ) 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
|
|
|
|
zefir
Donator
Hero Member
Offline
Activity: 919
Merit: 1000
|
|
August 01, 2012, 09:47:31 PM |
|
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 https://github.com/ckolivas/cgminer/pull/283Anyone 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: 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
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 01, 2012, 10:15:12 PM |
|
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 ) 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 Meh, I guess I shouldn't have assumed the original code (back when I started changing it) did that properly.
|
|
|
|
zefir
Donator
Hero Member
Offline
Activity: 919
Merit: 1000
|
|
August 01, 2012, 10:27:16 PM |
|
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 ) 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 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
|
|
August 01, 2012, 10:30:20 PM |
|
Can I pay for my order in BTC? If not, what are the options?
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 01, 2012, 10:31:39 PM |
|
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 ) 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)
|
|
|
|
|
Keninishna
|
|
August 01, 2012, 11:31:14 PM |
|
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 GLORIUS, thank you sir! I was hating spending so much time flashing my boards.
|
|
|
|
bitcowok
Newbie
Offline
Activity: 48
Merit: 0
|
|
August 02, 2012, 01:41:27 AM |
|
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
|
|
August 02, 2012, 02:54:33 AM |
|
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
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 02, 2012, 07:26:08 AM |
|
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 https://github.com/ckolivas/cgminer/pull/283Anyone 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: 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
|
|
August 02, 2012, 10:23:07 AM |
|
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?
|
|
|
|
|