Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Apr 1996 16:09:45 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        rmcgrave@alphapower.com (Dick McGravey)
Cc:        questions@FreeBSD.ORG
Subject:   Re: Support for Alpha
Message-ID:  <199604102309.QAA02691@phaeton.artisoft.com>
In-Reply-To: <199604101954.PAA02303@zork.tiac.net> from "Dick McGravey" at Apr 10, 96 03:55:53 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Does Free BSD have support for DEC  Alpha?  Specifically the 
> 21066 board 

There was a project to do an Alpha port, but ut was cancelled...
details follow, if you are interested.


Much of the code for the FreeBSD Alpha port, at least the architecture
specific stuff that Jeffrey Hsu did all the work on, was integrated
into the NetBSD Alpha port when the loaner machines we were using
had to go back (I offered to buy mine, but no dice).

Most of my code dealt with cleaning up the FreeBSD x86 architecture
dependencies (console code, timer code, bus code, etc.) to get a
functional HAL into FreeBSD without losing any existing features
out of the code or slowing it down terribly.  Since this included
porting the unified VM/buffer cache code to NetBSD (basically),
the incomplete code was a definite "no go" for integration into
the NetBSD code, so I didn't even try to submit it.  They may
have taken some (trivial) graphic console changes I did, for
all I know, but they probably didn't.


Because CGD integrated much of Jeffrey's code, NetBSD should run
on the 21066/21066A without problems.  I still have a 2G disk with
bootable NetBSD with integrated FreeBSD console and timer code that
I bought for the port, and I ran it on 21066 hardware.  I'm just
about to sacrifice it (it's backed up to tape, I'm not stupid 8-))
to fully self-hosting the Motorolla Ultra 603/604 PPC port.

The NetBSD Alpha code on that disk require OSF (DEC UNIX) to get
installed, and requires that the system be set up for "Ultrix
Microcode".  Since the install is via an FS image, you would
also need to hack the disk label to use it on other than a 424M
drive, which is what the bootable FS image from Chris required.

There is some twiddling with the partition label for the swap slice
you have to specifically use the label "swap" to make NetBSD happy,
and there are some "gotcha's in the FFS implementation for image
compatability with OSF disklabels (a problem which will be going
away shortly in FreeBSD because of upcoming devfs code).


I think in general an end user would be happier with a FreeBSD
installation, with bootable tape/disk/cdrom install, instead of
needing to have OSF to dd the disk image on.  As a hardware seller,
though, you might be able to be happy with NetBSD, if you preinstall
for your customers.  You would need one OSF license to do the
install, and as long as the microcode and boot code were there,
you should be able to crank out disks with NetBSD preinstalled
in a relatively short per-disk timeframe.

Unfortunately, recent changes in FreeBSD's VM and other code mean
that a FreeBSD port would pretty much have to start from ground
zero once again, though the fact that NetBSD now runs on the box
without a lot of work (thanks to a lot of work by Jeffrey and Chris)
is a big plus in that direction... it would mean fighting on only one
front (source integration) to get a port, instead of two (NetBSD
did not run on the hardware, so the FreeBSD port required a NetBSD
port followed by code integration for the shortest path).


This is probably more information than you wanted.  8-).



					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604102309.QAA02691>