From owner-freebsd-hackers Wed Aug 13 10:13:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA13344 for hackers-outgoing; Wed, 13 Aug 1997 10:13:10 -0700 (PDT) Received: from smoke.marlboro.vt.us (smoke.marlboro.vt.us [198.206.215.91]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA13334 for ; Wed, 13 Aug 1997 10:12:59 -0700 (PDT) Received: (from cgull@localhost) by smoke.marlboro.vt.us (8.8.5/8.8.5/cgull) id NAA03925; Wed, 13 Aug 1997 13:12:41 -0400 (EDT) Date: Wed, 13 Aug 1997 13:12:41 -0400 (EDT) Message-Id: <199708131712.NAA03925@smoke.marlboro.vt.us> From: john hood MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="IfVSRq12y7" Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Ada T Lim , jamil@counterintelligence.ml.org (Jamil J. Weatherbee), freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD --- ALPHA In-Reply-To: <22390.871468993@time.cdrom.com> References: <199708130841.SAA13894@polya.blah.org> <22390.871468993@time.cdrom.com> X-Mailer: VM 6.31 under Emacs 19.34.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk --IfVSRq12y7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jordan K. Hubbard writes: > Naw, it's probably just a standard alpha motherboard and CPU with the > SRM console instead of the ARC console code. That's another IBU > within DEC and they have their own little surcharges for using SRM > which get passed on to the consumer. > > Jordan There are actually different parts available from the semiconductor folks, one which is subtly munged in its MMU so that it cannot run OSF/1 (or SRM, I don't know which). Here's a message body out of one of the linux mailing lists-- sorry about the lack of headers, it came out of some modestly-evil WWW search UI. --jh -- John Hood cgull@smoke.marlboro.vt.us Predictably, they all eventually wandered away, rubbing their bruises and brushing mud out of their hair. Some went off to work for the ESA, launching much smaller rockets into low orbits, while others elected to sit on their front porches drinking Jim Beam from the bottle and launching bottle rockets from the empties. [Jordan Hubbard] --IfVSRq12y7 Content-Type: text/plain; charset=us-ascii Content-Description: goo from the dark side Content-Disposition: inline; filename="include.txt" Content-Transfer-Encoding: 7bit On Tue, 20 Feb 1996, David Mosberger wrote: > As long as it's capable of running Linux, most people probably won't > have a problem with this, if it means cheaper machines. However, is > this different behavior *documented* someplace? I'd really hate > spending hours debugging something that just doesn't work according to > specs. If the hw ref manuals are accurate all is fine. Otherwise, I > might just as well buy an x86. Intel has a real good history of not > documenting chip features (at least not without NDA). I hope Digital > is not following the same path. And Erik wrote: >>Last thing I heard, none of these crippled chips have actually been >>manufactured yet. Jim Paradis knows all about this stuff though... care >>to speak up Jim? >>Erik The 'crippled' versions have a -Pn suffix (for various integer n) and the difference in behaviour is documented in the IPR chapter of the HRM, rev C (EC-QAEQC-TE) and later (I expect it is also documented elsewhere). This change is not (nor is it intended to be) a hidden, undocumented feature. The reason for its introduction is a reflection of the way that businesses are organised (and therefore revenue channelled) within Digital. That's beyond the scope of this discussion (no flames, please). To repeat: behaviour of -Pn versions is INDETERMINATE if you try to run the SRM, OpenVMS and Digital Unix. What that means is that it may work or it may not work. This gives us (Digital) the ability to sell identical chips or chips that have had the documented features disabled. Today, the chips are identical. Tomorrow (and particularly with the introduction of the 21164A) that may not be the case. The two features that are (maybe) disabled in the -Pn versions are: 1) SPE[0] must always be SET in ICSR (Ibox csr) 2) SP[0] must always be SET in the MCSR (Mbox CSR). These features control one of the superpage mappings. It is a static configuration that is performed during initialisation. My job is to provide factory apps. support for customers who design with Digital's silicon so I guess, on this one, I speak for Digital. regards, Neal. ---------------------------------------------------------------------- Neal Crook Principal Engineer, European Semiconductor Applications Engineering Digital Equipment Co. LTD EMAIL neal.crook@reo.mts.dec.com Mailstop RE02-F/B3 Tel. +44 1734 206297 Digital Park FAX +44 1734 203133 Imperial Way, Reading, RG2 0TU ENGLAND ---------------------------------------------------------------------- ---------------------------------oOOo--------------------------------- --IfVSRq12y7--