RMP BOOT PROTOCOL AS USED BY THE HP SERIES 300 SPUs The basic mechanism used is the IEEE802.3 Ether Net protocol with HP extensions. This produces a packet of the following format as generated by the bootrom : 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 have the following formats: ===================================================== 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 blank padded file name variable name of file to be read. This field has a 1 byte length field as its first byte. NOTES: The seqence no. is used to identify unique requests from a client system. The server will use this to determine if the request is a retry of a request it has already seen or a request for a new session. 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. 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 writen which could handle both AVESTA and Series 300 compatable machines. The machine type field is to contain ASCII characters. Servers may use this field in determining which files will actualy be made available to the requestor/client. 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. See above boot request packet NOTE for details on this field and other optional fields. The version field must be greater than 1. 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. NOTE: 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. 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 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 FILE SEARCHING USING THE LAN BOOT PROTOCOL 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. SERVER IDENTIFY: 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 for display purposes. 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 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. FILE LIST: 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. When a file name is received, the bootrom will add it to the displayed list of selectable files. The next normal boot request will have a sequence no. incremented by 1 from the previous request. 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. General operations 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 lenghtened 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. From Appendix E possible return values 0 no error . 2 End of File encountered 3 Abort this operation 4 Server Busy 5 Lengthen timeout . 16 Filename specified does not exist 17 Filename can not be opened, no permission 18 Default filename does not exist 19 Default filename can not be opened 20 Filename specified cannot be created . 24 Forced boot is disabled, or security is invalid 25 Bad session ID detected 26 Bad sequence number detected 27 Bad packet detected 28 Offset out of range 29 End of Down Load or Read . 255 unknown error NOTE: not all of the above return codes apply to a boot operation.