NetBSD/sys/arch/alpha/README

$NetBSD: README,v 1.7 1995/11/23 02:33:17 cgd Exp $

Obtaining NetBSD/Alpha sources and binaries:

	NetBSD/Alpha sources and binaries are available from:
		ftp://ftp.netbsd.org/pub/NetBSD/arch/alpha
	See the README.files file there to figure out which of
	the following items corresponds to what file(s) in the FTP
	archive.

	There are two sets of system binaries available:
		(1) an rz25 disk image, for first-time installation
		    (see below), and
		(2) two tar files of the binaries, for updates.
		    (one of the tar files is the contents of /etc,
		    one is everything else, except a kernel.
		    There are no instructions on how to use these.
		    Good luck!  8-)

	There are also two precompiled kernels available: one generic
	kernel which will prompt for a root device, and one which tries
	to boot diskless.  The generic kernel is included in the rz25
	disk image.

	X11 client binaries are packaged seperately.  (There is no
	server at this time.)

	There are several sets of sources available:
		(1) kernel source snapshot (complete kernel sources),
		(2) compiler toolchain source snapshot (complete
		    toolchain sources),
		(3) diffs to the NetBSD-current sources as of the date
		    of the release to make them match what's used on
		    the alpha port.  (You should be able to get the
		    NetBSD-current sources, replace the kernel sources
		    with the ones i'm distributing, add in these
		    diffs and the toolchain sources, and compile up a
		    complete system.)
		(4) diffs to the XFree86 3.1.2 sources to make them
		    work with NetBSD/Alpha.  (If you add these to
		    the XFree86 3.1.2 sources, you should be able to
		    compile up the X clients.)
	
	If you are interested in the NetBSD/Alpha port, I suggest that you
	subscribe to the NetBSD "port-alpha" mailing list by sending an
	email message to majordomo@netbsd.org with no subject and with a
	body of "subscribe port-alpha" (without the quotes).  For help on
	using majordomo, send it mail with an empty subject and body.

Installing the NetBSD/Alpha distribution:

	[ Note that these instructions are minimal; it's assumed that if
	  you're going to be installing this, you're knowledgeable about
	  booting Alphas and doing other sysadmin-ish stuff, are willing
	  to look in your Alpha documentation, or are brave.  If they're
	  really not good enough to get you running, get in touch with me
	  and I'll try to help you. ]

	To install the NetBSD/Alpha distribution, you'll need a disk at
	least the size of an RZ25 -- about 406Mb.  Once you've gotten the
	binary distribution from me, gunzip it and dd it to the raw disk.
	The binary distribution includes a disklabel and boot block, so you
	don't need to do anything special to make it bootable.  I created
	the binary distribution's file systems with an older version (4.3
	Reno) of the Berkeley Fast File System format, so that you can
	mount, read, and write them under OSF/1.

	Once you've dd'd the image to the disk, set your system to use a
	serial console.  Boot the Alpha with the NetBSD disk, supplying the
	boot flag "-s".  It should print something about "NetBSD/Alpha Boot
	program", load the kernel, print a copyright, and print various
	startup messages.  Included among those startup messages will be
	SCSI bus/id to device name mappings for all of the SCSI devices
	that NetBSD recognizes.  Eventually, it'll ask you for the name of
	the root device.  It expects something like "sd0", "sd1", etc., and
	you should pick the name that corresponds to the NetBSD disk.

	After a short while, you should be asked for the name of a shell
	to use; just hit return.  You're advised to fsck the disk at this
	point (the root partition is partition 'a' and the /usr partition
	is partition 'd'), remount the root partition read-write (use mount
	-u root-dev /), and create some necessary system information files:
		/etc/hosts
		/etc/resolv.conf (if you want to use DNS)
		/etc/myname (the hostname of the machine)
		/etc/mygate (the LAN's gateway's IP address, if your network
			setup requires that it be named explicitly)
		/etc/hostname.le0 (on TurboChannel machines, to describe
			the enet addr, etc., for the Alpha's ethernet.  The
			format can be discerned by looking in /etc/netstart.
			As an example, for my development machine, it's:
			inet macallan.dssc.cs.cmu.edu 0xffff0000 128.2.255.255
			     ^^^^^^^^^^^^^^^hostname  ^^^netmask ^^^broadcast)
		/etc/hostname.de0 (on PCI machines; same format as
			hostname.le0 would have.)
		/etc/fstab (a prototype is in /etc/fstab.sd)
	(You can also create the files mentioned above by mounting the
	disk's file systems under OSF/1 and filling in the appropriate
	information.)

	Once those files are created, you should be able to boot the system
	multi-user.  To do so, halt the system and boot again from the
	NetBSD disk, this time supplying the boot flags "-a".

	Once the system has booted, you should be able to log in over the
	network.  (Log in as root, at first, then use vipw to create user
	account(s) and re-log in as the appropriate user.)  If you used a
	disk other than an RZ25, you may also want to edit the disk's
	disklabel, and create one or more partitions to use the extra space.

Using NetBSD/Alpha:
	You'll probably want to NFS mount the sources from another machine;
	that's what I do, and it works just fine.  If you'd like tips on
	good ways to keep the NetBSD sources under source control, just ask.

	A fair number of binaries don't work properly.  For example, GDB
	won't properly run programs or debug core files; someone needs
	to write support for NetBSD/Alpha.

	As noted above, the SCSI code on TurboChannel machines is reliable
	only when being used with one SCSI bus at a time; this is obviously
	a bug.  Additionally, the SCSI driver seems unhappy about dealing
	with certain types of disk drives (e.g. the IBM Lightning).

	Because I've been working on getting the system up and running, then
	out the door, I've not had much time to do performance analysis on
	the kernel, nor tried to improve performance in any way.  Some of
	the code is awfully rough.  That being said, on a lot of operations
	I'm seeing performance comparable to that of OSF/1 on the same
	hardware, so I've not gone too far wrong anywhere.



Chris Demetriou
cgd@cs.cmu.edu