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 |
|
|
|
I would once again like to urge more people who own cm1's to contribute to this bounty, you know there are a handfull of brillian individuals workin very hard at the moment to provide us a more efficient tool for earning. Most of you are allready benefitting from this. Im not saying it's only because of this bounty.. but Im fairly sure the pace things have been progressing for the last week or so has much to do with this bounty and as any well-informed virtual miner knows time is everything in this game.
As of now just 12 of us have sent some coins. https://blockchain.info/address/1CM1bj7jxVskkvKE2kcw6L16rHMXL38aFmspiccioli |
|
|
|
I've built cgminer 2.6.1 for linux 32bit (works ok on my ubuntu 12.04 64bit) with OpenCL/ADL disabled and just icarus support enabled. If you trust my build you can get it from: http://p2pool.soon.it/cgminer/cgminer-2.6.1Download it, issue a to make it executable and it's ready to go. spiccioli |
|
|
|
Boards 0001 to 0050 we will either replace with later issue boards or offer you a credit against new purchases as compensation if you still have an issue in 4 weeks time when we might have some unallocated board stock available again.
We now know from the work we are doing that the outer copper layers on these boards is slightly thinner that the boards 0051 onwards have. We can now more or less bring these boards back up to the 0051 onwards level by simply adding a few simple capacitors. That can be done in a few minutes and we are doing further testing on these boards to find out more and make those mods on any available boards we have. It's entirely possible we may also come up with firmware solution to solve this as well.
Thanks for the explanation. So the question of the fan attached on fan pins near FPGA3 as a source of noise is ruled out, isn't it? spiccioli. |
|
|
|
I would love to test the bitstream, but virtual box usb has issues, most the time it refuses any usb connected devices, even though they are installed and work fine in Windows.
To get around a few steps, the furthest along I've got it using wget all the files via my server, since I can't get my usb pen mounted either.
It kinda worked before, now the keeps complaining about "USB device is busy with a previous request".
Tried many of the usual stuff suggested on the virtual box support site, but it's short lived or doesn't work.
Their needs to be an easier way, maybe a native program for linux, rather than having to go via virtualbox.
Surely xc3sprog would work in a normal linux environment right? Don't mind sending a few bitcoins to someone who can help me out.
Seems a waste for me to be helping towards the bounty, then can't actually use it.
Lethos, are you trying to flash the SPI firmaware (to update it to controller rev. 1.3) or a bitstream from makomk? For the latter, you don't need windows at all, but for the former right now you can only do it in windows. spiccioli I am trying to use makomk bitstream. I believe my boards were already updated to 1.3v. So how do I update to the latest bitstream without using virtualbox? Lethos, start your virtualbox instance and then scp xc3sprog to the linux pc. Let's say that you have a user called "miner" on your linux box you issue this command from the virtualbox running image scp ./xc3sprog miner@ip-of-your-linux-box:
example scp ./xc3sprog spiccioli@192.168.1.100:
mind the colon at the end of the command. This will ask miner's password and copy xc3sprog to the home dir of user miner on the linux box. Then, from the linux box you use the same commands as if you were inside the virtualbox image. Mind you that if you have multiple boards attached to the linux box you need to: - unplug one board
- move SW1 switch 3 to OFF (start of programming)
- plug it again, this makes the board the "active" board for xc3sprog (1)
- issue a ./xc3sprog -c cm1 -j to see that the board is visible
- issue the xc3sprog command for each FPGA
- unplug the board again
- move SW1 switch 3 to ON
- move SW1 switch 1 to OFF (resets board) then after a few seconds to ON again
- when the yellow leds are on, plug the board again
(1) I don't know how to address one board between a few using xc3sprog if not using this series of plugging/unplugging to make it the "active" board. I've used this method several times and it works with my ubuntu server 12.04. SW2 and SW5 have all switches ON, SW3 and SW4 are ON-OFF-ON-ON SW6 switch 1 is OFF Tell me if it works. spiccioli. EDIT: the xc3sprog has to be run as sudo otherwise it cannot access the board you're trying to flash |
|
|
|
Any noticeable difference in mining with any of the bitstreams that presented problems on that slot before?
I don't know, board kept hashing. I think I should test it on board #8, but on that board I can't install makomk's bistreams and I have the old twin_test.bit running. Yohan, on the other hand, should have the means to test if it is the power to the fan creating problems. spiccioli. |
|
|
|
I would love to test the bitstream, but virtual box usb has issues, most the time it refuses any usb connected devices, even though they are installed and work fine in Windows.
To get around a few steps, the furthest along I've got it using wget all the files via my server, since I can't get my usb pen mounted either.
It kinda worked before, now the keeps complaining about "USB device is busy with a previous request".
Tried many of the usual stuff suggested on the virtual box support site, but it's short lived or doesn't work.
Their needs to be an easier way, maybe a native program for linux, rather than having to go via virtualbox.
Surely xc3sprog would work in a normal linux environment right? Don't mind sending a few bitcoins to someone who can help me out.
Seems a waste for me to be helping towards the bounty, then can't actually use it.
Lethos, are you trying to flash the SPI firmaware (to update it to controller rev. 1.3) or a bitstream from makomk? For the latter, you don't need windows at all, but for the former right now you can only do it in windows. spiccioli |
|
|
|
You know, that's an interesting thought...
I believe on the default controller bitstreams it monitors fan rpm, and kills mining if the fan isn't turning, so it might be hardcoded right now for that port. But you could always try moving the fan to one of the other fan headers and see if it affects the noise.
Once I get a bit further with mine I'll test the same (if I still have problems with communications)
I've just tested it on one board, controller 1.3, moving fan connector to the one beside FPGA0 does not stop the board, so it seems that it is not hard-coded. spiccioli |
|
|
|
I don't know exactly why, no...
But from the looks of it as I've said before, there is inductive noise on the comm/clock lines.
This noise (and it's severity) is different for each FPGA position, due to the routing of the wires, and proximity to other FPGAs, and so on. Position 3 seems to be the worst, so it is the least stable.
[...]
Can the noise that FPGA3 suffers come from the fan which in all my boards is connected to the pins beside FPGA3? spiccioli |
|
|
|
I don't know exactly why, no... [...] Though most of this is conjecture, from observations, and the odd speculative chat back and forth with Yohan, so I won't say for certain that these are the problems. And there are still plenty of "tricks" that can be used to work around these problems. I still think the hardware is good, a few bugs sure, but I don't think these problems are killers. Does that help? Yes thanks, it eases my mind to know that you still have tricks up your sleeve to work around FPGA3 issues spiccioli |
|
|
|
Just a quick touch-base.
Glasswalker, can you give us some details about the problems with FPGA3 and/or (I don't know if they're related) boards with serial number less than 50? Do you exactly know what's wrong on the hardware side and why FPGA3 does not work with your bitstream? spiccioli |
|
|
|
Boards 0-50 have SERIOUS issues, later boards just issues  "Serious" as in "cannot be fixed in software"? I'm rather concerned because I have "pre-50" board. Yohan, can you comment on this? I don't know how much serious problems they have or whether they can be fixed in software, but the fact that makomk bitstream doesn't work on them while it works on ebereon's ones (which has boards with serial number >= 400) without issues makes me think that it is serious enough. spiccioli |
|
|
|
now cmd is missing destination operand
cp /mnt/*bit <return>
this is the cmd line in the book but it asks for a destination - the later cmd to DL to CM1 is "xc3sprog -c cm1 -p 0 *.bt" so I assume the cp cmd copies teh file to the root...is this correct? if so how can I cp to the root directory as desitnation
I am learning cp /mnt/*bit /root this got a copy into the root dir for sc3sprog Crank4u, you can use "." to mean current directory, like in spiccioli |
|
|
|
Yes, the FTDI Chip have a serial number. I see it when I start the Enterpoint VM and under the USB devices when i hold the mouse over a board it shows my something like FXZGXXX.
Thanks, now I need a way to be able to read it on linux, since lsusb tells me nothing. spiccioli Not true, it needs to be called as root to see serial number sudo lsusb -v | grep iSerial
iSerial 1 0000:00:10.4
iSerial 1 0000:00:10.0
iSerial 1 0000:00:10.1
iSerial 1 0000:00:10.2
iSerial 0
iSerial 0
iSerial 3 FTVJ5AGN
iSerial 3 FTVJ5A9N
iSerial 3 FTVJ5AFK
iSerial 3 FTVJ5AB9
iSerial 3 FTVJ59WC
iSerial 3 FTVIDJ4R
iSerial 3 FTVJ88QX
iSerial 0
iSerial 3 FTVIUONW
iSerial 3 FTVJ5ALH
iSerial 3 FTVJ88VS
here they are, FTV.... spiccioli |
|
|
|
Yes, the FTDI Chip have a serial number. I see it when I start the Enterpoint VM and under the USB devices when i hold the mouse over a board it shows my something like FXZGXXX.
Thanks, now I need a way to be able to read it on linux, since lsusb tells me nothing. spiccioli |
|
|
|
Hi, I have a question: do the boards have a serial number? I mean, not the one written on the outside, but one that can be used to write an udev rule so that the same board ends up on the same ttyUSBnn no matter what cable/usb hub port I'm using. spiccioli. ps. I'm giving up on bitstreams , either boards below serial 400 have issues or the 160 bitstream does have problems. I can't mine for more than a few hours, sometimes even ony few minutes, before cgminer tells me they failed. with twin_test.bit I could mine for weeks without problems, slowly, but without problems. I think atleast boards 0-50 have issues. Not sure about 50-400. Boards 0-50 have SERIOUS issues, later boards just issues I have 9 boards past serial number 100. BTW, Glasswalker tells us that the serial code inside the icarus bitstream is not optimal for cairnsmore hardware, but I fear that this is not the whole story since latest report from Yohan says that they still cannot mine on FPGA3. On the other end makomk's bitstreams mine without problems on FPGA3, with latest boards at least. So I'm starting to think that boards past number 400 (or maybe a lower number) are OK, while previous boards have various degrees of hardware problems which make it more or less impossibile to use all four FPGAs (or use them reliably). I'd like to have a definitive answer on this by Yohan so that I can stop spending my time trying to make my boards work. spiccioli |
|
|
|
Hi, I have a question: do the boards have a serial number? I mean, not the one written on the outside, but one that can be used to write an udev rule so that the same board ends up on the same ttyUSBnn no matter what cable/usb hub port I'm using. spiccioli. ps. I'm giving up on bitstreams , either boards below serial 400 have issues or the 160 bitstream does have problems. I can't mine for more than a few hours, sometimes even ony few minutes, before cgminer tells me they failed. with twin_test.bit I could mine for weeks without problems, slowly, but without problems. |
|
|
|
Well, the shortfin_icarus_cm1_test_160.bit on four of my boards (serial n. 104, 130,134,137) worked on two of them for just a few hours. cgminer version 2.4.3 - Started: [2012-07-30 23:17:35]
--------------------------------------------------------------------------------
(5s):1968.1 (avg):2250.2 Mh/s | Q:30300 A:14675 R:75 HW:0 E:48% U:23.7/m
TQ: 10 ST: 23 SS: 0 DW: 735 NB: 66 LW: 174 GF: 0 RF: 3
Connected to http://pool.abcpool.co with LP as user spiccioli.cm1
Block: 000000f32622a03fa252476876f28739... Started: [09:07:39]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.9/360.8Mh/s | A:1626 R: 5 HW:0 U:2.62/m
ICA 1: | 379.9/361.5Mh/s | A:1284 R: 6 HW:0 U:2.07/m
ICA 2: | 349.5/340.5Mh/s | A:2692 R:19 HW:0 U:4.35/m
ICA 3: | 351.0/340.2Mh/s | A:2620 R: 9 HW:0 U:4.23/m
ICA 4: | 350.8/341.3Mh/s | A:2705 R:16 HW:0 U:4.37/m
ICA 5: | 351.5/341.5Mh/s | A:2582 R: 8 HW:0 U:4.17/m
ICA 6: | OFF / 40.9Mh/s | A: 292 R: 5 HW:0 U:0.47/m
ICA 7: | OFF / 41.4Mh/s | A: 303 R: 3 HW:0 U:0.49/m
ICA 8: | OFF / 41.1Mh/s | A: 293 R: 2 HW:0 U:0.47/m
ICA 9: | OFF / 41.0Mh/s | A: 278 R: 2 HW:0 U:0.45/m
--------------------------------------------------------------------------------
ICA0/1 is serial n. 8, and has the old twin_test.bit on it spiccioli |
|
|
|
You have the wrong one, the one you want (trust me) is:
shortfin_icarus_cm1_test_160.bit
Yeah, there probably shouldn't be any reason to use the older non-shortfin variants anymore. The newer ones are 99.9% the same except with improved reliability. makomk 160.bit on board #62-0008 gives a U: of 0.5 - 0.8 after an hour of hashing using cgminer 2.4.3 on linux.
Wait, does that mean your board serial number is 8? If so, don't bother - apparently my bitstreams don't work on boards 1-50. Ah, OK, I was not aware of this fact. Thanks. spiccioli |
|
|
|
makomk 160.bit on board #62-0008 gives a U: of 0.5 - 0.8 after an hour of hashing using cgminer 2.4.3 on linux.
I'm trying now to flash the 140 MH/s one to see if it is better.
spiccioli
You have the wrong one, the one you want (trust me) is: shortfin_icarus_cm1_test_160.bitIsokivi, sorry, I was not clear enough shorting the bitstream name from shortfin_icarus_cm1_test_160.bit to 160.bit, but I'm using the correct one Anyway, with the 140.bit I always fail cgminer test, even after a few complete power-off/on of the board, so I think I'm gonna flash the old twin_test.bit for now. spiccioli |
|
|
|
|
Show Posts
