Quote from: loshia on February 02, 2014, 07:39:34 AM

Quote from: Cheshyr on February 02, 2014, 05:54:55 AM

So how is everyone handling the cgminer integration?

The https://github.com/bitmine-ch/cgminer branch that Zefir put so much excellent work into is a bit deviant from the https://github.com/ckolivas/cgminer I'd been using. There are features in the ckolivas version that I'd like to use, so what's the standard procedure here? Fork/branch ckolivas version, integrate the A1 bits, then see what it takes to pull and merge it back?

Depends on the design and i/o USB communication protocol. There will be patch fro Technobit I beleive but it will be specific to their design. Actually there is some code released in their latest version

So far it seems I have been the only one using it - if and when the user base broadens, the correct way is to a) clean the code up, b) rebase it on current cgminer head, and c) get it accepted upstream. Since this needs some initial and ongoing maintenance effort, I need to know if anyone is using the driver as-is for own designs.

And that is one point: all designs currently being worked on are based on existing drivers already integrated in cgminer. Take marto74's for example: the uC on the 8-chip board will encapsulate the control of the A1 chips and to cgminer that board will look like any other HEX based one, fully accessible with the existing driver. Same goes for WASP, burnin, intron. My driver is meant to attach to a system's SPI port directly and most probably will serve only as template for full featured drivers or initial testing.

Quote from: totalslacker on February 01, 2014, 09:20:07 PM

So I'm in the final stages of PCB layout here (hoping to release the board today or tomorrow). Still one question is pending however: are there any sequencing restrictions on bringing up the IO/analog and core voltage supplies for the A1? I'm currently planning to bring up IO, then the core supply - will this be ok?

I've asked Bitmine as well and the question has been forwarded to engineers but no reply as yet.

There are no related restrictions documented or known and I am not aware that anyone from the working designs is keeping some defined bring-up order. The only requirement documented is the reset sequence (1s low, then 1s high before first command is sent).