Date: Sun, 5 Dec 1999 11:54:51 +1100 From: "Andrew Reilly" <reilly@zeta.org.au> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, Lord Isildur <isildur@guild.net>, Matthew Jacob <mjacob@feral.com>, alpha@FreeBSD.ORG, port-alpha@netbsd.org Subject: Re: Q: Compaq, *BSD and 'Linux-only' AlphaBIOS (fwd) Message-ID: <19991205115451.A20025@gurney.reilly.home> In-Reply-To: <199912040820.AAA00599@mass.cdrom.com> References: <14408.29267.776501.133049@grasshopper.cs.duke.edu> <199912040820.AAA00599@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 04, 1999 at 12:20:15AM -0800, Mike Smith wrote: > There are licensed components inside SRM that prevent this from > happening; we've been down this path with Dompaq already. However, there > does seem to be some fairly strong interest inside the organisation for > the production of an SRM replacement that would be open-sourced. Apart from boot-monitor stuff, there's PALcode, right? What does that actually do for you, that takes so much (proprietary) code? Isn't it just shortcuts to hide the TLB/memory management hardware under some sort of high-level API? Put another way: is there anything about the various Alpha implementations that are insufficiently documented, or prevent us from doing these things ourselves, right on the chip itself? The MIPS chips have to do the same sorts of manual TLB things, I thought, without the assistance of PALcode. The *BSD reliance on the SRM seems to basically limit the Alpha purchase choices to Compaq. I.e., not Samsung/AlphaProcessor. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991205115451.A20025>