[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Shark LED and I2C drivers
> > > 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?
Main Index |
Thread Index |