136 lines
6.2 KiB
Plaintext
136 lines
6.2 KiB
Plaintext
$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
|