From owner-freebsd-alpha Thu May 15 15:14:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20529 for alpha-outgoing; Thu, 15 May 1997 15:14:13 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA20521 for ; Thu, 15 May 1997 15:14:10 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wS8mH-0001Pj-00; Thu, 15 May 1997 16:13:37 -0600 To: Curt Sampson Subject: Re: Alpha questions.. Cc: Andrew Gallatin , freebsd-alpha@freebsd.org In-reply-to: Your message of "Thu, 15 May 1997 15:02:24 PDT." References: Date: Thu, 15 May 1997 16:13:36 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-alpha@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Curt Sampson writes: : I'm not entirely up on the services the various flavours of PALcode : provide, but I'm extremely dubious that it would be easy, or even : possible, to have a single kernel work with more than one flavour : of PALcode. Looking at the instruction sets they provide it's : obvious that they are very different. The key here is that we can generally load in our own PALs (ala milo) and then it won't be an issue. : Also, I understand that the PALcode in MILO is not idential to the : PALcode in the SRM console firmware. So long as the few PALs that are called are functionally the same, it shouldn't be an issue.... Now trying to get this to work with both NT's PAL set and SRM's PAL set w/o loading our own might be very interesting indeed. And might be hard like you describe since we'd need a HAL-like layer over the PALs. Warner