6 Jul
2001
6 Jul
'01
5:18 a.m.
I got the driver to come up on a second controller in E11.
Evidently the PRO350 RA driver would only work as a root drive,
which is attached via some other mechanism that I am not
familiar with. What I did to get it to autoconfig was create an
"raprobe" routine that simply returned the status code that says
"it's OK and you don't need to look for an interrupt". Crude,
but the target machine won't work without the controller
present.
Now I need to work on the boot sector. The problem is that
rauboot.s in the distribution is corrupt, in both the tree and
the tar version. See file
http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.9-pro350/
mdec/rauboot.s, the line that begins "NDIRIN = 4." ends in
garbage, and there is a chunk of code missing.
One of the doc files, I think boot.doc, has the same problem. It
seems that the disk from which the 2.9BSD-PRO patch distribution
was prepared was slightly scrambled. There is a chunk of C code
right in the middle of the doc in place of some important info.
I've been able to reconstruct most of rauboot.s by comparing
with other boot programs, except I need the snippet of code for
initializing the MSCP controller. I can probably figure this out
2.9
I
don't know about 2.9 but I do know just a little bit about 2.11
files -
from the 2.11 driver, but I'd much rather not have
to. The 2.11
driver is very different.
Does anyone know where I can get the original file?
--
Jonathan Engdahl Rockwell Automation
Principal Research Engineer 24800 Tungsten Road
Advanced Technology Euclid, OH 44117 USA
Euclid Labs http://users.safeaccess.com/engdahl
----- Original Message -----
From: "Steven M. Schultz" <sms(a)TO.GD-ES.COM>
To: <classiccmp>; <engdahl>; <pups>
Sent: Saturday, June 30, 2001 12:10 AM
Subject: Re: [pups] adding MSCP driver to 2.9BSD
Hi --
I'd normally be posting from my '2bsd.com' account but the
circuit
failed today and the telco is due out tomorrow
(Saturday)
morning.
From: "Jonathan Engdahl"
<engdahl(a)cle.ab.com>
I took the MSCP disk driver (the ra driver) from the PRO-350
version of 2.9BSD on the PUPS archive, and added it to the
Ah, I didn't know that someone had created a MSCP driver for
> I have figured out that the autoconfig will not work with
this
> driver. It reports "No autoconfig
routines". Evidently,
probe is
> not implemented in either the 2.9 or 2.11 version
of the
MSCP driver.
and the MSCP (and TMSCP) drivers 'probe' and
"autoconfig" just
fine.
In fact in 2.11 floating vectors are allocated descending from
01000
and programmed into the adaptor for secondary
controllers (the
primary/first/boot controller always gets 0154).
'autoconfig'
So, how to I get UNIX to "attach" the
ra driver?
When you updated the kernel did you also update the process? In 2.11 there is /sys/autoconfig and
whenever a new
device driver is added to the kernel it is also necessary to
update the autoconfig code with a 'XXauto.c" file and an entry
in a couple tables.
As I recall on 2.9 the autoconf stuff was intermingled with
the
regular driver sources which made for a bit of a mess.
When
2.11
came around the chance was taken to clean things up.
Programmable vector devices (such as MSCP) are a VERY awkward
thing
for 'autoconfig' to deal with. Prior to 2.11
the vectors
were
more or less hardcoded in 'l.s' (or was it
scb.s or locore.s -
gads
my memory is slipping) and the driver.
'autoconfig' was
mostly a
double check that a device was really present. 2.11
has the
kernel
hooks for 'autoconfig' to request a
dynamically allocated
vector
which can be assigned to a device - bit of a hack but
fairly
elegantly done.
> This is the first time I've tried doing a UNIX sysgen, so
extra
> explanations might be required. The only
documentation I
have is
what I
downloaded along with the distribution.
Look in /sys/pdpuba and see if you can find the '*auto.c' follow their lead and craft something for
'autoconfig'. The
simplest case is to just "check that something exists" at the
CSR and return 'true' - don't try to force an interrupt, etc.
Perhaps some other folks who have run 2.9 more recently (or
who
have better memory than I do ;)) can jump in here.
Steven Schultz
sms(a)moe.2bsd.com (when the circuit gets fixed ;))