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

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!

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.

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.

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.

I did use SPIprog, that was the easy part.

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

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

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.

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).

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

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!

EDIT:
For a TLDR version of this for those of you using the current bitstream:
- You are not at any risk at all, the "enhanced" protocol doesn't work currently in the existing bitstreams
- Once I release one where the dynamic clocking DOES work, you will want to use mining software which supports the "enhanced" protocol for security reasons.
- Even without said software support, it will still mine on older "unsupported" software fine, and the only real risk is if your pool decides to act maliciously (which is unlikely for most).
- That said, you will want to use this feature once it's out anyway, as it will allow faster mining.

Thanks!

--icarus-options :2:1

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.

Early days, but after flashing this to a pre-50 board that was giving lousy results with anything but the twintest bitstream, I am now seeing the best numbers I've seen for this board:

 ICA 0:                | 368.3/370.7Mh/s | A: 77 R:0 HW:0 U:  2.42/m
 ICA 1:                | 373.4/373.8Mh/s | A: 68 R:0 HW:0 U:  2.14/m
 ICA 2:                | 374.4/373.1Mh/s | A: 78 R:0 HW:0 U:  2.45/m
 ICA 3:                | 374.0/372.5Mh/s | A: 86 R:0 HW:0 U:  2.70/m

NB - this is one board - you add all USBs with this bitstream (and ignore the MH, just look at the U)

Obviously, this is only half an hour in. But looking good so far. Thanks.

I tried that Yohan, however only a quick temporary flash would go through and worked fine. The one I wanted to do and is usually suggested that properly flashes it, fails verification after the flash. I don't know if that is my fault, the hardware or the bitstream.

It works right now, with a quick temp flash, so I'm just testing it's stability, to see if it's worth doing the same to the other board.

I did a temp flash instead, which did still work, with switch 3 and 6 off. It sometimes cooperates to flash with:


Do the above for p0, p1, p2 and p3 (think I remembered the above correctly)

I will try and get some pictures for which way to connect as that might be part of the problem. You also have to use SWITCH4 set to master on the board with USB and slave for the second board. Otherwise it don't work.

We think Rev 1.5 is ok and programmer is fixed but we will do a little more testing with it before we release that formally.


Depending what Controller version you have the details may vary a little but for most versions SWITCH3 set to "off" during programming of the array FPGAs/SPI Flash is usually recommended. SWITCH8 at "on" (default) for using the internal programmer. Remember to put SWITCH3 back to "on" when finished programming. It's always best to power cycle the board before programming as sometimes FPGAs get hung up in strange states.

Got excactly the same issue, so you are not alone (Board SN 21 here).

EDIT: Confirm the bitstream works perfectly on all 4 fpga of this early board in temp mode now! Glasswalker did an awesome job.

Tried again and it's more solid with the temp-flashing this time it appears, Pretty solid 9u for the entire board.
I can't get perma-flashing working so if anyone feels like helping me out and point what I'm doing wrong (if at all) then I'd welcome it.

We have progress, I've had no luck perma-flashing them. But temp-flashing does works now (I did try that first, apparently gave up too quickly).

It lasted all of 7 minutes mining, before the entire board disabled.

Thanks Makomk, I've just done a verbose of the process, since it was pretty repeatable.
It does manage to flash all 17 sectors, but when it verifies it finds their is a difference between what is on the file and on the chip I presume that is what it's telling me.

I did have one of your 210 bitstreams on their before, I don't have a jtag cable, so I'm a little concerned to do anything that is not suggested here.
I'll give your suggestion a go. Will let you know it a bit.

Hmmmm. Try setting the SWITCH3 to Off as per Glasswalker's instructions, then toggling SWITCH1 to Off and back to On again (which power cycles the array FPGAs), wait for the LEDs next to each FPGA to light up, and then try flashing the array FPGAs again? This may be particularly necessary if you've got one of my faster bitstreams flashed to the board.