Oh well, lets see what tomorrow brings, ill try later on once again.
http://dl.dropbox.com/u/11807134/cairnsmore-06-20-2012.torrent someone asked for a torrent?
Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 89. (Read 286370 times)
first time i tried programming to SPI something went wrong and the unit didn't work, so i turned it off and started with only the temporary solution and it worked the first time. Dunno if that helps...
I turned it off, set the dips as described and turned on, the VM took it and i programmed it, disconnected, then switched the SW6.
I turned it off, set the dips as described and turned on, the VM took it and i programmed it, disconnected, then switched the SW6.
well, then i guess i had both (after several retries) programmed sucessfully (twice 
. tried enterpoint and normal cgminer, even reinstalled the com ports. Mmmhh, Im going to party now, 100 Mh/s mode for the win. I will try later again, drunk things work better anyway
When did you change the dip settings, after "default"dip power up, or powered up in "fast 380" dip mode?
. tried enterpoint and normal cgminer, even reinstalled the com ports. Mmmhh, Im going to party now, 100 Mh/s mode for the win. I will try later again, drunk things work better anyway When did you change the dip settings, after "default"dip power up, or powered up in "fast 380" dip mode?
yep
ebereon: Sounds like what i did. After "succesful" programming of sp6 #0 , did sp6 #1 turn red and yellow?
rampone, as you have the serial 0015 and I have 0016, I think we should have the same shipping firmware.
What I did for programming:
SW1 = 1 off, 234 on (115200 baud)
SW6 = 1234 on
SW2 = 1234 on
SW3 = 12 off, 34 on
SW4 = 12 off, 34 on
SW5 = 1234 on
I use now the temporary programming:
xc3sprog –c cm1 –p 0 twin_test.bit
xc3sprog –c cm1 –p 3 twin_test.bit
After both are done, I disconnected it from the VM.
SW6 = 1 off, 234 on (changed without powering down!)
and started mpbm (should be working also with cgminer).
Switches for working twin_test.bit:
SW1 = 1 off, 234 on (115200 baud)
SW6 = 1 off, 234 on
SW2 = 1234 on
SW3 = 12 off, 34 on
SW4 = 12 off, 34 on
SW5 = 1234 on
What I did for programming:
SW1 = 1 off, 234 on (115200 baud)
SW6 = 1234 on
SW2 = 1234 on
SW3 = 12 off, 34 on
SW4 = 12 off, 34 on
SW5 = 1234 on
I use now the temporary programming:
xc3sprog –c cm1 –p 0 twin_test.bit
xc3sprog –c cm1 –p 3 twin_test.bit
After both are done, I disconnected it from the VM.
SW6 = 1 off, 234 on (changed without powering down!)
and started mpbm (should be working also with cgminer).
Switches for working twin_test.bit:
SW1 = 1 off, 234 on (115200 baud)
SW6 = 1 off, 234 on
SW2 = 1234 on
SW3 = 12 off, 34 on
SW4 = 12 off, 34 on
SW5 = 1234 on
grmpf, with alot of retries and sp3 dips all on and the 1,2 off at the sp6 #1 #2 that are unused, I still cant manage to hash.
I see the red light flash shortly (the "detect" test work?) at the sp6 #0 and #3, also yellow turns off for like a 100th second and then on when I start cgminer and it sends the quick test work. after that (got 0000000000 should be x000specific).
Did the SP6 #1 and #2 turn on red and yellow at the same time for you after progamming 0 and 2? it did here?!
I guess back to slow for me...and wait for tomorrow
I see the red light flash shortly (the "detect" test work?) at the sp6 #0 and #3, also yellow turns off for like a 100th second and then on when I start cgminer and it sends the quick test work. after that (got 0000000000 should be x000specific).
Did the SP6 #1 and #2 turn on red and yellow at the same time for you after progamming 0 and 2? it did here?!
I guess back to slow for me...and wait for tomorrow
Excellent followup.
Atta-boy, ebereon!
Atta-boy, ebereon!
Ok for those that work with mpbm, i made a quick change and have made a "cairnsmoreworker" for it! (copy from icarusworker with change)
Download the files here: http://www.wuala.com/ebereon/Shared/bitcoin/mpbm_changed/
Go in mpbm folder "..\mpbm\modules\theseven\", create a new folder named "cairnsmore" and put the files in it. If you restart mpbm you now will see a new worker "theseven.cairnsmore worker v0.1.0beta". It work the same as the icarus worker, but with my change for the job interval i've described earlier. So you can leave the icarusworker file untouched, so icarus boards will also work as befor.
It's a temporary solution and work correct only with the bitstream "twin_test.bit".
Download the files here: http://www.wuala.com/ebereon/Shared/bitcoin/mpbm_changed/
Go in mpbm folder "..\mpbm\modules\theseven\", create a new folder named "cairnsmore" and put the files in it. If you restart mpbm you now will see a new worker "theseven.cairnsmore worker v0.1.0beta". It work the same as the icarus worker, but with my change for the job interval i've described earlier. So you can leave the icarusworker file untouched, so icarus boards will also work as befor.
It's a temporary solution and work correct only with the bitstream "twin_test.bit".
@Yohan.
Many people, including myself, are impressed with your operation.
I'm curious. If a semi-community funded ASIC solution were to come to fruition, where the chips could be had for a fair rate, would you find a business of producing rackmount/high capacity systems attractive?
I'm testing the waters for a possible synergistic effort.
Thanks.
This is only a temporary solution!
And I think it is a fine temporary solution. 
Was merely asking for clarification. Which you provided, thank you.
...I changed the calculation of the "self.stats.mhps" ...
You can also change it in your file ...
However, question, what about if you have a Quad XC connected and a BFL Single (or one of the other FPGAs currently available) connected?
Does fixing the Quad with this tweak break the other(s)?
It's only a change in the icarusworker.py, so yes it will break working correctly with an icarus board. Others have there own files and should not get affected except the icarus. I wish TheSeven would make a own mpbm worker for the cairnsmore1 board, but i think we have to wait until this board work as it should. This is only a temporary solution!
...I changed the calculation of the "self.stats.mhps" ...
You can also change it in your file ...
However, question, what about if you have a Quad XC connected and a BFL Single (or one of the other FPGAs currently available) connected?
Does fixing the Quad with this tweak break the other(s)?
Ah gotcha. So really 3 of 8?
Yes, 3 out of 8
Gets a bit confusing talking about FPGAs and boards in the same sentence Awesome!!
Also can somebody seed the .ova file via torrent?
For some reason I keep getting cut from the direct download site.
Also can somebody seed the .ova file via torrent?
For some reason I keep getting cut from the direct download site.
Thanks!
I uploading it to wuala, will take some minutes.
http://www.wuala.com/ebereon/Shared/bitcoin/cairnmore1/
@yohan: If you don't want that your files uploaded on other sides, please give me a message, i will delete it
For me only temporary is working, can not programm with SPI.
I got 280 - 350 Mh/s on p2pool.
If someone is interessted in my changed icarusworker.py from mpbm, here is the download:
http://content.wuala.com/contents/ebereon/Shared/bitcoin/mpbm_changed/icarusworker.py?dl=1
I changed the calculation of the "self.stats.mhps" in line 329. I just divided it by 2. The mpbm is checking the reported Mh/s from the device and calculate the job interval. In the normal file it calculates 380Mh/s per fpga, but we know this is not correct it's just 190 or so. So the job interval is wrong and every job is canceled to early. That's what i changed in the file. The displayed Mh/s is now also correct.
I hope it helps someone
I got 280 - 350 Mh/s on p2pool.
If someone is interessted in my changed icarusworker.py from mpbm, here is the download:
http://content.wuala.com/contents/ebereon/Shared/bitcoin/mpbm_changed/icarusworker.py?dl=1
I changed the calculation of the "self.stats.mhps" in line 329. I just divided it by 2. The mpbm is checking the reported Mh/s from the device and calculate the job interval. In the normal file it calculates 380Mh/s per fpga, but we know this is not correct it's just 190 or so. So the job interval is wrong and every job is canceled to early. That's what i changed in the file. The displayed Mh/s is now also correct.
I hope it helps someone
You can also change it in your file, just search for "self.stats.mhps = nonceval / 500000. / delta" and change it to "self.stats.mhps = (nonceval / 500000. / delta) / 2"
For me only temporary is working, can not programm with SPI.
I got 280 - 350 Mh/s on p2pool.
If someone is interessted in my changed icarusworker.py from mpbm, here is the download:
http://content.wuala.com/contents/ebereon/Shared/bitcoin/mpbm_changed/icarusworker.py?dl=1edit: made a own worker, see https://bitcointalksearch.org/topic/m.978580
I changed the calculation of the "self.stats.mhps" in line 329. I just divided it by 2. The mpbm is checking the reported Mh/s from the device and calculate the job interval. In the normal file it calculates 380Mh/s per fpga, but we know this is not correct it's just 190 or so. So the job interval is wrong and every job is canceled to early. That's what i changed in the file. The displayed Mh/s is now also correct.
I hope it helps someone
I got 280 - 350 Mh/s on p2pool.
If someone is interessted in my changed icarusworker.py from mpbm, here is the download:
I changed the calculation of the "self.stats.mhps" in line 329. I just divided it by 2. The mpbm is checking the reported Mh/s from the device and calculate the job interval. In the normal file it calculates 380Mh/s per fpga, but we know this is not correct it's just 190 or so. So the job interval is wrong and every job is canceled to early. That's what i changed in the file. The displayed Mh/s is now also correct.
I hope it helps someone
you could probably use enterpoints cgminer build and not have to switch the SW1 #1 DIP as i believe that switches between 115,200 and 57,600 baud rates.
default cgminer uses 115,200, enterpoints build used 57,600
default cgminer uses 115,200, enterpoints build used 57,600
I've got 3 out of 4 running on MPBM now so no need
Why isn't the 4th one working?
I'm using the "Normal mode" settings from the twin_test PDF.
I don't know why the 4th one isn't working. When I say the 4th one, I mean the 2nd one on my 2nd board. My 1st board works fine.
you could probably use enterpoints cgminer build and not have to switch the SW1 #1 DIP as i believe that switches between 115,200 and 57,600 baud rates.
default cgminer uses 115,200, enterpoints build used 57,600
default cgminer uses 115,200, enterpoints build used 57,600
I've got 3 out of 4 running on MPBM now so no need
you could probably use enterpoints cgminer build and not have to switch the SW1 #1 DIP as i believe that switches between 115,200 and 57,600 baud rates.
default cgminer uses 115,200, enterpoints build used 57,600
default cgminer uses 115,200, enterpoints build used 57,600
Jump to: