Cairnsmore1 - Quad XC6SLX150 Board

[Gomeler]

Noob question here but could I in theory develop a bitstream on the side and use the programming chip on the board to send it to the various FPGAs? I ask as I love tinkering with things and I think I'd have fun getting one of these to hash away at something pathetic like 1 MH/s 

[1714024913]

1714024913

[1714024913]

1714024913

[Doff]

Ok after further fiddling it looks as if the programming has not been working and that Ive been resetting it each time back to the shipping.test. As far as feedback goes, if you could go in to more detail on what as successful program looks like and what the lights should be doing when it was successful.

[daemonic]

The way i got mine going is as follows;

Setup dips as follows;

This is as per progamming operation from virtual box, but ignoring the SW6 3 off, once i had updated the firmware to rev 1.1 SW1 3 on works!)

Code:

SW6 all on
SW1 all on / SW6 12 off, 3 on, 4 off (see above!)
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on

I program each twin_test.bit to -P0 and -P3

PGA's 0 and 3 will have amber led on, 1 and 2 will have amber and red

Then disconnect the Cairsmore1 device from the Virtual Box instance (click "Devices" menu, then "USB Devices" then untick the "FTDI Cairnsmore1")

I then reset the dips as follows (whilst the device is still on) (if you are using the enterpoint provided cgminer, leave SW6 1 on, or if you set mpbm to 57600 leave it on also, else switch SW6 1 off to make the baud rate 115200 to use the standard cgminer in icarus mode or 115200 in mpbm, the red led next to the array will flash faster when SW6 1 is on)

Code:

SW6 1 off, 234 on (see above!)
SW1 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on

you should then be able to mine using \\.\COM22 and \\.\COM23

[rampone]

Okay, tried with the programming option, a green light show up, when finished programming, blue lights up (yellow stays lit). Now it also seems to be programmable on the first run.

After switching back to"run mode", everything lights as before (0,1,2,3 yellow, 1,2 red) but it wont hash. Probably the clock icarus stuff yohan was talking about.

(btw, sw1 are the dips near the usb, sw6 are the one to the green connector at my board? so programming for me is all on, ans sw1 3 off?, running all on and sw6 1 off? Did the labeling change on the board? I doubt it

[daemonic]

Ive just checked with magifying glass and you are right, so my dip settings in my posts should have SW1 and SW6 switched as i have been posting them the wrong way around.

(I have edited my posts to correct my mistake now, i believe ebereon has thought they were the the same way around as i did based on his posts, so perhaps we all confused each other here is a magnified image for clarity - http://s15.postimage.org/li1hpdz6f/20120622_013815_1.jpg

[yohan]

It is all too easy to get dip switches wrong. Our slightly longer term aim will be to eliminate most, if not all, dip switch settings and use something a bit more intelligent but more on that when we have it.

[daemonic]

rampone,
ill run through my process to see if you are doing anything different;

Okay, tried with the programming option, a green light show up, when finished programming, blue lights up (yellow stays lit). Now it also seems to be programmable on the first run.

Switch on the unit with SW1 3 off to put in programming mode
Whilst in programming mode, i have yellow/green on all 4 pga (if you switch the SW1 3 off with power applied, the green led doesnt light, but programming still works)
Whilst writing the twin_test programming to -P0 or -P3, the leds next to it change to yellow/blue/red
When programming is complete, the leds change to yellow/blue and the leds on its associated partner (-P1 if programming to -P0 or -P2 if programming to -P3) change to yellow/green/red

After switching back to"run mode", everything lights as before (0,1,2,3 yellow, 1,2 red) but it wont hash. Probably the clock icarus stuff yohan was talking about.

I then switch SW1 3 on without removing power inbetween
I then get yellow leds on all pga and red on the -P1/-P2 pgas

So this is the same as you, up to this point

i then disconnect the FTDI Cairnsmore1 from the virtualbox to give it back to windows.
i then switch SW6 1 off to make it 115,200 baud for use with cgminer or mpbm, (if i dont switch it, then cgimner reports the got 00000000 expecting 000187a2 error)

You should then be hashing

[yohan]

We are starting a Cairnsmore1 specific support email address where we can route problems to the best engineer to be able to sort them out. We will also start a FAQ page in the next few days and try and cover common problems there so hopefully whatever you encounter that there is an answer already waiting for most of you. The support email is bitcoin.support AT enterpoint.co.uk.

Yohan

[norulezapply]

We are starting a Cairnsmore1 specific support email address where we can route problems to the best engineer to be able to sort them out. We will also start a FAQ page in the next few days and try and cover common problems there so hopefully whatever you encounter that there is an answer already waiting for most of you. The support email is bitcoin.support AT enterpoint.co.uk.

Yohan

This is a great idea, thank you Yohan

Any news on why the SPI flash for the FPGAs isn't working yet when I'm trying to flash the twin_test bitstream permanantly?

[rampone]

You should then be hashing

Yeah, I should be hashing Did exactly what you said, and different other things on like 10 or 15 runs altogether. Like before, I guess I will have to wait.

[daemonic]

You should then be hashing

Yeah, I should be hashing Did exactly what you said, and different other things on like 10 or 15 runs altogether. Like before, I guess I will have to wait.

Sorry fella, thats about all the help i can give at the moment, was worth a try i guess

[Doff]

Ramp mine doesn't  hash either if it makes you feel any better, I had it going at about 25-50 for a few minutes, then tried to program it one more time and now it just connects and never finds a share.

[ebereon]

same here, after programm the controller and programm twin_test it was hashing for about 4 hours at 280Mh/s. After that it was going down to 40Mh/s and i tried to reprogramm it. But i don't got it hashing since that time.

I tried everything, but no luck anymore. If i start EP-cgminer SW6 all on it finds the units and show 380Mh/s but no share is processed. If i start cgminer 2.4.3 SW6 1 off, it only finds 1 unit and no hash.
With mpbm, the unit is no more found, as mpbm sends a test hash to the unit, but that will never be prozessed so mpbm don't find/connect the unit  

It looks like we have to wait some more time.  

[yohan]

Can anyone that has a problem email the new support email with the following:

Board serial number

What revision you think the controller is in. If you didn't touch it just say that.

A description of the problem you have.

What OS your host is running.

What your host is, if you know processor etc. that is all useful to know.

We will try and understand or even try and replicate the problems so that they can debugged. We probably won't do much on that until early next week so please be patient. The better bitstream is our priority for the next few days and as a lot of this stuff will change , hopefully for the better, once that is in place.
We don't want to put a lot of time on the "get going" unless that is strictly necessary as it will delay the better stuff. It would be far better for us to move the whole of the software and firmware side forward so that's the effort for the next few days.

I would also like to know who has a unit working ok is with the currently limited bitstreams. This might get us some insight to where problems actually are as much as the problem unit data. I suspect we don't have a major issue and it's all about recognising any weaknesses in combinations of different things and make even as simple as better docs.

[Doff]

Email sent.

Thanks!

Doff

[Gomeler]

Second board arrived along with the stacking kit. Looking forward to setting up my little tower of power.

[ebereon]

I have found MY problem

I don't know if it fixes your's also.

FIRST: Turn off the unit! Set the dip switches to the shipping configuration!
If you turn on the unit with other dip settings, the unit will not work! It will not work, no matter what you do.
Shipping configuration 50MHz:
SW1/6 all on
SW2 all on
SW3 134 on, 2 off
SW4 134 on, 2 off
SW5 all on

Keep in mind, every time you need to turn off your unit, you need to redo the dip switches to the shipping config BEFOR you turn on the unit!

1. Turn on the unit and wait until all led's turn orange. Then plug in the USB.
2. Then start up the VM (the VM automaticly takes the unit, that's really anoying). If it does not, connect it to the VM.
3. Now SW1 3 off! SW3/4 12 off, 34 on!
4. Then programm it, i think everyone knows how to do that with all that testing  
5. No change to the switches and disconnect it from the VM.
6. Turn off the VM now. Not the unit!    ...Please do that! The bump VM retakes the unit sometimes.
7. SW1 3 on.
8. SW6 1 off.
9. Start cgminer 2.4.3 with the COM-Ports your unit works.
10. cgminer show you some Mh/s, but U=0.0

Now you are at the point your were often the last day's. The unit will not hash...

But, now i find out there is a problem with the SW6 1. Donno if that is software or hardware related.

11. Just switch the SW6 1 on, and again off.
12. Wait some seconds/minutes.
13. One fpga(0) should now do something, if not repeat point 11. Take a look on the LED, the orange should go off. If it keeps getting on after a second, repeat point 11.
14. Now one fpga is working, repeat point 11. until you see the orange led from the second fpga(3) turn off.
15. Now it should work with both fpga's, but the second one is instable and don't provide hashes like the first fpga.

Please try that, it works for me now on every attempt. I hope it works for someone else too  

@yohan: could that be the problem with SW6 1? Is that the frequency or baud rate?

It cost me some hours to figure it out, if it works for you also, i would be happy if you have some mBTC's 0.0xx...   -> 1KWGtSxo5b52Adk3Pvw14E3o9kp96JZJm2

Greets,
eb

[spiccioli]

Hi all,

I've made some progress with my ubuntu server running on the HP thin client.

First I've installed ia32-libs and libftdi-dev:i386 so now I can run xc3sprog directly from it instead of using the virtualbox image I have on a Vista laptop.

Programming FPGA0/3 is still a pain, it took nearly half an hour for FPGA3 to accept twin_test.bit.

I've not re-programmed the FPGAs controller because it seems that it gives more hassles than good.

Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.

Ebereon, thanks for your help and the cairnsmore miner for MPBM, I've changed the icarus one following a previous message of yours, though, since the cairnsmore one gives an error when I start Mpbm that some methods accepts 4 parameters but it has been called with 5.

If you need I can dig out the correct error message, anyway I've sent you a little tip since you saved me from upgrading the FPGAs controller

spiccioli.

[yohan]

State of the Nation Time (What again!!!)

It's 8 weeks, 1 day and about 6hrs since I announced the Cairnsmore1 concept and the Enterpoint team started work on it so please do remember that in reading this. I don't believe there is any other team in the world capable of achieving what we have already done in that timescale never mind what we are continuing to deliver. It wasn't easy do this and I am glad many of you have recognised that and there should be a big handclap for team who have worked hard and still are to try and achieve this.

Doff we do have your email. Not seen any others yet though. If there are any problems please do email as requested. That could help us close down issues more quickly. I don't think we have anything that is a major problem we just need to make better documentation and support materials available. Unlikely to be Monday but hopefully Tuesday/Wednesday we will try and sort our way through at least some of these issues.

Shipping - Production took a big step forward and daily output doubled this week. There are nearly 200 units now in the field today and we are pulling in as much feedback from them as people will give us on these units. Generally it's all good but of course we need to advance the state of the bitstream and more on that in a minute. Going back to orders this week has seen us catch up and everyone that was indicated as a June delivery will either have already had a request for payment or will get one today. We do have a few days possibly in the first week of July where production may stop whilst we await our next delivery of Spartan-6 parts but that might pull forward and then that doesn't happen. Either way it won't have too much of an effect on July ship. At current daily delivery rates our line is capable of delivering 2.5X what we have promised so a a few days downtime we can live with.

Hardware - Thanks to all you that reported that the cooling system was working exceptionally well albeit maybe only working on half the power at the moment. That's very key to what we want finally achieve on this product and a lot of time did go into what might seem a very simple thing. Some people that had planned extreme cooling methods have indicated that they are going to drop these and stay with the standard setup such is the performance of it. Other than that I think we have a great platform to hash on.

Software - We will continue to try and improve this side but won't be our priority for a few days, or a week or whatever, that it takes to get a better performance bitstream.

Bitstream - We believe that 3rd party developers are now close to releasing a solution for Cairnsmore1. Our own bitstream solution we think has the potential to very good and might even be able to compete with *** claims once there some real numbers, and experience is available, for their unit. I know that is a matter of faith for all of you but do remember there is more FPGA knowledge and experience concentrated here in one place and one office than you will probably find vendor A or X's offices and remember that we specialise in doing the near impossible and have done so for very many years.

Our competitors *** have dropped what might be nuclear bomb into Bitcoin and it might well destroy Bitcoin. We will see if it actually happens. It still doesn't financially stack up to me or any way make sense what they are doing other than to destroy Bitcoin. However in Cairnsmore1 we might well have a second strike available to let loose and we won't unless we have to. What's for certain is that GPU miners are going to find it hard to justify switching on their rig if it all goes the way I think it will. I was hoping that this could be a controlled process and not a step change and everyone would win out of that but *** have more or less ensured that people lose money especially if you are a GPU miner and probably even if you are one of their own customers.

Anyway enough of the gloomy bit. We have lost a tiny percentage (0.4%) of orders due to ***'s claims and I believe we gained more orders than we lost and thank you to all that still believe and have faith in the Enterpoint way (I'll get my white collar out for next time and do this properly). We still think Cairnsmore1 is going to be an excellent product for all of our customers and that you will all be happy with your purchases from Enterpoint and that you will all have a sensible return on your investment. We will continue to strive to make that a good experience and will continue in our professional business manner in our engagement with you all. What's for certain if there is a Bitcoin market for what we do we will still be there with competing products.

Yohan

[ebereon]

I've not re-programmed the FPGAs controller because it seems that it gives more hassles than good.

Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.

I think both controller firmwares have there own problems. With the new one, the programming (still only temporary mode) works fine but i have to start cgminer and do all the things I have described until it's hashing and then I can stop cgminer to use mpbm.

Ebereon, thanks for your help and the cairnsmore miner for MPBM, I've changed the icarus one following a previous message of yours, though, since the cairnsmore one gives an error when I start Mpbm that some methods accepts 4 parameters but it has been called with 5.

If you need I can dig out the correct error message, anyway I've sent you a little tip since you saved me from upgrading the FPGAs controller

spiccioli.

I use the actual git, not the 0.1.0beta package. But there is also a problem, you have to change some things.
I will upload my version of mpbm here: http://www.wuala.com/ebereon/Shared/bitcoin/mpbm_changed/.

And thanks for the little tip!  

eb