All rights reserved. The Berkeley software License Agreement
specifies the terms and conditions for redistribution.
@(#)1.t 6.1 (Berkeley) 5/14/86
.nr H1 1 .bp
1. INTRODUCTION .R
This document explains how to install the \*(4B release of the Berkeley version of UNIX for the Tahoe on your system. While this is the first release from Berkeley for the Tahoe, the version of X distributed by CCI is derived from 4.2BSD. Consequently, the filesystem format is compatible and it will only be necessary for you to perform a full bootstrap procedure if you are installing the release on a new machine. The System V UNIX systems distributed by CCI, Sperry and Harris are also derived from 4.2BSD, but only the network and filesystem remain compatible with 4.2 and 4.3. The object file formats are completely different in the System V releases. Thus, the most straightforward procedure for upgrading a System V system is to perform a full bootstrap. The full bootstrap procecure is outlined in chapter 2; the process includes booting standalone utilities from tape to format a disk, if necessary, and then copying a small root filesystem image onto a swap area. This filesystem is then booted and used to extract a dump of a standard root filesystem. Finally, that root filesystem is booted, and the remainder of the system binaries and sources are read from the archives on the tape(s).
The technique for upgrading a 4.2BSD-based system is described in chapter 3 of this document. As 4.3BSD is upward-compatible with 4.2BSD, the upgrade procedure involves extracting a new set of system binaries onto new root and /usr filesystems. The sources are then extracted, and local configuration files are merged into the new system. 4.2BSD user filesystems may up upgraded in place. Some 4.2BSD binaries may be used with 4.3BSD in the course of the conversion. However due to significant incompatibilities between the vendor derived version of 4.2BSD and the \*(4B release, most binary images will not function properly. For such programs it will be necessary, as well as desirable, to recompile this software after the conversion. Consult section 3 for a description of the differences between \*(4B and the previous systems provided for the Tahoe. Hardware supported
This distribution can be booted on a CCI Power 6/32, Harris HCX-7 or Sperry 7000/40 with any disks supported on the VERSABUS disk controllers sold by these vendors (SMD/E or VDDC). The new CCI SMD/E controller with working scatter-gather I/O is supported as well. In particular, the following drives are supported:
| FUJITSU 160M CDC 9766 300M |
| FUJITSU 330M CDC 340M |
| FUJITSU 2351 Eagle CDC 515M |
The only tape drives supported by this distribution are the ones attached to the Tapemaster tape controller. Distribution format
The distribution comes in two formats: (3)\0\0 1600bpi 2400' magnetic tapes, or (1)\0\0 6250bpi 2400' magnetic tape Installation from scratch on any machine requires a tape unit. If your machine is currently running 4.2BSD and has a network connection to a 4.2BSD or 4.3BSD machine with a tape drive, it is a simple matter to install the software from a remote tape drive.
If you have the facilities, it is a good idea to copy the magnetic tape(s) in the distribution kit to guard against disaster. The tapes are 9-track 1600 BPI or 6250 BPI and contain some 1024-byte records followed by many 10240-byte records. There are interspersed tape marks; end-of-tape is signaled by a double end-of-file.
The first file on the tape contains a very small file system containing preliminary bootstrapping programs. This is followed by a binary image of a 2 megabyte ``mini root'' file system. Following the mini root file is a full dump of the root file system (see dump\|(8)*). .FS * References of the form X(Y) mean the subsection named X in section Y of the X programmer's manual. .FE Additional files on the tape(s) contain tape archive images (see tar\|(1)). See Appendix A for a description of the contents and format of the tape(s). One file contains software contributed by the user community; refer to the accompanying documentation for a description of its contents and an explanation of how it should be installed. Hardware terminology
This section gives a short discussion of the hardware terminology to help you get your bearings.
The Power 6/32 (and the current HCX-7 machines being shipped) use a VERSABUS for all i/o peripherals. The console processor used for bootstrap and diagnostic purposes is also located on the VERSABUS. The terminology you must familiarize yourself with is necessary to configure hardware devices on your machine. The device naming conventions described here apply to the console processor; under UNIX device naming is simpler as you will soon see.
The VERSABUS is a 32-bit bus that supports devices which use 16-bit, 24-bit, or 32-bit addresses (or some combination). The type of each address placed on the VERSABUS is indicated by an accompanying address modifier. In addition to the width of the address present on the bus, VERSABUS address modifiers may be used to indicate the privileges of the requesting program (.e.g the program is executing in supervisory mode). The 6/32's VERSABUS adapter accepts device requests with either 16, 24, or 32-bit address modifiers and interprets the address as an absolute physical address in referencing main memory. This means that the address space for 16-bit devices overlaps that of 24-bit devices and both overlap the address space of 32-bit devices. Devices which do not support full 32-bit addressing can be difficult to work with as their limited addressing restricts the placement of i/o buffers in main memory. Unfortunately, because the VERSABUS has had limited acceptance there are very few good VERSABUS device controllers available; this has resulted in several non-VERSABUS devices being attached to the VERSABUS through bus-adapter cards. Devices of this sort often support only 16-bit or 24-bit addressing.
From the Tahoe side of the VERSABUS adaptor, when memory management is enabled, the three address spaces are mapped so as to avoid overlaps. Addresses in the range 0xffff0000 to 0xfffffff are used to access VERSABUS devices which use 16-bit addresses. References to this region of the Tahoe address space result in a VERSABUS transfer with a 16-bit address generated from the lower order 16 bits of the memory address and a ``short addressing non-privileged i/o access'' address modifier (0x10). Addresses in the range 0xff000000 to 0xffff0000 are used to access 24-bit VERSABUS devices, generating a 24-bit address and a ``standard addressing non-privileged data access'' address modifier (0x01). Finally, any other address in the the primary i/o adapter space, 0xf0000000 to 0xff000000, generates a 32-bit VERSABUS address with an ``extended addressing non-privileged data access'' address modifier (0xf1). Note, however, that 32-bit addresses generated by references to this region result in a VERSABUS address with bits 31-30 set to 0. Thus, for example, a reference to a device located at 0xfe000000 would result in a VERSABUS transfer with the address set to 0x3e000000. A complete list of the characteristics of the devices supported in the system may be found in Appendix A.
The console processor has a set of names for devices:
| FUJITSU 160M disk drives fsd |
| FUJITSU 330M disk drives fuj |
| FUJITSU 450M disk drives egl* |
| CDC 300M disk drives smd |
| CDC 340M disk drives xfd |
| CDC 515M disk drives xsd |
| Cipher tape drives cyp |
The console processor has the notion of a default device to use with file related commands. The default device is specified according to the form shown above. Further, the console processor, by default, interprets certain system files on the default disk to discover information about disk drives in the system. As X device names are decidedly different from the names used by the console processor this can lead to serious confusion. We will return to this problem later in \(sc4.2.1; for now you should simply be aware of the difference in naming conventions. UNIX device naming
UNIX has a set of names for devices which are different from the CCI names for the devices, viz.:
| VERSABUS disk drives dk |
| Cipher tape drives cy |
The standalone system, used to bootstrap the full UNIX system, uses device names: xx(y,z) where xx is either dk, or cy. The value y specifies the controller to use and also the device; it is computed as 8 * controller + device Thus controller 0 device 0 would have a y value of 0 while controller 1 device 0 would have a y value of 4. The z value is interpreted differently for tapes and disks: for disks it is a disk partition (in the range 0-7), and for tapes it is a file number on the tape.
Each UNIX physical disk is divided into 8 logical disk partitions, each of which may occupy any consecutive cylinder range on the physical device. The cylinders occupied by the 8 partitions for each drive type are specified initially in section 4 of the programmers manual and in the disk description file /etc/disktab (c.f. disktab(5)). The partition information and description of the drive geometry are written in the first sector of each disk with the disklabel\|(8) program. Each partition may be used for either a raw data area such as a paging area or to store a UNIX file system. It is conventional for the first partition on a disk to be used to store a root file system, from which UNIX may be bootstrapped. The second partition is traditionally used as a paging area, and the rest of the disk is divided into spaces for additional ``mounted file systems'' by use of one or more additional partitions.
The disk partitions have names in the standalone system of the form ``dk(y,z)'' with varying y as described above. Thus partition 1 of a Fujitsu Eagle on controller vd0 at drive 0 would be ``dk(0,1)''. When not running standalone, this partition would normally be available as ``/dev/dk0b''. Here the prefix ``/dev'' is the name of the directory where all ``special files'' normally live, the ``dk'' serves an obvious purpose, the ``0'' identifies this as a partition of dk drive number ``0'' and the ``b'' identifies this as the second partition.
In all simple cases, a drive with unit number 0 (in its unit plug on the front of the drive) will be called unit 0 in its UNIX file name. This is not, however, strictly necessary, since the system has a level of indirection in this naming. If there are multiple controllers, the disk unit numbers will normally be counted sequentially across controllers. This can be taken advantage of to make the system less dependent on the interconnect topology, and to make reconfiguration after hardware failure extremely easy. We will not discuss that now.
Returning to the discussion of the standalone system, we recall that tapes also took two integer parameters. In the normal case where the Cipher tape drive is unit 0 on the first controller, the files on the tape have names ``cy(0,0)'', ``cy(0,1)'', etc. Here ``file'' means a tape file containing a single data stream. The distribution tape(s) have data structures in the tape files and though the tape(s) contain only 9 tape files, they contain several thousand UNIX files. UNIX devices: block and raw
UNIX makes a distinction between ``block'' and ``raw'' (character) devices. Each disk has a block device interface where the system makes the device byte addressable and you can write a single byte in the middle of the disk. The system will read out the data from the disk sector, insert the byte you gave it and put the modified data back. The disks with the names ``/dev/xx0a'', etc are block devices. There are also raw devices available. These have names like ``/dev/rxx0a'', the ``r'' here standing for ``raw''. Raw devices bypass the buffer cache and use DMA directly to/from the program's I/O buffers; they are normally restricted to full-sector transfers. In the bootstrap procedures we will often suggest using the raw devices, because these tend to work faster. Raw devices are used when making new filesystems, when checking unmounted filesystems, or for copying quiescent filesystems. The block devices are used to mount file systems, or when operating on a mounted filesystem such as the root.
You should be aware that it is sometimes important whether to use the character device (for efficiency) or not (because it wouldn't work, e.g. to write a single byte in the middle of a sector). Don't change the instructions by using the wrong type of device indiscriminately.