HOW_TO_UPGRADE_AN_RZ_DRIVE.TXT version 1.2 12/22/1995 This is a document that I am putting together showing what we currently have at our disposal to load code into devices. Some tools we Engineering have or provide are totally unsupportable because the code is either legacy code in executable format only with no source code available, given to us by Vendors as a nice-ity with no support. Engineering uses these tools to upgrade our own drives for code evaluation purposes and Field use is not always the design intent. Others tools we ourselves develop are supportable an I will try to indicate these. These tools are designed for "other than Engineering" use and have a little more intuitive interface that what Engineering needs. ALWAYS READ THE RELEASE NOTES AND MAKE SURE YOU ARE LOADING THE CORRECT VERSION OF FIRMWARE IN THE CORRECT DRIVE REVISION OR YOU WILL DESTROY THE DEVICE!! NEVER LOAD FIRMWARE FILES DESIGNATED FOR ONE DEVICE INTO ANOTHER AS YOU CAN LOSE ALL CUSTOMER DATA OR WORSE YET, DESTROY THE DEVICE. EX: RZ29B and RZ29C are the same hardware but different geometry and characteristics. Loading RZ29B code into a RZ29C is unsupported and will lose all data as you must now reformat the device for the geometry change. This follows true in any RZ29C -> RZ29B change also. EX: RZ28M version 568 will work on all drives, but loading older 466 into some newer revision B01 RZ28M's will destroy them. Roger Patenaude SEP Continuation Engineering ****************************************************************************** Draft index of this document... CURRENT WAYS TO LOAD... Loading code under VMS... Loading code under Digital UNIX... DEDICATED TESTERS... PROPRIETARY SOFTWARE... CONTROLLER BASED... ALPHA ARC CONSOLE... (Advanced RISC Computing Standard Specification) Some controller restrictions... Loading WIDE drives VS. NARROW drives... ****************************************************************************** CURRENT WAYS TO LOAD... The following is a summary of current alternatives for upgrading drive firmware. Current Alternatives Summary ============================ O/S, Platform Directly Attached Mylex HS* ------------- ----------------- ----- --- VMS, Alpha/Vax RZXX Standalone Loader No Solution No Solution or RZTools (Quantum Only) Digital UNIX, All SCU Utility No Solution No Solution Alpha, PCI Systems Indiana V1.0 No Solution No Solution INTEL, Adaptec based CoComp No Solution No Solution INTEL, parallel port SCSI Tester No Solution No Solution Note: The only mechanism for upgrading drive firmware in configurations not supported explicitly is to remove the drive and place it into a configuration which is supported. The recommended configuration at this time is Digital UNIX running SCU. Note: VMS currently has a 64KB I/O size limitation. Most all Seagate .LOD file however need to be loaded in one single 256KB I/O. This excludes VMS based loaders as an option. ****************************************************************************** Loading code under VMS... A) STANDALONE LOADER PROGRAMS This file although somewhat dated describes the .EXE files and how they are used. These files were developed by Engineering to upgrade Engineering drives for firmware evaluation. They have been made available to the field as a courtesy and any support provided will be minimal as all the original developers no longer work for Digital. NOTE: These files will NOT work on Seagate based drives as in the RZ25L, RZ25M, RZ28B, RZ28D, RZ29B and RZ29C drives or any SW/SH drives that uses these Seagate based drives. At this time, these files have been tested up to VAX/VMS 6.0 if you try to run on older version you may see an error like this; Loading via MTS download %SCSI-F-BADREQ, Illegal request or bad parameter. If you have a problem with them send mail to BABAGI::PATENAUDE "as a notice only" with your configuration. That way if we EVER do any work involving these loaders your problem will be addressed. We Digital have no source code for these loaders and such cannot support them. ALWAYS READ THE RELEASE NOTES AND MAKE SURE YOU ARE LOADING THE CORRECT VERSION OF FIRMWARE IN THE CORRECT DRIVE REVISION OR YOU WILL DESTROY THE DEVICE!! RZxx Standalone Loader Program OVERVIEW: The new drive firmware is contained within the program image. The program will check to ensure that the correct drive type is being loaded. If a mismatch is detected a message will be displayed. THIS PROGRAM ONLY WORKS WITH FILES WITH THE .FUP (QUANTUM DRIVE) EXTENSIONS! IT DOES NOT WORK ON .LOD (SEAGATE DRIVE) FIRMWARE FILES. RESTRICTIONS: 1. The program must be run from a privileged account such as the system account. 2. These utilities ONLY work on disks that are directly connected and will not work through any RAID controller (HSZ40, SWXCR, ETC...) 3. The process working set quota must be set to 1024 or greater. Use the DCL command SHOW WORKINGSET to view the present settings. Run AUTHORIZE to change these parameters. If parameters are changed it requires that you LOGOUT then log back in for the new parameters to take effect. 4. The target disk drive must be dismounted unless the drive is a booted system disk. 5. When upgrading the mounted system device the system must be booted MIN. The SYSGEN parameter STARTUP_P1 must be set to "MIN" either by using the SYSGEN utility or by performing a conversational boot 6. It is recommended that any open files on the disk be closed. Typically this would require the OPCOM and ERRFMT process's to be stopped. UPGRADE PROCEDURE: IT IS RECOMMENDED TO BACKUP THE RZ DRIVE BEFORE RUNNING THE PROGRAM, AS IN THE EVENT OF A FAILURE, ALL DATA MAY BE LOST. 1. The drive must be dismounted from the system, unless it is the booted system disk. When upgrading the system disk the system activity must be at a minimum. On a multi-disk system an alternative is to boot from another disk and upgrade the target as a dismounted disk. Shadowed disk can be upgraded by removing one drive from the shadow set, upgrading that drive, mounting the upgraded drive back into the shadow set and allowing the copy to complete. Then the other member can be removed and upgrade using the same method. If the drive should "Fault" during the upgrade, check to insure, if implemented, the FLASH enable jumper is installed. Be sure that the power is removed from the drive before installing or removing the jumper. For the RZ73, the FLASH enable jumper (12-36482-01) is installed between pins 19 to 20 on connector J3. J3 is located between the power plug and the SCSI connector. For the RZ35 and RZ26 the jumper is located on the right hand side, half way down the module while hold it with the SCSI connector facing you. The FLASH enable jumper part number is (12-36482-01). Run the program. The program can run directly and will prompt you for the device to load. $ run rz26_t388c_dec RZ26 Download Procedure (Rel. 3/16/93 Test Apache Rev) Enter Device Name: dka0: Beginning RZ Download procedure on _SIXIRN$DKA0: Firmware Version: Current T386F Loading T388. Comparing the Firmware Type to the Drive Type and Apache Chip Rev. Firmware and drive type match. ATTENTION: This drive may require an installed flash enable jumper to complete the upgrade. Enabling code load protocol in device.. Loading via SCSI write buff...... New code has been sent to the drive. *** Drive will become available after calibrations complete. *** Firmware rev successfully updated to T388. Disabling code load protocol in device.. %LOAD-S-COMPLETE, Load Completed B) RZTOOLS As a second way of loading code under VMS if the loaders fail to work, obtain a copy of RZTOOLS from the BABAGI::LCA:[specs.misc.rztools] directory and use it to load the .FUP file. This is a little more work but it will work. NOTE: These files will NOT work on Seagate based drives as in the RZ25L, RZ25M, RZ28B, RZ28C, RZ29B and RZ29C drives or any SW/SH drives that use these Seagate based drives. To use RZTOOLS you would define a local symbol for the image as in the following string; $ RZT :=="$sys$login:RZTOOLS.EXE" Where sys$login: is where I had my copy, and RZTOOLS is the image name. Then issue the following command; $ RZT DKA500: /LOAD=filename.FUP Where DKA500: is the drive I happen to be loading, and filename.FUP is the binary firmware file to be loaded. You will get an output like this; $ rzt dka500: /load=RZ28_XD41C_DEC2104.FUP;1 Read in 262144 bytes. Current FW version - DEC0 <- the Vendor name for 442D Upgrading to - XD41C <- I down graded the drive to XD41C (pass 6) Loading code ...... New code has been sent to the drive. $ ***************************************************************************** Loading code under Digital UNIX... ALWAYS READ THE RELEASE NOTES AND MAKE SURE YOU ARE LOADING THE CORRECT VERSION OF FIRMWARE IN THE CORRECT DRIVE REVISION OR YOU WILL DESTROY THE DEVICE!! FIRMWARE DOWNLOAD INSTRUCTIONS FOR RZ DRIVES USING SCU UTILITY. OVERVIEW: SCU is a utility that runs under the UNIX operating system and can be used to download FW to disk drives. For more info on other SCU features, invoke SCU, then type help. THIS PROGRAM WORKS WITH FILES WITH THE .FUP (QUANTUM DRIVE) EXTENSIONS AND IT WORKS ON .LOD (SEAGATE DRIVE) FIRMWARE FILES!! It also works on the EZ5x family of solid state disk products. This utility does however ONLY work on disks that are directly connected and will not work through any RAID controller (HSZ40, SWXCR, ETC...) DETAILS: Using a system that is running UNIX operating system, connect the drive to be upgraded to the UNIX systems SCSI bus. Load the firmware file from tape to system disk. Now use SCU to download the new Firmware and check after to ensure the drive has the new FW loaded. A short test of the drive should be done to ensure it's functioning properly. You may have to perform a "makedev" if the system was only configured with minimal disks at build time. Note: It is required to backup any valuable data from the disk drive prior to the FW download. EQUIPMENT REQUIRED: o SYSTEM WITH UNIX loaded on it. o RZ drive to be upgrade. o A binary firmware file for the specific drive. PROCEDURE: Copy the .FUP (Quantum) or .LOD (Seagate) to the system being used. Connect the disk drive to be upgraded to the SCSI bus, and power up. The device cannot be mounted to the file system or hanging off of a RAID controller. To get into SCU type the following: "scu -f /dev/rrzxg " (where x equals the device SCSI ID # of the unit you wish to upgrade) You should get the prompt SCU>. Under SCU you can do an Inquiry to the drive by typing: "show device" (This will show you what type of drive it is and the current FW level). To perform the download, type the following: "download filename save" (Where filename equals the full name and path of the binary file. For example, to load an RZ28 with 442D you would use; SCU> download rz28_442D_dec.fup save The download may take a short while. When the download has completed you get the SCU prompt. DO NOT ABORT THE DOWNLOAD AFTER STARTING IT FOR ANY REASON OR THE DRIVE WILL BECOME BRAIN DEAD! After load you may have power cycle the device to use the new firmware. To check that the download completed OK, type: "show inquiry" you should see the new FW version listed (you may have to power cycle the drive or exit and re-enter SCU). Remove the disk from the UNIX system and install it on the original system and perform a short test to ensure all is working properly. ***************************************************************************** DEDICATED TESTERS... One of the main things I use to load code in the lab and office is a SCSI bus tester. These range from a 14K tester/analyzer setup to a $600 PC based parallel to SCSI adapter. My tester of choice (today) is an ITECH PocketTest (IPC-100) running IXDL (Itech, eXerciser, DownLoad utility). The tester can be purchased from; Sierra Technologies 1800 Bayonne Court Bel Air, Maryland 21015 (410)838-2108 Attn: Steve Greenberg NOTE: I am NOT affiliated with this company, I just use the product and find it works for code loading quite well.. I'm sure other companies make a similar product, this just happens to be the one I use. To use it you plug the little adapter into you parallel port and run IXDL100.EXE (can be copied from ITECH's BBS or from BABAGI::LCA:[SPECS.MISC]ixdl100.zip), then enter the download menu and specify the name of the file you've copied from BABAGI and your off and running. IXDL100.EXE is a DOS application that is written SPECIFICALLY for the PocketTester. ***************************************************************************** PROPRIETARY SOFTWARE... One tool on the market the uses standard ASPI compliant hardware (1540, 1740, 2740, etc...) called SCSI Toolset(TM) marketed by a company called CO Comp, Inc. works quite well and we (Storage External Products) are working with them to make it even better. To obtain a base copy making you eligible for updates (currently you need version 1.91h to support RZ29B) contact; CoComp, Inc. 2330 S. McClintock Drive Tempe, AZ 85282 (602)784-4801 NOTE: I am NOT affiliated with this company, I just use the product and find it works for code loading quite well.. I'm sure other companies make a similar product, this just happens to be the one I use. This product is supported under Windows 3.1, Windows 95 and Windows NT and currently ASPI (Adaptec) Based controllers. This means you can use a HiNote Laptop with the SlimSCSI adapter to load firmware into most anything except EZ5X products. ***************************************************************************** CONTROLLER BASED... At this time there a a few different platforms and controllers that have built in download utilities but these are ALL still in development and will be released within the next 2 quarters. As these EXISTING controllers start shipping with this new feature tested I will update this section. NEW!!! ALPHA ARC CONSOLE... (Advanced RISC Computing Standard Specification) INDIANA is the project name for the ability to load firmware using the native console on PCI based ALPHA systems. The ARC executable program to do this is called DISKUPD.EXE and currently support only the RZ29B version 0014 upgrade. This program needs a minimum of ARC console revision 4.42 to run. Currently I have tested this on AlphaServer 2100 using the embedded NCR 53C810 SCSI controller with more testing in progress and with more hardware support to follow. All that is needed to to run this program are in two files located in the BABAGI::LCA:[SPECS.MISC] directory; ARC443.ZIP once unzipped to a 3.5 floppy under DOS contains all that is needed to upgrade a AlphaServer 2100 to ARC console to revision 4.43 DISKUPD.ZIP once unzipped to a 3.5 floppy under DOS contains all that is needed to upgrade RZ29B drives to revision 0014 firmware. Referred to as INDIANA V1.0. ***************************************************************************** Some controller restrictions... SWXCR ----- Current KZPSx/KZESx and Mylex Controllers do not have the capability to issue a 256KB Write Buffer command needed to load code in a good portion of our drives. For this reason you can not load code through them today. IMPORTANT: DO NOT DISCONNECT OR MOVE ANY DEVICES OFF OF THESE CONTROLLERS BEFORE MAKING SURE THE CONFIGURATION OF THE CONTROLLER IS BACKED UP. THIS IS THE ONLY WAY TO SAFELY RESTORE THE CONFIGURATION IF THE CONTROLLER IS INADVERTENTLY POWERED UP WITH THE DRIVES MISSING. HSxxx ----- Because controllers like the HSJ40/30, HSD30 and HSC controllers are accessed VIA MSCP protocol and MSCP has not provisions for a Write Buffer command, so it is not possible to load code from the Operating system through these controllers. The controllers themselves at the SCSI level ARE capable of doing Write Buffer but host access to this feature is not possible. Note: The HSD05 and HSD10 also fall to the MSCP restriction AND they also do NOT have Write Buffer capability To load code on devices connected to these controllers you must disconnect them from the Raid controller and move them to a direct connect bus. ****************************************************************************** Loading WIDE drives VS. NARROW drives... Updating wide drives is handled EXACTLY like narrow drives. The only trouble is when you try to load them using a 8 bit controller (EG: KZPAA or ITECH IPC-100). 16 bit transfers are negotiated just like synchronous and command queuing. Using a 16 bit device on a 8 bit controller leaves the upper 8 bits unused. This is ok as the 8 bit controller does not know how to negotiate to 16 bit so the drive will not use its upper bits for data phase. The only problem is if you ground the upper 8 bits. The 16 bit drive will see that and always think that someone at a higher arb than him is on the bus (SCSI uses data lines to put their ID on the bus) and never respond to any inquiry. Note: This is what happens when you try a wide drive on a AlphaServer-1000 (AKA: Mikasa) using narrow controller. They do have a new terminator available to pull up the lines instead of grounding them. Note: This is also what happens if your bus has an OLD -VA drive (pre 12/94) that has the upper bits grounded on the same bus as your wide device. Using a mix of 8 and 16 bit devices on a 16 bit controller works fine. When the 16 bit controller sees an 8 bit device in the returned inquiry data it leaves it at 8 bit and when he see 16 or 32 (yup it's in there) it will commence to negotiate for 16/32 bit only with that device.