Integrated into the current cgminer version via the A1 SPI driver today. Some thoughts:
HW_RESET via Pi's GPIO needs elevated privileges and is hardware specific, so I prepared a separate binary for that. Currently HW_RESET is only done once at start, hopefully doing it this way won't be a problem.
The reference board doesn't really have any kind of detection mechanism other than probing the SPI bus, so the board selector is stubbed out.
Also, I was thinking of modifying the set_pll code so that the fb_div never drops below 100, would this be of use?
I'm not sure if these changes would be accepted into the main cgminer branch, since they are not for a commercial product, but if there is any interest, I'd be happy to share the code.
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).
I can also confirm that a single chip A1 board did not function by itself. It replied to soft reset, but refused to be enumerated. It functioned fine when plugged as chip-3 into a 2 chip chain, though.
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.
If any of you DIYers get to the point of starting up cgminer, give me a message and we can have a two user userbase
The devspi should be a usermode driver, so there shouldn't be a need for root. At least that's what I have observed in my adventures. GPIO (on the Pi) on the other hand is usually mmaped to lower memory, thus the best one can do is to drop privileges as soon as the mapping is established, but that would still mean starting as root. I believe this was the reason that legkodymov's bitfury driver from sometime last summer did not get incorporated into cgminer proper. But perhaps I am mistaken and there is a way to do this, in which case I'd be very happy to learn about it.
I realize that running at 100MHz is kind of silly, but one use case I can think of is if you don't have a working cooling solution but really, really want to start hashing tonight
or allow self to keep working while bigger fans are on their way.
One of the boards me and mazurov built had only one of two chips on it, and jumper W1/W2 was soldered in "perpendicularly" to close the MISO and MOSI. Unfortunately, I did not save the log, and that particular board has made the ultimate sacrifice in the time since
The testing was done with the simple test prog that I posted earlier, and now that I think harder about it: the chip replied to SOFT_RESET, replied to BIST_TEST (showed up as one chip chain), and I believe it replied to BIST_FIX. Now, IIRC, it did not respond to the READ_REG command that followed if it was alone, but did respond as expected if it was plugged in after (using the chaining plugs) another board as chip 3.
