> 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
	    HWRPB.

	(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
	    area layout.

	    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
it.




cgd