Hm. How about when you turn on full diagnostics in CGMiner. Before the board resets, do you ever see anything odd like got Nonce for invalid hash, or stuff like that which might indicate chip cores are yammering on top of each other?

When the dies come back do you once again get invalid nonces coming out of them (meaning the dies reported stale work) or do they just pick up and hash (indicating the dies lost power and reset their buffers)

Any links to close up pictures of a board? How do they have the power laid out between the DC-DC's and the chips?

Edit: I see the nonce error. Interesting. Pi's suck at SPI by the way, they should have used beaglebones. This points away from a power supply dc-dc issue at the moment. Hm.

Honestly I feel like I should buy Kestrel 957 flux by the drum. It's not as tacky as Zephlux but that's for bitchy bga's.

C

Not right yet. I just got off fixing a bunch of Titans, and porting that code to BBB has given me an appreciation for the diagnostic code in BFGMiner. Thus my question if you can get into the system on a shell console and see if screen -r will get you the cgminer or bfgminer screen.

Then the fun can begin. If someone wants to front me a crap board and controller let me know. What's the worst that can happen?

C

Dear God No. This is me pounding my own head against the KNC wall. Besides I would rather blow up beaglebones on controllers trying to figure out some of these failures than the now limited supply of Raspberry Pi's.

Note: Everything I do here is my own work or is based on publicly accessible documents. I have no encumbrances or NDA's in this venture and I would prefer to keep it that way.

C

If you can get cgminer up turn on every logging option possible and post the results.

Hm. What do you see when you ssh into the Pi and run screen -r? What kind of errors is the cgminer saying, and is there a specific build they're using for the specific device? In fact what the hell devices are they using to talk to this thing over the SPI bus?

C

Update: I have the code working for a Neptune 100% on a beaglebone (yeah, big deal but it's a bitch to compile and get working) however Titan is still down. It's somewhere in the titan.c files in Bfgminer. But anyway in the meantime know that the newer version of fpga code on the Rpis can work with Neptune boards, so it's an enhancement to the Neptune code and not a replacement.

BBB's compile so much faster than Rpi's. I hate Rpi's.

Someone here made a replacement, but the gen two versions have a few issues. You can fix the Gen 1 versions by replacing the Pi and powering it from USB power if you really want. Or send it to me to fix.

C

Indeed. The problem seems to be that the video chip in use in the latest RPi B+ 512 1.2 Pi's requires the later bootloader and kernel than what is in the 2.00 release. The problem with this is the latest kernel totally breaks the SIO interface so things don't work for crap. It's possible someone can find the last kernel, bootloader, and elf that supported the old SPI standards we could try that. I spent all weekend screwing with this, someone else can help.

In the meantime I've picked up the "make the damn beaglebone work". After pounding for the rest of the weekend I have waas up, website up, I can configure the Titans (and Neptunes), and have bfgminer compiled to the point where it can see the knc0-4 devices but they don't initialize.

So close. There are a lot of errors in the KNC documentation, compiling this is a pain in the ass. I think the final issue is in asic.c.

C

I think we're fucked. I just spent 6 hours working on this code trash heap they call KNC. The problem is when you update the damn OS it breaks all the I2C extensions and re-enabling them is a work of pain.

Somebody else fix this, ok? It's pretty obvious that even older revision technology is incompatible with itself. Because stupid. It looks like it might be in the device tree support; I was able to get at least something up with turning that off, but the one i2c driver does not see any of the devices on the Pi at all.

Whole day shot to hell.

And in the ter-fucking-ific category, it looks like the Rpi model B 1.2 models currently on Amazon.com have a slightly different CPU and will not boot the stock KNC firmware. So we're dead in the water there.

Stupid micro-code. This could be a problem.

Yeah, I know. And I got two of them working on all dies (ok, one die out of 8 is a bit wonky but that's fucking amazing!) The trick is if it has only one die hashing it's possible the other dies have cold-soldered themselves to the point where they don't work. It's possible to reflow but be warned: IT IS VERY EASY TO FUCK IT UP AND WIND UP WITH A DEAD UNIT. Also the line drivers were damaged on one board.

Speaking of which: I finally figured out what line drivers/buffers these KNC people used: It's this:

https://www.digikey.com/product-detail/en/fairchild-semiconductor/NC7WZ17P6X/NC7WZ17P6XCT-ND/

They are super small, and super critical: If you plug in your 10 pin header so that it goes over pins 13579 with 246810 then you will probably blow up a few of these, your cube will appear, but will never hash. It will also blow out the FPGA on your controller, so a twofer failure.

So I have now expanded what I can fix:

If your Titan has one die, I can try to get it to 3-4 dies
If your Titan comes up with no hashing but can be seen in KNCminer, I can probably fix it
If your Titan has a burned power connector I can fix it
If your Titan totally burned the board under the power connector then sigh, I can fix it.
If your controller is dead, I can fix it
If your bridgeboard is dead, I can fix it but you have to replace your Rpi too.
If your Rpi is dead, just get a new one and power it via the USB port. Lazy but works.

And as for the crystals, it's probably one of these:

https://www.digikey.com/product-detail/en/txc-corporation/7B-24.576MBBK-T/887-1898-1-ND/

But I need to measure it with the digital calipers. Note though the cross-grounds that's part of the problem with the QB BB.

C

Um.... No, not hostile, just working. I charge my time and effort which includes figuring things out. Remember I've spent part of a week taking this little bridge board thing apart, reverse engineering the leads, scratching my head at why the grounds are different from a rational design (most people don't route 3.3v from a charge pump to ground) figuring out the component using a scope, and risking my own gear (my bridgeboard, my pi, and my controller board which costs me $90 in parts and an hour of cursing and two reheats to swap the fpga every time I blow it out because KNC didn't #&$@*$@ put any buffers on the outputs).

That's totally independent of the time it takes to design (if I had the design I would be a big big big step ahead in life but I don't and that's that) and work with a firm to fab boards. If I had the mask files for any of this, it would be a snap.


It's different skills, and thus not comparable. I charge at least $150 an hour for professional work partially because I value my time and partially because I can get paid a lot more for my main line of work (and there are only so many hours in the day). So far this week I have spent a lot more than that figuring out some of these problems, so my bill rate is probably pretty low :-)

As for you not being able to say anything, well you can't and that's fine, I can figure it out myself. Just takes a long time, using fuzzers on these boards is a bitch on wheels  due to the 6-8 layers and the monster ground planes in there. Also stuff goes weird places and some of the design decisions don't match what I would call anything rational. Which is why I post my stuff on my fixing forum, because other people should (and have done) working on my work. Since I have no encumbrances I can do that.

As for value, let's just say rework is not something that can be done easily (I have reversed the damage done by at least one other person trying to rework SOT23's with a blowtorch somewhere in the world) and takes some skill. If people wish to undercut me on price then by all means please DO SO!, having more people fixing this stuff is good, and gives home miners options.


I appreciate this, that's why I fix this stuff. Big big customers have their own shops and have probably twisted KNC's arm for the schematics. I just help level the field for the home miners. I also dispense advice around here, mostly telling people to STOP RUNNING THEM AT FULL BLAST and run them at 60mh per cube. Cooler, less power overload, etc. Also this is a several thousand dollar item made of ultra cutting edge parts for a cryptocurrency philosophy that is the cutting edge of the future. Don't run it in a fucking barn (I say as I literally had to clean horse crap out of one board. Yes. Straw included. Yes, the Straw had caught fire. Several Times based on the burns on the board).


Sounds good. In the meantime if anyone is dead in the water drop me a line or read my other thread on fixing these things for fun and laughs. You can do the fix yourself on the stock KNC boards (I believe I documented it in my thread) if you can use a fine-tipped soldering iron, have good eyes or a 3x loupe, and can get wire wrap wire from Radio Slack. That and a steady hand will do it.

Well, since the batch 2 boards appear broken I would assume that the seller refunded the cost of the board as what was delivered appears to be (at least in the case of 2 received and reviewed so far) a non-working board. That's not my issue or concern, and doesn't affect the prices I charge for my tools and time.

By that logic the total increase in cost of ownership to the end user is only .05btc plus shipping. .2 also accounts for my time, effort, and the (one) Pi fried so far in troubleshooting this thing blind, as the maker of the board is unable/unwilling to provide information on it. So I have to do it the good old fashioned way (my brain and time), just like the KNC boards.

C

Got the board to come up with a Pi, but that crystal is still wrong. I can order a few from Digikey, if I can fix this for .2btc is there any interest?

As for Searing I'm having fun with his boards and a blowtorch.... :-) (just kidding, well sort of, got 2 boards there fully hashing. Progress)

Actually 10btc sounds like about what it would cost me in time to hack together the code load on a BBB to a point where anyone could use it. Fair deal.

You have a working batch 2?

C

You don't know what is wrong with your board?

C

Oh I see what happened. He didn't short the +5 volts to ground. He shorted the +3.3 volts to ground. Which is produced by the Pi on pins 1 and 17. I can tell because the line from 1-17 that goes to two vias is shorted to ground before the first via. It then is supposed to attach up through the second via to the cap for the crystal, then go down to the main controller board (not sure if the main board uses 3.3 sourced by the Pi/BB. That would be odd since they have a perfectly good TMS chip there on the left....) I can see it's still grounded at the bottom of the board, will try seeing if I can figure out which via (or both) is shorted next.

Cutting that trace gives me a pi that will come up on the qberty board. Not going to try to hash with it (the crystal is powered by that 3.3 line, so it needs to be intact somehow) will see if the mainboard provides 3.3 as well. Maybe I can hot wire it.

Oi.

Edit: Found it. 3.3 is needed on main board. Working to re-mediate the error.

Meantime back to work. Some things I have been working on:

The qberty boards. Something is fucked on them, and I'm looking into it.

Got a Titan that was hashing on one die, problem is another die is mumbling garbage that shuts down the rest. Working to isolate.

Got another Titan with the normal 4-6 short. However I did find something: Pins 4 and 6 both are power to SCI type channels. Normally they are isolated, but on many cubes they share a common rail at the junction between U9 and U10. Disconnecting this clears the fault on pin 4 but not 6. However this does clear a lot:

Pin 4 powers the SCL lines for the DC-DC's, the EEPROM, LM75, and one of the level shifters. So it's not that.

Pin 6 powers U17,18,19 (the clock circuitry), and the 8 lines under each die. Which can't be isolated and sucks.

Pin 7 is a Sdi clock channel for the DC-DC's and house stuff
Pin 2 is the SDA channel for the DC-DC's and house stuff

Pin 8 is another interesting one: It goes to each of the corners of the chip, with isolation. I think that's either the SDI clock or signal for the chips themselves. This is how you can bypass a mumbler.

So if Pin 6 is what is blowing up, then it is either the clocks or the chip die (in which case we're fucked). Hm.