aztcd

《嵌入式系统设计与实例开发实验教材二源码》Linux内核移植与编译实验

           Germany


7. OTHER DRIVES
The following drives ORCHID CDS3110, OKANO CDD110, WEARNES CDD110 and Conrad
TXC Nr. 993123-series 04 nearly look the same as AZTECH CDA268-01A, especially 
they seem to use the same command codes. So it was quite simple to make the 
AZTECH driver work with these drives. 

Unfortunately I do not have any of these drives available, so I couldn't test
it myself. In some installations, it seems necessary to initialize the drive 
with the DOS driver before (especially if combined with a sound card) and then 
do a warm boot (CTRL-ALT-RESET) or start Linux from DOS, e.g. with 'loadlin'.

If you do not succeed, read chapter DEBUGGING. 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 us.

If you do have a CyCDROM CR520ie thanks to Hilmar Berger's help your chances
are good, that it will work with aztcd. The CR520ie is sold as an IDE-drive
and really is connected to the IDE interface (primary at 0x1F0 or secondary
at 0x170, configured as slave, not as master). Nevertheless it is not ATAPI
compatible but still uses Aztech's command codes.


8. DEBUGGING : IF YOU DON'T SUCCEED, TRY THE FOLLOWING
-reread the complete README file
-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 appropriately 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.
 If your drive's base address is something like 0x170 or 0x1F0 (and it is
 not a CyCDROM CR520ie or CR 940ie) you most likely are having an IDE/ATAPI-
 compatible drive, which is not supported by aztcd.c, use ide-cd.c instead.
 Make sure the Base Address is configured correctly in aztcd.h, also make
 sure, that /dev/aztcd0 exists with the correct major number (compare it with
 the entry in file /usr/include/linux/major.h for the Aztech drive). 
-insert a CD-ROM and close the tray
-cold boot your PC (i.e. via the power on switch or the reset button)
-if you 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 aztcd: init message during Linux init and note them exactly
-log in as root and do a mount -t iso9660 /dev/aztcd0 /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 aztcd-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 via loadlin (try both).
 ...
 Again note all commands and the aztcd-messages.

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

If this still does not help, 
-look in aztcd.c for the lines  #if 0
                                #define AZT_TEST1
                                ...
                                #endif
 and substitute '#if 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 aztcd-messages during init, before the login-prompt appears.
 Then look in aztcd.c, to find out, what happened. The normal calling sequence 
 is: aztcd_init() during Linux bootup procedure init()
 after doing a 'mount -t iso9660 /dev/aztcd0 /mnt' the normal calling sequence is
     aztcd_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
     aztUpdateToc()
     aztGetDiskInfo()
     aztGetQChannelInfo()   repeated several times
     aztGetToc()
     aztGetQChannelInfo()   repeated several times
     a list of track information
     do_aztcd_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
 aztcd.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 aztcd_open(). Try to open the tray, insert an
 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 aztcd.c in 
function aztcd_init, where the drive should be detected during init. Do the
following:
-reboot the system with boot parameter 'aztcd=<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 aztcd_init() to exactly match the first 3 or 4 letters you have seen.
-Another point is the 'smart' card detection feature in aztcd_init(). Normally
 the CD-ROM drive is ready, when aztcd_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 me 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.)


9. TECHNICAL HISTORY OF 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 information acknowledging
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 aztSendCmd(), 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
aztGetDiskInfo()).

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 only have implemen-
ted in the ioctl-section but not in the section which is used by the ISO9660. 

The driver was developed 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. My CD-ROM drive is an Aztech CDA268-01A. My
drive says, that it has Firmware Version AZT26801A1.3. It came with an ISA-bus
interface card and works with polled I/O without DMA and without interrupts.
The code for all other drives was 'remote' tested and debugged by a number of 
volunteers on the Internet.

Points, where I feel that possible problems might be and all points where I 
did not completely understand the drive's behaviour or trust my own code are 
marked with /*???*/ in the source code. There are also some parts in the 
Mitsumi driver, where I did not completely understand their code.


10. 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 analyzing the command structure of various CD-ROM drives, this
work would not have been possible. E.Moenkeberg was also a great help in 
making the software 'kernel ready' and in answering many of the CDROM-related 
questions in the newsgroups. He really is *the* Linux CD-ROM guru. Thanks 
also to all the guys on the Internet, who collected 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', which I copied from mcd.c.

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 occurred.

Reinhard Max delivered the information for the CDROM-interface of the
SoundWave32 soundcards.

Jochen Kunz and Olaf Kaluza delivered the information for supporting Conrad's 
TXC drive.

Hilmar Berger delivered the patches for supporting CyCDROM CR520ie.

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'.

11. PROGRAMMING ADD ONs: cdplay.c
You can use the ioctl-functions included in aztcd.c in your own programs. As
an example on how to do this, you will find a tiny CD Player for audio CDs 
named 'cdplay.c'. 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. You can find the code in the 
APPENDIX of this file, which you should cut out with an editor and store in a 
separate file 'cdplay.c'. To compile it and make it executable, do
  gcc -s -Wall -O2 -L/usr/lib cdplay.c -o /usr/local/bin/cdplay # compiles it
  chmod +755 /usr/local/bin/cdplay                              # makes it executable
  ln -s /dev/aztcd0 /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 set the correct permissions for cdplay *and* for /dev/mcd0 or
/dev/aztcd0 in order to use it. Remember, that you should not have /dev/cdrom 
mounted, when you're playing audio CDs. 

This program is just a hack for testing the ioctl-functions in aztcd.c. I will 
not maintain it, so if you run into problems, discard it or have a look into 
the source code 'cdplay.c'. The program does only contain a minimum of user 
protection and input error detection. If you use the commands in the wrong 
order or if you try to read a CD at wrong addresses, you may get error messages
or even hang your machine. If you get STEN_LOW, STEN_LOW_WAIT or segment violation 
error messages when using cdplay, after that, the system might not be stable 
any more, so you'd better reboot. As the ioctl-functions run in kernel mode,
most normal Linux-multitasking protection features do not work. By using
uninitialized 'wild' pointers etc., it is easy to write to other users' data 
and program areas, destroy kernel tables etc.. So if you experiment with ioctls
as always when you are doing systems programming and kernel hacking, you
should have a backup copy of your system in a safe place (and you also
should try restoring from a backup copy first)!

A reworked and improved version called 'cdtester.c', which has yet more
features for testing CDROM-drives can be found in
/usr/src/linux/Documentation/cdrom/sbpcd, written by E.Moenkeberg.

Werner Zimmermann
Fachhochschule fuer Technik Esslingen
(EMail: [e-mail])
October, 1997

---------------------------------------------------------------------------
APPENDIX: Source code of cdplay.c

/* Tiny Audio CD Player

   Copyright 1994, 1995, 1996 Werner Zimmermann ([e-mail])

This program originally was written to test the audio functions of the
AZTECH.CDROM-driver, but it should work with every CD-ROM drive. Before 
using it, you should set a symlink from /dev/cdrom to your real CDROM
device.

The GNU General Public License applies to this program.

History:  V0.1  W.Zimmermann: First release. Nov. 8, 1994
          V0.2  W.Zimmermann: Enhanced functionality. Nov. 9, 1994