Port-arm archive

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

Re: Shark LED and I2C drivers

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”.


> 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?



Home | Main Index | Thread Index | Old Index