Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Shark LED and I2C drivers


> I'm going to merge this into my thorpej-i2c-spi-conf branch.  I am trying to reduce the proliferation of "add more child devices in dictionaries", so I'd prefer they don't land in the trunk in current form.

I've updated the patch for the config changes:


Looking a bit further in the Shark OFW, there is an SPI EEPROM, driven via
bitbanging the gpio pins [1].  The pin configuration is available from the
Forth words too, so it should be possible to use it via a bit-banging SPI
mode 0 driver.  However, this is already in the OFW tee, so doesn't need
us to add additional devices.

> > Seeprom attaches because the DIMM's are not SPD-compatible.  I was however,
> > able to inspect their contents using:
> > 
> >  for i in 0 1; do dd if=/dev/seeprom$i bs=256k count=1 | hexdump -C; done
> > 
> > and see that it has 2 Samsung KMM366S203BTN-G2 (16MB PC-66) DIMM's installed.
> Where is the documentation for the eeprom data format?\

In this case, the DIMM's are almost following the SPD specification [2], but
the checksum field is 0.  We verify the checksum in the spdmem driver for
older memory types [3] so fail to attach here.  I did wonder if we should
also handle the zero checksum with a warning, but it seems a rare case.  It
would allow us to just have the spdmem driver though, so save some memory.
Maybe having seeprom commented out in GENERIC is a reasonable compromise?



[1] There are actually 2 EEPROM's - 1 for the MAC address, one for NVRAM and
FW, and it's possible to run the Forth commands and via the GPIO registers:
  dev /vlbus/isa/gpio@i3e0
  see select-uid-eeprom | select-fw-eeprom | set-cs | set-bit | set-clock |
  : dump-reg 0 begin dup . dup gpio@ . cr 1 + dup 8 = until drop ;

[2] See the JEDEC pages or:

[3] https://nxr.netbsd.org/xref/src/sys/dev/ic/spdmem.c#201

Home | Main Index | Thread Index | Old Index