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

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2025-03-28 16:01, Anders Magnusson wrote:
> Den 2025-03-28 kl. 15:28, skrev Johnny Billquist:
> > On 2025-03-28 15:05, Anders Magnusson wrote:
> > > Besides that, resetting the Unibus before autoconfig starts should do 
> > > no harm, but there may be devices that takes a significant time to 
> > > become ready after a ubareset (since ubareset should normally be 
> > > something that is done i a quite controlled fashion). Don't know if 
> > > that will affect any of the currently existing drivers.
> >
> > I am sortof surprised that the CMD controller would have that kind of 
> > bug. Even more so if this is a problem that only started appearing 
> > after a certain version of NetBSD. But if it has been thoroughly 
> > diangosed...
> >
> > Anyway, one thing I know from the past is that some sloppy MSCP code 
> > can fail to work on the CMD controller, but get away with it on the 
> > DEC controllers. There was an example of that in 2.11BSD for the boot 
> > loader that I had to fix. The normal driver was doing it correct, but 
> > the code in the bootloader was not. Booting from an UDA50 worked fine, 
> > but my CMD did not. I can dig up the exact details if needed. But I do 
> > remember it was only a few bits that needed correction for things to 
> > work right.
> Please do!  It may solve the problem for the friend of Hans without 
> having to reset the Unibus :-)

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.
But if someone points me at the specific code in NetBSD, I can try to 
see if it's a similar kind of issue.

But basically, the code was checking the interrupt register even though 
interrupts were not enabled, instead of checking to transfer of 
ownership of the command and response descriptors. Apparently, how the 
interrupt register is updated is different on the CMD controller. But I 
think the obvious comment is that if you don't have interrupts enabled, 
it is not the interrupt register you should be checking to make sure the 
command was read by the controller, and a response was generated.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol