Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!aplcen!casemo!brian
From: brian@casemo.UUCP (Brian Cuthie )
Newsgroups: comp.sys.mac
Subject: Re: Does anyone REALLY understand SCSI Booting?
Message-ID: <211@casemo.UUCP>
Date: Thu, 23-Jul-87 09:22:28 EDT
Article-I.D.: casemo.211
Posted: Thu Jul 23 09:22:28 1987
Date-Received: Sat, 25-Jul-87 08:53:22 EDT
References: <2585@husc6.UUCP>
Organization: CASE Communications, Columbia, MD
Lines: 75
Keywords: SCSI Bus
Summary: SCSI phases

In article <2585@husc6.UUCP>, olson@endor.harvard.edu (Eric Olson) writes:
> Well folks, here's a good puzzle for you:
> 
> I am in the process of writing some software for an SCSI device for the Mac
> which is not a hard disk (or a tape backup, or anything of that sort).  It
> is essentially a data aquisition box.  Unfortunately, it screws up booting
> the Mac!  Here are some details:
> 
> 	Our SCSI box is not entirely conforming to the standard (that is
> essentially the root of this problem, probably).  When an SCSI hard disk
> is selected, it typically goes into a "Command into Box" mode.  The only
> ways out of this are to send it a command (from the Mac), a message request
> (which makes it go into "Message into Box" mode if it has one), or an
> SCSI Reset.  The need to be in command mode after selection, however, is not
> part of the SCSI specification (as far as I know).  Therefore, when our
> box is selected, it goes into an "Idle" sort of mode, waiting for the Mac to
> request a "Message into Box".
> 
> 	Now this wouldn't normally mess anything up, but, according to

...

> Thank you all in advance.
> 
> -Eric
> 
> 
> Eric K. Olson		olson@endor.harvard.edu		harvard!endor!olson


Eric, 

I suspect what you have here is a non-compliant SCSI box.  Any device which 
responds to a select must enter some valid SCSI phase.  Idle is *not* a valid
SCSI phase.  The SCSI bus must be viewed as being entirely target driven once
arbitration and selection have been completed by the initiator.  Thus the 
initiator (the MAC in this case) is waiting for the target to go into *some*
phase.  This phase should always be a command phase.  There are many devices 
which may be connected to a SCSI bus and each responds to some subset of the
SCSI command palet (ie, printers, tapes, disks...).  There are many commands
that are completely valid for one type of device which make no sense
at all for another (imagine trying to tell a printer to read block 10).

Generally an initiator will try to issue an INQUIRY command to at least find
out what kind of devices it has selected.  If the device is a resonable one,
it will usually remember what's at SCSI address X and not need to reissue
that command unless the bus has been reset.

Since IDLE is not defined (at least that I can remember...) to be a valid
SCSI phase, the initiator is siting there waiting to be able to issue a
command.  There is no specification as to how long one should wait for
a valid phase from a target before assuming the target has brain damage.
Some drivers will wait a short period of time and some drivers will wait
forever. 

In summary, your box is likely to confuse 99% of the existing SCSI drivers
in the world since it has control of the bus and does nothing to give the
initiator a clue.  If, as you suggest in your posting, you are able to 
fix it to release the bus after .5 seconds, then why not just let it go
into the command phase.  It should be able to respond to the INQUIRY 
command so it can tell any curious initiator what kind of device it is.
Otherwise, it may reject any commands it likes. Drivers expect this sort
of behavior from a target.  But any driver is going to expect to at least
be able to send commands to the target.

Hope this helps...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Brian Cuthie
CASE Communications
(301) 290 - 7443

ARPA:	brian@umbc3.umd.edu
UUCP:	...seismo!mimsy!aplcen!casemo!brian