Thanks rjk and spicioli, helped me to find the problem with the xc3sprog host build.
Ok I am told we didn't do any patches for the xc3sprog so it is as the original.
Yet, you did
U. Bonnes added support for the cm1 cable to the SVN repository two weeks ago and swapped two digits in the product-id entry: 0x8530 instead of 0x8350
In the cablelist.txt file in the VirtualBox image you fixed that typo, but did not update in the repository.
Since I have no write access to the xc3sprog SVN repo and assume Mr. Bonnes is an Enterpoint fellow, you maybe want to forward him the required patch to fix the issue:
Index: cablelist.txt
===================================================================
--- cablelist.txt (revision 679)
+++ cablelist.txt (working copy)
@@ -9,7 +9,7 @@
ftdi ftdi 1500000 0x0403:0x6010:
ft232h ftdi 1500000 0x0403:0x6014:
ft4232h ftdi 1500000 0x0403:0x6011:
-cm1 ftdi 1500000 0x0403:0x8530:
+cm1 ftdi 1500000 0x0403:0x8350:
bbv2 ftdi 1500000 0x0403:0x6010::1:0x00:0x10:0x00:0x0
bbv2_2 ftdi 1500000 0x0403:0x6010::2
dlp2232h ftdi 1500000 0x0403:0x6010:DLP-2232H:1:0x00:0x10:0x00:0x0
To the Linux folks: forget the VirtualBox fuss and just compile the xc3sprog sources from SVN with the above patch and program your board natively.
Up/Down is not working yet. That will come after our first original bitstream. That will need another controller update.
Are the USB hubs you are using powered with a brick supply or bus powered? You might get this issue on un-powered hubs and it just one board is marginally more power hungary.
Ah, really? That might be the reason, since all tested hubs were passive. Isn't the FTDI powered by the main board power supply? If not, does this imply that powered USB hubs must be used if using more than 3 boards?
Do send this stuff to the emial support.bitcoin at enterpoint.co.uk. Response won't be terribly fast as we are balancing getting on with the new stuff with supporting the temporary things.
Will do. But will also post a copy in this thread, since evidently the community is of great help.
On a different point on CGminer we will probably put a second build for Windows up on the website shortly. It's specifically for the twin build. Basically the one that is currently up there is for the 50MHz build and we should have made that a little clearer. The twin build version is more or less the same as Icarus. I think there are a couple of minor switch settings changed but that's all.
As long as there are no functional differences to Icarus (i.e. if you could use baud-rate of 115.2k), I'd suggest to leave it as is and just take the Icarus cgminer. Right now I can use it as is with the one DIP switch correctly set and it does not make sense for your SW team to follow the Icarus development all the time when the only difference is the baud-rate.
When we bring in our own original build bitstream I expect to have quite a lot of changes including a new step of CGminer and new revision of the Controller. The up/down function may, or not, make the first of these versions but if it doesn't it should not be far behind. When we have that it will take a lot of the historical problems of large numbers of USB trying to run on one machine and will start to look much more like our planned long term structure of network nodes. That's a key in to what is coming in Cairnsmore2 where we will extend that idea somewhat more.
I understand that, alas that puts me personally in an odd situation: to have the boards running now I need to buy a dozen USB hubs - and dump them only two weeks later when the up/down functionality is supported
Anyhow, your boards are great - you folks know what you are doing and how to satisfy your customers.
Thanks, zefir
(fingers crossed!)
