Re: I/O bus reset to fix CMD MSCP controllers (and probably others)

On Fri, Mar 28, 2025 at 05:27:48PM +0100, Johnny Billquist wrote:
> 
> Here is the actual patch:
> 
> *** usr/src/sys/conf/boot/raboot.s.old  Mon Aug 17 21:41:34 2009
> --- usr/src/sys/conf/boot/raboot.s      Mon Aug 17 22:44:12 2009
> ***************
> *** 1,5 ****
> --- 1,9 ----
>   /*
>    *    SCCS id @(#)raboot.s    2.0 (2.11BSD)   4/13/91
> +  *
> +  * Code corrected as per the other primitive mscp drivers
> +  * to handles other mscp controllers than DECs.
> +  * /bqt - 20090817
>    */
>   #include "localopts.h"
> 
> ***************
> *** 59,65 ****
> 
>   MSCPSIZE =    64.     / One MSCP command packet is 64bytes long (need 2)
> 
> ! RASEMAP       =       140000  / RA controller owner semaphore
> 
>   RAERR =               100000  / error bit
>   RASTEP1 =     04000   / step1 has started
> --- 63,69 ----
> 
>   MSCPSIZE =    64.     / One MSCP command packet is 64bytes long (need 2)
> 
> ! RASEMAP       =       100000  / RA controller owner semaphore
> 
>   RAERR =               100000  / error bit
>   RASTEP1 =     04000   / step1 has started
> ***************
> *** 153,170 ****
>         mov     $RASEMAP,*$ra+RARSPH    / set mscp semaphores
>         mov     $RASEMAP,*$ra+RACMDH
>         mov     *_bootcsr,r0            / tap controllers shoulder
> !       mov     $ra+RACMDI,r0
>   1:
>         tst     (r0)
> !       beq     1b                      / Wait till command read
> !       clr     (r0)+                   / Tell controller we saw it, ok.
>   2:
>         tst     (r0)
> !       beq     2b                      / Wait till response written
>         clr     (r0)                    / Tell controller we got it
>         rts     pc
> 
> ! icons:        RAERR
>         ra+RARING
>         0
>         RAGO
> --- 157,176 ----
>         mov     $RASEMAP,*$ra+RARSPH    / set mscp semaphores
>         mov     $RASEMAP,*$ra+RACMDH
>         mov     *_bootcsr,r0            / tap controllers shoulder
> !       mov     $ra+RACMDH,r0
>   1:
>         tst     (r0)
> !       bmi     1b                      / Wait till command read
> !       mov     $ra+RARSPH,r0
>   2:
>         tst     (r0)
> !       bmi     2b                      / Wait till response written
> !       mov     $ra+RACMDI,r0
> !       clr     (r0)+                   / Tell controller we saw it, ok.
>         clr     (r0)                    / Tell controller we got it
>         rts     pc
> 
> ! icons:        RAERR + 033
>         ra+RARING
>         0
>         RAGO
> 
> 
> 
> Anyway, not sure if this helps, since now we're in PDP-11 assembler. But
> maybe it gives a bit of an idea what the problem was.

I've actually looked at that and tried to understand it when I was
looking into this issue. The PDP-11 assembly doesn't scare my, I've
written my fair share of it and I'm still comfortable reading it. Too
bad the patch doesn't show the definiton of RACMDI and RARSPH, and I'm
too lazy to google that. Maybe I'll boot the 11/73 later this weekend
and look at the full code.

What I did read was the MSCP programming document for the UDA50 that's
on Bitsavers.

> But if someone points me at the specific code in NetBSD, I can try to see if
> it's a similar kind of issue.

The problem is in sys/dev/qbus/uda.c, in particular in udamatch(). All
that udamatch() wants to do is to go through the first initialization
steps to cause an interrupt.

The state of the controller when udamatch() is running is that it has
been used already by VMB and boot to get the kernel loaded.

The UDA50 register interface really consists only of two registers, IP
and SA. Writing anything into IP should cause a initialization sequence
to be started, with SA indicating Step1 shortly after. If it doesn't,
udamatch() should try one more time, but currently doesn't. It only
retries the initialization if Step1 was reached and we then fail to
reach Step2.

The first thing I did was checking that the CSR was mapped correctly,
that the physical addresses where what was expected. I also read and
wrote the registers directly at the VMB console. It would have been
surprising if anything was wrong there, as the same code works just fine
when the controller hasn't been touched since the last I/O bus reset
since we've booted off the network.

One of the things I did as an experiment was have udamatch() write 0
into SA, and then read it once per second until something happened. Most
of the time, SA would have the error bit set after a few seconds. From
there, writing 0 into IP would kick off a controller initialization and
get SA to indicate Step1 2s later. But as I said, this incurs a boot
delay around 12s.


Hans


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown