Cairnsmore1 - Quad XC6SLX150 Board

[atsoat]

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

Sorry, no exciting method.

For the controller I use Xilinx iMPACT (exactly as Glasswalker decribed).

For the FPGAs I tried to use Xilinx iMPACT, but unfortunately the free version does not allow me to flash the PROM associated with the LX150 (as that FPGA requires the pay version of the software). Hence, I used xc3sprog.

I've done both my boards now (both pre-50) with no issues. After doing the controller, I unplug USB and power, set switch 3 OFF, all others ON. Attach power, wait, then attach USB.  I then run xc3sprog with the -j option to verify I can see the JTAG chain. I then flash 3,2,1,0 in that order using the standard command for each.

I'm running xc3sprog on the Enterpoint supplied Cairnsmore VM under VMware player on Windows 7. But, I have also previously flashed the FPGAs on a linux box directly without issue. The only time I had issues with the flashing was when running the very first revision of the controller I think (i.e. the one it shipped with).

[1714197783]

1714197783

[1714197783]

1714197783

[1714197783]

1714197783

[spiccioli]

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

Sorry, no exciting method.

For the controller I use Xilinx iMPACT (exactly as Glasswalker decribed).

atsoat,

do you know if you can you flash the controller FPGA using SPIprog.exe from windows like we did with enterpoint's controllers?

spiccioli.

[kano]

--icarus-options :2:1

Oh awesome, will this convince cgminer to adjust the hashrate estimations for single-chip setup?

Yeah I added --icarus-options a while ago - it was in cgminer 2.6.2 released 2 weeks ago
and of course in the current 2.6.5

Also Kano, come see me on IRC (#cm1 on freenode) or PM me. We're working on an addon to the icarus protocol to the hashvoodoo bitstream as a temporary measure until we can do the full protocol overhaul. It is technically in place in the current bitstream but it's broke, so it is basically un-used (I'll be fixing it in the next couple days). This addon leaves it backwards compatible with icarus, but with 2 major differences:

1 - It can now support specially constructed icarus style packets which act as "control" packets, to send other commands to the FPGA (right now the implemented one is "Set Clock Multiplier" for a given chip, allowing dynamic clock tuning)

2 - It is potentially vulnerable to malicious work sources. (if a pool operator knows the "special" packet format, they could send work down so a miner using the conventional icarus protocol and unaware of our additions would simply pass that work along to the fpga. This would allow the pool to directly control the clock of your FPGAs... We do have min/max in place to keep from physical damage to the chips, but it could still serve as a DOS (set clock to minimum multiplier effectively killing mining output, or setting it to max, potentially overheating it over time).

So this will require miners to add in special support for the newer hashvoodoo bitstreams on CM1 (or any other board it gets ported to) which will catch any packets which meet our "command packet" protocol coming from the pool and drop them (they should never occur in real mining, so it would be obviously either severely corrupted, or malicious).

And hopefully add support to actually use the clock tuning from the mining software.

Anyway, come see me, and I can help give you the details on this so you can start working it into cgminer.

I'm likely at LEAST weeks, if not a month or more away from the "final" protocol change, which will be a completely new protocol, so in the meantime this is a nice stop-gap measure that provides added functionality with minimal work, and provides backwards compatibility. And buys enough time to really think through the new protocol and make sure we "do it right" from the beginning.

Thanks!

I'd hope the new protocol would be commands and data with replies stating it received them.
Oddly enough, that is similar to a BFL - but they messed up that also ...
But anyway - that's just my suggestion

If you've hacked the data sent at the moment, it would logically be put in the middle where the values are currently forced to be zeros and always will be zeros with the current code - then there would be no issue with the data sent from the pool - or some weird pool wanting to take over your fpga by putting numbers in there - since they can't

I don't have a CM1 (nor do I expect to ever have one)
All the code changes I have done so far work with Icarus and I can test them on Icarus (since ngzhang gave me an Icarus back in February)
I'm not a fan of blind coding sorry.
With the --icarus-options I did guess a bit but I could test it on my Icarus board anyway and see the expected bad results of using the wrong values

[Lethos]

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

Sorry, no exciting method.

For the controller I use Xilinx iMPACT (exactly as Glasswalker decribed).

atsoat,

do you know if you can you flash the controller FPGA using SPIprog.exe from windows like we did with enterpoint's controllers?

spiccioli.

I did use SPIprog, that was the easy part.

[Lethos]

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

Sorry, no exciting method.

I've done both my boards now (both pre-50) with no issues. After doing the controller, I unplug USB and power, set switch 3 OFF, all others ON. Attach power, wait, then attach USB.  I then run xc3sprog with the -j option to verify I can see the JTAG chain. I then flash 3,2,1,0 in that order using the standard command for each.

Sounds like you did it exactly how I tried to at one point, but it didn't work for me. Lucky pre-50 boards you got there.

[Glasswalker]

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

Sorry, no exciting method.

I've done both my boards now (both pre-50) with no issues. After doing the controller, I unplug USB and power, set switch 3 OFF, all others ON. Attach power, wait, then attach USB.  I then run xc3sprog with the -j option to verify I can see the JTAG chain. I then flash 3,2,1,0 in that order using the standard command for each.

Sounds like you did it exactly how I tried to at one point, but it didn't work for me. Lucky pre-50 boards you got there.

Actually this has confirmed working on quite a few pre-50 boards at this point. Your experience with flashing is "abnormal".

I know roomservice was experiencing very similar issues to yours, and he recently got his working fine by simply adjusting the process and being extremely specific. There are several variables that can impact it.

as a general guideline:
- Doublecheck your USB cable (replace it with a known good one, preferably not too long)
- Try a different USB port on the PC
- Flash the controller to mine first, then try flashing the array FPGAs
- Doublecheck dip switch settings. Ensure they are right and power cycle the board (fully) before programming (unplug power AND usb, re-plug power, wait a bit then use USB once all the array FPGAs lights have come on)
- Flash the chips in reverse order (As suggested in the readme) starting with 3, and going back to 0.
- Try erasing the chips first, then going back and flashing them in reverse order. An existing bitstream in there may be interfering with the jtag chain (not sure how to erase using xc3sprog) (DO NOT do this on the controller, only on the array chips)
- sometimes due to jtag instability you get an error. Commonly simply re-trying will push past (the worst I've had on my 0001 board was like 5-6 retries to get a single chip to flash, completely intermittent). Once it's flashed no-need to reflash it in future attempts, just move onto the others. as long as they all verify in the end, you're good.
- Also make sure your mining software is not attempting to communicate with the chips while your flashing. (ie close it, or flash on a different computer, or remove those chips from your config or something)

Other than the above off the top of my head, pop into #cm1 on IRC (freenode), the group in there is extremely helpful and we'll try and get you up and running.

Hope that helps.

[Lethos]

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

Sorry, no exciting method.

I've done both my boards now (both pre-50) with no issues. After doing the controller, I unplug USB and power, set switch 3 OFF, all others ON. Attach power, wait, then attach USB.  I then run xc3sprog with the -j option to verify I can see the JTAG chain. I then flash 3,2,1,0 in that order using the standard command for each.

Sounds like you did it exactly how I tried to at one point, but it didn't work for me. Lucky pre-50 boards you got there.

Actually this has confirmed working on quite a few pre-50 boards at this point. Your experience with flashing is "abnormal".

I know roomservice was experiencing very similar issues to yours, and he recently got his working fine by simply adjusting the process and being extremely specific. There are several variables that can impact it.

as a general guideline:
- Doublecheck your USB cable (replace it with a known good one, preferably not too long)
- Try a different USB port on the PC
- Flash the controller to mine first, then try flashing the array FPGAs
- Doublecheck dip switch settings. Ensure they are right and power cycle the board (fully) before programming (unplug power AND usb, re-plug power, wait a bit then use USB once all the array FPGAs lights have come on)
- Flash the chips in reverse order (As suggested in the readme) starting with 3, and going back to 0.
- Try erasing the chips first, then going back and flashing them in reverse order. An existing bitstream in there may be interfering with the jtag chain (not sure how to erase using xc3sprog) (DO NOT do this on the controller, only on the array chips)
- sometimes due to jtag instability you get an error. Commonly simply re-trying will push past (the worst I've had on my 0001 board was like 5-6 retries to get a single chip to flash, completely intermittent). Once it's flashed no-need to reflash it in future attempts, just move onto the others. as long as they all verify in the end, you're good.
- Also make sure your mining software is not attempting to communicate with the chips while your flashing. (ie close it, or flash on a different computer, or remove those chips from your config or something)

Other than the above off the top of my head, pop into #cm1 on IRC (freenode), the group in there is extremely helpful and we'll try and get you up and running.

Hope that helps.

I could try erasing the ones on the chip, to see if it does help. Then try perma-flashing, but according to the verbose it actually does that anyway.
http://xc3sprog.sourceforge.net/manpage.php
The manual here gives a decent enough overview of what to do there.
However right now I got my 2 boards mining on a temp-flash, so until they crash I won't bother messing with it. It's been going a few hours at a solid 9.5u per board. I'm happy with that if it remains stable.

[Glasswalker]

To clarify I meant erase ALL 4 chips first (Without programming any), then go back and re-program from chip3 working back to chip0...

The reason for that is any of the 4 chips on the chain can be interfering with the jtag chain, wiping them gives a clean slate (no interference) then you can reprogram.

I wasn't talking about wiping the chip before programming it to ensure the flash is "clean".

Glad it's working for you, verifies the bitstream is stable even on your wacky board just flashing is being difficult. (which the above steps may remedy once you have cause to try them)

Thanks!

[Lethos]

To clarify I meant erase ALL 4 chips first (Without programming any), then go back and re-program from chip3 working back to chip0...

The reason for that is any of the 4 chips on the chain can be interfering with the jtag chain, wiping them gives a clean slate (no interference) then you can reprogram.

I wasn't talking about wiping the chip before programming it to ensure the flash is "clean".

Glad it's working for you, verifies the bitstream is stable even on your wacky board just flashing is being difficult. (which the above steps may remedy once you have cause to try them)

Thanks!

Good point, suppose they could be interfere with each other. One of those long shots I can't rule out.
They seem to be happy doing about 1.4 Gh/s and apparently less than 0.01% invalids so if it's stable for a few days I won't have anything to worry about. Look forward to improvements in the bitstream, kinda like making full use of 4 comm ports for each board.

[makomk]

It looks like I've managed to patch flashrom to flash the controller under Linux, fingers crossed. PMed Yohan and am waiting to hear what he thinks.

[gyverlb]

It looks like I've managed to patch flashrom to flash the controller under Linux, fingers crossed. PMed Yohan and am waiting to hear what he thinks.

Guess I may not have to wait for my JTAG cable then. If the new controllers can bring my 2 boards to 800MH/s instead of 650MH/s it would mean this would give me ~2.5 BTC more at current difficulty in the 3 weeks I expect to wait for the cable. I'll happily give you 1 of them

[kano]

Edit
Though I should add, if someone still wants to send me a CM1 as I was offered by someone who will remain nameless unless they want me to say who they were (I certainly know Yohan wouldn't) then yep I'd be able to try out these bitstreams and get it working in the Icarus code with the new bitstream options
(I said no before to him since I'd be wasting the board and reducing his hash rate and doing very little myself with it - but now the bitstreams/controllers are getting way more reliable it would no longer be a waste)

Oh and Glasswalker - a command to flash a led is also a good idea.
I've been thinking of adding that to the API for BFL to more easily identify which board is which - so being able to do that here would be good too.

[Glasswalker]

Oh and Glasswalker - a command to flash a led is also a good idea.
I've been thinking of adding that to the API for BFL to more easily identify which board is which - so being able to do that here would be good too.

That's not a bad idea at all, and could likely be done fairly easily. I'll see if I can add it in quickly in the latest code revision.

EDIT: This has just been added... There is now an "identify" command in the protocol, which takes a single bit as it's parameter. Turn that bit on, and all 4 LEDs on that chip begin flashing in unison, set it to 0 and the LEDs return to their normal operation.

[Lethos]

Good progress today, Glasswalker

The boards stayed stable over night, they had a few issues with hardware errors according to cgminer, which during all my testing will often appear in small amounts in the first few minutes with atleast 1 error, usually on the last (ica 2/3) ones on the board. However it was stable and still mining at a steady rate of around 9.5u a board.

I choose this time to restart them and look over the manual for Xc3sprog, to confirm what I knew it could do and that was just a quick erase. Hoping this would help me, perma flash them. It worked in the end, fully erasing them all, then restarting and going for a completely clean perma flash got them past verification and mining.
Also no more hardware errors after 2 hours of mining today.

Here was my methods incase it helps others;
I run xc3sprog natively from Ubuntu 12.04, instead of via virtualbox.
I also mine using Cgminer 2.65, with Kano's executable (will upgrade to 2.7 soon).
I use the verbose output in my commands to understand why they fail now, so it is abit different than before.

** Cold shutoff (all power and usb removed)
** Set switches 3 and 6 to off
** Plug in power.
** Wait a minute for it settle and connected usb.

Entered the follow, to confirm they were detected, then wipe them all individually (not sure), then do a all wipe.

Code:

sudo ./xc3sprog -c cm1 -v -j
sudo ./xc3sprog -c cm1 -v -p0 -e
sudo ./xc3sprog -c cm1 -v -p1 -e
sudo ./xc3sprog -c cm1 -v -p2 -e
sudo ./xc3sprog -c cm1 -v -p3 -e
sudo ./xc3sprog -c cm1 -v -e

** Cold Restart ( Disconnect USB and Power )
** Plug in power.
** Wait a minute for it settle and connected usb.

Then perma-flash it, with verbose out to see where it fails if it does.
* I've shorten the names on all the files for ease of typing them in

Code:

sudo ./xc3sprog -c cm1 -v -j
sudo ./xc3sprog -c cm1 -p3 -Ix150.bit hv175oc.bit
sudo ./xc3sprog -c cm1 -p2 -Ix150.bit hv175oc.bit
sudo ./xc3sprog -c cm1 -p1 -Ix150.bit hv175oc.bit
sudo ./xc3sprog -c cm1 -p0 -Ix150.bit hv175oc.bit

*x150.bit was originally xc6lx150.bit (if I remember right)
*hv175oc.bit is the name of the new hashvoodoo bitstream.

** Cold Restart ( Disconnect USB and Power )
** Return all switches to on (move 3 and 6 back)
** Plug in power.
** Wait a minute for it settle and connected usb.

Everyone mines a little different in cgminer, however I've found the icarus setting useful to add when starting up cgminer via the terminal are:

Code:

--icarus-options :1:1
--icarus-timing long

The first one is useful to properly calculate work division and the number of them per port. For Glasswalkers bitsteam this is different than Makomk's, ie it uses all 4 ports for 4 chips, instead of 2 ports for 4 chips. I find the timing set to long rather than short is better, since it hash rate changes all the time in small amounts I figure it's safer to do long.

[Edit:updated the correct options settings]

So in short, taking the extra step to fully erase a board, does fix some issues at the least, if flashing your board is problematic.

[Glasswalker]

Excellent! Glad you got it working!

And thanks for posting those instructions, they should help anyone else experiencing similar issues. So it does seem fairly common (your case adds to this) that the other FPGAs on the chain are definitely interfering with jtag operation. So I would say not only my suggestion of flashing in reverse order, but also wiping them all ahead of time should be the "reccomended" way going forward. (in my opinion).

I'll add this to the readme on all future releases.

Also Kano: Wanted to add, that I took both your suggestions:
I've moved the "improved" protocol packet into the tailing 0 block on the data2 block, so that it can't be used to exploit security. And I've improved validation/packet verification some.
And as I mentioned before, I've added your "identify" command, so each chip can now be identified easily via software.

I believe (fingers crossed) that I've solved the problems with the dynamic clocking code.

I've also stepped up the granularity of the DCM a little further (2.5Mhz increments now instead of 3.125, it's more even to work with, and a bit more smooth for tuning).

I'm doing a test build now, so hopefully it will succeed, and I can do another interrim release of that now.

Unfortunately due to the Xilinx tools going haywire, my previous smartxplorer run that's been going now for like 60+ hours, has just died... So I need to restart it.

I'm hoping I can re-run it with this new build if it works as expected.

So the next release may not be a faster version of the non-dynamic one, instead it will likely be an "approximately equal" speed release, but with the improved tweaks and new dynamic clock code, and then later I should have an improved clock version of that one.

[Lethos]

I hadn't expected the pre-emptive erase to be that effective, but since it was I figured it deserved a decent amount of feedback on how to do it.

[makomk]

Everyone mines a little different in cgminer, however I've found the icarus setting useful to add when starting up cgminer via the terminal are:

Code:

--icarus-options :2:1
--icarus-timing long

The first one is useful to properly calculate work division and the number of them per port. For Glasswalkers bitsteam this is different than Makomk's, ie it uses all 4 ports for 4 chips, instead of 2 ports for 4 chips. I find the timing set to long rather than short is better, since it hash rate changes all the time in small amounts I figure it's safer to do long.

In theory, I think Glasswalker's latest bitstreams should work slightly better with --icarus-options :1:1 (:2:1 is for FPGAs configured as an Icarus-like pair with no second FPGA, whereas his are designed to run standalone).

[kano]

As per the FPGA-README I wrote back when I added the option ...

Code:

--icarus-options <arg> Set specific FPGA board configurations - one set of values for all or comma separated
           baud:work_division:fpga_count

           baud           The Serial/USB baud rate - 115200 or 57600 only - default 115200
           work_division  The fraction of work divided up for each FPGA chip - 1, 2, 4 or 8
                          e.g. 2 means each FPGA does half the nonce range - default 2
           fpga_count     The actual number of FPGA working - this would normally be the same
                          as work_division - range is from 1 up to 'work_division'
                          It defaults to the value of work_division - or 2 if you don't specify
                          work_division

And yes you can leave values out if you want the default (as given in the example earlier by me and the one above)
  --icarus-options :2:1
Where the baud isn't specified so it uses the default
or even
  --icarus-options ::1
will also default work_division to '2'

So if Glasswalker's bitstream does a full nonce range on a single FPGA, yes indeed it would be
  --icarus-options :1:1
or even
  --icarus-options :1
(both mean the same thing)

[Lethos]

So if Glasswalker's bitstream does a full nonce range on a single FPGA, yes indeed it would be
  --icarus-options :1:1
or even
  --icarus-options :1
(both mean the same thing)

I only went off what you said earlier in the thread. Not like I really went into finding out what it did. It has worked beautifully since I done the change.
I will update and try :1:1 next time.

[kano]

So if Glasswalker's bitstream does a full nonce range on a single FPGA, yes indeed it would be
  --icarus-options :1:1
or even
  --icarus-options :1
(both mean the same thing)

I only went off what you said earlier in the thread. Not like I really went into finding out what it did. It has worked beautifully since I done the change.
I will update and try :1:1 next time.

No worries - just thought I should explain it