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

cgminer doesn't require opencl to compile, ./configure will work out that you don't have opencl and will not include GPU mining in the compile

Just a note about mpbm.

I'm using it on OS X (10.7 - Lion Server) with a BFL Single for a few days now (my Enterpoint order hasn't shipped yet) and quite like it.

Primary reason I'm not using cgminer is that I didn't want to bother installing the opencl libraries on that machine which cgminer requires to compile / run.

I had some trouble (cant remember what it was) with mpbm some weeks ago, so I'll prolly try it with cgminer because Im know the program.

nice it's working for you now! 

Please try it with mpbm, cgminer works too but sometimes it gets the error when started 0x... should be 0x....

The problem I had was the space between -p and the position number, I rammed one trough before I read you post so Im going for all four on the permanent flash now.

Glasswalker is right, you need to be carefull with the command line, it don't like spaces when no one is needed.

Isokivi,

I know you need to flash to the SPI, but first try the temporary mode. If this works, we can look to the SPI thing.

Please use: xc3sprog -c cm1 -p0 BitstreamFileHere.bit
Use it for p0 p1 p2 and p3. Then test.

Just a shot in the dark here, as I don't commonly use the commandline tools, but I don't believe there should be a space between the -p and the 0 (should be -p0) and the -lxc6lx150.bit can be dropped entirely. Just a space following -p0 and then the single .bit file you intend to load.

EDIT:

To be more clear:

It is on, constantly. Could you take a look at the command im pounding in, I guess the problem lies there.

For those of you looking for documentation, Yohan posted the dipswitch settings for the new controller. So the vague steps look like this:

- Use Enterpoint instructions for controller update, update to "Glasswalker" controller from them
- Use new dipswitch settings posted by Yohan to put board into update mode (selecting internal jtag)
- Power cycle the board with these new dipswitch settings (and disconnect USB)
- Connect USB
- Use enterpoint commandlines to flash the 4x matrix chips (from original document) using the .bit file I posted (in the zip).
- Be sure to flash the SPI.
- Return dipswitches to enable clock (not programming mode) and set the clock to 25Mhz (this is important).
- Power cycle the board (and disconnect USB)
- Reconnect USB
- Connect to the boards at 57600baud on all 4 serial ports detected by windows
- Mine

This is vague I know, as I said I have not tested this new controller yet, and my board is at home. Later tonight I will test specific instructions, verify they work, and then post the detailed instructions. Hopefully someone else with higher technical expertise can use these steps and get it working and post a more detailed howto.

I usually use a jtag cable to flash it, as I find it FAR simpler and faster than the USB method. But I'll verify the USB method when I get home.

Hope that helps.

Isokivi,

is the LED on the controller flashing/blinking? Or is it off or on permanently? With my dip settings?

Thank you

I am however attempting to do a permanent flash because my physical setup makes cycling power on individual boards nearly impossible and becase of this yor guide results in the same 2bitfile propably not loaded" Ive been seeing so far.
[edit]
swapping switch 6 off like the controller 1.3 picture says is not the solution.

I'll gladly start testing this if you can give me the dipswich settings and make sure my command: is correct

HowTo for Makomk bitstream 140:
Controller rev. 1.3 is tested be me. Please update to it and don't forget a powerdown after flashing it.

For temporary mode:
SW1 #3 off  others on
SW6 #1 off  others on

SW2 and SW5 all on
SW3 and SW4 #2 off   others on

When you have these settings, the LED from the controller is no more flashing, it's on or off completely. EDIT: if it is still flashing, something is wrong and you will get errors.

Then flash it with this command:
xc3sprog -c cm1 -p0 BitstreamFileHere.bit
xc3sprog -c cm1 -p1 BitstreamFileHere.bit
xc3sprog -c cm1 -p2 BitstreamFileHere.bit
xc3sprog -c cm1 -p3 BitstreamFileHere.bit

This is all, now switch SW1 #3 on again.

I hope it helps a bit.
eb

i have the same problem, any advice?

(plain simple on a big wood table here)

Ok, I've changed my mind... This is a little against my better judgement. I'm releasing the bitstream that accompanies the new glasswalker controller that enterpoint released. Keep in mind I have not tested this myself yet. I won't be able to do that until later tonight when I get home from work. I will confirm once I've done that.

But if any of you who are a bit more technical want to dive in and flash this along with the new controller, and let me know how it works, I'd appreciate it. As Enterpoint said, it should work in 3 of the 4 positions. the 4th may or may not work, and may be flaky.

It should mine stable at 175Mhash/s on the chips it does work on (I've tested it on one position for over 24h at a stable 175Mhash/s on my board).

In the meantime Enterpoint is still poking at the problem from the controller side, and I'm re-writing the UART core entirely from scratch which should fully solve the problem, so between the two we should have a stable bitstream very soon. Then we can just worry about driving the hashrate up to the max attainable. Then following that I'll move my focus back to my 100% "from scratch" bitstream which should offer much improved performance.

In addition, one last tidbit. I've begun work on a "from scratch" opensource version of the controller bitstream as well, with some advanced features. That should both be useful for this bitstream, and my future, but also having the opensource controller out there should help any other developers with this in the future. That one is a ways off though, it's low priority and I'm only working on it in my down cycles between the other bitstream work.

Oh and I missed the final bit, I've forked off MPBM as I prefer it to cgminer. I have added cairnsmore support to it in the form of a custom module. It's still reporting hashrate wrong, but I hope to fix that soon. This version of MPBM was tested with this released bitstream.

Here is the link to the bitstream: http://www.btcsyn.com/bitstreams/glasswalker_untested.zip
Here is the link to MPBM github: https://github.com/pmumby/Modular-Python-Bitcoin-Miner
(you want the "testing" branch)

Let me know how these work for you.

The programming failed, in controller rev 1.3 swich 6 needs to be in a different position to allow the spi flash, trying it now.
[edit] failed again.
[edit2] it's just me failing prolly, I swear the god I'll celebrate the day when I never ever have to touch those annoying dipswiches ever again. (have I mentioned I've positioned my boards and psu veri high and that I get to climb on a kitchen-stool every time I need to do anything on them?)
[edit3] no, cant program with these settings, ebereon please jump in and tell me how you did it!
[edit4] hmm, perhaps my problem lies here (because i dont fully understand why the command should have 2 bitstreams:

I think you should be able to use those DIP settings for both programming and running the mining FPGAs.

Thank you

Does this refer to porogramming or running settings: "  Set SW1 and SW6 according to the "Twin Build (Icarus)" diagram on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html and SW2/3/4/5 according to the "Initial Shipping Build (low performance) diagram. Load firmware, start your mining software and cross your fingers." ?

Quick update, I'll push up the bitstream file later tonight. I have yet to test my bitstream with this new controller from Enterpoint (before now I was only able to get it running stable on one position at 175Mhz). So I will test it as soon as I get home tonight (probably not until about 8pm EST) and as long as I can get 1+hr of 175Mhz on 3 of the positions I'll push the .bit file up.

As I posted in the bounty thread, I'm also working on further improvements on the bitstream (I'm re-writing the UART core from scratch to toss out the "flaky" one that ngzhang used in the icarus bitstream).

Anyway, so provided my test goes well, I'll have this bitstream out later tonight. Sorry for the delay folks.

After this release I'll continue on my next iteration of improvements, in this version it will be a 150Mhz build which should have many improvements (which could be installed in the poorly performing slot for now) which I will then push up to 200Mhz through further timing optimization.

I'm also working to remove the need to use any third party tools besides Xilinx ISE to compile the bitstream, so in my final release, it should be fully buildable with only the base Xilinx ISE.

Thanks for your patience!