Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



11/730 has only one Unibus.  IIRC the CPU is placed in 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.

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.

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






Home | Main Index | Thread Index | Old Index