Subject: Re: Are PC164 based alphas supported?
To: Andrew Gallatin <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 08/08/1997 21:09:54
> I've gotten the impression that the linux palcode provides a subset of
> the functionality of the DU palcode, and that the problem w/using the
> linux bootloader/palcode is that NetBSD currently makes use of some of
> the functionality that's only in the DU palcode. Is that right?
The words are more or less right, but the thoughts behind them sounds
like they might be wrong. 8-)
There are two sets of interfaces at issue:
(1) console software (SRM). The SRM console interface is
supposed remain constant across all systypes.
MILO doesn't provide anything remotely like these, as
far as I know. If I recall, MILO acts as both firmware
and a kernel loader. (Bloody bad design, in my opinion,
but that's another story. "The firmware should not know
anything about the kernel's executable format.")
Actually, I believe the exception of the above comment
is the HWRPB. I seem to recall that MILO fakes up a
(2) PALcode. The OSF PALcode is mostly the same across all
systypes, but there are certain additional PALcode ops
which _must_ be used on some systypes for proper OSF
PALcode operation. There are also other less-used
machine-dependent features, e.g. machine check logout
MILO doesn't provide the systype specific PALcode ops.
Last I saw, they don't provide _any_ useful info in
logout frames, either.
NetBSD/alpha's bootloader uses both (sets up and uses PALcode, uses
SRM console interfaces). This can't really be fixed, but a new
bootloader could be written for a new console interface, if necessary.
The kernel currently uses both, but that can be "mostly fixed." By
"mostly fixed" i mean that the kernel can be changed easily enough to
not use the SRM interfaces (it currently uses very few, and those uses
can be eliminated; jason's been working toward that a bit, and i'm
going to be working with him on it), and the feature that NetBSD most
depends on that's provided by the OSF/1 PALcode (the superpage; the
same feature that may be missing in some neutered chips) can be
avoided (with lots of work).
The problem is with the missing system-specific PALcode ops that MILO
doesn't implement. They deal with interrupt handling, and on a "real
OSF PALcode" system they _MUST_ be used or the system will not
function properly. Given their nature, it makes the most sense to
implement them in the PALcode, and not to special-case them in the
kernel for different "real" vs. "non-real' PALcode types.
I'm willing to say that NetBSD/alpha should (in the long run) run on
"fake" OSF PALcode systems, but if real SRM _requires_ a certain
behaviour from the OS, then the "fake" PALcode should at least allow