This is the readme file for the IOMEGA PC2/2B driver version 1.1.  The last
one was version 1.0- I didn't really think anyone would use it(!), so it
wasn't very stable and had no version number.  This one at least has a
version number.  

------------------
+++ How to install
------------------

1) Email bwh8918@rit.edu and tell me you're using it (or trying to!), what
   drive(s) and adapter you have.  It won't work if you don't do this.  
   Thanks.  
2) Apply the patch
    a) cd /usr/src/linux
    b) patch -p1 < pc2-closest.kernel.version.patch.gz
                              ---OR---
    a) copy src/iomega_pc2.* to ~linux/drivers/scsi and hack the kernel patch
       manually if you'd rather.

3) Edit iomega_pc2.cfg
       Read the comments and adjust as necessary.
4) Rebuild the kernel
    a) make config
        i) When it asks you if you want SCSI support, say `y'
        ii) Make sure you say `y' to SCSI disk support or tape or CDROM
            depending on what's hooked up to your PC2.
        iii) When it asks you if you want IOMEGA PC2/2B support, say `y'
        iv) I don't care what you do with the rest of the
            configuration.  
    b) make dep
    c) make clean
    d) make
8) Run lilo if you're using it, or copy the kernel onto a boot disk or
   whatever
9) Put cartridges in the drive and turn it on
10) Reboot!

------------------
+++ Known Problems
------------------

Axx specific:
    Each bernoulli drive attached to the card must have a cartridge
    inserted at boot time to be detected.  This has something to do with
    the way that the drives are detected (a TEST_UNIT_READY command)
    and the way the drives respond to it.  This problem may or may not
    be present in newer drives.

Non-Axx specific:
    You may already know this- DMA is a problem.  This is because the card
    design forces me to figure out how much data we need to DMA before
    starting the transfer, and if, for some reason, your drive doesn't want
    to transfer that much data, everything stops!  This can be fixed my
    maiming the big switch statement in iomega_pc2.c, but I don't know what
    numbers to fill in.  (I'm working on it...)

Everything:
    The bios_param function makes me want to vomit.  I've got to work on
    this.  (Or you can- mail me the patches.  :) )  Those of
    you with drive geometries different from those compiled in are
    either going to have to manually input the geometries when running
    fdisk, or just not run fdisk!

    There are a few bugs on the PC2 card.  I worked around a DMA bug by
    following my documentation's directions, but you may still see
    something about a `borken parity algorithm'.  The PC2 usually
    produces parity bits for the SCSI bus, but some of the older cards'
    algorithms didn't work.  I'm running a check at boot time to test
    you card, and if it doesn't pass you'll see a message.  No big deal-
    the driver doesn't look at it even if it DOES work!

-----------------------
+++ Babysitting options
-----------------------

I am blessed with a MOSTLY ANSI SCSI compatible drive.  I put in a
compile time thing called `BABYSIT_ALPHA' that keeps an eye on my drive so
it doesn't do anything stupid.  If you have an Axx drive too, you'll want
to define this and set up some stuff in iomega_pc2.cfg (see file for
details...)

--------------------
+++ Unknown problems
--------------------

Everything I don't know is documented extensively below.  :)

Ok- If something weird happens and the bottom drops out of the kernel you'll
probably see 

iomega_pc2: resetting with status 0x##

    This means your drive went bonkers and we tried to reset the SCSI
bus.  This has never left my machine in a stable condition, so I put in
the above message.  Here's how you interpret the status code (and,
hence, attempt to figure out why it was reset!)

For those of you that can do Binary/Hex conversions (or have a
calculator to do it for you!):

Bit  Explanation ("if the bit is 1...")
---  -----------
0    Drive is requesting something (depends on bits 1,2, and 3).  This
     usually means that either your drive or my driver is messed up
1    We're in the process of reading from the drive.  (Data was being
     transferred from the drive to the card).  If 0, we were writing to
     the drive.  (Data was being sent to the drive from the card)
2    We're sending the command bytes
3    `Message' bit.  Drive wants to send a message (last thing
     transferred for each command execution)
4    Busy.  There was a drive out there paying attention to what we were
     saying.
5    Parity bit.  Doesn't work on my card anyway, but will be set if there's
     a parity error... if it works, I mean.  
6    ACK.  I have never seen this set- it happens really fast I think.
7    Latch bit.  0 if we're in the process of DMAing, 1 otherwise

    If we ignore the top 3 bits (5, 6, and 7), it all boils down the
most-commonly-seen-by-the-driver-author status code list:

0x00: Bus was free, nothing was happening.  Usually shows up as 0x80
      (because of the latch bit... see below)
0x10: In the middle of getting a drive's attention.  
0x11: Drive want us to send out data
0x13: Drive wants to send us data
0x15: Drive wants a command byte
0x17: Drive is sending a message

    Ok, I lied- A lot of times, the LATCH bit will be set, so I
see 0x80, 0x90, 0x91, 0x93, 0x95, and 0x97 instead.  If a number
appears that is 1 LESS than on of the above numbers, we were in the
process of doing that action when the drive stopped asking for stuff
(REQuest was never raised).  Don't ask me! :)

-----------------------
+++ Need Documentation?
-----------------------

Me too.

I have full documentation for the PC2 and A10H.  I'd be happy to share.
IOMEGA wanted me to pay $33 for docs on one of their newer drives- I'm
currently haggling.

---------
+++ To-do 
---------

- Fix the cartridge-out/detect problem.  Probably requires more babysitting but
  at a higher level

- Add support for the other standard and non-standard drives out there
  (babysitting and bios_param stuff).

- Check parity bits on working cards

- Dynamically loadable module for Axxs?  (They not really SCSI compliant- it
  might be better if they weren't dependent on the mid-level SCSI drivers)

 Brian
 bwh8918@rit.edu
 11/07/94
