From owner-freebsd-hackers  Wed Mar  6 09:48:37 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA08243
          for hackers-outgoing; Wed, 6 Mar 1996 09:48:37 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA08238
          Wed, 6 Mar 1996 09:48:35 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA11313; Wed, 6 Mar 1996 10:45:08 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603061745.KAA11313@phaeton.artisoft.com>
Subject: Re: Triton-II support... when?
To: mikebo@tellabs.com
Date: Wed, 6 Mar 1996 10:45:08 -0700 (MST)
Cc: terry@lambert.org, mikebo@freefall.freebsd.org, questions@freebsd.org,
        hackers@freebsd.org
In-Reply-To: <199603052144.PAA02531@sunc210.tellabs.com> from "mikebo@tellabs.com" at Mar 5, 96 03:44:06 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk

> > FreeBSD supports the Triton chipset.  Since the difference between the
> > I and II is the cache bug is fixed in the II, I can't see where fixing
> > a bug could make it not run.
>
> As I understand it, there are much more profound changes than simply
> one bug fix. I've been told that Triton-II:
> o  fixes a write-back cache bug
> o  nominally speeds all memory accesses ~5%
> o  adds support for concurrent PCI/ISA bus accesses
> o  adds support for multi-processing
> o  adds support for ECC memory
> 
> Seems like a *lot* more functionality than can be accounted for by a
> simple bug fix, no? Perhaps Terry means Triton-II implements a superset
> of Triton-I functionality (plus the cache bug fix) so there's no reason
> existing kernel code would break? That's great... I thought perhaps
> there was more purpose to the chipset sensing code in
> /usr/src/sys/pci/pcisupport.c .

If I add a bell to a bicycle, I don't have to relearn how to ride it.

A better analogy would be the FIFO'ed floppy controllers: the driver
doesn't use the FIFO, but that doesn't mean the driver doesn't work.

Or VGA cards for standard resoloutions.

I don't think there will be a problem.  The *one* potential area for
trouble is if the chip ID is different and is used to gate behaviour,
in which case, you will need to dup a line in the PCI bus interface
data and rebuild a kernel.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.