> From: "Kevin P. Neal" <kpneal@pobox.com>
>
> On Thu, Apr 27, 2000 at 09:02:43AM -0700, Ross Harvey wrote:
> > DEC guards SRM tightly as a way to reserve for themselves the
> > sale of platforms for OSF/1^WDigital Unix^W^WTru64.
> > 
> > It is therefore somewhat to be expected that a Samsung board would either
> > not have SRM or have SRM only as an extra-cost item. I would call Samsung
> > on the phone at this point, if it were me...
>
> So, how tied to the SRM is NetBSD? If Samsung were to implement it's
> own PALcode from scratch and to published specs, could that be used
> with NetBSD? It's been said here before that writing PALcode is
> a huge undertaking that requires close interaction with the hardware
> guys; Samsung has the hardware guys in house....

Writing palcode is not hard.

It's the *idea* of palcode that was brilliant.

Palcode is not a lot more than the low level event vectors and software
TLB handlers that pretty much every other RISC chip needs also.

The really way-cool thing DEC^WCompaq did was to do it independently
of the kernel, document the interface, and cook up a name ("palcode") for
it.

If DEC hadn't done that, then the alpha would have been programmed
about like the PPC or MIPS .. with lots of contortions to adapt the
kernel to whatever the latest screwy interrupt or TLB hardware got
designed into the latest chip. It wouldn't have seemed any different
and we would not have called our (now much larger and uglier) locore.s
anything like "palcode.s". :-)

So, we could run directly on the HW without palcode, or Samsung could,
without great effort, write new palcode.

However, why should they?  They get the NT market anyway. It will be
interesting to see what happens with linux, tho. Contrary to opinions
frequently expressed here, linux needs SRM just like NetBSD does on
most platforms.

	ross