From owner-freebsd-alpha Sun Jan 9 14:19:52 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.cybcon.com (mail.cybcon.com [216.190.188.5]) by hub.freebsd.org (Postfix) with ESMTP id 666EE14CC5; Sun, 9 Jan 2000 14:19:42 -0800 (PST) (envelope-from freebsd@cybcon.com) Received: from laptop.cybcon.com (william@pm3b-13.cybcon.com [205.147.75.78]) by mail.cybcon.com (8.9.3/8.9.3) with ESMTP id OAA25475; Sun, 9 Jan 2000 14:19:34 -0800 (PST) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 09 Jan 2000 14:20:51 -0800 (PST) From: William Woods To: freebsd-current@freebsd.org, freebsd-alpha@freebsd.org Subject: PPP connections die in current.... Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Running 4.0 -current as of today.....on a DEC Alphaststion 233 when I dial out I connect for about 30 seconds then it dies...here is a copy of the ppp.log Jan 9 22:00:27 alpha ppp[388]: Phase: Using interface: tun0 Jan 9 22:00:27 alpha ppp[388]: Phase: deflink: Created in closed state Jan 9 22:00:27 alpha ppp[388]: tun0: Command: default: set device /dev/cuaa1 Jan 9 22:00:27 alpha ppp[388]: tun0: Command: default: set speed 57600 Jan 9 22:00:27 alpha ppp[388]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jan 9 22:00:27 alpha ppp[388]: tun0: Phase: PPP Started (interactive mode). Jan 9 22:00:33 alpha ppp[388]: tun0: Command: /dev/tty: dial cybcon Jan 9 22:00:33 alpha ppp[388]: tun0: Command: cybcon: set phone 5039721667:5039721668 Jan 9 22:00:33 alpha ppp[388]: tun0: Command: cybcon: set login ABORT NO\sCARRIER TIMEOUT 5 ogin:--ogin: Pxxxxx word: xxxxxxxxxx Jan 9 22:00:33 alpha ppp[388]: tun0: Command: cybcon: set timeout 300 Jan 9 22:00:33 alpha ppp[388]: tun0: Command: cybcon: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jan 9 22:00:33 alpha ppp[388]: tun0: Command: cybcon: add default HISADDR Jan 9 22:00:33 alpha ppp[388]: tun0: Warning: Add route failed: default already exists Jan 9 22:00:33 alpha ppp[388]: tun0: Command: cybcon: enable dns Jan 9 22:00:33 alpha ppp[388]: tun0: Phase: bundle: Establish Jan 9 22:00:33 alpha ppp[388]: tun0: Phase: deflink: closed -> opening Jan 9 22:00:33 alpha ppp[388]: tun0: Phase: deflink: Connected! Jan 9 22:00:33 alpha ppp[388]: tun0: Phase: deflink: opening -> dial Jan 9 22:00:33 alpha ppp[388]: tun0: Phase: Phone: 5039721667 Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: deflink: Dial attempt 1 of 1 Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Send: AT^M Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Expect(5): OK Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Received: AT^M^M Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Received: OK^M Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Send: ATE1Q0^M Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Expect(5): OK Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Received: ATE1Q0^M^M Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Received: OK^M Jan 9 22:00:33 alpha ppp[388]: tun0: Chat: Send: ATDT5039721667^M Jan 9 22:00:35 alpha ppp[388]: tun0: Chat: Expect(40): CONNECT Jan 9 22:01:00 alpha ppp[388]: tun0: Chat: Received: ATDT5039721667^M^M Jan 9 22:01:00 alpha ppp[388]: tun0: Chat: Received: CONNECT Jan 9 22:01:00 alpha ppp[388]: tun0: Phase: deflink: dial -> carrier Jan 9 22:01:01 alpha ppp[388]: tun0: Phase: deflink: /dev/cuaa1: CD detected Jan 9 22:01:01 alpha ppp[388]: tun0: Phase: deflink: carrier -> login Jan 9 22:01:01 alpha ppp[388]: tun0: Chat: Expect(5): ogin: Jan 9 22:01:01 alpha ppp[388]: tun0: Chat: Received: 44000 V42bis^M Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Received: Welcome to CyberConnectics (Portland Server)^M Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Received: ^M Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Received: ^M Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Received: login: Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Send: Pwwoods^M Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Expect(5): word: Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Received: Pwwoods^M Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Received: Password: Jan 9 22:01:02 alpha ppp[388]: tun0: Chat: Send: dataf^M Jan 9 22:01:02 alpha ppp[388]: tun0: Phase: deflink: login -> lcp Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: FSM: Using "deflink" as a transport Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: State change Initial --> Closed Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: State change Closed --> Stopped Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: RecvConfigReq(1) state = Stopped Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x3dec7f94 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: SendConfigAck(1) state = Stopped Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: LayerStart Jan 9 22:01:02 alpha ppp[388]: tun0: LCP: deflink: State change Stopped --> Ack-Sent Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: deflink: RecvConfigReq(2) state = Ack-Sent Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: deflink: SendConfigAck(2) state = Ack-Sent Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: deflink: SendConfigReq(1) state = Ack-Sent Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:05 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x3dec7f94 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: deflink: RecvConfigReq(3) state = Ack-Sent Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: deflink: SendConfigAck(3) state = Ack-Sent Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: deflink: SendConfigReq(1) state = Ack-Sent Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:08 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x3dec7f94 Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: deflink: RecvConfigReq(4) state = Ack-Sent Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: deflink: SendConfigAck(4) state = Ack-Sent Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:11 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:12 alpha ppp[388]: tun0: LCP: deflink: SendConfigReq(1) state = Ack-Sent Jan 9 22:01:12 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:12 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:12 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:12 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:12 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x3dec7f94 Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: deflink: RecvConfigReq(5) state = Ack-Sent Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: deflink: SendConfigAck(5) state = Ack-Sent Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:14 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:15 alpha ppp[388]: tun0: LCP: deflink: SendConfigReq(1) state = Ack-Sent Jan 9 22:01:15 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:15 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:15 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:15 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:15 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x3dec7f94 Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: deflink: RecvConfigReq(6) state = Ack-Sent Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: deflink: SendConfigAck(6) state = Ack-Sent Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: MRU[4] 1500 Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: ACCMAP[6] 0x00000000 Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: MAGICNUM[6] 0x4a62ddbf Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: PROTOCOMP[2] Jan 9 22:01:17 alpha ppp[388]: tun0: LCP: ACFCOMP[2] Jan 9 22:01:18 alpha ppp[388]: tun0: LCP: deflink: LayerFinish Jan 9 22:01:18 alpha ppp[388]: tun0: LCP: deflink: State change Ack-Sent --> Stopped Jan 9 22:01:18 alpha ppp[388]: tun0: LCP: deflink: State change Stopped --> Closed Jan 9 22:01:18 alpha ppp[388]: tun0: LCP: deflink: State change Closed --> Initial Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: deflink: Disconnected! Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: deflink: lcp -> logout Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: deflink: logout -> hangup Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: deflink: Disconnected! Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: deflink: Connect time: 45 secs: 378 octets in, 577 octets out Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: total 21 bytes/sec, peak 76 bytes/sec on Sun Jan 9 22:01:18 2000 Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: deflink: hangup -> closed Jan 9 22:01:18 alpha ppp[388]: tun0: Phase: bundle: Dead Jan 9 22:01:39 alpha ppp[388]: tun0: Command: /dev/tty: quit all Jan 9 22:01:39 alpha ppp[388]: tun0: Phase: PPP Terminated (normal). ---------------------------------- E-Mail: William Woods Date: 09-Jan-00 Time: 14:17:46 FreeBSD 3.4 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 10 5:42:17 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id EAAED15C82; Mon, 10 Jan 2000 05:36:50 -0800 (PST) (envelope-from phantom@FreeBSD.org) Received: (from phantom@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA07982; Mon, 10 Jan 2000 05:36:50 -0800 (PST) (envelope-from phantom@FreeBSD.org) Date: Mon, 10 Jan 2000 05:36:50 -0800 (PST) From: Message-Id: <200001101336.FAA07982@freefall.freebsd.org> To: phantom@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Re: conf/12832: config -g creates broken Makefile in 3.2-STABLE/alpha Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: config -g creates broken Makefile in 3.2-STABLE/alpha Responsible-Changed-From-To: freebsd-bugs->freebsd-alpha Responsible-Changed-By: phantom Responsible-Changed-When: Mon Jan 10 05:35:36 PST 2000 Responsible-Changed-Why: Alpha related problem To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 10 12: 7:47 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from noc.nyx.net (noc.nyx.net [206.124.29.3]) by hub.freebsd.org (Postfix) with ESMTP id 6664615337 for ; Mon, 10 Jan 2000 12:07:45 -0800 (PST) (envelope-from amunkres@nyx.net) Received: from nyx.nyx.net (amunkres@nyx.nyx.net [206.124.29.1]) by noc.nyx.net (8.9.1a+3.1W/8.9.1/esr) with ESMTP id NAA15170 for ; Mon, 10 Jan 2000 13:07:40 -0700 (MST) Received: from localhost (amunkres@localhost) by nyx.nyx.net (8.8.8/8.8.8/esr) with SMTP id NAA25287 for ; Mon, 10 Jan 2000 13:07:38 -0700 (MST) X-Nyx-Envelope-Data: Date=Mon Jan 10 13:07:38 2000, Sender=amunkres@nyx.net, Recipient=, Valsender=amunkres@localhost Date: Mon, 10 Jan 2000 13:07:37 -0700 (MST) From: Andrew Munkres To: freebsd-alpha@freebsd.org Subject: Re: 56k external modem on an Alpha...... In-Reply-To: <200001100604.QAA13397@gw.one.com.au> 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 Mon, 10 Jan 2000, User Raymond wrote: > To: amunkres@nyx.net > > > My computer is a PC164LX with 2 serial ports running 3.4-RELEASE. It > > displays the following message when booting: > > > > sio1: reserved for low-level i/o > > > > When I try to start ppp, it says: > > > > Warning: deflink: /dev/cuaa1: Bad file descriptor > > Failed to open /dev/cuaa1 > > Try /dev/cuaa0 That works, but there are overflows because /dev/cuaa0 is the first serial port. > > In the SRM, typing show config shows that COM2 is enabled. How can I get > > FreeBSD to make sio1 available for the modem? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 11 11:40:31 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 626FC15030 for ; Tue, 11 Jan 2000 11:40:26 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id OAA29475; Tue, 11 Jan 2000 14:40:25 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id OAA83318; Tue, 11 Jan 2000 14:39:54 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Jan 2000 14:39:53 -0500 (EST) To: Wilko Bulte Cc: freebsd-alpha@freebsd.org Subject: options EV4 (was Re: EV6) In-Reply-To: <20000111203251.A1527@yedi.iaf.nl> References: <20000111203251.A1527@yedi.iaf.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14459.34395.58995.497093@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > Sorry to bother you again: > > We have EV4 & EV5 in the alpha kernel config file. But no EV6 > > Why? I've never knew why EV4 & EV5 are there in the first place & that's why I never added an EV6 when I did the st6600 support. Those #defines don't seem to be used anywhere in sys/alpha outside the sys/alpah/conf. Does anybody know what they are for? Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 11 18:31:39 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from awfulhak.org (dynamic-104.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.232]) by hub.freebsd.org (Postfix) with ESMTP id 1452814D88; Tue, 11 Jan 2000 18:31:27 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA34151; Wed, 12 Jan 2000 00:59:37 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id UAA48886; Tue, 11 Jan 2000 20:50:56 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200001112050.UAA48886@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: William Woods Cc: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: PPP connections die in current.... In-Reply-To: Message from William Woods of "Sun, 09 Jan 2000 14:20:51 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jan 2000 20:50:56 +0000 From: Brian Somers Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Running 4.0 -current as of today.....on a DEC Alphaststion 233 when I dial out > I connect for about 30 seconds then it dies...here is a copy of the ppp.log [.....] Well, you're receiving data from the peer, but the peer is not sending any response to your config request. From what I can see, ppp is behaving exactly right. I have no idea what your ISP is expecting - he's sending exactly the same REQ as you are. You could try ``set accmap 000a0000'', but I'll bet it won't help. I think you're stuck with asking your ISP to tell you what their side thinks it's doing. You could also try ``set log +physical'' to see if anything funny is being read from the device and dropped, but again I expect nada :-( > ---------------------------------- > E-Mail: William Woods > Date: 09-Jan-00 > Time: 14:17:46 > FreeBSD 3.4 > ---------------------------------- -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 11 18:38: 2 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.theinternet.com.au (zeus.theinternet.com.au [203.34.176.2]) by hub.freebsd.org (Postfix) with ESMTP id 9A5E614F2D; Tue, 11 Jan 2000 18:37:36 -0800 (PST) (envelope-from akm@mail.theinternet.com.au) Received: (from akm@localhost) by mail.theinternet.com.au (8.9.3/8.9.3) id MAA77235; Wed, 12 Jan 2000 12:38:13 +1000 (EST) (envelope-from akm) From: Andrew Kenneth Milton Message-Id: <200001120238.MAA77235@mail.theinternet.com.au> Subject: Re: PPP connections die in current.... In-Reply-To: <200001112050.UAA48886@hak.lan.Awfulhak.org> from Brian Somers at "Jan 11, 2000 8:50:56 pm" To: brian@Awfulhak.org (Brian Somers) Date: Wed, 12 Jan 2000 12:38:13 +1000 (EST) Cc: freebsd@cybcon.com, freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, brian@hak.lan.Awfulhak.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org +----[ Brian Somers ]--------------------------------------------- | > Running 4.0 -current as of today.....on a DEC Alphaststion 233 when I dial out | > I connect for about 30 seconds then it dies...here is a copy of the ppp.log | [.....] | | Well, you're receiving data from the peer, but the peer is not | sending any response to your config request. From what I can see, | ppp is behaving exactly right. | | I have no idea what your ISP is expecting - he's sending exactly the | same REQ as you are. | | You could try ``set accmap 000a0000'', but I'll bet it won't help. I | think you're stuck with asking your ISP to tell you what their side | thinks it's doing. You could also try ``set log +physical'' to see | if anything funny is being read from the device and dropped, but | again I expect nada :-( Try disabling compression. I've seen this before also, when ppp was trying to talk to pppd. I think it's specifically related to DEFLATE compression, it was a while ago now that I saw it. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 11 18:42: 8 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from awfulhak.org (dynamic-104.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.232]) by hub.freebsd.org (Postfix) with ESMTP id CEF1C154AB; Tue, 11 Jan 2000 18:41:49 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id CAA34696; Wed, 12 Jan 2000 02:41:43 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id CAA06239; Wed, 12 Jan 2000 02:45:51 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200001120245.CAA06239@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Andrew Kenneth Milton Cc: brian@Awfulhak.org (Brian Somers), freebsd@cybcon.com, freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, brian@hak.lan.Awfulhak.org, brian@hak.lan.Awfulhak.org Subject: Re: PPP connections die in current.... In-Reply-To: Message from Andrew Kenneth Milton of "Wed, 12 Jan 2000 12:38:13 +1000." <200001120238.MAA77235@mail.theinternet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2000 02:45:51 +0000 From: Brian Somers Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > +----[ Brian Somers ]--------------------------------------------- > | > Running 4.0 -current as of today.....on a DEC Alphaststion 233 when I dial out > | > I connect for about 30 seconds then it dies...here is a copy of the ppp.log > | [.....] > | > | Well, you're receiving data from the peer, but the peer is not > | sending any response to your config request. From what I can see, > | ppp is behaving exactly right. > | > | I have no idea what your ISP is expecting - he's sending exactly the > | same REQ as you are. > | > | You could try ``set accmap 000a0000'', but I'll bet it won't help. I > | think you're stuck with asking your ISP to tell you what their side > | thinks it's doing. You could also try ``set log +physical'' to see > | if anything funny is being read from the device and dropped, but > | again I expect nada :-( > > Try disabling compression. I've seen this before also, when ppp was > trying to talk to pppd. > > I think it's specifically related to DEFLATE compression, it was a while > ago now that I saw it. Compression hasn't yet been negotiated. No compression takes place on these initial LCP packets. > -- > Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton > The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | > ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon > PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 11 20:48:16 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.cybcon.com (mail.cybcon.com [216.190.188.5]) by hub.freebsd.org (Postfix) with ESMTP id 70EFA14F7E; Tue, 11 Jan 2000 20:48:11 -0800 (PST) (envelope-from freebsd@cybcon.com) Received: from laptop.cybcon.com (william@pm3a-14.cybcon.com [205.147.75.143]) by mail.cybcon.com (8.9.3/8.9.3) with ESMTP id UAA25374; Tue, 11 Jan 2000 20:46:55 -0800 (PST) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200001120238.MAA77235@mail.theinternet.com.au> Date: Tue, 11 Jan 2000 20:48:36 -0800 (PST) From: William Woods To: Andrew Kenneth Milton Subject: Re: PPP connections die in current.... Cc: brian@hak.lan.Awfulhak.org, freebsd-alpha@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, (Brian Somers) Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How do I disable compression On 12-Jan-00 Andrew Kenneth Milton wrote: > +----[ Brian Somers ]--------------------------------------------- >| > Running 4.0 -current as of today.....on a DEC Alphaststion 233 when I dial >| > out >| > I connect for about 30 seconds then it dies...here is a copy of the >| > ppp.log >| [.....] >| >| Well, you're receiving data from the peer, but the peer is not >| sending any response to your config request. From what I can see, >| ppp is behaving exactly right. >| >| I have no idea what your ISP is expecting - he's sending exactly the >| same REQ as you are. >| >| You could try ``set accmap 000a0000'', but I'll bet it won't help. I >| think you're stuck with asking your ISP to tell you what their side >| thinks it's doing. You could also try ``set log +physical'' to see >| if anything funny is being read from the device and dropped, but >| again I expect nada :-( > > Try disabling compression. I've seen this before also, when ppp was > trying to talk to pppd. > > I think it's specifically related to DEFLATE compression, it was a while > ago now that I saw it. > > -- > Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton > The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | > ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon > PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message ---------------------------------- E-Mail: William Woods Date: 11-Jan-00 Time: 20:47:43 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 11 23:48:58 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id CF79114D71 for ; Tue, 11 Jan 2000 23:48:43 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA32006 for freebsd-alpha@freebsd.org; Wed, 12 Jan 2000 08:36:41 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id IAA53709 for freebsd-alpha@freebsd.org; Wed, 12 Jan 2000 08:40:13 +0100 (CET) (envelope-from wilko) Date: Wed, 12 Jan 2000 08:40:13 +0100 From: Wilko Bulte To: FreeBSD-alpha mailing list Subject: current shot at AlphaHW.txt Message-ID: <20000112084013.A53647@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As I have received some requests to see the latest version of the AlphaHW.txt that I'm working on: here it is. This is very much work in progress, please comment on any errors. Special attention please for +++ marked parts. FreeBSD/alpha Hardware Information ================================== This file is maintained by Wilko Bulte Additions, corrections and constructive criticism are invited. In particular information on system quirks is more than welcome. This file is a continuous work-in-progress. Wed Jan 12 08:37:51 CET 2000 ( +++ notes attention points or open issues. Please comment on those ) Scope ----- This document tries to provide a starting point for those who want to start running FreeBSD on an Alpha-based machine. It is aimed at providing background information on the various hardware designs. It is not a replacement for the system's manuals. Per system type that FreeBSD/alpha supports you will find a section that briefly describes the system, and, more importantly, provides information on the particulars/quirks of a system model. In general, what do you need to run FreeBSD/alpha? -------------------------------------------------- Obviously you will need an Alpha machine that FreeBSD/alpha knows about. Alpha machines are NOT PC-architectures. There are considerable differences between the various chipsets and mainboard designs. This means that a kernel needs to know the intimate details of a particular machine before it can run on it. Throwing some odd GENERIC kernel at unknown hardware is almost guaranteed to fail miserably. For a machine even to be considered for FreeBSD use please make sure it has the SRM console firmware installed. Or at least make sure that SRM console firmware is available for this particular model. If FreeBSD does not currently support your machine type, there is a good chance that this will change some time, assuming there is a SRM available. Machines with the ARC/AlphaBIOS console firmware are intended for WindowsNT. Some of them have SRM firmware available in the system ROMs which you only have to select (via an ARC/AlphaBIOS menu). In other cases you will have to re-flash the ROMs with SRM code. Check on http://ftp.digital.com/pub/DEC/Alpha/firmware to see what is available for your particular system. In any case: no SRM -> no FreeBSD (or NetBSD, OpenBSD, Tru64 Unix or OpenVMS for that matter). As part of the SRM you will get the so called OSF/1 PAL code (OSF/1 being the initial name of DEC's Unix offering on Alpha). The PAL code can be thought of as a software abstraction layer between the hardware and the operating system. It uses normal CPU instruction plus a handful of priviliged instructions specific for PAL use. PAL is not microcode by the way. The ARC firmware contains a different PAL code, geared towards WinNT and in no way suitable for use by FreeBSD (or more generic: Unix or OpenVMS). Before someone asks: AlphaLinux brings it's own PAL code, allowing it to boot. There are various reasons why this is not a very good idea in the eyes of the *BSD folks. I don't want to go into details here. There is another pitfall ahead: you will need a disk adapter that the SRM console recognises in order to be able to boot from your disk. For PCI SCSI this means you will need either a NCR/Symbios 810 based adapter, or a Qlogic 1020/1040 based adapter. Some machines come with a SCSI chip embedded on the mainboard. Newer machine designs and SRM versions will be able to work with later SCSI chips/adapters. This problem might bite those who have machines that started their lives as WinNT boxes. The ARC/AlphaBIOS knows about *other* adapter types that it can boot from than the SRM. For example you can boot from an Adaptec 2940UW with ARC but not with SRM. Some adapters that cannot be booted from work fine for data-only disks (e.g. Adaptec 2940x boards). The differences between SRM and ARC could also get you pre-packaged IDE CDROMs and harddrives in some (former NT) systems. SRM versions versions exist (depends on the mainboard) that can also boot from IDE disks. Again, this is system dependent. +++ As I'm a SCSI-only guy I invite comments on how well IDE works on +++ the various systems. Alpha machines can be run with SRM on a graphics console or on a serial console. ARC does not like serial consoles. If you want to run your Alpha without a monitor/graphics card just don't connect a keyboard/mouse to the machine. Instead hook up a serial terminal[emulator] to serial port #1. The SRM will talk 9600N81 to you. This is really practical for debugging purposes. Most PCI based Alphas can use ordinary PC-type VGA cards. The SRM contains enough smarts to make that work. It does not, however, mean that each and every PCI VGA card out on the street will work in an Alpha machine. Things like S3 Trio64 generally work. But ask around first before buying. Most PCI devices from the PC-world will also work in FreeBSD/alpha PCI-based machines. Check the /sys/alpha/conf/GENERIC file for the latest word on this. For now all parallel ports do not work on FreeBSD/alpha. The driver needs work to make this happen. For Alpha CPUs you will find multiple versions. The original Alpha design is the 21064. It was produced in a chip baking process called MOS4, chips made in this process are nicknamed EV4. Newer CPUs are 21164, 21264 etc. You will see designations like EV4S, EV45, EV5, EV56, EV6, EV67. The higher the EV number the more desirable (read: faster / more modern). For memory you want at least 32 Mbytes. I have had FreeBSD/alpha run on a 16 Mbyte system but you will not like that. Kernel build times halved when going to 32 Mbytes. Note that the SRM steals 2Mbyte from the total system memory (and keeps it). For more serious use >= 64Mbyte is recommended. Final word: I expect the above to sound a bit daunting to the first-time Alpha user. Don't be daunted too much. And feel free to ask questions. Model specific information -------------------------- Below is an overview of the hardware that FreeBSD/alpha is capable of running on. This list is bound to grow, a look in /sys/alpha/conf/GENERIC can be enlightening. Alpha machines are often best known by their project codename, these are listed below in (). * * AXPpci33 ("NoName") * The NoName is a baby-AT mainboard based on the 21066 LCA (Low Cost Alpha) processor. It was originally designed for OEM-use. The LCA chip includes almost all of the logic to drive a PCI bus. This makes for a low-priced design. Due to the limited memory interface the system is not particularly fast in case of cache misses. As long as you stay inside the on-chip cache the CPU is comparable to a 21064 (first generation Alpha) These boards should be very cheap to obtain these days (even here in the Netherlands they were sold new for US$ 25). Features: - 21066 Alpha CPU at 166/233MHz (21068 CPUs are also possible, but are even slower. Never seen/used one) - memory bus: 64 bits - onboard Bcache / L2 cache: 0, 256k or 1Mbyte (uses DIL chips) - PS/2 mouse & keyboard port OR 5pin DIN keyboard (2 mainboard models) - memory: PS/2 style 72 pin 36 bit Fast Page Mode SIMMs, 70ns or better, installed in pairs of 2, 4 SIMM sockets uses ECC - 512kB FlashROM for the console code. - 2x 16550A serial ports, 1x parallel port, floppy interface - 1x embedded IDE interface - expansion: 3 32 bit PCI slots (1 shared with ISA) 5 ISA slots (1 shared with PCI) - embedded FastSCSI using an NCR/Symbios 810 chip SRM: NoName's can either have SRM *or* ARC console firmware in their FlashROM. The FlashROM is not big enough to hold both ARC and SRM at the same time and allow software selection of alternate console code. But you need SRM only anyway. Cache: Cache for the NoNames are 15 or 20ns DIL chips. For a 256kByte cache you want to check your junked 486 mainboard. Chips for a 1Mbyte cache are a rare breed unfortunately. Getting at least a 256kByte cache is recommended performance wise. Cacheless they are really slow. Power: The NoName mainboard has a PC/AT-standard power connector. It also has a power connector for 3.3 Volts. No need to rush out to get a new power supply. The 3.3 Volts is only needed in case you run 3.3 Volts PCI expansion boards. IDE: SRM presumably cannot boot from IDE disks (have never tried this myself) Memory: Make sure you use true 36 bit SIMMs, and only FPM (Fast Page Mode). EDO RAM or SIMMs with fake parity *will not work* (the board uses the 4 extra bits for ECC!). 33 bit SIMMs will for the same reason not work either. Using a wrong memory type is the #1 problem that people encounter with NoNames. Keyboard/mouse: Given the choice, get the PS/2-variant mainboard. Apart from giving you a mouse port as bonus it is directly supported by Tru64 Unix in case you ever want/need to run it. The "DIN-plug"-variant should work OK for FreeBSD. The OEM manual is recommended reading. If you did not get one with your system/board send me email, I have a Postscript copy. The kernel configuration file for a NoName kernel must contain: options DEC_AXPPCI_33 * * Universal Desktop Box (UDB or "Multia") * Note: Multia can be either Intel or Alpha CPU based. We assume Alpha based Multias here for obvious reasons. Multia is a very compact 21066 based box, rougly 40cm square and 8 cm thick. It has a small 2.5" SCSI disk of 300Mbyte or so. Fortunately there is an external high density 50pin SCSI connector. It has an embedded 10Mbit Ethernet interface. There is only one PCI slot for expansion, and only for a small PCI card too. The socketed CPU is either 166 or 233 MHz. It comes with a TGA based graphics onboard. The 3.5" floppy drive is a very compact laptop variant. Note: Most the discussion of the NoName applies to Multia too. Hot: Multias are somewhat notorious for dying of heat strokes. The very compact box does not really allow cooling air access very well. Please use the Multia on it's vertical stand, don't put it horizontally ('pizza style'). Replacing the fan with something which pushes around more air is recommended. SCSI: In case you want to change the internal harddrive: the internal flatcable running from the PCI riserboard to the 2.5" (!!) harddrive has a finer pitch than the standard SCSI flatcables. Otherwise it would not fit on the 2.5" drives. I recommend against trying to cram another harddisk inside. Use the external SCSI connector and put your disk in an external enclosure. The kernel configuration file for a Multia kernel must contain: options DEC_AXPPCI_33 * * Personal Workstation ("Miata") * The Miata is a small tower machine intended to be put under a desk. There are multiple Miata variants. The original Miata is the MX5 model. Because it suffers from a number of hardware design flaws an ECO was performed, yielding the MiataGL. Unfortunately the boxes are identical for both variants. An easy check if to see if the back of the machine sports two USB connectors. If yes, it is a MiataGL. System designations look like "Personal Workstation 433a". This means it has a 433 MHz CPU, and started life as a WinNT workstation (the trailing 'a'). Systems designated from day 1 to run Tru64 Unix or OpenVMS will sport '433au'. WinNT-Miata's are likely to come pre-configured with an IDE CDROM drive. Features: - 21164A EV56 Alpha CPU, at 433, 500 or 600MHz - 21174 Core Logic ("Pyxis") chipset - onboard Bcache / L3 cache: 0, 2, 4Mbyte (uses a cache module) - memory bus: 128 bits wide, ECC protected - memory: Miata uses unbuffered SDRAMs, installed in pairs of 2 - onboard Fast Ethernet, the bulkhead can be 10/100 UTP, or 10 UTP/BNC (MX5 uses a 21142 or 21143 ethernetchip dependent on the version of the PCI riser card, MiataGL has a 21143 chip) - 2x onboard [E]IDE (MX5: CMD 646, MiataGL: Cypress 82C693) - 1x UltraWide SCSI Qlogic 1040 [MiataGL only] - expansion: 2 64-bit PCI slots 3 32-bit PCI slots (behind a DEC PCI-PCI bridge chip) 3 ISA slots (physically shared with the 32 bit PCI slots, via a Intel 82378IB PCI to ISA bridge chip) - 2x 16550A serial port - 1x parallel port +++ reviewers, does FreeBSD/alpha support parallel ports? - PS/2 keyboard & mouse port - USB interface [MiataGL only] - embedded sound based on a ESS1888 chip CPU mainboard and PCI 'riser' board: the Miata is divided into two printed circuit boards. The lower board in the bottom of the machine has the PCI and ISA slots and things like the sound chip etc. The top board has the CPU, the Pyxis chip, memory etc. Note that MX5 and the MiataGL use a different PCI riser board. This means that you cannot just upgrade to a MiataGL CPU board (with the newer Pyxis chip) but that you will also need a different riser board. Apparantly an MX5 riser with a MiataGL CPU board will work but it is definitely not a supported or tested configuration. Everything else (cabinet, wiring etc etc) is identical for MX5 and MiataGL. DMA bug: MX5 has problems with DMA via the 2 64-bit PCI slots when this DMA crosses a page boundary. The 32bit slots don't have this problem because the PCI-PCI bridge chip does not allow the offending transfers. The SRM code knows about the problem and refuses to start the system if there is a PCI card in one of the 64bit slots that it does not know about. Cards that are 'known good' to the SRM are allowed to be used in the 64bit slots. If you want to fool the SRM you can type "set pci_device_override" at the >>> SRM prompt. Don't complain if your data mysteriously gets mangled. The complete command is: set pci_device_override e.g. set pci_device_override 88c15333 The kernel reports it when it sees a buggy Pyxis chip: Sep 16 18:39:43 miata /kernel: cia0: Pyxis, pass 1 Sep 16 18:39:43 miata /kernel: cia0: extended capabilities: 1 Sep 16 18:39:43 miata /kernel: cia0: WARNING: Pyxis pass 1 DMA bug; no bets... A MiataGL probes as: Jan 3 12:22:32 miata /kernel: cia0: Pyxis, pass 1 Jan 3 12:22:32 miata /kernel: cia0: extended capabilities: 1 Jan 3 12:22:32 miata /kernel: pcib0: <2117x PCI host bus adapter> on cia0 MiataGL does not have the DMA problems of the MX5. PCI cards that make the MX5 SRM choke when installed in the 64bit slots are accepted without problems by the MiataGL SRM. The latest mainboard revisions of MX5 contain a hardware workaround for the bug. The SRM does not know about the ECO and will complain about unknown cards just like before. The same applies to the FreeBSD kernel by the way. IDE: The Miata SRM can boot from IDE CDROM drives. I am not sure if this also applies to harddisks +++ reviewers? PCI-PCI bridge: The MiataGL has a faster PCI-PCI bridge chip on the PCI riser card than some of the MX5 riser card versions. Some of the MX5 risers have the *same* chip as the MiataGL (are you still with me? ;-) Sound: both MX5 and MiataGL have an onboard sound chip, an ESS1888. I have yet to see/hear it work on my MiataGL. Cache: when your Miata has an optional cache board installed make sure it is firmly seated. A slightly loose cache has been observed to cause weird crashes (not surprising obviously, but maybe not so obvious when troubleshooting). Cache is identical between MX5 and MiataGL. Installing a cache module achieves, apart from a 10-15% speed increase (based on buildworld elapsed time), a *decrease* for PCI DMA read bandwith from 64bit PCI cards. A benchmark on a 64-bit Myrinet card resulted in a decrease from 149 Mb/sec to 115 Mb/sec. Something to keep in mind when doing really high speed things with 64 bit PCI adapters. USB: Does not currently seem to work on FreeBSD/alpha. +++ The kernel configuration file for a Miata kernel must contain: options DEC_ST550 * * DEC3000 family (the "Bird" machines) * The DEC3000 series were among the first Alpha machines ever produced. They are based on an I/O bus called the TurboChannel (TC) bus. These machines are built like tanks (watch your back). DEC3000 can be subdivided in DEC3000/500-class and DEC3000/300-class. The DEC3000/500-class is the early high-end workstation/server Alpha family. Servers use serial consoles, workstations have graphics tubes. DEC3000/300-class is the lower-cost workstation class. DEC3000/500-class are quite fast (considering their age) thanks to the good memory design. DEC3000/300 is crippled compared to DEC3000/500 because of it's much narrower memory bus. They are called 'Birds' because their internal DEC codenames were bird names: DEC3000/400 'Sandpiper' 133MHz CPU, desktop DEC3000/500 'Flamingo' 150MHz CPU, floorstanding DEC3000/500X 'Hot Pink' 200MHz CPU, floorstanding DEC3000/600 +++ 175MHz CPU, desktop DEC3000/700, +++ 225MHz CPU, floorstanding DEC3000/800, +++ 200MHz CPU, floorstanding DEC3000/900, +++ 275MHz CPU, floorstanding DEC3000/300 'Pelican' 150MHz CPU, desktop, 2 TC slots DEC3000/300X 175MHz CPU, desktop, 2 TC slots DEC3000/300LX 125MHz CPU, desktop, 2 TC slots DEC3000/300L 100MHz CPU, desktop, no TC slots Features: - 21064 CPU (100 to 200 MHz) 21064A CPU (225 to 275 MHz) - memory bus: 256 bit, with ECC [DEC3000/500-class] 64 bit, with ECC - memory: - proprietary 100pin SIMMs installed in sets of 8 [DEC3000/500-class] - PS/2 style 72pin 36 bit FPM SIMMs, 70ns or better used in pairs of 2 [DEC3000/300-class] - Bcache / L2 cache: varying sizes, 512 kB to 2 Mbyte - builtin 10Mbit ethernet based on a Lance 7990 chip, AUI and UTP - one or two SCSI buses based on a NCR53C94 or a NCR53CF94-2 chip - 2 serial ports based on Zilog 8530 (one usable as a serial console) - embedded ISDN interface - onboard 8 bit sound - 8 bit graphics onboard [some models] or via a TC card [some other models] SCSI: Currently DEC3000 machines can only be used diskless on FreeBSD/alpha. The reason for this is that the SCSI drivers needed for the TC SCSI adapters were not brought into CAM that the current FreeBSD versions use. TC option cards for single (PMAZ-A?) or dual fast SCSI (PMAZC-AA) are also available. And currently have no drivers n FreeBSD either. DEC3000/300 has 5Mbytes/sec SCSI onboard. This bus is used for both internal and external devices. DEC3000/500 has 2 SCSI buses. One is for internal devices only, the other one is for external devices only. ISDN interface: does not work on FreeBSD (to be honest I don't think there is any operating system, including Tru64 Unix, that can use it). Memory: DEC3000/300-class uses standard 36 bit, 72 pin Fast Page Mode SIMMs. EDO SIMMs, 32 or 33 bit SIMMs all will not work in Pelicans. For 32Mbyte SIMMs to work on the DEC3000/300-class the presence detect bits/pins of the SIMM must correspond to what the machine expects. If they don't, the SIMM is 'seen' as a 8 Mbyte SIMM. 8 Mbyte and 32 Mbyte SIMMs can be mixed, as long as the pairs themselves are identical. DEC3000/500-class can use 2, 4, 8, 16 and 32Mbyte 100pin SIMMs. Note that the maximum memory size varies from system to system, desktop machines have sacrificed box size for less memory SIMM sockets. Given enough sockets and enough SIMMs you can get to 512Mbytes maximum. Sound: is not supported on any of the models Graphics: The is no X-Windows version available for the TC machines. DEC3000/300 needs a serial console. DEC3000/500-class might work with a graphical console. I ran mine with a serial console so I cannot verify this. +++ reviewers? Birds can be obtained from surplus sales etc. As they are not PCI based they are no longer actively maintained. TC expansion boards can be difficult to obtain these days and support for them is not too good unless you write/debug the code yourself. Programming information for TC boards is hard to find. For the DEC3000/[4-9]00 series machines the kernel config file must contain: options DEC_3000_500 For the DEC3000/300 ("Pelican") machines the kernel config file must contain: options DEC_3000_300 * *Evaluation Board 64plus ("EB64+"), Aspen Alpine * In it's attempts to popularise the Alpha CPU DEC produced a number of so called Evaluation Boards. The EB64+ family boards have the following feature set: - 21064 or 21064A CPU, 150 to 275MHz - memory bus: 128 bit - memory: PS/2 style 72 pin 36bit Fast Page Mode SIMMs, 70ns or better, installed in pairs of 2, 8 SIMM sockets uses parity - Bcache / L2 cache: 512 kByte, 1 Mbyte or 2 Mbyte - 21072 chipset - Intel 82378ZB PCI to ISA bridge chip ('Saturn') - dual 16550A serial ports - 53C810 FastSCSI - embedded 10Mbit Ethernet - 2 PCI slots - 3 ISA slots Aspen Alpine: Aspen Alpine is slightly different, but is close enough to the EB64+ to run an EB64+ SRM EPROM (mine does..). The Aspen Alpine does not have an embedded Ethernet, has 3 instead of 2 PCI slots. It comes with 2 Mbytes of cache already soldered onto the mainboard. SRM: The SRM console code is housed in an UV-erasable EPROM. No easy flash SRM upgrades for the EB64+ The latest SRM version available for EB64+ is quite ancient anyway. SCSI: The EB64+ SRM can boot both NCR810 and Qlogic1040 SCSI adapters. Pitfall for the Qlogic is that the firmware that is downloaded by the SRM onto the Qlogic chip is very old. There are no updates for the EB64+ SRM available. So you are stuck with old Qlogic bits too. I have had quite some problems when I wanted to use UltraSCSI drives on the Alpine/Qlogic. The FreeBSD/alpha kernel can be compiled to include a much newer Qlogic firmware revision. This is not the default because it adds hunderds of kBytes worth of bloat to the kernel. All of this might mean that you need to use a non-Qlogic adapter to boot from. For the EB64+ class machines the kernel config file must contain: options DEC_EB64PLUS * * Evaluation Board 164 ("EB164, PC164, PC164LX, PC164SX") family * +++ reviewers who own any of these: please check carefully! EB164 is a newer design evaluation board, based on the 21164A CPU. This design has been used to 'spin off' multiple variations, some of which are used by OEM manufacturers/assembly shops. Samsung did it's own PC164LX which has only 32 bit PCI, whereas the DEC variant has 64 bit PCI. Features: - 21164A, multiple speed variants [EB164, PC164, PC164LX] 21164PC [only on PC164SX] - memory bus: 128 bit / 256 bit - memory: PS/2 style SIMMs in sets of 4 or 8, 36 bit, Fast Page Mode, uses ECC, [EB164 and PC164] SDRAM DIMMs in sets of 2, uses ECC [PC164SX and PC164LX] - dual 16550A serial ports - PS/2 style keyboard & mouse - floppy controller - parallel port - 32 bits PCI - 64 bits PCI [some models] - ISA slots via an Intel 82378ZB PCI to ISA bridge chip Memory: Using 8 SIMMs for a 256bit wide memory can yield interesting speedups over a 4 SIMM/128bit wide memory. Obviously all 8 SIMMs must be of the same type to make this work. The system must be explicitely setup to use the 8 SIMM memory arrangement. You must have 8 SIMMs, 4 SIMMs distributed over 2 banks does not cut it. SCSI: The SRM can boot from Qlogic 10xx boards or the NCR/Symbios 53C810. Maybe 53C825 will also work [anybody to confirm this?]. Newer versions of the Symbios 53Cxxx will likely not be bootable. If you want to try make sure that you have the latest SRM version. IDE: PC164 reputedly can boot from IDE disks [anybody to confirm this?] assuming your SRM is new enough. Samsung PC164UX: Whether FreeBSD/alpha runs on this board is unknown. Please let me know if it does. For the EB164 class machines the kernel config file must contain: options DEC_EB164 cpu EV5 * * AlphaStation 200 and 400 series * The Digital AlphaStation 200 and 400 series systems are early PCI based workstations for the lower end. The 200 series is a desktop box, the 400 series is a deskside mini-tower. Features: - 21064 or 21064A CPU - DECchip 21071-AA (core logic chipset) consisting of: Cache/memory controller (one 21071-CA chip) PCI interface (one 21071-DA chip) Data path (two 21071-BA chips) 512 Kbytes of on-board Bcache/L2 cache (15 ns SRAM) - memory bus: 64 bit - memory: 8 to 384 MBytes of RAM, 70 ns or better Fast Page DRAM, in three pairs uses parity - PS/2 keyboard and mouse port - two 16550 serial ports - parallel port - floppy disk interface - 32 bit PCI expansion slots (3 for 400 series, 2 for 200 series) - ISA expansion slots (4 for 400 series, 2 for 200 series) (some ISA/PCI slots are physicaly shared) - embedded 21040-based ethernet (200 series only) - embedded NCR/Symbios 53c810 Fast SCSI-2 chip - Intel 82378IB ("Saturn") PCI-ISA bridge chip - graphics is embedded TGA or PCI VGA (model dependent) - 16 bit sound (on 200 series) Memory: the system uses parity memory SIMMs, but it does not need 36 bit wide SIMMs. 33 bit wide SIMMs are sufficient, 36 bit SIMMs are acceptable too. EDO or 32 bit SIMMs will not work. 4, 8, 16, 32 and 64 Mbyte SIMMs are supported. Sound: the sound interface is not supported by FreeBSD. +++ correct? SCSI: AlphaStation 200 series has an automatic SCSI terminator. This means that as soon as you plug a cable onto the external SCSI connector the internal terminator of the system is disabled. It also means that you should not leave unterminated cables plugged into the machine. AlphaStation 400 series have an SRM variable that controls termination. In case you have external SCSI devices connected you must set this SRM variable using: "set control_scsi_term external". If only internal SCSI devices are present use: "set control_scsi_term internal" For the AlphaStation-[24]00 machines the kernel config file must contain: options DEC_2100_A50 * * AlphaStation 500 and 600 * AS500 and 600 were the high-end EV5 / PCI based workstations. EV6 based machines have in the meantime taken their place as front runners. AS500 is a desktop in a darkblue case (TopGun blue), AS600 is a sturdy deskside box. AS600 has a nice LCD panel to observe the early stages of SRM startup. Features: - 21164 EV5 CPU at 266, 333, 400 or 500 MHz - 21171 ("CIA") or 21172 ("CIA2") core logic chipset - 2 or 8 Mb L2 cache (8Mb on 500 MHz version only) 2 to 16 Mb L2 cache (AS600; 3 cache-SIMM slots) - memory bus: 256 bits, uses ECC - memory: AS500: industry standard 8 byte wide DIMMs +++ 8 DIMM slots installed in sets of 4, maximum memory is 1 Gb uses ECC AS600: industry standard 36 bit Fast Page Mode SIMMs installed in sets of 8, maximum memory is 1 Gb uses ECC - Qlogic 1020 based wide SCSI bus (1 bus/chip for AS500, 2 for AS600) - 21040 based Ethernet adapter with both Thinwire and UTP connectors - expansion: AS500: 3 32-bit PCI slots 1 64-bit PCI slot AS600: 2 32-bit PCI slot 3 64-bit PCI slots 1 PCI/EISA physically shared slot 3 EISA slots 1 PCI and 1 EISA slot are occupied by default - 21050 PCI-to-PCI bridge chip - Intel 82375EB PCI-EISA bridge (AS600 only) - 2 16550A serial ports - 1 parallel port - 16 bit audio Windows Sound System, in dedicated slot (AS500) in EISA slot (AS600, this is an ISA card) - PS/2 keyboard and mouse port SCSI: Early machines had Fast SCSI interfaces, later ones are Ultra SCSI capable. AS500 shares it's single SCSI bus with internal and external devices. For a Fast SCSI bus you are limited to 1.8 meters buslength external to the box. +++ This is what some DEC docs suggest. Did they ever go Ultra? AS600 has one Qlogic chip dedicated to the internal devices whereas the other one is dedicated to external SCSI devices. PCI: AS600 has a peculiarity for it's PCI slots. AS600 (or rather the PCI expansion card containing the SCSI adapters) does not allow I/O port mapping, therefore all devices behind it must use memory mapping. If you have problems getting the SCSI adapters to work, add the following option to /boot/loader.rc: set isp_mem_map=0xff This may need to be typed at the bootloader prompt before booting the installation kernel. For the AlphaStation-[56]00 machines the kernel config file must contain: options DEC_KN20AA * * AlphaServer 1000 ("Mikasa"), 1000A ("Noritake") and 800 (+++) * For the AlphaServer1000/1000A/800 machines the kernel config file must contain: options DEC_1000A # AlphaServer 1000, 1000A, 800 * * DS10 ("Webbrick") / XP1000 ("Monet") * Webbrick and Monet are high performance workstations/servers based on the EV6 CPU and the Tsunami chipset. Tsunami is also used in much higher-end systems and as such has very good performance to offer. The XP1000 has, by 1999 standards, *stunning* memory and I/O system bandwidth. ** Webbrick Features: - 21264 EV6 CPU at 466 MHz - 4MB L2 cache - memory bus: ? +++ - memory: proprietary buffered DIMMs with I2C interfaced ident chip +++ really proprietary? 4 DIMM slots installed in pairs of 2 - 21271 Core Logic Chipset ("Tsunami") - 2 onboard 21143 Fast ethernet controllers - AcerLabs M5237 (Aladdin-V) USB controller - AcerLabs M1533 PCI-ISA bridge - AcerLabs Aladdin ATA-33 controller - expansion: 3 64-bit PCI slots 1 32-bit PCI slots - 2x 16550A serial ports - 1x parallel port - PS/2 keyboard & mouse port Case: The DS10 is shipped in a desktop-style case similar to the older 21164 "Maverick" workstations but which offers much better access to components. If you intend to build a farm you can rackmount DS10 in a 19" rack. Memory: DS10 has 4 DIMM slots. DIMMs are installed as pairs. Please note that DIMM pairs are not installed in adjacent DIMM sockets but rather physically interleaved. EIDE: The base model comes with a FUJITSU 9.5GB ATA disk as its boot device. FreeBSD/alpha works just fine using EIDE disks on DS10. USB: whether this works on FreeBSD on DS10 is as yet unknown. ** Monet Features: - 21264 EV6 at 500 or 667 MHz - 4MB L2 cache - memory bus ??? +++ - memory ?? +++ - 21271 Core Logic Chipset ("Tsunami") - 1 onboard 21143 ethernet controller - Cypress 82C693 USB controller - Cypress 82C693 PCI-ISA bridge - Cypress 82C693 controller (bootable & usable for a root disk) - expansion: 2 independent PCI buses (called hoses) hose 0: (the upper 3 slots) 2 64-bit PCI slots 1 32-bit PCI slot hose 1: (the bottom 2 slots) 2 32-bit PCI slots (behind a PCI-PCI bridge) - 1x UltraWide SCSI port based on a Qlogic 1040 chip - 2x 16550A serial port - 1x parallel port - PS/2 keyboard & mouse port Case: Monet is housed in a mini-tower like enclosure. Memory: Expansion: Don't try to use NCR/Symbios-chip based SCSI adapters in the PCI slots connected to hose 1. There is a not-yet-found FreeBSD bug that prevents this from working correctly. The kernel config file must contain: options DEC_ST6600 # xp1000, dp264, ds20, ds10, family The following quirk applies - One cannot put a NCR scsi controller into a slot on the secondary PCI bus. DS20: Features: - 21264 EV6 at +++ MHz - dual CPU capable machine - +++ Mb L2 cache - memory bus: 256 bit ?+++ - memory: proprietary ?+++ DIMMs installed in sets of 4 uses ECC ?+++ 16 DIMM slots - 21271 Core Logic Chipset ("Tsunami") - expansion: hoses ?+++ 6 64-bit PCI slots 1 ISA slot Case: DS20 is housed in a fat minitower-like enclosure. The enclosure also contains a StorageWorks SCSI hotswap shelf for a maximum of 7 3.5" SCSI devices. CPU: DS20 can have a maximum of 2 CPUs installed. FreeBSD/alpha is not currently SMP-capable and will only use one CPU. Acknowledgements ---------------- In compiling this file I used multiple information sources, but http://www.netbsd.org proved to be an invaluable source of information. If it wasn't for NetBSD/alpha there probably would not be a FreeBSD/alpha in the first place. People who helped me with creating this document: - Nick Maniscalco - Andrew Gallatin - Christian Weisgerber - David O'Brien - Wim Lemmers -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jan 12 18:53:12 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by hub.freebsd.org (Postfix) with ESMTP id 9552B14A2F for ; Wed, 12 Jan 2000 18:53:08 -0800 (PST) (envelope-from shsrms@bellatlantic.net) Received: from bellatlantic.net (adsl-138-88-37-191.bellatlantic.net [138.88.37.191]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id UAA24962; Wed, 12 Jan 2000 20:44:04 -0500 (EST) Message-ID: <387D2E9E.46B7D760@bellatlantic.net> Date: Wed, 12 Jan 2000 20:47:10 -0500 From: ":)" Reply-To: shsrms@bellatlantic.net X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Wilko Bulte Cc: FreeBSD-alpha mailing list Subject: Re: current shot at AlphaHW.txt References: <20000112084013.A53647@yedi.iaf.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko, Thanks! I am still putting my PC164 together. I have my 3000 running fine, and my multia - both with netbsd. I am looking pretty seriously at FreeBSD,so I am very interested in the HW txt. It cleared up a bunch of my misconceptions!! thanks!! bob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 12:59: 3 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id A34DB15013 for ; Thu, 13 Jan 2000 12:58:49 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA06520; Thu, 13 Jan 2000 21:23:31 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA04103; Thu, 13 Jan 2000 21:07:22 +0100 (CET) (envelope-from wilko) Date: Thu, 13 Jan 2000 21:07:22 +0100 From: Wilko Bulte To: ":)" Cc: FreeBSD-alpha mailing list Subject: Re: current shot at AlphaHW.txt Message-ID: <20000113210721.E1602@yedi.iaf.nl> References: <20000112084013.A53647@yedi.iaf.nl> <387D2E9E.46B7D760@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <387D2E9E.46B7D760@bellatlantic.net>; from shsrms@bellatlantic.net on Wed, Jan 12, 2000 at 08:47:10PM -0500 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 12, 2000 at 08:47:10PM -0500, :) wrote: > Wilko, > Thanks! > I am still putting my PC164 together. > I have my 3000 running fine, and my multia - both with netbsd. > I am looking pretty seriously at FreeBSD,so I am very interested in the > HW txt. > It cleared up a bunch of my misconceptions!! > thanks!! I appreciate your feedback. By all means let me know if there is anything unclear. This applies to all of you on this list BTW. -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 13:17:29 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C7D0114D3E for ; Thu, 13 Jan 2000 13:17:21 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id QAA19703; Thu, 13 Jan 2000 16:17:20 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id QAA88183; Thu, 13 Jan 2000 16:16:50 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2000 16:16:49 -0500 (EST) To: Wilko Bulte Cc: FreeBSD-alpha mailing list Subject: Re: current shot at AlphaHW.txt In-Reply-To: <20000112084013.A53647@yedi.iaf.nl> References: <20000112084013.A53647@yedi.iaf.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14462.16191.409234.724569@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > * > * DS10 ("Webbrick") / XP1000 ("Monet") > * > > Webbrick and Monet are high performance workstations/servers based on the > EV6 CPU and the Tsunami chipset. Tsunami is also used in much higher-end > systems and as such has very good performance to offer. > > The XP1000 has, by 1999 standards, *stunning* memory and I/O system bandwidth. > > ** Webbrick > > Features: > - 21264 EV6 CPU at 466 MHz > - 4MB L2 cache > - memory bus: ? +++ > - memory: proprietary buffered DIMMs with I2C interfaced ident chip > +++ really proprietary? > 4 DIMM slots > installed in pairs of 2 > - 21271 Core Logic Chipset ("Tsunami") > - 2 onboard 21143 Fast ethernet controllers > - AcerLabs M5237 (Aladdin-V) USB controller > - AcerLabs M1533 PCI-ISA bridge > - AcerLabs Aladdin ATA-33 controller > - expansion: 3 64-bit PCI slots > 1 32-bit PCI slots > - 2x 16550A serial ports > - 1x parallel port > - PS/2 keyboard & mouse port > > Case: > The DS10 is shipped in a desktop-style case similar to the older 21164 > "Maverick" workstations but which offers much better access to > components. If you intend to build a farm you can rackmount DS10 in a 19" > rack. > > Memory: > DS10 has 4 DIMM slots. DIMMs are installed as pairs. Please note that > DIMM pairs are not installed in adjacent DIMM sockets but rather physically > interleaved. > > EIDE: > The base model comes with a FUJITSU 9.5GB ATA disk as its boot device. > FreeBSD/alpha works just fine using EIDE disks on DS10. > > USB: > whether this works on FreeBSD on DS10 is as yet unknown. > > ** Monet > > Features: > - 21264 EV6 at 500 or 667 MHz > - 4MB L2 cache > - memory bus ??? +++ > - memory ?? +++ > - 21271 Core Logic Chipset ("Tsunami") > - 1 onboard 21143 ethernet controller > - Cypress 82C693 USB controller > - Cypress 82C693 PCI-ISA bridge > - Cypress 82C693 controller (bootable & usable for a root disk) > - expansion: 2 independent PCI buses (called hoses) > hose 0: (the upper 3 slots) > 2 64-bit PCI slots > 1 32-bit PCI slot > hose 1: (the bottom 2 slots) > 2 32-bit PCI slots (behind a PCI-PCI bridge) > > - 1x UltraWide SCSI port based on a Qlogic 1040 chip > - 2x 16550A serial port > - 1x parallel port > - PS/2 keyboard & mouse port It also has an ess1888 sound card built into the motherboard. Today's -current "sorta" sees it: sbc0: at port 0x220-0x22f irq 5 drq 1 on isa0 sbc0: interrupting at ISA irq 5 pcm0: on sbc0 pcm0: chn_init() for record:0 failed pcm0: chn_init() for play:0 failed > Case: > Monet is housed in a mini-tower like enclosure. > > Memory: > > Expansion: > Don't try to use NCR/Symbios-chip based SCSI adapters in the PCI slots > connected to hose 1. There is a not-yet-found FreeBSD bug that prevents this > from working correctly. > > The kernel config file must contain: > options DEC_ST6600 # xp1000, dp264, ds20, ds10, family > > > The following quirk applies > - One cannot put a NCR scsi controller into a slot on the secondary > PCI bus. > > DS20: > > Features: > - 21264 EV6 at +++ MHz > - dual CPU capable machine > - +++ Mb L2 cache > - memory bus: 256 bit ?+++ > - memory: proprietary ?+++ DIMMs > installed in sets of 4 > uses ECC ?+++ > 16 DIMM slots > - 21271 Core Logic Chipset ("Tsunami") > - expansion: 2 independent PCI buses (called hoses) > 6 64-bit PCI slots (3/hose) > 1 ISA slot > > Case: > DS20 is housed in a fat minitower-like enclosure. The enclosure also > contains a StorageWorks SCSI hotswap shelf for a maximum of 7 3.5" SCSI > devices. > > CPU: > DS20 can have a maximum of 2 CPUs installed. FreeBSD/alpha is not currently > SMP-capable and will only use one CPU. The NCR quirk should be moved out of the monet section, it applies to all multi-hose machines (eg DS20, dp264 & UP2000). The DS20 ships with an NCR card in a pci slot on hose1, so one has to open the case & move the board to get FreeBSD booting. I think that the DS20's nickname is "goldrush" Notice the above edits about having 2 hoses, 3 pci slots / hose Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 14:19:47 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by hub.freebsd.org (Postfix) with ESMTP id 6D100154F3 for ; Thu, 13 Jan 2000 14:19:29 -0800 (PST) (envelope-from Blok_Peter@emcmail.lss.emc.com) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id RAA10195; Thu, 13 Jan 2000 17:18:48 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 17:18:50 -0500 Message-ID: From: Blok_Peter@emc.com To: wilko@yedi.iaf.nl Cc: freebsd-alpha@freebsd.org Subject: RE: current shot at AlphaHW.txt Date: Thu, 13 Jan 2000 17:18:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko, what i miss in your list is, what PCI and ISA cards are supported per type of alpha system. Is it possible to come up with a matrix systems vs pci/isa h/w. For example is the 3com 3C509 ISA supported in AXPPCI33? Peter -----Original Message----- From: owner-freebsd-alpha@FreeBSD.ORG [mailto:owner-freebsd-alpha@FreeBSD.ORG]On Behalf Of Wilko Bulte Sent: Wednesday, January 12, 2000 8:40 AM To: FreeBSD-alpha mailing list Subject: current shot at AlphaHW.txt As I have received some requests to see the latest version of the AlphaHW.txt that I'm working on: here it is. This is very much work in progress, please comment on any errors. Special attention please for +++ marked parts. FreeBSD/alpha Hardware Information ================================== This file is maintained by Wilko Bulte Additions, corrections and constructive criticism are invited. In particular information on system quirks is more than welcome. This file is a continuous work-in-progress. Wed Jan 12 08:37:51 CET 2000 ( +++ notes attention points or open issues. Please comment on those ) Scope ----- This document tries to provide a starting point for those who want to start running FreeBSD on an Alpha-based machine. It is aimed at providing background information on the various hardware designs. It is not a replacement for the system's manuals. Per system type that FreeBSD/alpha supports you will find a section that briefly describes the system, and, more importantly, provides information on the particulars/quirks of a system model. In general, what do you need to run FreeBSD/alpha? -------------------------------------------------- Obviously you will need an Alpha machine that FreeBSD/alpha knows about. Alpha machines are NOT PC-architectures. There are considerable differences between the various chipsets and mainboard designs. This means that a kernel needs to know the intimate details of a particular machine before it can run on it. Throwing some odd GENERIC kernel at unknown hardware is almost guaranteed to fail miserably. For a machine even to be considered for FreeBSD use please make sure it has the SRM console firmware installed. Or at least make sure that SRM console firmware is available for this particular model. If FreeBSD does not currently support your machine type, there is a good chance that this will change some time, assuming there is a SRM available. Machines with the ARC/AlphaBIOS console firmware are intended for WindowsNT. Some of them have SRM firmware available in the system ROMs which you only have to select (via an ARC/AlphaBIOS menu). In other cases you will have to re-flash the ROMs with SRM code. Check on http://ftp.digital.com/pub/DEC/Alpha/firmware to see what is available for your particular system. In any case: no SRM -> no FreeBSD (or NetBSD, OpenBSD, Tru64 Unix or OpenVMS for that matter). As part of the SRM you will get the so called OSF/1 PAL code (OSF/1 being the initial name of DEC's Unix offering on Alpha). The PAL code can be thought of as a software abstraction layer between the hardware and the operating system. It uses normal CPU instruction plus a handful of priviliged instructions specific for PAL use. PAL is not microcode by the way. The ARC firmware contains a different PAL code, geared towards WinNT and in no way suitable for use by FreeBSD (or more generic: Unix or OpenVMS). Before someone asks: AlphaLinux brings it's own PAL code, allowing it to boot. There are various reasons why this is not a very good idea in the eyes of the *BSD folks. I don't want to go into details here. There is another pitfall ahead: you will need a disk adapter that the SRM console recognises in order to be able to boot from your disk. For PCI SCSI this means you will need either a NCR/Symbios 810 based adapter, or a Qlogic 1020/1040 based adapter. Some machines come with a SCSI chip embedded on the mainboard. Newer machine designs and SRM versions will be able to work with later SCSI chips/adapters. This problem might bite those who have machines that started their lives as WinNT boxes. The ARC/AlphaBIOS knows about *other* adapter types that it can boot from than the SRM. For example you can boot from an Adaptec 2940UW with ARC but not with SRM. Some adapters that cannot be booted from work fine for data-only disks (e.g. Adaptec 2940x boards). The differences between SRM and ARC could also get you pre-packaged IDE CDROMs and harddrives in some (former NT) systems. SRM versions versions exist (depends on the mainboard) that can also boot from IDE disks. Again, this is system dependent. +++ As I'm a SCSI-only guy I invite comments on how well IDE works on +++ the various systems. Alpha machines can be run with SRM on a graphics console or on a serial console. ARC does not like serial consoles. If you want to run your Alpha without a monitor/graphics card just don't connect a keyboard/mouse to the machine. Instead hook up a serial terminal[emulator] to serial port #1. The SRM will talk 9600N81 to you. This is really practical for debugging purposes. Most PCI based Alphas can use ordinary PC-type VGA cards. The SRM contains enough smarts to make that work. It does not, however, mean that each and every PCI VGA card out on the street will work in an Alpha machine. Things like S3 Trio64 generally work. But ask around first before buying. Most PCI devices from the PC-world will also work in FreeBSD/alpha PCI-based machines. Check the /sys/alpha/conf/GENERIC file for the latest word on this. For now all parallel ports do not work on FreeBSD/alpha. The driver needs work to make this happen. For Alpha CPUs you will find multiple versions. The original Alpha design is the 21064. It was produced in a chip baking process called MOS4, chips made in this process are nicknamed EV4. Newer CPUs are 21164, 21264 etc. You will see designations like EV4S, EV45, EV5, EV56, EV6, EV67. The higher the EV number the more desirable (read: faster / more modern). For memory you want at least 32 Mbytes. I have had FreeBSD/alpha run on a 16 Mbyte system but you will not like that. Kernel build times halved when going to 32 Mbytes. Note that the SRM steals 2Mbyte from the total system memory (and keeps it). For more serious use >= 64Mbyte is recommended. Final word: I expect the above to sound a bit daunting to the first-time Alpha user. Don't be daunted too much. And feel free to ask questions. Model specific information -------------------------- Below is an overview of the hardware that FreeBSD/alpha is capable of running on. This list is bound to grow, a look in /sys/alpha/conf/GENERIC can be enlightening. Alpha machines are often best known by their project codename, these are listed below in (). * * AXPpci33 ("NoName") * The NoName is a baby-AT mainboard based on the 21066 LCA (Low Cost Alpha) processor. It was originally designed for OEM-use. The LCA chip includes almost all of the logic to drive a PCI bus. This makes for a low-priced design. Due to the limited memory interface the system is not particularly fast in case of cache misses. As long as you stay inside the on-chip cache the CPU is comparable to a 21064 (first generation Alpha) These boards should be very cheap to obtain these days (even here in the Netherlands they were sold new for US$ 25). Features: - 21066 Alpha CPU at 166/233MHz (21068 CPUs are also possible, but are even slower. Never seen/used one) - memory bus: 64 bits - onboard Bcache / L2 cache: 0, 256k or 1Mbyte (uses DIL chips) - PS/2 mouse & keyboard port OR 5pin DIN keyboard (2 mainboard models) - memory: PS/2 style 72 pin 36 bit Fast Page Mode SIMMs, 70ns or better, installed in pairs of 2, 4 SIMM sockets uses ECC - 512kB FlashROM for the console code. - 2x 16550A serial ports, 1x parallel port, floppy interface - 1x embedded IDE interface - expansion: 3 32 bit PCI slots (1 shared with ISA) 5 ISA slots (1 shared with PCI) - embedded FastSCSI using an NCR/Symbios 810 chip SRM: NoName's can either have SRM *or* ARC console firmware in their FlashROM. The FlashROM is not big enough to hold both ARC and SRM at the same time and allow software selection of alternate console code. But you need SRM only anyway. Cache: Cache for the NoNames are 15 or 20ns DIL chips. For a 256kByte cache you want to check your junked 486 mainboard. Chips for a 1Mbyte cache are a rare breed unfortunately. Getting at least a 256kByte cache is recommended performance wise. Cacheless they are really slow. Power: The NoName mainboard has a PC/AT-standard power connector. It also has a power connector for 3.3 Volts. No need to rush out to get a new power supply. The 3.3 Volts is only needed in case you run 3.3 Volts PCI expansion boards. IDE: SRM presumably cannot boot from IDE disks (have never tried this myself) Memory: Make sure you use true 36 bit SIMMs, and only FPM (Fast Page Mode). EDO RAM or SIMMs with fake parity *will not work* (the board uses the 4 extra bits for ECC!). 33 bit SIMMs will for the same reason not work either. Using a wrong memory type is the #1 problem that people encounter with NoNames. Keyboard/mouse: Given the choice, get the PS/2-variant mainboard. Apart from giving you a mouse port as bonus it is directly supported by Tru64 Unix in case you ever want/need to run it. The "DIN-plug"-variant should work OK for FreeBSD. The OEM manual is recommended reading. If you did not get one with your system/board send me email, I have a Postscript copy. The kernel configuration file for a NoName kernel must contain: options DEC_AXPPCI_33 * * Universal Desktop Box (UDB or "Multia") * Note: Multia can be either Intel or Alpha CPU based. We assume Alpha based Multias here for obvious reasons. Multia is a very compact 21066 based box, rougly 40cm square and 8 cm thick. It has a small 2.5" SCSI disk of 300Mbyte or so. Fortunately there is an external high density 50pin SCSI connector. It has an embedded 10Mbit Ethernet interface. There is only one PCI slot for expansion, and only for a small PCI card too. The socketed CPU is either 166 or 233 MHz. It comes with a TGA based graphics onboard. The 3.5" floppy drive is a very compact laptop variant. Note: Most the discussion of the NoName applies to Multia too. Hot: Multias are somewhat notorious for dying of heat strokes. The very compact box does not really allow cooling air access very well. Please use the Multia on it's vertical stand, don't put it horizontally ('pizza style'). Replacing the fan with something which pushes around more air is recommended. SCSI: In case you want to change the internal harddrive: the internal flatcable running from the PCI riserboard to the 2.5" (!!) harddrive has a finer pitch than the standard SCSI flatcables. Otherwise it would not fit on the 2.5" drives. I recommend against trying to cram another harddisk inside. Use the external SCSI connector and put your disk in an external enclosure. The kernel configuration file for a Multia kernel must contain: options DEC_AXPPCI_33 * * Personal Workstation ("Miata") * The Miata is a small tower machine intended to be put under a desk. There are multiple Miata variants. The original Miata is the MX5 model. Because it suffers from a number of hardware design flaws an ECO was performed, yielding the MiataGL. Unfortunately the boxes are identical for both variants. An easy check if to see if the back of the machine sports two USB connectors. If yes, it is a MiataGL. System designations look like "Personal Workstation 433a". This means it has a 433 MHz CPU, and started life as a WinNT workstation (the trailing 'a'). Systems designated from day 1 to run Tru64 Unix or OpenVMS will sport '433au'. WinNT-Miata's are likely to come pre-configured with an IDE CDROM drive. Features: - 21164A EV56 Alpha CPU, at 433, 500 or 600MHz - 21174 Core Logic ("Pyxis") chipset - onboard Bcache / L3 cache: 0, 2, 4Mbyte (uses a cache module) - memory bus: 128 bits wide, ECC protected - memory: Miata uses unbuffered SDRAMs, installed in pairs of 2 - onboard Fast Ethernet, the bulkhead can be 10/100 UTP, or 10 UTP/BNC (MX5 uses a 21142 or 21143 ethernetchip dependent on the version of the PCI riser card, MiataGL has a 21143 chip) - 2x onboard [E]IDE (MX5: CMD 646, MiataGL: Cypress 82C693) - 1x UltraWide SCSI Qlogic 1040 [MiataGL only] - expansion: 2 64-bit PCI slots 3 32-bit PCI slots (behind a DEC PCI-PCI bridge chip) 3 ISA slots (physically shared with the 32 bit PCI slots, via a Intel 82378IB PCI to ISA bridge chip) - 2x 16550A serial port - 1x parallel port +++ reviewers, does FreeBSD/alpha support parallel ports? - PS/2 keyboard & mouse port - USB interface [MiataGL only] - embedded sound based on a ESS1888 chip CPU mainboard and PCI 'riser' board: the Miata is divided into two printed circuit boards. The lower board in the bottom of the machine has the PCI and ISA slots and things like the sound chip etc. The top board has the CPU, the Pyxis chip, memory etc. Note that MX5 and the MiataGL use a different PCI riser board. This means that you cannot just upgrade to a MiataGL CPU board (with the newer Pyxis chip) but that you will also need a different riser board. Apparantly an MX5 riser with a MiataGL CPU board will work but it is definitely not a supported or tested configuration. Everything else (cabinet, wiring etc etc) is identical for MX5 and MiataGL. DMA bug: MX5 has problems with DMA via the 2 64-bit PCI slots when this DMA crosses a page boundary. The 32bit slots don't have this problem because the PCI-PCI bridge chip does not allow the offending transfers. The SRM code knows about the problem and refuses to start the system if there is a PCI card in one of the 64bit slots that it does not know about. Cards that are 'known good' to the SRM are allowed to be used in the 64bit slots. If you want to fool the SRM you can type "set pci_device_override" at the >>> SRM prompt. Don't complain if your data mysteriously gets mangled. The complete command is: set pci_device_override e.g. set pci_device_override 88c15333 The kernel reports it when it sees a buggy Pyxis chip: Sep 16 18:39:43 miata /kernel: cia0: Pyxis, pass 1 Sep 16 18:39:43 miata /kernel: cia0: extended capabilities: 1 Sep 16 18:39:43 miata /kernel: cia0: WARNING: Pyxis pass 1 DMA bug; no bets... A MiataGL probes as: Jan 3 12:22:32 miata /kernel: cia0: Pyxis, pass 1 Jan 3 12:22:32 miata /kernel: cia0: extended capabilities: 1 Jan 3 12:22:32 miata /kernel: pcib0: <2117x PCI host bus adapter> on cia0 MiataGL does not have the DMA problems of the MX5. PCI cards that make the MX5 SRM choke when installed in the 64bit slots are accepted without problems by the MiataGL SRM. The latest mainboard revisions of MX5 contain a hardware workaround for the bug. The SRM does not know about the ECO and will complain about unknown cards just like before. The same applies to the FreeBSD kernel by the way. IDE: The Miata SRM can boot from IDE CDROM drives. I am not sure if this also applies to harddisks +++ reviewers? PCI-PCI bridge: The MiataGL has a faster PCI-PCI bridge chip on the PCI riser card than some of the MX5 riser card versions. Some of the MX5 risers have the *same* chip as the MiataGL (are you still with me? ;-) Sound: both MX5 and MiataGL have an onboard sound chip, an ESS1888. I have yet to see/hear it work on my MiataGL. Cache: when your Miata has an optional cache board installed make sure it is firmly seated. A slightly loose cache has been observed to cause weird crashes (not surprising obviously, but maybe not so obvious when troubleshooting). Cache is identical between MX5 and MiataGL. Installing a cache module achieves, apart from a 10-15% speed increase (based on buildworld elapsed time), a *decrease* for PCI DMA read bandwith from 64bit PCI cards. A benchmark on a 64-bit Myrinet card resulted in a decrease from 149 Mb/sec to 115 Mb/sec. Something to keep in mind when doing really high speed things with 64 bit PCI adapters. USB: Does not currently seem to work on FreeBSD/alpha. +++ The kernel configuration file for a Miata kernel must contain: options DEC_ST550 * * DEC3000 family (the "Bird" machines) * The DEC3000 series were among the first Alpha machines ever produced. They are based on an I/O bus called the TurboChannel (TC) bus. These machines are built like tanks (watch your back). DEC3000 can be subdivided in DEC3000/500-class and DEC3000/300-class. The DEC3000/500-class is the early high-end workstation/server Alpha family. Servers use serial consoles, workstations have graphics tubes. DEC3000/300-class is the lower-cost workstation class. DEC3000/500-class are quite fast (considering their age) thanks to the good memory design. DEC3000/300 is crippled compared to DEC3000/500 because of it's much narrower memory bus. They are called 'Birds' because their internal DEC codenames were bird names: DEC3000/400 'Sandpiper' 133MHz CPU, desktop DEC3000/500 'Flamingo' 150MHz CPU, floorstanding DEC3000/500X 'Hot Pink' 200MHz CPU, floorstanding DEC3000/600 +++ 175MHz CPU, desktop DEC3000/700, +++ 225MHz CPU, floorstanding DEC3000/800, +++ 200MHz CPU, floorstanding DEC3000/900, +++ 275MHz CPU, floorstanding DEC3000/300 'Pelican' 150MHz CPU, desktop, 2 TC slots DEC3000/300X 175MHz CPU, desktop, 2 TC slots DEC3000/300LX 125MHz CPU, desktop, 2 TC slots DEC3000/300L 100MHz CPU, desktop, no TC slots Features: - 21064 CPU (100 to 200 MHz) 21064A CPU (225 to 275 MHz) - memory bus: 256 bit, with ECC [DEC3000/500-class] 64 bit, with ECC - memory: - proprietary 100pin SIMMs installed in sets of 8 [DEC3000/500-class] - PS/2 style 72pin 36 bit FPM SIMMs, 70ns or better used in pairs of 2 [DEC3000/300-class] - Bcache / L2 cache: varying sizes, 512 kB to 2 Mbyte - builtin 10Mbit ethernet based on a Lance 7990 chip, AUI and UTP - one or two SCSI buses based on a NCR53C94 or a NCR53CF94-2 chip - 2 serial ports based on Zilog 8530 (one usable as a serial console) - embedded ISDN interface - onboard 8 bit sound - 8 bit graphics onboard [some models] or via a TC card [some other models] SCSI: Currently DEC3000 machines can only be used diskless on FreeBSD/alpha. The reason for this is that the SCSI drivers needed for the TC SCSI adapters were not brought into CAM that the current FreeBSD versions use. TC option cards for single (PMAZ-A?) or dual fast SCSI (PMAZC-AA) are also available. And currently have no drivers n FreeBSD either. DEC3000/300 has 5Mbytes/sec SCSI onboard. This bus is used for both internal and external devices. DEC3000/500 has 2 SCSI buses. One is for internal devices only, the other one is for external devices only. ISDN interface: does not work on FreeBSD (to be honest I don't think there is any operating system, including Tru64 Unix, that can use it). Memory: DEC3000/300-class uses standard 36 bit, 72 pin Fast Page Mode SIMMs. EDO SIMMs, 32 or 33 bit SIMMs all will not work in Pelicans. For 32Mbyte SIMMs to work on the DEC3000/300-class the presence detect bits/pins of the SIMM must correspond to what the machine expects. If they don't, the SIMM is 'seen' as a 8 Mbyte SIMM. 8 Mbyte and 32 Mbyte SIMMs can be mixed, as long as the pairs themselves are identical. DEC3000/500-class can use 2, 4, 8, 16 and 32Mbyte 100pin SIMMs. Note that the maximum memory size varies from system to system, desktop machines have sacrificed box size for less memory SIMM sockets. Given enough sockets and enough SIMMs you can get to 512Mbytes maximum. Sound: is not supported on any of the models Graphics: The is no X-Windows version available for the TC machines. DEC3000/300 needs a serial console. DEC3000/500-class might work with a graphical console. I ran mine with a serial console so I cannot verify this. +++ reviewers? Birds can be obtained from surplus sales etc. As they are not PCI based they are no longer actively maintained. TC expansion boards can be difficult to obtain these days and support for them is not too good unless you write/debug the code yourself. Programming information for TC boards is hard to find. For the DEC3000/[4-9]00 series machines the kernel config file must contain: options DEC_3000_500 For the DEC3000/300 ("Pelican") machines the kernel config file must contain: options DEC_3000_300 * *Evaluation Board 64plus ("EB64+"), Aspen Alpine * In it's attempts to popularise the Alpha CPU DEC produced a number of so called Evaluation Boards. The EB64+ family boards have the following feature set: - 21064 or 21064A CPU, 150 to 275MHz - memory bus: 128 bit - memory: PS/2 style 72 pin 36bit Fast Page Mode SIMMs, 70ns or better, installed in pairs of 2, 8 SIMM sockets uses parity - Bcache / L2 cache: 512 kByte, 1 Mbyte or 2 Mbyte - 21072 chipset - Intel 82378ZB PCI to ISA bridge chip ('Saturn') - dual 16550A serial ports - 53C810 FastSCSI - embedded 10Mbit Ethernet - 2 PCI slots - 3 ISA slots Aspen Alpine: Aspen Alpine is slightly different, but is close enough to the EB64+ to run an EB64+ SRM EPROM (mine does..). The Aspen Alpine does not have an embedded Ethernet, has 3 instead of 2 PCI slots. It comes with 2 Mbytes of cache already soldered onto the mainboard. SRM: The SRM console code is housed in an UV-erasable EPROM. No easy flash SRM upgrades for the EB64+ The latest SRM version available for EB64+ is quite ancient anyway. SCSI: The EB64+ SRM can boot both NCR810 and Qlogic1040 SCSI adapters. Pitfall for the Qlogic is that the firmware that is downloaded by the SRM onto the Qlogic chip is very old. There are no updates for the EB64+ SRM available. So you are stuck with old Qlogic bits too. I have had quite some problems when I wanted to use UltraSCSI drives on the Alpine/Qlogic. The FreeBSD/alpha kernel can be compiled to include a much newer Qlogic firmware revision. This is not the default because it adds hunderds of kBytes worth of bloat to the kernel. All of this might mean that you need to use a non-Qlogic adapter to boot from. For the EB64+ class machines the kernel config file must contain: options DEC_EB64PLUS * * Evaluation Board 164 ("EB164, PC164, PC164LX, PC164SX") family * +++ reviewers who own any of these: please check carefully! EB164 is a newer design evaluation board, based on the 21164A CPU. This design has been used to 'spin off' multiple variations, some of which are used by OEM manufacturers/assembly shops. Samsung did it's own PC164LX which has only 32 bit PCI, whereas the DEC variant has 64 bit PCI. Features: - 21164A, multiple speed variants [EB164, PC164, PC164LX] 21164PC [only on PC164SX] - memory bus: 128 bit / 256 bit - memory: PS/2 style SIMMs in sets of 4 or 8, 36 bit, Fast Page Mode, uses ECC, [EB164 and PC164] SDRAM DIMMs in sets of 2, uses ECC [PC164SX and PC164LX] - dual 16550A serial ports - PS/2 style keyboard & mouse - floppy controller - parallel port - 32 bits PCI - 64 bits PCI [some models] - ISA slots via an Intel 82378ZB PCI to ISA bridge chip Memory: Using 8 SIMMs for a 256bit wide memory can yield interesting speedups over a 4 SIMM/128bit wide memory. Obviously all 8 SIMMs must be of the same type to make this work. The system must be explicitely setup to use the 8 SIMM memory arrangement. You must have 8 SIMMs, 4 SIMMs distributed over 2 banks does not cut it. SCSI: The SRM can boot from Qlogic 10xx boards or the NCR/Symbios 53C810. Maybe 53C825 will also work [anybody to confirm this?]. Newer versions of the Symbios 53Cxxx will likely not be bootable. If you want to try make sure that you have the latest SRM version. IDE: PC164 reputedly can boot from IDE disks [anybody to confirm this?] assuming your SRM is new enough. Samsung PC164UX: Whether FreeBSD/alpha runs on this board is unknown. Please let me know if it does. For the EB164 class machines the kernel config file must contain: options DEC_EB164 cpu EV5 * * AlphaStation 200 and 400 series * The Digital AlphaStation 200 and 400 series systems are early PCI based workstations for the lower end. The 200 series is a desktop box, the 400 series is a deskside mini-tower. Features: - 21064 or 21064A CPU - DECchip 21071-AA (core logic chipset) consisting of: Cache/memory controller (one 21071-CA chip) PCI interface (one 21071-DA chip) Data path (two 21071-BA chips) 512 Kbytes of on-board Bcache/L2 cache (15 ns SRAM) - memory bus: 64 bit - memory: 8 to 384 MBytes of RAM, 70 ns or better Fast Page DRAM, in three pairs uses parity - PS/2 keyboard and mouse port - two 16550 serial ports - parallel port - floppy disk interface - 32 bit PCI expansion slots (3 for 400 series, 2 for 200 series) - ISA expansion slots (4 for 400 series, 2 for 200 series) (some ISA/PCI slots are physicaly shared) - embedded 21040-based ethernet (200 series only) - embedded NCR/Symbios 53c810 Fast SCSI-2 chip - Intel 82378IB ("Saturn") PCI-ISA bridge chip - graphics is embedded TGA or PCI VGA (model dependent) - 16 bit sound (on 200 series) Memory: the system uses parity memory SIMMs, but it does not need 36 bit wide SIMMs. 33 bit wide SIMMs are sufficient, 36 bit SIMMs are acceptable too. EDO or 32 bit SIMMs will not work. 4, 8, 16, 32 and 64 Mbyte SIMMs are supported. Sound: the sound interface is not supported by FreeBSD. +++ correct? SCSI: AlphaStation 200 series has an automatic SCSI terminator. This means that as soon as you plug a cable onto the external SCSI connector the internal terminator of the system is disabled. It also means that you should not leave unterminated cables plugged into the machine. AlphaStation 400 series have an SRM variable that controls termination. In case you have external SCSI devices connected you must set this SRM variable using: "set control_scsi_term external". If only internal SCSI devices are present use: "set control_scsi_term internal" For the AlphaStation-[24]00 machines the kernel config file must contain: options DEC_2100_A50 * * AlphaStation 500 and 600 * AS500 and 600 were the high-end EV5 / PCI based workstations. EV6 based machines have in the meantime taken their place as front runners. AS500 is a desktop in a darkblue case (TopGun blue), AS600 is a sturdy deskside box. AS600 has a nice LCD panel to observe the early stages of SRM startup. Features: - 21164 EV5 CPU at 266, 333, 400 or 500 MHz - 21171 ("CIA") or 21172 ("CIA2") core logic chipset - 2 or 8 Mb L2 cache (8Mb on 500 MHz version only) 2 to 16 Mb L2 cache (AS600; 3 cache-SIMM slots) - memory bus: 256 bits, uses ECC - memory: AS500: industry standard 8 byte wide DIMMs +++ 8 DIMM slots installed in sets of 4, maximum memory is 1 Gb uses ECC AS600: industry standard 36 bit Fast Page Mode SIMMs installed in sets of 8, maximum memory is 1 Gb uses ECC - Qlogic 1020 based wide SCSI bus (1 bus/chip for AS500, 2 for AS600) - 21040 based Ethernet adapter with both Thinwire and UTP connectors - expansion: AS500: 3 32-bit PCI slots 1 64-bit PCI slot AS600: 2 32-bit PCI slot 3 64-bit PCI slots 1 PCI/EISA physically shared slot 3 EISA slots 1 PCI and 1 EISA slot are occupied by default - 21050 PCI-to-PCI bridge chip - Intel 82375EB PCI-EISA bridge (AS600 only) - 2 16550A serial ports - 1 parallel port - 16 bit audio Windows Sound System, in dedicated slot (AS500) in EISA slot (AS600, this is an ISA card) - PS/2 keyboard and mouse port SCSI: Early machines had Fast SCSI interfaces, later ones are Ultra SCSI capable. AS500 shares it's single SCSI bus with internal and external devices. For a Fast SCSI bus you are limited to 1.8 meters buslength external to the box. +++ This is what some DEC docs suggest. Did they ever go Ultra? AS600 has one Qlogic chip dedicated to the internal devices whereas the other one is dedicated to external SCSI devices. PCI: AS600 has a peculiarity for it's PCI slots. AS600 (or rather the PCI expansion card containing the SCSI adapters) does not allow I/O port mapping, therefore all devices behind it must use memory mapping. If you have problems getting the SCSI adapters to work, add the following option to /boot/loader.rc: set isp_mem_map=0xff This may need to be typed at the bootloader prompt before booting the installation kernel. For the AlphaStation-[56]00 machines the kernel config file must contain: options DEC_KN20AA * * AlphaServer 1000 ("Mikasa"), 1000A ("Noritake") and 800 (+++) * For the AlphaServer1000/1000A/800 machines the kernel config file must contain: options DEC_1000A # AlphaServer 1000, 1000A, 800 * * DS10 ("Webbrick") / XP1000 ("Monet") * Webbrick and Monet are high performance workstations/servers based on the EV6 CPU and the Tsunami chipset. Tsunami is also used in much higher-end systems and as such has very good performance to offer. The XP1000 has, by 1999 standards, *stunning* memory and I/O system bandwidth. ** Webbrick Features: - 21264 EV6 CPU at 466 MHz - 4MB L2 cache - memory bus: ? +++ - memory: proprietary buffered DIMMs with I2C interfaced ident chip +++ really proprietary? 4 DIMM slots installed in pairs of 2 - 21271 Core Logic Chipset ("Tsunami") - 2 onboard 21143 Fast ethernet controllers - AcerLabs M5237 (Aladdin-V) USB controller - AcerLabs M1533 PCI-ISA bridge - AcerLabs Aladdin ATA-33 controller - expansion: 3 64-bit PCI slots 1 32-bit PCI slots - 2x 16550A serial ports - 1x parallel port - PS/2 keyboard & mouse port Case: The DS10 is shipped in a desktop-style case similar to the older 21164 "Maverick" workstations but which offers much better access to components. If you intend to build a farm you can rackmount DS10 in a 19" rack. Memory: DS10 has 4 DIMM slots. DIMMs are installed as pairs. Please note that DIMM pairs are not installed in adjacent DIMM sockets but rather physically interleaved. EIDE: The base model comes with a FUJITSU 9.5GB ATA disk as its boot device. FreeBSD/alpha works just fine using EIDE disks on DS10. USB: whether this works on FreeBSD on DS10 is as yet unknown. ** Monet Features: - 21264 EV6 at 500 or 667 MHz - 4MB L2 cache - memory bus ??? +++ - memory ?? +++ - 21271 Core Logic Chipset ("Tsunami") - 1 onboard 21143 ethernet controller - Cypress 82C693 USB controller - Cypress 82C693 PCI-ISA bridge - Cypress 82C693 controller (bootable & usable for a root disk) - expansion: 2 independent PCI buses (called hoses) hose 0: (the upper 3 slots) 2 64-bit PCI slots 1 32-bit PCI slot hose 1: (the bottom 2 slots) 2 32-bit PCI slots (behind a PCI-PCI bridge) - 1x UltraWide SCSI port based on a Qlogic 1040 chip - 2x 16550A serial port - 1x parallel port - PS/2 keyboard & mouse port Case: Monet is housed in a mini-tower like enclosure. Memory: Expansion: Don't try to use NCR/Symbios-chip based SCSI adapters in the PCI slots connected to hose 1. There is a not-yet-found FreeBSD bug that prevents this from working correctly. The kernel config file must contain: options DEC_ST6600 # xp1000, dp264, ds20, ds10, family The following quirk applies - One cannot put a NCR scsi controller into a slot on the secondary PCI bus. DS20: Features: - 21264 EV6 at +++ MHz - dual CPU capable machine - +++ Mb L2 cache - memory bus: 256 bit ?+++ - memory: proprietary ?+++ DIMMs installed in sets of 4 uses ECC ?+++ 16 DIMM slots - 21271 Core Logic Chipset ("Tsunami") - expansion: hoses ?+++ 6 64-bit PCI slots 1 ISA slot Case: DS20 is housed in a fat minitower-like enclosure. The enclosure also contains a StorageWorks SCSI hotswap shelf for a maximum of 7 3.5" SCSI devices. CPU: DS20 can have a maximum of 2 CPUs installed. FreeBSD/alpha is not currently SMP-capable and will only use one CPU. Acknowledgements ---------------- In compiling this file I used multiple information sources, but http://www.netbsd.org proved to be an invaluable source of information. If it wasn't for NetBSD/alpha there probably would not be a FreeBSD/alpha in the first place. People who helped me with creating this document: - Nick Maniscalco - Andrew Gallatin - Christian Weisgerber - David O'Brien - Wim Lemmers -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 14:30:56 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by hub.freebsd.org (Postfix) with ESMTP id AEE1F14D68 for ; Thu, 13 Jan 2000 14:30:54 -0800 (PST) (envelope-from Blok_Peter@emcmail.lss.emc.com) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id RAA13711 for ; Thu, 13 Jan 2000 17:30:47 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 17:30:49 -0500 Message-ID: From: Blok_Peter@emc.com To: freebsd-alpha@freebsd.org Subject: ipfilter Date: Thu, 13 Jan 2000 17:30:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, did somebody successfully enable IPFILTER and compiled it on 3.4-CURRENT? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 14:57: 9 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 2943515271 for ; Thu, 13 Jan 2000 14:57:07 -0800 (PST) (envelope-from tlehman@east.isi.edu) Received: from east.isi.edu (sportster.east.isi.edu [38.245.76.176]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA11206 for ; Thu, 13 Jan 2000 17:57:44 -0500 (EST) Message-ID: <387E5874.8ED74C5D@east.isi.edu> Date: Thu, 13 Jan 2000 17:57:56 -0500 From: Tom Lehman Organization: USC/ISI X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-alpha@FreeBSD.ORG" Subject: XFree86 Xserver Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently installed FBSD 4.0-20000101-CURRENT on an Alpha machine (Comapaq XP1000). I also installed XFree86-3.3.5 from /usr/ports. I was able to configure and get X running with a Number Nine Imagine128 video card. My question is: Does anyone know if there is an XServer available for the "Compaq Powerstorm 350"? This is the video card that came with the machine, and I was not able to find an Xserver that worked with it. SuperProbe does not work, and I was not able to figure out what chipset this video card uses. Any help would be greatly appreciated. Thanks. _________________________________________________________________________ Tom Lehman University of Southern California 703.812.3736(voice) Information Sciences Institute 703.812.3732(fax) tlehman@isi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 14:58: 0 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id B809C14CF1 for ; Thu, 13 Jan 2000 14:57:57 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id RAA22248; Thu, 13 Jan 2000 17:57:56 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id RAA88375; Thu, 13 Jan 2000 17:57:25 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2000 17:57:25 -0500 (EST) To: dfr@nlsystems.com Cc: freebsd-alpha@freebsd.org Subject: Cypress USB oddity X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14462.21106.354099.290960@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Cypress USB controller (function 3 of the 82C693) used on later Digital Personal Workstations and all XP1000s & DS20s is somewhat odd. It is a PCI device, but it apparently wants to use an ISA interrupt (10) and has a truely bizzare irq in its pci config space (234). This results in the usb driver failing to aquire an irq: ohci0: mem 0x1094000-0x1094fff irq 234 at device 7.3 on pci0 ohci0: could not allocate irq The 82C693 has 2 IDE controllers on it as well: ata-pci0: port 0x10000-0x1000f,0x 3f4-0x3f7,0x1f0-0x1f7 irq 238 at device 7.1 on pci0 <...> ata-pci1: port 0x374-0x377,0x170- 0x177 irq 239 at device 7.2 on pci0 They would have the same problem except for the fact that their I/O base addrs match the primary & secondary I/O port addresses for IO_WD1 & IO_WD2. Because of this, they end up using the alpha_platform_setup_ide_intr() code which does the right thing and allocates them ISA irqs. What is the right way to handle the USB function? Do we need a similar hack? I have noticed that if you mask those irq's with 0xf, you get the isa irq that it wants. So I was thinking that we could catch this in the pci chipset code by looking for a bizzare irq, then setup the appropriate isa irq. This sounds pretty disgusting -- is there a better way? Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 15: 3: 5 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C637C15430 for ; Thu, 13 Jan 2000 15:03:02 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id SAA22376; Thu, 13 Jan 2000 18:03:01 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id SAA88393; Thu, 13 Jan 2000 18:02:30 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2000 18:02:30 -0500 (EST) To: Tom Lehman Cc: "freebsd-alpha@FreeBSD.ORG" Subject: Re: XFree86 Xserver Question In-Reply-To: <387E5874.8ED74C5D@east.isi.edu> References: <387E5874.8ED74C5D@east.isi.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14462.22731.234481.845360@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tom Lehman writes: > I recently installed FBSD 4.0-20000101-CURRENT on an Alpha machine > (Comapaq XP1000). > > I also installed XFree86-3.3.5 from /usr/ports. I was able to configure > and get X running with a Number Nine Imagine128 video card. > > My question is: Does anyone know if there is an XServer available for > the "Compaq Powerstorm 350"? This is the video card that came with the > machine, and I was not able to find an Xserver that worked with it. > > SuperProbe does not work, and I was not able to figure out what chipset > this video card uses. > > Any help would be greatly appreciated. Thanks. > DEC sometimes OEMs video cards. At least one of their "Powerstorm" cards is a 3dlabs card. So you might try using pciconf -l to determine the PCI vendor & device ID of the card. This might at least get you a name. Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 15: 7:27 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 0A1AE154B4 for ; Thu, 13 Jan 2000 15:06:46 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id SAA17282; Thu, 13 Jan 2000 18:05:59 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Thu, 13 Jan 2000 18:05:58 -0500 (EST) From: Chuck Robey To: Wilko Bulte Cc: FreeBSD-alpha mailing list Subject: Re: current shot at AlphaHW.txt In-Reply-To: <20000112084013.A53647@yedi.iaf.nl> 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 Wed, 12 Jan 2000, Wilko Bulte wrote: Correction: in the EB164 section. I have a PC164SX myself, I stuck a NCR 875 in it, and it boots fine. Your text makes me believe you can't do that. BTW, the AlphaBios it came with had a selection for what kind of console to choose, of which one option was SRM. Choosing that was a null choice, because it seemed to do nothing at all to the booting of AlphaBios. I had to load the SRM that was available in Mike Smith's dir on freefall, to get it to work. Doing that overwrote AlphaBios, so you can't even see that original option to choose SRM as the console. Just means, don't believe the GUI'd AlphaBios when it tells you there's a SRM option, if you have a PC164SX. > As I have received some requests to see the latest version of the > AlphaHW.txt that I'm working on: here it is. This is very much work in > progress, please comment on any errors. Special attention please for +++ > marked parts. > > > FreeBSD/alpha Hardware Information > ================================== > > This file is maintained by Wilko Bulte > > Additions, corrections and constructive criticism are invited. In > particular information on system quirks is more than welcome. This file > is a continuous work-in-progress. > > Wed Jan 12 08:37:51 CET 2000 > > ( +++ notes attention points or open issues. Please comment on those ) > > Scope > ----- > > This document tries to provide a starting point for those who want to start > running FreeBSD on an Alpha-based machine. It is aimed at providing > background information on the various hardware designs. It is not a > replacement for the system's manuals. Per system type that FreeBSD/alpha > supports you will find a section that briefly describes the system, and, > more importantly, provides information on the particulars/quirks of a system > model. > > > In general, what do you need to run FreeBSD/alpha? > -------------------------------------------------- > > Obviously you will need an Alpha machine that FreeBSD/alpha knows about. > Alpha machines are NOT PC-architectures. There are considerable differences > between the various chipsets and mainboard designs. This means that a kernel > needs to know the intimate details of a particular machine before it can run > on it. Throwing some odd GENERIC kernel at unknown hardware is almost > guaranteed to fail miserably. > > For a machine even to be considered for FreeBSD use please make sure it has > the SRM console firmware installed. Or at least make sure that SRM console > firmware is available for this particular model. If FreeBSD does not > currently support your machine type, there is a good chance that this will > change some time, assuming there is a SRM available. > > Machines with the ARC/AlphaBIOS console firmware are intended for > WindowsNT. Some of them have SRM firmware available in the system ROMs > which you only have to select (via an ARC/AlphaBIOS menu). In other cases > you will have to re-flash the ROMs with SRM code. Check on > http://ftp.digital.com/pub/DEC/Alpha/firmware to see what is available > for your particular system. In any case: no SRM -> no FreeBSD (or NetBSD, > OpenBSD, Tru64 Unix or OpenVMS for that matter). > > As part of the SRM you will get the so called OSF/1 PAL code (OSF/1 being the > initial name of DEC's Unix offering on Alpha). The PAL code can be thought > of as a software abstraction layer between the hardware and the operating > system. It uses normal CPU instruction plus a handful of priviliged > instructions specific for PAL use. PAL is not microcode by the way. > The ARC firmware contains a different PAL code, geared towards WinNT and in > no way suitable for use by FreeBSD (or more generic: Unix or OpenVMS). > Before someone asks: AlphaLinux brings it's own PAL code, allowing it to > boot. There are various reasons why this is not a very good idea in the > eyes of the *BSD folks. I don't want to go into details here. > > There is another pitfall ahead: you will need a disk adapter that the SRM > console recognises in order to be able to boot from your disk. For PCI SCSI > this means you will need either a NCR/Symbios 810 based adapter, or a Qlogic > 1020/1040 based adapter. Some machines come with a SCSI chip embedded on the > mainboard. Newer machine designs and SRM versions will be able to work with > later SCSI chips/adapters. > > This problem might bite those who have machines that started their lives as > WinNT boxes. The ARC/AlphaBIOS knows about *other* adapter types that it > can boot from than the SRM. For example you can boot from an Adaptec 2940UW > with ARC but not with SRM. > > Some adapters that cannot be booted from work fine for data-only disks > (e.g. Adaptec 2940x boards). The differences between SRM and ARC could also > get you pre-packaged IDE CDROMs and harddrives in some (former NT) systems. > SRM versions versions exist (depends on the mainboard) that can also boot > from IDE disks. Again, this is system dependent. > +++ As I'm a SCSI-only guy I invite comments on how well IDE works on > +++ the various systems. > > Alpha machines can be run with SRM on a graphics console or on > a serial console. ARC does not like serial consoles. If you want to run your > Alpha without a monitor/graphics card just don't connect a keyboard/mouse to > the machine. Instead hook up a serial terminal[emulator] to serial port #1. > The SRM will talk 9600N81 to you. This is really practical for debugging > purposes. > > Most PCI based Alphas can use ordinary PC-type VGA cards. The SRM contains > enough smarts to make that work. It does not, however, mean that each and > every PCI VGA card out on the street will work in an Alpha machine. Things > like S3 Trio64 generally work. But ask around first before buying. > > Most PCI devices from the PC-world will also work in FreeBSD/alpha PCI-based > machines. Check the /sys/alpha/conf/GENERIC file for the latest word on > this. > > For now all parallel ports do not work on FreeBSD/alpha. The driver needs > work to make this happen. > > For Alpha CPUs you will find multiple versions. The original Alpha > design is the 21064. It was produced in a chip baking process called MOS4, > chips made in this process are nicknamed EV4. Newer CPUs are 21164, 21264 > etc. You will see designations like EV4S, EV45, EV5, EV56, EV6, EV67. > The higher the EV number the more desirable (read: faster / more modern). > > For memory you want at least 32 Mbytes. I have had FreeBSD/alpha run on a > 16 Mbyte system but you will not like that. Kernel build times halved when > going to 32 Mbytes. Note that the SRM steals 2Mbyte from the total system > memory (and keeps it). For more serious use >= 64Mbyte is recommended. > > Final word: I expect the above to sound a bit daunting to the first-time > Alpha user. Don't be daunted too much. And feel free to ask questions. > > Model specific information > -------------------------- > > Below is an overview of the hardware that FreeBSD/alpha is capable of > running on. This list is bound to grow, a look in /sys/alpha/conf/GENERIC > can be enlightening. Alpha machines are often best known by their project > codename, these are listed below in (). > > * > * AXPpci33 ("NoName") > * > The NoName is a baby-AT mainboard based on the 21066 LCA (Low Cost Alpha) > processor. It was originally designed for OEM-use. The LCA chip includes > almost all of the logic to drive a PCI bus. This makes for a low-priced > design. Due to the limited memory interface the system is not particularly > fast in case of cache misses. As long as you stay inside the on-chip cache > the CPU is comparable to a 21064 (first generation Alpha) These boards > should be very cheap to obtain these days (even here in the Netherlands > they were sold new for US$ 25). > > Features: > - 21066 Alpha CPU at 166/233MHz > (21068 CPUs are also possible, but are even slower. Never seen/used one) > - memory bus: 64 bits > - onboard Bcache / L2 cache: 0, 256k or 1Mbyte (uses DIL chips) > - PS/2 mouse & keyboard port OR 5pin DIN keyboard (2 mainboard models) > - memory: PS/2 style 72 pin 36 bit Fast Page Mode SIMMs, 70ns or better, > installed in pairs of 2, > 4 SIMM sockets > uses ECC > - 512kB FlashROM for the console code. > - 2x 16550A serial ports, 1x parallel port, floppy interface > - 1x embedded IDE interface > - expansion: 3 32 bit PCI slots (1 shared with ISA) > 5 ISA slots (1 shared with PCI) > - embedded FastSCSI using an NCR/Symbios 810 chip > > SRM: > NoName's can either have SRM *or* ARC console firmware in their FlashROM. > The FlashROM is not big enough to hold both ARC and SRM at the same time > and allow software selection of alternate console code. But you need > SRM only anyway. > > Cache: > Cache for the NoNames are 15 or 20ns DIL chips. For a 256kByte cache you > want to check your junked 486 mainboard. Chips for a 1Mbyte cache are a rare > breed unfortunately. Getting at least a 256kByte cache is recommended > performance wise. Cacheless they are really slow. > > Power: > The NoName mainboard has a PC/AT-standard power connector. It also has > a power connector for 3.3 Volts. No need to rush out to get > a new power supply. The 3.3 Volts is only needed in case you run 3.3 Volts > PCI expansion boards. > > IDE: > SRM presumably cannot boot from IDE disks (have never tried this myself) > > Memory: > Make sure you use true 36 bit SIMMs, and only FPM (Fast Page Mode). EDO RAM > or SIMMs with fake parity *will not work* (the board uses the 4 extra bits > for ECC!). 33 bit SIMMs will for the same reason not work either. > Using a wrong memory type is the #1 problem that people encounter with > NoNames. > > Keyboard/mouse: > Given the choice, get the PS/2-variant mainboard. Apart from giving you a > mouse port as bonus it is directly supported by Tru64 Unix in case you ever > want/need to run it. The "DIN-plug"-variant should work OK for FreeBSD. > > The OEM manual is recommended reading. If you did not get one with your > system/board send me email, I have a Postscript copy. > > The kernel configuration file for a NoName kernel must contain: > options DEC_AXPPCI_33 > > > * > * Universal Desktop Box (UDB or "Multia") > * > > Note: Multia can be either Intel or Alpha CPU based. We assume Alpha based > Multias here for obvious reasons. > > Multia is a very compact 21066 based box, rougly 40cm square and 8 cm thick. > It has a small 2.5" SCSI disk of 300Mbyte or so. Fortunately there is > an external high density 50pin SCSI connector. > > It has an embedded 10Mbit Ethernet interface. There is only one PCI slot > for expansion, and only for a small PCI card too. The socketed CPU is > either 166 or 233 MHz. It comes with a TGA based graphics onboard. > The 3.5" floppy drive is a very compact laptop variant. > > Note: Most the discussion of the NoName applies to Multia too. > > Hot: > Multias are somewhat notorious for dying of heat strokes. The very compact > box does not really allow cooling air access very well. Please use the > Multia on it's vertical stand, don't put it horizontally ('pizza style'). > Replacing the fan with something which pushes around more air is > recommended. > > SCSI: > In case you want to change the internal harddrive: the internal flatcable > running from the PCI riserboard to the 2.5" (!!) harddrive has a finer pitch > than the standard SCSI flatcables. Otherwise it would not fit on the 2.5" > drives. I recommend against trying to cram another harddisk inside. Use the > external SCSI connector and put your disk in an external enclosure. > > The kernel configuration file for a Multia kernel must contain: > options DEC_AXPPCI_33 > > * > * Personal Workstation ("Miata") > * > The Miata is a small tower machine intended to be put under a desk. There > are multiple Miata variants. The original Miata is the MX5 model. Because > it suffers from a number of hardware design flaws an ECO was performed, > yielding the MiataGL. Unfortunately the boxes are identical for both > variants. An easy check if to see if the back of the machine sports two > USB connectors. If yes, it is a MiataGL. System designations look like > "Personal Workstation 433a". This means it has a 433 MHz CPU, and started > life as a WinNT workstation (the trailing 'a'). Systems designated from day > 1 to run Tru64 Unix or OpenVMS will sport '433au'. WinNT-Miata's are likely > to come pre-configured with an IDE CDROM drive. > > Features: > > - 21164A EV56 Alpha CPU, at 433, 500 or 600MHz > - 21174 Core Logic ("Pyxis") chipset > - onboard Bcache / L3 cache: 0, 2, 4Mbyte (uses a cache module) > - memory bus: 128 bits wide, ECC protected > - memory: Miata uses unbuffered SDRAMs, installed in pairs of 2 > - onboard Fast Ethernet, the bulkhead can be 10/100 UTP, or 10 UTP/BNC > (MX5 uses a 21142 or 21143 ethernetchip dependent on the version of the > PCI riser card, MiataGL has a 21143 chip) > - 2x onboard [E]IDE (MX5: CMD 646, MiataGL: Cypress 82C693) > - 1x UltraWide SCSI Qlogic 1040 [MiataGL only] > - expansion: 2 64-bit PCI slots > 3 32-bit PCI slots (behind a DEC PCI-PCI bridge chip) > 3 ISA slots (physically shared with the 32 bit PCI slots, via > a Intel 82378IB PCI to ISA bridge chip) > - 2x 16550A serial port > - 1x parallel port +++ reviewers, does FreeBSD/alpha support parallel ports? > - PS/2 keyboard & mouse port > - USB interface [MiataGL only] > - embedded sound based on a ESS1888 chip > > CPU mainboard and PCI 'riser' board: > the Miata is divided into two printed circuit boards. > The lower board in the bottom of the machine has the PCI > and ISA slots and things like the sound chip etc. The top board > has the CPU, the Pyxis chip, memory etc. Note that MX5 and the MiataGL use > a different PCI riser board. This means that you cannot just upgrade to > a MiataGL CPU board (with the newer Pyxis chip) but that you will also need > a different riser board. Apparantly an MX5 riser with a MiataGL CPU board > will work but it is definitely not a supported or tested configuration. > Everything else (cabinet, wiring etc etc) is identical for MX5 and MiataGL. > > DMA bug: > MX5 has problems with DMA via the 2 64-bit PCI slots when this DMA > crosses a page boundary. The 32bit slots don't have this problem because the > PCI-PCI bridge chip does not allow the offending transfers. The SRM code > knows about the problem and refuses to start the system if there is a PCI > card in one of the 64bit slots that it does not know about. Cards that are > 'known good' to the SRM are allowed to be used in the 64bit slots. > > If you want to fool the SRM you can type "set pci_device_override" at > the >>> SRM prompt. Don't complain if your data mysteriously gets mangled. > The complete command is: > > set pci_device_override > e.g. set pci_device_override 88c15333 > > The kernel reports it when it sees a buggy Pyxis chip: > Sep 16 18:39:43 miata /kernel: cia0: Pyxis, pass 1 > Sep 16 18:39:43 miata /kernel: cia0: extended capabilities: 1 > Sep 16 18:39:43 miata /kernel: cia0: WARNING: Pyxis pass 1 DMA bug; no > bets... > > A MiataGL probes as: > Jan 3 12:22:32 miata /kernel: cia0: Pyxis, pass 1 > Jan 3 12:22:32 miata /kernel: cia0: extended capabilities: 1 > Jan 3 12:22:32 miata /kernel: pcib0: <2117x PCI host bus adapter> on cia0 > > MiataGL does not have the DMA problems of the MX5. PCI cards that make > the MX5 SRM choke when installed in the 64bit slots are accepted without > problems by the MiataGL SRM. > > The latest mainboard revisions of MX5 contain a hardware workaround for the > bug. The SRM does not know about the ECO and will complain about unknown cards > just like before. The same applies to the FreeBSD kernel by the way. > > IDE: > The Miata SRM can boot from IDE CDROM drives. I am not sure if this also > applies to harddisks +++ reviewers? > > PCI-PCI bridge: > The MiataGL has a faster PCI-PCI bridge chip on the PCI riser card than > some of the MX5 riser card versions. Some of the MX5 risers have the *same* > chip as the MiataGL (are you still with me? ;-) > > Sound: > both MX5 and MiataGL have an onboard sound chip, an ESS1888. > I have yet to see/hear it work on my MiataGL. > > Cache: > when your Miata has an optional cache board installed make sure > it is firmly seated. A slightly loose cache has been observed to cause > weird crashes (not surprising obviously, but maybe not so obvious when > troubleshooting). Cache is identical between MX5 and MiataGL. > > Installing a cache module achieves, apart from a 10-15% speed increase (based on > buildworld elapsed time), a *decrease* for PCI DMA read bandwith from > 64bit PCI cards. A benchmark on a 64-bit Myrinet card resulted in a decrease > from 149 Mb/sec to 115 Mb/sec. Something to keep in mind when doing really > high speed things with 64 bit PCI adapters. > > USB: > Does not currently seem to work on FreeBSD/alpha. +++ > > The kernel configuration file for a Miata kernel must contain: > options DEC_ST550 > > * > * DEC3000 family (the "Bird" machines) > * > > The DEC3000 series were among the first Alpha machines ever produced. They > are based on an I/O bus called the TurboChannel (TC) bus. These > machines are built like tanks (watch your back). > > DEC3000 can be subdivided in DEC3000/500-class and DEC3000/300-class. > The DEC3000/500-class is the early high-end workstation/server Alpha family. > Servers use serial consoles, workstations have graphics tubes. > DEC3000/300-class is the lower-cost workstation class. > > DEC3000/500-class are quite fast (considering their age) thanks to the > good memory design. DEC3000/300 is crippled compared to DEC3000/500 because > of it's much narrower memory bus. > > They are called 'Birds' because their internal DEC codenames were bird > names: > > DEC3000/400 'Sandpiper' 133MHz CPU, desktop > DEC3000/500 'Flamingo' 150MHz CPU, floorstanding > DEC3000/500X 'Hot Pink' 200MHz CPU, floorstanding > DEC3000/600 +++ 175MHz CPU, desktop > DEC3000/700, +++ 225MHz CPU, floorstanding > DEC3000/800, +++ 200MHz CPU, floorstanding > DEC3000/900, +++ 275MHz CPU, floorstanding > > DEC3000/300 'Pelican' 150MHz CPU, desktop, 2 TC slots > DEC3000/300X 175MHz CPU, desktop, 2 TC slots > DEC3000/300LX 125MHz CPU, desktop, 2 TC slots > DEC3000/300L 100MHz CPU, desktop, no TC slots > > > Features: > - 21064 CPU (100 to 200 MHz) > 21064A CPU (225 to 275 MHz) > - memory bus: 256 bit, with ECC [DEC3000/500-class] > 64 bit, with ECC > - memory: - proprietary 100pin SIMMs > installed in sets of 8 [DEC3000/500-class] > - PS/2 style 72pin 36 bit FPM SIMMs, 70ns or better > used in pairs of 2 [DEC3000/300-class] > - Bcache / L2 cache: varying sizes, 512 kB to 2 Mbyte > - builtin 10Mbit ethernet based on a Lance 7990 chip, AUI and UTP > - one or two SCSI buses based on a NCR53C94 or a NCR53CF94-2 chip > - 2 serial ports based on Zilog 8530 (one usable as a serial console) > - embedded ISDN interface > - onboard 8 bit sound > - 8 bit graphics onboard [some models] or via a TC card [some other models] > > SCSI: > Currently DEC3000 machines can only be used diskless on FreeBSD/alpha. The > reason for this is that the SCSI drivers needed for the TC SCSI adapters > were not brought into CAM that the current FreeBSD versions use. TC option > cards for single (PMAZ-A?) or dual fast SCSI (PMAZC-AA) are also available. > And currently have no drivers n FreeBSD either. > > DEC3000/300 has 5Mbytes/sec SCSI onboard. This bus is used for both internal > and external devices. DEC3000/500 has 2 SCSI buses. One is for internal > devices only, the other one is for external devices only. > > ISDN interface: > does not work on FreeBSD (to be honest I don't think there is any > operating system, including Tru64 Unix, that can use it). > > Memory: > DEC3000/300-class uses standard 36 bit, 72 pin Fast Page Mode SIMMs. > EDO SIMMs, 32 or 33 bit SIMMs all will not work in Pelicans. > For 32Mbyte SIMMs to work on the DEC3000/300-class the presence detect > bits/pins of the SIMM must correspond to what the machine expects. If they > don't, the SIMM is 'seen' as a 8 Mbyte SIMM. 8 Mbyte and 32 Mbyte SIMMs can > be mixed, as long as the pairs themselves are identical. > > DEC3000/500-class can use 2, 4, 8, 16 and 32Mbyte 100pin SIMMs. > Note that the maximum memory size varies from system to system, > desktop machines have sacrificed box size for less memory SIMM sockets. > Given enough sockets and enough SIMMs you can get to 512Mbytes maximum. > > Sound: > is not supported on any of the models > > Graphics: > The is no X-Windows version available for the TC machines. > DEC3000/300 needs a serial console. DEC3000/500-class might > work with a graphical console. I ran mine with a serial console so I cannot > verify this. +++ reviewers? > > Birds can be obtained from surplus sales etc. As they are not PCI > based they are no longer actively maintained. TC expansion boards can > be difficult to obtain these days and support for them is not too good > unless you write/debug the code yourself. Programming information for TC > boards is hard to find. > > For the DEC3000/[4-9]00 series machines the kernel config file must > contain: > options DEC_3000_500 > > For the DEC3000/300 ("Pelican") machines the kernel config file must > contain: > options DEC_3000_300 > > * > *Evaluation Board 64plus ("EB64+"), Aspen Alpine > * > > In it's attempts to popularise the Alpha CPU DEC produced a number of so > called Evaluation Boards. The EB64+ family boards have the following feature > set: > > - 21064 or 21064A CPU, 150 to 275MHz > - memory bus: 128 bit > - memory: PS/2 style 72 pin 36bit Fast Page Mode SIMMs, 70ns or better, > installed in pairs of 2, > 8 SIMM sockets > uses parity > - Bcache / L2 cache: 512 kByte, 1 Mbyte or 2 Mbyte > - 21072 chipset > - Intel 82378ZB PCI to ISA bridge chip ('Saturn') > - dual 16550A serial ports > - 53C810 FastSCSI > - embedded 10Mbit Ethernet > - 2 PCI slots > - 3 ISA slots > > Aspen Alpine: > Aspen Alpine is slightly different, but is close enough to the EB64+ to > run an EB64+ SRM EPROM (mine does..). The Aspen Alpine does not have > an embedded Ethernet, has 3 instead of 2 PCI slots. It comes with 2 Mbytes > of cache already soldered onto the mainboard. > > SRM: > The SRM console code is housed in an UV-erasable EPROM. No easy flash SRM > upgrades for the EB64+ The latest SRM version available for EB64+ is quite > ancient anyway. > > SCSI: > The EB64+ SRM can boot both NCR810 and Qlogic1040 SCSI adapters. Pitfall for > the Qlogic is that the firmware that is downloaded by the SRM onto the > Qlogic chip is very old. There are no updates for the EB64+ SRM available. > So you are stuck with old Qlogic bits too. I have had quite some problems > when I wanted to use UltraSCSI drives on the Alpine/Qlogic. The > FreeBSD/alpha kernel can be compiled to include a much newer Qlogic firmware > revision. This is not the default because it adds hunderds of kBytes worth > of bloat to the kernel. All of this might mean that you need to use a > non-Qlogic adapter to boot from. > > For the EB64+ class machines the kernel config file must contain: > options DEC_EB64PLUS > > * > * Evaluation Board 164 ("EB164, PC164, PC164LX, PC164SX") family > * > > +++ reviewers who own any of these: please check carefully! > > EB164 is a newer design evaluation board, based on the 21164A CPU. This > design has been used to 'spin off' multiple variations, some of which are > used by OEM manufacturers/assembly shops. Samsung did it's own PC164LX > which has only 32 bit PCI, whereas the DEC variant has 64 bit PCI. > > Features: > - 21164A, multiple speed variants [EB164, PC164, PC164LX] > 21164PC [only on PC164SX] > - memory bus: 128 bit / 256 bit > - memory: PS/2 style SIMMs in sets of 4 or 8, > 36 bit, Fast Page Mode, uses ECC, [EB164 and PC164] > SDRAM DIMMs in sets of 2, uses ECC [PC164SX and PC164LX] > - dual 16550A serial ports > - PS/2 style keyboard & mouse > - floppy controller > - parallel port > - 32 bits PCI > - 64 bits PCI [some models] > - ISA slots via an Intel 82378ZB PCI to ISA bridge chip > > Memory: > Using 8 SIMMs for a 256bit wide memory can yield interesting speedups over > a 4 SIMM/128bit wide memory. Obviously all 8 SIMMs must be of the same type > to make this work. The system must be explicitely setup to use the > 8 SIMM memory arrangement. You must have 8 SIMMs, 4 SIMMs distributed over 2 > banks does not cut it. > > SCSI: > The SRM can boot from Qlogic 10xx boards or the NCR/Symbios 53C810. Maybe > 53C825 will also work [anybody to confirm this?]. Newer versions of the > Symbios 53Cxxx will likely not be bootable. If you want to try make sure > that you have the latest SRM version. > > IDE: > PC164 reputedly can boot from IDE disks [anybody to confirm this?] assuming > your SRM is new enough. > > Samsung PC164UX: > Whether FreeBSD/alpha runs on this board is unknown. Please let me know if > it does. > > For the EB164 class machines the kernel config file must contain: > options DEC_EB164 > cpu EV5 > > > * > * AlphaStation 200 and 400 series > * > > The Digital AlphaStation 200 and 400 series systems are early PCI based > workstations for the lower end. The 200 series is a desktop box, the 400 > series is a deskside mini-tower. > > Features: > - 21064 or 21064A CPU > - DECchip 21071-AA (core logic chipset) consisting of: > Cache/memory controller (one 21071-CA chip) > PCI interface (one 21071-DA chip) > Data path (two 21071-BA chips) > 512 Kbytes of on-board Bcache/L2 cache (15 ns SRAM) > - memory bus: 64 bit > - memory: 8 to 384 MBytes of RAM, > 70 ns or better Fast Page DRAM, > in three pairs > uses parity > - PS/2 keyboard and mouse port > - two 16550 serial ports > - parallel port > - floppy disk interface > - 32 bit PCI expansion slots (3 for 400 series, 2 for 200 series) > - ISA expansion slots (4 for 400 series, 2 for 200 series) > (some ISA/PCI slots are physicaly shared) > - embedded 21040-based ethernet (200 series only) > - embedded NCR/Symbios 53c810 Fast SCSI-2 chip > - Intel 82378IB ("Saturn") PCI-ISA bridge chip > - graphics is embedded TGA or PCI VGA (model dependent) > - 16 bit sound (on 200 series) > > Memory: > the system uses parity memory SIMMs, but it does not need 36 bit wide SIMMs. > 33 bit wide SIMMs are sufficient, 36 bit SIMMs are acceptable too. EDO or 32 > bit SIMMs will not work. 4, 8, 16, 32 and 64 Mbyte SIMMs are supported. > > Sound: > the sound interface is not supported by FreeBSD. +++ correct? > > SCSI: > AlphaStation 200 series has an automatic SCSI terminator. This means that as > soon as you plug a cable onto the external SCSI connector the internal > terminator of the system is disabled. It also means that you should not > leave unterminated cables plugged into the machine. > > AlphaStation 400 series have an SRM variable that controls termination. In > case you have external SCSI devices connected you must set this SRM > variable using: "set control_scsi_term external". If only internal SCSI devices > are present use: "set control_scsi_term internal" > > For the AlphaStation-[24]00 machines the kernel config file must contain: > options DEC_2100_A50 > > > * > * AlphaStation 500 and 600 > * > > AS500 and 600 were the high-end EV5 / PCI based workstations. EV6 based > machines have in the meantime taken their place as front runners. AS500 is > a desktop in a darkblue case (TopGun blue), AS600 is a sturdy deskside box. > AS600 has a nice LCD panel to observe the early stages of SRM startup. > > Features: > - 21164 EV5 CPU at 266, 333, 400 or 500 MHz > - 21171 ("CIA") or 21172 ("CIA2") core logic chipset > - 2 or 8 Mb L2 cache (8Mb on 500 MHz version only) > 2 to 16 Mb L2 cache (AS600; 3 cache-SIMM slots) > - memory bus: 256 bits, uses ECC > - memory: AS500: industry standard 8 byte wide DIMMs +++ > 8 DIMM slots > installed in sets of 4, > maximum memory is 1 Gb > uses ECC > AS600: industry standard 36 bit Fast Page Mode SIMMs > installed in sets of 8, > maximum memory is 1 Gb > uses ECC > - Qlogic 1020 based wide SCSI bus (1 bus/chip for AS500, 2 for AS600) > - 21040 based Ethernet adapter with both Thinwire and UTP connectors > - expansion: AS500: 3 32-bit PCI slots > 1 64-bit PCI slot > AS600: 2 32-bit PCI slot > 3 64-bit PCI slots > 1 PCI/EISA physically shared slot > 3 EISA slots > 1 PCI and 1 EISA slot are occupied by default > - 21050 PCI-to-PCI bridge chip > - Intel 82375EB PCI-EISA bridge (AS600 only) > - 2 16550A serial ports > - 1 parallel port > - 16 bit audio Windows Sound System, > in dedicated slot (AS500) > in EISA slot (AS600, this is an ISA card) > - PS/2 keyboard and mouse port > > SCSI: > Early machines had Fast SCSI interfaces, later ones are Ultra SCSI capable. > AS500 shares it's single SCSI bus with internal and external devices. For a > Fast SCSI bus you are limited to 1.8 meters buslength external to the box. > +++ This is what some DEC docs suggest. Did they ever go Ultra? > > AS600 has one Qlogic chip dedicated to the internal devices whereas the > other one is dedicated to external SCSI devices. > > PCI: > AS600 has a peculiarity for it's PCI slots. AS600 (or rather the PCI > expansion card containing the SCSI adapters) does not allow I/O port > mapping, therefore all devices behind it must use memory mapping. > If you have problems getting the SCSI adapters to work, add the following > option to /boot/loader.rc: > > set isp_mem_map=0xff > > This may need to be typed at the bootloader prompt before booting the > installation kernel. > > For the AlphaStation-[56]00 machines the kernel config file must contain: > options DEC_KN20AA > > * > * AlphaServer 1000 ("Mikasa"), 1000A ("Noritake") and 800 (+++) > > * > > For the AlphaServer1000/1000A/800 machines the kernel config file must contain: > options DEC_1000A # AlphaServer 1000, 1000A, 800 > > * > * DS10 ("Webbrick") / XP1000 ("Monet") > * > > Webbrick and Monet are high performance workstations/servers based on the > EV6 CPU and the Tsunami chipset. Tsunami is also used in much higher-end > systems and as such has very good performance to offer. > > The XP1000 has, by 1999 standards, *stunning* memory and I/O system bandwidth. > > ** Webbrick > > Features: > - 21264 EV6 CPU at 466 MHz > - 4MB L2 cache > - memory bus: ? +++ > - memory: proprietary buffered DIMMs with I2C interfaced ident chip > +++ really proprietary? > 4 DIMM slots > installed in pairs of 2 > - 21271 Core Logic Chipset ("Tsunami") > - 2 onboard 21143 Fast ethernet controllers > - AcerLabs M5237 (Aladdin-V) USB controller > - AcerLabs M1533 PCI-ISA bridge > - AcerLabs Aladdin ATA-33 controller > - expansion: 3 64-bit PCI slots > 1 32-bit PCI slots > - 2x 16550A serial ports > - 1x parallel port > - PS/2 keyboard & mouse port > > Case: > The DS10 is shipped in a desktop-style case similar to the older 21164 > "Maverick" workstations but which offers much better access to > components. If you intend to build a farm you can rackmount DS10 in a 19" > rack. > > Memory: > DS10 has 4 DIMM slots. DIMMs are installed as pairs. Please note that > DIMM pairs are not installed in adjacent DIMM sockets but rather physically > interleaved. > > EIDE: > The base model comes with a FUJITSU 9.5GB ATA disk as its boot device. > FreeBSD/alpha works just fine using EIDE disks on DS10. > > USB: > whether this works on FreeBSD on DS10 is as yet unknown. > > ** Monet > > Features: > - 21264 EV6 at 500 or 667 MHz > - 4MB L2 cache > - memory bus ??? +++ > - memory ?? +++ > - 21271 Core Logic Chipset ("Tsunami") > - 1 onboard 21143 ethernet controller > - Cypress 82C693 USB controller > - Cypress 82C693 PCI-ISA bridge > - Cypress 82C693 controller (bootable & usable for a root disk) > - expansion: 2 independent PCI buses (called hoses) > hose 0: (the upper 3 slots) > 2 64-bit PCI slots > 1 32-bit PCI slot > hose 1: (the bottom 2 slots) > 2 32-bit PCI slots (behind a PCI-PCI bridge) > > - 1x UltraWide SCSI port based on a Qlogic 1040 chip > - 2x 16550A serial port > - 1x parallel port > - PS/2 keyboard & mouse port > > Case: > Monet is housed in a mini-tower like enclosure. > > Memory: > > Expansion: > Don't try to use NCR/Symbios-chip based SCSI adapters in the PCI slots > connected to hose 1. There is a not-yet-found FreeBSD bug that prevents this > from working correctly. > > The kernel config file must contain: > options DEC_ST6600 # xp1000, dp264, ds20, ds10, family > > > The following quirk applies > - One cannot put a NCR scsi controller into a slot on the secondary > PCI bus. > > DS20: > > Features: > - 21264 EV6 at +++ MHz > - dual CPU capable machine > - +++ Mb L2 cache > - memory bus: 256 bit ?+++ > - memory: proprietary ?+++ DIMMs > installed in sets of 4 > uses ECC ?+++ > 16 DIMM slots > - 21271 Core Logic Chipset ("Tsunami") > - expansion: hoses ?+++ > 6 64-bit PCI slots > 1 ISA slot > > Case: > DS20 is housed in a fat minitower-like enclosure. The enclosure also > contains a StorageWorks SCSI hotswap shelf for a maximum of 7 3.5" SCSI > devices. > > CPU: > DS20 can have a maximum of 2 CPUs installed. FreeBSD/alpha is not currently > SMP-capable and will only use one CPU. > > > Acknowledgements > ---------------- > > In compiling this file I used multiple information sources, but > http://www.netbsd.org proved to be an invaluable source of information. > If it wasn't for NetBSD/alpha there probably would not be a FreeBSD/alpha > in the first place. > > People who helped me with creating this document: > > - Nick Maniscalco > - Andrew Gallatin > - Christian Weisgerber > - David O'Brien > - Wim Lemmers > > ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, New Year's Resolution: I | electronics, communications, and will not sphroxify gullible| signal processing. people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and fictitious words in the | jaunt.mat.net : FreeBSD-current(Alpha)| dictionary. | ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 15:50:37 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from lh2.rdc1.sdca.home.com (ha2.rdc1.sdca.home.com [24.0.3.67]) by hub.freebsd.org (Postfix) with ESMTP id 09E8514C49 for ; Thu, 13 Jan 2000 15:50:35 -0800 (PST) (envelope-from craig-burgess@home.com) Received: from home.com ([24.0.178.21]) by lh2.rdc1.sdca.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000113235034.WLOW1336.lh2.rdc1.sdca.home.com@home.com>; Thu, 13 Jan 2000 15:50:34 -0800 Message-ID: <387E6556.FD2F7412@home.com> Date: Thu, 13 Jan 2000 15:52:54 -0800 From: Craig Burgess X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD-alpha mailing list Cc: Chuck Robey , Wilko Bulte Subject: Re: current shot at AlphaHW.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I had a similar experience in modifying my machine from booting NT (EIDE drive) to FreeBSD -- Machine identified (From dmesg) as: EB164 Digital AlphaPC 164 500 MHz, 500MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 I used the SRM firmware update I found at the Compaq/Digital site. Chuck Robey wrote: > > On Wed, 12 Jan 2000, Wilko Bulte wrote: > > Correction: > > in the EB164 section. I have a PC164SX myself, I stuck a NCR 875 in it, > and it boots fine. Your text makes me believe you can't do that. > > BTW, the AlphaBios it came with had a selection for what kind of console > to choose, of which one option was SRM. Choosing that was a null choice, > because it seemed to do nothing at all to the booting of AlphaBios. I had > to load the SRM that was available in Mike Smith's dir on freefall, to get > it to work. Doing that overwrote AlphaBios, so you can't even see that > original option to choose SRM as the console. Just means, don't believe > the GUI'd AlphaBios when it tells you there's a SRM option, if you have a > PC164SX. > > > As I have received some requests to see the latest version of the > > AlphaHW.txt that I'm working on: here it is. This is very much work in > > progress, please comment on any errors. Special attention please for +++ > > marked parts. > > > > > > FreeBSD/alpha Hardware Information [snipped] FWIW, the remainder of the HW which is running: xl0: <3Com 3c905-TX Fast Etherlink XL> irq 2 at device 5.0 on pci0 xl1: <3Com 3c905B-TX Fast Etherlink XL> irq 3 at device 9.0 on pci0 ncr0: irq 1 at device 7.0 on pci0 The ncr controller is an old one from Corporate Data Systems (www.corpsys.com) da0: Fixed Direct Access SCSI-3 device "WARNING: preposterous clock chip time" (showd up after the new year) I bought the machine which had been used as a graphics workstation running NT. The machine is OEM "DeskStation Rebel" made by DeskStation Technologies and came with a 3DLabs display adapter. I have not successfully installed X -- or much else (FreeBSD 4.0-19991031-CURRENT #1); I have yet to find or create a file for CVSUP to work so that I can update the source. best regards, Craig -- For a man to truly understand rejection, he must first be ignored by a cat. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 13 21:38:19 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 603D614D34 for ; Thu, 13 Jan 2000 21:38:15 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA73878; Fri, 14 Jan 2000 00:37:40 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Fri, 14 Jan 2000 00:37:40 -0500 (EST) From: Chuck Robey To: Craig Burgess Cc: FreeBSD-alpha mailing list , Wilko Bulte Subject: Re: current shot at AlphaHW.txt In-Reply-To: <387E6556.FD2F7412@home.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 Thu, 13 Jan 2000, Craig Burgess wrote: > I had a similar experience in modifying my machine from booting NT (EIDE > drive) to FreeBSD -- > > Machine identified (From dmesg) as: > EB164 > Digital AlphaPC 164 500 MHz, 500MHz > 8192 byte page size, 1 processor. > CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 > > I used the SRM firmware update I found at the Compaq/Digital site. Good. Wilko, that was a confusing point, and I think it should be noted in the AlphaHW.txt. > > Chuck Robey wrote: > > > > On Wed, 12 Jan 2000, Wilko Bulte wrote: > > > > Correction: > > > > in the EB164 section. I have a PC164SX myself, I stuck a NCR 875 in it, > > and it boots fine. Your text makes me believe you can't do that. > > > > BTW, the AlphaBios it came with had a selection for what kind of console > > to choose, of which one option was SRM. Choosing that was a null choice, > > because it seemed to do nothing at all to the booting of AlphaBios. I had > > to load the SRM that was available in Mike Smith's dir on freefall, to get > > it to work. Doing that overwrote AlphaBios, so you can't even see that > > original option to choose SRM as the console. Just means, don't believe > > the GUI'd AlphaBios when it tells you there's a SRM option, if you have a > > PC164SX. > > > > > As I have received some requests to see the latest version of the > > > AlphaHW.txt that I'm working on: here it is. This is very much work in > > > progress, please comment on any errors. Special attention please for +++ > > > marked parts. > > > > > > > > > FreeBSD/alpha Hardware Information > [snipped] > > FWIW, the remainder of the HW which is running: > > xl0: <3Com 3c905-TX Fast Etherlink XL> irq 2 at device 5.0 on pci0 > xl1: <3Com 3c905B-TX Fast Etherlink XL> irq 3 at device 9.0 on pci0 > ncr0: irq 1 at device 7.0 on pci0 > The ncr controller is an old one from Corporate Data Systems > (www.corpsys.com) > da0: Fixed Direct Access SCSI-3 device > "WARNING: preposterous clock chip time" (showd up after the new year) > > I bought the machine which had been used as a graphics workstation > running NT. The machine is OEM "DeskStation Rebel" made by DeskStation > Technologies and came with a 3DLabs display adapter. I have not > successfully installed X -- or much else (FreeBSD 4.0-19991031-CURRENT > #1); I have yet to find or create a file for CVSUP to work so that I can > update the source. > > best regards, > Craig > > > ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, New Year's Resolution: I | electronics, communications, and will not sphroxify gullible| signal processing. people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and fictitious words in the | jaunt.mat.net : FreeBSD-current(Alpha)| dictionary. | ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 9:48:24 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from brak.fuzzfactor.com (cc824388-a.hwrd1.md.home.com [24.6.142.75]) by hub.freebsd.org (Postfix) with ESMTP id 7EE0B15808 for ; Fri, 14 Jan 2000 09:42:57 -0800 (PST) (envelope-from rharris@brak.fuzzfactor.com) Received: from localhost (localhost [[UNIX: localhost]]) by brak.fuzzfactor.com (8.8.8/8.8.8) with ESMTP id MAA13506 for ; Fri, 14 Jan 2000 12:18:55 -0500 (EST) Date: Fri, 14 Jan 2000 12:18:55 -0500 (EST) From: Rob Harris To: freebsd-alpha@freebsd.org 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 grrr--- I just got in two UP2000 based systems. They refuse to boot off of the latest SNAP floppy disks (both 10/30 and 01/01). It gets just past sc0, then goes: panic: ahc0: brkadrint, Scratch or SCB Memory Parity Error at seqaddr=0x2 This behavior is consistent on both boxes I acquired (identically configured). The REALLY odd thing is, when I connect a pre-made drive with an older SNAP (10/30 or so) distribution and kernel on it, it boots just fine. What am I doing wrong? -=[ Rob ]=- ___________________________________________________________________________ "He's old enough to know what's right, but young enough not to choose it. He's noble enough to win the world, but weak enough to lose it." --"New World Man" (Rush) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 10:58: 4 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id E13AC15A58; Fri, 14 Jan 2000 10:52:36 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id NAA09929; Fri, 14 Jan 2000 13:52:34 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id NAA89916; Fri, 14 Jan 2000 13:52:04 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 14 Jan 2000 13:52:03 -0500 (EST) To: Rob Harris Cc: msmith@freebsd.org, freebsd-alpha@freebsd.org In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14463.28607.353168.94402@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rob Harris writes: > > grrr--- > > I just got in two UP2000 based systems. They refuse to boot off of the > latest SNAP floppy disks (both 10/30 and 01/01). It gets just past sc0, > then goes: > > panic: ahc0: brkadrint, Scratch or SCB Memory Parity Error at seqaddr=0x2 > > This behavior is consistent on both boxes I acquired (identically > configured). > > The REALLY odd thing is, when I connect a pre-made drive with an older > SNAP (10/30 or so) distribution and kernel on it, it boots just fine. > > What am I doing wrong? > I think this is the result of a bug in the ahc driver which has recently been fixed. Mike, does your UP2000 do this? Can you try attaching the older disk, and building a -current kernel from today? Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 10:58:59 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 67656157C5 for ; Fri, 14 Jan 2000 10:54:29 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA16945; Fri, 14 Jan 2000 10:54:08 -0800 Date: Fri, 14 Jan 2000 10:54:08 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Rob Harris Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: your mail In-Reply-To: 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 This is actually not an alpha problem- this may have been a transitory buglet in the ahc driver that has been fixed within the last day or so. Try a newer snap. On Fri, 14 Jan 2000, Rob Harris wrote: > > grrr--- > > I just got in two UP2000 based systems. They refuse to boot off of the > latest SNAP floppy disks (both 10/30 and 01/01). It gets just past sc0, > then goes: > > panic: ahc0: brkadrint, Scratch or SCB Memory Parity Error at seqaddr=0x2 > > This behavior is consistent on both boxes I acquired (identically > configured). > > The REALLY odd thing is, when I connect a pre-made drive with an older > SNAP (10/30 or so) distribution and kernel on it, it boots just fine. > > What am I doing wrong? > > > -=[ Rob ]=- > ___________________________________________________________________________ > "He's old enough to know what's right, but young enough not to choose it. > He's noble enough to win the world, but weak enough to lose it." > --"New World Man" (Rush) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 12:30:30 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 66E4914CEE for ; Fri, 14 Jan 2000 12:30:22 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA80310; Fri, 14 Jan 2000 09:06:32 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 14 Jan 2000 09:02:07 +0000 (GMT) From: Doug Rabson To: Andrew Gallatin Cc: freebsd-alpha@freebsd.org Subject: Re: Cypress USB oddity In-Reply-To: <14462.21106.354099.290960@grasshopper.cs.duke.edu> 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 Thu, 13 Jan 2000, Andrew Gallatin wrote: > > The Cypress USB controller (function 3 of the 82C693) used on later > Digital Personal Workstations and all XP1000s & DS20s is somewhat odd. > It is a PCI device, but it apparently wants to use an ISA interrupt > (10) and has a truely bizzare irq in its pci config space (234). This > results in the usb driver failing to aquire an irq: > > ohci0: mem 0x1094000-0x1094fff irq 234 at device > 7.3 on pci0 > ohci0: could not allocate irq > > The 82C693 has 2 IDE controllers on it as well: > > ata-pci0: port 0x10000-0x1000f,0x > 3f4-0x3f7,0x1f0-0x1f7 irq 238 at device 7.1 on pci0 > <...> > ata-pci1: port 0x374-0x377,0x170- > 0x177 irq 239 at device 7.2 on pci0 > > They would have the same problem except for the fact that their I/O > base addrs match the primary & secondary I/O port addresses for IO_WD1 > & IO_WD2. Because of this, they end up using the > alpha_platform_setup_ide_intr() code which does the right thing and > allocates them ISA irqs. > > What is the right way to handle the USB function? Do we need a > similar hack? > > I have noticed that if you mask those irq's with 0xf, you get the isa > irq that it wants. So I was thinking that we could catch this in the > pci chipset code by looking for a bizzare irq, then setup the > appropriate isa irq. This sounds pretty disgusting -- is there a > better way? > > Thanks, This number is 0xe0 + isa irq. I think that some versions of SRM are using this range specifically to describe ISA irqs. If we supported this explicitly (maybe in cia.c - pci.c doesn't really need to hear about it) it might tidy up both this and also the ugly mess of the ide interrupts. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 13:35:38 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 3BB6615047 for ; Fri, 14 Jan 2000 13:35:31 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA81972; Fri, 14 Jan 2000 21:39:07 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 14 Jan 2000 21:34:34 +0000 (GMT) From: Doug Rabson To: Kurt Neumann Cc: freebsd-alpha@freebsd.org Subject: Re: Parallel port driver for Alpha? In-Reply-To: <002901bf58ad$d192ab60$050a0a0a@earthlink.net> 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 Thu, 6 Jan 2000, Kurt Neumann wrote: > I just finished an extensive install, and realized I didn't see the > parallel port driver anywhere in the kernelconfig. I am afraid to ask, > but is it really not supported? I tried adding the options from what I > saw in i386, but it had problems. Any info would be appreciated... > Its not supported right now. I plan to try out the new parallel driver which ought to work fairly easily but right now, I have very little time to play with this stuff. Hopefully before 4.0. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 13:35:55 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 6D5C415047 for ; Fri, 14 Jan 2000 13:35:49 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA81990; Fri, 14 Jan 2000 21:39:44 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 14 Jan 2000 21:35:11 +0000 (GMT) From: Doug Rabson To: Wilko Bulte Cc: FreeBSD-alpha mailing list Subject: Re: weird interrupts? In-Reply-To: <20000107201025.B614@yedi.iaf.nl> 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 Fri, 7 Jan 2000, Wilko Bulte wrote: > An excerpt from a 2 day old -current on a MiataGL: > > isa0: on isab0 > ata-pci0: irq 238 at device > 7.1 o > n pci0 > ata-pci0: Busmastering DMA supported > ata-pci1: irq 239 at device > 7.2 o > n pci0 > ata-pci1: Busmastering DMA not supported > ohci0: irq 234 at device 7.3 on pci0 > ohci0: could not allocate irq > device_probe_and_attach: ohci0 attach returned 12 > vga-pci0: at device 12.0 on pci0 > pcib1: at device 20.0 on pci0 > > Aren't the IRQs a bit weird (high)? I think SRM marks ISA interrupts in intline as 0xe0 + irq. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 15:19:20 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 850591536E for ; Fri, 14 Jan 2000 15:19:12 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id AAA13870; Sat, 15 Jan 2000 00:04:57 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA02731; Fri, 14 Jan 2000 23:50:11 +0100 (CET) (envelope-from wilko) Date: Fri, 14 Jan 2000 23:50:11 +0100 From: Wilko Bulte To: Blok_Peter@emc.com Cc: freebsd-alpha@freebsd.org Subject: Re: current shot at AlphaHW.txt Message-ID: <20000114235011.B2525@yedi.iaf.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from Blok_Peter@emc.com on Thu, Jan 13, 2000 at 05:18:21PM -0500 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 13, 2000 at 05:18:21PM -0500, Blok_Peter@emc.com wrote: > Wilko, > > what i miss in your list is, what PCI and ISA cards are supported per type > of alpha system. Is it possible to come up with a matrix systems vs pci/isa > h/w. > > For example is the 3com 3C509 ISA supported in AXPPCI33? I do understand your point, but that would be a heck of a job. What does exist for the DEC-machines/mainboards is the 'supported hardware list'. But that one only lists (surprise..) DEC-qualified & supported hardware. I'm afraid it is impossible to compile such a list, given all the different hardware out there that can potentially plug into an Alpha. I have never really tried using ISA cards in my NoName. I think it might differ from driver to driver whether they compile/work on Alpha. It won't burn, why not try it? W/ -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 14 15:49:56 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 2C85414D03 for ; Fri, 14 Jan 2000 15:49:53 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA02518; Fri, 14 Jan 2000 15:56:33 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001142356.PAA02518@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Andrew Gallatin Cc: Wilko Bulte , FreeBSD-alpha mailing list Subject: Re: current shot at AlphaHW.txt In-reply-to: Your message of "Thu, 13 Jan 2000 16:16:49 EST." <14462.16191.409234.724569@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jan 2000 15:56:33 -0800 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Features: > > - 21264 EV6 at +++ MHz > > - dual CPU capable machine > > - +++ Mb L2 cache > > - memory bus: 256 bit ?+++ > > - memory: proprietary ?+++ DIMMs > > installed in sets of 4 > > uses ECC ?+++ > > 16 DIMM slots > > - 21271 Core Logic Chipset ("Tsunami") > > - expansion: 2 independent PCI buses (called hoses) > > 6 64-bit PCI slots (3/hose) > > 1 ISA slot > > > > Case: > > DS20 is housed in a fat minitower-like enclosure. The enclosure also > > contains a StorageWorks SCSI hotswap shelf for a maximum of 7 3.5" SCSI > > devices. > > > > CPU: > > DS20 can have a maximum of 2 CPUs installed. FreeBSD/alpha is not currently > > SMP-capable and will only use one CPU. > > The NCR quirk should be moved out of the monet section, it applies to > all multi-hose machines (eg DS20, dp264 & UP2000). The DS20 ships > with an NCR card in a pci slot on hose1, so one has to open the case & > move the board to get FreeBSD booting. > > I think that the DS20's nickname is "goldrush" > > Notice the above edits about having 2 hoses, 3 pci slots / hose Note also that the onboard Adaptec controller on the DS20 is disabled when you're running FreeBSD, and can't be used. It'd be nice to see how they do that so we could reverse it... The onboard Adaptec on the dp264 is not bootable, but does work with FreeBSD (4.0 and later). -- \\ 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 From owner-freebsd-alpha Fri Jan 14 16:39:36 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 10FAF14D1F for ; Fri, 14 Jan 2000 16:39:35 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA03303; Fri, 14 Jan 2000 16:46:24 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001150046.QAA03303@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Rob Harris Cc: freebsd-alpha@freebsd.org In-reply-to: Your message of "Fri, 14 Jan 2000 12:18:55 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jan 2000 16:46:24 -0800 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The onboard Adaptec controller on the UP2000 board is funky, and our support for it wasn't fixed until around the 7th of January. Earlier versions of the drive will die with the panic you're seeing, and there is no workaround apart from replacing the kernel on the kern.flp image. > grrr--- > > I just got in two UP2000 based systems. They refuse to boot off of the > latest SNAP floppy disks (both 10/30 and 01/01). It gets just past sc0, > then goes: > > panic: ahc0: brkadrint, Scratch or SCB Memory Parity Error at seqaddr=0x2 > > This behavior is consistent on both boxes I acquired (identically > configured). > > The REALLY odd thing is, when I connect a pre-made drive with an older > SNAP (10/30 or so) distribution and kernel on it, it boots just fine. > > What am I doing wrong? > > > -=[ Rob ]=- > ___________________________________________________________________________ > "He's old enough to know what's right, but young enough not to choose it. > He's noble enough to win the world, but weak enough to lose it." > --"New World Man" (Rush) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > -- \\ 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 From owner-freebsd-alpha Fri Jan 14 21:13:56 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.25.39]) by hub.freebsd.org (Postfix) with ESMTP id 2E72814E57 for ; Fri, 14 Jan 2000 21:13:55 -0800 (PST) (envelope-from manning@uclink4.berkeley.edu) Received: from uclink4.berkeley.edu (manning.HIP.Berkeley.EDU [136.152.33.239]) by uclink4.berkeley.edu (8.8.8/8.8.8) with ESMTP id VAA00039 for ; Fri, 14 Jan 2000 21:13:54 -0800 (PST) Message-ID: <388001E0.7388E9CE@uclink4.berkeley.edu> Date: Fri, 14 Jan 2000 21:13:04 -0800 From: manning@uclink4.berkeley.edu X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-alpha@FreeBSD.ORG Subject: installation booting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I dd'd the 3.3-STABLE 2.88mb boot.flp image to my 2nd scsi drive (dka1), and booted from there. It seems fine until it asks for the mfs_root disk. I just press enter (because boot.flp is both, right?) and then it says "load: can't find "/mfsroot" and then gives the press any key in 5 seconds, or enter to boot [kernel]. I can press enter and it goes fine, until it's loading the ethernet drivers. Then it gives me a freaky kernel panic. Is this because it can't find /mfsroot? I "pressed any key" and got the boot prompt, and looked at what was on the disk, and mfsroot wasn't there.. i assume that's because it's all in kernel.gz am i right? what can i do to fix this? should i redownload the boot.flp? -Jesse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 15 3:18:56 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 2CDE314D3F; Sat, 15 Jan 2000 03:18:54 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id MAA04547; Sat, 15 Jan 2000 12:07:45 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id MAA54765; Sat, 15 Jan 2000 12:11:03 +0100 (CET) (envelope-from wilko) Date: Sat, 15 Jan 2000 12:11:03 +0100 From: Wilko Bulte To: Mike Smith Cc: Andrew Gallatin , FreeBSD-alpha mailing list Subject: Re: current shot at AlphaHW.txt Message-ID: <20000115121103.H53766@yedi.iaf.nl> References: <14462.16191.409234.724569@grasshopper.cs.duke.edu> <200001142356.PAA02518@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001142356.PAA02518@mass.cdrom.com>; from msmith@FreeBSD.ORG on Fri, Jan 14, 2000 at 03:56:33PM -0800 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 14, 2000 at 03:56:33PM -0800, Mike Smith wrote: > > Notice the above edits about having 2 hoses, 3 pci slots / hose > > Note also that the onboard Adaptec controller on the DS20 is disabled Can you please tell me which chip it is so that I can include that info? > when you're running FreeBSD, and can't be used. It'd be nice to see how > they do that so we could reverse it... Who is 'they'? Does the SRM disable the chip or so? > The onboard Adaptec on the dp264 is not bootable, but does work with > FreeBSD (4.0 and later). Do you have any further info on DP264? -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message