/boot,/mdec,[T]MSCP Part 0 of 22 (README)
Steven M. Schultz
sms at wlv.imsd.contel.com
Sat May 18 15:55:26 AEST 1991
Hello fellow 2.11BSD'ers:
This is part 0 of 22 - the "README" file. There will follow
(probably not in order) 22 additional patch files for 2.11BSD
(NOT 2.10 or 2.10.1!!)
Collect all parts before commencing to patch the sources. It might
also be worth the time to read/scan the changes to get an idea
what is being done.
Some of the parts are almost trivial in size while others are quite
large. Thought was given to batching the smaller ones but in the
end it was decided to leave the patches as individual files.
Save this 'README'/note - it will not be repeated in subsequent
postings.
While numerous (and large), the changes should slip into a stock
2.11BSD system with very little trouble. The diffs which will
follow are based on the files present in the USENIX distribution.
When the time comes to install the new /boot program remember
to also install a new bootblock from /mdec on the drive(s) used
for booting. The new boot program relies on the information
passed to it from the bootblock (major device number, unit number
and controller csr).
NOTE: The new boot program relies on information passed
by the new bootblocks.
A brief summary before the detailed explanation of the what/why/etc:
(order not necessarily the same as the detailed description)
1) TMSCP and MSCP drivers have extensive mods for bug fixes,
space reduction and capabilities added.
2) the boot code (bootblocks and standalone programs) rewritten
to be able to load from any controller/unit.
3) fixes for Fuji160 discs
4) GENERIC kernel support for the RL02 on UNIBUS systems
5) the testing of the "switch register" is gone - the reasons are
described in the source file, it was mainly a space constraint.
6) the standalone utilities required some changes to fit in the 48kb
limit.
7) the "return" protocol of the standalone utilities was changed,
this allows slightly oversized programs to still 'return' to
'boot'.
8) there is now a SINGLE UNIVERSAL TAPEBOOT! this will be
described in more detail later, but suffice it to say that
ALL 4 tape types can be booted from a SINGLE 512 byte bootblock.
(and they said it couldn't be done... :-)
9) 'checksys' had yet another bug in estimating system size.
10) updated documentation for the 'setup' portion of the documents.
The following files/directories have undergone extensive modifications
to add the following capabilities:
1) the MSCP (ra.c) and TMSCP (tmscp.c) drivers now have their
command packet areas external to the kernel. This was done
because each TMSCP controller consumed 1900+ bytes of
kernel D space and each MSCP controller 1000+ bytes. Having
one of each controller put a severe constraint on the kernel
D space and having two of each was impossible in a reasonably
configured kernel (there simply wasn't 6kb of kernel D space
to spare).
The external region is allocated in machdep2.c at system startup
time (only if MSCP or TMSCP devices are configured in the
kernel) and contains space enough for 2 each MSCP and TMSCP
controllers.
For UNIBUS systems the external region is mapped ONCE in machdep2.c
with sufficient UMRs to cover the entire region. NO FURTHER
UMRs are allocated by ra.c or tmscp.c to map command packets.
If multiple controllers are present this conserves UMRs.
All I-O to/from the command packets is handled by computing a
virtual address relative to the first UMR mapping the external
region. For Q22 (Q-bus) systems the physical address within
the external region is calculated.
NOTE: This has been *extensively* tested on a Q-BUS system,
but i do not have access to a UNIBUS system with MSCP
peripherals. IT should work (the method used was
copied from the DEUNA driver which DOES work) -
but back up your system before trying this.
If it does work or you have problems let me know,
please.
The method used to allocate memory from the external region
is the same as m_ioget() in the networking code. No 'free'
capability is present, but that shouldn't be a problem - how
often does a controller go away while the system is running? ;-)
The command packet region is allocated at 'attach' time (when
called from iinit() for 'root' fs capable devices) or at autoconfig
time.
The TMSCP driver has been extensively modified to support multiple
controllers (the comment in the earlier version about multi-
controller support was erroneous) AS WELL AS multiple drives
per controller. The multiple controller capability has been
tested, the multiple unit capability has not (but it *should*
work ;-) been tested yet [offers of a SCSI interfaced tape
drive accepted;-)].
In addition, there were numerous bugs (notably in the Get
Unit Status handling) fixed in the TMSCP driver.
Bugs in the MSCP driver were also fixed, it is now possible
to remove and reinsert RX50s and not get an error.
Both the TMSCP and MSCP drivers underwent a bit of a diet and
are now noticeably smaller than before.
2) /sys/pdpstand, /sys/mdec
The STANDALONE programs and bootblocks were essentially rewritten.
It is now possible to load /boot from any controller/drive
combination! The bootblocks (/sys/mdec, /mdec) were rewritten
to use the R0 and R1 values passed by the boot roms as the
booting unit and controller csr respectively. Using those
values allows the bootblocks to load /boot from other than
drive 0 on controller 0. *extremely* useful in case /boot
or the bootblock on the system disc becomes corrupted or missing.
THERE IS NOW A UNIVERSAL TAPEBOOT block! There is no longer
a separate 'tmscp' bootblock file. ALL 4 (TM/HT/TS/TMSCP)
tape types are now supported in a single 512 byte (actually
i have 26 bytes free) boot block. If you like tight/lean/mean
pdp-11 assembly code then take a look at 'mtboot.s'! Some of
the retry/error handling had to be sacrificed to make things
fit. 'mtboot' now pays attention to the device it was booted
from by the roms! no more assuming that because a HT exists
that it must be the load device (a situation i encountered
where a HT and a TS were present on the system, the boot roms
would load mtboot but then mtboot would test for the presence
of HT first and fail).
NOTE: Remove 'tmscpboot.s' and 'tmscptape.data' from
/sys/pdpstand, they are no longer needed.
NOTE: all of the tape types have been tested. (thanks Terry
for the help!)
All of the standalone programs (boot, mkfs, restor, icheck) have
dual controller support added for all devices. This is extendable
to additional controllers on a per device basis if desired. The
first controller MUST be at the *standard* CSR address and is
always known as controller 0. The controller number is encoded
in bits 6 and 7 of the unit number, so to refer to controller
1 drive 0 the unit number 64 would be used.
Example: after booting the tape/disc you wish to load
a program from the second TMSCP controller unit
0
73boot: tms(64,3)
would load the 'restor' program from the second
controller.
IF you have booted from a secondary controller (most boot roms
do not support this) the CSR of that controller is placed in
the second CSR slot for the device booted from, thus it is
automatically controller #1 (the standard CSR is #0).
IF you have booted from the standard (#0) controller and attempt
to access higher numbered controllers the 'boot' program will
prompt you for the CSR. The number you enter MUST be OCTAL.
A MAXIMUM of 4 controllers of any type are permitted (only 2
bits to hold the controller number).
'boot' prints out the CSR of the controller booted from now.
The bootblocks now pass the major device number to 'boot'. 'boot'
in turn passes this information thru to each program loaded
including the kernel. 'boot' also passes thru to the unix kernel
the bootcsr and unit number. The kernel saves this information
(mch_start.s) but at present does little else with it except to
pass it on in the event of an [auto]reboot (conf/boot/*).
More on this later.
NOTE: Unix must still be booted from unit 0 controller 0.
It is possible to custom build a kernel which can boot from
alternate units but it is NOT possible to boot from alternate
controllers. This is a consequence of the way autoconfigure and
"root"/'swap' attachment/allocation is done. I doubt the project
of allowing the kernel to boot from alternate controllers/units
automatically will ever be completed due to the need to rewrite the
autoconfigure process. At present the ability to load 'boot' and
the standalone utilities from alternate controllers/units will have
to suffice.
The 'return' protocol used by the standalone programs (icheck,
restor, mkfs) has changed because 'icheck' was too large and
was overwriting the saved 'rtt' info needed to return to 'boot'.
'icheck' was later modified to be smaller, but the protocol
changes were retained so that slightly oversized programs (>48kb)
could be used if necessary (this will apply to 'restor' if any
changes result in his growing in size).
3) /sys/pdpuba/rl.c
In a GENERIC kernel the rl02 driver would crash on a UNIBUS
system due to trying to access a register used by QBUS systems.
The fix was to test in a nonfaulting manner for the register.
Normally a UNIBUS system would not have Q22 defined. The
rlreg.h file was updated to not conditionally define the
extra register.
4) Misc other changes.
'ubmap' is a short now instead of a 'char/bool' - even alignment
was required in the networking code. (/sys/h/uba.h)
the check in the network startup code for being on a UNIBUS
system (sys_net.c) was corrected, previously it didn't check
'ubmap' just in case UNIBUS_MAP was turned on for a QBUS system.
'mt' was using a default tape device which would rewind on
close. this was kinda silly since most operations using 'mt'
want to position the tape and leave it positioned - not
rewound! two minor (one line changes) to mt.c and mtio.h
were made (thanks Paul!).
'newfs' has a new entry for the 'extended RM02' drive type.
this is a Fuji160 (Emulex SC01 or SC03 controller) doing
a pseudo RM80 emulation (or double sized RM02, whichever
you prefer). /etc/disktab was updated with the additional
new name for this drive/controller configuration and
/sys/pdpuba/xp.c modified to reflect new partitions for this
(RM2X) drive type.
NOTE: the Fuji160/rm2x partitions have changed because
there was not enough room on the 'd' partition
to hold the 2.11BSD distribution. IF you are
using this drive/controller combination a dump
and reload (i'm sorry) is necessary if you're
presently using the 'd' partition. If the 'c'
partition is being used as /usr then there is no
problem.
/usr/src/etc/icheck.c was modified to fit as a standalone
program. The modification was a simple #ifdef STANDALONE
to reduce the number of inodes read in at a time.
/usr/src/etc/restor.c was modified for standalone space
constraint reasons. many more register variables were
added to reduce the size of the code, some error messages
were reduced in verbosity and so on. Just space saving
measures were taken (i.e verbosity reduction without loss
of meaning).
a minor typo in config.c (a NOP of a program) was fixed.
4.3+ style kernel configuration is still a pipedream, so
why not update the version of the system which doesn't
support 'config' ;-)
#0 This file (README)
#1 /usr/src/sys/GENERIC/Makefile
#2 /usr/src/sys/conf/boot
#3 /usr/src/sys/h/uba.h
#4 /usr/src/sys/mdec
#5 /usr/src/sys/pdp/machdep2.c
#6 /usr/src/sys/pdp/mch_start.s
#7 /usr/src/sys/pdpstand
#8 /usr/src/sys/pdpuba/ra.c
#9 /usr/src/sys/pdpuba/rl.c
#10 /usr/src/sys/pdpuba/rlreg.h
#11 /usr/src/sys/pdpuba/tmscp.c
#12 /usr/src/sys/pdpuba/xp.c
#13 /usr/src/sys/sys/sys_net.c
#14 /usr/src/sys/conf/checksys.c
#15 /usr/doc/2.10/setup.2.11/2.t
#16 /etc/disktab
#17 /usr/src/sys/h/mtio.h
#18 /usr/src/bin/mt.c
#19 /usr/src/etc/restor/restor.c
#20 /usr/src/etc/icheck.c
#21 /usr/src/etc/newfs.c
#22 /usr/src/etc/config/config.c
More information about the Comp.bugs.2bsd
mailing list