If you follow the instructions in the OS9 manual for formatting
a new SCSI disk, you will FAIL! The following is an example of
successfully formatting a new SCSI disk for OS9 running on an MVME 167
board. Formatting on other hardware systems may be slightly
different.
I assume you have the following configuration:
SCSI Id 0 Main OS9 bootable system disk, called "/h0"
SCSI Id 1 New disk to be formatted, to be called "/h1"
Boot the OS9 system from the main disk and:
chd /h0/cmds/bootobjs
In this area are a number of device descriptors. The existing /h0
disk must have at least one device descriptor file, usually with
the name "h0". For more recent versions of OS9, you might have
a file named "h0.vccs" for the SCSI device. I will assume the
extant descriptor is "h0" from now on. The actual device descriptor
module file for /h0 is a good reference in case you get stuck.
For the new disk, the best procedure is to have two separate
descriptor files:
/h0/cmds/bootobjs/h1fmt For use only during formatting
/h0/cmds/bootobjs/h1 For general use after formatting
The primary difference between the two files is that one bit
in the h1fmt descriptor allows the device to be formatted. To
prevent accidental formatting, it is best to use the descriptor
h1fmt when formatting the disk and ONLY when formatting the disk.
The descriptor h1fmt should therefore only be loaded by hand.
Loading the file descriptor h1 may be included in the startup procedure,
after initialization is complete.
If the files h1fmt and h1 do not exist, you can copy existing versions
of the files h0fmt and h0, or their equivalent. The existence of the
h1fmt and h1 files on the OS9 distribution is somewhat unpredictable, so
chances are good you will have to:
chd /h0/cmds/bootobjs
copy h0fmt h1fmt
copy h0 h1
Then you MUST change the settings in the descriptor files. The "moded"
utitility is used to edit the files and "fixmod" is used to fix
the header after changes. To invoke moded and edit the descriptor
parameters to change the name of the device, type:
moded -f=h1fmt
moded: e
name of module to use (return if same as file name) : h0fmt
descriptor name : h0fmt = h1fmt
...etc.
The program will guide you through all the possible parameters and
prompt for changes. Press [return] for no change. At the "moded:"
prompt you can also type "l" for a listing or "?" for help. The
fields are described in the file:
/h0/sys/moded.fields
...buried under the "RBF" heading. Beware: The description of the
some fields is often wrong or misleading! When you have completed
changing the parameters, you must write the file and quit
the program at the "moded:" prompt:
moded: w
moded: q
Various settings will probably have to be changed in both the
h1fmt and h1 files. Below is listing of parameters that
actually worked in my system with the aforementioned configuration:
descriptor name : h1fmt h1
file manager name : RBF RBF
device driver name : rbvccs rbvccs
port address : $fffe4001 $fffe4001
irq vector : 69 69
irq level : 4 4
irq priority : 5 5
device mode capabilities : $e7 $a7
device class : $01 $01
drive number : 0 0
* step rate : 0 0
device type : $80 $80
* density : $00 $00
reserved : $00 $00
* number of cylinders : 0 0
* number of heads/sides : 0 0
disk write verification : 1 1
* default sectors/track : 0 0
* default sectors/track 0 : 0 0
segment allocation size : 32 32
sector interleave factor : 1 1
* dma transfer mode : 0 0
* track base offset : 0 0
* sector base offset : 0 0
* sector size : 0 0
control word : $000a $000b
number of tries (1=no retry) : 1 7
scsi unit number of drive : 0 0
* write precompensation cylinder : 0 0
* reduced write current cylinder : 0 0
* cylinder to park disk head : 0 0
* logical sector offset : 0 0
* total cylinders on device : 0 0
scsi controller id : $01 $01
* data-transfer/rotation rate : $00 $00
scsi options flags : $00000004 $00000004
maximum transfer count : $00ffffff $00ffffff
Items marked "*" are determined by the format command automatically
and should be set to 0. SCSI devices have an inquiry feature
which returns the various disk parameters needed by format.
The other parameters are explained below: (with modifed excerpts
from the /h0/sys/moded.fields file)
descriptor name : h1fmt h1
"Descriptor name" will be the name of the device as it appears
to the system and in the "devs" command. Note that this is usually,
but not necessarily, the same as the filename. The formattable
(h1fmt) and non-formattable (h1) names should be different to avoid
accidental formatting. There is no required relation between
the device name and the SCSI Id setting, but by convention
the digit "1" in "h1fmt" and "h1" indicates SCSI Id 1, etc.
file manager name : RBF RBF
For disk devices, this is fixed to be "RBF"
device driver name : rbvccs rbvccs
For SCSI hard disks, "rbvccs" is the device driver
port address : $fffe4001 $fffe4001
This is the absolute physical address of one of the
SCSI hardware controller's internal registers that will
be used by this device. Should be unique for
each SCSI hard drive. The starting register is located
at $fffe4000 for the MVME 147 and MVME 167 boards.
By convention, you should take the starting register
number (here $fffe4000) and add the SCSI Id number to
obtain a unique byte register address.
irq vector : 69 69
irq level : 4 4
irq priority : 5 5
The irq parameters refer to the interrupts of the SCSI controller
on the CPU board. This is highly hardware dependent, and
MVME167 and MVME147 have incompatible settings. However,
these values do not change from one disk to another on the
same system, so you can copy the values from the old disk's
descriptor. The values above are for the MVME 147 board.
The irq level and priority are programmable for the SCSI
bus as a whole, but these values must match the values loaded
into the SCSI controller and all SCSI device descriptor files.
The irq vector lower 4 bits are not programmable and are defined
by the PCC interface. The irq vector upper 4 bits are programmable
for the PCC interface as a whole, but beware that PCC interfaces
to serial i/o ports, ethernet and many other i/o devices with
interrupts. The irq vector should not usually be changed.
device mode capabilities : $e7 $a7
The value is an eight bit mask which enable or
disable the following device capabilities:
* <0> -- read (Read_)
* <1> -- write (Write_)
* <2> -- execute (Exec_)
<3> -- reserved
<4> -- reserved
* <5> -- creates with initial file size are supported (ISize_)
<6> -- single-user (non-sharable) (IShare_)
* <7> -- directory (Dir_)
For both /h1 and /h1fmt, you will want the bits marked with "*"
to be set to one in the mask. For /h1fmt, you should also set the
bit <6> to one in order to prevent other users from using the /h1fmt
disk during initialization.
device class : $01 $01
For "RBF" (disk) devices, this is $01
drive number : 0 0
This should be 0. Don't believe the documentation.
device type : $80 $80
Bit mask describing the type of disk:
bit <7> = 1 indicates hard disk
<6> = 1 removable hard disk
= 0 fixed hard disk
<5:0> -- reserved
reserved : $00 $00
Reserved, should be $00
disk write verification : 1 1
Optional bit indicating whether to do write verifies.
Not necessary, but probably a good idea.
segment allocation size : 32 32
sector interleave factor : 1 1
Generally 32 and 1 (respectively) for SCSI hard disks
control word : $000a $000b
Very important parameter! This specifies whether the device
can be formatted, and should be different in h1 and h1fmt. This
bit mask means:
bit <0> = 0 disk is format ENABLED -- 0 for /h1fmt
= 1 disk is format PROTECTED -- 1 for /h1
<1> = 0 driver/controller can perform single-sector i/o.
= 1 * driver/controller can perform multi-sector i/o.
<2> = 0 * device does not have stable id.
= 1 device has stable id.
<3> = 0 device size determined from device descriptor.
= 1 * device size determined by asking the drive itself.
<4> = 0 * device cannot format a single track
= 1 device can format a single track
Bit <0> should be zero for h1fmt so that a format can be performed.
However, after the format is complete, h1 should be loaded instead
with bit <0> set to one to prevent accidental formatting.
Bit <3> should be set to one since these are SCSI disks that can
provide their own hardware parameters. (for both h1 and h1fmt)
Setting this bit makes the controller disregard the hardware
parameters in the descriptor file.
The bit values marked with "*" indicate constant values for
both h1 and h1fmt
number of tries (1=no retry) : 1 7
This gives the number of tries before the controller will
report errors. Should be 1 for h1fmt so that the controller will not
attempt to correct errors during format operations.
scsi unit number of drive : 0 0
This is NOT the SCSI unit number of the drive! Should
always be set to 0 !!!!
scsi controller id : $01 $01
This is NOT the SCSI controller id!!!
This IS the SCSI UNIT NUMBER of the new drive! In our case,
the SCSI Id is 1, but we could have set the physical drive
to be on SCSI Id 2 through 6.
scsi options flags : $00000004 $00000004
These flags are dependent on what optional SCSI features your disk
hardware has implemented. The mask means:
<0> = 1 controller supports "assert ATN"
<1> = 1 target mode supported
<2> = 1 synchronous transfers supported
<3> = 1 enable SCSI parity
You should set bits corresponding to the capabilities of your
particular drive.
maximum transfer count : $00ffffff $00ffffff
PD_MaxCnt: This field contains the maximum byte-count that the
driver can transfer in one call.
When you are finished running "moded" on h1 and h1fmt, you should:
chd /h0/cmds/bootobjs
fixmod h1
fixmod h1fmt
The h1fmt can now be loaded into the system's memory as such:
load -d h1fmt
iniz h1fmt
Now the "devs" command should list the h1fmt device. Also, you
can query the device itself to findout if it is alive and see more
information:
inquiry /h1fmt
If this command fails, something is wrong in the device descriptor
or with the hardware itself. In this case, you need to do more work
before formatting.
If inquiry returns a reasonable response, the disk is now ready to
be formatted with the command:
format -v=label h1fmt
Where "label" is an arbitrary volume label -- a text string of your
choosing. The format command will prompt whether you want a
"physical format". Depending on the previous state of the disk, this may
not be necessary. If you have problems subsequently, consider running
the physical format option. Note that the physical format option is
quite time consuming, depending on the size of the disk, so be patient.
The format command will also prompt for "physical verify". After this,
format will put the OS9 logical structure on the disk and the format
will be complete.
If the format was successful, you can reboot the system to clear
the h1fmt device from the OS9. You can now mount the format
protected h1 device as such:
chd /h0/cmds/bootobjs
load -d h1
iniz h1
...and the device "/h1" will show up ready for work, and protected
from formatting. However, if you want the new disk to be OS9 bootable,
then the device must be format enabled, so do this instead:
load -d h1fmt
iniz h1fmt
The /h1fmt device will now be ready as a normal disk, and can have the
os9gen boot-writing utility run on it. But for subsequent
loads, be sure to use the h1 device!
A useful command available in some recent releases of OS9 is
the "dmode" utility. To view the device descriptor settings
of an installed device:
dmode /h0
Each of the fields displayed correspond to fields in the
device descriptor file. For more information on the fields,
type:
dmode -?
The command also allows you to change the device settings
on the fly, without reloading the device driver, etc. For
example:
dmode /h1 cntrl=$000E
will change the control word values. When the system
is rebooted, the original settings will be restored.
Alas, on older versions of OS9, you won't find "dmode".
Another useful utility is "ident" which should be available
to all OS9 versions. This utility will verify and display all
modules in a given file. If the file looks OK to ident,
you probably won't have to run the "fixmod" on edited
decriptor files! For example, type:
ident /h0/cmds/bootobjs/h0
to see the h0 descriptor. Note that there could
be many modules in a given file, unlike in the
previous examples.
W. Badgett (badgett@hep.physics.wisc.edu)