Re: Shark LED and I2C drivers

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi all,

> > > I have a slightly different version of this change merged into my
> > > local tree… I’ve created a separate “sequoia” device_t node that
> > > attaches at the “isa” OFW package, and then connect the
> > > Shark-specific (and very Sequoia-dependent) “sharkiic” as a child
> > > of “sequoia”.  “ofisa” is then also attached as a child of
> > > “sequoia”.

Thanks!

>
> As promised I dusted off the R4 shark, here's what it looks like:

> total memory = 98304 KB
> spdmem0: 11 rows, 10 cols, 2 banks, 2 banks/chip, 10.0ns cycle time
> spdmem1: 12 rows, 9 cols, 1 banks, 4 banks/chip, 7.5ns cycle time

> I never found a combination of RAM modules that would give me 128MB,
> but now I can at last see the differences in organization :)

From other threads, it seems that the important part is the "2 banks", as
the Shark doesn't handle more than 32MB per bank.

> Will try the LEDs stuff next.

I've updated the patch to look more like the current IIC code:

  http://ftp.netbsd.org/pub/NetBSD/misc/jdc/shark/shark-led.diff

And, from an older message:

> Seems like we could handle the “looks like SPD, but has a zero checksum” in a
> pretty reasonable fashion in “spdmem"

I think that we could ignore the checksum, and display the information with
a warning.  However, from looking at the contents of the SPD EEPROM when
seeprom attaches, the part numbers were more useful to me to search for
similar RAM.  I wonder if we should extend spdmem to display that in
addition to the other information?

Regards,

Julian