>> 	The PALcode included in MILO has severe bugs.  You can't use it
>> 	to run BSD, or OSF/1 for that matter.  It's remarkable that you
>> 	can use it to run Linux, and sundry reports of Linux
>> 	instability when run with MILO make me suspect that, in fact,
>> 	you can't.

> In essence what you're saying is that no Alpha OS is capable of
> actually talking to the bare hardware?  e.g. PALcode is still
> required after the kernel is loaded?

As I understand it - I'm sure I'll be corrected if I'm wrong - that's
correct.  The PALcode is used by the OS for things which are severely
hardware-dependent (like loading page table entries, I think), and I
think the PALcode itself is very hardware-specific.  (That is, it won't
work to, for example, put AlphaPC164LX PALcode on anything but an
AlphaPC164LX.)  Very loosely put, custom microcode. :-)

> e.g. Windows NT has PALcode embedded in it somehow?

Possible, I suppose, but it strikes me as unlikely; more likely it
knows how to call on the PALcode provided by ARC, just as *BSD knows
how to call on the PALcode provided by SRM.

> This sounds familiar, but I'm still confused about it.  Why can't the
> PALcode be reverse engineered, or otherwise re-written?

It probably could be, but if I'm right about the degree to which it's
hardware-specific, it likely wouldn't be worth it.

> I have typically thought of the "SRM is required for NetBSD/alpha"
> along the lines of "OpenFirmware is required for NetBSD/macppc."
> [...]  The impression I have now is more like "SRM is required for
> NetBSD/alpha" along the lines of "BIOS is required for Windows."

The latter is more or less the impression I have too, for what that may
be worth.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B