Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 44. (Read 286370 times)

I've built cgminer 2.6.1 for linux 32bit (works ok on my ubuntu 12.04 64bit) with OpenCL/ADL disabled and just icarus support enabled.

If you trust my build you can get it from:

http://p2pool.soon.it/cgminer/cgminer-2.6.1

Download it, issue a


to make it executable and it's ready to go.

spiccioli

Thanks, managed to get it working I beleive, assuming the update of a new bitstream goes okay, I'll send a little tip your way.

What you mean with USB noise issues? Never heard of that.

The baud rate depends on what controller version you use, with rev. 1.3 you need to use 115200 baud, with glasswalker2 rev. 1.0 you need to use 57600 baud.

eb

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

For giggles, I ended up flashing my USB controller again with 1.3.  I have the 190 OC bitstream on there already, after the controller reflash, I'm able to successfully hash using CGMiner and reporting around 10.2 U/M.  Thanks for the help and suggestions so far from everyone.

Update on latest bitstreams:
Total 40 FPGA's = 10 boards SN#400+. (my early board SN#0015 is not working at all)

Makomk's bitstreams:
11x 200Mh (still testing), 23x 190Mh, 1x 170Mh, 5x 160Mh. That means ~85% of all fpga's running @190Mh+ with <4% invalids (will update after a day or two)

Working bitstreams in percent:
200Mh oc = 27,5%
190Mh oc = 85%
180Mh oc = 85%
170Mh oc = 87,5%
160Mh = 100%
150Mh = 100%
140Mh = 100%


Update Glasswalker's bitstreams:
20x 175Mh

Working bitstreams in percent:
175Mh = 50% (runs only on 2 FPGA's per Board)
125Mh = 0% (not working at all)

eb

Going to give this a go, but with it getting late, I probably won't have any feedback till tomorrow.

Not having much luck doing it this way - Moving the file directly off the Virtualbox. I appreciate how much detail you went into explaining it though.

We can't 100% rule that out but it's very unlikely as the problem. You can always power it from a seperate power supply using the slow fan override to avoid the protection mechanism operating.

The nature of hashing with Icarus style bitstreams is inherently "noisy" and we did take special measures in the design to account for this e.g. using heavy weight power planes in the design. Obvious we probably use some more but it all costs somewhere down the line. There is always more that can be done for the future in the PCB design that will bring improvements but probably much more can actually be done in changing the hashing design and the way it operates.

We will work on understanding the particular problems and eventually work this into later products. We also know the design has it's good bits as well. The cooling has working welll as has the power supplies. It's actually hard to get the heatsinks more than a few degress above ambient. In our testing operating 1-2 FPGAs at 200MHz on our test boards has been amazingly stable given we don't actually meet timing at this speed. Once we have a reason bitstream available for most boards we can get back to the more interesting things we have planned for this design and start to show a little more of what we plan to do at a system level.

Thanks for the explanation.

So the question of the fan attached on fan pins near FPGA3 as a source of noise is ruled out, isn't it?

spiccioli.

Boards 0001 to 0050 we will either replace with later issue boards or offer you a credit against new purchases as compensation if you still have an issue in 4 weeks time when we might have some unallocated board stock available again.

We now know from the work we are doing that the outer copper layers on these boards is slightly thinner that the boards 0051 onwards have. We can now more or less bring these boards back up to the 0051 onwards level by simply adding a few simple capacitors. That can be done in a few minutes and we are doing further testing on these boards to find out more and make those mods on any available boards we have. It's entirely possible we may also come up with firmware solution to solve this as well.

Thanks guys I'll give it a go once I'm back In the house.
Went out with the misses since she could tell I was just getting frustrated.

It working straight from my linux box is ideal.

Lethos,

start your virtualbox instance and then scp xc3sprog to the linux pc.

Let's say that you have a user called "miner" on your linux box you issue this command from the virtualbox running image


example


mind the colon at the end of the command.

This will ask miner's password and copy xc3sprog to the home dir of user miner on the linux box.

Then, from the linux box you use the same commands as if you were inside the virtualbox image.

Mind you that if you have multiple boards attached to the linux box you need to:

• unplug one board
• move SW1 switch 3 to OFF (start of programming)
• plug it again, this makes the board the "active" board for xc3sprog (1)
• issue a ./xc3sprog -c cm1 -j to see that the board is visible
• issue the xc3sprog command for each FPGA
• unplug the board again
• move SW1 switch 3 to ON
• move SW1 switch 1 to OFF (resets board) then after a few seconds to ON again
• when the yellow leds are on, plug the board again

(1) I don't know how to address one board between a few using xc3sprog if not using this series of plugging/unplugging to make it the "active" board.

I've used this method several times and it works with my ubuntu server 12.04.

SW2 and SW5 have all switches ON, SW3 and SW4 are ON-OFF-ON-ON
SW6 switch 1 is OFF

Tell me if it works.

spiccioli.


EDIT: the xc3sprog has to be run as sudo otherwise it cannot access the board you're trying to flash

board #0005 still running stable with shortfin_icarus_cm1_test_160.bit (using controller 1.3) after running for about 19h45

 cgminer version 2.3.4 - Started: [2012-07-30 22:37:47]
--------------------------------------------------------------------------------
 (5s):598.2 (avg):733.2 Mh/s | Q:3695  A:10554  R:49  HW:0  E:286%  U:8.95/m
 TQ: 2  ST: 3  SS: 1  DW: 255  NB: 108  LW: 23701  GF: 0  RF: 0
--------------------------------------------------------------------------------
 CM 0:                | 460.7/367.6Mh/s | A:5266 R:24 HW:0 U:4.47/m
 CM 1:                | 383.8/365.5Mh/s | A:5288 R:25 HW:0 U:4.48/m
--------------------------------------------------------------------------------

pool account reports 550 Mhash/s

You can get the program here.

sudo svn co https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog/trunk xc3sprog

You will need Cmake, libftdi1, libftdipp1 from your distributions repository. Then  do a cmake . make, and make install and you should be golden. I was never able to get the pre-built binary version to work so this is how i did it.

I am trying to use makomk bitstream. I believe my boards were already updated to 1.3v. So how do I update to the latest bitstream without using virtualbox?

Lethos,

are you trying to flash the SPI firmaware (to update it to controller rev. 1.3) or a bitstream from makomk?

For the latter, you don't need windows at all, but for the former right now you can only do it in windows.

spiccioli

I would love to test the bitstream, but virtual box usb has issues, most the time it refuses any usb connected devices, even though they are installed and work fine in Windows.
To get around a few steps, the furthest along I've got it using wget all the files via my server, since I can't get my usb pen mounted either.

It kinda worked before, now the keeps complaining about "USB device is busy with a previous request".
Tried many of the usual stuff suggested on the virtual box support site, but it's short lived or doesn't work.

Their needs to be an easier way, maybe a native program for linux, rather than having to go via virtualbox.
Surely xc3sprog would work in a normal linux environment right? Don't mind sending a few bitcoins to someone who can help me out.

Seems a waste for me to be helping towards the bounty, then can't actually use it.

I don't know, because I didn't have time to set it up until now. (yes, the board just collected dust for some weeks...)

Currently I have "shortfin_icarus_cm1_test_150.bit" flashed + running and it looks good so far (U is 8.15). But I guess I'll have to wait a few more days to see if it's really stable. Also I didn't try the 160+ Mhz versions.

So at least makomk's bitstreams are working "somehow" on pre-s/n-50 boards, at least on mine.

Does twin_test.bit run stable on your board?