ebereon
|
|
June 30, 2012, 02:01:20 AM |
|
well done ebereon, ill sort another donation when im at my wallet machine 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 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.
|
|
|
|
daemonic
Newbie
Offline
Activity: 49
Merit: 0
|
|
June 30, 2012, 02:03:17 AM |
|
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
|
|
|
|
ebereon
|
|
June 30, 2012, 02:07:59 AM |
|
Thanks guys for the donations! And happy flashing, don't forget the coffee!
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
June 30, 2012, 06:38:47 AM |
|
If you want to flash both with one command, just do: 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 Thanks! Great finding that -I thing, I'm gonna flash mine as well. spiccioli
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
June 30, 2012, 06:43:45 AM |
|
well done ebereon, ill sort another donation when im at my wallet machine 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 Makes one wonder why every other option has a space but this one spiccioli
|
|
|
|
yohan (OP)
|
|
June 30, 2012, 07:01:41 AM |
|
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
Activity: 1378
Merit: 1003
nec sine labore
|
|
June 30, 2012, 09:45:06 AM |
|
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. 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. spiccioli.
|
|
|
|
yohan (OP)
|
|
June 30, 2012, 09:52:16 AM |
|
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. 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. 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
Activity: 1378
Merit: 1003
nec sine labore
|
|
June 30, 2012, 10:08:41 AM |
|
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. 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. 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: 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. 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
Activity: 1378
Merit: 1003
nec sine labore
|
|
June 30, 2012, 10:53:08 AM |
|
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)
|
|
June 30, 2012, 01:07:53 PM Last edit: June 30, 2012, 04:11:59 PM by yohan |
|
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
|
|
June 30, 2012, 03:32:29 PM |
|
... 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 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
|
|
June 30, 2012, 04:17:16 PM |
|
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)
|
|
June 30, 2012, 05:14:32 PM |
|
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
|
|
June 30, 2012, 05:22:24 PM |
|
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 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
|
|
June 30, 2012, 05:32:46 PM |
|
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)
|
|
June 30, 2012, 06:01:49 PM |
|
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 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.
|
|
|
|
|
Doff
|
|
June 30, 2012, 06:38:36 PM |
|
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 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)
|
|
June 30, 2012, 07:00:41 PM |
|
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.
|
|
|
|
|