Date: Sat, 04 Dec 1999 16:57:58 -0800 From: Mike Smith <msmith@freebsd.org> To: Andrew Gillham <gillhaa@ghost.whirlpool.com> Cc: tls@rek.tjls.com, port-alpha@netbsd.org, alpha@freebsd.org Subject: Re: Q: Compaq, *BSD and 'Linux-only' AlphaBIOS (fwd) Message-ID: <199912050057.QAA05494@mass.cdrom.com> In-Reply-To: Your message of "Sat, 04 Dec 1999 19:03:59 EST." <199912050003.TAA23976@ghost.whirlpool.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Thor Lancelot Simon writes: > > > > I can't *believe* I'm having to say this again, for the Nth time in as many > > months: > > > > 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? That's partially correct. The PALcode requirements for different operating systems are different; that's why there is NT PALcode, VMS PALcode and OSF PALcode. The NT PALcode footprint is perhaps the smallest, and as a result (according to one of the developers therof with whom I have had conversation) there is a single common PALcode for each CPU architecture. The OSF PALcode footprint is the one that the BSD's use. Linux uses a subset of this, and MILO (just) covers that. As Thor has said, MILO is buggier than a $5 hotel room. > e.g. Windows NT has PALcode embedded in it somehow? I don't believe so. The PALcode is typically provided by the system's firmware. > This sounds familiar, but I'm still confused about it. Why can't the > PALcode be reverse engineered, or otherwise re-written? Theoretically it could. However, doing that would require access to documentation that's not generally available, and a massive development effort. Right now, there aren't the people or documentation available to make it a viable project. > [snip] > > Gee, it'd be nice if anyone would _remember_ this explanation for more > > than a month this time. > > Maybe the explanation is missing some details. I have typically thought > of the "SRM is required for NetBSD/alpha" along the lines of "OpenFirmware > is required for NetBSD/macppc." (e.g. to boot and get started) You are confusing "SRM" and "PALcode". The two are typically bundled together, but they are in no way inseperable. > The impression I have now is more like "SRM is required for NetBSD/alpha" > along the lines of "BIOS is required for Windows." (e.g. calling the BIOS > all the time for services) No. OSF PALcode is required for BSD/alpha in more or less that fashion. SRM is only "required" because nobody has written an ARC/AlphaBIOS-aware bootstrap. There's one in some unknown state in the FreeBSD bootloader sources, FWIW, but it's not useful unless the machine already has OSF PALcode, in which case it'll have SRM and thus it's a bit of an unuseful item at this stage. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com 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?199912050057.QAA05494>