[ Carl Shapiro sent me the following, as part of a reply, in private
  mail.  I'm reposting the inclusions (from his mail) with
  permission. 8-]

> Suppsedly these are the diffrences (from a semi official DEC posting on
> a Linux Alpha mailing list):
> 
> [...]
> 
> 1) SPE[0] must always be SET in ICSR (Ibox csr)
> 
> 2) SP[0] must always be SET in the MCSR (Mbox CSR). 
> 
> [...]
>
> Here is the URL that I got this from (sorry, >80 columns):
>
> http://www.redhat.com/support/mailing-lists/archives/axp-list/1996-February/0189.html

Looking at the URL you mention, it would seem that that causes the
superpage to be mapped at a place different than where NetBSD/Alpha's
VM code wants it.  "Yuck."

To support these chips would likely require substantial changes to
NetBSD/Alpha's physical memory management model.


> > I have absolutely no intention of personally doing so.  People are
> > welcome to do so, and i'd be happy if they did, but quite frankly it's
> > a huge amount of work, and _i_ am not keen on even maintaining it.
> > (It's the type of thing where whoever does it would end up getting an
> > account on the netbsd development machines, would be told to check the
> > code in, and would be given 'ownership' of that chunk of the source
> > tree.)
> 
> I don't know anything about how the ARC console code works, but there has
> to be something like this for the MIPS/ARC machines?  How does the PICA
> port boot?

It's not just the boot blocks at issue here, it's also PALcode.

the SRM console firmware provides the OSF/1 PALcode.  The SRM console
firmware really isn't used much at all by the kernel.  In fact, it's
used in the following places:

	(0) boot blocks, to load the kernel.

	(1) at boot time, to get a few console environment variables.

	(2) at boot time, to do console getchar/putchar before the
	console device is initialized (and, on unsupported systems,
	for just long enough for the system to print out a panic
	message and quit).

	(3) at a few random places, where the HWRPB is accessed
	(because the console firmware sets up the RPB, if you
	use different console firmware the RPB might be different,
	or might not exist at all).
	

The OSF/1 PALcode, provided by the SRM console firmware, is used
heavily throughout the Alpha port.  It forms the basis for
NetBSD/Alpha's virtual memory management and interrupt handling code,
as well as system call dispatch, exception and fault handling, etc.


>From the sound of the modifications you mention, it's impossible for
anybody (DEC, MILO, whoever) to provide the functionality currently
provided by the OSF/1 PALcode, which NetBSD/Alpha requires to run.  In
particular, NetBSD/Alpha requires the superpage to be where it is
under the OSF/1 PALcode, and that location is not possible with the
change described above (if i understand the messages referenced by the
URL you mentioned).



That means that without substantial changes that _I_ have no intention
of making, NetBSD/Alpha will not run on those CPUs.  I will probably
never own or even have access to those CPUs, given the fact that my
group buys hardware to run Digital UNIX on, and i tend to be given
access to 'spare' machines.

If somebody wants to take on the task of making them go, I'd be very
happy to assist them.  Since it'd pretty much require rewriting the
low-level VM code (which needs to be done anyway), it'd save me a lot
of work down the road... 8-)


chris