[vortex] Tyan Thunder K7 S2462 Dual 3c59x

[Donald Becker]

On Fri, 18 Jan 2002, Bogdan Costescu wrote:
> On Wed, 16 Jan 2002, Donald Becker wrote:
> 
> > Since the driver doesn't know if the EEPROM uses 6 or 8 address bits, it
> > determines the size by either trying to read a location and verifying
> > the result, or sending out address bits and looking for the leading
> > data marker bit.
> 
> Thank you for the explanation. It seems logical... but I don't really 
> understand the code from vortex-diag which implements it, after an 
> afternoon of comparing code and docs.
> 
> Firstly, for 905B, there are only 6 bits of address, so that's fine. For 
> 905C, there can be 2K, 4K and 16K chips (cf. docs), which means up to 10 
> bits.

Hmmm, none of my drivers or diagnostics anticipate a 10 bit address.

> However, page 81 of the 905C PDF says that bits 6 and 7 of the 
> Command Reg are used for the command while higher order address bits are 
> bits 8 to 11.

Errrmmm, take all of the following with a grain of salt.  It's easy for
me to confuse the Vortex driver with other drivers.

After checking I realized that the only 3Com driver that generates the
serial bit stream is the 3c509 detection.  The other 3Com drivers and
diagnostics all use Window 0 register access and let the hardware
generate the serial bit stream.

> There is also a paragraph just above the table that says 
> something about legacy software functionality and some bit swapping: now I 
> don't understand why they mean by this, as the "legacy" hardware didn't 
> have more than 6 bits address space, so legacy software shouldn't be 
> supposed to use more than 6 bits. If this table is correct, then the 
> actual way of handling more than 6 bits in vortex-diag is incorrect, as 
> the command should not be put as the 2 MSB, but always at bit 6 and 7.

I seem to recall that earlier manuals were wrong about the EEPROM
command bit assignment.  The command+address bits were sent out
verbatim.  When the address size changed from 6 to 8 bits,  the leading
two command bits just shifted up in the obvious way.

3Com has independent design teams working on the different chips.  They
started with the same core and documentation, but independently
implemented the same extensions.  It may be that I don't know about some
specific chip's EEPROM implementation.

> Secondly, I don't understand the way of separating 6-bit and 8-bit ones 
> (the "else" branch of the comparison with 0x5555). How can the second 
> comparison (with 0xffff) tell this ?

The code is
	outw(0x5555, ioaddr + Wn0EepromData);
	if (read_eeprom(ioaddr, 6, 0) != 0x5555) {
		if (debug)
			printf(" EEPROM Address length is 6 bits (%4.4x).\n",
				   read_eeprom(ioaddr, 6, 0));
		eeaddrlen = 6;
	}

This just checks if a 6-address-bit read works.  For some chips (read
that as "at least one board, sometime in the past") this worked to find
the EEPROM size.

> > If the address size is incorrectly detected as 8 bits, the driver sends
> > out 8 address bits and only the first six are used by the EEPROM.
> 
> OK, but if the detection mechanism is improved or the EEPROM size is 
> somehow forced, data should be accesible (both read and write), right ?

Correct.  At least for reads.
EEPROMs have different semantics for writes, and I don't know how
consistent 3Com and motherboard vendors are about picking EEPROM
vendors.  Some EEPROMs accept a write command at any time.  Others
require unlocking the chip before writing, or even immediately before
each individual write.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993