Port-arm archive

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

Re: Shark LED and I2C drivers

On Mon, 3 May 2021, Julian Coleman wrote:

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


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:


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?

Full decode of the spdmem ROMs is available from sysutils/decode-dimms
package.  :)

| Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
| (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |

Home | Main Index | Thread Index | Old Index