HP 3000 Manuals HP 3000 Manuals
The initial system loader
The Initial System Loader performs these functions:
* provides user interface with boot path information and alters boot
path.
* loads an operating system-specific code set or a hardware-specific
code set and launches it. If this implementation-specific code
does not damage the ISL image, ISL remains in memory in case the
code returns control to ISL for initialization of further
utilities.
Certain standards are used by hardware and software operating systems
using system bootstrap, IPL, and ISL standard. These standards are
architectural in nature, but are not necessarily defined in any system
architectural document. The remainer of this chapter contains a
description of these standards.
Stable storage and nonvolatile memory layout
Stable storage and nonvolatile memory (NVM) are described as blocks of
bytes that are accessible by bootstrap, ISL, and the operating system
through standard entry points. The first 96 bytes of stable storage are
required implementation; bytes 96 through 191 are optional, but if
implemented they are reserved for PDC and ISL access as described below.
Nonvolatile memory is not required by the architecture; therefore, it
should contain only values that can be managed by an alternate method.
When more than one byte is used in the representation of an item in
stable storage, the most significant byte is the byte with the lower
address.
The format of stable storage is shown below:
Table 25-1. Stable storage format
---------------------------------------------------------------------------------------------
| | |
| BYTE | CONTENTS |
| | |
---------------------------------------------------------------------------------------------
| | |
| 0-31 | Boot flags and device |
| | |
---------------------------------------------------------------------------------------------
| | |
| 32-63 | Unique file names |
| | |
---------------------------------------------------------------------------------------------
| | |
| 64-95 | Future OS requirements |
| | |
---------------------------------------------------------------------------------------------
| | |
| 96-127 | Console terminal |
| | |
---------------------------------------------------------------------------------------------
| | |
| 128-159 | Alternate boot path |
| | |
---------------------------------------------------------------------------------------------
| | |
| 160-191 | Dump flags and device |
| | |
---------------------------------------------------------------------------------------------
| | |
| 192-nnn | Future OS options |
| | |
---------------------------------------------------------------------------------------------
Autoboot flags and device path
This 32-byte field defines the coldload path that PDC uses for autoboot.
If this path is not valid, or if the device that it describes is not a
valid boot device containing an IPL image, PDC then requests a valid path
through the console if the console is present; otherwise, the error is
displayed through the front panel.
A detailed internal representation of a boot or console path (the format
applies to the auto bootpath, the alternate boot path, the dump path, and
the console path) is as follows:
Table 25-2. Boot or console path
-----------------------------------------------------------------------------------------------------
| | | | | |
| 0000 | flags | BC(0) | BC(1) | BC(2) |
| | | | | |
-----------------------------------------------------------------------------------------------------
| | | | | |
| 0004 | BC(3) | BC(4) | BC(5) | MOD |
| | | | | |
-----------------------------------------------------------------------------------------------------
| | | | | |
| 0008 | | Logical_ID | | |
| | | | | |
-----------------------------------------------------------------------------------------------------
| | | | | |
| 000C | | Device_Depend | | |
| | | | | |
-----------------------------------------------------------------------------------------------------
| | | | | |
| 001F | | | | |
| | | | | |
-----------------------------------------------------------------------------------------------------
| | | | | |
| 0020 | | | | |
| | | | | |
-----------------------------------------------------------------------------------------------------
Note that in the above illustration, the flags field in the console path
is ignored. The format of flags is as follows:
Format of flags
Table 25-3. Format of flags
-------------------------------------------------------------------------------------------------
| | | | |
| 0 | 1 | 2-3 | 4 through 7 |
| | | | |
-------------------------------------------------------------------------------------------------
| | | | |
| ab | as | 00 | timer |
| | | | |
-------------------------------------------------------------------------------------------------
Console Path
This 32-byte field defines the device path that PDC uses to locate the
system console. If this path is not valid, or if the device that it
describes is not a valid console device image, PDC then uses a default
path.
Alternate Boot Path
This 32-byte field defines the coldload path that PDC uses (after getting
the go-ahead from the operator) if the operator rejects the autoboot path
through console intervention. If this path is not valid, or if the
device it describes is not a valid boot device containing an IPL image,
PDC then requests a valid path through the console.
Dump flags and device
This 32-byte field is used to describe the destination device for a
snapshot dump facility.
The format of nonvolatile memory is shown below:
Table 25-4. Nonvolatile memory
---------------------------------------------------------------------------------------------
| | |
| BYTE | CONTENTS |
| | |
---------------------------------------------------------------------------------------------
| | |
| 0-63 | PDC and boot reserved |
| | |
---------------------------------------------------------------------------------------------
| | |
| 64-nn | OS reserved |
| | |
---------------------------------------------------------------------------------------------
NVM is an optional implementation, not required by the architecture. If
NVM is implemented, the PDC and boot reserved area of NVM is as follows:
Table 25-5. PDC and boot area for NVM
---------------------------------------------------------------------------------------------
| | |
| BYTE | CONTENTS |
| | |
---------------------------------------------------------------------------------------------
| | |
| 0-1F | Last boot-device path |
| | |
---------------------------------------------------------------------------------------------
| | |
| 20-23 | Self-test status |
| | |
---------------------------------------------------------------------------------------------
| | |
| 24-27 | Powerfail time stamp |
| | |
---------------------------------------------------------------------------------------------
| | |
| 28-2A | Boot restart time stamp |
| | |
---------------------------------------------------------------------------------------------
| | |
| 2B-2F | TOC restart time stamp |
| | |
---------------------------------------------------------------------------------------------
| | |
| 30-63 | PDC and boot reserved |
| | |
---------------------------------------------------------------------------------------------
LIF standard
The Hewlett-Packard Logical Interchange Format (LIF) provides a standard
method for locating IPL code on the boot device.
The method of locating IPL code on the boot device must be the same for
all boot devices, computer processors, and the operating systems, so that
the PDC knows where to find it. Having IPL at the very beginning of the
device is ideal; however, some operating systems require a volume label
at the beginning of a disk. IPL also needs a method of locating its
modules (utilities) when they are needed.
The LIF standard addresses these issues, and provides a standard with
utilities already in existence. For further information on LIF format,
refer to LIF Directory Organization and Record Format for Data
Interchange.
LIF requires a 256-byte volume label at the beginning of the media; thus,
the operating-system-specific volume label can be located at the
beginning of the disk, offset by 256 bytes. The LIF volume label points
to the location of the LIF directory, which then points to the location
of each of the files.
Compliance to LIF standard does not require complete implementation. The
level of compliance to the standard in the IPL code is the minimum
implementation (volume header and directory in ASCII code). The format
of the files is the system object module (SOM) format.
The LIF volume header, as well as an entry in the LIF directory, points
to the IPL code.
The following drawing represents the LIF standard logical layout of disk
and tape media.
![[]](../../pic3k/M013422/FFN53c50.gif)
LIF Standard logical layout
The LIF volume label allows easy identification of media type and gives
the location of the directory. The format of the LIF volume label
follows:
Table 25-6. LIF volume label format
---------------------------------------------------------------------------------------------
| | |
| BYTE | CONTENTS |
| | |
---------------------------------------------------------------------------------------------
| | |
| 0-1 | LIF identifier |
| | |
---------------------------------------------------------------------------------------------
| | |
| 2-7 | Volume label (0-6 ASCII characters) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 8-11 | Directory start address (in blocks) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 12-13 | Octal 10000 |
| | |
---------------------------------------------------------------------------------------------
| | |
| 14-15 | Set to 0 (dummy) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 16-19 | Length of directory (fixed at |
| | initialization) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 20-21 | Set to 0 |
| | |
---------------------------------------------------------------------------------------------
| | |
| 22-23 | Set to 0 |
| | |
---------------------------------------------------------------------------------------------
| | |
| 24-41 | Set to 0 (level 1 extension) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 42-239 | Set to 0 (reserved for extensions and |
| | future use) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 240-243 | Byte address of IPL on media |
| | |
---------------------------------------------------------------------------------------------
| | |
| 244-247 | IPL length (in bytes) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 248-251 | Offset in IPL of entry |
| | |
---------------------------------------------------------------------------------------------
| | |
| 252-253 | Set to 0 |
| | |
---------------------------------------------------------------------------------------------
| | |
| 254-255 | Set to 0 (reserved by system 250) |
| | |
---------------------------------------------------------------------------------------------
The directory contains all of the information necessary to find files.
It is a linear list of 32-byte directory entries, one for each LIF file
on the media. The maximum number of entries in the directory is fixed at
the time of initialization. A logical end of directory mark is defined
to be a file type of -1 and is written only if the directory is not
filled. The physical end of directory is determined by adding the start
of directory and length of directory fields from the volume lable.
Directory entries must be stored so that they are in strictly increasing
starting addresses on sequential media. Directory entries are undefined
after the logical end of directory, so when a file is appended to the
directory, the following directory entry's file type must be set to -1 to
make it the logical end of the directory.
LIF addressing is in blocks of 256 bytes, and system addresses are
2K-bytes-aligned.
Each directory is organized as follows:
Table 25-7. LIF addressing
---------------------------------------------------------------------------------------------
| | |
| BYTE | CONTENTS |
| | |
---------------------------------------------------------------------------------------------
| | |
| 0-9 | File name (1-10 ASCII characters, trailing |
| | blanks) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 10-11 | File type |
| | |
---------------------------------------------------------------------------------------------
| | |
| 12-15 | Starting address (in blocks) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 16-19 | Length of file (in blocks) |
| | |
---------------------------------------------------------------------------------------------
| | |
| 20-25 | Time of creation |
| | |
---------------------------------------------------------------------------------------------
| | |
| 26-27 | 1 /volume number |
| | |
---------------------------------------------------------------------------------------------
| | |
| 28-31 | Set to 0 (implementation) |
| | |
---------------------------------------------------------------------------------------------
The file type is a 16-bit signed integer. The defined file types that
are recognized by systems are
* 0--Purged file
* 30001--Bootable, executable file
* 30002--Boot data file
* 30003--Autoexecutable file list
* 30004--Data protect file
* 30010--HPE system file
A file is deleted from the directory by changing its file type to -2, to
represent a purged file. The data itself need not be removed from the
media.
Bootable utility format
All of the bootable utilities accessible through the LIF directory must
have enough of a common format for IPL to load and launch the utilities
through a standard method. IPL may need to know the intended physical
memory destination address for which the module was linked, as well as
the length of the image and the entry point. For those utilities that
are position independent, the destination address can be set to -1 and
IPL will load it at the first available memory after IPL.
All software implementation intends to support the system object module
(SOM) format, using the linker; therefore, an auxilary SOM header for
IPL, as described below, would meet IPL's needs for loading and launching
bootable utilities. For further description of the linker and the SOM
format, refer to the System Linker External Specifications and the System
Object File Format Architectural Control Document.
![[]](../../pic3k/M013422/FFN63c50.gif)
Figure 25-1. Boot utility format
Main Memory Layout
Although the exact memory locations of boot and IPL code during the boot
process vary according to size of the IODC and IPL, a general description
of memory layout is presented here for clarification. Also, the first
page of main memory is reserved for communication between PDC and
software.
Table 25-8. Main memory layout
----------------------------------------------------------------------------------------------
| | | |
| X'00000000 | Initalize vectors | 0 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000040 | Processor dependent | 64 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000200 | Reserved | 512 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000350 | Memory configuration | 848 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000360 | MEM_ERR | 864 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000380 | MEM_FREE | 896 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000384 | MEM_HPA | 900 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000388 | MEMPDC | 904 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'0000038C | MEM_10MSEC | 908 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000390 | Initial memory module | 912 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'000003A0 | Boot console/display | 928 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'000003D0 | Boot device | 976 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000400 | Boot keyboard | 1024 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000430 | Reserved | 1072 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000600 | Processor dependent | 1536 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000800 | | 2048 |
| | | |
----------------------------------------------------------------------------------------------
The format of the first memory controller configuration is as follows:
* word0: HPA of the memory controller
* word1: SPA of the corresponding memory
* word2: SPA_size
* word3: Max_Mem
The format of the console terminal and boot device configurations are as
follows:
Table 25-9. Console terminal and boot device configuration
----------------------------------------------------------------------------------------------
| | | |
| X'00 | path | 00 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'08 | LAYERS | 08 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'20 | HPA | 322 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'24 | SPA | 36 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'28 | IODC_IO | 40 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'2C | Reserved | 44 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'30 | Class | 48 |
| | | |
----------------------------------------------------------------------------------------------
The format of the boot and system console device paths is the same as
that for the autoboot, alternate boot, and console paths in stable
storage. In the console path, the flags are ignored.
The offsets of IODC, IPL, and booted utilities are variable, based on the
size of code images.
Table 25-10. IODC, IPL, and booted utilities offsets
----------------------------------------------------------------------------------------------
| | | |
| X'00000000 | Page zero | 0 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| X'00000800 | | 2048 |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| MEM_FREE | Monarch PDC | MEM_FREE |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| | Console IODC | |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| | Boot Device IODC | |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| IPL_START | IPL code | IPL_START |
| | | |
----------------------------------------------------------------------------------------------