320 lines
11 KiB
Plaintext
320 lines
11 KiB
Plaintext
<!-- $Id: hw.sgml,v 1.4 1995/08/27 02:44:20 jfieber Exp $ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
<!--
|
|
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
|
-->
|
|
|
|
<chapt><heading>PC Hardware compatibility<label id="hw"></heading>
|
|
|
|
<p>Issues of hardware compatibility are among the most
|
|
troublesome in the computer industry today and FreeBSD is by
|
|
no means immune to trouble. In this respect, FreeBSD's
|
|
advantage of being able to run on inexpensive commidity PC
|
|
hardware is also its liability when it comes to support for
|
|
the amazing variety of components on the market. While it
|
|
would be impossible to provide a exhaustive listing of
|
|
hardware that FreeBSD supports, this section serves as a
|
|
catalog of the device drivers included with FreeBSD and the
|
|
hardware each drivers supports. Where possible and
|
|
appropriate, notes about specific products are included.
|
|
|
|
As FreeBSD is a volunteer project without a funded testing
|
|
department, we depend on you, the user, for much of the
|
|
information contained in this catalog. If you have direct
|
|
experience of hardware that does or does not work with
|
|
FreeBSD, please let us know by sending email to
|
|
<tt>doc@freebsd.org</tt>. Questions about supported hardware
|
|
should be directed to <tt>questions@freebsd.org</tt> (see
|
|
<ref id="eresources:mail" name="Mailing Lists"> for more
|
|
information). When submitting information or asking a
|
|
question, please remember to specify exactly what version of
|
|
FreeBSD you are using and include as many details of your
|
|
hardware as possible.
|
|
|
|
<sect><heading>Core/Processing<label id="hw:core"></heading>
|
|
|
|
<sect1><heading>Motherboards, busses, and chipsets</heading>
|
|
<sect2><heading>* ISA</heading>
|
|
<sect2><heading>* EISA</heading>
|
|
<sect2><heading>* VLB</heading>
|
|
<sect2><heading>PCI</heading>
|
|
|
|
<p><em>Contributed by &a.rgrimes;.<newline>25 April 1995.</em></p>
|
|
|
|
<p>Of the Intel PCI chip sets the following is a list
|
|
of brokenness from worst to best and a short
|
|
description of brokenness.</p>
|
|
|
|
<p><descrip>
|
|
|
|
<tag>Mercury:</tag> Cache coherency problems,
|
|
especially if there are ISA bus masters behind
|
|
the ISA to PCI bridge chip. Hardware flaw, only
|
|
known work around is to turn the cache
|
|
off.
|
|
|
|
<tag>Saturn-I <em>(ie, 82424ZX at rev 0, 1 or
|
|
2)</em>:</tag> write back cache coherency
|
|
problems. Hardware flaw, only known work around
|
|
is to set the external cache to write-through
|
|
mode. Upgrade to Saturn-II.
|
|
|
|
<tag>Saturn-II <em>(ie, 82424ZX at rev 3 or
|
|
4)</em>:</tag> Works fine, but many MB
|
|
manufactures leave out the external dirty bit
|
|
SRAM needed for write back operation. Work
|
|
arounds are either run it in write through mode,
|
|
or get the dirty bit SRAM installed. (I have
|
|
these for the ASUS PCI/I-486SP3G rev 1.6 and
|
|
later boards).
|
|
|
|
<tag>Neptune:</tag> Can not run more than 2 bus
|
|
master devices. Admitted Intel design flaw.
|
|
Workarounds include do not run more than 2 bus
|
|
masters, special hardware design to replace the
|
|
PCI bus arbiter (appears on Intel Altair board
|
|
and several other Intel server group MB's). And
|
|
of course Intel's official answer, move to the
|
|
Triton chip set, we ``fixed it there''.
|
|
|
|
<tag>Triton:</tag> No known cache coherency or bus
|
|
master problems, chip set does not implement
|
|
parity checking. Workaround for parity issue.
|
|
Wait for Triton-II.
|
|
|
|
<tag>Triton-II:</tag> Unknown, not yet shipping.
|
|
|
|
</descrip>
|
|
</p>
|
|
|
|
<sect1><heading>* CPUs/FPUs</heading>
|
|
<sect1><heading>* Memory</heading>
|
|
<sect1><heading>* BIOS</heading>
|
|
|
|
<sect><heading>Input/Output Devices<label id="hw:io"></heading>
|
|
|
|
<sect1><heading>* Video cards</heading>
|
|
<sect1><heading>* Sound cards</heading>
|
|
<sect1><heading>Serial ports and multiport cards</heading>
|
|
|
|
<p>The <tt>sio</tt> driver provides support for NS8250-,
|
|
NS16450-, NS16550 and NS16550A-based EIA RS-232C (CCITT
|
|
V.24) communications interfaces. Several multiport
|
|
cards are supported as well. See the <tt>sio(4)</tt>
|
|
manual page for detailed technical documentation.
|
|
|
|
<sect2><heading>Digiboard PC/8</heading>
|
|
|
|
<p><em>Contributed by &a.awebster;.<newline>26 August
|
|
1995.</em>
|
|
|
|
Here is a config snippet from a machine with
|
|
digiboard PC/8 with 16550. It has 8 modems connected
|
|
to these 8 lines, and they work just great. Do not
|
|
forget to add <tt>options "COM_MULTIPORT"</tt> or it
|
|
wo not work very well!
|
|
|
|
<tscreen><verb>
|
|
device sio4 at isa? port 0x100 tty flags 0xb05
|
|
device sio5 at isa? port 0x108 tty flags 0xb05
|
|
device sio6 at isa? port 0x110 tty flags 0xb05
|
|
device sio7 at isa? port 0x118 tty flags 0xb05
|
|
device sio8 at isa? port 0x120 tty flags 0xb05
|
|
device sio9 at isa? port 0x128 tty flags 0xb05
|
|
device sio10 at isa? port 0x130 tty flags 0xb05
|
|
device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
|
|
</verb></tscreen>
|
|
|
|
The trick in setting this up is that the MSB of the
|
|
flags represent the last SIO port, in this case 11 so
|
|
flags are 0xb05.
|
|
|
|
<sect2><heading>Boca 16</heading>
|
|
|
|
<p><em>Contributed by &a.whiteside;.<newline>26 August
|
|
1995.</em>
|
|
|
|
The procedures to make a Boca 16 pord board with
|
|
FreeBSD are pretty straighforward, but you will need
|
|
a couple things to make it work:
|
|
|
|
<enum>
|
|
<item>You either need the kernel sources installed
|
|
so you can recompile the necessary options or
|
|
you will need someone else to compile it for you.
|
|
The 2.0.5 default kernel does <bf>not</bf> come with
|
|
multiport support enabled and you will need to add
|
|
a device entry for each port anyways.
|
|
</item>
|
|
<item>Two, you will need to know the interrupt and IO
|
|
setting for your Boca Board so you can set these
|
|
options properly in the kernel.</item>
|
|
</enum>
|
|
|
|
One important note - the actual UART chips for the
|
|
Boca 16 are in the connector box, not on the internal
|
|
board itself. So if you have it unplugged, probes of
|
|
those ports will fail. I have never tested booting with
|
|
the box unplugged and plugging it back in, and I
|
|
suggest you do not either.
|
|
|
|
If you do not already have a custom kernel
|
|
configuration file set up, refer to <ref
|
|
id="kernelconfig" name="Kernel Configuration"> for
|
|
general procedurs. The following are the specifics
|
|
for the Boca 16 board and assume you are using the
|
|
kernel name MYKERNEL and editing with vi.
|
|
|
|
<enum>
|
|
<item>Add the line
|
|
<tscreen><verb>
|
|
options "COM_MULTIPORT"
|
|
</verb></tscreen>
|
|
to the config file.
|
|
</item>
|
|
|
|
<item>Where the current <tt>device sio
|
|
<em>xxx</em></tt> lines are, you will need to add
|
|
16 more devices. <em>Only the last device
|
|
includes the interrupt vector for the
|
|
board</em>. (See the <tt>sio(4)</tt> manual page
|
|
for detail as to why.)
|
|
|
|
The following example is for a Boca Board with an
|
|
interrupt of 3, and a base IO address 100h. The
|
|
IO address for Each port is +8 hexidecimal from
|
|
the previous port, thus the 100h, 108h, 110h...
|
|
addresses.
|
|
|
|
<tscreen><verb>
|
|
device sio1 at isa? port 0x100 tty flags 0x1005
|
|
device sio2 at isa? port 0x108 tty flags 0x1005
|
|
device sio3 at isa? port 0x110 tty flags 0x1005
|
|
device sio4 at isa? port 0x118 tty flags 0x1005
|
|
...
|
|
device sio15 at isa? port 0x170 tty flags 0x1005
|
|
device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
|
|
</verb></tscreen>
|
|
|
|
The flags entry <em>must</em> be changed from
|
|
this example unless you are using the exact same
|
|
sio assignments. Flags are set according to
|
|
0x<em>MYY</em> where <em>M</em> indicates the
|
|
minor number of the master port (the last port on
|
|
a Boca 16) and <em>YY</em> indicates if FIFO is
|
|
enabled or disabled(enabled), IRQ sharing is
|
|
used(yes) and if there is an AST/4 compatible IRQ
|
|
control register(no).
|
|
|
|
In this example,
|
|
<tscreen><verb>
|
|
flags 0x1005
|
|
</verb></tscreen>
|
|
|
|
indicates that the master port is sio16. If I
|
|
added another board and assigned sio17 through
|
|
sio28, the flags for all 16 ports on
|
|
<em>that</em> board would be 0x1C05, where 1C
|
|
indicates the minor number of the master port.
|
|
Do not change the 05 setting.</item>
|
|
|
|
<item>Save and complete the kernel configuration,
|
|
recompile, install and reboot.
|
|
|
|
Presuming you have successfully installed the
|
|
recompiled kernel and have it set to the correct
|
|
address and IRQ, your boot message should
|
|
indicate the successful probe of the Boca ports
|
|
as follows: (obviously the sio numbers, IO and
|
|
IRQ could be different)
|
|
|
|
<tscreen><verb>
|
|
sio1 at 0x100-0x107 flags 0x1005 on isa
|
|
sio1: type 16550A (multiport)
|
|
sio2 at 0x108-0x10f flags 0x1005 on isa
|
|
sio2: type 16550A (multiport)
|
|
sio3 at 0x110-0x117 flags 0x1005 on isa
|
|
sio3: type 16550A (multiport)
|
|
sio4 at 0x118-0x11f flags 0x1005 on isa
|
|
sio4: type 16550A (multiport)
|
|
sio5 at 0x120-0x127 flags 0x1005 on isa
|
|
sio5: type 16550A (multiport)
|
|
sio6 at 0x128-0x12f flags 0x1005 on isa
|
|
sio6: type 16550A (multiport)
|
|
sio7 at 0x130-0x137 flags 0x1005 on isa
|
|
sio7: type 16550A (multiport)
|
|
sio8 at 0x138-0x13f flags 0x1005 on isa
|
|
sio8: type 16550A (multiport)
|
|
sio9 at 0x140-0x147 flags 0x1005 on isa
|
|
sio9: type 16550A (multiport)
|
|
sio10 at 0x148-0x14f flags 0x1005 on isa
|
|
sio10: type 16550A (multiport)
|
|
sio11 at 0x150-0x157 flags 0x1005 on isa
|
|
sio11: type 16550A (multiport)
|
|
sio12 at 0x158-0x15f flags 0x1005 on isa
|
|
sio12: type 16550A (multiport)
|
|
sio13 at 0x160-0x167 flags 0x1005 on isa
|
|
sio13: type 16550A (multiport)
|
|
sio14 at 0x168-0x16f flags 0x1005 on isa
|
|
sio14: type 16550A (multiport)
|
|
sio15 at 0x170-0x177 flags 0x1005 on isa
|
|
sio15: type 16550A (multiport)
|
|
sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
|
|
sio16: type 16550A (multiport master)
|
|
</verb></tscreen>
|
|
|
|
If the messages go by too fast to see, <tt>dmesg
|
|
> more</tt> will show you the boot
|
|
messages.</item>
|
|
|
|
<item>Next, apprepriate entries in <tt>/dev</tt> for the devices
|
|
must be made using the <tt>/dev/MAKEDEV</tt>
|
|
script. After becoming root:
|
|
<tscreen>
|
|
cd /dev<newline>
|
|
./MAKEDEV tty1<newline>
|
|
./MAKEDEV cua1<newline>
|
|
<em>.. (everything inbetween)</em><newline>
|
|
./MAKEDEV ttyg<newline>
|
|
./MAKEDEV cuag
|
|
</tscreen>
|
|
|
|
If you do not want or need callout devices for some
|
|
reason, you can dispense with making the <tt>cua*</tt>
|
|
devices.</item>
|
|
|
|
<item>If you want a quick and sloppy way to make
|
|
sure the devices are working, you can simply plug
|
|
a modem into each port and (as root) <tt>echo at
|
|
> ttyd*</tt> for each device you have
|
|
made. You <em>should</em> see the RX lights flash
|
|
for each working port.</item>
|
|
</enum>
|
|
|
|
|
|
<sect1><heading>* Parallel ports</heading>
|
|
<sect1><heading>* Modems</heading>
|
|
<sect1><heading>* Network cards</heading>
|
|
<sect1><heading>* Keyboards</heading>
|
|
<sect1><heading>* Mice</heading>
|
|
<sect1><heading>* Other</heading>
|
|
|
|
<sect><heading>* Storage Devices<label id="hw:storage"></heading>
|
|
|
|
<sect1><heading>* Disk/tape controllers</heading>
|
|
<sect2><heading>* SCSI</heading>
|
|
<sect2><heading>* IDE</heading>
|
|
<sect2><heading>* Floppy</heading>
|
|
<sect1><heading>* Hard drives</heading>
|
|
<sect1><heading>* Tape drives</heading>
|
|
<sect1><heading>* CD-ROM drives</heading>
|
|
<sect1><heading>* Other</heading>
|
|
|
|
<sect><heading>* Other<label id="hw:other"></heading>
|
|
|
|
<sect1><heading>* PCMCIA</heading>
|
|
|
|
|
|
|