.EH "''Programmers Guide''" .OH "''Programmers Guide''" .H 1 "PROGRAMMERS GUIDE" .H 2 "Introduction" This manual contains internal documentation on the Series 300 Bootrom , Revision C1. This version is the same as the Rev. C manual with minor corrections and additions. This manual is intended primarily for use by HP systems programmers, NOT for high level programming users. The less this manual is used, the more easy it will be to maintain compatibility with boot ROMs in the future. .P Revision C1 is primarily a bug fix version of Rev. C . The most visible changes are for SCSI and IODC execution in connection with the system console. Rev. C is derived from the s200 4.0 Bootrom and s300 Rev. B Bootrom, therefore, carries along many of the s200's externally referenced utilities, tables, and routines, no matter how small/big and/or useless, either to maintain compatibility w/ operating systems or because there wasn't time to remove them. (There is at least 12K bytes of code used only to maintain compatibility with the past s200 boot ROMs.) Note that much of this code was removed to make room for LAN boot drivers in Rev. B and more of it was removed or stubbed out in Rev. C to simplify various changes that were needed in Rev. C. Further changes may be required. Therefore, beware that any code not documented in this chapter as supported with this revision of the boot ROM .I may be removed at any time. SO DON'T USE IT! .R .SK .H 2 "Boot File/Area Formats" The formats are defined using pascal structure type declarations. The following types are used in these definitions: .SP .DS type bcd = 0..9; bcd12 = packed array[1..12] of bcd; unsgn15 = 0..32767; string16 = string[16]; .DE .SP .P The actual boot code data is the same for all formats. It consists of a sequence of load segments. Each load segment must begin on an 256 byte boundary. The first 4 bytes is the load address. The second 4 bytes is the number of bytes of code that follow in the load segment. .SP .DS Format For A Load Segment byte # 0 1 2 3 4 5 6 7 8 9 ----+---+---+---+---+---+---+---+---+--- | start address | no. of bytes | code text to be loaded for as ----+---+---+---+---+---+---+---+--- many sectors as is required. .DE .SK .H 3 "L.I.F. System File Format" System Record must be of the following format: .SP .DS LIF_vol_type = {LIF volume label} packed record LIFid: signed16; {Must be equal to -32768} LIFvolume_label: packed array[1..6] of char; LIFdir_start_address: integer; LIFoct_10000: signed16; {Must be equal to 4096} LIFdummy: signed16; {Must be equal to 0} LIFdir_length: integer; LIFversion: signed16; LIFzero: signed16; {Must be equal to 0} end; Directory Entry must be of the following format: LIF_dir_entry = {LIF directory entry} packed record LIFfile_name: pac10 {array[1..10] of char}; LIFfile_type: signed16; {Must be equal to -5822} LIFstart_address: integer; LIFfile_length: integer; LIFtoc: bcd12; LIFl_flag: boolean; LIFvol_number: unsgn15; LIFimplement: integer; {Execution Address} end; .DE .SP .H 3 "S.D.F. Boot Area Format" System record must be of the following format: .SP .DS SDF_vol_type = {SDF volume label} packed record SDFid: signed16; {Must be equal to 1792} SDFreserved1: packed array[2..3] of char; SDFreserved2: packed array[1..6] of integer; SDFlogical_block_size: integer; SDFboot_start_block: integer; SDFboot_block_count: integer; {Must be Non-zero} end; Boot Block must be of the following format: SDF_boot_head_type = {SDF boot block header} packed record SDFowner: signed16; {Must be equal to -5822} SDFexecution_address: integer; SDFfilename: string16; {Pad to 256 byte boundary} {Data follows} end; .DE .SK .H 3 "UNIX Boot Area Format" System record must be of the following format: .SP .DS UNIX_vol_type = {UNIX volume label} packed record UNIXid: signed16; {Must be equal to 12288} UNIXreserved1: packed array[2..3] of char; UNIXowner: integer; {Must be equal to -5822} UNIXexecution_address: integer; UNIXboot_start_sector: integer; UNIXboot_byte_count: integer; {Must be Non-Zero} UNIXfilename: string16; end; .DE .SP .H 3 "LAN System File Format" .P For booting purposes, the bootrom uses what is known as LIF EMBEDDED format. A LIF volume image is EMBEDDED in the FILE. This follows the L.I.F. standard as described above except that: .AL 1 .LI The directory may begin in either sector 1 or sector 2. .LI The files in the directory MUST all have the same start, length and type values. .LE .P During scanning of the directory, empty entries are skipped and both the logical and physical end of directory conditions are recognized. .P The LAN boot protocol is intended only to transport files NOT directories. The LIF volume image is used as a mechanism to provide the information normally supplied by the directory on a LIF volume. Neither the volume name or file names are ever examined. It is assumed that the correct name was used given to the boot server. .P The multiple files with identical type, start and length values is used by the HP-UX secondary loader. All HP-UX type system files boot the same physical file, which is the secondary loader. This loader then examines the name under which it was booted then loads the corresponding a.out file. .SK .H 3 "SRM System File Format" Below is the description of the packet used to create a system file on SRM. The body of the file is the same as for the other formats. .SP .DS const name_type_len = 16; type file_id_type = integer; gang_32bit_filler = integer; gang_16bit_filler = -32768..32767; long_boolean = record case integer of 1: (i : integer); 2: (fill1: gang_16bit_filler; fill2: gang_boolean_filler; value: boolean); end; gang_file_codes = packed record case integer of 0: (i: integer); 1: (firstword: -32768..32767; division_code: 0..63; dcd_system_type: 0..15; dcd_file_type: 0..63); 2: (si1:shortint; si2:shortint); end; name_type = packed array [1..name_type_len] of char; path_start_type = (start_root, {Start search at root directory} start_alternate {Start search at a working directory.} ); device_address_type = record address1 : integer; haddress : integer; unit_num : integer; volume_num : integer end; file_header_type = record num_file_name_sets : integer; working_directory : file_id_type; filler1 : gang_16bit_filler; path_type : path_start_type; root_password : name_type; end; linkfillertype = packed record requeue: boolean; zit1: byte; { unused } zit2: integer; { unused } oddbytefiller: byte; { unused } destaddr: byte; sourceaddr: byte; { These three bytes } len_lobyte: byte; { are filled in by } len_hibyte: byte; { the transmitting card } level: byte; end; send_header_type = record linkfiller : linkfillertype; message_length : integer; send_request_type : integer; user_sequencing_field : integer end; volume_header_type = record filler1 : gang_32bit_filler; driver_name : name_type; catalogue_organization : name_type; device_address_present : long_boolean; device_address : device_address_type; volume_name : name_type; end; send_createafile = record send_mess_header : send_header_type; volume_name_header : volume_header_type; file_name_header : file_header_type; file_code : gang_file_codes; {Must be equal -5822} record_mode : integer; max_record_size : integer; first_extent : integer; {Size in logical records.} contiguous_first_extent : long_boolean; secondary_extent : integer; max_file_size : integer; boot_start_address : integer; {Execution Address} num_protect_code_sets : integer; label_included_flag : long_boolean; start_name_sets : integer end; .DE .SK .H 2 "ROM Header Definitions" .H 3 "OS, OS and Boot ROM Extensions" The ROM header is an 18 byte entity found at 16K byte boundaries in ROM space. ROM space begins at 64k for Rev. B and 128K bytes for Rev. C1. ROM space ends at 4 Mbytes. There are two ROM systems that have only a 16 byte header, 1.0 HPL and 1.0 BASIC, and they are not supported on Series 300. A 16 byte header is present whenever bytes 14 and 15 both have only bit 6 set in bits 7..3. A 16 byte header is assumed to be part of a pair of 8K by 8 ROMS for checksum purposes. .P Anyone having any questions or desired additions should see Chris VanWoerkom. .SP .DS Byte Use ---- --- 0 Part of HDR: Must equal $F0 to have a header 1 Part of HDR: Must equal $FF to have a header 2 L: ASCII Character to designate System Name. (boot ROM only uses this if SYSTEM ROM bit of byte 3 is set) Values presently being used are: B for BASIC H for HPL 3 F: Flag for type of ROM. Bit 0 1=System ROM (LSB of the byte) Bit 1 1=Boot Extension ROM Bit 2 1=Language Extension ROM Bit 3 1=Disc Follows Header in Memory Bit 4 1=ROM should not be checksummed Bit 5-7 Reserved at 0 4-7 BOOT XQT: Address relative to start of header to start execution of a BOOT EXTENSION ROM. If this is not a BOOT EXTENSION ROM, then this location can be used for storing a checksum. 8-11 SYSTEM XQT: Address relative to start of header plus 8 to start execution of a system. This is only used if bit 0 of byte 3 is set. It should be cleared otherwise. 12 EVEN PART ROM Number and SYSTEM REV: Bits<5:0> is the part number for the EVEN ROM in a ROM PAIR. (One is the first valid number. Three is the next valid number.) Bits<7:6> is the system revision number for the EVEN ROM in a ROM PAIR. (Zero is the first valid number.) The boot ROM verifies that bytes 12 and 13 have consecutive values. 13 ODD PART ROM Number and SYSTEM REV: Bits<5:0> is the part number for the ODD ROM in a ROM PAIR. (Two is the first valid number. Four is the next valid number.) Bits<7:6> is the system revision number for the ODD ROM in a ROM PAIR. (Zero is the first valid number.) 14 CAPABILITY BITS I and EVEN PART REV: Bits<2:0> is the part revision for the EVEN ROM in a ROM PAIR. (One is the first valid number.) Bits<7:3> are System Capability Bits: Bit 7 Reserved at 0 Bit 6 System can handle a 50 wide alpha display Bit 5-4 Reserved at 0 Bit 3 System can handle an 80 wide alpha display (Capability bits are only looked at by the boot ROM if the SYSTEM BIT, bit 0 of byte 3, is set.) 15 CAPABILITY BITS II and ODD PART REV: Bits<2:0> is the part revision for the ODD ROM in a ROM PAIR. (One is the first valid number.) Bits<7:3> are System Capability Bits: Bit 7 Reserved at 0 Bit 6 Reserved at 1 Bit 5-3 Reserved at 0 16 ROM SIZE and GROUP TYPE: Bits<7:4> is the ROM size flag. It is a multiple of 64K bits (e.g. zero is illegal). For ROMs that don't have this byte as above, 64K bits is assumed. Bits<3:0> is the Group type. Systems are given the number 0. Option ROMs are then given consecutive numbers starting with 1. 17 ROM ADDRESS: The ROM address is in bits 21 thru 14 of the address of the ROM header byte 0 (i.e., the address of the ROM header right shifted 14 places). The boot ROM does not verify this to allow for relocatable systems. .DE .H 3 "EPROM Disc Format" An eprom disc begins with a ROM header in ROM space with the disc bit (bit 3 of byte 3) set. Immediately following the 18 bytes of header information is the first sector of the disc, the system record. Following the system record are the rest of the disc records. The data is contiguous, except that a zeroed 16 bit word is placed at every 16K byte boundary to prevent ROM headers from accidentally occurring. .SK .nr Cl +2 .ds HF 3 3 3 3 2 2 2 .H 2 "Machine Configuration Determination and Identification" This section presents current machine configuration identification concepts and techniques. .P Configuration identification is another example of code that does not need to be in the boot ROM. It is true that the boot ROM must do a limited amount of configuration identification in order to boot successfully. It also must do a limited amount of just about everything else to boot: I/O, mass storage, human interface, etc. This does not mean that everything should go in the boot ROM. .P In future boot ROMs, systems should not be allowed to depend on the boot ROM for configuration identification except where it is needed to boot a system. Every time a system depends on a particular routine in the boot ROM, that routine must be maintained and replaced and Q.A.ed with all past systems whenever a new hardware or software technology requires a change. (Examples of such new things include: multi-tasking, and higher speed CPUs.) Since old systems must still be supported, the routine will grow in size with time and the Q.A. matrix will get out of hand. This was already the case with the 4.0 boot ROM and has not improved with the Series 300 Bootroms. .P Machine configuration identification is a set of algorithms that is guaranteed to grow and change with time (unless the 68000 family stops its growing and developing). Putting such an unstable set of algorithms in the boot ROM for use by all systems increases the support nightmares, the probability of bugs in the boot ROM, and the probability that the boot ROM will have to be upgraded to run new software. .SP .H 3 "Self-Test Is Linked To Configuration Identification" Before a system can use a device, it has to be present and in a usable state. In many cases, to determine this requires that a self-test of the device be performed. In Rev. C a vector was added to the documented interface which contains one bit for each select code 0..255. A one bit indicates that the boot ROM found the device and it passed a self test (if available). A zero indicates that either the interface does not exist or that it failed self test. This was added because of the increased difficulty of testing some multiboard graphics equipment. These devices carry test code which can at present only be executed in the simple boot ROM type of environment. Some mechanism was needed to pass this information on to the operating systems. .P For example if the graphics memory bus errors, then it is either failing or not present. As far as machine configuration identification is concerned, graphics memory that bus errors is not present. If the graphics memory fails a memory test, machine configuration identification can indicate that it is present and bad in a non-fatal way. .SP .H 3 "Hardware Configuration Identification Registers" Tactic number five of the boot ROM tactics discussed in chapter 2, gives guidelines on how to set up a hardware configuration identification register for a new device. Below is an example of such a register. This is the 16 bit CRT configuration identification register (at $51FFFE) used in the compatibility (alpha/graphics) display controller. .SP .DS CRTID<15> - Self-Initializing CRT. CRTID<14> - Reserved at 0. CRTID<13> - State of character mapping 0: The character ROM contains USASCII and Katakana and partial Roman Extension fonts, where the latter two fonts are mapped together. This font requires mapping of the Roman Extensions, and does not contain all Roman Extension characters. 1: The character ROM requires no mapping. It could be Roman8 or any 8 bit set. All characters are defined. CRTID<12:11> - Sub-Top Type (To handle 9836C Unknowns at time of 3.0 BOOTROM Bit Release) 0: Monochrome 1: 4 Planes starting at $520000 4 bits/byte using 256K bytes 1 byte/pixel (least significant 4 bits) 2: 3 Planes starting at $528000 8 pixels/byte using 128K bytes (unused 64K at $520000) 3: 8 Planes starting at $520000 8 bits/byte using 256K bytes 1 byte/pixel CRTID<10> - Highlight (See SYSFLAG) CRTID<9> - Graphics (See SYSFLAG) CRTID<8> - Alpha (See SYSFLAG) CRTID<7:4> - CRT Number: Implies CRT Constants and Physical Dimensions of CRT. 0: 9826A Monitor 1: 9836A Monitor 2: 9816 Monitor 3: 9836C Monitor 4: 9920 B/W Monitor 5: 9920 Commercial Monitor CRTID<3> - 50Hz/not-60Hz CRTID<2:0> - Model # (0 is for all 6845 Based systems) CRTID<15:8> AND $7 = SYSFLAG<7:0> AND $7. Model allows new scheme. CRTID<7:3> - Specifies what set of 6845 Initialization constants to use. There are 10 unused values at this point. .DE .P Any CRT top with a CRT ID Register may also have a control register 16 bit word at $51FFFC to control the CRT: .DS bit 0 0 = Turns Off Graphics 1 = Turns On Graphics .DE .P To determine if an alpha display is present, a bus error check should be done by using the instruction "move.b #15,$510001". .P The bit mapped display controller does not have a CRT configuration identification register. All of the configuration information for these controllers is contained in an ID/initialization ROM on the display controller board. Steve Wolf is the keeper of the documentation on the bit mapped display controller ID/Initialization ROM. Presence of the controller board is determined by reading the address $560000. If a bus error occurs or if the primary DIO ID is not 25 and the secondary DIO ID is not 1, then there is not a supported bit mapped display controller. These displays are different from the old style alpha displays because they look like IO cards and can be addressed to the external IO space as external graphics devices. .P In Rev. C, displays at all addresses are identified and initialized. However, the boot console will be either the internal display (address $560000) or the lowest working display in DIO II space (select codes 132 to 255). .P The keyboard system jumpers are used to identify the keyboard configuration for all .I local .R keyboards. .P The following devices have configuration registers at present: .AL a .LI Internal RS-232 hardware, .LI External I/O cards, .LI Internal keyboard/HP-IB cards, .LI The compatibility display controller, .LE .SP .H 3 "Device Configuration Identification and Self-Test Algorithm" Below is the basic algorithm for both self-testing a device and determining its configuration. (Actual device identification, e.g. keyboard vs. CRT, is done by memory address.) .SP .tr~\\ .nf ---------------- |Is it present?|---No---->+<-----------------+ ---------------- | | | ----------------- | Yes |Indicate it is | | | |not present and| | ---------------- | never try to | | |Does it have a| |access again. | | |configuration | ----------------- | |register? | | | ---------------- ------ | | ~ |Exit| | | ~ ------ | | ~ | Yes +-------No--->| | | | | ---------------- ----------------------- | |Extract | |Deduce configuration | | |configuration | |from unique hardware | | |from register.| |traits. | | ---------------- ----------------------- | | | | |<-----------------+ | | | ----------- | | Check | +--------+ | |Self-Test|-+-----Fatal Error---|Indicate|-->+ -----------~ | Error | | ~ ---------- | | Passes +-Non-Fatal-Error--+ Self-test | | v ------ ---------------- |Exit|<----------------|Indicate Error| ------ ---------------- .fi .P The initial test for the presence of a device is device dependent. Presence is typically determined by looking for no bus errors at a particular address, memory at particular address, by looking for a ROM value at a particular address, or by looking for a certain read/write protocol at a particular address. .SP .H 3 "Global Boot ROM Variables" The global boot ROM variable SYSFLAG ($FFFFFED2) is part of the current mechanism for communicating machine configuration to operating systems. .P SYSFLAG is generated by the boot ROM, and is defined as follows: .DS SYSFLAG<0> Refers to the compatibility display only. 0=80 wide alpha display. 1=50 wide alpha display.* SYSFLAG<1> 0=400X300 graphics. 1=512X390 graphics. SYSFLAG<2> Highlight indicator -- Refers to compatibility display only. 0=(SYSFLAG<2> XOR SYSFLAG<1>) when highlights are not present. 1=(SYSFLAG<2> XOR SYSFLAG<1>) when highlights is present. SYSFLAG<3> 0=Internal keyboard present. 1=Internal keyboard not present. SYSFLAG<4> 0=No CRT configuration register present.* 1=CRT configuration register present. SYSFLAG<5> 0=Internal HP-IB present. 1=Internal HP-IB not present. SYSFLAG<6> Reserved at 0. (Note: On s200 boot ROMs this bit was defined as bit 7 is now defined and visa versa. These bits were swapped so that some ISV software would work on s300. Bit 6 is used internally by Rev. C1, but will ALWAYS BE PASSED TO THE SYSTEM AS ZERO. There- fore, I recommend that systems OR bits 6 and 7 together to determine the presence of a bit mapped display when they may be running on either a s300 or a s200.) SYSFLAG<7> 0=No working internal bit mapped display controller present (There may be a broken one though, or there may be one in DIO II space (selectcodes 132 .. 255)). 1=Bit mapped display controller present. * Note that these values are invalid on s300 but are kept around for series 200 compatibility. .DE .P The boot ROM also sets up a 16 bit word that indicates the default boot device. Operating systems take care of any further machine configuration identification (such as I/O cards). .P The boot ROM also sets up the global variable, SYSFLAG2 ($FFFEDA), to communicate information to operating systems. SYSFLAG2 is defined as follows: .DS SYSFLAG2<0> 0=No ID PROM present. 1=Good PROM present. (always 0 for s300, kept around for system compatibility reasons.) SYSFLAG2<1> 0=Processor board timer present. 1=Processor board timer not present. (always 0 for s300) SYSFLAG2<2> 0=Processor is 68010 or 68020. 1=Processor is 68000 or 68030. SYSFLAG2<3> Reserved at 1. SYSFLAG2<4> 0=Processor is a 68000 or 68010. 1=Processor is a 68020 or 68030. SYSFLAG2<5> 0=internal bmd is 237 1=internal bmd is topcat, catseye etc. always 1 for s300 SYSFLAG2<6> Reserved at 1. SYSFLAG2<7> 0=32 bits for iocards 1=256 bits for iocards (NOTE: bits 1 and 2 were incorrectly documented in the previous release of this manual) The definition for bit 7 was added in Rev. C and is backwards compatible. When bit 7 = 1 it indicates that io_cards_ptr is valid and points to a 256 bit vector. .DE .P The global variable NDRIVES ($FFFFFED8--byte sized) gives the highest allowable unit number for the internal mini-floppy. A value of 255 (or -1) means that there are no drives present, and this is always the case for s300. This variable is just kept around for s300. Even if some kind of floppy drive were integrated into a future s300 SPU, this, and other mini-floppy variables, would not apply as the new drivers would undoubtedly be different. .SK .H 3 "Bootrom Revision and Configuration" A Bootrom Configuration Word exists at $3FFC. The following information is contained there: .SP .DS bits 15-9 Reserved at zero bit 8 If 0 then boot ROM has read interface capability bits 7-5 Reserved at zero bits 4-0 Size of boot ROM in 16K byte increments .DE .SP A Bootrom revision word exists at $3FFE for all s200 and s300 Bootroms. The following information is contained there: .SP .DS Negative(-192492) s200 1.0 Boot ROM (9826 only) 1 s200 2.0 Bootrom (9826/9836 only) 3 s200 3.0 Bootrom 4 s200 4.0otromROM $A s300 Bootrom Rev. A $A2 s300 Bootrom Rev. A2 $B s300 Bootrom Rev. B $0C s300 Bootrom Rev. C $C1 s300 Bootrom Rev. C1 $EC s300 Bootrom Experimental Rev. C1 or Rev. C1 .DE .SK .nr Cl -2 .ds HF 3 3 2 2 2 2 2 .H 2 "Machine State After System Load" At the time control is turned over to the system, the following conditions will be in effect and the following information will be made available: .SP .AL .LI Type of boot (Value), .AL a .LI POWER UP (0) .LI CRASH RECOVERY (6) .LI REQUESTED RE-BOOT (12) .LI REQUESTED BOOT (18) .LE .LI Address of lowest usable RAM (determined by RAM test), .LI The flag byte showing battery backup presence (always 0; must keep this around for BASIC), .LI The status register will be set to $2700 (that is, interrupts will be disabled), .LI The hardware will be in a state of RESET except for the keyboard and any remote human interface. .LI Keyboard interrupts will be disabled, .LI The keyboard input buffer may not be empty, .LI All vectors will be initialized to JSR CRASH. CRASH is a recovery routine in the boot ROM. If there is a RAM Monitor present at $00880000, then trap 15 and the trace trap will be left as set up by the monitor, .LI The stack pointer will be pointing to the top of the boot ROM stack area, .LI SYSFLAG & SYSFLAG2 will be set up correctly. .LE .SK .H 2 "MSUS (Mass Storage Unit Specifier) Definition" The default MSUS (DEFAULT_MSUS, $FFFEDC, long word) is used by systems for the following three purposes: .AL a 1 .LI As the default MSUS for operating systems, .LI As the device from which to load an autostart program, and .LI As the device from which to do a secondary load. .LE .SP Each of the four bytes of the MSUS is a field with a different meaning. These fields describe type (device and directory), unit number, select code, and primary address as follows: .AL a .LI TYPE Byte ($FFFFFEDC): The TYPE byte describes the protocol or device to be used as well as the directory format to be used. .SP .nf TYPE<7:5> - Directory Format 0 = L.I.F. sector oriented 1 = S.D.F. (mid-range format) 2 = UNIX sector oriented 3-6 = Reserved for future sector oriented 7 = SPECIAL (ROM, SRM, LAN, etc.) *LAN is new in Rev. B* TYPE<4:0> - Device Type 0 = s200 internal 5.25' mini-floppy (or ROM for SPECIAL) 1 = Reserved internal (or SRM for SPECIAL) 2 = Reserved internal 3 = Reserved internal 4 = 9895 8" floppy / 913X 5.25" micro-winchester (HP-IB) 5 = 82900 series 5.25" mini-floppy (HP-IB) 6 = 9885 8" floppy (GPIO) 7 = 913X A 5-megabyte 5.25" micro-winchester (HP-IB) 8 = 913X B 10-megabyte 5.25" micro-winchester (HP-IB) 9 = 913X C 15-megabyte 5.25" micro-winchester (HP-IB) 10 = 7905 hard disc (HP-IB) 11 = 7906 hard disc (HP-IB) 12 = 7920 hard disc (HP-IB) 13 = 7925 hard disc (HP-IB) 14 = SCSI direct access device *new in Rev. C* 15 = Reserved for Future 16 = CS/80 and SS/80 devices with 256-byte blocks (HP-IB) 17 = All other CS/80 and SS/80 devices (HP-IB) 18-19 = Reserved for future 20 = EPROM card (HP98255) 21 = Reserved for future 22 = BUBBLES (HP98259) 23-31 = Reserved for future .ni .LI UNIT Byte ($FFFFFEDD): The UNIT byte is a device dependent variant record which gives a unit addressing scheme for a particular device. It typically has a value of zero through three. .SP .nf UNIT<7:0> - Device Dependent Variant Record packed record case boolean of false: un: 0..255; 8 bit unit number true: (vn4: 0..15; volume number (CS80/7905/7906) un4: 0..15;) unit number end .ni .LI SELECT CODE Byte ($FFFFEEDE): This byte contains the select code of the MSUS (zero through 31). This field is meaningless for the internal floppy drive. .LI PRIMARY ADDRESS Byte ($FFFFEEDF): This byte contains the primary address (HP-IB address for HPIB devices) (BUS address for SCSI devices) for the MSUS device. .LE .P The above definition is also used when calling any of the boot ROM routines which require an MSUS. .SK .H 2 "The SYSBOOT Interface" The s300 Bootrom has two routines to boot a system, REQ_BOOT and REQ_REBOOT. These two routines use the variable, DEFAULT_MSUS, to determine where to search for a system. .P The bootrom interface allows the specification of up to a 255 character filename (with optional path names and passwords) and the boot device MSUS. This interface will return to the calling routine if the device is inaccessible or if the file cannot be opened. The routine can be called from PASCAL. This routine, called BOOT, is located at $4000 and has parameters as follows: .SP BOOT(MSUS:LONGWORD,VAR FILENAME:STRING255). .SP .DS The Algorithm for this routine is shown below: Indicate that the booter has been called. IF M_INIT(MSUS) and M_FOPEN(FILENAME,X_ADR,LENGTH,BTYPE:=-5822) THEN BEGIN Sector:=0; On Error ERROR(Error,RESET to RETRY, CONTROL-RESET to POWER-UP, Hang); On Bus Error ERROR(Not Enough RAM,RESET to POWER-UP, Hang); ANYTHING_LOADED:=False; IF LENGTH THEN REPEAT M_READ(Sector,256,FUBUFFER,Relative); Load_adr:=FUBUFFER[0:3];Seg_length:=FUBUFFER[4:7]; IF Load_adr to Load_adr+Seg_length-1 overlaps (F_AREA to LOWRAM-1 or MINRAM to 0) THEN ERROR(Not Enough RAM,RESET to RETRY, Hang); ANYTHING_LOADED:=True; Sector:=Sector+1; IF Seg_length<=(256-8) then Copy Seg_length from FUBUFFER at 8 to Load_Adr; ELSE BEGIN Copy 256-8 bytes from FUBUFFER to Load_Adr; Load_Adr:=Load_Adr+256-8; Seg_length:=Seg_length-(256-8); M_READ(Sector,Seg_length,Load_adr,Relative); Sector:=Sector+((Seg_length+255) div 256); END; UNTIL (Sector+1)>LENGTH; M_FCLOSE; {Determine Default MSUS.} If MSUS#ROM THEN DEFAULT_MSUS:=MSUS ELSE IF DEFAULT_MSUS=ROM THEN BEGIN {Determine ROM DEFAULT_MSUS} DEFAULT_MSUS:=<":M700,0">; Media_Found:=False; Present_MSUS:=ROM; FOR EACH BOOTV in BOOT_LIST DO WITH BOOTV^ DO BEGIN "FINDMSUS" {BOOT_LIST Search} MSUSVALID:=False; Media:=ACTIVE(1,TRUE,MSUS,MSUSVALID,False); IF MSUSVALID and MSUS#ROM THEN BEGIN IF Media THEN BEGIN DEFAULT_MSUS:=MSUS; Media_Found:=True; EXIT "FINDMSUS"; END; IF Present_MSUS=ROM THEN Present_MSUS:=MSUS; END; END "FINDMSUS"; {BOOT_LIST Search} IF NOT Media_Found AND Present_MSUS#ROM THEN DEFAULT_MSUS:=Present_MSUS; END; {Determine ROM DEFAULT_MSUS} SPECIAL CASE BASIC 2.0: Patch two Procedure Variables and Set DEFAULT_MSUS to INTERNAL,0 if no devices are present; Set LOWRAM back; Mem[LOWRAM]:=FILENAME; SYSNAME:=FILENAME; Initialize MACHINE; JSR (X_ADR); END; .DE .SP .P If the system is not found, it will return to the caller. If it is successful, it will not return to the caller, but will boot a new system. There are several cases where returning is impossible because the caller and/or some of the caller's data structures may have been destroyed by the booting process. In these cases, the routine will not return to the caller. .P The Boot ROM will return to the caller if the MSUS device is not present, if the system is not found, or if the file to be booted is not a valid system. .P If the boot error is unrecoverable the boot ROM will display the message: .SP .DS RESET To Power-Up .DE .SK .H 2 "The Read Interface For Secondary Loaders" The read interface drivers are made available for secondary loader programs. Despite the tactic that says loaded systems should not depend upon the boot ROM for any support after they have gained control, there are two reasons why the boot ROM's read drivers must be accessible: .AL .LI Some systems, such as UNIX, are only permitted to load a small (768 bytes) code segment at boot time. This is not enough space to enable it to start up a system on its own. It cannot possibly have its own mass storage drivers. .LI Some systems, such as Pascal, are designed to have the kernel booted in first. This kernel has hardly any drivers at all. It would like to have the boot ROM read some more stuff in. In other words, some systems by design require a two stage booting process. .LI The third reason that always pops up is: "If the code is there why do I have to maintain my own copy?". .LE .P The boot ROM's read drivers (no write drivers are present) can be used by any system under the following constraints: .AL .LI The read interface will be pointed at some msus (usually the default msus). .LI The read drivers will not concern themselves with interactions with any other I/O drivers. They will not know about multi-tasking, virtual memory, interrupts, or anything over what they do during booting. .LI The read drivers should only be used to do extended booting of additional code. .LE .P The read interface is designed to be extendable to any mass storage system or network. It allows simple random sector reading of a disc and it allows reading sectors relative to an opened file. .P All routines are PASCAL callable and use the same parameter passing and error reporting mechanisms as the internal mini-floppy drivers. Only one MSUS and one File can be open at a time. The routines use a silent escape error mechanism (Pascal Error Recovery Block) for hardware or unexpected errors. .DS REQUIRED PASCAL Environment: A5 pointing to a recover block. e.g.: link a5,#-10 pea recover move.l sp,-10(a5) where recover is the address of a routine that extracts the error number from -2(A5) and handles it. Space allocated for the SRM. e.g.: mb_size equ $14 mb_ptr equ $10 movea.l f_area,a0 move.l mb_size(a0),d0 move.l a1,mb_ptr(a0) The routines can destroy D0-D7 and A0-A4. .DE .P Caller must handle any bus error exceptions. Only bus errors caused by a DMA card will be trapped and escaped as an error. .P The stack pointer should point to a space of at least 1K bytes. .P The following errors are possible: .AL .LI No Device (1) .LI No Medium (2) No Server for LAN .LI Not Ready (3) .LI Read Error (4) .LI Bad Hardware (5) .LI Bad Error State (6) .LI Bus Error (7) .LE .P The following read interface routines are available: .BL .LI M_INIT[$4004](MSUS:MSUSTYPE):BOOLEAN .P This routine does the following: .AL a .LI Initializes the default mass storage device. .LI Sets up any temporaries. .LI Determines if both the device and media are present and returns true if they are. .LI Verifies that the device is of the expected MSUS. .LI Resets the pointer to the start of the directory. .LE Possible error escapes from this routine are 4 through 7. .LI M_FOPEN[$4008](VAR FILENAME: STRING255; VAR X_ADR, LENGTH: INTEGER; VAR FTYPE: WORD): BOOLEAN; .P This routine does the following: .AL a .LI Attempts to open the specified file. .LI If the file was successfully opened, then it returns .AL i .LI True, .LI The actual file name opened, .LI The actual file type, .LI The size in bytes, and .LI The start execution address in memory. .LE .LI Sets up the driver to read sectors relative to the opened file. .LI If a character of the file name is null, then a wild card search of anything with same previous characters is performed. If the file type (FTYPE) is -1, then any file type is allowed. Otherwise, the file type must also match. The first file found in the wild card search is used. .LI If the device or media is not present, then this routine returns false. .LE This routine could escape with any error. .P Searching for a file is always done starting from the point where the last call to M_FOPEN left off, except on the SRM. When, on an SRM, a specific file name is given with no wild card, this routine will try to open the file directly without effecting the current search state. .LI M_READ[$400C](SECTOR, BYTECOUNT, RAMADDRESS: INTEGER; MEDIA: BOOLEAN); This routine reads the specified number of bytes (BYTECOUNT) starting at the specified sector (SECTOR) to a specified RAM location (RAMADDRESS). The sector number is relative to a file, if one is open and MEDIA is set to false, but the sector number is absolute if media true. (SECTOR zero is the first sector.) This routine uses the error mechanism for all errors, except for bus errors. Bus errors must be handled by the caller. .LI M_FCLOSE[$4010] This routine closes the opened file. It uses the error mechanism for all errors. .LE .SK .H 2 "Maintained boot ROM Routines" The following pages list routines which are supported and maintained by the s300 Bootrom. However they should only be used in a very limited manner. Be forewarned that, although these routines are guaranteed to stay around for a long time, when these routines must be changed by an update to the boot ROM, your system will .I NOT .R be QAed by the boot ROM designers. System groups are responsible for QAing old systems with new boot ROMs. Boot ROM designers are only responsible for making sure that an old system can be booted by a new boot ROM revision. So, .I use these routines sparingly, and carefully document where they are used!!! .R .P In addition to the routines supported by the s300 Bootrom, routines which were formerly supported by the series 200 boot ROMs but which are .I not .R supported by the s300 boot ROMs are listed on the following pages. The entry points and code for these routines may still exist, however, the code is not guaranteed to perform as expected, nor is it guaranteed to remain in the boot ROM from one release to the next. .P .nr Cl +2 .ds HF 3 3 3 3 2 2 2 .SK .H 3 "FLOPPY DRIVERS" Since no internal floppy drives will be present in a s300, these routines are no longer supported. Since BASIC needs the entry points, all floppy routines will do a silent escape with the error value of 2080. .P The following floppy driver routines were removed from the support list: .DL .LI F_PWR_ON / RESET .LI FLPYREAD .LI FLPY_WRT .LI FINTRUPT .LI FLPYINIT .LI FLPYMREAD .LI FLPYMWRITE .LI FLPYSREAD .LE .SK .H 3 "FILE OPERATIONS" .P All of the routines in this section for s200 boot ROMs were based on the internal floppy drivers and are, therefore, not supported with s300. The list of now unsupported routines is as follows: .DL .LI SOFTLOAD .LI LIFHEAD .LI FINDFILE .LI LOADFILE .LI BLOCKLOAD .LE .SK .H 3 "SYSTEM SWITCHING" .P .H 4 "* REQ_BOOT" .FS * BOOTTYPE will be set to 18 when the system starts and the machine will be in the condition described under GO. .FE .DS This routine will load and start a system. ARGUMENTS: NONE PRE CONDITIONS: SYSNAME contains the name/id of the system to start. If the first character is null (binary zero) then the power-up search sequence will be used to search for a system. If the first character is not null and the second one is null, then a search will be made for soft system "SYSTEM_Cxx" where C is the non-null first character and xx are any characters. If the search fails then ROM system C will be searched for. If neither the first nor second character is null then only soft systems will be searched for. REGISTER REQUIREMENTS: A0,A1,A2,A3,A4,A5,A6,A7 D0,D1,D2,D3,D4,D5,D6,D7 RAM REQUIREMENTS: HI RAM variables. Stack space. SAMPLE CALLING SEQUENCE: MOVE.L 'SYSQ',SYSNAME set the name CLR.B SYSNAME+4 set terminator TRAP #11 go into supervisor state JMP $1C0 do it .DE .SK .H 4 "* REQ_REBOOT" .FS * BOOTTYPE will be set to 12 when the system starts. and the machine will be in the condition described under GO. .FE .DS This routine will load and start a system. ARGUMENTS: NONE PRE CONDITIONS: SYSNAME contains the name/id of the system to start. If the first character is null (binary zero) then the power-up search sequence will be used to search for a system. If the first character is not null and the second one is null, then a a search will be made for soft system "SYSTEM_Cxx" where C is the non-null first character and xx are any characters. If the search fails then ROM system C will be searched for. If neither the first nor second character is null, then only soft systems will be searched for. REGISTER REQUIREMENTS: A0,A1,A2,A3,A4,A5,A6,A7 D0,D1,D2,D3,D4,D5,D6,D7 RAM REQUIREMENTS: HI RAM variables. Stack space. SAMPLE CALLING SEQUENCE: MOVE.L 'SYSQ',SYSNAME set the name CLR.B SYSNAME+4 set terminator TRAP #11 go into supervisor state JMP $1A4 do it .DE .SK .H 4 " GO" .DS This routine is used to start a system. It is intended for use by boot extension code. ARGUMENTS: NONE PRE CONDITIONS: A0 contains the start execution address of the system. The variable BATTERY must be set up correctly (a hold-over from s200). REGISTER REQUIREMENTS: A0,A1,..,..,..,..,..,A7 D0,D1,..,..,..,..,..,D7 RAM REQUIREMENTS: Stack space. SAMPLE CALLING SEQUENCE: LEA sys_start,A0 set start address TRAP #11 Go into supervisor state JMP $140 do it NOTES: The status reg. is set to 2700, keyboard interrupts are disabled, all vectors are set to JSR CRASH, and the SP is set to BOOT_STACK before control is given to the system. .DE .SK 0 .H 3 "DISPLAY DRIVERS" .P Please note that most of these routines work only for the "local" console. If a remote console is present in these cases, the boot ROM will ignore the remote console and will look for a local console. In most cases the local console is determined by the following algorithm: .SP .DS IF (bit #6 of sysflag is SET) { indicating an internal BMD } THEN treat internal bit mapped display as console ELSE IF DIO II display present and presence vector indicates that it passed self test THEN use it ELSE IF (low ram variables indicate 98627 console) THEN use 98627 as console ELSE use alpha/graphics display as console .DE .SP Note that low ram variables will only indicate a 98627 display as console if the boot ROM sets those variables up as such, and the boot ROM will only do so if no bit mapped display and no alpha/graphics display is present. .P .I Beware of using these routines if you have changed the value of sysflag or if you have messed with the boot ROM's low RAM variables. For Rev. C and later, be aware that bit SYSFLAG bit 6 only applies to the INTERNAL BIT MAPPED DISPLAY, there may be a BMD in DIO II. .R .P The series 200 graphics routine, GRPHCLEAR, is not supported on s300. .SK .H 4 "* CRTINIT" .DS If a bit mapped display controller is present, this routine uses data in the ID/Initialization ROM to initialize the controller. If no bit mapped display is present, but there is a compatibility display controller, then registers 0 thru 11 of that controller are initialized. This routine does not look for or effect a remote console or a 98627 card as console. ARGUMENTS: NONE PRE CONDITIONS: NONE REGISTER REQUIREMENTS: NONE RAM REQUIREMENTS: High RAM variables Low RAM variables Stack Space SAMPLE CALLING SEQUENCE: JSR $13C do it NOTES: May be called from PASCAL. It doesn't work for 98627 or remote consoles. .DE .SK .H 4 " CRTCLEAR" .DS This routine initializes and clears the local display controller. For bit mapped displays, the entire frame buffer is cleared. Remote consoles are not effected by this routine. ARGUMENTS: NONE PRE CONDITIONS: NONE REGISTER REQUIREMENTS: NONE RAM REQUIREMENTS: High RAM variables Low RAM variables Stack Space SAMPLE CALLING SEQUENCE: JSR $148 do it NOTES: May be called from PASCAL. Ignores remote consoles. .DE .SK .H 4 " CRTBLANK" .DS This routine clears the local console display controller. If the console is a compatibility display, then the alpha memory is blanked. If the console is a bit mapped display, then only the displayed portion of its frame buffer is cleared. If the console is a HP98627 card, the entire display is cleared. ARGUMENTS: NONE PRE CONDITIONS: NONE REGISTER REQUIREMENTS: NONE RAM REQUIREMENTS: High RAM variables Low RAM variables Stack Space SAMPLE CALLING SEQUENCE: JSR $14C NOTES: May be called from PASCAL. .DE .SK .H 4 " CRTMSG" .DS This routine is used to put a string of characters on the CRT at a given line. ARGUMENTS: NONE PRE CONDITIONS: Reg. A0 contains the address of the string. Reg. D0 contains the line number. (Top of CRT is counted as line zero (0). REGISTER REQUIREMENTS: A0,..,..,..,..,..,..,.. D0,..,..,..,..,..,..,.. RAM REQUIREMENTS: High RAM variables Low RAM variables Stack Space SAMPLE CALLING SEQUENCE: LEA message,A0 point to the message MOVE.L #2,D0 set the line number JSR $150 display the message NOTES: The message consists of consecutive characters ending in NULL (binary zero). It is assumed that the alpha CRT scanning will begin with the lowest RAM address (512705 hex). This routine assumes you are smart enough not to make a message that goes off the end of the screen. .DE .SK 0 .H 3 "KEYBOARD DRIVERS" .P These routines are very touchy since the introduction of external keyboard support. Therefore, .I they are NOT recommended for system use!!! .R These entry points are only kept around for some internal HP tools which, unfortunately, use these routines. .P All of these routines are supported for the internal keyboard only. All bets are off when an external keyboard is used. Also, the routines are only guaranteed to work with the s300 HP-HIL keyboard (including the HP-HIL NIMITZ keyboard). Support for old s200 keyboards may still exist, but is not guaranteed to remain. .P The series 200 keyboard translation table, KTRANS, is not supported for external use on s300. .SK .H 4 " KBD_NO_INT" .DS This routine waits for the internal keyboard to stop interrupting. It is advisable to call this routine before exiting a keyboard isr to avoid getting spurious interrupts. It takes some time before the keyboard stops pulling on the interrupt line after the 680xx has told it to stop. ARGUMENTS: NONE PRE CONDITIONS: If the keyboard is interrupting it must have been told to stop; Otherwise, this routine will hang. REGISTER REQUIREMENTS: NONE RAM REQUIREMENTS: High RAM Variables Low RAM Variables Stack Space SAMPLE CALLING SEQUENCE: JSR $15C NOTES: .DE .SK .H 4 " KBD_CWAIT" .DS This routine waits for the internal keyboard to become ready to accept a command or data. ARGUMENTS: NONE PRE CONDITIONS: Reg. D0 contains the number of times the internal keyboard should be polled before giving up. A count of 200 takes approximately 1 millisecond. The keyboard is polled between each time the clock is checked, and the exact number of polls is not guaranteed. The count is a WORD (i.e. 0 to 32767). A count of zero (0) causes a wait until the keyboard is ready to accept the command. REGISTER REQUIREMENTS: ..,..,..,..,..,..,..,.. D0,..,..,..,..,..,..,.. RAM REQUIREMENTS: Low RAM variables High RAM variables Stack Space SAMPLE CALLING SEQUENCE: CLR.L D0 clear the wait count JSR $160 call wait routine NOTES: On return to the calling code, the condition code will be set zero if the keyboard is ready and non zero if the keyboard did not become ready. .DE .SK .H 4 " KBD_WCMD" .DS This routine writes a command to the internal keyboard. It waits for the previous command to complete before writing the new command. ARGUMENTS: NONE PRE CONDITIONS: Reg. D0 contains the number of times the internal keyboard should be polled before giving up. A count of 200 takes approximately 1 millisecond. The keyboard is polled between each time the clock is checked, and the exact number of polls is not guaranteed. The count is a WORD (i.e. 0 to 32767). A count of zero (0) causes a wait until the keyboard is ready to accept the command. Reg. D1 contains the command byte to be written. REGISTER REQUIREMENTS: ..,..,..,..,..,..,..,.. D0,D1,..,..,..,..,..,.. RAM REQUIREMENTS: Low RAM variables High RAM variables Stack Space SAMPLE CALLING SEQUENCE: CLR.L D0 clear the wait count. MOVE.L #$A3,D1 give the command JSR $164 NOTES: On return to the calling code, the condition code will be set zero if the write was done, and non zero if the keyboard did not become ready. .DE .SK .H 4 " KBD_WDATA" .DS This routine writes data to the internal keyboard. It waits for the previous command to clear before writing the new data. ARGUMENTS: NONE PRE CONDITIONS: Reg. D0 contains the number of times the internal keyboard should be polled before giving up. A count of 200 takes approximately 1 millisecond. The keyboard is polled between each time the clock is checked, and the exact number of polls is not guaranteed. The count is a WORD (i.e. 0 to 32767). A count of zero (0) causes a wait until the keyboard is ready to accept the data. Reg. D1 contains the data byte to be written. REGISTER REQUIREMENTS: ..,..,..,..,..,..,..,.. D0,D1,..,..,..,..,..,.. RAM REQUIREMENTS: Low RAM variables High RAM variables Stack space SAMPLE CALLING SEQUENCE: MOVE.W #400,D0 wait 2 millisecs. MOVE.B #$FD,D1 give the data JSR $168 BNE kerror check for done NOTES: On return to the calling code, the condition code will be set zero if the write was done, and non zero if the keyboard did not become ready. .DE .SK .H 4 " KBD_RDATA" .DS This routine POLLS the internal keyboard for data input. ARGUMENTS: NONE PRE CONDITIONS: The keyboard must be enabled to interrupt on key strokes. The processor priority must be at least 1 to stop the keyboard interrupts from occurring. Reg. D0 contains the number of times the internal keyboard should be polled before giving up. A count of 200 takes approximately 1 millisecond. The keyboard is polled between each time the clock is checked, and the exact number of polls is not guaranteed. The count is a WORD (i.e. 0 to 32767). A count of zero (0) causes a wait until keyboard data is read. REGISTER REQUIREMENTS: ..,..,..,..,..,..,..,.. D0,D1,..,..,..,..,..,.. RAM REQUIREMENTS: Low RAM variables High RAM variables Stack Space SAMPLE CALLING SEQUENCE: MOVE.W #600,D0 wait 3 millisecs. JSR $16C call the routine BNE nokey check for timeout NOTES: On return to the calling code, The condition code will be set zero if a data byte was read; and non zero if data was not read. D0 byte 0 will contain the data and D1 byte 0 will contain the keyboard status. .DE .SK .H 4 " READ_KEYS" .DS This routine POLLS the internal keyboard for data input then translates the keycode for alpha keys. ARGUMENTS: NONE PRE CONDITIONS: The keyboard must be enabled to interrupt on key strokes. The processor priority must be at least 1 to stop the keyboard interrupts from occurring. Reg. D0 contains the number of times the internal keyboard should be polled before giving up. A count of 200 takes approximately 1 millisecond. The keyboard is polled between each time the clock is checked, and the exact number of polls is not guaranteed. The count is a WORD (i.e. 0 to 32767). A count of zero (0) causes a wait until a key is read. REGISTER REQUIREMENTS: A0,..,..,..,..,..,..,.. D0,D1,D2,..,..,..,..,.. RAM REQUIREMENTS: High RAM variables Low RAM variables Stack Space SAMPLE CALLING SEQUENCE: CLR.L D0 set wait for key JSR $1C4 NOTES: On Return to the calling program, If the count ran out before a key was hit, D1 will be zero (0). Byte 0 of D1 will contain the status read from the keyboard except that bit 0 will be 1 if the keycode was translated; otherwise it will be 0. Byte 0 of D0 will contain the data/keycode read from the keyboard and byte 2 will contain the translated keycode. Only keys A-Z, a-z, 0-9 and RETURN are guaranteed to be correctly translated, especially on foreign keyboards. .DE .SK .H 3 "BATTERY DRIVERS" .P Since no battery backup is present in s300 (at least not the same one that was present in the s200), these routines are no longer supported. .P The s200 battery routines that are no longer supported are: .DL .LI CHK_BATTERY .LI BAT_NO_INT .LI BAT_CWAIT .LI BAT_WCMD .LI BAT_WDATA .LI BAT_RDATA .LE .SK .H 3 "MISCELLANEOUS UTILITIES" .P The series 200 routine, FMSGS, is not supported on s300. .H 4 " END_TEST_ROM" .DS This is the entry point at which the TEST ROM returns to the Boot code. It is expected that the machine is in a RESET condition when entry is made here. This is in effect where the boot code begins i.e. CRT initialization RAM test etc. This entry point is still active BUT there is no longer any other support in the bootrom for the TEST ROM. (it no longer needs it) ARGUMENTS: NONE PRE CONDITIONS: The machine is in a RESET condition REGISTER REQUIREMENTS: All registers RAM REQUIREMENTS: All RAM (because of the RAM test) SAMPLE CALLING SEQUENCE: RESET JMP #19C NOTES: All internal peripherals are reset and some are initialized. .DE .SK .H 4 " RTN_TO_MONITOR" .DS This routine checks for the presence of a monitor at $880000 . If the monitor is there, a jump is made to the specified address. If no monitor is there, control is returned to the caller. ARGUMENTS: address in monitor to jump to PRE CONDITIONS: NONE REGISTER REQUIREMENTS: NONE RAM REQUIREMENTS: 6 + bytes of stack space SAMPLE CALLING SEQUENCE: PEA monitor_nmi set monitors nmi isr address JSR $1A0 call for jump to monitor ADDA.L #4,SP came back so no monitor remove the argument. NOTES: This routine is intended to support the convention that for an operating system, the combination CTL SHIFT PAUSE means return to the monitor. .DE .SK .H 4 " BIN_TO_DEC" .DS This routine converts the contents of D0 (all 32 bits) to ASCII decimal. Leading zeros are suppressed. The number is signed; - is prefixed if the number is negative. ARGUMENTS: NONE PRE CONDITIONS: D0 contains the number to be converted. A1 contains the address of the output string. REGISTER REQUIREMENTS: ..,A1,..,..,..,..,..,.. D0,D1,D2,D3,D4,D5,D6,.. RAM REQUIREMENTS: The bytes required to hold the converted number. Stack Space. SAMPLE CALLING SEQUENCE: MOVE.L #12345,D0 set the number LEA cbuffer,A1 set the address JSR $1A8 call for the conversion NOTES: On return; the contents of D0 are destroyed, and A1 points to one byte past the end of the string. .DE .SK .H 4 " PNT8HEX" .DS This routine converts the contents of Reg. D0 to ASCII Hex. ARGUMENTS: NONE PRE CONDITIONS: D0 contains the binary number to be converted. A1 contains the address into which the string will be generated. REGISTER REQUIREMENTS: ..,A1,..,..,..,..,..,.. D0,D1,D2,..,..,..,..,.. RAM REQUIREMENTS: 12 bytes Stack space plus 8 bytes of RAM for the ASCII digits SAMPLE CALLING SEQUENCE: MOVE.L #1234,D0 set the number LEA cstring,A1 set the buffer address JSR $1AC NOTES: On return from the routine, A1 will point 1 byte beyond the end of the string. The contents of D0 are destroyed. .DE .SK .H 4 " NMI_DECODE" .DS This is the address of the NMI (level 7) interrupt isr used by boot ROM. It determines which device caused the NMI then jumps to one of four (4) pseudo vectors. ARGUMENTS: NONE PRE CONDITIONS: The address at location $1B0 must be moved to the level 7 vector. The variable BATTERY must be set correctly (this is a hold on from the s200 is the set up is done by the boot ROM). REGISTER REQUIREMENTS: NONE RAM REQUIREMENTS: High RAM variables. SAMPLE CALLING SEQUENCE: MOVE.W #$4EF9,$FFFFFFF9A set jump opcode MOVE.L $1B0,$FFFFFFF9C set the isr address NOTES: .DE .SK .H 4 " BOOT_BUSERROR" .DS This is a Jump to a Bus error routine and is intended for use by boot extension code. ARGUMENTS: NONE PRE CONDITIONS: The bus error vector at $FFFFFFFA must jump to this location ($1B4). Reg. A6 must contain the address of where execution is to continue after a bus error. REGISTER REQUIREMENTS: ..,..,..,..,..,..,A6,.. ..,..,..,..,..,..,..,.. RAM REQUIREMENTS: High RAM variables Stack Space SAMPLE CALLING SEQUENCE: NOTES: This routine removes the bus error information from the stack then executes a JMP (A6) . If the return address is in the TEST ROM area then a JMP to a vector in the TEST ROM is made. .DE .SK .H 4 " CRASH" .DS This routine is intended to recover the system from use of an interrupt or pseudo vector not setup by the operating system. ARGUMENTS: NONE PRE CONDITIONS: SYSNAME contains the name/id of the system to restart. This system and no other will be loaded and started. REGISTER REQUIREMENTS: A0,A1,A2,A3,A4,A5,A6,A7 D0,D1,D2,D3,D4,D5,D6,D7 RAM REQUIREMENTS: Boot ROM Stack space plus Boot ROM RAM variables SAMPLE CALLING SEQUENCE: JSR $000001B8 jsr to the CRASH routine NOTES: The crash code executes a RESET, and performs the power on checkout except for RAM TEST, (all internal peripherals are initialized / reset) (the keyboard real time clock is preserved) then displays the messages: UNEXPECTED USE OF aaaaaaaa RESET TO RETRY aaaaaaaa is the address in Hex of the JSR. This is computed as return address - 6. When the system starts, BOOTTYPE will be 6. The boot code loads all vector locations with JSR CRASH prior to the system being given control. .DE .SK .H 4 " BEEP" .DS This routine causes the beeper to sound. ARGUMENTS: NONE PRE CONDITIONS: Byte 0 of Reg. D2 must contain the frequency value Byte 1 of Reg. D2 must contain the duration value REGISTER REQUIREMENTS: ..,..,..,..,..,..,..,.. D0,D1,D2,..,..,..,..,.. RAM REQUIREMENTS: 8 bytes Stack space SAMPLE CALLING SEQUENCE: MOVE.W #$09F6,D2 JSR $1C8 NOTES: .DE .nr Cl -2 .ds HF 3 3 2 2 2 2 2 .SK .H 2 "Maintained Tables and PASCAL Support" The second 8k bytes of the boot ROM (addresses $2000-$3ED7) contain tables and support routines used by BASIC and PASCAL. .P Contained in this section are: .AL A .LI A font pattern in addresses $2000 to $2FFF. These patterns are stored 16 bytes per character, with each byte representing 8 horizontal pixels. The first byte is the upper 8 pixels of the character, and bit 7 is the leftmost pixel of the byte. This font is used by the HP98627 console drivers. .LI BCD to binary and binary to BCD conversion tables, .LI Support routines for PASCAL, and .LI Math tables for BASIC and PASCAL. .LE .P The assembly language source file for this code, BOOTROM2.TEXT, is unchanged from the series 200 boot ROM 4.0 to the s300 Bootrom, and the actual bits in this area will be confirmed to be identical. .SK .H 2 "High RAM Memory Layout" This section describes how the s300 Bootrom uses high memory. It is ordered starting at the top of memory and working down. .P The following vectors are accessed via the 680XX exception vectors in low ROM. 680XX exceptions transfer control to these RAM vectors which normally have been initialized by the operating system. .SP .nf * * SOFTINTERRUPT VECTORS * FFFFFFFA BUS ERROR FFFFFFF4 ADDRESS ERROR FFFFFFEE ILLEGAL INSTRUCTION FFFFFFE8 ZERO BY ZERO TRAP FFFFFFE2 CHK TRAP FFFFFFDC TRAPV TRAP FFFFFFD6 PRIVILEGE VIOLATION FFFFFFD0 TRACE TRAP FFFFFFCA 1010 OPCODE FFFFFFC4 1111 OPCODE FFFFFFBE INTERRUPT LEVEL 1 FFFFFFB8 2 FFFFFFB2 3 FFFFFFAC 4 FFFFFFA6 5 FFFFFFA0 6 FFFFFF9A 7 FFFFFF94 TRAP 0 FFFFFF8E 1 FFFFFF88 2 FFFFFF82 3 FFFFFF7C 4 FFFFFF76 5 FFFFFF70 6 FFFFFF6A 7 FFFFFF64 8 FFFFFF5E 9 FFFFFF58 A FFFFFF52 B FFFFFF4C C FFFFFF46 D FFFFFF40 E FFFFFF3A F .fi .P The boot ROM has a facility for decoding NMI. If the language system routes NMIs through NMI_DECODE, it will jump to one of the following four vectors depending on what caused the NMI. .nf FFFFFF34 PSEUDO VECTOR 1 RESET from keyboard FFFFFF2E PSEUDO VECTOR 2 Keyboard timer timeout (fast handshake) FFFFFF28 PSEUDO VECTOR 3 Battery backup interrupt (not valid for s300) FFFFFF22 PSEUDO VECTOR 4 NMI from the backplane FFFFFF1C SPURIOUS INTERRUPT FFFFFF16 VECTORED " 0 FFFFFF10 " " 1 FFFFFF0A " " 2 FFFFFF04 " " 3 FFFFFEFE " " 4 FFFFFEF8 " " 5 FFFFFEF2 " " 6 FFFFFEEC " " 7 FFFFFEE6 FORMAT ERROR OR CO-PROCESSOR VIOLATION OR UNKNOWN PSEUDO VECTOR FFFFFEE0 EXCEPTION VECTOR FROM THE 68881 FLOATING POINT CO-PROCESSOR FFFFFEDC DEFAULT_MSUS (See Section 5.7 for it's definition) INTERNAL BOOT ROM VARIABLES: .fi .I (Note: Variables marked with an asterisk are not valid for s300 but must be kept around for BASIC and PASCAL WORKSTATION compatibility reasons.) .R .SP .nf FFFFFEDB *DRVR_KEY Disable reads to default MSUS thru mini-floppy (Ignored - Use the READ interface) FFFFFEDA SYSFLAG2 A system configuration byte (Defined earlier in this chapter) FFFFFED9 *RETRY Used by floppy drivers FFFFFED8 *NDRIVES This byte gives the number of internal floppy drives minus one (255 means no drives) (Not valid on s200 1.0 boot ROMs) FFFFFED4 F_AREA This long-word points to an area in low RAM that is used for boot ROM temporaries. This area is 32 bytes long. The address of the first word above this area is contained in LOWRAM. (Not valid on s200 1.0 boot ROMs) FFFFFED3 *DRIVE Language systems set this byte to indicate the drive (0 or 1) to be accessed with the next floppy operation. (Not valid on 1.0 boot ROMs) ------------------ FFFFFED2 SYSFLAG A system configuration byte (Defined in earlier in this chapter) FFFFFDD2 FUBUFFER A 256 byte buffer for use by mass storage drivers FFFFFDCE LOWRAM When control passes from the boot ROM to the operating system, this location will contain the address of the lowest byte of usable RAM (four bytes) FFFFFDCD *BATTERY Always zero for s300 (Indicates Battery backup on s200) FFFFFDCC *BLFLAGS Boot ROM temp flags (Used by SOFTLOAD which is no longer supported) Bit 0 SYSTEM NOT FOUND 1=NOT FOUND 1 ERROR 1=ERROR DURING LOAD 2 SOFT SYSTEM ONLY 1=LOAD ONLY SOFT SYSTEM bits 3 & 4 are zero bits 5 thru 7 are used for internal purposes and are not guaranteed to be 0 at GO time. FFFFFDC2 SYSNAME This 10 byte area will contain the ID byte for the ROM being started or the name of the file the system was loaded from. If the name/id is less than 10 bytes long the last byte +1 MUST BE binary 0. This convention applies when boot ROM is invoked to switch systems. FFFFFDC0 BOOTTYPE This WORD will contain a code to indicate what condition caused the system to start. 0= power on 6= crash recovery 12= re-boot requested 18= boot/ system switch FFFFFDBC STARTADDRESS For soft systems, this byte contains the start address of the system. For ROM systems, this byte is meaningless. FFFFFDBC SYSTEMS SHOULD BE CAREFUL OF USING MEMORY AT THIS ADDRESS OR HIGHER FOR TEMPORARIES. ------------------ other boot ROM temporary variables ------------------ FFFFFDAC Top of boot ROM stack ------------------ FFFFFAC0 SYSTEMS CANNOT LOAD OVER THIS LOCATION OR HIGHER. .fi .SK .H 2 "Low ROM Memory Layout" This section describes how the s300 Bootrom (and the 680xx) uses low ROM. It is ordered starting at the bottom of memory and working up. .SP 2 .DS 0000 RESET stack address 0004 RESET start address 0008 HBUSERROR BUS ERROR ROUTINE; jumps to FFFFFFFA unless special 000C FFFFFFF4 ADDRESS ERROR 0010 FFFFFFEE ILLEGAL INSTRUCTION 0014 FFFFFFE8 DIVIDE BY ZERO 0018 FFFFFFE2 CHK 001C FFFFFFDC TRAPV 0020 FFFFFFD6 PRIVILEGED INSTRUCTION VIOLATION 0024 FFFFFFD0 TRACE 0028 FFFFFFCA OPCODE 1010 002C FFFFFFC4 OPCODE 1111 0030 FFFFFEE6 UNASSIGNED INTERRUPT (MOTOROLA HAS RESERVED THESE) 0034 FFFFFEE6 CO-PROCESSOR PROTOCOL VIOLATION 0038 FFFFFEE6 FORMAT ERROR 003C - 005F UNASSIGNED INTERRUPTS (MOTOROLA HAS RESERVED THESE) FFFFFEE6 0060 FFFFFF1C SPURIOUS INTERRUPT 0064 FFFFFFBE INTERRUPT LEVEL 1 0068 FFFFFFB8 " " 2 006C FFFFFFB2 " " 3 0070 FFFFFFAC " " 4 0074 FFFFFFA6 " " 5 0078 FFFFFFA0 " " 6 007C FFFFFF9A " " 7 0080 FFFFFF94 TRAP 0 0084 FFFFFF8E 1 0088 FFFFFF88 2 008C FFFFFF82 3 0090 FFFFFF7C 4 0094 FFFFFF76 5 0098 FFFFFF70 6 009C FFFFFF6A 7 00A0 FFFFFF64 8 00A4 FFFFFF5E 9 00A8 FFFFFF58 10 00AC FFFFFF52 11 00B0 FFFFFF4C 12 00B4 FFFFFF46 13 00B8 FFFFFF40 14 00BC FFFFFF3A 15 00C0 FFFFFEE0 68881: BRANCH OR SET ON UNORDERED CONDITION 00C4 FFFFFEE0 68881: INEXACT RESULT 00C8 FFFFFEE0 68881: FLOATING POINT DIVIDE BY ZERO 00CC FFFFFEE0 68881: UNDERFLOW 00D0 FFFFFEE0 68881: OPERAND ERROR 00D4 FFFFFEE0 68881: OVERFLOW 00D8 FFFFFEE0 68881: SIGNALLING NAN ------------------------ 00DC -- 00FF FFFFFEE6 UNASSIGNED INTERRUPTS 0100 FFFFFF16 VECTORED INTERRUPT 0 (User Interrupt Vector) 0104 FFFFFF10 1 0108 FFFFFF0A 2 010C FFFFFF04 3 0110 FFFFFEFE 4 0114 FFFFFEF8 5 0118 FFFFFEF2 6 011C FFFFFEEC 7 ------------------------ .DE .SP .I (NOTE: Not all of the following entry points are supported on s300. Please carefully check the section on "Maintained Boot ROM Routines" before using ANY of the entry points listed below.) .R .SP .DS 0120 JMP FLOPPY SECTOR READ & MOVE DATA TO USER BUFFER 0124 JMP FLOPPY SECTOR WRITE FROM USER BUFFER 0128 JMP FLOPPY ISR 012C JMP FLOPPY INITIALIZE LIF DISK 0130 JMP FLOPPY MULTI SECTOR READ TO USER BUFFER 0134 JMP FLOPPY MULTI SECTOR WRITE FROM USER BUFFER 0138 JMP floppy read sector no move to user buffer 013C JMP CRTINIT Initializes local display controller 0140 JMP GO Start the system (initialize vectors etc.) 0144 JMP FLOPPY POWER ON ------------------------ 0148 JMP CRTCLEAR (Initialize and clear display) 014C JMP CRTBLANK (Clear displayed portion of frame buffer) 0150 JMP CRTMSG (Send a string to a given line of the CRT) 0154 address of KEYBOARD TRANSLATE TABLE 0158 JMP GRPHCLEAR Clear graphics RAM ------------------------ 015C JMP KBD_NO_INT Wait for keyboard interrupt to stop 0160 JMP KBD_CWAIT Wait for last command to keyboard 0164 JMP KBD_WCMD Write command to keyboard 0168 JMP KBD_WDATA Write data to keyboard 016C JMP KBD_RDATA Read data from keyboard (polling) ------------------------ 0170 JMP CHK_BATTERY Check for battery backup 0174 JMP BAT_NO_INT Wait for battery interrupt to stop 0178 JMP BAT_CWAIT Wait for last command to battery 017C JMP BAT_WCMD Write command to battery 0180 JMP BAT_WDATA Write data to battery 0184 JMP BAT_RDATA Read data from battery (polling) ------------------------ 0188 JMP SOFTLOAD Find and load SYSNAME file 018C JMP LIFHEAD Verify LIF volume header 0190 JMP FINDFILE Scan lif directory arbitrary file name/type 0194 JMP LOADFILE Load a file from a given sector 0198 JMP BLOCKLOAD Load a block from a given sector ------------------------ 019C JMP END_TEST_ROM Entry for test ROM to continue boot 01A0 JMP RTN_TO_MONITOR Entry for "RETURN" to RAM monitor (880xxx) 01A4 JMP REQ_REBOOT Re-load and start current system 01A8 JMP BIN_TO_DEC Binary to decimal conversion 01AC JMP PNT8HEX Binary to hexadecimal conversion 01B0 address NMI_DECODE Address of NMI decoder ISR 01B4 JMP BOOT_BUSERROR Boot ROM bus error ISR 01B8 JMP CRASH Crash recovery routine 01BC JMP FMSGS Floppy error messages routine 01C0 JMP REQ_BOOT Boot SYSNAME system 01C4 JMP READ_KEYS Read from keyboard and translate (polling) 01C8 JMP BEEP Cause keyboard to BEEP 01CC -- 01EC Floppy Test Utilities JMP Table ===================================================================== 01EC 00808000 User Int. Vector 123: Resv. For Red Board Mon. 01F0 00801D7C User Int. Vector 124: Resv. For Red Board Mon. User Interrupt Vectors (125-255): 01F4 FFFFF400 User Interrupt Vector 125 01F8 FFFFF406 User Interrupt Vector 126 01FC FFFFF40C User Interrupt Vector 127 0200 FFFFF412 User Interrupt Vector 128 0204 FFFFF418 User Interrupt Vector 129 0208 FFFFF41E User Interrupt Vector 130 . . . . . . . . . 03F8 FFFFF706 User Interrupt Vector 254 03FC FFFFF70C User Interrupt Vector 255 START OF BOOT ROM CODE .DE .H 3 "User Interrupt Vectors" In low ROM, all possible user interrupt vectors have been made available. At a cost of over 512 bytes in the boot ROM, 130 of the 194 vectors have been pointed to a contiguous block of high RAM memory starting at FFFFF400 hex. Unfortunately for compatibility reasons, the jump table that sits on top of about 50 of the vectors could not be moved. Also, it is not possible for the boot ROM to initialize any of these vectors, because systems load right over them. .P Any operating system that wants to use the new vectors, must be responsible for initializing them. Also, note that the current family of 680XX machines does not handle the case of two devices on the same interrupt level trying to do vectored interrupts. Thus, only one device per interrupt level may use vectored interrupts. (Still, this allows the higher speed "interrupt on a condition" capability.) .SK .H 2 "F_AREA (Low RAM) Memory Layout" F_AREA is an area of stolen read/write memory for boot ROM usage. It is bounded by the bottom of physical memory and address in LOWRAM ($FFFFFDCE). Revision A steals 174 bytes. .P As far as all operating systems go, there are only two offsets into this area that will not move. They are: .SP .DS io_cards_ptr equ 12 Pointer to 256 bit vector: 4 bytes mb_ptr equ 16 Pointer to Allocated RAM: 4 bytes mb_size equ 20 Number of Bytes of Allocated RAM Required: 4 bytes .DE .P io_cards_ptr is a pointer to what could be described as a .SP PACKED ARRAY [0..255] of boolean .SP where each bit corresponds to a selectcode. If the value is true (1) the interface is present and believed to be working. If the value is false (0) the interface is either not present or believed to be NOT working. .P This capability was added in Rev. C to accomodate the situation where an interface has IODC code and the bootrom is the only code which can determine if the interface/device is working. .P mb_ptr and mb_size are used by any system that uses the read interface. .SK .H 2 "Boot ROM Extensions" .P This section is mostly documentation to make it easier to modify the boot ROM. .SP .H 3 "Boot Extension ROMS" .P Boot ROM extensions are very feasible. Since there was no time to test the mechanism, and since they probably should not be used unless .I absolutely .R necessary, and because Greg Lawson didn't write any documentation, the only documentation will be the source itself. One of FSD's OEMs, BRUNING/CAD, has successfully used this mechanism with the series 200 boot ROMs. .SP .H 3 "Mass Storage Extension Mechanisms" There are several relevant data and code structures: .DS STEAL[in F_AREA].w Tells how much LOWRAM to reserve. D_START[in F_AREA].l Points to the driver list that is searched by directed read interface based on TYPE in msus. If TYPE<7:5>=7 then all 8 bits of TYPE are compared with each entry. Otherwise only TYPE<7:5> is compared for a match. Last entry in list is for a set of dummy drivers. An element of the list consists of: Long Offset to Next Element Address of Read Drivers: init fopen read fclose menu Type Byte DD_START[in F_AREA].l Points to Device Driver list that is searched by directory managers at a level below the read interface. An element of the list consists of: Long Offset to Next Element Address of Device Drivers: Controllers ID Set Device Name Controller Init Unit Init Device Read Device Type Byte Descriptor Byte for Menu: Bit 0 indicates if Select Code is a Care in Menu Bit 1 indicates if HP-IB Address is a Care in Menu Bit 2 indicates if Drive # is a Care in Menu Bit 3 indicates Comma between Select Code and Name Bit 4 indicates Comma between Select Code and Address Bit 5 indicates to Split Volume Number from Unit Number B_START[in F_AREA].l Points to Boot Vector list that is used by the Boot Priority Scanner to choose a system to boot. An element of the list consists of: Address of Vector Routines: active next_system Long Offset to Next Element M_MSUS[in F_AREA].l Global MSUS to routines. M_FILESEC[in F_AREA].l Start Sector for an Opened File. M_DIRLEN[in F_AREA].l Length of Directory. M_DIRSEC[in F_AREA].l Start of Directory. M_DIRENT[in F_AREA].l Directory Sub-selector. FOUND_LIST[$FFXXXX].l Points to list of Systems found by scanner so far. Each item in the FOUND_LIST will have the following attributes: Address of Next FOUND_LIST Entry. (Long Word) 1 Subselector. (1 Bytes) 1 Character Selector. (Byte) MSUS Longword: Type [implying: Device Protocol (CS80, AMIGO, GANGLIA) and Media Format (LIF, DAWN, UNIX).] (Byte) I/O Select Code Address or INTERNAL. (Byte) HPIB Device Address. (Byte) Unit Number. (Byte) File Name (STRING255). (2 to 256 bytes) .DE .P During the power up sequence a boot extension ROM can modify the driver list, the device driver list, the boot list, and reserve more low RAM using STEAL. This way O.E.M.s can add new boot drivers. Whenever a driver cannot be found a set of dummy drivers will be used. .SP .H 3 "Boot List Vector Routines" ACTIVE is called to determine if a device or family of devices is to be searched for systems. If ACTIVE returns true, then, to find all boot ROM systems, NEXT_SYSTEM may be called several times until it returns false. These routines are callable by the boot ROM only and do not use any error mechanism at this level. .BL .LI ^.ACTIVE(BOOTPASS:WORD,INIT:BOOLEAN; VAR MSUS:LONGWORD,MSUSVALID:BOOLEAN):BOOLEAN .SP ACTIVE executes as follows: .DL .LI Returns true if device is to be searched. .LI Returns false if: .AL .LI Device was searched previously, .LI Device will not be looked at when BOOTPASS>n, or .LI Device or media is not present. .LE .LI Always sets MSUSVALID to indicate if MSUS is set. .LI Sets MSUS whenever device present even if there is no media. .LI Sets m_msus[f_area] up for calls to NEXT_SYSTEM .LI IF INIT=TRUE, assume that no devices have been previously searched. .LI Initialize device and drivers if true will be returned. .LI Determine media format and protocol of first media if true will be returned. .LI BOOTPASS number can be used by driver to prevent looking at devices that are guaranteed ready during BOOTPASS=1. .LE .LI ^.NEXT_SYSTEM(VAR FILENAME:STRING255):BOOLEAN .SP NEXT_SYSTEM executes as follows: .DL .LI Returns false if nothing is found. .LI The routine is passed a file name to look for. .LI Returns true if a system is found. It also should return FILENAME of system found to be used as parameters to M_INIT, M_OPEN, and BOOT. .LI Determine Media Format and Protocol of media, if true will be returned. .LE .LE .H 3 "Boot Supervisor Scanner Algorithm" The boot scanner works according to the following algorithm: .SP .DS CTRL_RESET Restarts Power-UP Search; Set up PASCAL Environment; Clear FOUND_LIST; Initialize Screen Menu; Indicate that a Boot System is being searched for; Found_MSUS:=False; DEFAULT_MSUS:=ROM; IF PROM then BEGIN Wait as per PROM; MSUS:=prom_msus; FILENAME:=prom_filename; IF M_INIT(MSUS) and M_FOPEN(FILENAME,Zilch,Zilch,SFTYPE:=-5822) THEN BEGIN ADD_TO_FOUND_AND_MENU(MSUS,FILENAME); IF NOT ATTENDED OR BOOT_SELECT(MSUS,FILENAME) THEN BOOT(MSUS,FILENAME); END; END; FOR BOOTPASS:=1 TO 2^16-1 & WHILE TRUE DO FOR BOOTPASS:=2 to 2^16-1 DO FOR EACH BOOTVECTOR in BOOT_LIST DO WITH BOOTVECTOR^ DO BEGIN {BOOT_LIST Scan} Init:=TRUE; Zilch:=False; WHILE ACTIVE(BOOTPASS,Init,MSUS,Zilch) DO BEGIN {Active Device Scan} Init:=FALSE; IF NOT Found_MSUS and MSUS#ROM THEN BEGIN Found_MSUS:=True;DEFAULT_MSUS:=MSUS; END; WHILE NEXT_SYSTEM(MSUS,FILENAME:='SYSTEM_0') DO BEGIN ADD_TO_FOUND_AND_MENU(MSUS,FILENAME); IF NOT ATTENDED or BOOT_SELECT(MSUS,FILENAME) THEN BOOT(MSUS,FILENAME); END; IF BOOT_SELECT(MSUS,FILENAME) THEN BOOT(MSUS,FILENAME); END; {Active Device Scan} IF BOOT_SELECT(MSUS,FILENAME) THEN BOOT(MSUS,FILENAME); END; {BOOT_LIST Scan} .DE .P During the boot supervisor scanner: .BL .LI Media are only searched once. Devices are only accessed once. (BOOT will access them again.) .LI To cause another search, the user must do a CTRL-RESET or cycle power. .LI The DEFAULT_MSUS for ROM systems is set to the first active media found up to the point a ROM system is chosen. If none is found, the boot ROM has to try to find one. (The DEFAULT_MSUS for non-ROM systems is the msus that was booted.) .LE .SP .H 3 "Sector-Oriented Device Driver Guidelines" .SP .DS function controllersID(): boolean; * called ONLY by the extd scanning procedures * answers the question "is this your controller's ID?" * if a driver supports more than one controller type, it should return true only if this controller corresponds to the value in m_msus.dev * if a driver supports a controller that supports multiple device types, the driver should return true if any of the possible device types correspond to the value in m_msus.dev. Unit_init will set the actual device type in msus.dev at the proper time, since different units on the same controller may be of different device types. procedure controller_init; * called ONLY by the extd scanning procedures * called only if controllersID returned true * if desired, the driver may do a "hard" clear to the device, potentially taking a "long" time (up to several seconds). If successful (meaning no escape), controller_init will not be called again during the scan, so the potentially long time penalty will not be paid with each scan pass. * even though for most cases, controller_init IS called before any of the read interface procedures, the driver MUST NOT count on it; a system may be loaded before the scanner gets all the way through the boot list, then the loaded system itself may call the read interface to do secondary loading. * the philosophy of controller_init is really to give the boot scanner the best possible chance of successfully accessing a device, no matter what the device's previous state might have been. procedure set_devicename(); * called only by the boot scanner after the device has been successfully accessed * normally assigns a string constant to devicename * drivers of multiple device types look at m_msus.dev to determine which device name to assign * CS80 drivers do I/O (CS80 describe cmd) to determine the device name procedure unit_init; * called by the scanning procedures & the read interface routine m_init * the driver may assume that unit_init will be called before the initial call to deviceread * unit_init should: 1. confirm CONTROLLER present & of type consistent with m_msus.dev. 2. confirm UNIT/VOLUME present, but NOT "medium present" or "unit ready" 3. SET m_msus.dev to the correct value if the controller supports more than one dev type. 4. configure the unit if necessary, and remove any holdoff's. procedure deviceread(); * the reason for all the rest of this stuff * the error conditions "no medium" and "not ready" deserve special comment. Some devices don't distinguish between "no medium" and "not ready", thus the driver has to decide which error code to return. For proper operation with the extd scanner, follow this rule: return "no medium" if the device SHOULD NOT be tried again; return "not ready" if the device SHOULD be tried again. This distinction allows the drivers to specify no "retries" for say, 9885's or Chinooks, where it is undesirable to repeatedly clang the 9885's heads or run Chinook's motors. On the other hand, it does allow drivers to specify retries for CS80 tapes and Amigo hard discs, where the units do not become ready immediately and need time for the tapes to load or the hard discs to spin up to speed. .DE .SP .H 3 "Three Human Interface Extension Mechanisms" To allow extensions to the boot ROM by an O.E.M., the boot ROM uses the test list, the driver list, and the boot list. It also uses replaceable human interface drivers as much as possible. In order to prevent support problems, these drivers are NOT to be used by operating systems. .SP The display output vectors used by the boot ROM are: .AL .LI "WINIT - " Initializes and clears the console display, and sets up other display vectors. .LI "WTB - " Writes a character in D0 at the location PRTHEAD, increments PRTHEAD to the next position. It ignores carriage returns and does carriage return/line feed for line feed. All other characters are printed with no translations. .LI "TABXY - " Positions PRTHEAD at X(D0),Y(D1) on the screen. The range of X is from 1 to the width of the screen, left to right. The range of Y is from 1 to height of the screen, top to bottom. A value of zero means do not change that coordinate. .LE .P 0 The display output data structures used by the boot ROM are: .AL .LI "PRTHEAD - " Contains the address of the next CRT position to write to when the routine WTB is called. .LI "H_50_60 - " This bit tells whether to use 50 or 60 Hz when initializing the compatibility display. This is a LOWRAM permanent value, except during the RAM test when a copy is kept in high RAM. It does not apply to the bit mapped display controllers. .LE .P 0 The keyboard input vectors used by the boot ROM are: .AL .LI "RINIT - " Initializes the keyboard for interrupt service and initializes any required data structures. Interrupt service will handle the PAUSE key and configure mode immediately. Any other key will cause ATTENDED to be set to true. .LI "RSTATUS - " Sets the condition code to NOT ZERO if there is a character ready to be read, and sets condition code to ZERO otherwise. .LI "RDB - " Gets a character from the input queue and puts it into register D0. .LE .P 0 The Keyboard Input Data Structures used by the boot ROM are: .AL .LI "RBUFF - " A 16 character input buffer queue. .LI "RWAIT - " The number of characters waiting to be processed. .LI "RHEAD - " Address of the next character ready to be processed. .LI "RTAIL - " Address of the next free character position at the end of the queue. .LE .P 0 Other Data Structures: .AL .LI "ATTENDED - " This bit tells if a system boot is to be forced by the attending operator. .LI "RAMTEST_TIME - " A boolean bit in memory used to control the RAM test time. .LE .SP If no human interface exists, then either (or both) sets of human interface vectors can be set to point at dummy drivers which allow the rest of the code to operate without requiring either device.) .SP .H 4 "How To Call Human Interface Routines" All of the human interface routines can be called using a JSR relative to an address register. For example, WINIT is normally called using the following mechanism: .SP .DS MOVE.L F_AREA,Ax JSR WINIT(Ax) .DE .SP .H 3 "Self-Test Extension Mechanisms" The self-test vectors are also in the form of a linked list headed by a soft pointer that can be modified by a boot extension ROM. .SK .H 2 "LAN BOOTING" .H 3 "LAN Read interface specifications" .SP The LAN drivers will support the read interface as used by secondary loaders. .DS The LAN MSUS is fmt = 7 dev = 2 sc = card select code .DE .P In hex this is E2xxSCxx. The x fields are don't cares, the SC field is the select code. .P Other fields in the msus may be non zero but are not significant for read interface purposes. .P The LAN drivers also require the 6 byte link address of the server. This link address is left at offset 0 in the F_AREA and could be accesses as F_AREA^ or in assembler code .DS movea.l F_AREA,a0 ....... (a0) .DE .P When using the read interface, INIT must be called before any other read interface entry points. (not all devices require this). .P A false value for M_INIT indicates either no card, wrong card type or the card failed to initialize. .P The LAN interface works with two kinds of files, files which are LIF volume images and those which are not. .P M_FOPEN parameters are treated a little differently than otherwise because the interface has only file level and not directory level access. .P If the FTYPE parameter is not -1 then the file specified must be a LIF volume image and a file of matching type must be in the volume. If such a file is found then the lif extension field is returned in the X_ADR parameter, (for system type files this is the execution address) the file length is returned in the LENGTH parameter. .P If the FTYPE parameter is -1 then the file specified may or may not be a LIF volume image (LVI). If it is an LVI then the values for the first file found in the volume will be returned. If it is not an LVI then X_ADR and FTYPE will be returned as 0 and LENGTH will be returned as -1. .P The LIF volume images allowed for LAN booting deviate from the LIF standard in that: * .FS * .DL 0 1 .LI Empty entries are skipped. .LI Both the logical and physical end of directory conditions are recognized. .LE .FE .AL 1 .LI The directory must begin on either sector 1 or sector 2. .LI The files in the directory MUST all have the same start, length and type values. .P The LAN boot protocol is intended only to transport files NOT directories. The LIF volume image is used as a mechanism to provide the information normaly supplied by the directory on a LIF volume. Neither the volume name or file names are ever examined. It is assumed that the correct name was used given to the server. .P The multiple files with identical type, start and length values is used by the HP-UX secondary loader. All HP-UX type system files boot the same physical file, which is the secondary loader. This loader then examines the name under which it was booted then loads the corresponding a.out file. .DS The M_READ MEDIA parameter is used as follows: If the file is a LIF volume image then if MEDIA is true then offsets are volume image relative. if MEDIA is false then offsets are from the start address given in a directory entry. If the file is not a LIF volume image then then offsets are always from the beginning of the file. .DE .P Errors are signaled by the standard read interface escape codes .SP .tr~ .VL 15 .LI No~Device not used .LI No~Server (M_FOPEN only) The server did not respond to a boot request. .LI Not~Ready (M_FOPEN or M_READ) LAN hardware powerup or reset failed or M_FOPEN was called without calling M_INIT, or M_READ was called without calling M_FOPEN. .LI Read~Error For M_FOPEN, the open operation worked but the server has since then failed to respond to a read request or the server sent eof. For M_READ, the server failed to respond to a read request or the server sent eof. .LI Bad~Hardware (M_FOPEN or M_READ) the LAN hardware failed to respond to some operation or reported a catastrophic error. .LI Bad~State (M_FOPEN or M_READ) damaged bootrom code .LE .tr .SP .P If a system calls the bootrom to boot/reboot a system and a file name is specified and the msus is for LAN, the bootrom will retry indefinitely to contact the server at the given link address. All other devices have a fixed number of retries/timeout and will report No Medium or SYSTEM NOT FOUND. .P The system call for a boot/reboot on LAN is the only time an indefinite retry/timeout is used. .SK .H 3 "PACKET FORMATS" The basic mechanism used is the IEEE802.3 Ether Net protocol with HP extensions. The protocol is version 2 of the RMP BOOT PROTCOL. This produces a packet of the following general format as generated by the bootrom: .SP .DS field name size value/description ------------------------------------------------------------------------------- destination address 6 bytes server link address or boot multicast value source address 6 bytes card link address length 2 bytes # of bytes in the packet past this field dsap 1 byte $F8 signals hp extension ssap 1 byte $F8 signals hp extension cntrl 1 byte 3 filler 3 bytes all zeroes dxsap 2 bytes $608 sxsap 2 bytes $609 data variable RMP boot packet The five RMP boot packets used have the following formats: ========================================================== .DE .H 3 "BOOT REQUEST PACKET" .SP .DS boot request packet transmitted by the bootrom field name size value/description ------------------------------------------------------------------------------- type 1 byte 1 return code 1 byte 0 sequence no. 4 bytes normally a value from the real time clock session id 2 bytes normally 0 version 2 bytes 2 machine type 20 bytes HPS300_10 or HPS300_20 blank padded file name variable name of file to be read. This field has a 1 byte length field as its first byte. .DE .SP NOTES: .SP .P The reason for a length byte in the file name field is to allow other optional fields to be appended to this packet type. The underlying assumption is that optional fields would appear in the packet in a specific order and that any fields not present and lying between the machine type field and the last field actually present would have zero valued length bytes. .P The version field is set to 2 as a final measure to ensure that this bootrom will not attempt to communicate with an AVESTA server. This still allows a server to be written which could handle both AVESTA and Series 300 compatible machines. .SP .H 4 "BOOT REPLY PACKET" .SP .DS boot reply packet transmitted by the server in response to a boot request field name size value/description ------------------------------------------------------------------------------- type 1 byte 129 return code 1 byte normally 0 sequence no. 4 bytes copied from same field in corresponding boot request packet session id 2 bytes generated by server version 2 bytes 2 file name variable normally copied from same field in corresponding boot request packet. .DE .SP .P See above boot request packet NOTE for details on this field and other optional fields. The version field must be greater than 1. .SP .H 4 "READ REQUEST PACKET" .SP .DS read request packet transmitted by the bootrom field name size value/description ------------------------------------------------------------------------------- type 1 byte 2 return code 1 byte 0 offset 4 bytes file relative byte offset of the first byte to be sent as data in the next read reply packet. session id 2 bytes copied from same field in corresponding boot reply packet size 2 bytes maximum number of data bytes to be sent in the corresponding read reply packet. .DE .SP NOTES: .SP .P The first byte in a file is at offset 0. The size field can be any value from 1 to 1482. Offsets are typically multiples of 256 or the value 1482 but under some conditions can be any value. S300 secondary loaders will often request reads from arbitrary offsets in a file. A request could be made for any single byte in the file. .SK .H 4 "READ REPLY PACKET" .SP .DS read reply packet transmitted by the server in response to a read request field name size value/description ------------------------------------------------------------------------------- type 1 byte 130 return code 1 byte normally 0 offset 4 bytes file relative byte offset of the first byte in the data field. Must be the same value as the offset field in the corresponding read request packet. session id 2 bytes copied from same field in corresponding boot reply packet data variable up to a maximum of size field in corresponding read request .DE .SP .H 4 "BOOT COMPLETE PACKET" .SP .DS boot complete packet transmitted by the bootrom field name size value/description ------------------------------------------------------------------------------- type 1 byte 3 return code 1 byte 0 unused 4 bytes 0 session id 2 bytes copied from same field in corresponding boot reply packet .DE .SK .H 3 "FILE SEARCHING USING THE LAN BOOT PROTOCOL" .SP .H 4 "GENERAL NOTES" .SP .DS 1. HP Series 300 bootrom interface specs/expectations are such that the user can be offered a choice of systems/standalone applications to load. 2. The current RMP boot specifications are such that this can not be done with out perverting them in some fashion. 3. The two functions missing are 1. SERVER IDENTIFY: have the server return its name for display purposes. This is not required but would be very helpful. 2. FILE LIST: obtain a list of files a particular server can supply to the requestor. This is required. The following changes have been made to the boot request and boot reply packet interpretations to accomodate these requirements. .DE .SK .H 4 "SERVER IDENTIFY" .SP .DS The key to making this work is the use of -1 in the boot request packet session id field (in the 3.2 spec this is labeled unused) and a session id value of zero in the boot reply packet. In the initiating boot request packet: The session id field will be set to -1. The sequence no. will be set to 0. The file name field will be empty. In response to such a packet the bootrom will expect a boot reply with the following characteristics: The return code is 0. The sequence no. 0. The session id is 0. If the above are all true then the file name field is assumed to be the servers name. This string of ascii characters will be truncated to 13 characters. If the file name field is empty then the servers link address will be used as its name. If the server does not implement this capability it should treat it as a boot request for the default file. The field values should then be: The return code is 0. The sequence no. 0. The session id non zero. The file name field containing the name of the file. If a reply packet is received with a the above characteristics the packet is assumed to have been mistaken for a default file request. The bootrom will add the file name to the list of selectable files and send a boot complete packet. The servers link address will be used as its name for display purposes. If any field in the packet contains an incorrect value, the packet will be ignored. .DE .SP .H 4 "FILE LIST" .SP .DS The Series 300 bootrom makes the assumption that if a server can not handle the SERVER IDENTIFY operation (ie it treats the probe as a standard default boot request) then it can not handle the FILE LIST operation either. The key to making this work is again making use of the session_id field of the boot request packet. The FILE LIST sequence starts with the same kind of a boot request packet as is used by the SERVER IDENTIFY except that the sequence no. is now greater than 0. The sequence no. field is assumed to be a signed integer. The session id field will be set to -1. The sequence no. will be set to some number greater than zero. The file name field will be empty. The sequence no. is to be treated as a request for the name of the Nth file in the default/availability list for the requestor. The boot reply packet fields will have: The return code at zero. The sequence no. copied from the boot request. The session id zero. The file name field containing the name of the file. The ability to request the Nth default file is intended as a way to speed recovery procedures in the event that communication with a server is lost during a LIST REQUEST sequence. It can be handled in a stateless fashion by the server. .DE .SP .P When a file name is received, the bootrom will add it to the displayed list of selectable files. * .FS * If the first character of the file name is a NULL then the string (with the null removed) will be displayed as a message only. ie it will not be interpreted as a file name. .FE The next normal boot request will have a sequence no. incremented by 1 from the previous request. .DS Return code handling is as follows: code code name bootrom action ------+-----------------------------------+--------------- 0 No Error. process as normal 3 Abort stop requesting 4 Server Busy suspend requests 18 Default filename does not exist. end the file list phase All other return codes cause the packet to be ignored. example of a LIST FILE sequence request reply seq. session return seq. session 1 -1 0 1 0 file1 2 -1 0 2 0 file2 3 -1 0 3 0 file3 4 -1 18 4 0 If a packet is received which contains an invalid value, it will be ignored. .DE .SP .H 3 "LAN General operations" .SP .DS In unattended mode, the first file identified will be selected. In attended mode, as files are identified they are presented to the operator for selection. When the LAN interface is selected in the bootrom overall scan code, first on select code 21 then on select codes 0..31, the following actions are taken: 1. for each card located, identify any servers connected to the card by sending a multicast server identify packet. (this is the only time the multicast address is used) 2. for each server, and in the order in which they respond, request the names of all available files. As each file is identified, it is presented to the operator for selection. (in unattended mode, the first file identified will automatically be selected) 3. when a file is selected, send a boot request giving that file name. NOTE: this bootrom always requests a specific file when it intends to load that file. The default form of the boot request is only used during server identify and file list operations. The bootrom overall scan may come back to the LAN interface on a subsequent pass. The LAN driver records which servers have responded for each interface card (to a maximum of 16 per interface card). Servers which have identified all of their files will not be scanned again ie the only packet such servers will see again during the bootrom scan phase is a multicast server identify. If communication with a server was lost during a previous file list phase, the bootrom will try to resume communications by requesting the N+1th file. Once a file has been selected, either the first file in unattended mode or the operator has selected one in attended mode, the packet sequence is as follows: Boot Request The return code set to 0. The session id set to 0. The sequence no. set to a number taken from real time clock. The file name field set to the name of the selected file. Boot Reply The session id field set to not 0. The sequence no. the same as this field in the boot request. The file name field set to the same as in the boot request. Return code handling is as follows: code code name bootrom action ------+-----------------------------------+--------------- 0 No Error. proceed to read phase 4 Server Busy wait then try again 5 Lengthen timeout wait then try again 27 Bad Packet ignore the packet All other return code values cause the bootrom to report that it could not open the file. Reporting an error will cause the bootrom to halt all operations. Both Server Busy and Lengthen timeout will cause the timeout between retrys to be lengthened up to a maximum of 15 seconds. Upon receipt of a valid boot reply packet, the bootrom will read the file. Read Request return code set to 0. offset set to a byte offset in the file. session id taken from the session id field of the boot reply. size number of bytes requested, guaranteed to be even. Read Reply offset same value as given in the read request session id same as session id of boot reply size determined from packet length must be less than or equal to the number of requested bytes. If greater than requested bytes, the packet will be ignored. NOTE: If the reply size is less than the request size, a read request will be issued in an attempt to read all of the originally requested data, by using adjusted offset and size values. Return code handling is as follows: code code name bootrom action ------+-----------------------------------+--------------- 0 No Error. proceed to read next read 2 End of File report read error 3 Abort report read error All other return code values cause the packet to be ignored. Reporting an error will also cause the bootrom to halt all operations. Each ignored packet will cause the timeout to be extended. Each original request resets the timeout. Boot Complete Request Sent when boot operation is done or when EOF encountered. session id taken from session id field of boot reply. .DE .SK .H 2 "IODC INTERFACE SPECIFICATIONS" .SP .DS Specification For Series 300 IO Dependant Code IODC 300 This specification applies to all Series 300 DIO2 interfaces and all display interfaces with ID byte hex 39 11 Sep 87 rdq General Concepts This subset defines a mechanism for a subsystem to perform tests on itself at boot time. The purpose of the tests would be to identify failed field replaceable units (FRUs). The interface will contain 680xx instructions in rom which the bootrom will locate, download and call on code to perform test operations. This approach minimizes the interface cost for such a capability and is extensible. eg if the test is to be performed by special processor on the interface then the rom code provides a standard interface to the bootrom. The test code can be developed and tested outside the bootrom environment then moved in to it when the bugs are out. The conventions & terminology used for Series 300 are patterned after the same capabilities proposed for IODC entry TEST for the Series 800. General Specifications Locating the IODC Interface offsets hex 85 & 87 are concatenated to form a 16 bit unsigned value. This value when added to the interface base address to forms the absolute physical address where the IODC 300 header will be found. If the value is zero it is assumed that there is no IODC on the interface. IODC 300 Structure The structure has two bytes of header followed by an arbitrary number of consecutive code blocks. All data in the structure is stored every other byte. If the IODC 300 header address is even then data is in the even bytes, if it is odd then data is in the odd bytes. Storage Description Value Range 1 byte flag 0 1 byte revision # two hex digits eg A0 For each code block 1 byte block type code 0..255 1 byte end of list marker non zero means this is the last header 2 bytes code size 2..65535 (size is in bytes and does NOT include the 4 bytes in the block header) code body next code block (if there is one) etc. The block type byte is interpreted as follows: msb 7 8 6 5 4 3 2 1 0 lsb m m m c c c c c c the m m m is a machine language code 0 0 0 is M680xx type code ie at least 68010 compatible 1 0 0 is HP-PA type code the c c c c c c is an entry point code 0 0 0 0 0 0 is entry point TEST For series 300 the header type byte is zero. Entry TEST Specifications A checksum will be computed for the code body, if it fails then the code will not be called. For execution, code will be moved from the interface (and compacted to consecutive byte format) to some arbitrary ram location. All code therefore must be self relocating. The execution entry point is the first location after the code size field. The bootrom will JSR to this location. ( see calling sequence below ) offset description 0 block type code 1 eol flag 2 code size 4 execution entry point { ENTRY_TEST equ * } All calls made by the bootrom are for Off-line type tests. There are 3 kinds of tests called for, but only the Off-line non-interactive (normal) test is required. Type of test When called for normal default (eg un attended powerup) extended bootrom configured to continuous, extended interactive bootrom configured to one pass, extended The calling and environment conventions assume that the code is written in ASSEMBLER language. The calling sequence is : pea com_rec jsr entry_test or the equivalent in PASCAL is the statement entry_test(com_rec); where entry_test has been defined as: procedure entry_test(var c : com_rec_type); NOTE that ENTRY_TEST code is responsible for removing the address of com_rec from the stack before returning. If the test code is written in PASCAL or C etc. then there must exist some interface code to create the appropriate environment and on return, the original environment must be completely restored. The environment is such that, A7 is the stack pointer and A6 contains the address of where to go when a bus error occurs. no other registers are significant. The bootrom calling sequence also saves any registers it needs before the JSR to ENTRY_TEST is executed. The only ram locations the test code may change are stack space, buffer space (allocated) after the RETURN INFO call, and message space provided by the BOOTROM for the purpose of returning message data. All exception and interrupt vectors are set to CRASH except Bus error which is set to clean the stack and jump thru A6, interrupt level 1 which is set to the bootroms keyboard ISR and possibly the interrupt level for an RS232 card used as a console port. If the test code alters exception or interrupt vectors, these must be restored to their original values before control is returned to the caller. Test code must not allow an interrupt to occur when test code is not in control. NOTE: In the Series 300 bootrom, the IODC code will be invoked after any existing test code has been run against the interface. NOTE: NOTE: In Rev. C the IODC code for the system console will never be called. ( hence the need for Rev C1 ) it will be called for non system console displays. In Rev. C1 the IODC code is called before the normal boot code turnon occurs. eg. for displays, the ID rom will have been checksummed, the init sequence will have been executed to turn on the display and the frame buffer will have been cleared. All communication between bootrom and test code is thru a communications record structure. COM_REC is declared as follows { all fields are 32 bits wide } corresponding argument in HP-PA IODC COM_REC_TYPE = RECORD op_code : INTEGER; {arg1} device : ANYPTR; {arg3 ?} type_code : INTEGER; {arg5} buf_addr : ANYPTR; {arg6} test_sect : INTEGER; {arg7} lang : INTEGER; {arg8} data_addr : ANYPTR; {arg9} buf_size : INTEGER; {ret0} status : INTEGER; spare1 : INTEGER; spare2 : INTEGER; The following fields contain the absolute addresses of routine entry points. See below for calling conventions. delay : procf1arg; start_timer : procv1arg; time_expired : procv2arg; pspare1 : INTEGER; pspare2 : INTEGER; END; op_code always identifies the operation to be performed. operation: value Return Info 0 Execute Step 1 Describe Section 2 Return Message 3 device always contains the base address of the interface under test. lang always contains the a code read from the keyboard language jumpers. The high order word (16 bits) contain a 0 if the keyboard is HP_HIL or a 1 if it is NIMITZ The low order word contains the language code. status always used to return a code describing the results of the call (see list below for expected values) spare1 unused parameter Rev. C1 bootrom will set these to 0 spare2 unused parameter Rev. C1 bootrom will set these to 0 delay,start_timer and time_expired each contain the address of a procedure delay will wait a specified number of micro seconds before returning calling sequence is move.l #time,-(sp) movea.l delay(a0),a1 jsr (a1) it cleans off the stack before returning start_timer will calculate the value the timer will have, a specified number of micro seconds in the future calling sequence is pea time time is the address of a location containing the number of micro seconds movea.l start_timer(a0),a1 jsr (a1) it cleans off the stack before returning time_expired will check its argument against the timer. It is designed to be used with start_timer. calling sequence is addq.l #-2,sp pea time time is the same address given to start_timer movea.l time_expired(a0),a1 jsr (a1) tst.b (sp)+ bne time_has_expired beq there_is_time_remaining pspare1 and pspare2 are unused, set to zero, and are intended to contain procedure addresses. The value and interpretation of all other parameters is dependant on the op_code value. status code values and interpretation ------------------------------------- -4 error detected; damage possible do not continue testing. -3 error detected; FRU isolated, module not usable -2 error detected; FRU isolated, module may be usable -1 error detected; FRU not isolated, testing should continue. 0 no errors 1 non-existent option (step, section, list number) 2 returning for user input, next call should be sequential. 3 invalid user input, re-execute step with new input. 4 invalid parameter. 5 invalid command. 6 not a test section (used to control the results display for a section. After this point if only 0 status codes are returned by steps in the current section then at the end of the section, the results field of the display is left blank instead of the normal Failed or Passed message.) Return Info used to setup for a particular test sequence. NOTE: This will be the first call made to test code. op_code := 0; type_code contains the number of the test list to be performed. (see description of standard test lists below) buf_addr contains the address of an array[1..100] of integer; on normal return, this array will contain the test step info. buf_size on normal return, contains the size of the data buffer required for execution of the test steps. The same space allocated after this call is available on all following calls. all other op_code dependant parameters are undefined for this operation. ****************************************************************************** ============================================================================== NOTE: For display devices the total space available is 67584 (66k) bytes. This means 67184 bytes to divide between code and global data (as specified by buf_size) This restriction is because of the restrictions the bootrom is operating under during its search for a display console. ============================================================================== ****************************************************************************** Execute Step used to execute a specific test step. op_code := 1; type_code contains the number of the step to execute. buf_addr may contain the address of single character of user input. data_addr contains the address of a buffer of the size requested by the buf_size argument in the Return Info call. all other op_code dependant parameters are undefined for this operation. Describe Section used to retrieve a one line description of a test section op_code := 2; type_code contains the number of a test list test_sect contains the number of a test section in the list buf_addr contains the address of an area of 255 bytes to be used to contain the message. buf_size on return will contain the actual number of bytes placed in the space pointed at by buf_addr. all other op_code dependant parameters are undefined for this operation. Return Message used to retrieve a status/error message/user input prompt op_code := 3; type_code is zero for short msg, one for longer msg buf_addr contains the address of an area of 255 bytes to be used to contain the message. buf_size on return will contain the actual number of bytes placed in the space pointed at by buf_addr. all other op_code dependant parameters are undefined for this operation. Standard Test Lists ------------------- List number ----------- 1 Interactive Off line interactive 2 Default Non interactive Off line normal 3 Extended Non interactive Off line extended 4 Default Interactive On line for use by O.S. code 5 Default Non interactive On line for use by O.S. code .DE .SK .DS Test List Composition --------------------- A test list is composed of contiguous 4 byte integers. These integers are organised in sections. The first integer in each section is the section number. This number will be an argument given in a Describe Section call. The last number in a section will be either a -1 or -2. A -2 signals end of test list. A -1 is used to separate sections. All numbers between the section number and the -1 or -2 must be greater than zero and are step numbers. A step number is given as an argument in the Execute Step call. Examples 1 section 1 1 section 1 1 step 1 1 step 1 2 step 2 2 step 2 -1 section separator -2 end of test 2 section 2 3 step 3 -2 end of test It is suggested that if there are more than one test steps that the very first step be used only to initialize the ram area allocated as requested by the Request Info call. This same area is made available on all Execute Step calls and is not examined or altered by the calling program. It is can therefore be used to contain status or other information which needs to survive between steps. The bootrom has no mechanism for imposing a time limit on tests. List number 2 is the one invoked during a normal powerup or reboot operation. The steps in this list should take no longer than 4 seconds and preferably no more than 3 seconds. This is because while a test step is in progress, the bootrom can only record key strokes and can not react in any other way to them. The steps in list numbers 1 & 3 may take as long as required because there is no requirement to respond to the keyboard in a timely fashion. It is recommended that if there is no requirement for extended tests, the test rom should return the same list for list 2 and list 3. Test Execution Sequence ----------------------- Steps are done in sequence unless notes direct otherwise. The device is assumed to be usable until proven otherwise. If list type is normal powerup the all section info messages are suppressed. if no display present then all messages are suppressed ( this could mean that the display routine vectors are not yet setup ) 1. locate the ROM 2. locate the test header 3. allocate the required ram space (400 bytes + code requirements) 4. download the code 5. checksum the code if it fails, pretend no IODC code (Rev. C1 bootrom has only pass fail capability on a select code) 6. request a test list ( Return Info call) if looping then if extended then list is 3 else list is 2 else if extended then list is 1 else list is 2 7. status check 0 then step 9 1 then step 8 otherwise exit testing 8. request a test list ( Return Info call ) if was list 1 then do list 3, goto step 7 list 3 then do list 2, goto step 7 list 2 then exit testing 9. allocate the space requested by the Return Info. Begin execution of the test if list is 2 (normal powerup) then perform one pass operation otherwise perform two pass operation. 10. If normal mode then goto step 13. 11. blank the menu half of the display. 12. sequence thru the test list and for each section found, a. call for Describe Section and if a message returned, b. show it in the line for that section. c. remember the highest number. Exit all testing if 1. a non zero status is seen. 2. an out of range section number is seen. valid. section numbers are in the range 1 to h-6 where h is then number of lines on the display. at end of sequences goto step 13 13. reset the scan index. section is marked pass. 14. increment to next number in list. 15. a. if number >=0 then goto step 16 b. if normal list then goto step 16 c. display section pass/fail or blank d. clear section message area e. if number <= 0 then exit testing ( should be a -2 ) f. save the section number g. set section status to pass h. goto step 14. 16. a. call for Execute Step b. save the status c. status check <=0 goto step 18 2 or 3 or 6 then goto step 18 exit testing 18. a. call Return Message b. if status<>0 then exit testing c. if exec status = 0 goto step 20 d. if exec status < 0 goto step 19 e. if exec status = 2 or 3 goto step 21 f. mark section neither pass or fail g. goto step 20 19. a. print as error message (status area) b. mark device unusable c. mark section as failed 20. a. print as info message (section info area) b. if exec status = -4 then exit testing c. goto step 14 21. a. if not interactive mode then exit test b. if no text in message then exit test c. put in section info area d. put in prompt area e. get input f. if exec status = 2 then goto step 14 g. backup one number h. goto step 14 .DE .SK .H 2 "SCSI DEVICE INTERFACE REQUIREMENTS" .P This document describes the operating characteristics that a SCSI device must have in order for the Rev. C and C1 Bootroms to successfully load a system from that device. .P The boot ROM works only with devices which are capable of direct access read operations. The device types recognized are: .DS code device-class/description 0 DAD Direct Access Devices (Read & Write) 4 WORM Write Once Read Many 5 RO Read Only 7 MO Magnito-Optical (Read & Write) hex 7F Logical Unit not present .DE .P The boot ROM operates in a very restricted environment. Effort has been made to allow as wide a range of devices as possible with in the limits of current knowledge, code space and implementation time available. .P Operations are done in asynchronous mode only, attempts to negotiate synchronous mode are ignored. Mid-operation disconnects are not allowed. For Rev. C, parity error checking is always done. For Rev. C1, parity checking is controlled by the "parity" switch on the interface board. .P Four commands were chosen as the minimum command set required. These are: .SP .DS 1. Inquiry opcode hex 12 This command is used for two different purposes: a. To find out the device type. When issued for this purpose, only 2 bytes are requested. b. To obtain the vendor id and device name. When issued for this purpose, 36 bytes are requested. The vendor id is assumed to start in byte 4 (after the length byte) and occupy 8 bytes. The device name is assumed to start in byte 12 and occupy 16 bytes. The lunit and length fields will be set but all other fields in the command will be zero. .DE .SP .DS 2. Read capacity opcode hex 25 This command is required so that the bootrom can perform translations from the 256 byte sector addressing used internally to to whatever block size the device uses. The lunit and length fields will be set but all other fields in the command will be zero. In the returned data, The block sizes must be a power of two and in the range of 32 bytes to 1 Megabyte (1024*1024). There are no restrictions on the number of blocks. .DE .SP .DS 3. Request sense opcode hex 03 The lunit and length fields will be set but all other fields in the command will be zero. Eight bytes are requested. Fewer may be sent. Only the sense-key field is checked. Sense key codes 0 thru 8 and code 11 (hex B) are recognized; any other code will cause the bootrom to stop communications with the device. .DE .SP .DS 4. Read opcode hex 28 It was felt that the bootrom could not reliably operate with both short and long format reads. The majority of devices either require or can use the long format command rather than the short format version. The lunit field, block-number and number-of-blocks fields will be set but all other fields in the command will be zero. .DE .H 3 "Parity error handling" .SP .P When the bootrom detects a parity error it will set ATN . Then in response to the MSG_OUT phase, an ABORT message (hex 6) will be sent. Rev. C always has the interface controller chip do parity checking. Rev. C1 reads the "parity" bit from the interface switches and sets the controller chip accordingly. .H 3 "Retries, timeouts and messages." .SP .P When the boot ROM is merely attempting to identify a device, the Inquiry command will be attempted up to 4 times. All other commands are attempted 7 times. The restriction on the identify is to keep from spending too much time looking for boot devices. (there are impatient people watching and there are a lot of places to look for systems) .P The bootrom performs all operations by polling (i.e., interrupts are disabled), so the timeouts and their placement in the sequence of events is different from those used/specified by operating systems which are interrupt-driven. .H 3 "Timeouts:" .SP .P On a select operation, wait 1 millisecond for select to complete. .P Between phases or after a select, wait 15 seconds for REQ. This is most critical for the time between COMMAND_OUT and DATA_IN phases on a read command. .P After a bus reset, the bootrom waits for approximately 2 seconds before attempting any other bus activity. .H 3 "Messages:" .SP .P The only Message accepted is Command Complete (code 0) (extended messages are read but no attempt will be made to examine them) .P The only Message generated is Abort (code 6)