.EH "''Rev. C1 ERS''" .OH "''Rev. C1 ERS''" .H 1 "INTRODUCTION" This document describes the plans for the s300 Bootrom Revision C1 . The bootrom software will be responsible for testing a very few critical system components and for booting an operating system. .ni .P There are five sections to this document. The first section is an introduction, the second section presents the strategy for s300 Boot ROMs, and the third section describes the actual implementation plans for Rev. C1. Section four is a User's Manual for the bootrom, and section five is a Programmers Guide for system programmers. .P Included in the description section is a discussion of other projects which must be coordinated with this revision, a schedule and development plan, a list of features to be implemented, and a quality assurance plan. .P NOTE: Certain versions of this manual may be missing the Programmers Guide because it is very long. If you need this section, please contact Robert Quist, x3427, e-mail hpfcla!quist, mail stop 99 . .H 1 "PROJECT BACKGROUND INFORMATION" .H 2 "Series 300 BOOTROM Rev. C1 PDS" .SP .DS Project Number: I-7546 Project Name: Crabapple Project Manager: John Schmidt Revised: April 19, 1988 .DE .SP .DS CONTRIBUTION The primary contribution of this rev of the bootrom is fixing defects found in the REV C BOOTROM. .DE .SP .DS MUST OBJECTIVES - Allow IODC test on console to execute. (Properly support DaVinci.) - Fix SCSI driver to properly id the SCSI interface. - For console testing, execute IODC code BEFORE doing normal console turn on. - Fix timer vector interface to IODC code. - Fix SCSI drivers to enable/disable parity checking according to the switch setting. .DE .SP .DS HIGH WANT OBJECTIVES - For SCSI add the test for bus free interrupt. - Fix BOOT ROM to checksum all of itself. - Put timeout handling code in CRT init interpreter. - Put delay after SCSI reset to allow reboot from HP EAGLE drive. .DE .SP .DS NON-REQUIREMENTS - New device support. - Fixes for low weight defects. .DE .SP .DS RESOURCES - 1 MTS, Robert Quist (0.5 time) - 1 PME, Don Boxley .DE .SP .DS DEPENDENCIES - availability of a SCSI drives for parity testing - availability of a Da Vinci system - shipping date of Da Vinci systems. - demands on STAFFING from other projects .DE .SP .DS ISSUES - What to do about Rev C bootroms already shipped - Changing the upgrade kit(s) involving Rev C to include Rev C1 - Does new bootrom mean new CPU board numbers ? .DE .SP .DS ASSUMPTIONS - appropriate DaVinci systems & SCSI disk drives will be made available by the lab groups currently working on them. .DE .SP .DS FORECAST - 20 Apr 88 Requirements Check Point - 16 May 88 Start of Formal Testing - 27 May 88 End of Formal Testing - 1 Jun 88 Release to Manufacturing .DE .H 2 "Boot ROM History" .P This project is needed defects fount in Rev. C which could not wait for a major revision. These defects affect the testing of DaVinci when it is the console and the SCSI drivers when a 98630 Breadboard interface is present. A few minor defects were also fixed at this time. These low priority fixes were included because they would not affect the total elapsed time of the project. .P The code is based on the Series 300 Rev. C . .SP .H 2 "s300 Boot ROM Strategy" .P The following strategy should be followed in the development of Series 300 bootroms: .AL .LI Boot ROM development should better utilize software development resources. .LI Boot ROMs feature sets should fit into the product strategy. .LI Hardware costs for bootroms should be minimized. .LI Boot ROM functions and capabilities should be minimized to keep the bootrom size minimal, to keep the Q.A. effort reasonable and to keep bootrom code maintainable. .LI As bootroms are very expensive to turn, they should consist of high quality, well tested code. .LI Boot ROM releases should support service and production needs by minimizing such things as inventory costs and production changes. .LI Boot ROM code should be as flexible and adaptable as possible in order to maximize future opportunities (i.e., support of future features and peripherals should be included whenever possible). .LE .H 2 "s300 Boot ROM Tactics" The following is a list of tactics which will be used in the s300 bootrom in an attempt to adhere to the s300 bootrom strategy. .AL .LI One bootrom should work on all s300 family products. This tactic will keep service and production inventory costs down and will ease Q.A. efforts. (circumstances changed beginning with Rev. C to the point where 310 and 320 SPUs are now equipped with Bootrom Rev. B and all the others will be equipped with Bootrom Rev. C1) .LI Boot ROMs should NOT be retrofited to old CPU boards in the field. This will minimize the effort required to maintain and Q.A. bootroms and will better utilize software development resources. .LI S300 bootroms should not exceed 64K bytes of code in order to keep hardware costs down. After much discussion and investigation it was determined that there was no reasonable way to provide the capabilities required of Rev C and keep within the 64k limit, even after unused code was removed. The situation is not likely to change with later releases. .LI Boot ROMs should only test interfaces absolutely required in order to boot a test system (i.e., HP-IB interface, RAM, CPU board timer, CRT and keyboard, but not MMU, cache, or floating point hardware). This, too, will minimize the effort required to maintain and Q.A. bootroms and will better utilize software development resources. .LI Boot ROMs should be able to boot from all devices that fit into the product strategy. .LI Boot ROMs should not have features which do not fit into the product strategy (i.e., boot from devices which do not fit into the strategy, print bootrom messages on laser printers, etc...). This will minimize bootrom features and capabilities and will ease the Q.A. efforts, maintainability, and development of bootroms. .LI The bootrom should attempt to ID all known internal and external backplane cards and human interface features. However, it should not notify users if a piece of hardware is "missing". This, too, will minimize bootrom features and capabilities and will ease the Q.A. efforts, maintainability, and development of bootroms. .LI As much code as is possible should be leveraged from existing bootrom code. This will better utilize our resources and will ease the Q.A. effort. .LE .H 1 "PROJECT PLANS" This section describes the actual plan for bootrom Rev. C1. As of 20 Apr. the concerns driving the MR are: .AL 1 .LI Shipment date for DaVinci systems. .LI Shipment date for 360 (weasel) systems. .LI Shipment date for HP-UX 6.2 . .LI The number of SCSI systems which may have to be upgraded. .LE .SP .H 2 "Schedule and Development Plan" .DS The schedule for the Rev C Bootrom is a follows: - 20 Apr 88 Requirements Check Point - 16 May 88 Start of Formal Testing - 27 May 88 End of Formal Testing - 1 Jun 88 Release to Manufacturing .DE .H 2 "Staffing" One MTS, Robert Quist, is staffed for the entire project from April '88 through May 88. .H 2 "Future Boot ROMs Planned" .P At this point there are no specific plans for a future Series 300 bootrom. There are a set of requirements emerging which will likely result in a Rev. D boot ROM to be released no sooner than March of 89. Two major items at this point in time are: 1. boot from a DAT tape drive which is a serial device. 2. requests to support dumb terminals as a boot console. .SK .H 2 "Quality Assurance Plan" .H 3 "Q.A. Schedule and Criteria" Formal Q.A. is scheduled to begin on 16/May/88 .SP The criteria for entry to formal Q.A. are as follows: .AL .LI Designer acceptance, .LI Conformance to ERS, .LI Features frozen and preliminary documentation to manual writers, .LI Reasonably stable code (i.e., works in all normal situations), .LI All hardware required for Q.A. available, (identified) .LI Formal Q.A. plan completely in place, .LI Code has been tried successfully in all target machines (as best available prototypes will allow), and .LI Code is complete. .LE .SP 2 The criteria for release to manufacturing are as follows: .AL .LI Designer acceptance, .LI Project manager acceptance, .LI Complete coverage of "MUSTS" in Q.A. plan, .LI Less than two defects of weight greater than 0.5 found during the last week of Q.A. testing, and .LI All known defects of weight 0.5 and greater fixed. .LI No code changes during the last week of Q.A. testing. .LE .SK .H 3 "Defect Weighting" The following defect weighting scheme will be used: .BL .LI Weight of 1.0 .DL Li 1 .LI The user cannot use the product for the purpose for which he bought it. .LI The reasonable expectation of the user is not met, and no work around exists. .LI Major features are not working. .LI The system crashes. .LI Data is permanently lost from the mass storage media. .LI Crucial information is incorrectly given. .LE .LI Weight of 0.7 .DL Li 1 .LI The product can be used to solve the user's problem, but it is much harder than expected. .LI The reasonable expectation of the user does not work, and a workaround is difficult. .LI Important information is incorrectly given. .LE .LI Weight of 0.5 .DL Li 1 .LI The product will solve the user's problem, but the solution is not simple. .LI The reasonable expectation of the user is not met, but the workaround is simple. .LE .LI Weight of 0.3 .DL Li 1 .LI The product will solve the user's problem with minor annoyances. .LI Incorrect input is not handled well, but it has no serious results. .LI Misleading, but non-vital, information is displayed. .LE .LI Weight of 0.1 .DL Li 1 .LI The defect is cosmetic. .LI The product solves the problem, but could be better. .LE .LI Weight of 0.0 .DL Li 1 .LI No problem exists. .LI Duplicate defect. .LI The users misunderstood the problem. .LI The problem is not repeatable. .LE .LE .P Probability of occurrence of a defect can cause the weight of that bug to move up or down by 0.2. .SK .H 3 "Emphasis of Q.A." .SP .H 4 "general strategy" .P The changes in this revision are primarily defect fixes and have little or no impact on other code. QA testing will concentrate on testing the specific code changes. The regression testing will be only sufficient to check for the loss of major capabilities. .H 4 "objectives" .DS MUST OBJECTIVES ITEMS: 1- work with DaVinci IODC test code 2- work with 98630 breadboard interfaces. 3- IODC timer interface must work 4- work with SCSI drives which don't implement parity checking HIGH WANT OBJECTIVE ITEMS: 5- detect failure of SCSI bus going to free state. 6- detect checksum failures in the high 16K of the bootrom 7- detect stuck bits in display interface 8- reboot with SCSI eagle (350 or 330 with 204B display) .DE .H 4 "specific tests" .DS 1 STATUS for - work with DaVinci IODC test code Pre QA testing done. Pre QA releases of Rev C1 are being used in production for testing new DaVinci systems. Code for this area has not changed. ACTION ITEMS 1. Have the production machines upgraded to the current release. 2. demonstrate correct operation by configuration testing. DaVinci some other display ---------+-------------------- a internal [x] b internal dio II [x] c dio II [x] d dio II internal [x] e internal dio II [x] failed [x] (failure was forced) f dio II dio II internal [x] failed [x] (failure was forced) g external [x] tested at select code 30 .DE .DS 2 STATUS for - work with 98630 breadboard interfaces. pre QA testing done ACTION ITEMS locate a breadboard interface and try it [x] SCSI present at higher select code [x] SCSI present at lower select code [x] SCSI absent .DE .DS 3 STATUS for - IODC timer interface must work Pre QA testing none done ACTION ITEMS create test code which uses this feature install it on a LCC catseye (98549A) [x] .DE .DS 4 STATUS for - work with SCSI drives which don't implement parity checking pre QA testing done ACTION ITEMS 1.use the SCSI led board to pull on parity while booting [x] 2.locate a drive which does not implement parity, [x] demonstrate failure to boot with parity enabled [x] demonstrate success with parity disabled [x] demonstrate loopback test fails with parity jammed .DE .DS 5 STATUS for - detect failure of SCSI bus going to free state. pre QA testing done (initial code failed, found and fixed a defect) ACTION ITEMS 1. demonstrate passes [x] cable not connected [x] cable connected to drive (drive off) [x] cable connected to drive (drive on) [x] two drives in all combinations of drive on off states 2. demonstrate error detection [x] use the SCSI led board to stop the bus from going free. .DE .DS 6 STATUS for - detect checksum failures in the high 16K of the bootrom pre QA testing done ACTION ITEMS [x] demonstrate no error currently [x] use soft rom to jam errors and demonstrate failure in high 16K .DE .DS 7 STATUS for - detect stuck bits in display interface pre QA testing done works ok on 330 & high res mono topcat rev EC1A failed with DaVinci. fixed in rev EC1B ACTION ITEMS [x] find a way to jam a bit on any display to demonstrate failure detection. [x] demonstrate working with current code via matrix testing. The concern is that the timing has changed in the execution of the CRT turn on pseudo code. crt +--------------------------- controller | SPU |320|330|350|360|370| +------+---+---+---+---+---+ 98541A VGA (avail in NOV) | | | | x| | 98542A 512x400 b&w | | | | x| | 98543A 512x400x4 color | x| | | | | 98544A/B 1024x768 b&w | | x| x| x| |rev A only 98545A 1024x768x4 color | | x| | | | 98547A 1024x768x6 color | | | | x| x| 98548A | | x| | x| | 98549A | | x| x| x| x| 98550A | | x| | x| | 98287A 98700A/H gator box | not tested | | 98725A 98720A Renaissance | | | x| x| | 98726A 98730A DaVinci | | x| x| | x| ----------------------------------------------------- 310 with built in [yes] 318 with built in [ ] not tested 318s will only have Rev B 319 with built in [yes] =============================================================================== These tests only cover the Bit Map Displays (BMD) since only low level BMD code was changed. .DE .DS 8 STATUS for - reboot with SCSI eagle (350 or 330 with 204B display) pre QA testing done ACTION ITEMS [x] test SCSI eagle with 330 & 204B interface| 350 demonstrate booting and rebooting. Rev 1B with 330 and 204B display. .DE .SK .H 4 "Regression testing" .DS boot latest versions of HP-UX, BASIC, PWS on at least one configuration. [x] HP-UX with (HPIB [x] & SCSI [x] & LAN [x]) [x] BASIC with (HPIB [x] & SCSI [x] & SRM [x] & LAN [x]) [x] PWS with (HPIB [x] & SCSI [x] & SRM [x] & LAN [x]) DaVinci [x] normal testing [x] extended testing [x] continuous testing SCSI [x] normal testing [x] extended testing [x] continuous testing boot sources [x] hpib disc [x] scsi disc [x] LAN [x] SRM [x] ROM console [x] bit mapped [x] alpha [x] rs232 .DE .H 4 "Special testing" .DS [x] arrange to have some 360 systems equipped with Rev. C1 EPROMS [x] arrange to have some 370 systems equipped with Rev. C1 EPROMS .DE .H 4 "SCSI driver path forcing .DS [x] cause parity errors [x] power cycle SPU while drive is operating [x] issue bus reset .DE .SK .H 3 "Bit Comparison of Unchanged Code" .P Several blocks of code will be lifted from the series 300 Rev A2 bootrom with no change (i.e., math tables, etc.). Therefore, the only testing this code should require is a bit comparison with the Rev A2 bootrom bits to verify that it has not changed. .H 3 "Final bit tests" .P this final change & test procedure consists of changing the Rev id from the last QA rev id to the production rev id, regenerating the checksums then comparing the new bits against the old to verify that only the rev id and checksums have changed. .SK .H 3 "Q.A. Priorities" The following lists the MUST tests for exiting Q.A.: .DL .LI All known defect reports resolved .LI All fixed defect reports verified .LI Final bit tests complete .LE .SP Before manufacturing release mtg: .AL .LI Final code verified .LI Q.A. documentation complete .LI M.R. documentation complete .LE .SP Available at release to mfg time will be: .AL .LI A drawing describing how to recreate this rev. from the source .LI A drawing containing the Notebook (this document) .LI Five 3.5-inch floppies containing the bootrom source in LIF format. as well as the code generation utilities, LAN test suite and IODC test code. .LE .SK .H 3 "DEFECT REPORT" .DS =========================================================================== Defect reports beginning with rev EC1f =========================================================================== EC1f (last release before formal QA) 1. SCSI boot with parity disabled, and parity jammed hangs bootrom SCSI boot with parity enabled, and parity jammed reports No device 7 fixed in EC1A EC1A created 12 May 88 (first release for formal QA) 2. DaVinci fails turn on. Weight 1.0 fix was in new code, fix was to invert the sense of a conditional branch fixed in EC1B EC1B created 17 May 88 3. Call to bus free test was commented out Weitht 1.0 fix was in new code. fix was to un comment the call. fixed in EC1C EC1C created 19 May 88 no defects found .DE