Quote from: [gadget] on May 02, 2014, 10:08:21 AM

Quote from: zefir on May 02, 2014, 08:50:01 AM

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.

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?

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.