I can report that the binary drops in and replaces the old one, matches the architecture, and runs without exploding in a ball of flames!
So I've pointed my S4, running this new binay, back at Slush's pool to see how it goes. [not well ...] after a few minutes that climbed up to and settled around 1TH and has been sitting there.
The Web UI also reports the Diff column (of the Slush row in the Pools table) as 1.05K, but I'm not sure if that indicates a problem...
Well, glad it works for starters. At least we know it managed to get up to higher diff which was half the problem to begin with. I doubt that getting it to diff 2k would help any further. So if it hashes lower than that then there's still some remaining issue, and likely it's the choice of a halfway diff.
Halfway Diff?
What the heck does the --bitmain-checkn2diff option do (play chicken with the diff? lol) google not so helpful here, not was the cgminer readme.
Checkn2diff is a hack used by the slow bitmain products to round off diff to the nearest power of 2 since they're so slow at confirming hashes. There's a chance it may not be needed with the hack I added to the driver, so try removing that command line option. As for suggest_diff, only ckpools have that implemented at the pool end anyway so I didn't bother adding it to the driver (though it's easy enough for me to do). So try without checkn2diff next.
Ok I removed the chicken diff option, but no change, really. I couldn't keep staring at half my hashrate being lost in slush's pool anymore so I pointed the S4 at ckpool (user gigawatt) and set the difficulty to 2250 (since its overclocked). Finally, a pool that recognizes my hashrate!
I wonder how thw payout will compare to Slush's pool... Assuming of course that ckppool ever solves a block lol -- it's like solo mining with a few friends!
{sigh} i'm gonna go nag Slush to re-enable user diff, now.