From owner-freebsd-alpha Sat Dec 4 20:29:57 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 20C27152AA for ; Sat, 4 Dec 1999 20:29:53 -0800 (PST) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id UAA17892; Sat, 4 Dec 1999 20:29:44 -0800 (PST) Message-Id: <199912050429.UAA17892@lestat.nas.nasa.gov> To: Andrew Gillham Cc: tls@rek.tjls.com, port-alpha@netbsd.org, alpha@freebsd.org Subject: Re: Q: Compaq, *BSD and 'Linux-only' AlphaBIOS (fwd) Reply-To: Jason Thorpe From: Jason Thorpe Date: Sat, 04 Dec 1999 20:29:43 -0800 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 4 Dec 1999 19:03:59 -0500 (EST) Andrew Gillham wrote: > 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? e.g. Windows NT has PALcode embedded in it somehow? No, ARC console comes with the NT PALcode. It is possible to run on the bare hardware. But, there are some things that the PALcode does that are *quite* model-specific: - various cache issues - various interrupt issues (e.g. issuing EOIs, interrupt routing, etc.) - machine checks generated by the core logic - machine checks generated by the I/O processors ...and the list goes on. This doesn't include the processor-model specific stuff: - TLB differences - cache differences - trap differences ..and the list goes on here, too. Basically, the PALcode provides a very nice abstraction to the hardware which makes it actually reasonably possible to port the OS to the hardware (and, geez, even Digital UNIX is horribly complex in the hardware specific stuff even *WITH* the PALcode). Running on the bare hardware would be a real pain. Now... The NT PALcode *is* documented ... pretty well in the Green Book, and probably even better in the Red Book. It might not be totally unreasonable to think about a NetBSD/arcalpha ... however, the NT PALcode comes with some caveats: - It's very geared to NT's kernel model - Memory management is essentially MIPS-like, and also limits the virtual address space to 32-bit (except for some virtual address extension hack used to get at the hardware in the kernel) - It's ... amazingly large and complex. The number of NT PALcode calls is simply mind boggling. > This sounds familiar, but I'm still confused about it. Why can't the > PALcode be reverse engineered, or otherwise re-written? Writing PALcode for the Alpha is not in the business you want to be in. It's a lot (a lot a lot a lot) of very carefully written assembly code. Instruction counts in many operations matter. It's a daunting task. > 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) > 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) Note, SRM isn't really required, per se. NetBSD/alpha *DOES RUN* on a platform that doesn't have SRM; it's a parallel multicomputer called the Avalon A12. It's not a DEC machine. It does't have DEC console software. The console software it does have, however, provides OSF/1 PALcode, and the A12 console software also complies with the Alpha Console Architecture as described in the architecture manual. SRM also complies with this (obviously). The AlphaBIOS console software complies with ARC (originally a console specification for MIPS systems), and not with Alpha Console Architecture. If someone were to write some free console software, please pay careful attention to the Green and or Red Book's description of the Console Architecture. The Console Architecture doesn't suck. Now, strictly speaking, the console software and the PALcode are distinct entities. When NetBSD calls the PALcode, it's not calling the console software, really. It's calling the PALcode. There is a standard PALcode operations called `swppal' which enables you do switch to a different PALcode image on the fly (the NetBSD/alpha boot loader does this; SRM comes up in the OpenVMS PALcode by default). However, the PALcode is called literally all the time. Take a NetBSD kernel image sometime, pump it though objdump --disassemble, and grep for the "call_pal" instruction: bishop:thorpej 53$ pwd /sys/arch/alpha/compile/GENERIC bishop:thorpej 54$ objdump --disassemble netbsd | grep -c call_pal 4807 bishop:thorpej 55$ Some of those are in key places, like, for example, all traps (syscalls, interrupts, page faults, etc.). The C library uses it, too. It's how system calls are made (the `callsys' PALcode operation). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message