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