Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!mephisto!udel!mmdf From: MDOELL%DOSUNI1.BITNET@cunyvm.cuny.edu (Magnus Doell) Newsgroups: comp.os.minix Subject: A (hopefully) general driver for SCSI [long] Message-ID: <32154@nigel.ee.udel.edu> Date: 2 Oct 90 20:15:46 GMT Sender: mmdf@ee.udel.edu Lines: 181 Hello world! Following is a brief description of my SCSI driver, I have written quick-and-dirty nearly a year ago, first with a Storage Dynamics T-1007 SCSI hostadapter, now with Seagates ST-02. This driver has nothing to do with the one Fred has posted a few days ago, but this description may help you in understanding it (I don't know, as I couldn't uud it - uud grumbled something about duplicate char in translation table and I am grumbling to |-). RUNNING ENVIRONMENT The driver is now running with the following hardware configuration: 16 MHz 386sx Seagates ST-02 SCSI hostadapter Seagates ST296N 80 MByte harddisk as SCSI device 0 (a few days ago, I have added a second harddisk for testing only) Control Datas WREN IV CDC 94171 300 MByte harddisk as SCSI device 1 but it should be configurable to run on other hardware environments also. GENERAL NOTES Before I start with the description of my driver, let me state out one point or another here explicitly: 1. This driver isn't designed to be an optimal driver for a specific SCSI hostadapter, but to be configurable to as many SCSI hostadapters as possible with only minor changes (for this reason, it couldn't use the controllers special features like programmed DMA, interrupts etc. |-( but it could be a workable starting point for such an optimized driver). 2. This driver isn't finished yet |-( I have a somewhat ideallistic layout for the finished version, from which this driver is now far away |-) but I am now searching for pre-beta-testers, so I could include missing features as well as other hardware environments, to which this driver may be configurable or definitely won't. For this reason, I won't post the driver yet, but mail it to the pre-beta-testers (all interested peoples are welcome) as long as the list isn't to great (in which case I'll post it however). 3. I am willing to give Andy all the rights he needs to add this driver to coming versions of MINIX (are you interested, Andy) with all the configurations coming from the net (so if you want to (pre-)beta-test this driver on your hardware configuration, you should also be willing to mail me your changes/extensions/configurations and give me all the rights neccessary to build them into the final version). 4. There should be at least 2 extensions to MINIX outside this driver to increase the throughput drastically in some circumstances, including: a) 2 routines in klib.x for reading/writing multiple bytes from an I/O port b) a better interface for tasks to install watchdog-functions within the clock driver, avoiding the message-passing overhead and -more important- handling the pending ticks accordingly (this driver needs timings in dozends of milliseconds and the clock driver is designed to handle timings in seconds, although times are specified in ticks). (I haven't implemented this extensions yet, but use a poor timeout mechanism with a counter instead |-( and I won't implement them until I have your O.K., Andy). 5. As this driver is based on informations I found in some german computer magazines (named c't and mc, many thanks to them for these articles) and a close look with a debugger to the different controllers BIOSes (to get informations about the controllers mappings) not using the ANSI draft proposal X-3T9.2 (I don't know, where to get it - could anybody tell me?) nor any technical handbook for the different controllers or harddisks, I may have misunderstand something (and so will the driver now) as well as there are some missing features (like forcing messages to targets and all the thinks only related to disconnections and reselections). THE SCSI HOSTADAPTER The SCSI hostadapter should map (parts of) the SCSI bus more or less directly into the processors address space, leaving the driver the job to check and activate the SCSI bus lines directly with only minor helps on some very time critical actions (it won't be wrong to assume, that the hostadapter's architecture is designed to minimize the accesses to the mapped SCSI bus). I have decided to devide (somewhat arbitrary but not uncommon) this mapping into 3 parts: part 1 are (parts of) the SCSI bus handshake signals as well as all the signals needed to determine any legal SCSI bus phase. I will name this part "status register(s)". part 2 are (parts of) the SCSI bus handshake signals as well as all the signals needed to bring the SCSI bus into any legal SCSI bus phase. I will name this part "command register(s)". part 3 are all the SCSI bus data lines. I will name this part the "data register" (only one, although it could be mirrored for easier access when it is memory mapped into the processors address space). All this parts may be independandly mapped into the processors address space (even in different types of address spaces, although it is bad design style, to map part one and two into different address space types). Part two does contain all the neccessary SCSI bus lines (or some the SCSI bus lines controlling switches) as well as it may also contains some other switches (e.g. a switch for connecting/disconnecting the registers to the SCSI bus). The driver is designed to use a minimum set of SCSI bus lines, so that it shouldn't be dramatic, if your hostadapter is missing one SCSI line or the other in the mapping (e.g. the driver doesn't use arbitration, as the attention line may be missing). THE DRIVERS OVERALL STRUCTURE The driver is devided into 4 layers (or at least should be). layer 0 realizes the access of the different controllers registers by defining the access mechanism in terms of routines found elsewhere in MINIX (e.g. phys_copy for memory mapped registers, port_in, port_out etc. for I/O mapped registers). It also defines the registers's addresses, masks, status values and command values. To be more precise, it defines a set of symbolic names for register addresses, values for masking, checking and setting for each SCSI bus phase to be used in layer 1 as well as some more general values (e.g. for detecting the SCSI's bus phase etc.). layer 1 is a collection of routines each handling one SCSI bus phase together with some utility routines for more convenience and error recovery. The routines access the SCSI hostadapter only through layer 0 and upper layers should access it only through layer 1, so a configuration should be restricted to layer 0 in most cases. The routines in this layer assume, that the accesses to the hostadapter's data register also handle the neccessary SCSI bus acknoledgement (this is the point, where accesses to the hostadapter's registers are minimized). They all do busy waiting on the SCSI bus (whereas some may avoid this busy waiting others can't without using special features from the hostadapter), so they should be called from upper layers, when these are awaiting the corresponding SCSI bus phase soon. For now I have implemented a poor timeout mechanism, which I will reimplement, when I am adding the missing features to MINIX. I will also add the abilty to specify some timeout values in upper layers as they may vary highly on the devices and this layer shouldn't assume too much on the devices attached to the SCSI bus (but for now it actually assumes quick harddisks |-). layer 2 isn't yet existing but should implement the SCSI's common command set. For now I have special versions for some group 0 and one group 1 command built-in in layer 3. I have decided to implement this special versions also busy waiting for 3 reasons: a) it is easier to implement |-) b) as the filesystem is blocked waiting for the driver to finish, it may be better to finish as quick as possible than to avoid busy waiting - or at least it shouldn't slow it down dramatically c) as I have only harddisks to control and these are quick, I could live with this (in fact the Seagate ST296N has only 2 buffers build in, so the driver has to get this buffer quick from the harddisk or it may wait another harddisks revolution on a multi sector read). Nevertheless I am now working to implement this layer and I will use some more sophisticated algorithms which could be controlled for the device dependent parts by upper layers. This layer will become more important as other layer 3 software are implemented (like drivers for tape streamers etc.). layer 3 is the winchester task finding the harddisks connected to the SCSI hostadapter, handling the logical devices, block address translation, message passing etc. There are a few restrictions build in here a) only two harddisks could be managed (easy to change) b) only one logical unit could be handled for one harddisk device and this is LUN 0 (although the block address translation isn't checked for now, so that great values could select other LUN'S - this is a bug, not a feature) c) the harddisks sector size must be 512 (as I don't know how to handle the partition table otherwise) d) the harddisks must have a valid partition table or they won't be installed with this driver and a bug/feature, that this driver will accept removable harddisks also (unless there isn't a valid partition table) without any special handling of harddisk changes. It is up to you, to use this feature accordingly (don't forget to umount before changing |-). That should be enough for now (blame me, if I have wasted your time). Ma.D.