Search content
Sort by
Showing 20 of 30 results by [gadget]
I have an A1 board in need of repair, and I have Bitfurys that I'm likely never going to build. But perhaps there is a person out there in a mirror image situation... If so - let's trade! My Bitfurys for your A1s, GH for GH.
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
http://i.imgur.com/a5H8z8t.jpg
We have some level shifters we made for the ref boards. We could make a bigger batch for sale. Any interest out there?
We have some level shifters we made for the ref boards. We could make a bigger batch for sale. Any interest out there?
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
Driver is for RaspPi with direct communication thru SPI. I'm using microcontroller that is a brigde between chain of chips and host thru RS485 comm port. So I needed to write own "driver". Obviously I was looking at that piece of code, but it's not secret that looking at someone's code is painfull 
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...Hm, I tried to write the driver source code as self-explanatory and readable as possible, sorry if it was not as helpful as it could have been. Anyway, for one prototype I once ported the code to an STM32 controller, and after adapting the access to the SPI interface, it worked mostly unchanged. Unless you have a very resource-limited uC working with, I won't expect any issues.
Otherwise feel free to ask for clarifications, I'm helping out as far as possible.
Zefir, your code in cgminer is some of cleanest there is in there. Please don't let anyone tell you otherwise.
I wrote my own test code for A1s using the Pi and my feedback about the datasheet is that it was well written and (mostly) easy to understand. In combination with this thread I was able to get going in no time. I mean compare this to the (missing) bitfury docs and you'll see the difference.
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
Got my PCB made this week. Anyone else working on a reference build? Would love to compare notes 
http://i.imgur.com/J34PiOI.jpg
http://i.imgur.com/J34PiOI.jpg
I am selling 2 extra boards that I had made at cost ($25). I am in the US, quick shipping.
Does this work and do you have the BOM? How much for all the parts except for the A1 chips?
yes and yes. Oh, I dunno $50 maybe
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
Can anyone confirm on having built a working A1 board?
my reference boards are working
Re: Mining Asics Technologoes - 6 THS Bitcoin Miner - First PICS!
hey, hey, I'll do a review of your unit
On a more serious note - I looked at your website and it says that the ASICs are made by Dream Chip Technology. Is this a new chip? Just curious...
On a more serious note - I looked at your website and it says that the ASICs are made by Dream Chip Technology. Is this a new chip? Just curious...
Hi guys, have leftover chips (Bitfury rev2) from a project - 22 in total.
Offering them for sale at $6/chip. This is cheaper than buying from
bitfurystrikesback, and I'm in the US, so save further on shipping. Pm me if interested.
http://i.imgur.com/PtQOF1s.jpg
Offering them for sale at $6/chip. This is cheaper than buying from
bitfurystrikesback, and I'm in the US, so save further on shipping. Pm me if interested.
http://i.imgur.com/PtQOF1s.jpg
Re: Assembly Service for BitFury r.2 Chips into Nano Fury 6 USB Miners, 6 chips/unit
I was wondering if the assembly service is still open? If so, is it possible to do less than 8? Or maybe someone would want to go in with me? I was possibly interested in ordering 4
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
userbase++
If you all can confirm a single chip works, it would further motivate me to finish my schematic in KiCAD (and then work on a PCB layout) for the http://grid.coop/Minetor/ concept. Even if I have to have two chips, that would work, but I would have to run them at something like 400mhz or slower because I have a 30W power budget from power-over-ethernet. The real question about is 100mhz silly is what is the system total Gigahash/watt at that clock speed. If you can get away with some serious undervolting, it might actually make sense.
Also see http://bitspjoule.org/hg/nTekminer/rev/8128400e0aad for a patch that uses /usr/local/bin/gpio (from http://wiringpi.com/download-and-install/ ) for reset. I would rather use mercurial and bitbucket, but I will post a git version if that means someone will use it or it gets merged upstream.
If you all can confirm a single chip works, it would further motivate me to finish my schematic in KiCAD (and then work on a PCB layout) for the http://grid.coop/Minetor/ concept. Even if I have to have two chips, that would work, but I would have to run them at something like 400mhz or slower because I have a 30W power budget from power-over-ethernet. The real question about is 100mhz silly is what is the system total Gigahash/watt at that clock speed. If you can get away with some serious undervolting, it might actually make sense.
Also see http://bitspjoule.org/hg/nTekminer/rev/8128400e0aad for a patch that uses /usr/local/bin/gpio (from http://wiringpi.com/download-and-install/ ) for reset. I would rather use mercurial and bitbucket, but I will post a git version if that means someone will use it or it gets merged upstream.
I'm aware of wiringPi, but I'm not sure this approach is that much different from what I am currently doing. It is a separate binary that runs with root privileges, albeit set via setuid rather than an explicit sudo. I do like the idea of executing it through a fork() though.
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
Integrated into the current cgminer version via the A1 SPI driver today. Some thoughts:
HW_RESET via Pi's GPIO needs elevated privileges and is hardware specific, so I prepared a separate binary for that. Currently HW_RESET is only done once at start, hopefully doing it this way won't be a problem.
The reference board doesn't really have any kind of detection mechanism other than probing the SPI bus, so the board selector is stubbed out.
Also, I was thinking of modifying the set_pll code so that the fb_div never drops below 100, would this be of use?
I'm not sure if these changes would be accepted into the main cgminer branch, since they are not for a commercial product, but if there is any interest, I'd be happy to share the code.
Commercial product or not, as soon as it is used by more than one user, it is worth being integrated. Detection would have to be fine tuned then to distinguish between them, but I can support you on that.HW_RESET via Pi's GPIO needs elevated privileges and is hardware specific, so I prepared a separate binary for that. Currently HW_RESET is only done once at start, hopefully doing it this way won't be a problem.
The reference board doesn't really have any kind of detection mechanism other than probing the SPI bus, so the board selector is stubbed out.
Also, I was thinking of modifying the set_pll code so that the fb_div never drops below 100, would this be of use?
I'm not sure if these changes would be accepted into the main cgminer branch, since they are not for a commercial product, but if there is any interest, I'd be happy to share the code.
As for the privileged access: if I remember correctly, SPI access usually also requires root access, so it should be no problem integrating the GPIO based HW-reset functionality as part of a dedicated board selector.
Finally, as for limiting the minimum system clock to 100MHz, I have no defined response if that is really a hard limit. If you say you were not able to lock it below that, it would make sense to add a related sanity check to the code (although I doubt that this will be a use case).
I can also confirm that a single chip A1 board did not function by itself. It replied to soft reset, but refused to be enumerated. It functioned fine when plugged as chip-3 into a 2 chip chain, though.
Now this worries me somewhat, since I remember that during the very first bring-up phase we once break the chain after the first chip (shorted MISO/MOSI) and were able to work with only one chip. Are you saying that enumeration does not work at all, or the current driver failed to do so? If you had available a SPI trace of the enumeration command, that would help to ensure it is not the SW failing.If any of you DIYers get to the point of starting up cgminer, give me a message and we can have a two user userbase
The devspi should be a usermode driver, so there shouldn't be a need for root. At least that's what I have observed in my adventures. GPIO (on the Pi) on the other hand is usually mmaped to lower memory, thus the best one can do is to drop privileges as soon as the mapping is established, but that would still mean starting as root. I believe this was the reason that legkodymov's bitfury driver from sometime last summer did not get incorporated into cgminer proper. But perhaps I am mistaken and there is a way to do this, in which case I'd be very happy to learn about it.
I realize that running at 100MHz is kind of silly, but one use case I can think of is if you don't have a working cooling solution but really, really want to start hashing tonight
or allow self to keep working while bigger fans are on their way.One of the boards me and mazurov built had only one of two chips on it, and jumper W1/W2 was soldered in "perpendicularly" to close the MISO and MOSI. Unfortunately, I did not save the log, and that particular board has made the ultimate sacrifice in the time since
The testing was done with the simple test prog that I posted earlier, and now that I think harder about it: the chip replied to SOFT_RESET, replied to BIST_TEST (showed up as one chip chain), and I believe it replied to BIST_FIX. Now, IIRC, it did not respond to the READ_REG command that followed if it was alone, but did respond as expected if it was plugged in after (using the chaining plugs) another board as chip 3.Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
so you tried but it did not work?
Yes. There was some issue with initializing
the SPI chain correctly. It looked like a
chain of length '1' was not supported.
I also made a 10 chip A1 board, but never
even populated it. It all took too much time
and we moved on.
But c-cape did the coding, you should ask
him for details.
I can also confirm that a single chip A1 board did not function by itself. It replied to soft reset, but refused to be enumerated. It functioned fine when plugged as chip-3 into a 2 chip chain, though.
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
Integrated into the current cgminer version via the A1 SPI driver today. Some thoughts:
HW_RESET via Pi's GPIO needs elevated privileges and is hardware specific, so I prepared a separate binary for that. Currently HW_RESET is only done once at start, hopefully doing it this way won't be a problem.
The reference board doesn't really have any kind of detection mechanism other than probing the SPI bus, so the board selector is stubbed out.
Also, I was thinking of modifying the set_pll code so that the fb_div never drops below 100, would this be of use?
I'm not sure if these changes would be accepted into the main cgminer branch, since they are not for a commercial product, but if there is any interest, I'd be happy to share the code.
HW_RESET via Pi's GPIO needs elevated privileges and is hardware specific, so I prepared a separate binary for that. Currently HW_RESET is only done once at start, hopefully doing it this way won't be a problem.
The reference board doesn't really have any kind of detection mechanism other than probing the SPI bus, so the board selector is stubbed out.
Also, I was thinking of modifying the set_pll code so that the fb_div never drops below 100, would this be of use?
I'm not sure if these changes would be accepted into the main cgminer branch, since they are not for a commercial product, but if there is any interest, I'd be happy to share the code.
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
After some distractions over the weekend, I finally have some news to report. Using the new PLL formula
I was able to lower the sysclk to 100MHz, where the chips finally ran at a temp that did not burn my fingers when
touching them (infrared thermometer is on the way). I remember reading somewhere in this thread that chips
could be run at 200MHz without cooling, is that still true? Or does that refer to running them at idle (not under load)?
As a side note: the minimum fb_div appears to be 100. Anything lower would not PLL lock.
Code:
sysclk = (refclk*fbdiv)/(prediv*2^(postdiv-1))
I was able to lower the sysclk to 100MHz, where the chips finally ran at a temp that did not burn my fingers when
touching them (infrared thermometer is on the way). I remember reading somewhere in this thread that chips
could be run at 200MHz without cooling, is that still true? Or does that refer to running them at idle (not under load)?
As a side note: the minimum fb_div appears to be 100. Anything lower would not PLL lock.
Re: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support
Please take a look at latest cgminer driver. The PLL code was re-written to match updated specs quite some time ago and was merged upstream just recently. The issue was a misinterpretation of the PLL formula that got clarified with the latest chip documentation. It affected system clocks below 250MHz, so exactly your case. Please let me know if the problem remains.
As for the chip temps: as soon as the chip starts hashing, it instantly gets very hot. At nominal 800MHz, if you have no top heatsink installed, it reaches almost immediately 60°C with proper back heatsinks and more than that without. Obviously this also highly depends on the supply voltage, which is supposed to be on a safe side over 820mV. This requirement is unfortunately chip specific, so you might find some boards going just fine with 760mV while other are more picky with chips resetting immediately below 820mV.
As for the HW reset: this is always board specific. As reference, please check the A1 board selector sources where reset is performed with different types of i2c board expanders.
As for the chip temps: as soon as the chip starts hashing, it instantly gets very hot. At nominal 800MHz, if you have no top heatsink installed, it reaches almost immediately 60°C with proper back heatsinks and more than that without. Obviously this also highly depends on the supply voltage, which is supposed to be on a safe side over 820mV. This requirement is unfortunately chip specific, so you might find some boards going just fine with 760mV while other are more picky with chips resetting immediately below 820mV.
As for the HW reset: this is always board specific. As reference, please check the A1 board selector sources where reset is performed with different types of i2c board expanders.
Zefir, thank you for the quick reply. I am going through the code right now. I just wanted to quickly confirm something with you - the integrated code is specific to the CoinCraft Desk and communicates over libusb (rather than RPi SPI headers), correct? Thus, I will be merging some of the new stuff (such as the updated PLL code) into the old RPi A1 driver code?