2002-06-30 04:46:48 +04:00
|
|
|
.\" $NetBSD: prep,v 1.13 2002/06/30 00:46:49 lukem Exp $
|
1999-01-13 10:30:01 +03:00
|
|
|
.
|
2000-10-29 17:08:04 +03:00
|
|
|
\*M machines usually need little or no preparation before installing
|
|
|
|
.Nx ,
|
1999-01-13 10:30:01 +03:00
|
|
|
other than the usual, well advised precaution of
|
|
|
|
.Em backing up all data
|
|
|
|
on any attached storage devices.
|
|
|
|
.Pp
|
2000-11-01 13:58:29 +03:00
|
|
|
The exception to the above is that
|
2000-11-21 15:38:59 +03:00
|
|
|
.Tn MVME162
|
|
|
|
,
|
2000-11-01 13:58:29 +03:00
|
|
|
.Tn MVME167
|
2000-11-21 15:38:59 +03:00
|
|
|
,
|
|
|
|
.Tn MVME172
|
|
|
|
and
|
|
|
|
.Tn MVME177
|
|
|
|
boards require a jumper to be removed or DIP switch changed before
|
2000-11-01 13:58:29 +03:00
|
|
|
.Nx
|
|
|
|
can be installed.
|
|
|
|
On
|
|
|
|
.Tn MVME162-LX
|
2000-11-21 15:38:59 +03:00
|
|
|
and
|
|
|
|
.Tn MVME172-LX
|
2000-11-01 13:58:29 +03:00
|
|
|
pins 1-2 of jumper J11
|
|
|
|
.Em must
|
|
|
|
be removed.
|
|
|
|
On
|
2000-11-21 15:38:59 +03:00
|
|
|
.Tn MVME162-P2/P4
|
|
|
|
and
|
|
|
|
.Tn MVME172-P2/P4
|
|
|
|
switch S4, position 8
|
|
|
|
.Em must
|
|
|
|
be set to OFF.
|
|
|
|
On
|
2000-11-01 13:58:29 +03:00
|
|
|
.Tn MVME167
|
2000-11-21 15:38:59 +03:00
|
|
|
and
|
|
|
|
.Tn MVME177
|
2000-11-01 13:58:29 +03:00
|
|
|
pins 1-2 of jumper J1
|
|
|
|
.Em must
|
|
|
|
be removed.
|
|
|
|
.Pp
|
|
|
|
Once you've made any necessary jumper changes,
|
|
|
|
the following instructions should make your machine
|
2000-10-29 17:08:04 +03:00
|
|
|
.Dq NetBSD Ready .
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
2002-06-30 04:46:48 +04:00
|
|
|
Power-up your MVME147 board.
|
|
|
|
You should have the
|
1999-01-13 10:30:01 +03:00
|
|
|
.Em bug No prompt:
|
2000-10-05 12:54:55 +04:00
|
|
|
.(disp
|
1999-01-13 10:30:01 +03:00
|
|
|
COLD Start
|
1997-12-18 22:20:10 +03:00
|
|
|
|
1999-01-13 10:30:01 +03:00
|
|
|
Onboard RAM start = $00000000, stop = $007FFFFF
|
1997-12-18 22:20:10 +03:00
|
|
|
|
1999-01-13 10:30:01 +03:00
|
|
|
147-Bug\*>
|
2000-10-05 12:54:55 +04:00
|
|
|
.disp)
|
2000-10-10 16:55:15 +04:00
|
|
|
.Pp
|
2000-11-21 15:38:59 +03:00
|
|
|
Or, if you have an MVME162/172 or MVME167/177 board (the following boot
|
|
|
|
message is from MVME167; the others are similar):
|
2000-10-05 12:54:55 +04:00
|
|
|
.(disp
|
1999-02-20 19:18:10 +03:00
|
|
|
MVME167 Debugger/Diagnostics Release Version 2.3 - 02/25/94
|
|
|
|
COLD Start
|
|
|
|
|
|
|
|
Local Memory Found =02000000 (&33554432)
|
|
|
|
|
|
|
|
MPU Clock Speed =33Mhz
|
|
|
|
|
|
|
|
167-Bug\*>
|
2000-10-05 12:54:55 +04:00
|
|
|
.disp)
|
2000-10-10 16:55:15 +04:00
|
|
|
.Pp
|
2002-04-06 01:12:21 +04:00
|
|
|
Make sure the RAM size looks ok (if you've got an 8 MB
|
|
|
|
.Tn MVME147
|
|
|
|
or a 32 MB
|
|
|
|
.Tn MVME167
|
|
|
|
you should have the same value as we do).
|
|
|
|
Also make sure the clock is ticking:
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
2000-11-01 13:58:29 +03:00
|
|
|
.Dl 1xx-Bug\*> Ns Ic time
|
1999-04-10 20:16:11 +04:00
|
|
|
.Dl Sunday 12/21/31 16:25:14
|
2000-11-01 13:58:29 +03:00
|
|
|
.Dl 1xx-Bug\*> Ns Ic time
|
1999-04-10 20:16:11 +04:00
|
|
|
.Dl Sunday 12/21/31 16:25:15
|
2000-11-01 13:58:29 +03:00
|
|
|
.Dl 1xx-Bug\*>
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
|
|
|
Note that
|
|
|
|
.Nx
|
|
|
|
bases its year at 1968, and adds the year offset in
|
2002-06-30 04:46:48 +04:00
|
|
|
the system's real-time clock to get the current year.
|
|
|
|
So the
|
2000-10-29 17:08:04 +03:00
|
|
|
.Li 31
|
|
|
|
here
|
2002-06-30 04:46:48 +04:00
|
|
|
equates to 1999.
|
|
|
|
You may have to adjust your clock using the
|
2000-10-29 17:08:04 +03:00
|
|
|
.Ic set
|
1999-01-13 10:30:01 +03:00
|
|
|
command to comply with
|
|
|
|
.Nx "" 's
|
2002-06-30 04:46:48 +04:00
|
|
|
requirements.
|
|
|
|
Don't worry if the
|
2000-10-29 17:08:04 +03:00
|
|
|
.Sq Day of the week
|
|
|
|
is not correct, as
|
1999-01-13 10:30:01 +03:00
|
|
|
.Nx
|
|
|
|
doesn't use it.
|
1999-02-20 19:18:10 +03:00
|
|
|
Motorola has acknowledged a year 2000 bug in some versions of the MVME147
|
|
|
|
whereby the day of the week
|
1999-01-13 10:30:01 +03:00
|
|
|
doesn't get set correctly by the 147Bug PROM.
|
2000-11-21 15:38:59 +03:00
|
|
|
.Em It does not affect
|
1999-01-13 10:30:01 +03:00
|
|
|
.Nx "" !
|
|
|
|
.Pp
|
1999-02-20 19:18:10 +03:00
|
|
|
Also make sure that your board's ethernet address is initialised to
|
2002-06-30 04:46:48 +04:00
|
|
|
the correct value.
|
|
|
|
You'll find the address on a label on the inside of
|
2000-11-21 15:38:59 +03:00
|
|
|
the MVME147's front panel, and on the VMEbus P2 connector of the other
|
|
|
|
board types.
|
2002-04-06 01:12:21 +04:00
|
|
|
On the
|
|
|
|
.Tn MVME147 ,
|
|
|
|
enter the last five digits of the address
|
2000-10-29 17:08:04 +03:00
|
|
|
using the
|
|
|
|
.Ic lsad
|
2002-06-30 04:46:48 +04:00
|
|
|
command.
|
|
|
|
On the MVME162/172 and MVME167/177, you should use the
|
2000-10-29 17:08:04 +03:00
|
|
|
.Ic cnfg
|
|
|
|
command.
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
2002-04-06 01:12:21 +04:00
|
|
|
The
|
|
|
|
.Nx
|
|
|
|
kernel reads the first two long words of the onboard NVRAM to
|
|
|
|
determine the starting and ending address of any VMEbus RAM that should be
|
|
|
|
used by the system.
|
|
|
|
You should verify that this area is set properly for your configuration.
|
|
|
|
.Pp
|
|
|
|
If you have no VMEbus RAM boards, the values should be set to zero (0).
|
|
|
|
.Pp
|
|
|
|
For an
|
|
|
|
.Tn MVME162 ,
|
|
|
|
.Tn MVME167 ,
|
|
|
|
.Tn MVME172
|
|
|
|
or
|
|
|
|
.Tn MVME177
|
|
|
|
board, at the 1xx-Bug\*> prompt:
|
|
|
|
.Pp
|
|
|
|
.Dl 1xx-Bug\*> Ns Ic mm fffc0000 ;l
|
|
|
|
.Dl fffc0000: xxxxxxxx? Ns Ic 0
|
|
|
|
.Dl fffc0004: xxxxxxxx? Ns Ic 0
|
|
|
|
.Dl fffc0008: xxxxxxxx? Ns Ic .
|
|
|
|
.Dl 1xx-Bug\*>
|
|
|
|
.Pp
|
|
|
|
For an
|
|
|
|
.Tn MVME147
|
|
|
|
board, at the 147Bug prompt:
|
|
|
|
.Pp
|
|
|
|
.Dl 147Bug\*> Ns Ic mm fffe0764 ;l
|
|
|
|
.Dl fffe0764: xxxxxxxx? Ns Ic 0
|
|
|
|
.Dl fffe0768: xxxxxxxx? Ns Ic 0
|
|
|
|
.Dl fffe076c: xxxxxxxx? Ns Ic .
|
|
|
|
.Pp
|
|
|
|
If you do have VMEbus RAM available and want
|
|
|
|
.Nx
|
|
|
|
to use it, the first
|
|
|
|
long word should be set to the starting address of this RAM and the
|
|
|
|
second long word should be set to the ending address.
|
|
|
|
.Pp
|
|
|
|
If you have more than one VMEbus RAM board installed, the starting and
|
|
|
|
ending addresses must be contiguous from one board to the next.
|
|
|
|
Also note that, for various reasons beyond the scope of this document,
|
|
|
|
VMEbus RAM should be configured in A32 address space.
|
|
|
|
.Pp
|
1997-12-18 22:20:10 +03:00
|
|
|
To install successfully to a local SCSI disk, you need to ensure that
|
2002-06-30 04:46:48 +04:00
|
|
|
the system is aware of what targets are connected to the SCSI bus.
|
|
|
|
This can be done by issuing the following command:
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
2000-11-01 13:58:29 +03:00
|
|
|
.Dl 1xx-Bug\*> Ic iot;t
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
2002-06-30 04:46:48 +04:00
|
|
|
At this point, Bug will scan for any attached SCSI devices.
|
|
|
|
After a short delay, a list of SCSI devices will be displayed.
|
|
|
|
147Bug will ask if LUNs should be assigned from SCSI ids, to which you should
|
|
|
|
answer Y.
|
|
|
|
You should also answer Y when asked if the information is
|
|
|
|
to be saved to NVRAM.
|
|
|
|
16xBug does not prompt for this information.
|
1999-01-13 10:30:01 +03:00
|
|
|
.Pp
|
1997-12-18 22:20:10 +03:00
|
|
|
The following installation instructions will assume that your target
|
2002-06-30 04:46:48 +04:00
|
|
|
SCSI disk drive appears at SCSI-ID 0.
|
|
|
|
If you have a tape drive, the instructions assume is is configured
|
|
|
|
for SCSI-ID 5.
|
|
|
|
When the RAMDISK root boots,
|
1999-01-13 10:30:01 +03:00
|
|
|
.Nx
|
2000-10-29 17:08:04 +03:00
|
|
|
will refer to these devices as
|
|
|
|
.Li sd0
|
|
|
|
and
|
|
|
|
.Li rst0
|
2002-06-30 04:46:48 +04:00
|
|
|
respectively.
|
|
|
|
You may wish to note these down; you'll be using them a lot. :-)
|