I have a couple of Sharks that have been in the cupboard for a few years and haven't done anything with them. Based on conversations on chat about memory, I decided to get mine out and look at the installed memory. On the Extending memory on your DNARD (shark) to more than 64MB page, there is a note about the type of 64MB DIMM that works in Shark.

One of my Sharks has 64MB of memory and the other has 32MB, so it seemed reasonable to try to find larger memory DIMM's. I also noticed, whilst reading the DNARD User's Guide that some of the GPIO pins on the Sequoia chip set were used for a software generated (i.e. bit-bang) I²C bus connected to the DIMM EEPROM's. The User's Guide also mentioned the pins that were used and the existing sequoia.h header file contains definitions of all the registers. So, it should be easy to check exactly which DIMM's are installed in each Shark.

It turned out to be not quite that easy because the documentation didn't mention exactly how the register settings corresponded to the signals on the clock and data lines. However, after a lot of experimenting with reading the values for various settings, I was able to discover that the critical part is that enabling the pins drives the signal, and that we always see our own signal (which is mentioned for the data line in the User's Guide). This means that we can't wait for the clock signal, as it is instantly set, although this hasn't been a problem in practice.

Because I was looking at our code for the Sequoia chip set in sequoia.c, I noticed that the code there was able to set the front and debug LED's. It was straightforward to add an LED driver to allow these to also be set from sysctl. The only problem remaining was how to hook the IIC and LED drivers into the direct configuration framework. I proposed using the properties framework in a similar way to sparc64, but Jason Thorpe suggested a better way of adding a sequoia device and adding there instead.

-^- More notes -^-

---