From owner-freebsd-alpha Sat Dec 4 18:33: 5 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from audrey.Ivy.NET (audrey.Ivy.NET [204.183.93.14]) by hub.freebsd.org (Postfix) with ESMTP id 53A69153AB for ; Sat, 4 Dec 1999 18:32:50 -0800 (PST) (envelope-from carton@Ivy.NET) Received: from localhost (localhost [[UNIX: localhost]]) by audrey.Ivy.NET (8.8.8/8.8.8) with ESMTP id CAA02248; Sun, 5 Dec 1999 02:31:58 GMT Date: Sat, 4 Dec 1999 19:31:57 -0700 (MST) From: Miles Nordin 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) In-Reply-To: <199912050003.TAA23976@ghost.whirlpool.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 4 Dec 1999, Andrew Gillham wrote: > Windows NT has PALcode embedded in it somehow? Windows NT has god only knows what embedded in it. We all know where Digital has been taking it from them since the beginning. Alpha's even have a PeeCee DRAM-refreshtimer-speakerbeeper in them, no? i'm feeling more wholesome not knowing what's going on inside that tent. not that anyone is offering to tell me. > "SRM is required for NetBSD/alpha" along the lines of "OpenFirmware > is required for NetBSD/macppc." (e.g. to boot and get started) notPC's don't use the same MAME-type arcade machine architecture as PC's. The OS generally stays on friendly terms with the firmware even after boot. This is good, because it allows some simple hardware abstraction to take place so that motherboards don't need to be pin-for-pin, trace-for-trace compatible with the golden original version of the Bionic Commando board or the PC XT or whatever video game you happen to be talking about. Supporting a chip or a chip family is good enough. The arcade machine philosophy is perhaps workable, for arcade machines. I've been harping about the PS2 recently. If you buy a Playstation, you know your small investment is protected for at least three or four years. Every Playstation sold in that release cycle will be basically identical, so you don't have to worry about Johnny down the street getting a faster Playstation than you, at least not for a while. Likewise, if your OS works on the first Playstation, it will almost certainly keep working for a few years without further attention. When a new one does come out, it will be a BFD, completely different, radical architecture changes, new CPU, require all new MD code. But working this way is outrageous when you're talking about $1000-$3000 machines that change just very, very slightly on a monthly basis like Alpha's, with a bunch of different CPU models and steppings and architecture codenames. If you expect your code to be the only code running in the system, you are doomed to the constant nuissance-level hacks that make good i386 support such a challenge--obscure tweaks to the OS to keep up with the latest buggy chipset used by some flash-in-the-pan Chineese Slave Labour motherboard manufacturer. That's what firmware is supposed to help. OS Q. Any SCSI stuff on this box? FW A. There is an ISP-ish chip. The ISP is a (Revision xxxxx), in case you care. It is attached (here.) It is initialized and ready for your use. as opposed to: /* probe for ISP */ [...] /* are we on ISA? */ [...] /* don't touch 0x224 with an 0x8a or an 0x9f, because it might be a soundblaster and lock up the bus */ [...] #if 1 /* clever hack from frightwig@eroticom.com */ [...] #endif #ifdef __i386__ /* workaround for 440BX bug */ [...] [...] [...] [...] [...] [...] [...] [...] #else /* Digital host bridge */ [...] #endif /* great! now, initialize the chip. */ #ifdef SUPPORT_ISP1040A [...] #else /* we are on a 1040B or later */ [...] #endif [...] [...] /* grrmph.. eh, nevermind. */ [...] [...] My understanding is obviously minimal--the other posts here suggest that the PALcode idea is a lot more complex and interesting than this. PC's keep trying to do something vaguely like Firmware, but from reading stuff on these lists it seems they still don't ``get it,'' and the BIOS people who keep trying are all fired as far as NetBSD is concerned. Thanks to NT the Alpha seems to have inherited some of this insanity. The people who wrote MILO _wanted_ an arcade machine, and refused to trust firmware, or even admit firmware's right to exist--which, is often the right way to deal with bugridden PeeCee nonsense, but the Alpha is hopefully not so badly off. > I said it was a stupid question. If it's so stupid, then why don't the Linux people understand it? MILO spawned a whole mess of its own--a dozen forks and branches and revisions, half of which violate the GPL, half of which don't work, and half of which disappear from the site the moment you realize you need them. Digital funded some development on it, which brought two branches and who knows how many revisions of broken video card BIOS x86-emulator code to the table. I remember at one point having three video cards (one of which counted for two, becuase it had a socketed ROM chip that I could remove, and this changed things a bit), three versions of MILO, SRM and ARC, and workingness defined as ``works in SRM, / works in MILO / works at kernel boot / works in X'' which gets you a 96-cell 4-dimensional matrix--i fell over laughing and plugged in a Mac SE serial console. MILO inspired the NILO project, the Overly Complex 256kB proposed Linux Netbooting Architecture complete with a scheduler and an interrupt handler, intended to replace the sprightly BSD netboot code they took from us. And then suddenly the ``firmware'' in the Corel Netwinder is a leprous Linux kernel, just like MILO. dumdumdum.Duh... MILO, strikes again. I tell you as one who used it--MILO is eeevil. Stay away from it. -- Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680 555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message