[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Shark LED and I2C drivers
> On Apr 28, 2021, at 11:15 PM, Julian Coleman <jdc%coris.org.uk@localhost> wrote:
>> 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:
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”.
> Looking a bit further in the Shark OFW, there is an SPI EEPROM, driven via
> bitbanging the gpio pins . 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 , but
> the checksum field is 0. We verify the checksum in the spdmem driver for
> older memory types  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?
Seems like we could handle the “looks like SPD, but has a zero checksum” in a pretty reasonable fashion in “spdmem"
Main Index |
Thread Index |