Re: Fresh APUS install - questions

[<fh...@at...>]

In <Pin...@ms...>, on
09/13/00 
   at 11:06 AM, Alan Buxey <al...@ms...> said:

>hi,

>> I have worked on a driver off and on for awhile.  I haven't got it to 
>> work at all yet.  I'd like to see the patch.  It may be the same file that
>> I have, 53c770.tar.gz.

>what is peculiar about this...well, to me anyway, is that Ralph Schmidt
>(laire) seems to class the BPPC and CPPC SCSI controller as the one and
>same same in his documents for MorphOS. They have different chip
>revisions and types, but i wonder if the CPPC SCSI has some compatability
>subset of the BPPC SCSI?

AFAIK the BPPC chip is the 53c710 and CPPC chip is the 53c770.  The 53c770
chip, if I understand the docs correctly, is electrically, a drop in 
replacement for the `710 chip.  The couple emails I got from Ralph seemed
to imply that the BPPC and CPPC SCSI subsystems were
layed out identically with respect to the memory and so forth. Now this
makes a whole lot of sense to me as there would seem to be no good and
practical reason to make them different.

The difference in the SCSI chips is primarily in the way they are
programmed. The 710 chip is programmed like ...(I don't know), and the 770
chip has more in common with it's PCI siblings; the 825/875 (815?) chips.

A message I read on the NET somewhere said that a 710 driver could be made
to work with a 770 chip in about two weeks.  Probably assuming the person
doing the conversion was an experienced SCSI programmer. I think looking
at modifying the 710 driver would be a worthwhile project, but others on
this list disagreed.  My reasoning for this is that the bus, ZORRO
interface, and memory allocation code is already written and should
require much debugging.  One should only have to concern him/her self with
the differences in logic between the two chips.

The other way is to look at modifying the sym53c8xx driver that,
evidently, is used on the vast majority of Linux systems with the LSI SCSI
cards.  The driver code I am playing around with is an old version of that
driver.  This driver is actively developed/debugged and supports the most
modern features of the latest chips.  It has also been ported to 2.3 and
2.4 kernels.  What one would have to do there is put in the Amiga
interface code and tweak it for the differences between  the 8xx chips and
the 7xx chips.   Actually I have been thinking about  working on that
driver instead of the code I got.  I have no idea if the  code I got ever
worked properly on any system, and I would prefer not  to have to debug
code I don't have too.  Additionally, no one seems to  have or volunteer
any information about the code I have.

One hickup I am having at the moment is that the SCRIPTS processor in the
770 chip is identical or very much like the SCRIPTS processor in the 8xx
series of chips and expects the SCRIPTS code to be little endian like the
PCI chips.  It seems the chip, when in big endian mode treats registers
and memory addresses as bigendian, but nevertheless expects the SCRIPTS
code to be little endian.  This would seem to imply that the same SCRIPTS
code that works on the intel based systems should work on the 770 chip. 
From an engineering viewpoint this seems to make sense as a good approach. 
i.e. no significant  changes required to already written and debugged
SCRIPTS code.

The approach I would take for modifying the sym53c8xx driver is to try to
substitute routines for the chip bus interface access that mimic  the PCI
routines that are already there.   I have no idea if that is  practical
but it seems to make sense.  This is sort of what the approach is in the
53c770 driver I have.  i.e.

void some_pci_routine( struct scsi ... )
{
#ifdef ZORRO
 /* do Amiga based interface */
#else
 /* do the PCI thing */
}

Another thing I have found is that there is a Sun model that evidently has
a 770 based SCSI card (S-BUS?) that is working.  The Sun systems are big
endian, like the PPC/680x0 systems that the Amiga shares.

The last thing is that there is a working SCSI driver for the CPPC/BPPC
SCSI in the NetBSD distribution, though it is 680x0 based at the moment.

The bottom line is that there is no real reason that there is not a
working driver for the CPPC SCSI other than that no clever person or
persons has done it.

Fred