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.

Please read my related post: https://bitcointalk.org/index.php?topic=294235.msg6536840#msg6536840


Aside from that, if you are struggling with technical problems or want to discuss them, you should visit the above A1 DIY thread with better chances to meet other developers and get your issues resolved.


Cheers,
zefir

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.

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).

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.

Well, this is a political topic meanwhile and I can not disclose as much as I would like for now. But I can tell you that this is a perfect example on how idealism was killed by bad business ethics and greed.

As this thread indicates, being open source was mine and Bitmine's goal from the beginning. As you note, the idea was to make everything public and get compensated for the engineering efforts by increased chip sales. Obviously this only worked as long as we were sure that the chip engineering contract will be respected and Bitmine remained the exclusive distributor of A1 chips. The rest of the story is well known meanwhile: chips being sold directly into the market, mass production of mining products driven by foreign open source SW, disruption of mining market.

Don't get me wrong: open source is the way to go and pays off in most cases. In my day job it took me 5 years to convince my boss to go open source and it took another 3 years to notice an economical gain for giving our work away for free. What you get back is free testing / bug fixing and maintenance, leading to a long term higher stability for long-living products. And that's the key killer argument for open source: long-term.

In our bitcoin world things are different: I am not aware of a single mining product that ever passed the prototype state - with a typical lifetime of 3-6 months there is simply not enough time to mature. Consequently, open source (at least for now) can't be economically profitable for the publisher if he has no means to prevent free-riding and plagiarism.


This went slightly off-topic, and despite all said, keep up your open source spirit - it will pay off some day.

The approach you are describing is similar to what I implemented as a calibration tool. It consists of a dummy cgminer that feeds the chains with reference test vectors and collects per-chip statistics over the complete parameter range. Ideally, the output of such a calibration run would provide you the optimal settings for each chip for a given power consumption / hashrate target. Unfortunately those statistics showed the unreliable characteristics I described above.

As for your high-level approach, two components to consider:
a) voltage control is completely done outside of cgminer over i2c-tools. Accessing the voltage regulator gives means to damage the chips, so for liability reasons I need to check first if and under which conditions I can publish the relevant information.
b) you are right, there is no per-board or per-chip configuration support in the A1 driver currently. This is considered useless for now, since it would lead to a configuration hell (like you don't know which slots are populated in your product and how to assign them individual configs).

If you are familiar with the cgminer source code, you can help yourself with b) easily by implementing an extension to the --bitmine-a1-options parser to consider sys_clock not as a global value but as a comma separated array and provide individual clocks for each board. For this you obviously need to be able to build your own cgminer binary, i.e. replace Bitmine's FW with a full RPi distribution including build tools. With some related howto posts in this forum this should be easy.

Good luck.

Hi,

are you talking about a DIY design, or Bitmine's CoinCraft?

First to your generic question about PLL: yes, you can set the PLL individually for each chip. In the current driver, at initialization phase lower grade chips (those with a reduced number of working cores) are already set to work at lower speed (check https://github.com/ckolivas/cgminer/blob/master/driver-SPI-bitmine-A1.c#L403). The same mechanism can be used to 'optimize' individual chips in a chain.

Assuming you are operating a CCD 400, the response to the temperature sensor is as follows: temperature data is not meant to be accurate enough to be used for optimization. In the CCD, there are up to two 1-wire sensors attached to the back heat-sink of defined boards. Sensors are not accessed from cgminer but from within a polling system daemon that uses the monitored data to stop cgminer on overheat.

I don't want to demotivate you, but what I can tell you is this: over the past ~3 months I worked intensively on auto-tuning mechanisms and have to admit that I did not came up with something useful. There is a bunch of inter-dependent system parameters (chip grade, supply voltage, clock, etc.). While itself not trivial, the dependencies are neither static (e.g. change with temperature) nor linear nor continuous. Sometimes they are even not deterministic   With that, for me it looks almost impossible to provide some generally usable auto-tuning mechanism.


Nevertheless, I wish you best of luck and would gladly see your code contributed upstream.

The driver code accesses the chips directly over the Linux spidev user space SPI driver (Win not supported), the layering goes like: spidev -> spi-context -> A1_chip -> A1_chain -> board_selector

If you need to replace direct SPI access through some USB->SPI bridge, your best take is to replace the existing spi-context.c file with something that provides the spi_transfer() function to do a full duplex data exchange with the A1.

Same goes for the upper layer: if you want to use the driver as is, you need to implement a board selector for your product variant. It needs at least to provide a reset_all() method which should issue a HW reset to all chips of a selected board.

Let me know if you need further assistance. I tried to implement the A1 driver in a way that allows to cover a wide range of variants and would like to keep it generally usable - in contrast to e.g. having slightly modified copies of existing ones (e.g. BitFury) for every variant out there. If something is missing to support your variant, please let me know.

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.

No, that is for sure not ok. As a rule of thumb, I would classify the chips as follows:

• grade A: 31 - 32 working cores: run at full speed
• grade B: 26 - 30 working cores: run at reduced speed (50-80% of nominal), bears low risk to disturb chain
• grade C: 25 and less working cores: disable chip (or enable only after proper inspection), bears high risk to disturb chain

Alas, I have never seen a chip with only one working core so far. Are you sure your power supply is stable at ~850mV and you assert reset for ~1s before you issue the BIST command?

This is the same issue we observed with the Platimax 1500W: some PCIe connectors share the same rail, with that you are feeding two hashing units over the same rail and overloading it - the Platimax uses to shut down after a while. Since the Lepa's PCIe pinout looks similar to that one, here is the correct way to set up your CCD with the chosen PSU:

1) take a look at bottom of datasheet page 2 (http://www.lepatek.com/files/LE_ProductBasic_eng/PB_File/G1600-EN.pdf)
2) notice that the distribution of the 6 12V rails is as follows: 12V1:MB, 12V2:MB, 12V3:PCIe1+4, 12V4:PCIe2, 12V5:PCIe5+6, 12V6:PCIe3
3) ensure that you connect 4 hashing units to PCIe connectors 1, 2 , 3, and 6 (left 4 and 5 unconnected)
4) buy or build yourself an adapter from MB-20 (12V1) or MB-16 (12V2) connector to PCIe and feed the 5th hashing unit with that

Bottom line: ensure to feed only one hashing unit through one 12V rail. Even if the PSU uses a common rail, powering two hashing units through a single rail will either cause voltage ripples or over-current protection shutting down the PSU.


Good luck

Please contact support@bitmine.ch for 1st level support. The support staffing was improved recently, response time should be quite good meanwhile.

I am not part of the management and as such not involved in the daily business. When I knew more and posted it here, people took my feedback and misused it for legal actions against Bitmine, which in the end rendered transparency very expensive. Since I am open by nature and dislike keeping track of what I can disclose and what not, I asked Bitmine to withheld any information from me that is not meant to be shared publicly. With that, effectively my knowledge about delivery and progress status is the same as everyone's else here.

Nevertheless, the SW part I am working on is something I can provide - hoping it is informative only and not suited to harm Bitmine even more.

The 2nd revision of the CCR board was build around a STM32 uC who acted as a proxy to distribute the SPI traffic from RPi to two 6-chip chains. This was basically done to cascade the processing and shift load from RPi to the uC. The core issue addressed was to ensure RPi can handle the large amount of chips in a CCR system. From operating the CCD we learned that a RPi is sufficient to operate a fully populated CCR; from testing rev2 boards we also learned that the STM32 has its own limitations (like issues when running i2c in parallel with 3 SPI buses) and over-complicates system design for a limited gain. Therefore, the rev3 board abandons the uC approach and instead uses an SPI multiplexer to map the up to 16 chip chains to RPi's SPI bus directly. With that, from the SW side a fully populated CCR consists of 16 6-chip chains - which is way better controllable compared to a STM32 based proxy.

I finalized the driver for the new CCR board last week and will push it upstream as soon as I know the productization step went fine. And that is the key point here: I tested the board under lab conditions and it worked as expected (nominal + 20% over-clocking). But operating a single board attached to the PSU with chilled cooling is one thing - stuffing 8 of them into a closed case, fed by a single PSU and operated at arbitrary environmental conditions is a completely different story.

I wish I had enough confidence with the results observed to give an estimated shipping date, which most of the users here badly deserve. But I (and also Bitmine management) were tricked often enough to announce products' availability based on working prototypes - and we all know the outcome.


HTH

Info: Clarification on HW errors / hashrate

I got the below SW support request via PM which I think is relevant for other DIY projects and therefore want to respond here publicly.


Hello,

a diverging hashrate at pool and cgminer simply means you are losing shares through HW errors.

What you need to consider is:

a) a detected HW error also implies that there were errors on true results; the related probability needs to be derived correctly, but I would assume that when you have a HW error rate of 5% it also means you are missing 5% of real results

b) the A1 uses real target, that is, if your pool sends you diff256 work, A1 filters any result witch lower difficulty. In that case, generating a HW error is (at least, needs correct mathematical analysis) 256 times less probable (since you need to generate a wrong diff256 share) therefore you won't see many HW errors with increasing difficulty. Equivalently, because of a) HW errors will cause loss of wrongly calculated real shares.


The current cgminer driver for the A1 is meant for a field deployment where optimal hashrate was measured before and PLL is not tuned by users. If you need to have some meaningful feedback on HW errors to tune your system, you can achieve this easily by letting the A1 report Diff1 shares. For that, you basically need to prevent setting the real target for the jobs with this patch:


Good Luck

Yes, seems to be for US customers only: with the link in post #3, when I select the Bitcoin payment method, the right hand info showing up says:

I think the naming for post and pre divider were reversed in an earlier version of documentation / software, but basically yes, this should set the sys_clock to 250MHz.

If unsure, you always can double-check by scoping the inter-chip SPI clock, which is sys_clk/64, so at 250MHz you should get ~3.9MHz.

Note: take care to configure your host SPI clock below the inter-chip SPI clock, i.e. in this case configure your RPi SPI interface below 3.9MHz.

Well, that's the standard problem with unstable power blocks: once you feed the chip with work, it starts hashing and with that consuming serious power. When that happens and your DCDC is not capable to provide the required power, the chip resets itself.

You need to scope your supply voltage and the reset line; then you should be able to notice significant voltage drops below critical values (800mV supply, 1.6V reset).

Once the chip resets itself, it gets inaccessible and you need to re-issue a HW-reset and send initialisation command sequence again.


Hope this does not demotivate you, but getting this issue stable was the hardest part with the boards at Bitmine.


Good Luck

In fact it is also valid in the context of physics exams: since 1J=1Ws, W/GH/s is equivalent to J/GH

There is a very detailed post from DaT on the forums going into details (can't find it just now), but yes: AM's rev3 is at least twice as energy efficient as Avalon's rev3 (if expected values can be reached).

That needs to be forked from someone actually having that kind of hardware (I don't). The driver that is in cgminer upstream repository is specifically for the CoinCraft Desk modules, every derivative will need to have its dedicated driver.

Clarification: SPI Processing shorter Chip Chains

I have been approached by users having difficulties to operate their designs with the official or reference cgminer driver.

Here is the SPI trace provided:

To understand why polling for the ACK (i.e. reading 0x90 00 from the chain) fails in this case, consider how the current implementation accesses the chain:
1) write a command to the first A1, which with every next dummy write is shifted to the next A1
2) to get an ACK, shift the data through the chain until you receive the expected return values

The reference implementation in a first step writes the command and in the second polls for the result. This works with longer chains, but in this case (with 1 or 2 chip chains) fails because the response is obviously returned already while the command is still written.

To circumvent the issue, one needs to search for the ACK already in the RX buffer of the command write step. In the upper case the correct processing would therefore be:
1) write 8 bytes for command 09
2) in the RX buffer search for the ACK (here at position 5)
3) determine how many more words need to be polled for the full ACK (here 2 more words) and do the poll


Unfortunately I have no single chip chain available to test and implement this, but it obviously is no rocket science and should be easily done.

I pointed Bitmine management to your post for clarification and got following official feedback.

This is a transport damage and covered by related insurance.

If the damage is cosmetic or easy to fix (like re-plugging cables or tighten screws), customers might want to give a try. Otherwise, please contact customer service to get the issue resolved. Support currently has a backlog for around 3 working days. Also, please document the damages with photos and provide them with your request for handling the insurance and improving the shipping process.


Thanks and good luck.