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

The 11/730 and 11/750 can only have one Unibus as far as I can remember.

   Johnny

On 2025-03-28 11:30, Hans Rosenfeld wrote:
> 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
> 
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol