[CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support

[totalslacker]

I will work on getting the voltage up to 0.85V.

I used the supply margining feature and got the core voltage up to 0.85V. I'm still getting exactly the same results.

I poked around online and found some other test vectors. I don't get the same results as they do either, but I consistently get the same (incorrect) nonce's so I guess that's good I'm running multiple jobs through each chip and looping through the whole test five times (just running one chip at a time currently).

I'm seeing peak to peak ripple of about 50mV on the scope so power looks to be good. I would also expect to not get such consistent behavior if I had a power issue?

So perhaps I have a nasty bug somewhere…

Thanks!

[1715228850]

1715228850

[1715228850]

1715228850

[1715228850]

1715228850

[jbcheng]

Announcement: Clarification on my personal Involvement with Bitmine


Dear DIY folks and miners,

as written in the OP, with the chips I ordered and distributed here, I have been Bitmine's largest customer from the beginning. With my ongoing work as consultant for SW and support during bring-up phase, I must have made at least something right: I have been offered a substantial stake of the company's shares and with that since this week I am also a board member.


How does this change the DIY chip distribution?
Definitively only for the better. Running this proxy service for the community already turned out to be error prone and impractical for higher demands. With manual processing, I already messed several orders up (delaying them or sending twice). The first action implemented for that was to make sample chips available from Bitmine's online shop.

Now that the first wave of DIY volumes was delivered, I expect not much further demands for 50+ volumes - those with working design will sure go for 500+ chip orders. To keep the door always open for late comers, I will pursue the integration of smaller order quantities in the online shop.

From this position I have a better influence on Bitmine's day business, so if there is something that can be improved for the DIY scene (I know there is), please let me know, either by posting here publicly or via PM.



Thank you all for the trust and support so far,
zefir

Congrats Zefir，You deserve it!

[danchoo]

I have some problem in comfile the cgminer-bitnime-A1-scratchpad.

https://github.com/bitmine-ch/cgminer/tree/bitmine-A1-scratchpad

in making process...Message like this.

  CC     cgminer-api.o
  CC     cgminer-logging.o
  CC     cgminer-usbutils.o
  CC     cgminer-driver-SPI-bitmine-A1.o
In file included from driver-SPI-bitmine-A1.c:19:0:
spi-context.h:4:25: fatal error: linux/types.h: No such file or directory
 #include <linux/types.h>
                         ^
compilation terminated.
make[2]: *** [cgminer-driver-SPI-bitmine-A1.o] Error 1
make[2]: Leaving directory `/home/Note/cgminer-bitmine-A1-scratchpad'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Note/cgminer-bitmine-A1-scratchpad'
make: *** [all] Error 2


It is missing some libraries?

[Cheshyr]

I pulled it from git and compiled it on the RPi yesterday with no issues.  I'm not sure why you'd receive that error.

[danchoo]

I pulled it from git and compiled it on the RPi yesterday with no issues.  I'm not sure why you'd receive that error.

This source code is only RPi work?

I try to activate Windows 7.

[end18]

I pulled it from git and compiled it on the RPi yesterday with no issues.  I'm not sure why you'd receive that error.

This source code is only RPi work?

I try to activate Windows 7.

Are you doing in MinGW?

you need to change some headers for windows.

#include <linux/types.h>
#include <linux/spi/spidev.h>

[zefir]

I pulled it from git and compiled it on the RPi yesterday with no issues.  I'm not sure why you'd receive that error.

This source code is only RPi work?

I try to activate Windows 7.

Oh sorry, I thought it was obvious. Already wrote it several times it is designated for Linux and works only if you have an SPI interface in your system.

How do you plan to access it from Windows? If you are using some USB->SPI bridge, check some posts above: drinkmorecoffee and others work toward such approaches that will allow to decouple the driver from the OS. In the driver I provided there is already an initial abstraction from the SPI interface: just write your own spi-context module that wraps direct access to SPI over that bridge (cgminer has already support for MCP2210).

I could help with that once I am done with the SW for Bitmine, but I'm sure it will be already done by then.

[danchoo]

I pulled it from git and compiled it on the RPi yesterday with no issues.  I'm not sure why you'd receive that error.

This source code is only RPi work?

I try to activate Windows 7.

Oh sorry, I thought it was obvious. Already wrote it several times it is designated for Linux and works only if you have an SPI interface in your system.

How do you plan to access it from Windows? If you are using some USB->SPI bridge, check some posts above: drinkmorecoffee and others work toward such approaches that will allow to decouple the driver from the OS. In the driver I provided there is already an initial abstraction from the SPI interface: just write your own spi-context module that wraps direct access to SPI over that bridge (cgminer has already support for MCP2210).

I could help with that once I am done with the SW for Bitmine, but I'm sure it will be already done by then.

That's very good news for DYI users like me who use MCP2210.

Use of this product is very easy and the price is cheap.(MCP2210 Breakout Module : 15$...)

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ADM00419


Please make(or help) cgminer for window.

If your Cgminer can be connected to MCP2210 with A1 chip, Many DYI user will be a great help.

[zulunation]

I would like to ask about HW reset signal for raspi. In my version of cgminer is see the following:

Code:

#ifdef NOTYET
	a1_nreset_low();
	cgsleep_ms(1000);
	a1_nreset_hi();
	cgsleep_ms(1000);
#endif

So it is not implemented yet. Maybe it is implemented in a newer version of cgminer?

Another question. Can the lack of HW reset at the beginning be responsible for chip not to reply on the 0x04 (RESET) command?

[zefir]

I would like to ask about HW reset signal for raspi. In my version of cgminer is see the following:

Code:

#ifdef NOTYET
	a1_nreset_low();
	cgsleep_ms(1000);
	a1_nreset_hi();
	cgsleep_ms(1000);
#endif

So it is not implemented yet. Maybe it is implemented in a newer version of cgminer?

Another question. Can the lack of HW reset at the beginning be responsible for chip not to reply on the 0x04 (RESET) command?

It is not implemented because it is HW dependent. You need to have your means of driving RSTn low and 1V8 high. This can't be done generic, since some design will have a level-shifted GPIO, others an i2c driven GPIO port expander, whatever. Every design will need to have its own HW reset routine implemented in the driver.

As for your second question: yes, it was stated from the beginning and multiple times: you need to always start with a HW reset before you try to access the chain. That is not only for startup, but also for regaining access if chip chain got corrupt (which happens with unstable power or SPI communication failures).

[zulunation]

I would like to ask about HW reset signal for raspi. In my version of cgminer is see the following:

Code:

#ifdef NOTYET
	a1_nreset_low();
	cgsleep_ms(1000);
	a1_nreset_hi();
	cgsleep_ms(1000);
#endif

So it is not implemented yet. Maybe it is implemented in a newer version of cgminer?

Another question. Can the lack of HW reset at the beginning be responsible for chip not to reply on the 0x04 (RESET) command?

It is not implemented because it is HW dependent. You need to have your means of driving RSTn low and 1V8 high. This can't be done generic, since some design will have a level-shifted GPIO, others an i2c driven GPIO port expander, whatever. Every design will need to have its own HW reset routine implemented in the driver.

As for your second question: yes, it was stated from the beginning and multiple times: you need to always start with a HW reset before you try to access the chain. That is not only for startup, but also for regaining access if chip chain got corrupt (which happens with unstable power or SPI communication failures).

Thanks for fast reply.
I have implemented low level access to the GPIO pins. Will try tomorrow.

[Tyger]

Is it me or is this a Datasheet bug?, the first is from datasheet and the 2 behind are from the reference design.

http://oi61.tinypic.com/2n0ndwo.jpg

[silver71]

Picture with parts details is at the bottom :   

Here is my attempt to approximate production costs for 2xA1 DIY PCB.

Another thing visible from this list is various different sources for components, from 4 continents...

and...the amount of minimum ordering items to achieve best pricing.

So my estimate is that (best possible pricing based on this parts) for this DIY board :

- without A1 chips
- without assembly cost
- without transport costs, p&p
- without testing costs

...would be arround 48 USD.

Complexity of this board and chosen parts is not low but not too high either.

However, by choosing even better quality of parts, price of PCB would be higher, but reliability would/might
get "announced" turbo-mode possible with no significant damage to the A1 chips with severe overclocking and heat disipation.

The general problem is I suppose in the cheapest components - resistors, with 5% tollerance, instead od 1 - 2% tollerance max.
I know these PCBs are not CISCO routers or likes, but they have to be brute-forced into not usual working envinment - reason for sensitive component selection process, which to my knowledge was a :

- timing for delivery compromise / pricing compromise, which BITMINE had to do, but such compomise could be avoided in nextgen og Coincraft rigs / PCBs, so let's hope things might be improved in the future.

Some problems with delay might be happening because of the fact that some parts are not easily obtainable, or productions specs, simulator specs and real after production testing specs - differ, and PCBs production delay due to above mentioned reasons (because it can not go as advertised up to full turbo speed) is the result.

Key to understanding how this magnificent CHIP (A1) works is temperature issue....on lower operating temperature, everything works perfect, but the problem begun when Giorgio wanted to produce the best righ in tthe world in a very short time, so I propose to solve this thing this way :

a) deliver rigs - as is
b) develop and test driver patches if that can solve the problem in the future
c) carefully select future batch of components.

Those who receive their rigs first, will earn more, regardless of the absence of turbo more.

Those who receive their rigs later will earn less, but, their rigs might have turbo availability, which is curently as Zefir said and I Quote :

":..only going to be logically available in very cold areas of the globe or with custom cooling/submersion."

Full turbo compliant rigs are / might be possible but not in March...this is my opinion.

See just how many parts they have to source from what companies...and how this is a very hard task, because if only one components is missing the whole production stops.

These boards, are however not the same as those going into desk and rack rigs, but, probably are similar, so you must understand the process and have patience...because I think Giorgio is doing everything he can to do the things right...

w w w . a n o n y . w s / i / 2 0 1 4 / 0 2  / 1 7 / B e P d 3 .  p n g  (remove blanks)

Good works guys, keep the spirit high, since Mt.Gox is getting back in the game (payment withdrowals reinstated) on the very same day (saturday), your first rigs are planned for shipping to customers...

Can somebody comment ?

[zulunation]

Is it me or is this a Datasheet bug?, the first is from datasheet and the 2 behind are from the reference design.

http://oi61.tinypic.com/2n0ndwo.jpg

Seems that there is a mistake in schematics. Check the gerbers to be 100% sure.

[zefir]

Thanks for fast reply.
I have implemented low level access to the GPIO pins. Will try tomorrow.

Before you do, just a reminder (otherwise you'll kill the chips): you're aware that all pins are 1V8 - if you are using RPi's 3V3 GPIO you need to have level-shifters in place.

Is it me or is this a Datasheet bug?, the first is from datasheet and the 2 behind are from the reference design.

http://oi61.tinypic.com/2n0ndwo.jpg

Seems that there is a mistake in schematics. Check the gerbers to be 100% sure.

Yes, I received several more bugs via PM, which either means this is not the latest revision - or the HW guys tweaked the board after assembly. Unfortunately the eval board was done by external resources, so it will take time to get fixes back into the repository. I'd assume the community will be faster with that.


General comment for the eval board: I have been asked for permission to rebuild the board and sell it. A related license file was added to the git repository today that explicitly allows for that. But please note: this eval board was developed exactly for that - evaluate the chip and bring it up. Design guidelines re signal integrity, efficiency, thermal, etc. were not taken into account as you would do for a final product. Therefore, please consider the design only as reference but not for field deployment.

[totalslacker]

So perhaps I have a nasty bug somewhere…

I brought up the second board we had built up fortunately everything pretty much just worked - getting spoiled with that happening twice in a row

It still produces the same nonce on your test hash zefir (and it's consistent at a range of clock rates from clock_mux set (12Mhz) to the default PLL at 800Mhz) so I'm pretty sure whatever I'm doing to get this result is outside of the chip.

I have a raspberry pi that should come in tomorrow. When that's here I can hook it up to the spi test headers and validate it against your driver.

In the meantime I cobbled together a really quick and dirty driver for cgminer (based of your bitmine driver) that talks to the micro controller on my board via a UART. It then sends down one item of work and waits for a response (not very speedy!). I get this sort of result in the cgminer logs:

[2014-02-17 18:30:33] BMH_scanwork: nonce=0xbe72021b
[2014-02-17 18:30:33]  Proof: 00000000a670e9d47f911dbe284736a57bb18608989637e1d99b81c8eb3fc1b0
Target: 0000000010000000000000000000000000000000000000000000000000000000
TrgVal? no (false positive; hash > target)
[2014-02-17 18:30:33] Share above target
[2014-02-17 18:30:33] YEAH: chip 0: nonce 0xbe72021b

Is this correct? Should the final hash be below the target (the "false positive" comment is unclear to me). Guess I need to learn more about cgminer

Thanks for any suggestions!

[zefir]

Update: bring-up-howto fixes, real target processing


Fix in reference test-vector
totalslacker, burnin and all who tried to test the chip with the test vector I gave some pages ago: I had a copy-paste error there with the first byte (8c instead of 8d). Can't explain how that happened, but fixed it in that post. Really sorry about that, I hope you did not lost to much time with that but instead tried to feed the chip from cgminer directly.

So for reference, this is the exact SPI trace for the job processed by the A1:

Code:

spi mode: 1
bits per word: 8
max speed: 800 kHz
--
TX: 58 bytes:17 01 8D 1F A3 18 D8 0A 25 2C E4 B7 CD 6D 12 2F 80 8F 17 DC D8 10 04 17 EA 3F E8 F3 71 41 70 F3 
	4B 49 D6 98 8E 01 27 1F 66 52 B6 0A 10 19 00 00 00 00 FF FF 00 1D FF FF FF FF 
RX: 58 bytes:00 00 17 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
	00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Processing command 0x0a01
TX: 2 bytes:0A 01 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:1A 01 
Cmd 0x1a ACK'd
TX: 6 bytes:00 00 00 00 00 00 
RX: 6 bytes:46 C8 21 85 01 20 
Processing command 0x0a01
TX: 2 bytes:0A 01 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:1A 01 
Cmd 0x1a ACK'd
TX: 6 bytes:00 00 00 00 00 00 
RX: 6 bytes:46 C8 21 84 01 20 
Processing command 0x0800
TX: 2 bytes:08 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:18 01 
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00 
RX: 4 bytes:18 8D B1 99 
Nonce: 4 bytes:18 8D B1 99 
Golden**************************: 4 bytes:18 8D B1 99 
Processing command 0x0800
TX: 2 bytes:08 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:18 01 
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00 
RX: 4 bytes:3F 8F 64 DE 
Nonce: 4 bytes:3F 8F 64 DE 
Golden**************************: 4 bytes:3F 8F 64 DE 
Processing command 0x0800
TX: 2 bytes:08 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:18 01 
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00 
RX: 4 bytes:B9 9C C7 09 
Nonce: 4 bytes:B9 9C C7 09 
Golden**************************: 4 bytes:B9 9C C7 09 
Processing command 0x0800
TX: 2 bytes:08 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:18 01 
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00 
RX: 4 bytes:EC C1 4E 74 
Nonce: 4 bytes:EC C1 4E 74 
Golden**************************: 4 bytes:EC C1 4E 74 
Processing command 0x0800
TX: 2 bytes:08 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:00 00 
TX: 2 bytes:00 00 
RX: 2 bytes:08 00 
Output queue empty

What is happening here is:
1) feed the A1 with the given job
2) loop over register read until chip is jobless
3) read out found results

You will notice that you get back 4 results, although the job has 5 winning nonces. That is because the A1 has an output queue of 4 elements, so one of the results is overwritten. To get them all, you need to pull the results early enough while chip is still hashing. Have a look at the reference driver to check how to do this continuously.


Result validity / real target

Is this correct? Should the final hash be below the target (the "false positive" comment is unclear to me). Guess I need to learn more about cgminer

What you get back from the chip is a valid Diff1 share, while your pool is obviously asking for higher difficulty shares. That's absolutely normal, i.e. you will see this trace log with every HW that produces Diff1 shares. cgminer then drops all those below pool's difficulty.

Having Diff1 shares returned is a good feedback for you to know that chip is still alive and kicking. But once you know it works stable, the communication load to the A1 chain can be reduced by providing the real difficulty. I have already implemented this in the driver variant for the CoinCraft and will get it into cgminer upstream, but until I have the time here is the related source code snippet:

Code:

uint32_t get_diff(double diff)
{
	uint32_t n_bits;
	int shift = 29;
	double f = (double) 0x0000ffff / diff;
	while (f < (double) 0x00008000) {
		shift--;
		f *= 256.0;
	}
	while (f >= (double) 0x00800000) {
		shift++;
		f /= 256.0;
	}
	n_bits = (int) f + (shift << 24);
	return n_bits;
}

static uint8_t *create_job(uint8_t chip_id, uint8_t job_id, struct work *work)
{
	static uint8_t job[WRITE_JOB_LENGTH] = {
		/* command */
		0x00, 0x00,
		/* midstate */
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		/* wdata */
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00,
		/* start nonce */
		0x00, 0x00, 0x00, 0x00,
		/* difficulty 1 */
		0xff, 0xff, 0x00, 0x1d,
		/* end nonce */
		0xff, 0xff, 0xff, 0xff,
	};
	uint8_t *midstate = work->midstate;
	uint8_t *wdata = work->data + 64;

	uint32_t *p1 = (uint32_t *) &job[34];
	uint32_t *p2 = (uint32_t *) wdata;

	job[0] = (job_id << 4) | A1_WRITE_JOB;
	job[1] = chip_id;

	swab256(job + 2, midstate);
	p1[0] = bswap_32(p2[0]);
	p1[1] = bswap_32(p2[1]);
	p1[2] = bswap_32(p2[2]);
	p1[4] = get_diff(work->sdiff);
	return job;
}

That's maybe not the easiest way (I'm pretty sure that value is available from cgminer structs somewhere), but for now it works.



Good Luck,
zefir

[totalslacker]

You will notice that you get back 4 results, although the job has 5 winning nonces. That is because the A1 has an output queue of 4 elements, so one of the results is overwritten. To get them all, you need to pull the results early enough while chip is still hashing. Have a look at the reference driver to check how to do this continuously.

Thank you! I had indeed switched over to cgminer but getting the test to run correctly makes me feel a lot better about the status of my hardware.

Interestingly, I get six nonces? The four you post, the one I assume that was overwritten and an extra. Same results for all four chips (haven't tried the second board).

Code:

************** Got nonce! 18 8d b1 99
************** Got nonce! 3a a6 b2 0c
************** Got nonce! 3f 8f 64 de
************** Got nonce! b9 9c c7 09
************** Got nonce! be 7b 58 b3
************** Got nonce! ec c1 4e 74

What you get back from the chip is a valid Diff1 share, while your pool is obviously asking for higher difficulty shares. That's absolutely normal, i.e. you will see this trace log with every HW that produces Diff1 shares. cgminer then drops all those below pool's difficulty.

OK, perfect. I figured the target difficulty wasn't right given it's fixed in the job creation function. I will integrate your new code at some point. Until then, you're correct: getting confirmation of things working is very helpful!

First, however, it's time to do some reliability testing with the test vector

[zefir]

Interestingly, I get six nonces? The four you post, the one I assume that was overwritten and an extra. Same results for all four chips (haven't tried the second board).

That's ok. The reference job was taken from a nightly session where I collected the share log of a BE blade miner and picked up a work item with a high number of winning nonces. It does not necessarily mean the blade found all of them, so if you happen to verify the 6th result as valid, I will add to the related post.

Thanks for feedback and good luck (you're almost there )

[zulunation]

Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?