CVS commit: [netbsd-10] src/sys/arch/vax

Module Name:	src
Committed By:	martin
Date:		Thu Apr  2 16:43:43 UTC 2026

Modified Files:
	src/sys/arch/vax/boot/boot [netbsd-10]: conf.c ra.c vaxstand.h
	src/sys/arch/vax/uba [netbsd-10]: uba_mainbus.c

Log Message:
Pull up following revision(s) (requested by hans in ticket #1248):

	sys/arch/vax/boot/boot/conf.c: revision 1.19
	sys/arch/vax/boot/boot/ra.c: revision 1.23
	sys/arch/vax/boot/boot/vaxstand.h: revision 1.12
	sys/arch/vax/uba/uba_mainbus.c: revision 1.15

vax/uba: fix detection of CMD CQD-22x MSCP controllers

Certain models of CMD MSCP controllers fail to be detected by uda(4) if
they have been booted from. This failure mode has been introduced in
revision 1.11 of uba_mainbus.c, when scanning for Qbus/Unibus memories
was added. They are deteced fine when NetBSD is booted from any other
device such as over the network.

When NetBSD is booted from a MSCP controller, the boot loader sets up
the Qbus map to provide the controller with a small command/response
ring in memory to be used for I/O. Once the kernel is loaded and uba(4)
is attaching, the Qbus map is cleared while scanning for memories. It
appears that sudden loss of access to the command/response ring causes
the firmware of these CMD controllers to drop dead.

As a result, these controllers don't react in a reasonable time (100ms
by the spec) when their IP register is written to re-initialze the
controller. Even though uda(4)'s udamatch() waits up to 10s for a sign
of life from the controller, that's usually not enough for it to wake
up and it is assumed to be absent. Which, of course, causes the kernel
to fail booting as the boot device can't be found.

This needs to be addressed both in the kernel and the bootloader.

We can work around this issue in the kernel by restoring the Qbus map
registers to their original values after we've used them for detecting
Qbus memories. The code to do that is already there but commented out,
it just needs uncommenting.

vax/boot: fix detection of CMD CQD-22x MSCP controllers

Certain models of CMD MSCP controllers fail to be detected by uda(4) if
they have been booted from. This failure mode has been introduced in
revision 1.11 of uba_mainbus.c, when scanning for Qbus/Unibus memories
was added. They are deteced fine when NetBSD is booted from any other
device such as over the network.

When NetBSD is booted from a MSCP controller, the boot loader sets up
the Qbus map to provide the controller with a small command/response
ring in memory to be used for I/O. Once the kernel is loaded and uba(4)
is attaching, the Qbus map is cleared while scanning for memories. It
appears that sudden loss of access to the command/response ring causes
the firmware of these CMD controllers to drop dead.

As a result, these controllers don't react in a reasonable time (100ms
by the spec) when their IP register is written to re-initialze the
controller. Even though uda(4)'s udamatch() waits up to 10s for a sign
of life from the controller, that's usually not enough for it to wake
up and it is assumed to be absent. Which, of course, causes the kernel
to fail booting as the boot device can't be found.

This needs to be addressed both in the kernel and the bootloader.

To fix this properly, the standalone ra.c driver in the boot loader
should provide a close() entry point which clears the IP register to
issue a controller reset. Thus when the kernel is loaded, the firmware
of the MSCP controller is again in reset state and can't get confused
anymore by the initialization of the Qbus map in uba(4).


To generate a diff of this commit:
cvs rdiff -u -r1.18 -r1.18.32.1 src/sys/arch/vax/boot/boot/conf.c
cvs rdiff -u -r1.22 -r1.22.32.1 src/sys/arch/vax/boot/boot/ra.c
cvs rdiff -u -r1.11 -r1.11.4.1 src/sys/arch/vax/boot/boot/vaxstand.h
cvs rdiff -u -r1.14 -r1.14.40.1 src/sys/arch/vax/uba/uba_mainbus.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.