From owner-freebsd-alpha Sat Jan 8 12:48: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 2691314D68 for ; Sat, 8 Jan 2000 12:48:44 -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 VAA28059 for freebsd-alpha@freebsd.org; Sat, 8 Jan 2000 21:42:04 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA02156 for freebsd-alpha@freebsd.org; Sat, 8 Jan 2000 21:45:01 +0100 (CET) (envelope-from wilko) Date: Sat, 8 Jan 2000 21:45:01 +0100 From: Wilko Bulte To: FreeBSD-alpha mailing list Subject: first shot at AlphaHW.txt / please review... Message-ID: <20000108214500.A2099@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 Hi 'list', Please find below my first shot at the AlphaHW.txt file that I'm compiling. For obvious reasons I have started with systems that I am familiar with myself. Please review it for usability, paying particular attention to <> marked sections. If you are familiar with a system that is not yet listed please write up your part of the story so that I can include it in the AlphaHW.txt Cheers, Wilko ------- FreeBSD/alpha Hardware Information ================================== This file is maintained by Wilko Bulte Additions, corrections and constructive criticism are invited. Sat Jan 8 21:41:43 CET 2000 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. 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. In any case: no SRM -> no FreeBSD (or NetBSD, OpenBSD, Tru64 Unix or OpenVMS for that matter). 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. Some SRM versions (depends on the mainboard) can also boot from IDE disks. As I'm a SCSI-only guy I invite comments on 'GO/NOGO' here <> This problem might bite those who have machines that started it's life as a WinNT box. The ARC/AlphaBIOS knows about *other* adapters 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 IDE CDROMs and harddrives in some systems. You better check Alpha machines can generally 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. 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 32Mbytes. I have seen FreeBSD/alpha run on a 16Mbyte system but you will not like that. Note that the SRM steals 2Mbyte from the total system memory. For more serious use >= 64Mbyte is recommended. 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 models 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/AT 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. Features: - 21066 Alpha CPU at 166/233Mc (21068 CPUs are also possible, but are even slower. Never seen/used one) - memory bus: 64 bits - onboard 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 36bit 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 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 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. The NoName comes with a power connector 3.3Volts. No need to rush out to get a new power supply. An ordinary AT-style power supply will work just fine as long as you don't use 3.3V PCI option cards. SRM presumably cannot boot from IDE disks (have never tried this myself) <> 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!). This is the #1 problem that people encounter with NoNames. 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 CPU is either 166 or 233 Mc. It comes with a TGA based graphics onboard. The 3.5" floppy drive is a very compact laptop variant. Multias are somewhat notorious for dying of heat strokes. The very compact box does not really allow cooling very well. Please use the Multia on it's vertical stand, don't put it horizontally ('pizza style'). Most the discussion of the NoName applies to Multia too. 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 Features: - 21164 EV5 Alpha CPU, at 433, 500 or 600Mc [MX5] - 21164A EV56 Alpha CPU, at 433, 500 or 600Mc [MiataGL] - 2117x Core Logic ("Pyxis") chipset - onboard 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 ethernetchip, MiataGL has a 21143 chip) - 2x onboard 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 PCI-PCI bridge chip) 3 ISA slots (physically shared with the 32 bit PCI slots, via a Intel 82378IB PCI to ISA bridge) - 2x 16550A serial port - 1x parallel port <> - PS/2 keyboard & mouse port - USB interface [MiataGL only] 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. 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 88c15333" at the >>> SRM prompt. This example assumes the PCI ID of your PCI card is 88c15333, use the right valua for your card. 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. Sound: both MX5 and MiataGL have an onboard sound chip, an ESS1887 and an ESS1888 respectively. 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). The kernel configuration file for a Miata kernel must contain: options DEC_ST550 # Personal Workstation 433, 500, 600 * * DEC3000 family (the "Bird" machines) * The DEC3000 series were among the first Alpha machines ever produced. They are based on a proprietary I/O bus, the TurboChannel (TC) bus. These machines are built like tanks (watch your back). They are quite fast (considering their age) thanks to the good memory design. 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. They are called 'Birds' because their internal DEC codenames were bird names: DEC3000/400 'Sandpiper' 133Mc CPU, desktop DEC3000/500 'Flamingo' 150Mc CPU, floorstanding DEC3000/600 ' ? ' 175Mc CPU, desktop DEC3000/700, DEC3000/800, DEC3000/900, DEC3000/300 'Pelican' different variations, workstation class Features: - 21064 CPU (speeds varying between 133 and 200Mc) - memory bus: 256 bit, with ECC - memory: proprietary SIMMs (DEC3000/300 has different memory SIMMs) used in sets of 8 - builtin 10Mbit ethernet based on a Lance 7990 chip - one or two SCSI buses based on a NCR53C94 chip - 2 serial ports (one usable as a serial console) - embedded ISDN interface 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. 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). 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. Be prepared to run a serial console on the Birds. 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 275Mc - 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 - 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 The SRM console code is housed in an UV-erasable EPROM. No easy flash SRM upgrades for the EB64+ 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. For the EB64+ class machines the kernel config file must contain: options DEC_EB64PLUS 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. -- 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