I don't get it, why is the program called I2Cset when the chipset doesn't use I2C but rather SPI?
I believe there is an i2c to SPI bridge, which would explain the need for both and why they are both detected.
I am still understanding those aspects a bit more as I am finding I need the information to make potentially bring the boards back to life.
http://www.i2cchip.com/mix_spi_i2c.html is one resource (of many I found)
The good news is that it
might be possible to bring the cards back provided I can find the right command to bring them back. The AMT-setup dpot command (in my previous post) do not appear to work at all as they are coming up with an invalid value. That just means it doesn't work. I am reading through the AMT script to understand the issue.
As you can see in the above I get [OK] Error: Data value invalid! is a sign that the code might not be correct. OR something else is wrong. Hopefully AMT can clear this particular piece up.
The card on the chain is found so that's positive. BUT the command to set it is invalid (bad). I know at this point I have 7 cards that are potentially zombiefiable (new word to add to webster dictionary), I have 3 working cards (not messing with that) and 1 totally dead card that will prevent any sort of power up (need to check it for shorts)
On the hardware side I tried something based on ISAWHIM's mention of the potential board short from the PCB touching the metal cage. I taped up the edges where the cards contact the metal I had hoped on a long shot that might actually bring up a card or two, but no dice
That said least now that is a potential issue that is mitigated. I think the boards COULD be brought back with software. Maybe not all but some of them. The fact that the i2cset commands was not actually taking because the value was invalid would be a good reason why this happened. I am currently testing now with AMT's default firmware before I move on to the porting process (which I have partially done). I figure it might be best doing it with what is already available before reinventing the wheel. If I get the cards back up then I will proceed with the next steps of porting over to the new firmware.
I think there is progress tho seeing as the cards are detected but nonfucntional at this point. Hopefully not beyond the point of recovery.
EDIT: To add I am working on the i2cset commands to do all this manually if I have to (not something I recommend to anyone not experienced in this sort of thing), and seeing how the script interacts with that. If I can manually do this bypassing the script I will modify the existing scripts to issue the correct commands and add comments in the scripts for proper use. Its fairly trivial to add the usage part. That might actually get the hardware working. While the progress is slow (in my opinion) its progress that's happening. My time is limited so I really only put in a couple hours a day on this at most.