Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jan 2000 08:40:13 +0100
From:      Wilko Bulte <wilko@yedi.iaf.nl>
To:        FreeBSD-alpha mailing list <freebsd-alpha@freebsd.org>
Subject:   current shot at AlphaHW.txt
Message-ID:  <20000112084013.A53647@yedi.iaf.nl>

next in thread | raw e-mail | index | archive | help
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 <wilko@freebsd.org>

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 <vendor_id><device_id>
	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<BWEN>
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<BWEN>
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 <nmanisca@vt.edu>
- Andrew Gallatin <gallatin@cs.duke.edu>
- Christian Weisgerber <naddy@mips.rhein-neckar.de>
- David O'Brien <obrien@NUXI.com>
- Wim Lemmers <wim.lemmers@compaq.com>

-- 
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000112084013.A53647>