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

On Fri, Mar 28, 2025 at 04:01:16PM +0100, 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 :-)

The reason I didn't just commit this was that I'm wondering who I might
break with that, and whether it's worth moving this out of uba.c into
the CPU specific setup.

Every Unibus/QBus attachment we have provides a function for ubainit(),
and except for the 11/78x and 86x0 systems, that will just write into
PR_IUR. This code was already there, and was called as part of a
Unibus/QBus reset handling, although I'm not sure when/if that actually
runs. So I assume at least in theory we're already able to handle
Unibus/QBus resets in a running system?

I'm really not sure that the change in the 2.11BSD MSCP boot loader is
relevant here, because none of the related code seems to have changed in
a meaningful way between 3.1.1 and 10.1 either.


Hans


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