home *** CD-ROM | disk | FTP | other *** search
/ Amiga GigaPD 3 / Amiga_GigaPD_v3_3of3.iso / netbsd / docs / mailinglist-archive / 1993-08 / text0026.txt < prev    next >
Encoding:
Text File  |  1993-06-25  |  4.0 KB  |  83 lines
  1.  
  2. Someone sent me this - use it if it's useful.
  3.  
  4.     ================= Begin forwarded message =================
  5.  
  6.     From: fontana@di.epfl.ch (" ")
  7.     To: aa457@freenet.carleton.ca
  8.     Subject: AM33C93/A
  9.     Date: Tue, 03 Aug
  10.  
  11.     
  12.     Hi !
  13.     
  14.     I'm programing a driver for Smaky (ever heard about?) which rely on the
  15.     AM33C93/A chip. A friend of mine told me you spoke with him about the bugs
  16.     of that controller. Could you tell me in few words what's the problem and
  17.     how it can be avoided ? I mailed to the guys whose names were mentionned
  18.     in the README files of the BSD source, but none of them knew about the bug
  19.     or the workaround. Also, do you know people using the B/C release ?
  20.     
  21.     While working with the AM33C93/A, I found out that the internal state machine
  22.     is NOT updated properly, which causes the controller to generate interrupt
  23.     that give WRONG informations about what's happening. Here are a few examples
  24.     and how I solved the problem.
  25.     
  26.     1) An Unexpected Status In phase interrupt is generated after a data in phase.
  27.        This happened after the synchronous negociation, during an Inquiry command.
  28.        I checked out and found no error (5 byte to transfer, 5 bytes transfered,
  29.        0 byte left in the Transfer Count Registers), and therefore simpy get the
  30.        status as normally.
  31.     
  32.     2) During synchronous negociation, the AM3393/A went wild... When the first
  33.        byte of the negociation occured, a Terminated interrupt was generated,
  34.        which is correct since there was a SelectAndTransfer command executing.
  35.        In answer, I get the first byte of the message. A Pause/Aborted interrupt
  36.        is generated to allow the driver to read the message before accepting it,
  37.        which is still correct according to the specifications. Knowing now it's
  38.        an extended message, I start another Transfer Info (single byte) to get
  39.        the size of the tail of the extended message. Then, instead of generating
  40.        another Pause/Aborted interrupt after the second byte (as for the first),
  41.        a Service Required Interrupt is generated !!! Then, the 33C93/A used to
  42.        generate some Pause/Aborted Interrupt and some Service Required Ints. I
  43.        guess it's a problem of timing
  44.     
  45.        To solve this problem, I get the byte only when they are requested on the
  46.        bus. In aswer to the Pause/Aborted Interrupt generated on the last byte
  47.        of a Transfer Info during a Message In phase, I only negate Acknowledge,
  48.        and wait for the next Service Required Interrupt to get the next byte.
  49.     
  50.     3) I modified the driver to support the TARGET role of the SCSI protocole.
  51.        In answer to a selection with ATN, I tried to get the Message Out, which
  52.        always failed with an ATN asserted. Though it's perfectly normal that ATN
  53.        is asserted during a Selection... with ATN, the AM33C93/A acts as if it
  54.        was an error.
  55.        To get around that problem, I re-program the Control Register at each
  56.        phase change, so that ATN is ignored during Message Out phase, and
  57.        considered in any other phase.
  58.     
  59.     4) The same kind of problems happened with the DMA transfers. According to
  60.        the specifications, the DMA mode is used ONLY for DATA phases, but the
  61.        chip does it different and use that DMA mode in some other phases.
  62.        To solve this, I go for the same way as for the ATN problem: I re-program
  63.        the Control Register according to the current phase (DMA only during
  64.        Data In/Out).
  65.     
  66.      
  67.     Thanks for answering my request
  68.     
  69.     Pierre Fontana
  70.     
  71.     " Sometimes I think the surest sign that intelligent life exists somewhere in
  72.       the Universe is that none of it ever tried to contact us (Calvin & Hobbes). "
  73.     
  74.     
  75.     
  76.  
  77. --
  78.  David Jones          FreeNet: (preferred) aa457@freenet.carleton.ca
  79.  6730 Tooney Drive    NotSoFreeNet:        dej@qpoint.ocunix.on.ca
  80.  Orleans, Ontario     Fidonet:             1:163/109.8
  81.  K1C 6R4, Canada      Phone:               1-613-830-1437
  82.  
  83.