1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
$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
|
