Plex 6/Plex6.mdf/u_linux/aztech05.rea

Text File | 1994-12-28 | 16.6 KB | 327 lines

Readme-File for Aztech CD-ROM268A and ORCHID CD-3110 Driver ALPHA-Version 0.50
      (for OKANO and WEARNES drives see 10.)

1. NOTE
This software is ALPHA, thus it may contain many bugs and may even hang your
machine or crash files. Therefore only real hackers, who know, what they are
doing, should install it !!!

2. INSTALLATION
- Unzip/untar the file AZTECH.CDROM.Vxx.tgz (xx=version number) in the
  tmp-directory.
- Rename your Mitsumi-CDROM-Driver Files mcd.c and mcd.h, they should reside
  in /usr/src/linux/drivers/block and /usr/include/linux, respectively:
      cd /usr/include/linux
      mv mcd.h mcd.h.MITSUMI
      cd /usr/src/linux/drivers/block
      mv mcd.c mcd.c.MITSUMI
- Move the files azt.c and azt.h from the tmp-directory to these directories
  and create symlinks to mcd.c and mcd.h:
      cd /usr/include/linux
      mv /tmp/azt.h /usr/include/linux/azt.h
      ln -s azt.h mcd.h
      cd /usr/src/linux/drivers/block
      mv /tmp/azt.c /usr/src/linux/drivers/block/azt.c
      ln -s azt.c mcd.c
  The AZTECH.DRIVER simply substitutes the Mitsumi-Driver, thus it is not
  possible in the moment, to have both the AZTECH and the Mitsumi-Driver in
  the same kernel.
- Edit azt.h to set the I/O-adress to your I/O-Base adress (AZT_BASE_ADDR),
  the driver does not use interrupts or DMA, so if you are using an AZTECH
  CD268 or an ORCHID CD-3110 that's the only item you have to set up.
  Users of other drives should read chapter 10. of this readme-file.
  You also can configure that address by LILO boot parameter mcd=... (note:
  here it is still mcd and not yet azt)
- Build a new kernel, configure it for 'Mitsumi support' and include the
  iso9660 filesystem.
- Activate the new kernel, normally this is done by running lilo (don't for-
  get to configure it before and to keep a copy of your old kernel in case
  something goes wrong!).
- Reboot
- You should see during boot some messages like
    Aztech CD-ROM Init: DriverVersion=<version number> BaseAddress=<baseaddress>
    Aztech CD-ROM Init: FirmwareVersion=<firmware version id of your I/O-card>
    Aztech CD-ROM Init: End
  If these messages look different, there may either be a problem with the
  base adress or with the drive recognition (look in file azt.c in function
  azt_init(), how I check this by issuing a ACMD_GET_VERSION command).
- If you're lucky, as root you should be able to mount the drive by
          mount -t iso9660 -r /dev/mcd0 /mnt
  and use it as any other filesystem.

3. MODIFICATIONS TO THE DRIVER
The AZTECH-Driver is a rework of the Mitsumi-Driver. Four major items had to
be reworked:

a) The Mitsumi drive does issue complete status informations acknowleding
each command, the Aztech drive does only signal that the command was
processed. So whenever the complete status information is needed, an extra
ACMD_GET_STATUS command is issued. The handshake procedure for the drive
can be found in the functions sendCmd(), sendAztCmd() and getAztStatus().

b) The Aztech Drive does not have a ACMD_GET_DISK_INFO command, so the
necessary info about the number of tracks (firstTrack, lastTrack), disk
length etc. has to be read from the TOC in the lead in track (see function
getDiskInfo()).

c) Whenever data is read from the drive, the Mitsumi drive is started with a
command to read an indefinite (0xffffff) number of sectors. When the appropriate
number of sectors is read, the drive is stopped by a ACDM_STOP command. This
does not work with the Aztech drive. I did not find a way to stop it. The
stop and pause commands do only work in AUDIO mode but not in DATA mode.
Therefore I had to modify the 'finite state machine' in function azt_poll to
only read a certain number of sectors and then start a new read on demand. As I
have not completely understood, how the buffer/caching scheme of the Mitsumi
driver was implemented, I am not sure, if I have covered all cases correctly,
whenever you get timeout messages, the bug is most likely to be in that
function azt_poll() around switch(cmd) .... case ACD_S_DATA.

d) I did not get information about changing drive mode. So I doubt, that the
code around function azt_poll() case AZT_S_MODE does work. In my test I have
not been able to switch to reading in raw mode. For reading raw mode, Aztech
uses a different command than for cooked mode, which I haven't yet implemen-
ted. On the other hand, until now I have not found a reason, why anybody should
need reading in raw mode.

4. PROBLEMS
The drive status recognition does not work correctly in all cases. Changing
a disk or having the door open, when a drive is already mounted, is
detected by the Aztech driver itself, but nevertheless causes multiple read
attempts, which finally timeout, so you have to wait quite a little... But
isn't it bad style to change a disk in a mounted drive, anyhow ?!

The driver uses busy wait in most cases for the drive handshake (macros
STEN_LOW and DTEN_LOW). I tested with a 486/DX2 at 66MHz and a Pentium at
60MHz. Whenever you use a much faster machine you are likely to get timeout
messages. In that case edit azt.h and increase the timeout value AZT_TIMEOUT.

For some 'slow' drive commands I implemented waiting with a timer waitqueue
(macro STEN_LOW_WAIT). If you get this timeout message, you may also edit
azt.h and increase the timeout value AZT_STATUS_DELAY. The waitqueue has
shown to be a little critical. If you get kernel panic messages, edit azt.c
and substitute STEN_LOW_WAIT by STEN_LOW. Busy waiting with STEN_LOW is more
stable.

Note: When you compare the code of the Mitsumi and the Aztech driver,
remember that variable and commands have been renamed from mcd... to azt...

5. TEST STATUS
This software has only be tested for quite a short time in some different
machines. Especially the support for drives other than AZTECH CD268 V1.3 is
not tested appropiately. So I'm quite sure I'll see some bug reports (see 8
aand 10).

Points, where I feel that possible problems might be and all points where I
did not completely understand the drives behaviour or trust my own code are
marked with /*???*/ in the source code. There are also some points, where I
definitely did not understand the code in the Mitsumi driver. And after all,
already the Mitsumi driver is not a good example for structured software
(who uses goto-statements in C software?). This has now been fixed by Joe
Nardone, who rewrote the azt_poll routine.

6. TEST ENVIRONMENT
My Aztech CD-ROM DRIVE says, that it has Firmware Version AZT26801A1.3. It
came with a ISA-bus interface card and works with polled I/O without DMA and
without interrupts.
I tested on an AST PC with Intel 486/DX2, 8MB RAM, 340MB IDE hard disk and
on an AST PC with Intel Pentium 60MHz, 16MB RAM, 520MB IDE running Linux
kernel version 1.0.9 from the LST 1.8 Distribution. The kernel was compiled
with gcc.2.5.8.

7. ACKNOWLEDGMENTS
Without the help of P.Bush, Aztech, who delivered technical information
about the Aztech Drive and without the help of E.Moenkeberg, GWDG, who did a
great job in disassembling and analyzing the Aztech DOS-driver, this work
would not have been possible. Thanks also to Ruediger Helsch, Unifix, and to
all the unknown guys, who delivered valuable technical information about
CDROMs.

Joe Nardone ([e-mail]) was a patient tester even for my first
trial, which was more than slow, and made suggestions for code improvement.
Especially the 'finite state machine' azt_poll() was rewritten by Joe to get
clean C code and avoid the ugly 'gotos'.

Robby Schirmer ([e-mail]) tested the audio stuff (ioctls)
and suggested a lot of patches for them.

Joseph Piskor and Peter Nugent were the first users with the ORCHID CD3110
and also were very patient with the problems, which occured.

Anybody, who is interested in these items should have a look at 'ftp.gwdg.de',
directory 'pub/linux/cdrom' and at 'ftp.cdrom.com', directory 'pub/cdrom'.

8. BUG REPORTS
Please send detailed bug reports and bug fixes via EMail to

                  [e-mail]

I also would like to get positive feedback. Please inform me, if you have
positive test results. Please include a description of the version number of
the AZTECH.CDROM-driver, of your hardware and of the Linux kernel version
and tell me, with which applications you tried it.

I will try to collect the reports and make the necessary modifications from
time to time. But please note, that due to my equipment here I will not be
able to test functions in depth concerning AUDIO MODE, CD-I etc..

9. ADD ONs
You will find a tiny CD Player for audio CDs named "cdplay". It allows you
to play audio CDs. You can play a specified track, pause and resume or skip
tracks forward and backwards. If you quit the program without stopping the
drive, playing is continued. You can also (mis)use cdplay to read and hexdump
data disks in raw and cooked mode.

To compile it and make it executable, do
      gcc -s -O6 -L/usr/lib cdplay.c -o /usr/local/bin/cdplay  # compiles it
      chmod +755 /usr/local/bin/cdplay                         # makes it executable
      ln -s /dev/mcd0 /dev/cdrom                   # creates a link
   (for /usr/lib substitute the top level directory, where your include files
    reside,  and for /usr/local/bin the directory, where you want the executable
    binary to reside )

You have to be ROOT in order to use it. Remember, that you should not have
/dev/mcd0 mounted, when you're playing audio CDs.

This program is just a hack for testing the ioctl-functions in azt.c, I will
not maintain it, so if you run into problems, discard it or have a look into
the source code cdplay.c. If you get STEN_LOW or STEN_LOW error messages
when using cdplay, after that, the system might not be stable any more, so
you'd better reboot.

10. OTHER DRIVES
The DOS drivers of the following drives ORCHID CDS3110, OKANO CDD110 and
WEARNES nearly look the same as the DOS driver for AZTECH, especially they
seem to use the same command codes. So it should be simple to make the
AZTECH driver work with these drives.

Unfortuntately I do not have any of these drives available, so I can't test
it. I've got some reports, that it works with ORCHID CDS3110 and a Game-Wave32
sound card. In some installations, it seems necessary to initialize the
drive with the DOS driver before and then do a warm boot (CTRL-ALT-RESET) or
start Linux from DOS, e.g. with 'loadlin'.

Please give me positive or negative feedback, if you have tried it.
Especially you should tell me, how the version string reads during
initialization. If you don't succeed, read chapter 11. Thanks in advance!

Sorry for the inconvenience, but it is difficult to develop for hardware,
which you don't have available for testing. So if you like, please help me
and look at 11.!

11. IF YOU DON'T SUCCEED ... DEBUGGING
Try the following
-reread points 2 and 10!
-make sure, that your drive is hardware configured for
    transfer mode: polled
    IRQ:           not used
    DMA:           not used
    Base Address:  something like 300, 320 ...
 You can check this, when you start the DOS driver, which came with your
 drive. By appropiately configuring the drive and the DOS driver you can
 check, whether your drive does operate in this mode correctly under DOS. If
 it does not operate under DOS, it won't under Linux.
 Make sure the Base Address is configured correctly in azt.h.
-insert a CD-ROM and close the tray
-cold boot your PC (i.e. via the power on switch or the reset knob)
-if your start Linux via DOS, e.g. using loadlin, make sure, that the DOS
 driver for the CD-ROM drive is not loaded (comment out the calling lines
 in DOS' config.sys!)
-look for the azt: init message during Linux init and note them exactly
-log in as root and do a mount -t iso9660 /dev/mcd0 /mnt
-if you don't succeed in the first time, try several times. Try also to open
 and close the tray, then mount again. Please note carefully all commands
 you typed in and the azt-messages, which you get.
-if you get an 'Aztech CD-ROM init: aborted' message, read the remarks about
 the version string below.

If this does not help, do the same with the following differences
-start DOS before; make now sure, that the DOS driver for the CD-ROM is
 loaded under DOS (i.e. uncomment it again in config.sys)
-warm boot your PC (i.e. via CTRL-ALT-DEL)
 if you have it, you can also start from via loadlin (try both).
 ...
 Again note all commands and the azt-messages.

If you see STEN_LOW or STEN_LOW_WAIT error messages, increase the timeout
values.

If this still does not help,
-look in azt.c for the lines  #if 0
                              #define TEST1
                              ...
                              #ENDIF
 and substitute '#ifdef 0' by '#if 1'.
-recompile your kernel and repeat the above two procedures. You will now get
 a bundle of debugging messages from the driver. Again note your commands
 and the appropriate messages. If you have syslogd running, these messages
 may also be found in syslogd's kernel log file. Nevertheless in some
 installations syslogd does not yet run, when Init is called, thus look for
 the azt-messages during init, before the login-prompt appears.
 Then look in azt.c, to find out, what happened. The normal calling sequence
 is: azt_init() during Linux bootup procedure Init
 after doing a 'mount -t iso9660 /dev/mcd0 /mnt' the normal calling sequence is
     azt_open()    -> Status 2c after cold reboot with CDROM or audio CD inserted
                   -> Status 8  after warm reboot with CDROM inserted
                   -> Status 2e after cold reboot with no disk, closed tray
                   -> Status 6e after cold reboot, mount with door open
     updateToc()
     GetDiskInfo()
     GetQChannelInfo()   repeated several times
     GetToc()
     GetQChannelInfo()   repeated several times
     a list of track informations
     do_azt_request()  }
     azt_transfer()    } repeated several times
     azt_poll          }
 Check, if there is a difference in the calling sequence or the status flags!

 There are a lot of other messages, eg. the ACMD-command code (defined in
 azt.h), status info from the getAztStatus-command and the state sequence of
 the finite state machine in azt_poll(). The most important are the status
 messages, look how they are defined and try to understand, if they make
 sense in the context where they appear. With a CD-ROM inserted the status
 should always be 8, except in azt_open(). Try to open the tray, insert a
 audio disk, insert no disk or reinsert the CD-ROM and check, if the status
 bits change accordingly. The status bits are the most likely point, where
 the drive manufacturers may implement changes.

If you still don't succeed, a good point to start is to look in azt.c in
function azt_init, where the drive should be detected during init. Do the
following:
-reboot the system with boot parameter 'mcd=<your base address>,0x79'. With
 parameter 0x79 most of the drive version detection is bypassed. After that
 you should see the complete version string including leading and trailing
 blanks during init.
 Now adapt the statement
      if ((result[1]=='A')&&(result[2]=='Z' ...)
 in azt_inti() to exactly match the first 3 or 4 letters you have seen.
-Another point is the 'smart' card detection feature in azt_init(). Normally
 the CD-ROM drive is ready, when azt_init is trying to read the version
 string and a time consuming ACMD_SOFT_RESET command can be avoided. This is
 detected by looking, if AFL_OP_OK can be read correctly. If the CD-ROM drive
 hangs in some unknown state, e.g. because of an error before a warm start or
 because you first operated under DOS, even the version string may be correct,
 but the following commands will not. Then change the code in such a way,
 that the ACMD_SOFT_RESET is issued in any case, by substituting the
 if-statement 'if ( ...=AFL_OP_OK)' by 'if (1)'.

If you succeed, please mail may the exact version string of your drive and
the code modifications, you have made together with a short explanation.
If you don't succeed, you may mail me the output of the debugging messages.
But remember, they are only useful, if they are exact and complete and you
describe in detail your hardware setup and what you did (cold/warm reboot,
with/without DOS, DOS-driver started/not started, which Linux-commands etc.)

11. KNOWN BUGS
AZTECH firmware versions newer than 1.3, especially 1.6:
The driver was developped and tested with Aztech Firmware version 1.3 (see
the azt: init message during booting). I do not have access to newer versions,
but I've got a report from one user of AZTECH firmware version 1.6, that the
driver did not work. May be, AZTECH has changed commands or -more likely-
status flags. We're looking after that. Anybody who has a newer version than
1.3 is asked to help us!

Werner Zimmermann
Fachhochschule fuer Technik Esslingen
Dez 14, 1994