* Make author's email address come out as mailto url's in HTML.
* Import my "Installation for the Impatient" to the install section. * Move Booting and memory use into a "Tech Topics" chapter; add DMA information. (Frank Durda IV) * Bring in ESDI section. (Wilko Bulte) * Bring in MD5/DES section. (Garrett Wollman) * Fix a couple problems with LaTeX output.
This commit is contained in:
John Fieber
parent
0ab588786c
commit
0fd1ece01f
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=91
10 changed files with 879 additions and 46 deletions
|
|
@ -1,11 +1,11 @@
|
|||
# $Id: Makefile,v 1.1 1995-09-08 19:34:26 jfieber Exp $
|
||||
# $Id: Makefile,v 1.2 1995-09-25 04:53:26 jfieber Exp $
|
||||
|
||||
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+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml dialup.sgml
|
||||
SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml glossary.sgml
|
||||
SRCS+= handbook.sgml history.sgml hw.sgml install.sgml kerberos.sgml
|
||||
SRCS+= kerneldebug.sgml memoryuse.sgml mirrors.sgml nfs.sgml nutshell.sgml
|
||||
SRCS+= porting.sgml ports.sgml ppp.sgml relnotes.sgml scsi.sgml sections.sgml
|
||||
SRCS+= slipc.sgml slips.sgml submitters.sgml sup.sgml
|
||||
SRCS+= troubleshooting.sgml userppp.sgml
|
||||
|
||||
|
|
|
|||
|
|
@ -1,29 +1,100 @@
|
|||
<!-- $Id: authors.sgml,v 1.7 1995-08-27 02:44:16 jfieber Exp $ -->
|
||||
<!-- $Id: authors.sgml,v 1.8 1995-09-25 04:53:27 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
Names and email address of contributing authors. Use these
|
||||
entities when referencing people.
|
||||
entities when referencing people. Please not the use of single
|
||||
and double quotes.
|
||||
-->
|
||||
|
||||
<!ENTITY a.asami "Satoshi Asami <tt><asami@FreeBSD.org></tt>">
|
||||
<!ENTITY a.awebster "Andrew Webster <tt><awebster@dataradio.com></tt>">
|
||||
<!ENTITY a.davidg "David Greenman <tt><davidg@Root.COM></tt>">
|
||||
<!ENTITY a.dufalt "Peter Dufault <tt><dufault@hda.com></tt>">
|
||||
<!ENTITY a.gclarkii "Gary Clark II <tt><gclarkii@FreeBSD.org></tt>">
|
||||
<!ENTITY a.gena "Gennady B. Sorokopud <tt><gena@NetVision.net.il></tt>">
|
||||
<!ENTITY a.ghelmer "Guy Helmer <tt><ghelmer@alpha.dsu.edu></tt>">
|
||||
<!ENTITY a.gpalmer "Gary Palmer <tt><gpalmer@FreeBSD.org></tt>">
|
||||
<!ENTITY a.jfieber "John Fieber <tt><jfieber@FreeBSD.org></tt>">
|
||||
<!ENTITY a.jkh "Jordan Hubbard <tt><jkh@FreeBSD.org></tt>">
|
||||
<!ENTITY a.joerg "Joerg Wunsch <tt><joerg_wunsch@uriah.heep.sax.de></tt>">
|
||||
<!ENTITY a.john "John Lind <tt><john@starfire.MN.ORG></tt>">
|
||||
<!ENTITY a.mark "Mark Murray <tt><mark@grondar.za></tt>">
|
||||
<!ENTITY a.martin "Martin Renters <tt><martin@innovus.com></tt>">
|
||||
<!ENTITY a.md "Mark Dapoz <tt><md@bsc.no></tt>">
|
||||
<!ENTITY a.nik "Nik Clayton <tt><nik@blueberry.co.uk></tt>">
|
||||
<!ENTITY a.phk "Poul-Henning Kamp <tt><phk@FreeBSD.org></tt>">
|
||||
<!ENTITY a.paul "Paul Richards <tt><paul@FreeBSD.org></tt>">
|
||||
<!ENTITY a.rgrimes "Rodney Grimes <tt><rgrimes@FreeBSD.org></tt>">
|
||||
<!ENTITY a.whiteside "Don Whiteside <tt><whiteside@acm.org></tt>">
|
||||
<!ENTITY a.wilko "Wilko Bulte <tt><wilko@yedi.iaf.nl></tt>">
|
||||
<!ENTITY a.asami "Satoshi Asami
|
||||
<tt><htmlurl url='mailto:asami@FreeBSD.org'
|
||||
name='<asami@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.awebster "Andrew Webster
|
||||
<tt><htmlurl url='mailto:awebster@dataradio.com'
|
||||
name='<awebster@dataradio.com>'></tt>">
|
||||
|
||||
<!ENTITY a.davidg "David Greenman
|
||||
<tt><htmlurl url='mailto:davidg@Root.COM'
|
||||
name='<davidg@Root.COM>'></tt>">
|
||||
|
||||
<!ENTITY a.dufalt "Peter Dufault
|
||||
<tt><htmlurl url='mailto:dufault@hda.com'
|
||||
name='<dufault@hda.com>'></tt>">
|
||||
|
||||
<!ENTITY a.gclarkii "Gary Clark II
|
||||
<tt><htmlurl url='mailto:gclarkii@FreeBSD.org'
|
||||
name='<gclarkii@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.gena "Gennady B. Sorokopud
|
||||
<tt><htmlurl url='mailto:gena@NetVision.net.il'
|
||||
name='<gena@NetVision.net.il>'></tt>">
|
||||
|
||||
<!ENTITY a.ghelmer "Guy Helmer
|
||||
<tt><htmlurl url='mailto:ghelmer@alpha.dsu.edu'
|
||||
name='<ghelmer@alpha.dsu.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.gpalmer "Gary Palmer
|
||||
<tt><htmlurl url='mailto:gpalmer@FreeBSD.org'
|
||||
name='<gpalmer@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.jfieber "John Fieber
|
||||
<tt><htmlurl url='mailto:jfieber@FreeBSD.org'
|
||||
name='<jfieber@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.jkh "Jordan Hubbard
|
||||
<tt><htmlurl url='mailto:jkh@FreeBSD.org'
|
||||
name='<jkh@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.joerg "Joerg Wunsch
|
||||
<tt><htmlurl url='mailto:joerg_wunsch@uriah.heep.sax.de'
|
||||
name='<joerg_wunsch@uriah.heep.sax.de>'></tt>">
|
||||
|
||||
<!ENTITY a.john "John Lind
|
||||
<tt><htmlurl url='mailto:john@starfire.MN.ORG'
|
||||
name='<john@starfire.MN.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.mark "Mark Murray
|
||||
<tt><htmlurl url='mailto:mark@grondar.za'
|
||||
name='<mark@grondar.za>'></tt>">
|
||||
|
||||
<!ENTITY a.martin "Martin Renters
|
||||
<tt><htmlurl url='mailto:martin@innovus.com'
|
||||
name='<martin@innovus.com>'></tt>">
|
||||
|
||||
<!ENTITY a.md "Mark Dapoz
|
||||
<tt><htmlurl url='mailto:md@bsc.no'
|
||||
name='<md@bsc.no>'></tt>">
|
||||
|
||||
<!ENTITY a.nik "Nik Clayton
|
||||
<tt><htmlurl url='mailto:nik@blueberry.co.uk'
|
||||
name='<nik@blueberry.co.uk>'></tt>">
|
||||
|
||||
<!ENTITY a.phk "Poul-Henning Kamp
|
||||
<tt><htmlurl url='mailto:phk@FreeBSD.org'
|
||||
name='<phk@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.paul "Paul Richards
|
||||
<tt><htmlurl url='mailto:paul@FreeBSD.org'
|
||||
name='<paul@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.rgrimes "Rodney Grimes
|
||||
<tt><htmlurl url='mailto:rgrimes@FreeBSD.org'
|
||||
name='<rgrimes@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.uhclem "Frank Durda IV
|
||||
<tt><htmlurl url='mailto:uhclem@nemesis.lonestar.org'
|
||||
name='<uhclem@nemesis.lonestar.org>'></tt>">
|
||||
|
||||
<!ENTITY a.whiteside "Don Whiteside
|
||||
<tt><htmlurl url='mailto:whiteside@acm.org'
|
||||
name='<whiteside@acm.org>'></tt>">
|
||||
|
||||
<!ENTITY a.wilko "Wilko Bulte
|
||||
<tt><htmlurl url='mailto:wilko@yedi.iaf.nl'
|
||||
name='<wilko@yedi.iaf.nl>'></tt>">
|
||||
|
||||
<!ENTITY a.wollman "Garrett Wollman
|
||||
<tt><htmlurl url='mailto:wollman@FreeBSD.org'
|
||||
name='<wollman@FreeBSD.org>'></tt>">
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
This conversion has been made by Ollivier Robert.
|
||||
|
||||
$Id: booting.sgml,v 1.5 1995-08-29 01:42:30 jfieber Exp $
|
||||
$Id: booting.sgml,v 1.6 1995-09-25 04:53:28 jfieber Exp $
|
||||
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
|
@ -22,7 +22,7 @@
|
|||
<toc>
|
||||
-->
|
||||
|
||||
<chapt><heading>The FreeBSD Booting Process<label id="booting"></heading>
|
||||
<sect><heading>The FreeBSD Booting Process<label id="booting"></heading>
|
||||
|
||||
<p><em>Contributed by &a.phk;. v1.1, April 26th.</em>
|
||||
|
||||
|
|
@ -30,7 +30,7 @@
|
|||
determine the root filesystem and initialize user-land things. This
|
||||
leads to some interesting possibilities shown below.
|
||||
|
||||
<sect><heading>Loading a kernel</heading>
|
||||
<sect1><heading>Loading a kernel</heading>
|
||||
<p>
|
||||
We presently have three basic mechanisms for loading the
|
||||
kernel as described below:
|
||||
|
|
@ -67,7 +67,7 @@
|
|||
</descrip>
|
||||
|
||||
|
||||
<sect><heading>Determine the root filesystem</heading>
|
||||
<sect1><heading>Determine the root filesystem</heading>
|
||||
<p>
|
||||
Once the kernel is loaded and the boot-code jumps to it, the kernel
|
||||
will initialize itself, trying to determine what hardware is
|
||||
|
|
@ -104,7 +104,7 @@
|
|||
</descrip>
|
||||
|
||||
|
||||
<sect><heading>Initialize user-land things</heading>
|
||||
<sect1><heading>Initialize user-land things</heading>
|
||||
<p>
|
||||
To get the user-land going, when the kernel has finished
|
||||
initialization, it will create a with ``<tt/pid == 1/'' and execute
|
||||
|
|
@ -119,7 +119,7 @@
|
|||
1/''.
|
||||
|
||||
|
||||
<sect><heading>Interesting combinations</heading>
|
||||
<sect1><heading>Interesting combinations</heading>
|
||||
<p>
|
||||
Boot a kernel with a MFS in it with a special <tt>/sbin/init</tt>
|
||||
which...
|
||||
|
|
|
|||
80
handbook/crypt.sgml
Normal file
80
handbook/crypt.sgml
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
<!-- $Id: crypt.sgml,v 1.1 1995-09-25 04:53:28 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>DES, MD5, and Crypt<label id="crypt"></heading>
|
||||
|
||||
<p><em>Contributed by &a.wollman;<newline>24 September 1995.</em>
|
||||
|
||||
<p><bf>History</bf>
|
||||
|
||||
<p>In order to protect the security of passwords on UN*X systems from
|
||||
being easily exposed, passwords have traditionally been scrambled in
|
||||
some way. Starting with Bell Labs' Seventh Edition Unix, passwords
|
||||
were encrypted using what the security people call a ``one-way hash
|
||||
function''. That is to say, the password is transformed in such a way
|
||||
that the original password cannot be regained except by brute-force
|
||||
searching the space of possible passwords. Unfortunately, the only
|
||||
secure method that was available to the AT&T researchers at the
|
||||
time was based on DES, the Data Encryption Standard. This causes only
|
||||
minimal difficulty for commercial vendors, but is a serious problem
|
||||
for an operating system like FreeBSD where all the source code is
|
||||
freely available, because national governments in many places like to
|
||||
place restrictions on cross-border transport of DES and other
|
||||
encryption software.
|
||||
|
||||
<p>So, the FreeBSD team was faced with a dilemma: how could we provide
|
||||
compatibility with all those UNIX systems out there while still not
|
||||
running afoul of the law? We decided to take a dual-track approach:
|
||||
we would make distributions which contained only a non-regulated
|
||||
password scrambler, and then provide as a separate add-on library the
|
||||
DES-based password hash. The password-scrambling function was moved
|
||||
out of the C library to a separate library, called `<tt>libcrypt</tt>'
|
||||
because the name of the C function to implement it is
|
||||
`<tt>crypt</tt>'. In FreeBSD 1.x and some pre-release 2.0 snapshots,
|
||||
the non-regulated scrambler uses an insecure function written by Nate
|
||||
Williams; in subsequent releases this was replaced by a mechanism
|
||||
using the RSA Data Security, Inc., MD5 one-way hash function. Because
|
||||
neither of these functions involve encryption, they are believed to be
|
||||
exportable from the US and importable into many other countries.
|
||||
|
||||
<p>Meanwhile, work was also underway on the DES-based password hash
|
||||
function. First, a version of the `<tt>crypt</tt>' function which was
|
||||
written outside the US was imported, thus synchronizing the US and
|
||||
non-US code. Then, the library was modified and split into two; the
|
||||
DES `<tt>libcrypt</tt>' contains only the code involved in performing
|
||||
the one-way password hash, and a separate `<tt>libcipher</tt>' was
|
||||
created with the entry points to actually perform encryption. The
|
||||
code was partitioned in this way to make it easier to get an export
|
||||
license for the compiled library.
|
||||
|
||||
<p><bf>Recognizing your `<tt>crypt</tt>' mechanism</bf>
|
||||
|
||||
<p>It is fairly easy to recognize whether a particular password
|
||||
string was created using the DES- or MD5-based hash function.
|
||||
MD5 password strings always begin with the characters
|
||||
`<tt>$1$</tt>'. DES password strings do not have
|
||||
any particular identifying characteristics, but they are shorter
|
||||
than MD5 passwords, and are coded in a 64-character alphabet
|
||||
which does not include the `<tt>$</tt>' character, so a
|
||||
relatively short string which doesn't begin with a dollar sign is
|
||||
very likely a DES password.
|
||||
|
||||
<p>Determining which library is being used on your system is fairly
|
||||
easy for most programs, except for those like `<tt>init</tt>' which
|
||||
are statically linked. (For those programs, the only way is to try
|
||||
them on a known password and see if it works.) Programs which use
|
||||
`<tt>crypt</tt>' are linked against `<tt>libcrypt</tt>', which for
|
||||
each type of library is a symbolic link to the appropriate
|
||||
implementation. For example, on a system using the DES versions:
|
||||
|
||||
<tscreen><verb>
|
||||
$ cd /usr/lib
|
||||
$ ls -l /usr/lib/libcrypt*
|
||||
lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a
|
||||
lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0
|
||||
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a
|
||||
</verb></tscreen>
|
||||
|
||||
On a system using the MD5-based libraries, the same links will be
|
||||
present, but the target will be `<tt>libscrypt</tt>' rather than
|
||||
`<tt>libdescrypt</tt>'.
|
||||
105
handbook/dma.sgml
Normal file
105
handbook/dma.sgml
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
<!-- $Id: dma.sgml,v 1.1 1995-09-25 04:53:29 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>PC DMA<label id="dma"></heading>
|
||||
|
||||
<p><em>Contributed by &a.uhclem;.<newline>
|
||||
31 August 1995.</em>
|
||||
|
||||
Posted to <htmlurl url="mailto:hackers@freebsd.org"
|
||||
name="freebsd-hackers@freebsd.org">:
|
||||
<quote>
|
||||
<p><em>Yes, as long as `single mode' is appropriate for you, there's no need
|
||||
to worry about TC. TC is intented for continuous mode. Well, i've
|
||||
just noticed that the PC DMAC cannot even generate an interrupt when
|
||||
ready... hmm, go figure, the Z80 DMAC did it.</em>
|
||||
<p><em>And yes, for `single mode', the masking trick will do it. The
|
||||
peripheral device will issue a DRQ signal for each transfered
|
||||
byte/word, and masking would prevent the DMAC from accepting new DRQs
|
||||
for this channel. Aborting a continuous mode transfer would not be so
|
||||
easy (or even impossible at all).</em>
|
||||
</quote>
|
||||
|
||||
Actually, masking is the correct procedure for all transfer modes on the
|
||||
8237, even autoinit mode, which is frequently used for audio operations
|
||||
since it allows seamless DMA transfers with no under/overruns.
|
||||
|
||||
You are generally correct about TC. All the TC signal does is
|
||||
when the counter on any channel in the DMA controller goes from
|
||||
one to zero, TC is asserted. What the peripherals are supposed
|
||||
to if they want to generate an interrupt when the transfer is
|
||||
through, is that peripheral device is supposed to look at
|
||||
<tt>(-DACK%d && TC && DEVICE_DMA_ACTIVE)</tt> and then
|
||||
latch an <tt>IRQ%d</tt> for the 8259 interrupt controller. Since there is
|
||||
only one TC signal, it is important that only the peripheral who
|
||||
is transferring data at that moment honor the TC signal.
|
||||
|
||||
The host CPU will eventually investigate the interrupt by having some driver
|
||||
poll the hardware associated with the peripheral, NOT the DMA controller.
|
||||
If a peripheral doesn't want an interrupt associated with the DMA counter
|
||||
reaching zero, it doesn't implement the circuitry to monitor TC.
|
||||
|
||||
Some sound cards realize that when the TC hits zero it means the DMA
|
||||
is now idle and that is really too late, so they don't use TC and
|
||||
instead allow the driver to program in a local counter value, which
|
||||
is usually set lower than the value programmed into the DMA. This means
|
||||
the peripheral can interrupt the CPU in advance of the DMA "running dry",
|
||||
allowing the CPU to be ready to reprogram the DMA the instant it finishes
|
||||
what it is doing, rather than incurring the latency later.
|
||||
|
||||
This also means that two or more different devices could share a
|
||||
DMA channel, by tristating <tt>DRQ%d</tt> when idle and only
|
||||
honoring <tt>-DACK%d</tt> when the device knows it is expecting
|
||||
the DMA to go active. (Iomega PC2B boards forgot this minor
|
||||
point and will transfer data even if they are not supposed to.)
|
||||
|
||||
|
||||
So, if you want to abort a 8237 DMA transfer of any kind, simply mask the
|
||||
bit for that DMA channel in the 8237. Note: You can't interrupt an individual
|
||||
transfer (byte or burst) in progress. Think about it... if the DMA is
|
||||
running, how is your OUT instruction going to be performed?
|
||||
The CPU has to be bus master for the OUT to be performed.
|
||||
|
||||
Since the 8237 DMA re-evaluates DMA channel priorities constantly, even if
|
||||
the DMA had already asserted HOLD (to request the bus from the CPU) when
|
||||
the OUT actually took place, the processor would still grant the bus to the
|
||||
DMA controller. The DMA controller would look for the highest-priority
|
||||
DMA source remaining (your interrupt is masked now) at that instant,
|
||||
and if none remained, the DMA will release HOLD and the processor will
|
||||
get the bus back after a few clocks.
|
||||
|
||||
There is a deadly race condition in this area, but if I remember right,
|
||||
you can't get into it via mis-programming the DMA, UNLESS you cause the DMA
|
||||
controller to be RESET. You should not do this. Effectively the CPU
|
||||
can give up the bus and the DMA doesn't do anything, including giving the
|
||||
bus back. Very annoying and after 16msec or so, all is over since
|
||||
refresh on main memory has started failing.
|
||||
|
||||
So, mask the DMA controller, then go do what you have to do to get the
|
||||
transfer aborted in the peripheral hardware. In some extremely stupid
|
||||
hardware (I could mention a few), you may have to program the DMA to
|
||||
transfer one more byte to a garbage target to get the peripheral hardware
|
||||
to go back to an idle state. Most hardware these days isn't that
|
||||
stupid.
|
||||
|
||||
Technically, you are supposed to mask the DMA channel, program the other
|
||||
settings (direction, address, length, etc), issue commands to the
|
||||
peripheral and then unmask the DMA channel once the peripheral commands have
|
||||
been accepted. The last two steps can be done out of order without
|
||||
harm, but you must always program the DMA channel while it is masked to
|
||||
avoid spraying data all over the place in the event the peripheral
|
||||
unexpected asserts <tt>DRQ%d</tt>.
|
||||
|
||||
If you need to pad-out an aborted buffer, once you have masked the
|
||||
DMA, you can ask it how many bytes it still had to go and what
|
||||
address it was to write to next. Your driver can then fill in the
|
||||
remaining area or do what needs to be done.
|
||||
|
||||
|
||||
Don't forget that the 8237 was designed for use with the 8085 and
|
||||
really isn't suited to the job that IBM gave it in the original PC.
|
||||
That's why the upper eight bits of DMA addressing appear to be lashed-on.
|
||||
They are. Look at the schematics of the original PC and you will
|
||||
the upper bits are kept in external latches that are enabled whenever
|
||||
the DMA is too. Very kludgy.
|
||||
|
||||
421
handbook/esdi.sgml
Normal file
421
handbook/esdi.sgml
Normal file
|
|
@ -0,0 +1,421 @@
|
|||
<!-- $Id: esdi.sgml,v 1.1 1995-09-25 04:53:30 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<title>An introduction to ESDI hard disks and their use with FreeBSD</title>
|
||||
<author>(c) 1995, Wilko Bulte, <tt/wilko@yedi.iaf.nl/
|
||||
<date>Tue Sep 12 20:48:44 MET DST 1995</date>
|
||||
|
||||
Copyright 1995, Wilko C. Bulte, Arnhem, The Netherlands
|
||||
|
||||
<abstract>
|
||||
This document describes the use of ESDI disks in combination
|
||||
with the FreeBSD operating system. Contrary to popular
|
||||
belief, this is possible and people are using ESDI based
|
||||
systems succesfully! This document tries to explain you
|
||||
how to do this.
|
||||
|
||||
If you find something missing, plain wrong or have useful
|
||||
comments on how to improve
|
||||
the document please send mail to <tt/wilko@yedi.iaf.nl/
|
||||
</abstract>
|
||||
-->
|
||||
|
||||
<sect><heading>ESDI hard disks and FreeBSD<label id="esdi"></heading>
|
||||
|
||||
<p><em>© 1995, &a.wilko;.<newline>24 September 1995.</em>
|
||||
|
||||
ESDI is an acronym that means Enhanced Small Device Interface.
|
||||
It is loosely based on the good old ST506/412 interface originally
|
||||
devised by Seagate Technology, the makers of the first affordable
|
||||
5.25" winchester disk.
|
||||
|
||||
The acronym says Enhanced, and rightly so. In the first place
|
||||
the speed of the interface is higher, 10 or 15 Mbits/second
|
||||
instead of the 5 Mbits/second of ST412 interfaced drives.
|
||||
Secondly some higher level commands are added, making the ESDI
|
||||
interface somewhat 'smarter' to the operating system driver
|
||||
writers. It is by no means as smart as SCSI by the way. ESDI
|
||||
is standardised by ANSI.
|
||||
|
||||
Capacities of the drives are boosted by putting more sectors
|
||||
on each track. Typical is 35 sectors per track, high capacity
|
||||
drives I've seen were up to 54 sectors/track.
|
||||
|
||||
Although ESDI has been largely obsoleted by IDE and SCSI interfaces,
|
||||
the availability of free or cheap surplus drives makes them
|
||||
ideal for low (or now) budget systems.
|
||||
|
||||
<sect1><heading>Concepts of ESDI</heading>
|
||||
<p>
|
||||
<sect2><heading>Physical connections</heading>
|
||||
<p>
|
||||
The ESDI interface uses two cables connected to each drive.
|
||||
One cable is a 34 pin flatcable edge connector that carries
|
||||
the command and status signals from the controller to the
|
||||
drive and viceversa. The command cable is daisy chained
|
||||
between all the drives. So, it forms a bus onto which all
|
||||
drives are connected.
|
||||
|
||||
The second cable is a a 20 pin flatcable edge connector that
|
||||
carries the data to and from the drive. This cable is radially
|
||||
connected, so each drive has it's own direct connection to the
|
||||
controller.
|
||||
|
||||
To the best of my knowledge PC ESDI controllers are limited
|
||||
to using a maximum of 2 drives per controller. This is
|
||||
compatibility feature(?) left over from the WD1003 standard
|
||||
that reserves only a single bit for device addressing.
|
||||
|
||||
<sect2><heading>Device addressing</heading>
|
||||
<p>
|
||||
On each command cable a maximum of 7 devices and 1 controller
|
||||
can be present. To enable the controller to uniquely
|
||||
identify which drive it addresses, each ESDI device is equipped
|
||||
with jumpers or switches to select the devices address.
|
||||
|
||||
On PC type controllers the first drive is set to address 0,
|
||||
the second disk to address 1. <it>Always make sure</it> you
|
||||
set each disk to an unique address! So, on a PC with it's
|
||||
two drives/controller maximum the first drive is drive 0, the
|
||||
second is drive 1.
|
||||
|
||||
<sect2><heading>Termination</heading>
|
||||
<p>
|
||||
The daisy chained command cable (the 34 pin cable remember?)
|
||||
needs to be terminated at the last drive on the chain.
|
||||
For this purpose ESDI drives come with a termination resistor
|
||||
network that can be removed or disabled by a jumper when it
|
||||
is not used.
|
||||
|
||||
So, one and <it>only</it> one drive, the one at
|
||||
the fartest end of the command
|
||||
cable has it's terminator installed/enabled. The controller
|
||||
automatically terminates the other end of the cable.
|
||||
Please note that this implies that the controller must be
|
||||
at one end of the cable and <it>not</it> in the middle.
|
||||
|
||||
<sect1><heading>Using ESDI disks with FreeBSD</heading>
|
||||
<p>
|
||||
Why is ESDI such a pain to get working in the first place?
|
||||
|
||||
People who tried ESDI disks with FreeBSD are known to have
|
||||
developed a profound sense of frustration. A combination of
|
||||
factors works against you to produce effects that are
|
||||
hard to understand when you have never seen them before.
|
||||
|
||||
This has also led to the popular legend ESDI and FreeBSD
|
||||
is a plain NO-GO.
|
||||
The following sections try to list all the pitfalls and
|
||||
solutions.
|
||||
|
||||
<sect2><heading>ESDI speed variants</heading>
|
||||
<p>
|
||||
As briefly mentioned before, ESDI comes in two speed flavours.
|
||||
The older drives and controllers use a 10 Mbits/second
|
||||
data transfer rate. Newer stuff uses 15 Mbits/second.
|
||||
|
||||
It is not hard to imagine that 15 Mbits/second drive cause
|
||||
problems on controllers laid out for 10 Mbits/second.
|
||||
As always, consult your controller <it>and</it> drive
|
||||
documentation to see if things match.
|
||||
|
||||
<sect2><heading>Stay on track</heading>
|
||||
<p>
|
||||
Mainstream ESDI drives use 34 to 36 sectors per track.
|
||||
Most (older) controllers cannot handle more than this
|
||||
number of sectors.
|
||||
Newer, higher capacity, drives use higher numbers of sectors
|
||||
per track. For instance, I own a 670 Mb drive that has
|
||||
54 sectors per track.
|
||||
|
||||
In my case, the controller could not handle this number
|
||||
of sectors. It proved to work well except that it only
|
||||
used 35 sectors on each track. This meant losing a
|
||||
lot of diskspace.
|
||||
|
||||
Once again, check the documentation of your hardware for
|
||||
more info. Going out-of-spec like in the example might
|
||||
or might not work. Give it a try or get another more
|
||||
capable controller.
|
||||
|
||||
<sect2><heading>Hard or soft sectoring</heading>
|
||||
<p>
|
||||
Most ESDI drives allow hard or soft sectoring to be
|
||||
selected using a jumper. Hard sectoring means that the
|
||||
drive will produce a sector pulse on the start of each
|
||||
new sector. The controller uses this pulse to tell when
|
||||
it should start to write or read.
|
||||
|
||||
Hard sectoring allows a selection of sector size (normally
|
||||
256, 512 or 1024 bytes per formatted sector). FreeBSD uses
|
||||
512 byte sectors. The number of sectors per track also varies
|
||||
while still using the same number of bytes per formatted sector.
|
||||
The number of <em>unformatted</em> bytes per sector varies,
|
||||
dependent on your controller it needs more or less overhead
|
||||
bytes to work correctly. Pushing more sectors on a track
|
||||
of course gives you more usable space, but might give
|
||||
problems if your controller needs more bytes than the
|
||||
drive offers.
|
||||
|
||||
In case of soft sectoring, the controller itself determines
|
||||
where to start/stop reading or writing. For ESDI
|
||||
hard sectoring is the default (at least on everything
|
||||
I came across). I never felt the urge to try soft sectoring.
|
||||
|
||||
In general, experiment with sector settings before you install
|
||||
FreeBSD because you need to re-run the low-level format
|
||||
after each change.
|
||||
|
||||
<sect2><heading>Low level formatting</heading>
|
||||
<p>
|
||||
ESDI drives need to be low level formatted before they
|
||||
are usable. A reformat is needed whenever you figgle
|
||||
with the number of sectors/track jumpers or the
|
||||
physical orientation of the drive (horizontal, vertical).
|
||||
So, first think, then format.
|
||||
The format time must not be underestimated, for big
|
||||
disks it can take hours.
|
||||
|
||||
After a low level format, a surface scan is done to
|
||||
find and flag bad sectors. Most disks have a
|
||||
manufacturer bad block list listed on a piece of paper
|
||||
or adhesive sticker. In addition, on most disks the
|
||||
list is also written onto the disk.
|
||||
Please use the manufacturer's list. It is much easier
|
||||
to remap a defect now than after FreeBSD is installed.
|
||||
|
||||
Stay away from low-level formatters that mark all
|
||||
sectors of a track as bad as soon as they find one
|
||||
bad sector. Not only does this waste space, it also
|
||||
and more importantly causes you grief with bad144
|
||||
(see the section on bad144).
|
||||
|
||||
<sect2><heading>Translations</heading>
|
||||
<p>
|
||||
Translations, although not exclusively a ESDI-only problem,
|
||||
might give you real trouble.
|
||||
Translations come in multiple flavours. Most of them
|
||||
have in common that they attempt to work around the
|
||||
limitations posed upon disk geometries by the original
|
||||
IBM PC/AT design (thanks IBM!).
|
||||
|
||||
First of all there is the (in)famous 1024 cylinder limit.
|
||||
For a system to be able to boot, the stuff (whatever
|
||||
operating system) must be in the first 1024 cylinders
|
||||
of a disk. Only 10 bits are available to encode the
|
||||
cylinder number. For the number of sectors the limit
|
||||
is 64 (0-63).
|
||||
When you combine the 1024 cylinder limit with the 16 head
|
||||
limit (also a design feature) you max out at fairly limited
|
||||
disk sizes.
|
||||
|
||||
To work around this problem, the manufacturers of ESDI
|
||||
PC controllers added a BIOS prom extension on their boards.
|
||||
This BIOS extension handles disk I/O for booting (and for
|
||||
some operating systems <it>all</it> disk I/O) by using
|
||||
translation. For instance, a big drive might be presented
|
||||
to the system as having 32 heads and 64 sectors/track.
|
||||
The result is that the number of cylinders is reduced to
|
||||
something below 1024 and is therefore usable by the system
|
||||
without problems.
|
||||
It is noteworthy to know that FreeBSD after it's kernel has
|
||||
started no longer uses the BIOS. More on this later.
|
||||
|
||||
A second reason for translations is the fact that most
|
||||
older system BIOSes could only handle drives with 17 sectors
|
||||
per track (the old ST412 standard). Newer system BIOSes
|
||||
usually have a user-defined drive type (in most cases this is
|
||||
drive type 47).
|
||||
|
||||
<em>Whatever you do to translations after reading this document,
|
||||
keep in mind that if you have multiple operating systems on the
|
||||
same disk, all must use the same translation</em>
|
||||
|
||||
While on the subject of translations, I've seen one controller
|
||||
type (but there are probably more like this) offer the option
|
||||
to logically split a drive in multiple partitions as a BIOS
|
||||
option. I had select 1 drive == 1 partition because this
|
||||
controller wrote this info onto the disk. On powerup it
|
||||
read the info and presented itself to the system based on
|
||||
the info from the disk.
|
||||
|
||||
<sect2><heading>Spare sectoring</heading>
|
||||
<p>
|
||||
Most ESDI controllers offer the possibility to remap bad sectors.
|
||||
During/after the low-level format of the disk bad sectors are
|
||||
marked as such, and a replacement sector is put in place
|
||||
(logically of course) of the bad one.
|
||||
|
||||
In most cases the remapping is done by using N-1 sectors on
|
||||
each track for actual datastorage, and sector N itself is
|
||||
the spare sector. N is the total number of sectors physically
|
||||
available on the track.
|
||||
The idea behind this is that the operating system sees
|
||||
a 'perfect' disk without bad sectors. In the case of
|
||||
FreeBSD this concept is not usable.
|
||||
|
||||
The problem is that the translation from <it>bad</it> to <it>good</it>
|
||||
is performed by the BIOS of the ESDI controller. FreeBSD,
|
||||
being a true 32 bit operating system, does not use the BIOS
|
||||
after it has been booted. Instead, it has device drivers that
|
||||
talk directly to the hardware.
|
||||
|
||||
<em>So: don't use spare sectoring, bad block remapping or
|
||||
whatever it may be called by the controller manufacturer when you
|
||||
want to use the disk for FreeBSD.</em>
|
||||
|
||||
<sect2><heading>Bad block handling</heading>
|
||||
<p>
|
||||
The preceding section leaves us with a problem. The controller's
|
||||
bad block handling is not usable and still FreeBSD's filesystems
|
||||
assume perfect media without any flaws.
|
||||
To solve this problem, FreeBSD use the <it>bad144</it> tool.
|
||||
Bad144 (named after a Digital Equipment standard for bad block
|
||||
handling) scans a FreeBSD slice for bad blocks. Having found
|
||||
these bad blocks, it writes a table with the offending block
|
||||
numbers to the end of the FreeBSD slice.
|
||||
|
||||
When the disk is in operation, the diskaccesses are checked
|
||||
against the table read from the disk. Whenever a blocknumber
|
||||
is requested that is in the bad144 list, a replacement block
|
||||
(also from the end of the FreeBSD slice) is used.
|
||||
In this way, the bad144 replacement scheme presents 'perfect'
|
||||
media to the FreeBSD filesystems.
|
||||
|
||||
There are a number of potential pitfalls associated with
|
||||
the use of bad144.
|
||||
First of all, the slice cannot have more than 126 bad sectors.
|
||||
If your drive has a high number of bad sectors, you might need
|
||||
to divide it into multiple FreeBSD slices each containing less
|
||||
than 126 bad sectors. Stay away from low-level format programs
|
||||
that mark <em>every</em> sector of a track as bad when
|
||||
they find a flaw on the track. As you can imagine, the
|
||||
126 limit is quickly reached when the low-level format is done
|
||||
this way.
|
||||
|
||||
Second, if the slice contains the root filesystem, the slice
|
||||
should be within the 1024 cylinder BIOS limit. During the
|
||||
boot process the bad144 list is read using the BIOS and this
|
||||
only succeeds when the list is within the 1024 cylinder limit.
|
||||
<em>Note</em> that the restriction is not that only the root
|
||||
<em>filesystem</em> must be within the 1024 cylinder limit, but
|
||||
rather the entire <em>slice</em> that contains the root filesystem.
|
||||
|
||||
|
||||
<sect2><heading>Kernel configuration</heading>
|
||||
<p>
|
||||
ESDI disks are handled by the same <it>wd</it>driver as
|
||||
IDE and ST412 MFM disks. The <it>wd</it> driver should work
|
||||
for all WD1003 compatible interfaces.
|
||||
|
||||
Most hardware is jumperable for one of two different I/O
|
||||
address ranges and IRQ lines. This allows you to have
|
||||
two wd type controllers in one system.
|
||||
|
||||
When your hardware allows non-standard strappings, you
|
||||
can use these with FreeBSD as long as you enter the
|
||||
correct info into the kernel config file.
|
||||
An example from the kernel config file (they live in
|
||||
<tt>/sys/i386/conf</tt> BTW).
|
||||
|
||||
<tscreen><verb>
|
||||
# First WD compatible controller
|
||||
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
|
||||
disk wd0 at wdc0 drive 0
|
||||
disk wd1 at wdc0 drive 1
|
||||
|
||||
# Second WD compatible controller
|
||||
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
|
||||
disk wd2 at wdc1 drive 0
|
||||
disk wd3 at wdc1 drive 1
|
||||
</verb></tscreen>
|
||||
|
||||
<!--
|
||||
<sect2><heading>Tuning your ESDI kernel setup</heading>
|
||||
<p>
|
||||
-->
|
||||
|
||||
<sect1><heading>Particulars on ESDI hardware</heading>
|
||||
<p>
|
||||
<sect2><heading>Adaptec 2320 controllers</heading>
|
||||
<p>
|
||||
I succesfully installed FreeBSD onto a ESDI disk controlled by a
|
||||
ACB-2320. No other operating system was present on the disk.
|
||||
|
||||
To do so I low level formatted the disk using NEFMT.EXE
|
||||
(<it>ftp</it>able from <it>www.adaptec.com</it>) and answered NO
|
||||
to the question whether the disk should be formatted with a
|
||||
spare sector on each track. The BIOS on the ACD-2320 was
|
||||
disabled. I used the 'free configurable' option in the system
|
||||
BIOS to allow the BIOS to boot it.
|
||||
|
||||
Before using NEFMT.EXE I tried to format the disk using the
|
||||
ACB-2320 BIOS builtin formatter. This proved to be a showstopper,
|
||||
because it didn't give me an option to disable spare sectoring.
|
||||
With spare sectoring enabled the FreeBSD installation
|
||||
process broke down on the bad144 run.
|
||||
|
||||
Please check carefully which ACB-232xy variant you have. The
|
||||
x is either 0 or 2, indicating a controller without or with
|
||||
a floppy controller on board.
|
||||
|
||||
The y is more interesting. It can either be a blank,
|
||||
a "A-8" or a "D". A blank indicates a plain 10 Mbits/second
|
||||
controller. An "A-8" indicates a 15 Mbits/second controller
|
||||
capable of handling 52 sectors/track.
|
||||
A "D" means a 15 Mbits/second controller that can also
|
||||
handle drives with > 36 sectors/track (also 52 ?).
|
||||
|
||||
All variations should be capable of using 1:1 interleaving. Use 1:1,
|
||||
FreeBSD is fast enough to handle it.
|
||||
|
||||
<sect2><heading>Western Digital WD1007 controllers</heading>
|
||||
<p>
|
||||
I succesfully installed FreeBSD onto a ESDI disk controlled by a
|
||||
WD1007 controller. To be precise, it was a WD1007-WA2. Other
|
||||
variations of the WD1007 do exist.
|
||||
|
||||
To get it to work, I had to disable the sector translation and
|
||||
the WD1007's onboard BIOS. This implied I could not use
|
||||
the low-level formatter built into this BIOS. Instead, I grabbed
|
||||
WDFMT.EXE from www.wdc.com Running this formatted my drive
|
||||
just fine.
|
||||
|
||||
<sect2><heading>Ultrastor U14F controllers</heading>
|
||||
<p>
|
||||
According to multiple reports from the net, Ultrastor ESDI
|
||||
boards work OK with FreeBSD. I lack any further info on
|
||||
particular settings.
|
||||
|
||||
<!--
|
||||
|
||||
<sect1><heading>Tracking down problems</heading>
|
||||
<p>
|
||||
-->
|
||||
|
||||
<sect1><heading>Further reading<label id="esdi:further-reading"></>
|
||||
<p>
|
||||
If you intend to do some serious ESDI hacking, you might want to
|
||||
have the official standard at hand:
|
||||
|
||||
The latest ANSI X3T10 committee document is:
|
||||
<itemize>
|
||||
<item>Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991]
|
||||
[X3T10/792D Rev 11]
|
||||
</itemize>
|
||||
On Usenet the newsgroup <htmlurl url="news:comp.periphs"
|
||||
name="comp.periphs"> is a noteworthy place to look
|
||||
for more info.
|
||||
|
||||
The World Wide Web (WWW) also proves to be a very handy info source:
|
||||
For info on Adaptec ESDI controllers see <htmlurl
|
||||
url="http://www.adaptec.com/">.
|
||||
For info on Western Digital controllers see <htmlurl
|
||||
url="http://www.wdc.com/">.
|
||||
|
||||
<sect1>Thanks to...
|
||||
<p>
|
||||
Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk
|
||||
for testing.
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: handbook.sgml,v 1.27 1995-09-03 21:12:27 jfieber Exp $ -->
|
||||
<!-- $Id: handbook.sgml,v 1.28 1995-09-25 04:53:31 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
<author>
|
||||
<name>The FreeBSD Documentation Project</name>
|
||||
</author>
|
||||
<date>August 31, 1995</date>
|
||||
<date>September 24, 1995</date>
|
||||
|
||||
<abstract>Welcome to FreeBSD! This handbook covers the
|
||||
installation and day to day use of <bf>FreeBSD Release
|
||||
|
|
@ -37,6 +37,9 @@ you are interested in helping with this project, send
|
|||
email to &a.jfieber; or to the FreeBSD Documentation
|
||||
Project mailing list <tt><htmlurl url="mailto:doc@freebsd.org"
|
||||
name="<doc@freebsd.org>"></tt>.
|
||||
The latest version of this document is always available from
|
||||
the <url url="http://www.freebsd.org/" name="FreeBSD World Wide
|
||||
Web server">.
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
|
|
@ -72,7 +75,7 @@ name="<doc@freebsd.org>"></tt>.
|
|||
<!-- &kernelconfig; -->
|
||||
|
||||
<chapt><heading>Users, groups and security</heading>
|
||||
<sect><heading>* DES, MD5 and Crypt</heading>
|
||||
&crypt;
|
||||
<sect><heading>* S/Key</heading>
|
||||
&kerberos;
|
||||
<sect><heading>* Firewalls</heading>
|
||||
|
|
@ -88,8 +91,9 @@ name="<doc@freebsd.org>"></tt>.
|
|||
name="The XFree86 Project, Inc">.
|
||||
|
||||
<chapt><heading>Managing hardware</heading>
|
||||
&scsi;
|
||||
<sect><heading>* Adding and reconfiguring disks</heading>
|
||||
&scsi;
|
||||
&esdi;
|
||||
<sect><heading>* Tapes and backups</heading>
|
||||
<sect><heading>* Serial ports</heading>
|
||||
<sect><heading>* Sound cards</heading>
|
||||
|
|
@ -127,8 +131,8 @@ name="<doc@freebsd.org>"></tt>.
|
|||
name="<gryphon@healer.com>"> for more information.
|
||||
|
||||
&nfs;
|
||||
<sect><heading>* Yellow Pages/NIS</heading>
|
||||
&diskless;
|
||||
<sect><heading>* Yellow Pages/NIS</heading>
|
||||
<sect><heading>* ISDN</heading>
|
||||
|
||||
<chapt><heading>* Mail</heading>
|
||||
|
|
@ -143,10 +147,9 @@ name="<doc@freebsd.org>"></tt>.
|
|||
⊃
|
||||
&kerneldebug;
|
||||
&submitters;
|
||||
&booting;
|
||||
&memoryuse;
|
||||
&troubleshooting;
|
||||
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>Appendices</heading>
|
||||
|
|
@ -154,6 +157,10 @@ name="<doc@freebsd.org>"></tt>.
|
|||
&bibliography;
|
||||
&eresources;
|
||||
&hw;
|
||||
<chapt><heading>Assorted technical topics</heading>
|
||||
&booting;
|
||||
&memoryuse;
|
||||
&dma;
|
||||
&contrib;
|
||||
&glossary;
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: install.sgml,v 1.9 1995-08-29 01:42:39 jfieber Exp $ -->
|
||||
<!-- $Id: install.sgml,v 1.10 1995-09-25 04:53:32 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -6,8 +6,154 @@
|
|||
-->
|
||||
<chapt><heading>Installing FreeBSD<label id="install"></heading>
|
||||
|
||||
<p>So, you would like to try out FreeBSD on your system?
|
||||
This section is a quick-start guide for what you need to
|
||||
do. FreeBSD can be installed from a variety of media
|
||||
including CD-ROM, floppy disk, magnetic tape, an MS-DOS
|
||||
partition, and if you have a network connection, via
|
||||
anonymous ftp or NFS.
|
||||
|
||||
Regardless of the installation media you choose, you can
|
||||
get started by downleading the <bf>installation disk</bf>
|
||||
as described below. Booting your computer with disk will
|
||||
provide important information about compatibility between
|
||||
FreeBSD and your hardware which could dictate which
|
||||
installation options are possible. It can also provide
|
||||
early clues to compatibilty problems that could prevent
|
||||
FreeBSD running on your system at all. If you plan on
|
||||
installing via anonymous FTP, then this installation disk
|
||||
is all you need to download.
|
||||
|
||||
For more information on obtaining the FreeBSD distribution
|
||||
itself, please see <ref id="mirrors" name="Obtaining
|
||||
FreeBSD"> in the Appendix.
|
||||
|
||||
So, to get the show on the road, follow these steps:
|
||||
<enum>
|
||||
|
||||
<item>Review the <ref id="install:hw" name="supported
|
||||
configurations"> section of this installation guide to
|
||||
be sure that your hardware is supported by FreeBSD. It
|
||||
may be helpful to make a list of any special cards you
|
||||
have installed, such as SCSI controllers, etherernet
|
||||
adapters or sound cards. This list should include
|
||||
relevant configuration parameters such as interrupts
|
||||
(IRQ) and IO port addresses. </item>
|
||||
|
||||
<item>Download the <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/2.0.5-RELEASE/UPDATES/boot.flp"
|
||||
name="installation boot disk image"> file to your hard
|
||||
drive, and be sure to tell your browser to
|
||||
<em>save</em> rather than <em>display</em>.
|
||||
<bf>Note:</bf> This disk image can be used for
|
||||
<em>both</em> 1.44 megabyte 3.5 inch floppy disks and
|
||||
1.2 megabyte 5.25 inch floppy disks.</item>
|
||||
|
||||
<item>Make the installation boot disk from the image file:
|
||||
<itemize>
|
||||
<item>If you are using MS-DOS download
|
||||
<url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/tools/dos-tools/rawrite.exe"
|
||||
name="rawrite.exe"> (tell your browser to <em>save</em> rather than
|
||||
<em>display</em>!), then run it:
|
||||
<tscreen><verb>
|
||||
C:\> rawrite
|
||||
</verb></tscreen> The
|
||||
program will prompt you for the floppy drive
|
||||
containing the disk you want to write to (A: or
|
||||
B:) and the name of the file to put on disk (boot.flp).
|
||||
</item>
|
||||
|
||||
<item>If you are using a UNIX system:
|
||||
<tscreen>
|
||||
% dd if=boot.flp of=<em>disk_device</em> bs=18k
|
||||
</tscreen>
|
||||
where <em>disk_device</em> is the <tt>/dev</tt>
|
||||
entry for the floppy drive. On FreeBSD systems, this
|
||||
is <tt>/dev/rfd0</tt> for the A: drive and
|
||||
<tt>/dev/rfd1</tt> for the B: drive.
|
||||
</item>
|
||||
</itemize>
|
||||
|
||||
</item>
|
||||
|
||||
<item>With the installation disk in the A: drive, reboot your
|
||||
computer. You should get a boot prompt something like this:
|
||||
<tscreen>
|
||||
>> FreeBSD BOOT ...<newline>
|
||||
Use hd(1,a)/kernel to boot sd0 when wd0 is also installed.<newline>
|
||||
Usage: [[hd(1,a)]/kernel][-abcCdhrsv]<newline>
|
||||
Use ? for file list or press Enter for defaults<newline>
|
||||
Boot:
|
||||
</tscreen>
|
||||
If you do <em>not</em> type anything, FreeBSD will automatically boot
|
||||
with its default configuration after a delay of about
|
||||
five seconds. As FreeBSD boots, it probes your computer
|
||||
to determine what hardware is installed. The results of
|
||||
this probing is displayed on the screen.
|
||||
</item>
|
||||
|
||||
<item>When the booting process is finished, The main FreeBSD
|
||||
installation menu will be displayed.</item>
|
||||
|
||||
</enum>
|
||||
|
||||
<p><bf>If something goes wrong...</bf>
|
||||
|
||||
<p>Due to limitations of the PC architecture, it is
|
||||
impossible for probing to be 100 percent reliable. In the event
|
||||
that your hardware is incorrectly identified, or that the
|
||||
probing causes your computer to lock up, first check the
|
||||
<ref id="install:hw" name="supported
|
||||
configurations"> section of this installation guide to be
|
||||
sure that your hardware is indeed supported by FreeBSD.
|
||||
|
||||
<p>If your hardware is supported, reset the computer and when
|
||||
the <tt>Boot:</tt> prompt comes up, type <bf>-c</bf>. This puts
|
||||
FreeBSD into a configuration mode where you can supply
|
||||
hints about your hardware. The FreeBSD kernel on the
|
||||
installation disk is configured assuming that most hardware
|
||||
devices are in their factory default configuration in terms
|
||||
of IRQs, IO addresses and DMA channels. If your hardware
|
||||
has been reconfigured, you will most likely need to use the
|
||||
<bf>-c</bf> option at boot to tell FreeBSD where things are.
|
||||
|
||||
<p>It is also possible that a probe for a device not present
|
||||
will cause a later probe for another device that is present
|
||||
to fail. In that case, the probes for the conflicting
|
||||
driver(s) should be disabled.
|
||||
|
||||
<p>In the configuration mode, you can:
|
||||
|
||||
<itemize>
|
||||
<item>List the device drivers installed in the kernel.</item>
|
||||
<item>Disable device drivers for hardware not present in your
|
||||
system.</item>
|
||||
<item>Change the IRQ, DRQ, and IO port addresses used by a
|
||||
device driver.</item>
|
||||
</itemize>
|
||||
|
||||
<p>While at the <tt>config></tt> prompt, type
|
||||
<tt>help</tt> for more information on the available
|
||||
commands. After adjusting the kernel to match how you have
|
||||
your hardware configured, type <tt>quit</tt> at the
|
||||
<tt>config></tt> prompt to continue booting with the new
|
||||
settings.
|
||||
|
||||
After FreeBSD has been installed, changes made in the
|
||||
configuration mode will be permanent so you do not have
|
||||
to reconfigure every time you boot. Even so, it is likely
|
||||
that you will want to build a custom kernel to optimize the
|
||||
performance of your system. See <ref id="kernelconfig"
|
||||
name="Kernel configuration"> for more information on
|
||||
creating custom kernels.
|
||||
|
||||
<sect><heading>MS-DOS user's Questions and Answers</heading>
|
||||
|
||||
<p>Many FreeBSD users wish to install FreeBSD on PCs inhabited
|
||||
by MS-DOS. Here are some commonly asked questions about
|
||||
installing FreeBSD on such systems.
|
||||
|
||||
<p><bf>Help! I have no space! Do I need to delete
|
||||
everything first?</bf>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!-- $Id: memoryuse.sgml,v 1.2 1995-06-30 17:37:42 jfieber Exp $ -->
|
||||
<!-- $Id: memoryuse.sgml,v 1.3 1995-09-25 04:53:33 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>PC memory utilization<label id="memoryuse"></heading>
|
||||
<sect><heading>PC memory utilization<label id="memoryuse"></heading>
|
||||
|
||||
<p><em>Contributed by &a.joerg;.<newline>
|
||||
16 Apr 1995.</em>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: sections.sgml,v 1.1 1995-09-03 21:12:29 jfieber Exp $ -->
|
||||
<!-- $Id: sections.sgml,v 1.2 1995-09-25 04:53:33 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!-- Entities containing all the pieces of the handbook are -->
|
||||
|
|
@ -10,9 +10,12 @@
|
|||
<!ENTITY contrib SYSTEM "contrib.sgml">
|
||||
<!ENTITY ctm SYSTEM "ctm.sgml">
|
||||
<!ENTITY current SYSTEM "current.sgml">
|
||||
<!ENTITY crypt SYSTEM "crypt.sgml">
|
||||
<!ENTITY dialup SYSTEM "dialup.sgml">
|
||||
<!ENTITY diskless SYSTEM "diskless.sgml">
|
||||
<!ENTITY dma SYSTEM "dma.sgml">
|
||||
<!ENTITY eresources SYSTEM "eresources.sgml">
|
||||
<!ENTITY esdi SYSTEM "esdi.sgml">
|
||||
<!ENTITY glossary SYSTEM "glossary.sgml">
|
||||
<!ENTITY history SYSTEM "history.sgml">
|
||||
<!ENTITY hw SYSTEM "hw.sgml">
|
||||
|
|
|
|||
Loading…
Reference in a new issue