diff options
| author | cvs2svn <cvs2svn@FreeBSD.org> | 1995-09-15 20:15:11 +0000 |
|---|---|---|
| committer | cvs2svn <cvs2svn@FreeBSD.org> | 1995-09-15 20:15:11 +0000 |
| commit | bfbc580797babffd502df152b40ad384c9638c2c (patch) | |
| tree | d1b8ea42f49e396daa8df631fbbd15a1973c8fdc /share | |
| parent | 93ecce1be0f50592ae4f2c3dc798a862c4fae52c (diff) | |
Notes
Diffstat (limited to 'share')
| -rw-r--r-- | share/doc/FAQ/Makefile | 6 | ||||
| -rw-r--r-- | share/doc/handbook/Makefile | 12 | ||||
| -rw-r--r-- | share/doc/handbook/boothelp.sgml | 50 | ||||
| -rw-r--r-- | share/doc/handbook/contrib.sgml | 300 | ||||
| -rw-r--r-- | share/doc/handbook/hw.sgml | 319 | ||||
| -rw-r--r-- | share/doc/handbook/mirrors.sgml | 410 | ||||
| -rw-r--r-- | share/doc/handbook/sections.sgml | 38 | ||||
| -rwxr-xr-x | share/examples/startslip/sldown.sh | 3 | ||||
| -rwxr-xr-x | share/examples/startslip/slip.sh | 4 | ||||
| -rwxr-xr-x | share/examples/startslip/slup.sh | 16 | ||||
| -rw-r--r-- | share/man/man4/man4.i386/asc.4 | 179 | ||||
| -rw-r--r-- | share/man/man4/man4.i386/meteor.4 | 771 | ||||
| -rw-r--r-- | share/mk/bsd.sgml.mk | 151 |
13 files changed, 2259 insertions, 0 deletions
diff --git a/share/doc/FAQ/Makefile b/share/doc/FAQ/Makefile new file mode 100644 index 0000000000000..40ecc8aa77906 --- /dev/null +++ b/share/doc/FAQ/Makefile @@ -0,0 +1,6 @@ +# $Id$ + +DOC= freebsd-faq +SRCS= freebsd-faq.sgml + +.include <bsd.sgml.mk> diff --git a/share/doc/handbook/Makefile b/share/doc/handbook/Makefile new file mode 100644 index 0000000000000..7bf538d5ff81c --- /dev/null +++ b/share/doc/handbook/Makefile @@ -0,0 +1,12 @@ +# $Id$ + +SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml +SRCS+= booting.sgml contrib.sgml ctm.sgml current.sgml dialup.sgml +SRCS+= diskless.sgml eresources.sgml glossary.sgml handbook.sgml +SRCS+= history.sgml hw.sgml install.sgml kerberos.sgml kerneldebug.sgml +SRCS+= memoryuse.sgml mirrors.sgml nfs.sgml nutshell.sgml porting.sgml +SRCS+= ports.sgml ppp.sgml relnotes.sgml scsi.sgml sections.sgml +SRCS+= slipc.sgml slips.sgml submitters.sgml sup.sgml +SRCS+= troubleshooting.sgml userppp.sgml + +.include <bsd.sgml.mk> diff --git a/share/doc/handbook/boothelp.sgml b/share/doc/handbook/boothelp.sgml new file mode 100644 index 0000000000000..fbda261aa6693 --- /dev/null +++ b/share/doc/handbook/boothelp.sgml @@ -0,0 +1,50 @@ +<!-- $Id$ --> +<!-- The FreeBSD Documentation Project --> + +<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [ + +<!-- Conditional flags for this version of the document --> +<!ENTITY % boothelp.only "INCLUDE"> +<!ENTITY % handbook.only "IGNORE"> + +<!-- Entity shorthand for authors' names and email addresses --> +<!ENTITY % authors SYSTEM "authors.sgml"> +%authors; + +<!-- Entity definitions for all the parts --> +<!ENTITY % sections SYSTEM "sections.sgml"> +%sections; + +]> + +<linuxdoc> + <book> + + <title>FreeBSD Installation + <author> + <name></name> + </author> + + <abstract>Welcome to FreeBSD! This guide describes the + FreeBSD installation process. To navigate through the + sections in this guide using the <bf>up</bf> and + <bf>down</bf> arrow keys to select a section you wish to + read. Then use the <bf>right arrow</bf> or the <bf>enter + key</bf> to view the section. You can backtrack through + sections you have read by using the <bf>left arrow</bf>. + </abstract> + + <chapt><heading>General information</heading> + &nutshell; + &history; + &relnotes; + + &install; + &troubleshooting; + &bibliography; + &eresources; + &hw; + &contrib; + + </book> +</linuxdoc> diff --git a/share/doc/handbook/contrib.sgml b/share/doc/handbook/contrib.sgml new file mode 100644 index 0000000000000..b3bd245e4a680 --- /dev/null +++ b/share/doc/handbook/contrib.sgml @@ -0,0 +1,300 @@ +<!-- $Id: contrib.sgml,v 1.14 1995/08/31 15:15:17 jkh Exp $ --> +<!-- The FreeBSD Documentation Project --> + +<chapt><heading>FreeBSD contributor list<label id="contrib"></heading> + + <sect><heading>Derived software contributors</heading> + + <p>This software was originally derived from William + F. Jolitz's 386BSD release 0.1, though almost none of the + original 386BSD specific code remains. This software has + been essentially reimplemented from the 4.4 BSD Lite + release provided by the Computer Science Research Group + (CSRG) at the University of California, Berkeley and + associated academic contributors. + + There are also portions of NetBSD that have been integrated + into FreeBSD as well, and we would therefore like to thank + all the contributors to NetBSD for their work. Despite + some occasionally rocky moments in relations between the + two groups, we both want essentially the same thing: More + BSD based operating systems on people's computers! We wish + the NetBSD group every success in their endevors. + + <sect><heading>Hardware contributors</heading> + + <p>A special thank-you to Walnut Creek CDROM for providing + the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are + being used for our development work, to say nothing of the + network access and other donations of hardware resources. + It would have been impossible to do this release without + their support. + + TRW Financial Systems, Inc. provided 130 PCs, three 68 GB + fileservers, twelve ethernets, two routers and an ATM + switch for debugging the diskless code. They also keep a + couple of FreeBSD hackers alive and busy. Thanks! + + Thanks also to Dermot McDonnell for his donation of a + Toshiba XM3401B CDROM drive. It's been most useful! + + Thanks to Chuck Robey <chuckr@eng.umd.edu> who's been + contributing his floppy tape streamer for experimental + work. + + <sect><heading>The FreeBSD core team<label id="contrib:core"></heading> + + <p>(in alphabetical order by first name): + + <itemize> + <item>Andrey A. Chernov <ache@FreeBSD.org> + <item>Bruce Evans <bde@FreeBSD.org> + <item>David Greenman <davidg@FreeBSD.org> + <item>Garrett A. Wollman <wollman@FreeBSD.org> + <item>Gary Palmer <gpalmer@FreeBSD.org> + <item>Jörg Wunsch <joerg@FreeBSD.org> + <item>John Dyson <dyson@FreeBSD.org> + <item>Jordan K. Hubbard <jkh@FreeBSD.org> + <item>Justin Gibbs <gibbs@FreeBSD.org> + <item>Poul-Henning Kamp <phk@FreeBSD.org> + <item>Rich Murphey <rich@FreeBSD.org> + <item>Rodney W. Grimes <rgrimes@FreeBSD.org> + <item>Satoshi Asami <asami@FreeBSD.org> + <item>Søren Schmidt <sos@FreeBSD.org> + </itemize> + + <sect><heading>Who is responsible for what</heading> + + <p><descrip> + <tag/President/ Jordan K. Hubbard <jkh@FreeBSD.org> + <tag/Principle Architect/ David Greenman <davidg@FreeBSD.org> + <tag/Documentation/ John Fieber <jfieber@FreeBSD.org> + <tag/Internationalization/ Andrey A. Chernov <ache@FreeBSD.org> + <tag/Networking/ Garrett A. Wollman <wollman@FreeBSD.org> + <tag/Postmaster/ Jonathan M. Bresler <jmb@FreeBSD.org> + <tag/Public Relations/ Jordan Hubbard <jkh@FreeBSD.org> + <tag/Release Coordinator/ Jordan Hubbard <jkh@FreeBSD.org> + <tag/System Administration/ Gary Palmer <gpalmer@FreeBSD.org> + <tag/Webmasters/ John Fieber <jfieber@FreeBSD.org> and + James L. Robinson <jlrobin@FreeBSD.org> + <tag/XFree86 Project, Inc. Liason/ Rich Murphey + <rich@FreeBSD.org> + </descrip> + + <sect><heading>Additional FreeBSD contributors</heading> + + <p>(in alphabetical order by first name): + + <itemize> + <item>Adam David <adam@veda.is> + <item>Adam Glass <glass@postgres.berkeley.edu> + <item>Akito Fujita <fujita@zoo.ncl.omron.co.jp> + <item>Alain Kalker <alain@Wit401402.student.utwente.nl> + <item>Andras Olah <olah@cs.utwente.nl> + <item>Andreas Klemm <andreas@knobel.GUN.de> + <item>Andrew Herbert <andrew@werple.apana.org.au> + <item>Andrew Moore <alm@FreeBSD.org> + <item>Anthony Yee-Hang Chan <yeehang@netcom.com> + <item>Atsushi Murai <amurai@spec.co.jp> + <item>Bill Fenner <fenner@parc.xerox.com> + <item>Bill Paul <wpaul@FreeBSD.org> + <item>Bob Wilcox <bob@obiwan.uucp> + <item>Brian Tao <taob@gate.sinica.edu.tw> + <item>Charles Hannum <mycroft@ai.mit.edu> + <item>Chris G. Demetriou <cgd@postgres.berkeley.edu> + <item>Chris Provenzano <proven@athena.mit.edu> + <item>Chris Stenton <jacs@gnome.co.uk> + <item>Chris Torek <torek@ee.lbl.gov> + <item>Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> + <item>Christoph Robitschko <chmr@edvz.tu-graz.ac.at> + <item>Chuck Robey <chuckr@Glue.umd.edu> + <item>Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> + <item>Craig Struble <cstruble@vt.edu> + <item>Curt Mayer <curt@toad.com> + <item>Danny J. Zerkel <dzerkel@feephi.phofarm.com> + <item>Dave Burgess <burgess@hrd769.brooks.af.mil> + <item>Dave Chapeskie <dchapes@zeus.leitch.com> + <item>Dave Rivers <rivers@ponds.uucp> + <item>David Dawes <dawes@physics.su.OZ.AU> + <item>Dean Huxley <dean@fsa.ca> + <item>Don Whiteside <dwhite@anshar.shadow.net> + <item>Eric L. Hernes <erich@lodgenet.com> + <item>Frank Durda IV <bsdmail@nemesis.lonestar.org> + <item>Frank Maclachlan <fpm@crash.cts.com> + <item>Frank Nobis <fn@trinity.radio-do.de> + <item>Gary A. Browning <gab10@griffcd.amdahl.com> + <item>Gary Clark II <gclarkii@FreeBSD.ORG> + <item>Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com> + <item>Gene Stark <stark@cs.sunysb.edu> + <item>Guido van Rooij <guido@gvr.win.tue.nl> + <item>Havard Eidnes <Havard.Eidnes@runit.sintef.no> + <item>Holger Veit <Holger.Veit@gmd.de> + <item>Ishii Masahiro, R. Kym Horsell + <item>J.T. Conklin <jtc@winsey.com> + <item>James Clark <jjc@jclark.com> + <item>James da Silva <jds@cs.umd.edu> et al + <item>Janusz Kokot <janek@gaja.ipan.lublin.pl> + <item>Javier Martin Rueda <jmrueda@diatel.upm.es> + <item>Jim Wilson <wilson@moria.cygnus.com> + <item>Jonathan Bresler < jmb@FreeBSD.ORG> + <item>Josh MacDonald <jmacd@uclink.berkeley.edu> + <item>Julian Elischer <julian@dialix.oz.au> + <item>Julian Stacey <stacey@guug.de> + (fallback: <julian@meepmeep.pcs.com>) + <item>Keith Bostic <bostic@toe.CS.Berkeley.EDU> + <item>Keith Moore <?> + <item>Kirk McKusick <mckusick@mckusick.com> + <item>Kurt Olsen <kurto@tiny.mcs.usu.edu> + <item>L Jonas Olsson <ljo@po.cwru.edu> + <item>Lars Fredriksen <fredriks@mcs.com> + <item>Lucas James <Lucas.James@ldjpc.apana.org.au> + <item>Marc Frajola <marc@dev.com> + <item>Marc Ramirez <mrami@mramirez.sy.yale.edu + <item>Marc van Kempen <wmbfmk@urc.tue.nl> + <item>Mark Murray <mark@grondar.za> + <item>Mark Tinguely <tinguely@plains.nodak.edu> + <tinguely@hookie.cs.ndsu.NoDak.edu> + <item>Martin Birgmeier + <item>Martin Renters <martin@innovus.com> + <item>Matt Thomas <thomas@lkg.dec.com> + <item>Michael Smith <msmith@atrad.adelaide.edu.au> + <item>Mike Pritchard <mpp@mpp.minn.net> + <item>NIIMI Satoshi <sa2c@and.or.jp> + <item>Nate Williams <nate@FreeBSD.org> + <item>Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> + <item>Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> + <item>Ollivier Robert <roberto@FreeBSD.org> + <item>Paul Kranenburg <pk@cs.few.eur.nl> + <item>Paul Mackerras <paulus@cs.anu.edu.au> + <item>Paul Richards <paul@FreeBSD.org> + <item>Paul Traina <pst@cisco.com> + <item>Peter Dufault <dufault@hda.com> + <item>Peter Wemm <peter@haywire.DIALix.COM> + <item>Philippe Charnier <charnier@lirmm.fr> + <item>Richard Stallman <rms@gnu.ai.mit.edu> + <item>Rob Shady <rls@id.net> + <item>Rob Snow <rsnow@txdirect.net> + <item>Sascha Wildner <swildner@channelz.GUN.de> + <item>Scott Mace <smace@FreeBSD.org> + <item>Sean Eric Fagan <sef@kithrup.com> + <item>Serge V. Vakulenko <vak@zebub.msk.su> + <item>Stefan Esser <se@MI.Uni-Koeln.DE> + <item>Stephen McKay <syssgm@devetir.qld.gov.au> + <item>Steve Gerakines <steve2@genesis.tiac.net> + <item>Steven Wallace <swallace@ece.uci.edu> + <item>Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> + <item>Terry Lee <terry@uivlsi.csl.uiuc.edu> + <item>Theo Deraadt <deraadt@fsa.ca> + <item>Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de> + <item>Tom Samplonius <tom@misery.sdf.com> + <item>Torbjorn Granlund <tege@matematik.su.se> + <item>Torsten Blum <torstenb@FreeBSD.ORG> + <item>Ugen J.S.Antsilevich <ugen@NetVision.net.il> + <item>Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> + <item>Wolfgang Stanglmeier <wolf@kintaro.cologne.de> + <item>Wolfram Schneider <wosch@cs.tu-berlin.de> + <item>Yuval Yarom <yval@cs.huji.ac.il> + <item>Yves Fonk <yves@cpcoup5.tn.tudelft.nl> + </itemize> + + <sect><heading>386BSD Patch kit patch contributors</heading> + + <p>(in alphabetical order by first name): + + <itemize> + <item>Adam Glass <glass@postgres.berkeley.edu> + <item>Adrian Hall <adrian@ibmpcug.co.uk> + <item>Andrey A. Chernov <ache@astral.msk.su> + <item>Andrew Herbert <andrew@werple.apana.org.au> + <item>Andrew Moore <alm@netcom.com> + <item>Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> + <item>Arne Henrik Juul <arnej@Lise.Unit.NO> + <item>Bakul Shah <bvs@bitblocks.com> + <item>Barry Lustig <barry@ictv.com> + <item>Bob Wilcox <bob@obiwan.uucp> + <item>Branko Lankester + <item>Brett Lymn <blymn@mulga.awadi.com.AU> + <item>Charles Hannum <mycroft@ai.mit.edu> + <item>Chris G. Demetriou <cgd@postgres.berkeley.edu> + <item>Chris Torek <torek@ee.lbl.gov> + <item>Christoph Robitschko <chmr@edvz.tu-graz.ac.at> + <item>Daniel Poirot <poirot@aio.jsc.nasa.gov> + <item>Dave Burgess <burgess@hrd769.brooks.af.mil> + <item>Dave Rivers <rivers@ponds.uucp> + <item>David Dawes <dawes@physics.su.OZ.AU> + <item>David Greenman <davidg@Root.COM> + <item>Eric J. Haug <ejh@slustl.slu.edu> + <item>Felix Gaehtgens <felix@escape.vsse.in-berlin.de> + <item>Frank Maclachlan <fpm@crash.cts.com> + <item>Gary A. Browning <gab10@griffcd.amdahl.com> + <item>Geoff Rehmet <csgr@alpha.ru.ac.za> + <item>Goran Hammarback <goran@astro.uu.se> + <item>Guido van Rooij <guido@gvr.win.tue.nl> + <item>Guy Harris <guy@auspex.com> + <item>Havard Eidnes <Havard.Eidnes@runit.sintef.no> + <item>Herb Peyerl <hpeyerl@novatel.cuc.ab.ca + <item>Holger Veit <Holger.Veit@gmd.de> + <item>Ishii Masahiro, R. Kym Horsell + <item>J.T. Conklin <jtc@winsey.com> + <item>Jagane D Sundar < jagane@netcom.com > + <item>James Clark <jjc@jclark.com> + <item>James Jegers <jimj@miller.cs.uwm.edu> + <item>James W. Dolter + <item>James da Silva <jds@cs.umd.edu> et al + <item>Jay Fenlason <hack@datacube.com> + <item>Jim Wilson <wilson@moria.cygnus.com> + <item>Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de> + <item>Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> + <item>John Dyson - <formerly dyson@ref.tfs.com> + <item>John Woods <jfw@eddie.mit.edu> + <item>Jordan K. Hubbard <jkh@whisker.hubbard.ie> + <item>Julian Elischer <julian@dialix.oz.au> + <item>Julian Stacey <stacey@guug.de> + (fallback: <julian@meepmeep.pcs.com>) + <item>Karl Lehenbauer <karl@NeoSoft.com> + <karl@one.neosoft.com> + <item>Keith Bostic <bostic@toe.CS.Berkeley.EDU> + <item>Ken Hughes + <item>Kent Talarico <kent@shipwreck.tsoft.net> + <item>Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> + <kml@mosquito.cis.ufl.edu> + <item>Marc Frajola <marc@dev.com> + <item>Mark Tinguely <tinguely@plains.nodak.edu> + <tinguely@hookie.cs.ndsu.NoDak.edu> + <item>Martin Renters <martin@innovus.com> + <item>Michael Galassi <nerd@percival.rain.com> + <item>Mike Durkin <mdurkin@tsoft.sf-bay.org> + <item>Nate Williams <nate@bsd.coe.montana.edu> + <item>Nick Handel <nhandel@NeoSoft.com> + <nick@madhouse.neosoft.com> + <item>Pace Willisson <pace@blitz.com> + <item>Paul Kranenburg <pk@cs.few.eur.nl> + <item>Paul Mackerras <paulus@cs.anu.edu.au> + <item>Paul Popelka <paulp@uts.amdahl.com> + <item>Peter da Silva <peter@NeoSoft.com> + <item>Phil Sutherland <philsuth@mycroft.dialix.oz.au> + <item>Ralf Friedl <friedl@informatik.uni-kl.de> + <item>Rick Macklem <root@snowhite.cis.uoguelph.ca> + <item>Robert D. Thrush <rd@phoenix.aii.com> + <item>Rodney W. Grimes <rgrimes@cdrom.com> + <item>Rog Egge <?> + <item>Sascha Wildner <swildner@channelz.GUN.de> + <item>Scott Burris <scott@pita.cns.ucla.edu> + <item>Scott Reynolds <scott@clmqt.marquette.mi.us> + <item>Sean Eric Fagan <sef@kithrup.com> + <item>Simon J Gerraty <sjg@melb.bull.oz.au> + <sjg@zen.void.oz.au> + <item>Stephen McKay <syssgm@devetir.qld.gov.au> + <item>Terry Lambert <terry@icarus.weber.edu> + <item>Terry Lee <terry@uivlsi.csl.uiuc.edu> + <item>Warren Toomey <wkt@csadfa.cs.adfa.oz.au> + <item>Wiljo Heinen <wiljo@freeside.ki.open.de> + <item>William Jolitz <withheld> + <item>Wolfgang Solfrank <ws@tools.de> + <item>Wolfgang Stanglmeier <wolf@dentaro.GUN.de> + <item>Yuval Yarom <yval@cs.huji.ac.il> + </itemize> + + Last, but not least, the release engineer would like to + thank: His Wife, for chocolate chip cookies, and some other + things. The DGB project @ TFS, for patience and tolerance. diff --git a/share/doc/handbook/hw.sgml b/share/doc/handbook/hw.sgml new file mode 100644 index 0000000000000..372997456200f --- /dev/null +++ b/share/doc/handbook/hw.sgml @@ -0,0 +1,319 @@ +<!-- $Id: hw.sgml,v 1.5 1995/08/29 01:42:37 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 + will 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> + + + diff --git a/share/doc/handbook/mirrors.sgml b/share/doc/handbook/mirrors.sgml new file mode 100644 index 0000000000000..bc6cefbfb7702 --- /dev/null +++ b/share/doc/handbook/mirrors.sgml @@ -0,0 +1,410 @@ +<!-- $Id:$ --> +<!-- The FreeBSD Documentation Project --> + +<!-- +<!doctype linuxdoc public "-//FreeBSD//DTD linuxdoc//EN"> +--> + +<chapt><heading>Obtaining FreeBSD<label id="mirrors"></heading> + +<p>The official sources for FreeBSD available via anonymous FTP from: +<quote> +<htmlurl url="ftp://ftp.freebsd.org/pub/FreeBSD" +name="ftp://ftp.FreeBSD.org/pub/FreeBSD"> +</quote> +and on CD-ROM from Walnut Creek CDROM: +<quote> + Walnut Creek CDROM<newline> + 1547 Palos Verdes Mall, Suite 260<newline> + Walnut Creek CA 94596 USA<newline> + Phone: +1 510 647-0783<newline> + Fax: +1 510 647-0821<newline> + Email: <htmlurl url="mailto:info@cdrom.com" name="info@cdrom.com"><newline> + WWW: <htmlurl url="http://www.cdrom.com/" name="http://www.cdrom.com/"> +</quote> + +<p>Additionally, FreeBSD is available via anonymous FTP from the + following mirror sites. If you choose to obtain FreeBSD via + anonymous FTP, please try to use a site near you. + +<descrip> +<tag>Australia</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.physics.usyd.edu.au/FreeBSD" + name="ftp://ftp.physics.usyd.edu.au/FreeBSD"><newline> + Contact: <htmlurl url="mailto:dawes@xfree86.org" + name="dawes@xfree86.org">. + +<item> +<htmlurl url="ftp://minnie.cs.adfa.oz.au/FreeBSD" + name="ftp://minnie.cs.adfa.oz.au/FreeBSD"><newline> + Contact: <htmlurl url="mailto:wkt@dolphin.cs.adfa.oz.au" + name="wkt@dolphin.cs.adfa.oz.au">. + +</itemize> + +<tag>Canada</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.synapse.net/contrib/FreeBSD" + name="ftp://ftp.synapse.net/contrib/FreeBSD"><newline> + Contact: <htmlurl url="mailto:evanc@synapse.net" + name="evanc@synapse.net">. + +</itemize> + +<tag>Finland</tag> + +<itemize> + +<item> +<htmlurl url="ftp://nic.funet.fi/pub/unix/FreeBSD" + name="ftp://nic.funet.fi/pub/unix/FreeBSD"><newline> + Contact: <htmlurl url="mailto:count@nic.funet.fi" + name="count@nic.funet.fi">. + +</itemize> + +<tag>France</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.ibp.fr/pub/FreeBSD" + name="ftp://ftp.ibp.fr/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:Remy.Card@ibp.fr" + name="Remy.Card@ibp.fr">. + +</itemize> + +<tag>Germany</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD" + name="ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp@ftp.fb9dv.uni-duisburg.de" + name="ftp@ftp.fb9dv.uni-duisburg.de">. + +<item> +<htmlurl url="ftp://gil.physik.rwth-aachen.de/pub/FreeBSD" + name="ftp://gil.physik.rwth-aachen.de/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:kuku@gil.physik.rwth-aachen.de" + name="kuku@gil.physik.rwth-aachen.de">. + +<item> +<htmlurl url="ftp://ftp.uni-paderborn.de/freebsd" + name="ftp://ftp.uni-paderborn.de/freebsd"><newline> + Contact: <htmlurl url="mailto:ftp@uni-paderborn.de" + name="ftp@uni-paderborn.de">. + +<item> +<htmlurl url="ftp://ftp.leo.org/pub/comp/os/bsd/FreeBSD" + name="ftp://ftp.leo.org/pub/comp/os/bsd/FreeBSD"><newline> + Contact: <htmlurl url="mailto:bsd@leo.org" + name="bsd@leo.org">. + +<item> +<htmlurl url="ftp://ftp.tu-dresden.de/pub/soft/unix/bsd/FreeBSD" + name="ftp://ftp.tu-dresden.de/pub/soft/unix/bsd/FreeBSD"><newline> + Contact: <htmlurl url="mailto:pdsowner@rcs1.urz.tu-dresden.de" + name="pdsowner@rcs1.urz.tu-dresden.de">. + +</itemize> + +<tag>Ireland</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.internet-eireann.ie/pub/FreeBSD" + name="ftp://ftp.internet-eireann.ie/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftpadmin@internet-eireann.ie" + name="ftpadmin@internet-eireann.ie">. + +</itemize> + +<tag>Israel</tag> + +<itemize> + +<item> +<htmlurl url="ftp://orgchem.weizmann.ac.il/pub/FreeBSD" + name="ftp://orgchem.weizmann.ac.il/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:serg@klara.weizmann.ac.il" + name="serg@klara.weizmann.ac.il">. + +</itemize> + +<tag>Hong Kong</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.hk.super.net/pub/FreeBSD" + name="g ftp://ftp.hk.super.net/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp-admin@HK.Super.NET" + name="ftp-admin@HK.Super.NET">. + +</itemize> + +<tag>Korea</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.cau.ac.kr/pub/FreeBSD" + name="ftp://ftp.cau.ac.kr/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftpadm@ftp.cau.ac.kr" + name="ftpadm@ftp.cau.ac.kr">. + +</itemize> + +<tag>Netherlands</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.nl.net/pub/os/FreeBSD" + name="ftp://ftp.nl.net/pub/os/FreeBSD"><newline> + Contact: <htmlurl url="mailto:archive@nl.net" + name="archive@nl.net">. + +</itemize> + +<tag>Russia</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.kiae.su/FreeBSD" + name="ftp://ftp.kiae.su/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp@ftp.kiae.su" + name="ftp@ftp.kiae.su">. + +</itemize> + +<tag>Sweden</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.luth.se/pub/FreeBSD" + name="ftp://ftp.luth.se/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ragge@ludd.luth.se" + name="ragge@ludd.luth.se">. + +</itemize> + +<tag>Taiwan</tag> + +<itemize> + +<item> +<htmlurl url="ftp://NCTUCCCA.edu.tw/Operating-Systems/FreeBSD" + name="ftp://NCTUCCCA.edu.tw/Operating-Systems/FreeBSD"><newline> + Contact: <htmlurl url="mailto:freebsd@NCTUCCCA.edu.tw" + name="freebsd@NCTUCCCA.edu.tw">. + +<item> +<htmlurl url="ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD" + name="ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp@netbsd.csie.nctu.edu.tw" + name="ftp@netbsd.csie.nctu.edu.tw">. + +</itemize> + +<tag>Thailand</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.nectec.or.th/pub/FreeBSD" + name="ftp://ftp.nectec.or.th/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftpadmin@ftp.nectec.or.th" + name="ftpadmin@ftp.nectec.or.th">. + +</itemize> + +<tag>USA</tag> + +<itemize> + +<item> +<htmlurl url="ftp://gatekeeper.dec.com/pub/BSD/FreeBSD" + name="ftp://gatekeeper.dec.com/pub/BSD/FreeBSD"><newline> + Contact: <htmlurl url="mailto:hubbard@gatekeeper.dec.com" + name="hubbard@gatekeeper.dec.com">. + +<item> +<htmlurl url="ftp://ftp.cybernetics.net/pub/FreeBSD" + name="ftp://ftp.cybernetics.net/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:michael@Cybernetics.NET" + name="michael@Cybernetics.NET">. + +<item> +<htmlurl url="ftp://ftp.neosoft.com/systems/FreeBSD" + name="ftp://ftp.neosoft.com/systems/FreeBSD"><newline> + Contact: <htmlurl url="mailto:smace@NeoSoft.COM" + name="smace@NeoSoft.COM">. + +<item> +<htmlurl url="ftp://kryten.atinc.com/pub/FreeBSD" + name="ftp://kryten.atinc.com/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:jmb@kryten.atinc.com" + name="jmb@kryten.atinc.com">. + +<item> +<htmlurl url="ftp://ftp.dataplex.net/pub/FreeBSD" + name="ftp://ftp.dataplex.net/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:rkw@dataplex.net" + name="rkw@dataplex.net">. + +<item> +<htmlurl url="ftp://ftp.cps.cmich.edu/pub/ftp.freebsd.org" + name="ftp://ftp.cps.cmich.edu/pub/ftp.freebsd.org"><newline> + Contact: <htmlurl url="mailto:ftpadmin@cps.cmich.edu" + name="ftpadmin@cps.cmich.edu">. + +<item> +<htmlurl url="ftp://ftp.cslab.vt.edu/pub/FreeBSD" + name="ftp://ftp.cslab.vt.edu/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp@ftp.cslab.vt.edu" + name="ftp@ftp.cslab.vt.edu">. + +</itemize> + +<tag>Japan</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.tokyonet.ad.jp/pub/FreeBSD" + name="ftp://ftp.tokyonet.ad.jp/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftpadmin@TokyoNet.AD.JP" + name="ftpadmin@TokyoNet.AD.JP">. + +<item> +<htmlurl url="ftp://ftp.tut.ac.jp/FreeBSD" + name="ftp://ftp.tut.ac.jp/FreeBSD"><newline> + Contact: <htmlurl url="mailto:<ashida@ftp.tut.ac.jp" + name="ashida@ftp.tut.ac.jp">. + +<item> +<htmlurl url="ftp://ftp.sra.co.jp/pub/os/FreeBSD" + name="ftp://ftp.sra.co.jp/pub/os/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp-admin@sra.co.jp" + name="ftp-admin@sra.co.jp">. + +<item> +<htmlurl url="ftp://ftp.ee.uec.ac.jp/pub/os/mirror/ftp.freebsd.org" + name="ftp://ftp.ee.uec.ac.jp/pub/os/mirror/ftp.freebsd.org"><newline> + Contact: <htmlurl url="mailto:ftp-admin@ftp.ee.uec.ac.jp" + name="ftp-admin@ftp.ee.uec.ac.jp">. + +<item> +<htmlurl url="ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD" + name="ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD"><newline> + Contact: <htmlurl url="mailto:tanig@isl.mei.co.jp" + name="tanig@isl.mei.co.jp">. + +<item> +<htmlurl url="ftp://ftp.waseda.ac.jp/pub/FreeBSD" + name="ftp://ftp.waseda.ac.jp/pub/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp-admin@waseda.ac.jp" + name="ftp-admin@waseda.ac.jp">. + +<item> +<htmlurl url="ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD" + name="ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD"><newline> + Contact: Yoshihiko USUI <htmlurl url="mailto:usui@pu-toyama.ac.jp" + name="usui@pu-toyama.ac.jp">. + +<item> +<htmlurl url="ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD" + name="ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD"><newline> + Contact: <htmlurl url="mailto:ftp-admin@u-aizu.ac.jp" + name="ftp-admin@u-aizu.ac.jp">. + +</itemize> + +<tag>UK</tag> + +<itemize> + +<item> +<htmlurl url="ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD" + name="ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD"><newline> + Contact: <htmlurl url="mailto:wizards@doc.ic.ac.uk" + name="wizards@doc.ic.ac.uk">. + +<item> +<htmlurl url="ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD" + name="ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD"><newline> + Contact: <htmlurl url="mailto:archive-admin@unix.hensa.ac.uk" + name="archive-admin@unix.hensa.ac.uk">. + +<item> +<htmlurl url="ftp://ftp.demon.co.uk/pub/BSD/FreeBSD" + name="ftp://ftp.demon.co.uk/pub/BSD/FreeBSD"><newline> + Contact: <htmlurl url="mailto:uploads@demon.net" + name="uploads@demon.net">. + +</itemize> +</descrip> + +The latest versions of export-restricted code for FreeBSD (2.0C or later) +(eBones and secure) are being made available at the following locations. +If you are outside the U.S. or Canada, please get secure (DES) and +eBones (Kerberos) from one of the following foreign distribution sites: + +<descrip> + +<tag>SouthAfrica</tag> + +<itemize> + +<item> +<htmlurl url="ftp://skeleton.mikom.csir.co.za/pub/FreeBSD" + name="ftp://skeleton.mikom.csir.co.za/pub/FreeBSD"><newline> + Contact: Mark Murray <htmlurl url="mailto:mark@grondar.za" + name="mark@grondar.za">. + +<item> +<htmlurl url="ftp://storm.sea.uct.ac.za/pub/FreeBSD" + name="ftp://storm.sea.uct.ac.za/pub/FreeBSD"><newline> + Contact: Shaun Courtney <htmlurl url="mailto:ftp@storm.sea.uct.ac.za" + name="ftp@storm.sea.uct.ac.za">. + +</itemize> + +<tag>Brazil</tag> + +<itemize> + +<item> +<htmlurl url="ftp://ftp.iqm.unicamp.br/pub/FreeBSD" + name="ftp://ftp.iqm.unicamp.br/pub/FreeBSD"><newline> + Contact: Pedro A M Vazquez <htmlurl url="mailto:vazquez@iqm.unicamp.br" + name="vazquez@iqm.unicamp.br">. + +</itemize> + +<tag>Finland</tag> + +<itemize> + +<item> +<htmlurl url="ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt" + name="ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt"><newline> + Contact: <htmlurl url="mailto:count@nic.funet.fi" + name="count@nic.funet.fi">. + +</itemize> +</descrip>
\ No newline at end of file diff --git a/share/doc/handbook/sections.sgml b/share/doc/handbook/sections.sgml new file mode 100644 index 0000000000000..0c8a2b1b42835 --- /dev/null +++ b/share/doc/handbook/sections.sgml @@ -0,0 +1,38 @@ +<!-- $Id$ --> +<!-- The FreeBSD Documentation Project --> + +<!-- Entities containing all the pieces of the handbook are --> +<!-- defined here --> + +<!ENTITY bibliography SYSTEM "bibliography.sgml"> +<!ENTITY basics SYSTEM "basics.sgml"> +<!ENTITY booting SYSTEM "booting.sgml"> +<!ENTITY contrib SYSTEM "contrib.sgml"> +<!ENTITY ctm SYSTEM "ctm.sgml"> +<!ENTITY current SYSTEM "current.sgml"> +<!ENTITY dialup SYSTEM "dialup.sgml"> +<!ENTITY diskless SYSTEM "diskless.sgml"> +<!ENTITY eresources SYSTEM "eresources.sgml"> +<!ENTITY glossary SYSTEM "glossary.sgml"> +<!ENTITY history SYSTEM "history.sgml"> +<!ENTITY hw SYSTEM "hw.sgml"> +<!ENTITY install SYSTEM "install.sgml"> +<!ENTITY kerberos SYSTEM "kerberos.sgml"> +<!ENTITY kernelconfig SYSTEM "kernelconfig.sgml"> +<!ENTITY kerneldebug SYSTEM "kerneldebug.sgml"> +<!ENTITY memoryuse SYSTEM "memoryuse.sgml"> +<!ENTITY mirrors SYSTEM "mirrors.sgml"> +<!ENTITY nfs SYSTEM "nfs.sgml"> +<!ENTITY nutshell SYSTEM "nutshell.sgml"> +<!ENTITY porting SYSTEM "porting.sgml"> +<!ENTITY ports SYSTEM "ports.sgml"> +<!ENTITY ppp SYSTEM "ppp.sgml"> +<!ENTITY relnotes SYSTEM "relnotes.sgml"> +<!ENTITY scsi SYSTEM "scsi.sgml"> +<!ENTITY slipc SYSTEM "slipc.sgml"> +<!ENTITY slips SYSTEM "slips.sgml"> +<!ENTITY submitters SYSTEM "submitters.sgml"> +<!ENTITY sup SYSTEM "sup.sgml"> +<!ENTITY troubleshooting SYSTEM "troubleshooting.sgml"> +<!ENTITY userppp SYSTEM "userppp.sgml"> + diff --git a/share/examples/startslip/sldown.sh b/share/examples/startslip/sldown.sh new file mode 100755 index 0000000000000..1f342a47b0c9c --- /dev/null +++ b/share/examples/startslip/sldown.sh @@ -0,0 +1,3 @@ +#!/bin/sh +/sbin/ifconfig $1 $2 +/sbin/route delete default diff --git a/share/examples/startslip/slip.sh b/share/examples/startslip/slip.sh new file mode 100755 index 0000000000000..1a0c1ad7f831b --- /dev/null +++ b/share/examples/startslip/slip.sh @@ -0,0 +1,4 @@ +#!/bin/sh +startslip -b 57600 -U ./slup.sh -D ./sldown.sh \ + -s atd<phone1> -s atd<phone2> -s atd<phone3> \ + -h -t 60 -w 2 -W 20 /dev/cuaa1 <login> <password> diff --git a/share/examples/startslip/slup.sh b/share/examples/startslip/slup.sh new file mode 100755 index 0000000000000..79cded3395585 --- /dev/null +++ b/share/examples/startslip/slup.sh @@ -0,0 +1,16 @@ +#!/bin/sh +myname=<my.ip.address> +gateway=<gateway.ip.address> +netmask=255.255.255.248 +tune1="link0 -link2" # force headers compression +tune2="mtu 296" # for FreeBSD 1.x host + +case $LINE in + 0) tune=$tune1;; # 1st phone connected + 1) tune=$tune2;; # 2nd phone connected + *) tune=;; # others +esac + +/sbin/ifconfig $1 $2 $tune +/sbin/ifconfig $1 inet $myname $gateway netmask $netmask +/sbin/route add default $gateway diff --git a/share/man/man4/man4.i386/asc.4 b/share/man/man4/man4.i386/asc.4 new file mode 100644 index 0000000000000..fc187f306bb13 --- /dev/null +++ b/share/man/man4/man4.i386/asc.4 @@ -0,0 +1,179 @@ +.\" asc(4) - manual page for the scanner device driver `asc' +.\" +.\" +.\" Copyright (c) 1995 Gunther Schadow, Luigi Rizzo. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgements: +.\" This product includes software developed by Gunther Schadow. +.\" This product includes software developed by Luigi Rizzo. +.\" 4. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.TH ASC 4 "January 6, 1995" FreeBSD "FreeBSD Programmer's Manual" +.SH NAME +\fBasc\fP - a device driver for a handy scanner +.SH SYNOPSIS +.TP +\fB#include <machine/asc_ioctl.h>\fP +.TP +\fBMinor number bits:\fP \fIuu d g p ...\fP +\fIuu\fP - unit asc0 .. asc3 +\fI d\fP - selects logging of \fIdebug\fP messages +\fI g\fP - selects \fIbitmap\fP vs. \fIgraymap\fP output +\fI p\fP - selects \fIraw\fP vs. portable \fIpnm\fP output +.TP +\fBdd if=/dev/asc0 of=rawfile bs=(width/8) count=(height) +.TP +\fBcat /dev/asc0p > pbmfile\fP +.PB +.SH DESCRIPTION +The \fBasc\fP character device driver currently handles the +GI1904-based hand scanner (e.g. Trust Amiscan Grey). +It uses DMA and interrupts. Input data from the scanner are +buffered, up to 50 scanlines are buffered in the driver. +.PP +The device can operate at four different \fIresolutions\fP: 100, 200, +300 and 400dpi. It produces a simple bitmap with the most significant bit +at the left side. The driver can optionally output the famous and +likely simple portable bitmap file format pbm(5) by Jef +Poskanzer. Thus the scans can easily processed by any graphic package +around (xpaint, xv, xli only to name some of them ...). +.PP +The \fIwidth\fP of the output bitmap is fixed as given by the +resolution value. However, the \fIheight\fP of the bitmap must be +supplied in \fIpnm\fP mode since the driver must know at what time the +'end-of-file' shall be reached. The default is to produce a +square image, i.e. \fIheight=width\fP. With this feature you are able to +directly copy the scanner output into a pbm file whith cat(1). Of +course you can obtain a similar effect by using dd(1) with the driver +in \fIraw\fP mode. +.PP +The \fIgraymap\fP output mode is not yet implemented into the driver. +It is even questionable if external programs would not do this job +better thereby not counting to the size of the kernel. Even though, I +do not know of tools which produce a graymap from a halftone bitmap. +.SH IOCTL REQUESTS +The ioctl requests that are served by \fBasc\fP are listed below. +There is a utility, called sasc(1), that provides access to these +requests from within shell. +.TP +ASC_GRES int +Get current resolution in dots per inch (dpi). +.TP +ASC_GWIDTH int +Get current width of the bitmap in pixels. +.TP +ASC_SHEIGHT int +Set the \fIheight\fP of the bitmap in \fIpnm\fP mode. This is actually +a limit on the amount of lines scannable after the first read +operation. When the limit is reached read will return 0. However, the +device is turned off only when a close is performed (either +explicitely or implicitely on exit of the calling process). +.TP +ASC_GHEIGHT int +Get the current height of the bitmap. +.TP +ASC_SBLEN int +Set the length of the buffer used internally to do the DMA transfer. +The buffer length is supplied in lines of the bitmap. Since the buffer +size limit is (currently) 0x3000 bytes the maximum number of lines +allowed will vary with the width of each line. This upper limit is +checked before it overwrites the current value and pases an ENOMEM in +the \fBerrno\fP variable. However, since the bitmap width can change +after a buffer length was selected a read request may fail with ENOMEM +if the buffer length turns out too high. It is generally wise to +choose long buffers rather than go save in order to obtain better +output. +.TP +ASC_GBLEN int +Get the current buffer length in lines. +.TP +ASC_SBTIME int +Set the timeout for the completion of reading one buffer. Since a +handy scanner is a human/computer interface timeout values are usually +higher than those of a flat scanner. Default is 15 seconds. After +timeout is reached the read operation will fail with EBUSY. Note that +the timeout timer starts anew for each buffer to be read and thus does +not cause you to scan faster for longer images. BLEN/BTIME is similar +as MIN/TIME in termios(4). +.TP +ASC_GBTIME int +Get the current buffer timeout. +.PP +All ioctl requests that modify a parameter except ASC_SBTIME do not +have an effect on an ongoing scan process, i.e. after the first read +request that follows open. You must close the device and open it again +for the new selections to take effect. Consequently, the selections +are not reset when you close or open the device. +.PP +Similarily, requests that read a value do not report the value that is +used for the ongoing scan process. The values needed during the scan +process are saved when it starts and thus are not accessed by ioctl +requests. +.PP +The BTIME value does, however, have an immediate effect on the ongoing +scan. Thus the timeout can for example be set to long until the user +starts scanning. It can then be set to a short amount to react +(nearly) immediately when the user stops. Note that the user should be +left time to at least fill one buffer without having to haste. +.PP +Note that the \fIpbm\fP versus \fIraw\fP mode selection is done by the +minor number not by ioctl requests. In \fIraw\fP mode the selected +height of the bitmap will have no effect. +.SH FILES +.TP 15 +.BI /dev/asc0 +device node for \fIraw\fP output, has minor number 0. +.TP +.BI /dev/asc0d +device node for \fIraw\fP output emiting \fIdebug\fP messages if the +ASCDEBUG option was given at compile time, has minor number 32. +.TP +.BI /dev/asc0p +device node for output in \fIpbm\fP file format, has minor number 8. +.TP +.BI /dev/asc0pd +device node for \fIpbm\fP and \fIdebug\fP mode, has minor number 40. +.PB +.SH DIAGNOSTICS +.TP +\fBASCDEBUG\fP +When you define this name as an `option' in the kernel configuration +you can get debug output if you access the driver with a minor number +whose debug bit (i.e. bit 5 out of 7) is set. +.SH SEE ALSO +.nh +open(2), +ioctl(2), +intro(2), +read(2), +close(2), +cat(1), +dd(1), +pbm(5), +pnm(1), +termios(4). +.hy +.SH BUGS +Ioctl support is not working yet. +.SH AUTHOR +Luigi Rizzo <luigi.rizzo@iet.unipi.it> diff --git a/share/man/man4/man4.i386/meteor.4 b/share/man/man4/man4.i386/meteor.4 new file mode 100644 index 0000000000000..c4c26185e2071 --- /dev/null +++ b/share/man/man4/man4.i386/meteor.4 @@ -0,0 +1,771 @@ +.Dd August 15, 1995 +.br +.in +0.5i +.Dt METEOR 4 +.Os FreeBSD +.Sh NAME +.Nm meteor +.Nd video capture driver +.Sh SYNOPSIS +.Nm video meteor +.Sh DESCRIPTION +The +.Xr meteor +driver provides support for a PCI +.Em video +capture. It allows the capture of 24 bit RGB, 16 bit RGB and 16 bit YUV +output formats. + +.Pp +.Sh Meteor Driver Installation +To use the Matrox Meteor card in your system, you need a computer +that support the PCI (preferably the Type 2 or better) interface bus. +It is recommended that the system has as more than 16 MB of RAM since this +capture card directly deposits the image to system RAM. +.Pp +The files required for Matrox Meteor card are: +.br +.in +0.5i +/sys/pci/meteor.c +.br +/sys/i386/include/ioctl_meteor.h (also known as: +.br +/usr/include/machine/ioctl_meteor.h) +.br +.in -0.5i +For FreeBSD release versions 2.1 and earlier, the following patch files are also required: +.br +.in +0.5i +meteor/usr/sys/i386/i386/conf.patch +.br +meteor/usr/sys/conf/files.patch +.br +meteor/sys/i386/conf/LINT.patch +.br +These files are available for anonymous ftp at: +.br +.in +0.5i +ftp://joy.cs.ndsu.nodak.edu/pub/meteor.tgz +.br +.in -1.0i +.Pp +1) In the configuration file, add the line (as shown in +meteor/usr/sys/i386/conf/LINT.patch): +.Pp +.Em device meteor0 +.Pp +2) There is also a couple of optional parameters you may use +.Pp +.Em options "METEOR_ALLOC_PAGES=xxx" +specifies the number of contiguous pages to allocate when successfully +probed. The default number of pages allocated by the kernel is 151. +This means that there are (151*4096) bytes available for use. +.Pp +.Em options METEOR_DEALLOC_PAGES +deallocate all pages when closing the device. Note, the chance of +contiguously re-allocating new pages are very small. The default +behavior is to not deallocate pages. +.Pp +.Em options "METEOR_DEALLOC_ABOVE=xxx" +deallocate all pages above the specified number. The default action is +to not deallocate above any pages. +.Pp +3) Make and install the kernel. +.Pp +4) Make the special file name: +.Pp +.Em mknod /dev/meteor0 c <major> 0 +The major number is determined by the placement of the device in conf.c. +The patch supplied with the driver will make the major number 67. +.Pp +.Sh Meteor Capture Modes +The Meteor capture driver has three modes of capture operation. +.Pp +1) Conventional read(2) interface. +.in +0.5i +.Pp +This mode is the easiest and slowest to use. This mode is great for +capturing a single field at little programming cost. +.Pp +In this mode, the user opens the device, set the capture mode +and size (See: METEORSETGEO ioctl call), and uses the read system +call to load the data into a buffer. +.Pp +meteor_read.c; read 400x300 RGB24 into a viewable PPM file +.Pp +.in -0.5i +.nf +#include <sys/fcntl.h> +#include <machine/ioctl_meteor.h> + +extern int errno; +#define ROWS 300 +#define COLS 400 +#define SIZE (ROWS * COLS * 4) +main() +{ + struct meteor_geomet geo; + char buf[SIZE],b[4],header[16],*p; + int i,o,c; + + if ((i = open("/dev/meteor0", O_RDONLY)) < 0) { + printf("open failed: %d\n", errno); + exit(1); + } + /* set up the capture type and size */ + geo.rows = ROWS; + geo.columns = COLS; + geo.frames = 1; + geo.oformat = METEOR_GEO_RGB24 ; + + if (ioctl(i, METEORSETGEO, &geo) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + c = METEOR_FMT_NTSC; + + if (ioctl(i, METEORSFMT, &c) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + c = METEOR_INPUT_DEV0; + + if (ioctl(i, METEORSINPUT, &c) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + if ((c=read(i, &buf[0], SIZE)) < SIZE) { + printf("read failed %d %d %d\n", c, i, errno); + close(i); + exit(1); + } + close(i); + + if ((o = open("rgb24.ppm", O_WRONLY | O_CREAT, 0644)) < 0) { + printf("ppm open failed: %d\n", errno); + exit(1); + } + + /* make PPM header and save to file */ + strcpy(&header[0], "P6 400 300 255 "); + header[2] = header[6] = header[10] = header[14] = '\n'; + write (o, &header[0], 15); + /* save the RGB data to PPM file */ + for (p = &buf[0]; p < &buf[SIZE]; ) { + b[2] = *p++; /* blue */ + b[1] = *p++; /* green */ + b[0] = *p++; /* red */ + *p++; /* NULL byte */ + write(o,&b[0], 3); /* not very efficient */ + } + close(o); + exit(0); +} +.if +.Pp + 2) Memory mapped single capture or unsynchronized continuous capture. +.in +0.5i +.Pp +The single capture mode is designed for conferencing tools such as nv. +These tools need to control the starting of the image capture and also +need several frames a second. The continuous capture mode is designed +for applications that want free-running data. +.Pp +In this mode, the user opens the device, set the capture mode +and size (See: METEORSETGEO ioctl call), memory maps the frame buffer +memory into the user process space, and issues either the +single-capture or the continuous capture call (See: METEORCAPTUR ioctl +call) to load the data into the memory mapped buffer. +.Pp +As explained in the METEORCAPTUR ioctl call, the single frame capture +ioctl will block until the capture is complete, the continuous capture +will return immediately. +.in -0.5i +.Pp + meteor_mmap_single_continuous.c +.Pp +.nf +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/fcntl.h> +#include <machine/ioctl_meteor.h> + +extern int errno; +#define ROWS 480 +#define COLS 640 +#define SIZE (ROW * COLS * 2) +main() +{ + struct meteor_geomet geo; + char buf[SIZE]; + char *mmbuf; + int i,c; + + if ((i = open("/dev/meteor0", O_RDONLY)) < 0) { + printf("open failed\n"); + exit(1); + } + + geo.rows = ROWS; + geo.columns = COLS; + geo.frames = 1; + geo.oformat = METEOR_GEO_RGB16 ; + + if (ioctl(i, METEORSETGEO, &geo) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + c = METEOR_FMT_NTSC; + + if (ioctl(i, METEORSFMT, &c) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + c = METEOR_INPUT_DEV0; + + if (ioctl(i, METEORSINPUT, &c) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + mmbuf=(char *)mmap((caddr_t)0, SIZE, PROT_READ, 0, i, (off_t)0); + +#ifdef SINGLE_MODE + /* single frame capture */ + c = METEOR_CAP_SINGLE ; + ioctl(i, METEORCAPTUR, &c); /* wait for the frame */ + + /* directly access the frame buffer array data in mmbuf */ +#else + /* continuous frame capture */ + c = METEOR_CAP_CONTINOUS ; + ioctl(i, METEORCAPTUR, &c); /* returns immediately */ + + /* directly access the frame buffer array data in mmbuf */ + + c = METEOR_CAP_STOP_CONT ; + ioctl(i, METEORCAPTUR, &c); /* close will also stop capture */ +#endif + + close(i); + exit(0); +} +.if +.Pp + 3) Memory mapped, multi-frame ring buffer synchronize capture. +.Pp +.in +0.5i +This continuous capture mode is synchronized with the application that +processes up to 32 frames. This gives the advantages of both single and +continuous capture modes. +.Pp +The kernel notifies the application of a new data by raising an +application defined signal. The driver also shares a structure with +the application that allows them to communicate which frame has been +written by the kernel and which frame has been read by the application. +.Pp +The shared structure starts on the first page after your data. The +structure address can be found by calculation: +.in +0.5i +.Pp +(number_rows * number_columns * pixel_depth + 4095) & 0xfffff000 +.in -0.5i +.Pp + or +.in +0.5i +.Pp +((number_rows * number_columns * pixel_depth + 4095)/4096) * 4096 +.in -0.5i +.Pp +The shared structure is of type struct meteor_mem. The two most +important fields are called active and num_active_buf. active +is a bitmap of frames written by the kernel. num_active_bufs is +a count of frames marked in the active field. When a frame is read +in by the driver, the num_active_bufs count is tested, if this +count is below the threshold of number of active frames (value +in meteor_mem's hiwat variable), the bit representing frame +number in the buffer is stored in the active variable, the +num_active_bufs is incremented, the kernel then raises the specified +signal to activate the user application. The user application's +responsibility when getting the signal is to check the active bitmap +to determine the lowest active frame, use the data as the application +desires, clear the bitmap entry for that frame, and decrement the +num_active_bufs. If the threshold of number of active frames (hiwat) +has been exceeded, no new frames or signal from the kernel will occur +until the num_active_bufs is less than or equal to lowat. +.Pp +The driver loads the frames in a round-robin fashion. it is expected +that the user removes them in the same order. The driver does not +check to see if the frame is already active. +.Pp +The frame_size and number of frames in the buffer are also provided +to the meteor_mem structure, but changing these fields in the +application will not change the operation of the driver. +.Pp +In programming for this mode, the user opens the device, sets the +geometry, mmaps the data/common control structure, then starts the +continuous capture mode. A special signal catcher is required to +process the frames as they are read by the kernel. +.Pp +When specifying the geometry (See: ioctl METEORSETGEO), it +is important that the number of frames is set greater than 1. +.in -0.5i +.Pp + skeleton_capture_n.c +.Pp +.nf +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/fcntl.h> +#include <sys/signal.h> +#include <machine/ioctl_meteor.h> + +int video; /* made global if you wish to stop capture in signal handler */ +caddr_t data_frames; +struct meteor_mem *common_mem; +extern int errno; + +#define FRAME_MAX + +void +usr2_catcher() +{ +#ifdef SIGNAL_STOP + struct meteor_capframe capframe; /* for ioctl */ +#endif + char *frame; + + /* find frame */ + frame = (char *) (data_frames + sig_cnt * common_mem->frame_size) ; + + /* add frame processing here */ + /* deactivate frame */ + common_mem->active &= ~(1 << (sig_cnt % 16)); + common_mem->num_active_bufs--; + + /* process next frame on next interrupt */ + sig_cnt = ((sig_cnt+1) % FRAME_MAX); + +#ifdef SIGNAL_STOP + if (some_condition_requiring_stopping) { + capframe.command=METEOR_CAP_STOP_FRAMES; + + if (ioctl(i, METEORCAPFRM, &capframe) < 0) { + printf("METEORCAPFRM failed %d\n", errno); + exit(1); + } + } +#endif +} + +main() +{ + struct meteor_geomet geo; + int height, width, depth, frames, size; + struct meteor_capframe capframe; + + if ((i = open("/dev/meteor0", O_RDONLY)) < 0) { + printf("open failed\n"); + exit(1); + } + printf("test %d %d\n", errno, i); + + height = geo.rows = 120; + width= geo.columns = 320; + frames = geo.frames = FRAME_MAX; + depth = 2; /* 2 bytes per pixel for RGB*/ + + + geo.oformat = METEOR_GEO_RGB16; + + if (ioctl(i, METEORSETGEO, &geo) < 0) { + printf("METEORSETGEO failed %d\n", errno); + exit(1); + } + + c = METEOR_FMT_NTSC; + + if (ioctl(i, METEORSFMT, &c) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + c = METEOR_INPUT_DEV0; + + if (ioctl(i, METEORSINPUT, &c) < 0) { + printf("ioctl failed: %d\n", errno); + exit(1); + } + + size = ((width*height*depth*frames+4095)/4096)*4096; + /* add one page after data for meteor_mem */ + data_frames = mmap((caddr_t)0, size + 4096, PROT_READ | PROT_WRITE, + 0, i, (off_t)0); + + if (data_frames == (caddr_t) -1) return (0); + + /* common_mem is located at page following data */ + common_mem = (struct meteor_mem *) (y + size); + + signal(SIGUSR2, usr2_catcher); /* catch new frame message */ + + capframe.command=METEOR_CAP_N_FRAMES; + capframe.signal=SIGUSR2; + capframe.lowat=12; /* must be < hiwat */ + capframe.hiwat=14; /* must be < FRAME_MAX */ + + /* start the sync capture */ + if (ioctl(i, METEORCAPFRM, &capframe) < 0) { + printf("METEORCAPFRM failed %d\n", errno); + exit(1); + } + + /* this is the background working area, or you can sleep */ + + + /* to stop capture */ + capframe.command=METEOR_CAP_STOP_FRAMES; + + if (ioctl(i, METEORCAPFRM, &capframe) < 0) { + printf("METEORCAPFRM failed %d\n", errno); + exit(1); + } +} +.if +.Pp +.Sh Meteor IOCTL Call and Parameters +.Pp +The Meteor capture driver has ioctl requests for capturing, reading card +status, for setting and reading the geometry, and for setting and reading the +attributes. +.Pp +IT IS VERY IMPORTANT TO CHECK FOR ERRORS ON THESE RETURNING IOCTLs. +Errors indicate that something is very wrong with the ioctl and the +application should not attempt to proceed further with capturing. The +meteor capture driver still makes attempts to stop the next capture step if +an error occurred in a previous step but was ignored by the application +programmer. +.Pp +1) ioctl requests METEORSETGEO and METEORGETGEO +.in +0.5i +METEORSETGEO and METEORGETGEO are used to set and read the input +size, input device, and output format for frame capture. +.Pp +These ioctl routines use the meteor_geomet structure that has the +following entries: +.Pp +.Bl -tag -width columns +.It Dv rows +number of rows (lines high) in output image +.It Dv columns +number of pixels in a row (width) in output image +.It Dv frames +number of frames in buffer. Should be 1, unless using +the multi-framed synchronous capture mode (METEORCAPFRM) +which REQUIRES frames to be larger than 1. +.Pp +Note: if rows, columns or frames is not changed, then +the existing values are used. The system defaults +is 640x480x1. +.It Dv oformat +you may choose one of the following output format: +.Bl -tag -width METEOR_GEO_YUV_PACKED +.It Dv METEOR_GEO_RGB16 +RGB 16 bits xrrrrrgg gggbbbbb default) +.It Dv METEOR_GEO_RGB24 +(RBG 24 bits packed in 32 bits: +00000000 rrrrrrrr gggggggg bbbbbbbb) +.It Dv METEOR_GEO_YUV_PACKED +(4-2-2 YUV 16 bits packed. byte format: +u0 y0 v0 y1 u1 y2 v1 y3 ...) +.It Dv METEOR_GEO_YUV_PLANER +(4-2-2 YUV 16 bits planer format: +rows * columns bytes of y +rows * column / 4 bytes of even u +rows * column / 4 bytes of even v +rows * column / 4 bytes of odd u +rows * column / 4 bytes of odd v) +.El +.El +.Pp +The METEORSETGEO ioctl will fail if more than one entry from a category +is selected. It is highly recommended that a METEORSETGEO is done +before capturing data because you cannot guarantee the initial mode +the card. +.Pp +The METEORSETGEO will also attempt to reallocate a new contiguous +kernel buffer if the new geometry exceeds the old geometry. On +other hand, if the new geometry will fit in the existing buffer, +the existing buffer is used. +.Pp +If METEORSETGEO fails the ioctl() will return a value of -1 and the +external variable errno will be set to: +.Pp +.Bl -tag -width EINVAL +.It Dv EINVAL +invalid meteor_geomet structure pointer, rows, columns, +frames were invalid. +.It Dv ENOMEM +could not allocate the contigous block. +.El +.in -0.5i +.Pp +2) ioctl requests METEORSFMT and METEORGFMT +.in +0.5i +.Pp +METEORSFMT and METEORGFMT are used to set and read the camera input +standard format. +.Pp +Possible formats are: +.Bl -tag -width METEOR_FMT_AUTOMODE +.It Dv METEOR_FMT_NTSC +NTSC (default mode) +.It Dv METEOR_FMT_PAL +PAL +.It Dv METEOR_FMT_SECAM +SECAM +.It Dv METEOR_FMT_AUTOMODE +Autodetect. +.El +.in -0.5i +.Pp +3) ioctl requests METEORSINPUT and METEORGINPUT +.in +0.5i +.Pp +METEORSINPUT and METEORGINPUT are used to set and read the camera +input device. Using the DB9 connector on the Meteor card, 4 input +devices can be connected and an input camera can be selected with this +ioctl. +.Pp +Possible formats are: +.Bl -tag -width METEOR_INPUT_DEV_SVIDEO +.It Dv METEOR_INPUT_DEV0 +(default if none specified) +.It Dv METEOR_INPUT_DEV_RCA +(same as METEOR_INPUT_DEV0) +.It Dv METEOR_INPUT_DEV1 +.It Dv METEOR_INPUT_DEV2 +.It Dv METEOR_INPUT_DEV_SVIDEO +(same as METEOR_INPUT_DEV2) +.El +.in -0.5i +.Pp +4) ioctl request METEORSTATUS +.in +0.5i +.Pp +METEORSTATUS is used to read the status of the Meteor capture card +and returns the following information: +.Pp +.Bl -tag -width METEOR_STATUS_ID_MASK +.It Dv METEOR_STATUS_ID_MASK +4 bit ID of the SAA7196 scaler chip. +.It Dv METEOR_STATUS_DIR +0 = scaler uses internal source. +.br +1 = scaler uses external data of expansion bus. +.It Dv METEOR_STATUS_OEF +0 = even field detected. +.br +1 = odd field detected. +.It Dv METEOR_STATUS_SVP +VRAM Port state: +.br +0 = inputs HFL and INCADDR inactive. +.br +1 = inputs HFL and INCADDR active. +.It Dv METEOR_STATUS_STTC +0 = TV horizontal time constant (slow). +.br +1 = VCR horizontal time constant (fast). +.It Dv METEOR_STATUS_HCLK +0 = Horizontal Phase Lock Loop locked. +.br +1 = Horizontal Phase Lock Loop unlocked. +.It Dv METEOR_STATUS_FIDT +0 = 50 Hz Field detected. +.br +1 = 60 Hz Field detected. +.It Dv METEOR_STATUS_ALTD +0 = no line alternating color burst detected. +.br +1 = line alternating color burst detected +(PAL/SECAM). +.It Dv METEOR_STATUS_CODE +0 = no color information detected. +.br +1 = color information detected. +.El +.in -0.5i +.Pp +5) ioctl request METEORCAPTUR +.in +0.5i +.Pp +METEORCAPTUR is used to single frame capture or unsynchronized +continuous capture. +.Pp +The single frame capture ioctl request will return only after a +frame has been captured and transfered to the frame buffer. +.Pp +The unsynchronized continuous capture will return immediately and +data is directly deposited into the buffer when it is available. +Since this is unsynchronized, it is possible the data is being +written by the kernel while being read by the application. +.Pp +These ioctl routines use the following settings: +following entries: +.Pp +.Bl -tag -width METEOR_CAP_CONTINOUS +.It Dv METEOR_CAP_SINGLE +capture one frame +.It Dv METEOR_CAP_CONTINOUS +unsynchronized continuous capture +.It Dv METEOR_CAP_STOP_CONT +stop the unsynchronized continuous +capture +.El +.Pp +If METEORCAPTUR fails the ioctl() will return a value of -1 and the +external variable errno will be set to: +.Pp +.Bl -tag -width EINVAL +.It Dv EINVAL +invalid capture command value +.It Dv ENXIO +there is not internal buffer to hold the frame. +this indicates the previous set geometry ioctl failed. +.It Dv EIO +card is already capturing. +.El +.in -0.5i +.Pp +6) ioctl request METEORCAPFRM +.in +0.5i +.Pp +METEORCAPFRM is used for synchronous capture of multiple frames. +.Pp +This ioctl routines use the meteor_capture structure that has the +following entries: +.Pp +.Bl -tag -width command +.It Dv command +possible values for command are: +.Bl -tag -width METEOR_CAP_STOP_FRAMES +.It Dv METEOR_CAP_STOP_FRAMES stop the capture does not use the +other variable in structure. +.It Dv METEOR_CAP_N_FRAMES start the capture using the other +variables in the structure as inputs +.El +.It Dv signal +signal to send to application when a new +frame has been captured. This signal will +only be raised if the captured frame is saved. +.It Dv lowat +see below +.It Dv hiwat +see below +.El +.Pp +When a new frame is completed, the driver checks the current unread +frame count stored in shared variable (the shared variable are stored +in the meteor_mem structure) num_active_buf, if the count is larger +than hiwat, the driver will not store any new frames and will not +send capture signal to the user application until the num_active_buf +is lower than lowat. +.Pp +If METEORCAPFRM fails the ioctl() will return a value of -1 and the +external variable errno will be set to: +.Pp +.Bl -tag -width EINVAL +.It Dv EINVAL +invalid meteor_geomet structure pointer or bad command. +.It Dv ENXIO +there is not internal buffer to hold the frame. +this indicates the previous set geometry ioctl failed. +.It Dv EIO +card is already capturing. +.El +.in -0.5i +.Pp +7) ioctl requests METEORSCHCV and METEORGCHCV +.in +0.5i +.Pp +METEORSCHCV and METEORGCHCV are used to set and get the chrominance +gain control and effects the UV output amplitude. +.Pp +If METEORSCHCV or METEORGCHCV fails the ioctl() will return a value +of -1 and the external variable errno will be set to: +.Pp +.Bl -tag -width EINVAL +.It Dv EINVAL +EINVAL +invalid unsigned char pointer. +.El +.in -0.5i +.Pp +8) ioctl requests METEORGHUE and METEORSHUE +.in +0.5i +.Pp +METEORGHUE and METEORSHUE are used to get and set the hue. The +signed character has legal values are from +127 which represent ++178.6 degrees to -128 which represents -180 degrees. +.Pp +If METEORGHUE or METEORSHUE fails the ioctl() will return a value of +-1 and the external variable errno will be set to: +.Pp +.Bl -tag -width EINVAL +.It Dv EINVAL +invalid signed char pointer. +.El +.in -0.5i +.Pp +9) ioctl requests METEORSCOUNT and METEORGCOUNT +.in +0.5i +.Pp +METEORGCOUNT is used to get the count of frame errors, DMA errors and +count of the number of frames captured that have occurred since +the device was opened. METEORSCOUNT can be used to reinitialize the +counters. +.Pp +This ioctl routines use the meteor_counts structure that has the +following entries: +.Pp +.Bl -tag -width frame_count +.It Dv fifo_errors +number of FIFO errors since device was opened. +.It Dv dma_errors number of DMA errors since device was opened. + +.It Dv frame_count number of frames captured since device was opened. +.El +.Pp +If METEORSCOUNT or METEORGCOUNT fails the ioctl() will return a value +of -1 and the external variable errno will be set to: +.Bl -tag -width EINVAL +.It Dv EINVAL +invalid meteor_counts structure pointer. +.El +.in -0.5i +.Pp +.Sh Known Bugs: +.in +0.5i +.Pp +1) IIC register is difficult to set. We got around that by adding a long +wait at each IIC register write. +.Pp +2) We had difficulties getting the Meteor capture card to work on systems +that used NCR chipset SCSI cards. It is possible that the Meteor and NCR SCSI +could work together using the newer TRITON motherboards. +.in -0.5i +.Pp +.Sh Authors: +.Pp +.Bl -tag -width Mark_Tinguely +.It Dv Jim Lowe +(james@miller.cs.uwm.edu) +.It Dv Mark Tinguely +(tinguely@plains.nodak.edu) +.El diff --git a/share/mk/bsd.sgml.mk b/share/mk/bsd.sgml.mk new file mode 100644 index 0000000000000..799dfdb0c5535 --- /dev/null +++ b/share/mk/bsd.sgml.mk @@ -0,0 +1,151 @@ +# bsd.sgml.mk - 8 Sep 1995 John Fieber +# This file is in the public domain. +# +# $Id: bsd.sgml.mk,v 1.1 1995/09/08 19:23:19 jfieber Exp $ + +.if exists(${.CURDIR}/../Makefile.inc) +.include "${.CURDIR}/../Makefile.inc" +.endif + +# FORMATS indicates which output formats will be generated. See +# the sgmlfmt(1) man page for a list of valid formats. +# If FORMATS is empty, nothing will be built or installed. +# Use SGMLOPTS to pass extra flags to sgmlfmt(1). + +FORMATS?= ascii html +SGMLFLAGS+= ${SGMLOPTS} + +VOLUME?= ${.CURDIR:T} +DOC?= ${.CURDIR:T} +BINDIR?= /usr/share/doc +SRCDIR?= ${.CURDIR} +DISTRIBUTION?= doc +SGMLFMT?= sgmlfmt +LPR?= lpr + +DOCS= ${FORMATS:S/^/${DOC}./g} + +.MAIN: all +all: ${DOCS} + +# If FORMATS is empty, do nothing +.if empty(FORMATS) +${DOC}. install- print- clean-: +.endif + +.if !target(obj) +.if defined(NOOBJ) +obj: +.else +obj: + @cd ${.CURDIR}; rm -f obj; \ + here=`pwd`; dest=/usr/obj`echo $$here | sed 's,^/usr/src,,'`; \ + ${ECHO} "$$here -> $$dest"; ln -s $$dest obj; \ + if test -d /usr/obj -a ! -d $$dest; then \ + mkdir -p $$dest; \ + else \ + true; \ + fi; +.endif +.endif + +clean: ${FORMATS:S/^/clean-/g} + rm -f [eE]rrs mklog + +cleandir: clean + cd ${.CURDIR}; rm -rf obj + +install: beforeinstall realinstall afterinstall + +.if !target(beforeinstall) +beforeinstall: + +.endif +.if !target(afterinstall) +afterinstall: + +.endif +.if !target(maninstall) +maninstall: + +.endif + +realinstall: ${FORMATS:S/^/install-/g} + +.if !target(print) +print: ${FORMATS:S/^/print-/g} + +.endif + +spell: ${SRCS} + (cd ${.CURDIR}; spell ${SRCS} ) | sort | \ + comm -23 - ${.CURDIR}/spell.ok > ${DOC}.spell + +.if !target(distribute) +distribute: + cd ${.CURDIR} ; $(MAKE) install DESTDIR=${DISTDIR}/${DISTRIBUTION} SHARED=copies +.endif + +.if !target(depend) +depend: + +.endif + + +# For each FORMATS type, define a build, install, clean and print target. +# Note that there is special case handling for html targets +# because the number of files generated is generally not possible +# to predict outside of sgmlfmt(1). + +.for _XFORMAT in ${FORMATS} + +# XXX This doesn't work: +# .if ${_FORMAT} == "foobar" +# but defining another variable does: (?!?!) + +_FORMAT = ${_XFORMAT} + +.if !target(print-${_FORMAT}) +.if ${_FORMAT} == "html" +print-${_FORMAT}: + +.else +print-${_FORMAT}: ${DOC}.${_FORMAT} + ${LPR} -P${.TARGET:S/print-//} ${DOC}.${_FORMAT} + +.endif +.endif + +.if !target(install-${_FORMAT}) +.if ${_FORMAT} == "html" +install-${_FORMAT}: ${DOC}.${_FORMAT} + ${INSTALL} ${COPY} -o ${MANOWN} -g ${MANGRP} -m ${MANMODE} \ + *.${.TARGET:S/install-//} ${DESTDIR}${BINDIR}/${VOLUME} + +.else +install-${_FORMAT}: ${DOC}.${_FORMAT} + ${INSTALL} ${COPY} -o ${MANOWN} -g ${MANGRP} -m ${MANMODE} \ + ${DOC}.${.TARGET:S/install-//} ${DESTDIR}${BINDIR}/${VOLUME} + +.endif +.endif + +.if !target(${DOC}.${_FORMAT}) +${DOC}.${_FORMAT}: ${SRCS} + ${SGMLFMT} -f ${.TARGET:S/${DOC}.//} ${SGMLFLAGS} ${.CURDIR}/${DOC}.sgml + +.endif + +.if !target(clean-${_FORMAT}) +.if ${_FORMAT} == "html" +clean-${_FORMAT}: + rm -f *.${.TARGET:S/clean-//} + +.else +clean-${_FORMAT}: + rm -f ${DOC}.${.TARGET:S/clean-//} + +.endif +.endif + +.endfor |