olson@endor.harvard.edu (Eric Olson) (07/23/87)
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 Inside Mac Volume IV, p. 293, "The system startup procedure takes the following steps: 1. It attempts to select the first target device on the bus by its ID, beginning with the device, if any, having an ID of 6. 2. It reads the first 256 bytes of physical block 0, checking for the signature indicating a valid driver descriptor map ($4552). It then reads the device partition map from physical block 1 and checks for the proper signature ($5453). 3. It searches the driver descriptor map for a driver for the Mac. 4. It reads the driver from the indicated physical blocks into the system heap, using standard SCSI read commands. It checks for a proper driver signature. 5. It calls the driver to install itself, and passes a pointer to the device partition map for examination by the driver. 6. It performs steps 1 through 5 for all other SCSI devices on the Bus. Note: During system startup, the SCSI Manager may call SCSIReset after your driver has been loaded." Now, I looked at the code in the ROM, and it does, essentially, what is described above. Our solution was to have our box release the SCSI bus after 1/2 second of idle time, since (in the application code) we would never pause that long. This fix was unneeded on an SE (the SE times out and goes on to the next bus address), and works fine on a Mac+ w/FX20 under system 4.0/Finder 5.4, but fails on a Mac+ w/FX20 under system 4.1/Finder 5.5! The SE is running 4.1/5.5, incidentally. The symptom of failure on the Mac+ w/FX20 4.1/5.5 are: If box address higher than disk address, boot gets to "Welcome to Macintosh" which is then (quickly) replaced by an ID=2 bomb (with the Resume button available, stangely enough-- pushing it restarts). If the box address is lower than the disk address, boot gets to "Welcome to Macintosh" and then just stops. The symptom of failure on the Mac+ w/FX20 4.0/5.4 before we made it time out was that the boot sequence would just sit there, continuously trying the box over and over (it selects, we timeout, it selects, we timeout,...). I believe the new system is going back to "found" SCSI devices after it gets ahold of the System File and trying to do something else with them. It doesn't bother, apparently, to check whether any of the above signatures were any good on the "found" SCSI devices. I NEED HELP WITH THIS ONE! WHAT'S GOING ON????? If anyone knows someone I can call, mail, email... whatever about this, I would be eternally grateful (or at least for a week or so). Anyone at Apple know what's going on here? Thank you all in advance. -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
brian@casemo.UUCP (Brian Cuthie ) (07/23/87)
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