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?