Bitcoin Forum
March 19, 2024, 06:39:27 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 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 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 286362 times)
ebereon
Sr. Member
****
Offline Offline

Activity: 397
Merit: 500


View Profile
June 30, 2012, 02:01:20 AM
 #1041

well done ebereon, ill sort another donation when im at my wallet machine Smiley

did you stick to the twin_test.bit or go with the 190M_V3.bit bitstream for the SPI

and proof for the -I<bitstream.bit> is in the man page (http://xc3sprog.sourceforge.net/manpage.php) d'oh Smiley

I tested the 190M_V3.bit but it will not work, after power on the fpga with this bitstream have all led's on. Don't know why it is working in temp mode but not in SPI mode.

I stick to the twin_test.bit. Fingers crossed that it will work longer then my 14 hours max.
1710830367
Hero Member
*
Offline Offline

Posts: 1710830367

View Profile Personal Message (Offline)

Ignore
1710830367
Reply with quote  #2

1710830367
Report to moderator
1710830367
Hero Member
*
Offline Offline

Posts: 1710830367

View Profile Personal Message (Offline)

Ignore
1710830367
Reply with quote  #2

1710830367
Report to moderator
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
daemonic
Newbie
*
Offline Offline

Activity: 49
Merit: 0


View Profile
June 30, 2012, 02:03:17 AM
 #1042

I tested the 190M_V3.bit but it will not work, after power on the fpga with this bitstream have all led's on. Don't know why it is working in temp mode but not in SPI mode.

I stick to the twin_test.bit. Fingers crossed that it will work longer then my 14 hours max.
I just the found the same also, time to put twin_test.bit back on and leave it overnight now (3am) to see how it does Cheesy
ebereon
Sr. Member
****
Offline Offline

Activity: 397
Merit: 500


View Profile
June 30, 2012, 02:07:59 AM
 #1043

Thanks guys for the donations! And happy flashing, don't forget the coffee! Wink
spiccioli
Legendary
*
Offline Offline

Activity: 1378
Merit: 1003

nec sine labore


View Profile
June 30, 2012, 06:38:47 AM
 #1044

If you want to flash both with one command, just do:
Code:
xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit && xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit

This will flash the first (0) and if it was ok, then the last one (3). And that takes ~16 minutes to finnish, just take a cup of coffee  Wink

Thanks! Great finding that -I thing, I'm gonna flash mine as well.

spiccioli
spiccioli
Legendary
*
Offline Offline

Activity: 1378
Merit: 1003

nec sine labore


View Profile
June 30, 2012, 06:43:45 AM
 #1045

well done ebereon, ill sort another donation when im at my wallet machine Smiley

did you stick to the twin_test.bit or go with the 190M_V3.bit bitstream for the SPI

and proof for the -I<bitstream.bit> is in the man page (http://xc3sprog.sourceforge.net/manpage.php) d'oh Smiley

Makes one wonder why every other option has a space but this one Sad

spiccioli
yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 07:01:41 AM
 #1046

Looks like you guys have found at least one silly thing for me too look for today. When I get a chance I will ask about the -I thing and if we can in any way make it more consistant with the rest of the switches. If nothing else we can at least highlight that fact in the instructions.
spiccioli
Legendary
*
Offline Offline

Activity: 1378
Merit: 1003

nec sine labore


View Profile
June 30, 2012, 09:45:06 AM
 #1047

So I updated the controller FPGA on board serial n. 8 and it went withouth problems.

Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA.

Code:
user@t5570:~$ time sudo ./xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0x390dc1e841c73bf1
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!

real 2m50.569s
user 0m4.340s
sys 0m10.517s

Less than 3 minutes per FPGA.

Smiley

spiccioli.
yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 09:52:16 AM
 #1048

So I updated the controller FPGA on board serial n. 8 and it went withouth problems.

Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA.

Code:
user@t5570:~$ time sudo ./xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0x390dc1e841c73bf1
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!

real 2m50.569s
user 0m4.340s
sys 0m10.517s

Less than 3 minutes per FPGA.

Smiley

spiccioli.



Doing the direct programming of the FPGA is fast but won't stay when you power cycle. Loading ointo the SPI Flash takes longer but is there every time you power up the board.
spiccioli
Legendary
*
Offline Offline

Activity: 1378
Merit: 1003

nec sine labore


View Profile
June 30, 2012, 10:08:41 AM
 #1049

So I updated the controller FPGA on board serial n. 8 and it went withouth problems.

Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA.

Code:
user@t5570:~$ time sudo ./xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0x390dc1e841c73bf1
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!

real 2m50.569s
user 0m4.340s
sys 0m10.517s

Less than 3 minutes per FPGA.

Smiley

spiccioli.



Doing the direct programming of the FPGA is fast but won't stay when you power cycle. Loading ointo the SPI Flash takes longer but is there every time you power up the board.

Yohan,

I'm loading it into the SPI, I'm using -I see my command above, but I'm not doing it from VirtualBox, but from a linux pc using your xc3sprog.

I have a different problem, though, when I try to flash board serial nr. 136, it throws this error:

Code:
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0xb9c83ffc56e627ff
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
readusb waiting too long for 9 bytes, only 0 read
error Resource temporarily unavailable
terminate called after throwing an instance of 'io_exception'

for both FPGA0/3.

I can program them without problems if I don't try to flash the SPI memory.

Code:
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0  twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0xb9c83ffc56e627ff

Are there differences from board 136 on? I had no problems with board 8 and 104.

spiccioli
spiccioli
Legendary
*
Offline Offline

Activity: 1378
Merit: 1003

nec sine labore


View Profile
June 30, 2012, 10:53:08 AM
 #1050


Code:
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0xb9c83ffc56e627ff
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
readusb waiting too long for 9 bytes, only 0 read
error Resource temporarily unavailable
terminate called after throwing an instance of 'io_exception'


Hi again it was the USB hub port and/or usb cable, moving the card to a different cable/hub port fixed the problem and I was able to program this cards as well as the other ones.

spiccioli.

yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 01:07:53 PM
Last edit: June 30, 2012, 04:11:59 PM by yohan
 #1051

One little tip for people running Linux and programming is that we have found the xc3sprog is more stable running as a VM under the main Linux. There also seems to be a machine speed relationship as well. This all suggests that there might be software timing loops in xc3sprog and that is part of the problems some of you have.

On the Windows side I am about alter/create a set of instructions specifically for loading the SPI Flash with the twin design. These should be available later today. It's not really any new info but hopefuly it's in a better format to follow and maybe less chance to make a mistake.
Doff
Sr. Member
****
Offline Offline

Activity: 327
Merit: 250


View Profile
June 30, 2012, 03:32:29 PM
 #1052

... I'm guessing this will load the SPI with the twin_flash.bit? So it won't need to be reprogrammed everytime I power off.

Yep! And it's working  Cheesy

ebereon if you get that error where it cuts out after about 14 hours you might look at BFGminer, its a fork of cgminer and in his patch notes a while back it mentioned fixing that error in his build of cgminer. So it may have nothing to do with the cairnsmore programing.
Doff
Sr. Member
****
Offline Offline

Activity: 327
Merit: 250


View Profile
June 30, 2012, 04:17:16 PM
 #1053

Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.

Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.

The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 05:14:32 PM
 #1054

Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.

Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.

The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.

Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.
Doff
Sr. Member
****
Offline Offline

Activity: 327
Merit: 250


View Profile
June 30, 2012, 05:22:24 PM
 #1055

Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.

Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.

The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.

Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.

Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it Smiley

I'm sure its just software as well, but since I don't have the full picture I just don't know what else try.

Do I need to resend any of my info to you for that, or are you all set?

Thank you for the awesome customer service Yohan.
Doff
Sr. Member
****
Offline Offline

Activity: 327
Merit: 250


View Profile
June 30, 2012, 05:32:46 PM
 #1056

One thing I have noticed Yohan when I program the Twin test my SW 3-4 seem to have the wrong program on them. The reason I say this is because one stays on with a blue/red/amber light on the whole time and the other just has amber/red, no clue what they should be. If I could somehow get the right program on those switches it may save you the trouble of shipping a new unit.
yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 06:01:49 PM
 #1057

Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.

Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.

The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.

Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.

Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it Smiley

I'm sure its just software as well, but since I don't have the full picture I just don't know what else try.

Do I need to resend any of my info to you for that, or are you all set?

Thank you for the awesome customer service Yohan.


You are nearly in Canada if I pulled up the right record. If I am wrong let me know. Hopefully we can get it there for Tuesday.

But let's work out what the problem is. No point being frustrated if we can do something about it. It might be that you have a board that has a real fault. It is very unusual for one of our standard boards to fail in the field having been though one of our tests. I think it's about 2-3 boards in the last 9 years but it's still always a possibility.

We are still at the stage of being bit of rough and ready in terms of documentation, software and bitstreams and we will do our best to get you all past that bit as fast as we can. Hopefully this coming week will see the next major step forward and we will meet at least some of the expectations out there.

I am nearly finshed the document that will hopefully make this simplier for Windows users and that will have dip switch settings. 90% of that will still be useful to you as a Linux user so you could try and follow that. It some be available tonight or early tomorrow. I will have some more dip switch setting pictures that I am doing for that now and I will try and post those here shortly as a short term help.
yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 06:21:43 PM
 #1058

Ok before programming the twin bitstream set dip switches as this picture. I would recomend programming the SPI flash as you can do power cycles etc without pain. It's just slow to do.





Once it is verified ok set dip switches like this


Doff
Sr. Member
****
Offline Offline

Activity: 327
Merit: 250


View Profile
June 30, 2012, 06:38:36 PM
 #1059

Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.

Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.

The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.

Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.

Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it Smiley

I'm sure its just software as well, but since I don't have the full picture I just don't know what else try.

Do I need to resend any of my info to you for that, or are you all set?

Thank you for the awesome customer service Yohan.


You are nearly in Canada if I pulled up the right record. If I am wrong let me know. Hopefully we can get it there for Tuesday.

But let's work out what the problem is. No point being frustrated if we can do something about it. It might be that you have a board that has a real fault. It is very unusual for one of our standard boards to fail in the field having been though one of our tests. I think it's about 2-3 boards in the last 9 years but it's still always a possibility.

We are still at the stage of being bit of rough and ready in terms of documentation, software and bitstreams and we will do our best to get you all past that bit as fast as we can. Hopefully this coming week will see the next major step forward and we will meet at least some of the expectations out there.

I am nearly finshed the document that will hopefully make this simplier for Windows users and that will have dip switch settings. 90% of that will still be useful to you as a Linux user so you could try and follow that. It some be available tonight or early tomorrow. I will have some more dip switch setting pictures that I am doing for that now and I will try and post those here shortly as a short term help.

Yeah, I'm not to far from the Canadian border, so that sounds correct.

Ive tried programing with the exact settings you have listed as well with no Luck maybe I did get the 1 off board. Ive spent a few hours on it this morning and decided to put it aside, I may give it a go later but I don't think its going to change much.

Thank you again for the prompt response.

Doff
yohan (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 251



View Profile
June 30, 2012, 07:00:41 PM
 #1060

I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html .

I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
Pages: « 1 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 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 ... 129 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!