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

[Hans Rosenfeld <hans%netbsd.org@localhost>]

Hi,

it has been reported here before that some MSCP controllers, the CMD
CQD-220/223 in particular, aren't detected when booting from a disk
attached to them. They are detected just fine when netbooting, however.

So this is almost certainly caused by their firmware getting confused in
one way or another. When booting from disk, the boot ROM and/or our boot
loader have already initialized them, and now the uda(4) driver comes
along and udamatch() writes 0 into IP and expects to see a controller
init step1 in SA happening within 10s as the spec requires.

For some reason I don't fully understand yet this was working fine in
4.0 and broke some time afterwards, possibly due to the big VAX code
rototilling that was done in 2008. A friend of mine was suffering from
this on his VAX 4000/200 (KA660), preventing him from upgrading from
3.1.1. to 10.1.

By playing around with the registers and introducing long delays I was
able to get the controller to initialize after 12s or more, most of the
time at least. However, a much simpler and more reliable fix that
doesn't incur long wait times just adds a I/O bus reset in uba_attach()
by calling sc->uh_ubainit.

On the small QBus VAXen, this results in a mtpr(0, PR_IUR) to reset the
QBus. The KA660 manual states clearly that this doesn't affect the
onboard devices (SGEC and SHAC), and I'm reasonably confident that this
works the same on all models with onboard devices coming after the KA640.

I'm a bit more concerned about the older and bigger Unibus systems, the
11/7xx and 86x0, most of which can have multiple Unibus adapters. For
the 11/78x and 86x0, dw780_init() looks like it would take care of only
initializing the particular Unibus adapter it is called for, so this
should work. But dw730_init() and dw750_init() just do a mtpr(0, PR_IUR),
so they might actually reset all Unibusses on these systems? Does anyone
know?

So, please take a look at the attached patch. I think this is the right
thing to do, but I'm not sure. Another way to do this would be to add
this to the model specific CPU initialisation code. Any opinions?


Hans


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

commit abe03ae39ad3c18b5762acf1f7dfb22da77e06c9
Author: Hans Rosenfeld <rosenfeld%grumpf.hope-2000.org@localhost>
Date:   Thu Mar 27 19:55:07 2025 +0100

    vax/uba(4): perform I/O bus reset before attaching children
    
    This resets all Qbus and Unibus devices before we try to talk to them,
    making sure they are in a sane state.
    
    It has been observed that when booting from some CMD MSCP controllers,
    uda(4) fails to detect the controller in udamatch(), not attaching as
    a result.
    
    It appears that these controllers fail to react to the initialization
    sequence done by udamatch() correctly and within the specified time if
    it was already initialized and used by the boot ROM and/or boot loader.
    
    Allowing longer timeouts than 10s and multiple retries allows uda(4) to
    detect the controller, but that wait time is unnecessary as performing
    a proper I/O bus reset gets it to work pretty much instantaneously.

diff --git a/sys/dev/qbus/uba.c b/sys/dev/qbus/uba.c
index 1bf70c663ce0..533072d0e423 100644
--- a/sys/dev/qbus/uba.c
+++ b/sys/dev/qbus/uba.c
@@ -255,6 +255,12 @@ uba_attach(struct uba_softc *sc, paddr_t iopagephys)
 	if (bus_space_map(sc->uh_iot, iopagephys, UBAIOSIZE, 0, &sc->uh_ioh))
 		return;
 
+	/*
+	 * Perform an I/O bus reset first.
+	 */
+	if (sc->uh_ubainit)
+		(*sc->uh_ubainit)(sc);
+
 	/*
 	 * Keep track of which addressed devices are found.
 	 */