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

On 2025-03-28 15:05, Anders Magnusson wrote:
> 11/730 has only one Unibus.  IIRC the CPU is placed in the Unibus :-)

Well, I wouldn't describe it like that. The CPU have the UBA integrated 
to the CPU, but not everything is on the Unibus. :-)

> 11/750 can have multiple Unibuses, but I have never seen that in real 
> life (multiple Massbus though).  The ubareset IPR resets all of them.

Had to read up on this. You are right. By default it would be one Unibus 
and up to three massbuses. However, you can throw one massbus out, and 
insert a second Unibus instead. I've never seen that either.

> 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.

   Johnny

> 
> -- Ragge
> 
> 
> Den 2025-03-28 kl. 11:50, skrev Johnny Billquist:
>> 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 confusedin
>>> 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