2.11BSD boot looping
Steven M. Schultz
sms at moe.2bsd.com
Tue Nov 30 08:07:48 AEST 1999
> From: James Lothian <simul8 at simul8.demon.co.uk>
> For what it's worth, this does sound suspiciously like what the 4.3
> boot code did with the Viking. As far as I can remember, there is a
> flag in one of the UDA50 registers that is set to 1 one the device
> interrupts. The 4.3 boot code runs the UDA50 with interrupts disabled,
Actually it's in the response packet rather than a UDA 'register' but
yep - that sounds very familiar.
> but polls this flag to find out when the controller has finished a
> On the UDA50, even if interrupts are disabled, this flag gets set. On
> the viking, it doesn't. I can't remember the exact change I made, but I
At least one of the changes was to give the MSCP adaptor a vector
during the 3 or 4 step init process. Normally 4.3/2.11 didn't bother
to give a vector since interrupts were disabled. It doesn't
reall matter what the vector is as long as it's non zero - the
value used was 0154 (primary/1st MSCP adaptor).
Some other 3rd party adaptors (can't recall if it was Dilog or
Emulex or ...) had the same problem.
> "Daniel A. Seagraves" wrote:
> > It's looping around at 157702.
> > 157702 contains 001776
Hmmm, I wonder if that's in the bootblock code or the actual boot
The standalone MSCP driver in 2.11 has the "give a vector to the
adaptor" change so my guess is that the bootblock is where the
looping is happening. The bootbock (rauboot.s from /sys/mdec)
relocates itself to 0160000-01000 or 0157000 so a loop at 0157702
would be where the 'racmd:' routine is looping waiting for a
command to complete (or the adaptor to come ready the first time).
I thought the same "give a vector" change had been made to rauboot.s
but it would appear that's not the case ;-(
Received: (from major at localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id CAA59602
for pups-liszt; Wed, 1 Dec 1999 02:59:41 +1100 (EST)
More information about the TUHS