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

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 :-)

-- R



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