Path: utzoo!attcan!uunet!decwrl!sgi!shinobu!odin!anchor!olson From: olson@anchor.esd.sgi.com (Dave Olson) Newsgroups: comp.sys.sgi Subject: Re: CD-ROM offer [ details on implementation ] Message-ID: <1991Feb15.004413.26956@odin.corp.sgi.com> Date: 15 Feb 91 00:44:13 GMT References: <9102131750.AA08632@scripps.edu> <1991Feb14.021900.8427@odin.corp.sgi.com> <1991Feb14.155649.20613@utstat.uucp> Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 48 In <1991Feb14.155649.20613@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: | In article <1991Feb14.021900.8427@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: | >In <9102131750.AA08632@scripps.edu> jwk@SCRIPPS.EDU (John Kupec) writes: | > | > | >By the way, the CDROM drive(s) we end up supporting will have custom | >proms in the drive, in order to support booting from existing CPU | >proms. The main change is to default to 512 byte blocks instead of | >2048, and secondarily to claim in the inquiry command that they are | >device type 0 (hard disk). Re-powering the drive, or a SCSI bus reset | >will cause it to revert to the hard-disk mode (it has to do it on a bus | >reset for installs to work correctly after an init 0 without | >re-powering the CPU). | > | | Why not change the boot proms on the CPU side instead? | | Convince me that this would be more expensive than the charging scheme | that I see on the back of the CD-ROM jewel case. I don't know anything about the fees that will be charged for CDROM software updates, except that they are supposed to be less than for tape. Upgrading CPU proms has 2 main problems, of which the first is probably the most significant to the engineering community, and the second to the bean counters: 1) creating AND testing new proms for every machine and configuration out there would be a huge engineering job, and one that no one wants to do (we would rather give you new features on existing machines, and new machines). 2) changing cpu proms would require an FE for many sites (not all). Any time you open up a machine and take out the boards, you tend to expose problems that were lurking (heat stress, oxidized connectors, etc., etc., and then you are looking at downtime for the customer and even more expense. someone has to pay for it, either directly, or indirectly in higher costs on future products. NOTE: as always, these are my opinions, and not the official opinion of SGI... -- Dave Olson Life would be so much easier if we could just look at the source code.