Floating CSRs [was Re: Address of second TMSCP controller]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> The whole point of the DEC defined floating CSR configuration rules
>>> was in order to reliably identify each controller type.  But it
>>> requires a rather more intelligent contextual probing of the
>>> address space instead of the NetBSD rules based matching system.
>> The probing algorithm is quite simple, and data driven.

Yes, but it also is specific to Unibus (and lookalikes, such as Qbus),
and depends heavily on having a single repository of device information
covering all, or nearly all, devices.  In DEC's case this was easy
because there was a single vendor providing nearly all devices.  There
is nothing conceptually impossible about doing something similar for,
say, ISA, but it would be far more difficult because, to use '80s-DEC
terminology, practically all cards in many systems were third-party
hardware.

> The algorithm is definitely not complicated.  However, it basically
> means that CSR addresses and vectors are not defined in the config
> anymore, if you are to follow it.

Indeed.  It would require all uba-attached devices (or at least all
participating uba-attached devices) to talk to the floating-CSR code to
know what address(es) to probe at, if done at boot time.

I'm not sure how I would implement it, if I were to want to build such
a thing for NetBSD/vax.  Maybe as another locator, so you could attach

dhu* at uba? floating-csr

and then the dhu driver would know its fixed address(es?) and
floating-CSR rank.  Or perhaps I would implement it as an alternative
bus implementation

floatinguba at mainbus0
dhu* at floatinguba

or perhaps something else.

> Which is where it is rather different than the NetBSD configuration
> system, which builds up a config at compile time, and at boot it
> tries to probe through that configuration (now talking about the VAX
> bits here, not sure about how it works on other architectures).

As I understand it - an important caveat here - it depends less on the
CPU architecture you're using (VAX, i386, ARM, etc) than it does on the
bus type (Unibus, PCI, Microchannel, etc).  As I recall the
terminology, there are direct-addressed buses and indirect-addressed
buses, though I don't recall which is which.  Examples in the peecee
world are PCI and ISA: with PCI you address a slot, and it tells you
what the device in that slot, if any, is (or at least claims to be),
whereas with ISA, you probe an address and try to guess what, if
anything, is there.  Unibus/Qbus, of course, works like ISA in this
respect, but that is the nature of Unibus, not VAX: if someone were to
build a VAX with PCI, or, say, a Unibus/PCI bridge, probing the PCI bus
would work like probing a PCI bus on any other port, except of course
for the attachment (or bridge) magic.  And if someone were to build,
say, a MIPS machine with a Unibus, probing it would work like probing a
Unibus on a VAX - again, except for attachment magic.

I'm sure there are people here who can and probably will correct the
errors I've doubtless made in the above.

> On PDP-11s, RSX definitely did not care about [the floating CSR
> rules] either.  Instead, similar to NetBSD, you define at compile
> time where different things are located in the address space, and it
> just gets probed at boot time, if the hardware is actually present.
> If things were added, and hardware should shift to other addresses
> because of this, then RSX wouldn't find it anymore.  Same with
> NetBSD.

Perhaps the most appropriate way to do it with NetBSD, then, would be a
tool which takes a list of what devices you have and spits out device
attachment lines for a kernel configuration, presumably something like
a reskin of tih's tool.

> So I'm not fully convinced you really would want to have a system
> that goes by the DEC floating address conventions.

Well, from a strictly utilitarian perspective, probably not.  But from
a strictly utilitarian perspective, there is little reason to run a VAX
at all, except for the few people - a small fraction even among those
on this list, I would hazard to guess - who have Unibus-/Qbus-specific
hardware with no modern replacement.

Given the retrocomputing geeks who want to run systems as original as
feasible, even to the point of doing things like trying to find
original parts for power supplies and the like, I suspect some would
want to use the floating-CSR rules simply bceause they were The Way It
Was Done Back Then.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B