Cablepair is Tom, he's with Modminer.

Today i have time to test again.

You have to change the Device Identifier Code.
Cause My Spartan 6 have: Device IDCODE= 0x4401d093. That is the latest Revision that Xilinx delivers.

http://www.xilinx.com/support/documentation/user_guides/ug380.pdf page 80, the First 4 Bits Are Revision Codes.

My complete Commandline is:
java -Dbitstream=leibniz -Dclock_pin=csg484.W11 -Dclock_pin_freq=6.666 -jar tml.jar urjtag:flyswatter http://HelloWorld:-1@my.pool.bitcoin:8332

And this is the complete output:

_________________________________________________________________________
Tricone Mining Logic, host software v1.11

   IF YOU EXPERIENCE HIGH ERROR RATES: try running just one ring at a
   time (e.g. use 'ztex:0:0.0' on command line instead of 'ztex:0'). 
   If each ring works error free on its own, but you get errors when 
   running all three, it means your power supply is sagging.         

             adding work source gigaforge.com
             starting long poll thread
[flyswatter     ] found new board urjtag:flyswatter
[urjtag:flyswatter:0] found new chip
[urjtag:flyswatter:0] programming FPGA with bitstream leibniz
             USERCODE before bitstream upload: 0xcafebabe
             USERCODE after bitstream upload: 0xcafebabe
[urjtag:flyswatter:0]   done programming FPGA
[urjtag:flyswatter:0] magic number check ok 
[urjtag:flyswatter:0] chip is running bitstream version 0x50547e78, built 8d8h54m32s ago
[urjtag:flyswatter:0] chip has 3 rings       
[urjtag:flyswatter:0] assuming input clock frequency of 6 Mhz
[urjtag:flyswatter:0] asserting global reset
[urjtag:flyswatter:0.0] disabling DCM bypass mux
[urjtag:flyswatter:0.0] opening signcryption channel
[urjtag:flyswatter:0.0] setting clock to 149 Mhz, mult=45 div=2
H:0 X:0 E:0 T:10s   |  H:0 E:0 A:0 R:0 T:10s java.io.IOException: DCM did not report ready for programming
   at com.triconemining.miner.DCM.setClockFrequency(DCM.java:151)
   at com.triconemining.miner.DCM.setClockFrequency(DCM.java:62)
   at com.triconemining.miner.RingWrapper.setClockFrequency(RingWrapper.java:393)
   at com.triconemining.miner.ChipWrapper.enableRing(ChipWrapper.java:268)
   at com.triconemining.miner.ChipWrapper.enableRing(ChipWrapper.java:184)
   at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:101)
   at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:73)
   at java.lang.Thread.run(Thread.java:722)


My Clock is generated from a Frequency Generator. I also tried with 5, 10 and 20 Mhz. always the same result.

FYI I will have limited/unreliable internet and email access until Tuesday 02-Oct.

Hello,

  I'm running 2 mod miners and mine died about the same time.
I don't have remote access to them yet and I'm not in front of them so I have know Idea what the error is yet.
Just weird that mine died at roughly the same time as yours.


 

Looks if code changed to avoid send of shares below difficulty.  May be because of load on TML servers.  It would be excuse for not allowing connections from older client.

Bitstreams significantly differ, but could be result of compilation of minor change.  Appears some midstate java code calls simplified.  Could be reason for larger bitstream, to move into fpga.  Midstate changes relate to signcryption and could be server affecting as well.

I am guessing based on simple analysis of available source code and eyeball + tools of bitstreams.

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!
But why on earth does this warrant a breaking protocol change AT ALL? (Not to even mention that there was no prior notice.)
Well, maybe the old bitstream contained some critical flaw in the signcryption code that was fixed in the new one? I can't think of a different (rational) explanation. But OTOH it wouldn't be the first time for ET to act in a completely irrational way.

I suspect he accidentally released enough information for a clever hacker to bypass the signcryption. Been resisting the temptation to try.

Below is an excerpt from an email I sent to TheSeven which does a good job of explaining the situation.

All of the anger is completely justified.  This was a screwup on my part.  The only consolation I offer is that this wasn't the result of me doing something, it was the result of me failing to do something.

The leibniz bitstream doesn't expire for another 40 days.  Long before then I will make sure this doesn't happen again, most likely by removing the ntime check.

FWIW, I had no idea so many people were using the TML.  I suppose that means that when I turn on the commissions I will get a nontrivial income from this, in which case I will have a strong motivation to take uptime very seriously.



Blue portions were edited relative to the email I sent him (due to wider audience).  Bold added for those who are skimming.

Well, the reasons are standardized as part of BIP 22.
Obviously it's not necessarily a rule for the now-obsolete getwork protocol, but there's no reason not to use the same strings either.

But more importantly: if your miner had supported the target - which has been standard since getwork was created - you wouldn't have these rejects at all.