A lot of the early posts talk about only connecting RX and TX, no mention of ground. Even some of the earlier pictures IIRC didn't connect ground. I had tried ground but was facing the damn silkscreen reversal issue.
I imagine my pl2303s would've worked too.

Note for people trying this after me and facing issues:

***
Try reversing RX and TX lines on the UART.
Connect Ground between blade and UART.
Use the FireWalkerX git.
Make sure you are in the right USB group, and that /dev/ttyUSB0 is created with the right permissions. If not, check the udev rules file from the git.
Ask for help on here. Be clear with your issues.
**

THAT WAS IT!!!

I connected ground on one of the blades, fired up cgminer from FirewalkerX. Boom, hashing at 65GH/s!!

uart and and blade flashing like mad.

Poolside even shows 65GH/s. Sweeeeeeeet.

Also, very low error rate on this one blade, 0.03%.

I was wondering about that, I tried connecting ground awhile back with the PL2303s but considering the mixed RX/TX lines and other issues, I'm not surprised it didn't work. I'll add it to the troubleshooting list!

Thanks!!

Not anywhere that I have seen.

Only ones here (https://www.bitmaintech.com/support.htm?pid=007201404130633105772QFG6R2u0635) are Windows.

I just tried bfgminer from the repositories and once I tell it to detect /dev/ttyUSB0, I get:

 bfgminer version 3.10.0 - Started: [2014-11-15 11:00:40] - [  0 days 00:01:24]
snip
 1            | 60.88/943.5/ 0.00Mh/s | A:0 R:0+0(none) HW:3494/100%\
 BPM 0:       |  2.61/ 1.11/ 0.00Gh/s | A:0 R:0+0(none) HW:3494/100%

Not sure if this is an improvement, I definitely see 100% error rate. I will try again later. Thanks again.

Are you referring to the Windows binary? This one? https://github.com/AntMiner/AntGen1/blob/master/cgminer/cgminer-run-windows-20131224.zip?raw=true

Bit of a pain as I have no bare-metal install of Windows. Might try USB pass-through on my virtualbox vm today.

Cheers and thanks for the help! Unfortunately I have essentially no coin to tip.

Ha, yep!

Here's the full output, no sudo but in the proper usb groups. It hangs here, no change. Green LED on board is flashing, no hashing, no further messages. As I speak, I'm compiling on the rpi to try it there too. I've tried one of the PL2303s too, same behaviour.

I wait until cgminer fully starts up (displaying the full console) before I plug in the USB.
 [2014-11-15 10:17:49] Started cgminer 4.7.0
 [2014-11-15 10:17:49] No devices detected!
 [2014-11-15 10:17:49] Waiting for USB hotplug devices or press q to quit
 [2014-11-15 10:17:49] Probing for an alive pool
 [2014-11-15 10:17:50] Pool 0 difficulty changed to 16
 [2014-11-15 10:17:51] Network diff set to 39.6G
 [2014-11-15 10:18:01] -----------------start freq-------------------
 [2014-11-15 10:18:02] Send frequency 82098110
 [2014-11-15 10:18:02] Send freq getstatus 84000400

And after some time, it segfaults out with classic "Segmentation fault (core dumped)".

Previously (with RX->TX and TX->RX) I've had it get further where outside of this snip, the 0xea60 device is found:

[2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:13] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)

With RX->RX, TX->TX, I played with when I plugin the uart device. Right now I have with debug and starting cgminer first:

 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 10 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 5 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 1 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 8 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 2 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 2 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 13 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 8 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb

(or some other 'Read data' string depending on which time I fire this up) I still have green LED on the blade.
The blade is never formally "detected" by cgminer and hashing does not start.
My conclusion is that RX and TX were indeed swapped on the uart.

So far no dice with the switched RX/TX. I get flashing on the blade, but no further activity on cgminer. Stalls at:

 [2014-11-15 09:24:59] Started cgminer 4.7.0
 [2014-11-15 09:24:59] -----------------start freq-------------------
 [2014-11-15 09:25:00] Send frequency 82098110
 [2014-11-15 09:25:00] Send freq getstatus 84000400

and eventually segfaults out. Switching to the other blade without resoldered pins.

Screw it, pray for no magic smoke. I'd be blown away if that was it. Two different uarts, both swapped on the silkscreening...

Ouf, really? I thought twisted RX/TX lines would end up blowing one end of the UART and letting out the purple smoke?

How did you discover that they are twisted? Did you just flip them half-way through and saw if they worked?

These are the UARTs I have:

http://www.ebay.ca/itm/USB-2-0-to-UART-TTL-6PIN-CP2102-Connector-Module-Serial-Converter-New-/231367399716?pt=US_Parallel_Serial_PS_2_Cables_Adapters&hash=item35de925924

This is all on Ubuntu 14.04 fwiw.

Not running with sudo (as no one should be, much better to set the proper permissions. A compromised miner running with sudo could easily infect your machine)

I'm part of plugdev, and dialout (...4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),124(sambashare)...)

Permissions on /dev/ttyUSB0 are:

crw-rw---- 1 root dialout 188, 0 Nov 15 08:27 /dev/ttyUSB0

Also, I have /etc/udev/rules.d/01-cgminer.rules from I believe it's bitmaintech.

The USB bus is rather complicated on the laptop I'm running this on (screen digitizer, fingerswipe reader, etc). I'm going to fire up my raspberry pi and see if I can get it running there.

I've been using two different CP2102s on two different blades for now. I've run a voltmeter across the 12V pci-e connector, getting a healthy 12V. I haven't test pointed anywhere else on the blade. If the pi is unsuccessful, I will make sure the RX/TX lines are good. One of the blades has had resoldered pins to ease prototyping, the other has direct soldered to leads off the uart. It's possible the resoldered one didn't get good solder through the hole. Are these blade multilayer boards? I suspect they are.

Same, no change. I'll diagnose in the morning.

Working through my CP2102s on my 4 boards again after a hiatus.

I have a whole slew of:

AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:13] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] Discarded work
 [2014-11-14 20:37:14] Selecting pool 0 for work
 [2014-11-14 20:37:14] Generated stratum merkle dd97b19085ad4c5c1631a740ee43a7dcf52656eec12e478c7b582189d553d70b
 [2014-11-14 20:37:14] Generated stratum header 0000000255f68287a970c063a3523c67d4edc537dd0ecd13018236260000000000000000dd97b19 085ad4c5c1631a740e
e43a7dcf52656eec12e478c7b582189d553d70b5466ae2e181bc330000000000000008000000000 000000000000000000000000000000000000000000000000
 [2014-11-14 20:37:14] Work job_id 62459d0e nonce2 5 ntime 5466ae2e
 [2014-11-14 20:37:14] Generated target 00000000000000000000000000000000000000000000000000f0ff0f00000000
 [2014-11-14 20:37:14] Generated stratum work
 [2014-11-14 20:37:14] Pushing work from pool 0 to hash queue
 [2014-11-14 20:37:14] (5s):0.000 (1m):0.000 (5m):0.000 (15m):0.000 (avg):0.000h/s
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] Send freq getstatus 84000400
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=471)
 [2014-11-14 20:37:14] Send freq getstatus ok
 [2014-11-14 20:37:15] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:15] AMU0: Read freq Comms timeout (rerr=-7 relen=0)

and

 [2014-11-14 20:37:00] AMU: cgid 0 EnableUART got err 0
 [2014-11-14 20:37:00] AMU: cgid 0 SetDataCtrl got err 0
 [2014-11-14 20:37:00] AMU: cgid 0 SetBaud got err 4

But no hashing using --bmsc-options 115200:550 --bmsc-freq 0981. I've played with many timeout settings but same behavior. Again, using bitmaintech cgminer. No flashing lights on the board either.

Thoughts?

It's being seen as 067b:2303, I will try again with strictly the --enable-icarus instead of --enable-bmsc. According to lsmod, the driver is loaded properly, and /dev/ttyUSB0 is being made (until it is grabbed by cgminer)

EDIT:  [2014-11-11 15:48:32] USB init - ICA device 6:30 usbver=0110 prod='USB-Serial Controller' manuf='Prolific Technology Inc.' ser
ial=''
 [2014-11-11 15:48:32] ICA0: GetResults (amt=0 err=-7 ern=61)
 [2014-11-11 15:48:32] ICA: cgid 0 SetDataCtrl got err 0
 [2014-11-11 15:48:32] ICA: cgid 0 SetLine got err 7
 [2014-11-11 15:48:32] ICA: cgid 0 Vendor got err 0

That's what I appear to get with solely enabled icarus.

I have a sneaking suspicion this might be due to the fact that the uarts I'm using are the super-cheap (ie, counterfeit) ones. They work fine when shorting RX and TX, but might not be behaving 100% correctly.

Got another board setup (I really need better heatsinks...), but I've come to the conclusion that the PL2303s simply won't work, period. cgminer sees the uarts, and sends the nonce tests. However, that fails (Bmsc recv golden nonce timeout). Even if I comment out/skip past the checks in driver-bmsc.c, it fails out even further down. So I suspect it really won't work, at least not with the little time I can invest at this point.

Has anyone had the PL2303 work?

I do have some CP2102s which should be in the mailbox any day now so I can get in on the party. I might try underclocking so I can avoid/minimize the heatsinking.

So far so good, I managed to get further than before. Stupidly, I was using the ckolivas repo instead of the bitmaintech one.

 

For someone in my footsteps:
So, install the bitmaintech one and compile. With my PL2303s, I didn't have to make any changes except to the rules file which I will be reverting back as it wasn't necessary. It may be the cause of my problems anyways.

The UART is seen by cgminer where it attempts to mine. However, I'm hitting the:

 [2014-11-08 00:07:48] Bmsc send golden nonce
 [2014-11-08 00:07:48] Bmsc recv golden nonce timeout

issue which can't be fixed by the timing of which I plug in the device. Still diagnosing this. I suspect it may have to do with the shitty connections I have as the jumper leads to the blade header aren't so good or the rules file. If not, I will also try another blade, small chance this one isn't working.

I'm interested too as I got a pile of PL2303's before we were set in stone about the CP2102s. I imagine I have to compile a cgminer/bfgminer with modified source on my linux machine for the different UART boards. I changed the "rules" files of each so that only the PID/VID of the PL2303s is used but haven't had any luck so far after compiling. I'll be reattempting later tonight/tomorrow just using --enable-bmsc.

Either way, I just purchased some CP2102s too and hopefully they can come in quick so I can get mining away on this.

Any thoughts?

I ended up changing all the PIDs/VIDs in the "rules" file of both cgminer and bfgminer to match a PL2303, but still no dice. I assume that there's more to it than that, and it's further hardcoded based on each asic type?

Could I recompile bfgminer for PL2303 using the correct PID/VID (I'm on Linux)? Sorry for the silly questions, this is my first exposure to ASIC mining that wasn't plug n' play.

I got my heatsinks and UARTs in so I put together one blade to start hashing

I hooked up TX->RX and RX->TX. I tried with GND connected and disconnected.

However, with the bitmaintech cgminer 4.7 and compiled with "./configure --enable-icarus --enable-bmsc --enable-bitmain", I get a whole slew of

 [2014-11-04 19:30:15] ICA 0 usb transfer err:(-9) LIBUSB_ERROR_PIPE
 [2014-11-04 19:30:15] FAIL: USB get_lock not found (6:18)
 [2014-11-04 19:30:22] ICA 0 usb transfer err:(-9) LIBUSB_ERROR_PIPE
 [2014-11-04 19:30:22] FAIL: USB get_lock not found (6:19)
 [2014-11-04 19:30:34] ICA 0 usb transfer err:(-9) LIBUSB_ERROR_PIPE
 [2014-11-04 19:30:34] FAIL: USB get_lock not found (6:20)

I'm using a PL2303 device, and when I start cgminer, I lose the /dev/ttyUSB0 (I think cgminer is grabbing it)

Any thoughts?