davep@gapos.bt.co.uk (Dave Parkinson) (11/27/90)
I have recently bought MINIX 1.5 and installed it on my AT (& also
discovered the net). As I'm new to the net I've missed any preceeding
traffic on SCSI drivers but herewith my experiences.
In installing MINIX I've had to clear a reasonable amount of space on my
hard disk to make room for it. (Now 25M DOS, 15M Minix). As always I want
more space! I have an accumulation of bits & pieces acquired over the
years, including some early winchester drives & SASI/SCSI controllers. (
How about a full-height 5.25" winchester with a capacity of 5M - yes five!).
Anyway I decided to press into service some of these Winchesters with an
Adaptec ACB-4000 Winchester Disk Controller (circa March 1984). To
interface to this I purchased the Seagate ST01-B SCSI Host adapter (cheap).
Then the fun started...
Initially I wrote a simple test driver that ran OK under Dos - this I then
ported to MINIX. After spending a while debugging things and recompiling
the kernel many times I've decided the ST01 (or ST02) driver belongs in
MSDOS, not MINIX....
The salient points of the ST01 interface are:
* The interface is memory mapped. (requires a GDT entry similar to the
video interface).
* The card does not support DMA. (the Seagate DOS driver uses REP MOVSB).
(I don't know how successful it would be trying to use memory-memory
DMA. The DMA controllers are only 16-bit - there is a latch that holds
the high address bits. [This is why you can't DMA transfer across a
physical 64k boundary]. Because of this you could only transfer within
the same physical 64k segment, not directly between the ST01 and the
source/destination buffer).
* The SCSI REQ/ACK handshake is handled by the ST01 which uses I/O Channel
ready to delay the 8x8x processor. (But this times-out after 13.2us
should the processor attempt a read/write too far in advance of the
SCSI REQ signal being asserted).
* The only interrupt condition the card supports is interrupt on select.
(ie if something out there on the SCSI BUS asserts select, the ST01 will
interrupt so you can check & see if it's you they're after).
With SCSI:
* Whilst the Host initiates a SCSI activity/transfer, all the transfers
across the SCSI bus are under the control of the TARGET, not the HOST.
(It is the target that controls all the lines other than ACK. The
target sets the speed of the transfer, and the time of the transfer).
The conventional disk drivers set up the command, initialise the DMA
channel to look after the data transfer, and then suspend themselves and
await the interrupt on completion - a reasonably efficient process in
a multi-tasking environment.
With the ST01 you cannot do this. DMA is out, and the process has to run
all the time - even while the drive is seeking to the requested track.
(My Adaptec controller does not support a 'disconnect & please signal me
when you've completed the command' mode of operation. Other drives/
controllers might). Another problem is that if the task is interrupted
during a transfer, then the Target can time-out and abort the transfer that
is progress. (Having asserted REQ, the Target expects an ACK from the host
within a certain time-period - 250ms in the case of the Adaptec).
Thus interrupts have to be disabled during the entire transfer operation.
I reached the stage where fdisk ran Ok, but I had problems with readall.
Initially the machine 'locked' at the start or after reading a few sectors.
(This point I don't fully understand as my driver was not disabling
interrupts at the time - so surely the F1/F2 keys should have produced
screen displays?).
Adding lock() and unlock() commands either side of my scsi_op() call
improved matters (see previous para). Readall would run for maybe 20
seconds before the machine locked-up. (I'm using the standard
PH distribution with only a small mod to the keyboard drivers so they
suppot a UK keyboard).
For now I've decided to get my extra DOS disk space from the ST01 + external
SCSI drives, and MINIX will use the more efficient embedded AT drive.....
Anyone else got any better ideas?adrie@philica.ica.philips.nl (Adrie Koolen) (11/27/90)
In article <1990Nov26.163451.21348@gapos.bt.co.uk> davep@gapos.bt.co.uk (Dave Parkinson) writes: >With SCSI: >* Whilst the Host initiates a SCSI activity/transfer, all the transfers > across the SCSI bus are under the control of the TARGET, not the HOST. > (It is the target that controls all the lines other than ACK. The > target sets the speed of the transfer, and the time of the transfer). Some clarification. The SCSI bus can be in one of 10 phases: Bus Free, Arbitration, Selection, Reselection, Command, Data In, Data Out, Status, Message In and Message Out. The current phase is determined by some (5) SCSI signals. If noone drives the signals, the bus is in the Bus Free phase. The Initiator drives the bus into the Arbitration and Selection phases, the other phases (in which bytes are transfered from Initiator to Target or vice versa, as Dave correctly stated) are driven by the Target. The REQ and ACK lines are used to transfer one byte. The ACK is driven by the Initiator, The REQ by the Target. In asynchronous transfers the speed of the transfer is dependant on BOTH the Initiator AND the Target. In synchronous mode, the Initiator and the Target have to agree on the minimum time between two consecutive bytes (REQ or ACK pulses) and the number of unacknowledged bytes. >(My Adaptec controller does not support a 'disconnect & please signal me >when you've completed the command' mode of operation. Other drives/ >controllers might). The Disconnect/Reselect feature is only useful if you have multiple Initiators on one SCSI bus or more than one Target, which you want to use concurrently. Minix can't handle this case because of the single-threaded FS! >(Having asserted REQ, the Target expects an ACK from the host >within a certain time-period - 250ms in the case of the Adaptec). 250ms is the time recommended to wait for the assertion of the BSY signal after selecting a Target (or reselecting the Initiator). I think that the maximum REQ --> ACK time would be much shorter than 250ms. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
paradis@crater.zk3.dec.com (Jim Paradis) (11/29/90)
davep@gapos.bt.co.uk (Dave Parkinson) writes: [long story of ST01 woes deleted...] >For now I've decided to get my extra DOS disk space from the ST01 + external >SCSI drives, and MINIX will use the more efficient embedded AT drive..... > >Anyone else got any better ideas? Well, I have a similar situation: I have a 40Mb MFM drive on my system and an 84Mb SCSI drive hanging off an ST01. For a short time I ran System V on my system (386 box) and I used a driver for the ST01 that was posted to the net sometime back. Eventually I switched to Minix 1.5 with Bruce Evans' 32-bit patches (I'm a UNIX kernel hacker by trade and I much prefer to run an OS that I have the sources for 8-) ). Anyhow, eventually I decided I wanted to access the big hard drive as well, so I started trying to hammer that UNIX driver into MINIX. After ripping about 80% of its guts out, I ended up with a VERY crude driver. It's slow (20Kb/sec with a tailwind), and it eats up a lot of the machine, but it's also rock-solid. I, too, had problems with the memory-mapped interface. I solved this by adding a couple of assembly-language routines to klib386.x which just loaded up FLAT_DS_SELECTOR and fired away. As for its strange interrupt behavior... I noticed that it did not seem to want to generate interrupts even when I supposedly had the card strapped for them. Since I didn't have any internals documentation and I was more interested in getting a working driver quickly, I just ran the driver in polled mode. Success! Of course, when I did that, it ran slow as molasses and ate up a ton of CPU cycles waiting for seeks... so I added a REAL hack. Instead of polling, I'd schedule a clock task to go off and interrupt us a couple of ticks in the future... and I'd keep doing this until the poll succeeded. This worked, and took up a lot less of the machine (although the CPU-driven copy loops STILL eat up cycles like you wouldn't believe!). It's running on my system now... these days I use the SCSI drive mainly for archival storage and the MFM drive for working stuff. I'd planned to tune up the SCSI driver once I was able to get hardware docs for the ST01, but from what you tell me it looks as though I may as well not bother... If anyone is interested, I'll post the driver, but I offer NO guarantees or support. Strictly as-is! Jim Paradis, working at but not employed by DEC. (603)881-1221 paradis@decvax.dec.com "All I got was a rock!"
mde@cup.portal.com (Michael Dennis Evenson) (12/04/90)
I'd be interested in the SCSI driver you hacked from the unix post.