Quote from: totalslacker on February 11, 2014, 06:37:16 PM

In the A1_scanwork function I see the following code:

Code:

hexdump("A1 RX", a1->spi_rx, 8);
if ((a1->spi_rx[5] & 0x02) != 0x02) {
work_updated = true;
struct work *work = wq_dequeue(&a1->active_wq);
assert(work != NULL);

I assume this is checking a "work done" flag in the register, however I don't see this bit defined in the data sheet?

Actually, while I'm here it also seems that the driver code is setting the PLL values differently than in the data sheet. The code sets pre_div to be the first two bits in the register data whereas the data sheet defines it as being bits 44:40. Is the data sheet wrong or am I just reading this incorrectly?

Both

I must have started developing the driver based on an initial version of the specs and did not modify naming to the updated ones. Will be fixed in the driver I'll provide for upstream integration.

As for the 'work done' flag: this is something I found out tracking the register (already described somewhere in this thread) and which is currently being worked on to get integrated into the data sheet update by Bitmine. They are currently in the final steps of ramping up production, so please be patient for that.

Quote from: jrkalf on February 12, 2014, 09:02:39 PM

Will the A1 driver you've written in your github be ported back to the main cgminer development?

This was already addressed in this thread somewhere. Generally: yes I plan to push it upstream and also remain maintainer of that driver. Since that involves quite some initial and ongoing efforts, I need to be sure that it is useful for other projects. Right now, all projects I know do not communicate directly to the A1 but use FW to wrap control over the chip chain from some uC. At the same time, it turned out that for driving Bitmine's products it was required to add lots of HW specific code (like for programmable potis, i2c multiplexers, voltage regulators, temp sensors), so that I doubt the specialized drivers will be usable for anyone beside Bitmine. Here my approach is to wait and see other direct SPI based designs and modularize the driver in a generic part (basically what is already out + some cleanups and updates) and derivate code.