On Sun, 16 Jul 2000 [EMAIL PROTECTED] wrote:
> I'm trying to make a rather old version of the 53c8xx driver work on an
> Amiga PPC system that uses a 53c770 chip. The way I understand Symbios
> chip is that the 53c770 chip is very similar to the 8xx chips as far as
> features. The main difference is that the 770 chip is designed to hook
> directly to a CPU bus instead of the PCI bus. After spending a
> considerable number of hours trying to get the driver past the cache
> (ncr_snooptest) I have come to the conclusion that I need more
> understanding on the general principals of the way the 53c8xx driver is
> organized.
The 53c770 has lots of similarities with the 53c8xx series. It looks like
a 53c875 without LOAD/STORE instructions. But there are differences in
the IO register layout. I looked into the 53c770 manual a couple of
years ago, but unfortunately, I forgot everything.
It is probably possible to adapt the ncr53c8xx driver for it to accomodate
the differences of the 53c770, but for the driver to work with the 53c770
there are some requirements. For example, 32 bit memory aligned accesses
are required to be performed atomically by the chip from the BUS.
> One question that comes to mind is that concerning the "np" data
> structure. This appears to me to be the access point to the SCSI chip
> registers.
The chip IO register can be accessed using IO or MMIO. On PPC, the driver
uses by default some brain-deaded IO emulation, since it was this way that
this could be done when the driver has been adapted for the PPC.
We should nowadays use explicitely MMIO. If I had a machine for testings,
this would have been done.
The "np" structure contains sort of handles usable for IO or MMIO. For IO,
it is some port address and for MMIO it is a the BUS physical address,
that points to the IO register window, remapped to a virtual address
usable by the kernel (if needed).
> If the alignment of the structure in memory is off how would
> this affect the reading and writing of values into the chip registers?
The "np" structure is normally well aligned.
> The reason I ask, is that when the driver puts the "pc" value into the
> DSP register it is bf2fe50, but when the value is read back out it is
> "bf2".
Weird ... 16 bit reversed in a DWORD + 16 bit lost.
Or the BUS access reads 16 bits instead of 32 bits.
> To my logic it seems that either the correct value may not have
> got into the register due to an alignment problem, or the read back value
> cannot be guaranteed to be
> correct due to properties of the particular register.
If you write 32 bits at a given IO (MMIO) address and read back the same
location and width, you should get all the 4 bytes, possibly in a
different order if the glue that does IO is not endian-consistent.
> Yet a third concern
> is am I reading data from the chip or just values in the np data structure
> in main memory. Consequently, this problem is also making me think in
> general about the "np" data structure. and its relationship to the SCSI
> chip registers. At the begining stages of the driver startup the actual
> device information seems to be copied into this data structure. Then
> magically this data structure is used to "run" the SCSI chip and hold
> pointers to the scripts that the processor will use.
Each controller has its own SCRIPT instance that is linked with the
controller data structure. Basically, each SCRIPT instance reads and
writes data to/from the data structure of the controller it is linked
with.
> From looking at the
> Symbios manual it looks like the SCSI chip "knows" about this structure
> and accesses it itself. What I want to know is am I on the right track or
> totally confused.?
> Since this driver is not on a PCI bus, how is this going to complicate
> things? Is the driver code set up to include this deviation?
Excepted for the requirement of 32 bit memory accesses (or 16 bit inside a
32 bit DWORD) to be atomic and the same requirement for MMIO accesses from
the CPU, the driver should not prevent the 53c770 from being supported
given proper changes (possibly large and not simple) in the code.
> In summary, I am interested in any helpful comments or pointers to
> information that may help me. If I have any success I plan to try and
> merge my changes into the main Symbios 8xx driver,
There is no "main Symbios 8xx driver", AFAICT. But the 53c7,8xx driver,
the 53c7xx driver(S) or the sim710 driver are probably easier to adapt
to the 53c770 than the ncr53c8xx driver.
G�rard.
> Fred
>
>
> This is the information of how the controller looks in memory:
>
> MyController =(struct RegFrame_Sym770*) 0xf40000;
> MyController =(struct RegFrame_Sym710*) 0xf40000;
>
> chiplayout like described in the symbios books
>
> #define IPL_BASE 0xf60000
> #define ADDRESS_REG_RESET (IPL_BASE + 0x0)
> #define REG_RESETF_SETRESET 0x80
> #define REG_RESETF_SCSIRESET 0x1
>
> #define ADDRESS_REG_IRQ (IPL_BASE + 0x8)
> #define REG_IRQF_SETRESET 0x80
> #define REG_IRQF_SCSIIRQSELECT 0x4
> #define REG_IRQF_IRQENABLE 0x2
> #define REG_IRQF_SCSIIRQ 0x1
>
>
> This is the output of some printks:
>
> Trying to detect PuP SCSI...
> ncr53c8xx: 53c770 detected
> ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12
> new NCB[2924] @c3f35000.
> Storing input
> new SCRIPT[3772] @c3f34000.
> new SCRIPTH[3708] @c3f2f000.
> np: ID: 770 REV: 0 FEA: 15382 CLCK: 5 OF: 10
> Initialize timer
> paddr: f40000 paddr2: 0
> io_port: 0
> Peparing...
> stuff: 0 0 0 0 1
> set verbose:
> myaddr: 0
> myaddr: 0
> myaddr: 7
> ncr53c770-0: ID 7, Fast-20, Parity Checking
> verbose:5
> ncr53c770-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex)
> 00/00/00/00/00/00 ncr53c770-0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 =
> (hex) 05/82/20/00/08/24 no on-board ram
> NCR_IOMAPPED
> BIG_ENDIAN
> scripth: c3f2f000 p_scripth: bf2f000 script: c3f34000 p_script: bf34000
> Resetting for snoop test
> offset: c
> istat: 0
> SCSI reset
> istat: 40
> istat: 0
> virt_to_phys(np): bf35000
> np: c3f35000
> ncr_cache: 0 pc: bf2fe50
> nc_dsp: bf2
> ncr_snooptest(): CACHE TEST FAILED: timeout.
> CACHE INCORRECTLY CONFIGURED.
> ncr53c770-0: detaching...
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
