Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!endor!olson From: olson@endor.harvard.edu (Eric Olson) Newsgroups: comp.sys.mac Subject: Does anyone REALLY understand SCSI Booting? Message-ID: <2585@husc6.UUCP> Date: Wed, 22-Jul-87 18:55:11 EDT Article-I.D.: husc6.2585 Posted: Wed Jul 22 18:55:11 1987 Date-Received: Fri, 24-Jul-87 06:34:59 EDT Sender: news@husc6.UUCP Reply-To: olson@endor.UUCP (Eric Olson) Organization: Aiken Computation Lab Harvard, Cambridge, MA Lines: 80 Keywords: SCSI Bus Summary: Mac SCSI changes often 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