|author||John Fieber <jfieber@FreeBSD.org>||1995-10-30 15:23:57 +0000|
|committer||John Fieber <jfieber@FreeBSD.org>||1995-10-30 15:23:57 +0000|
Completely rewritten section on DMA.
Submitted by: Frank Durda IV <firstname.lastname@example.org> Revised section on SCSI Submitted by: Wilko Bulte <email@example.com>
Notes: svn path=/branches/RELENG_2_1_0/; revision=136
2 files changed, 521 insertions, 120 deletions
diff --git a/handbook/dma.sgml b/handbook/dma.sgml
index db63b82b8b..cc18402471 100644
@@ -1,105 +1,511 @@
-<!-- $Id: dma.sgml,v 1.1 1995-09-25 04:53:29 jfieber Exp $ -->
+<!-- $Id: dma.sgml,v 184.108.40.206 1995-10-30 15:23:53 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:firstname.lastname@example.org"
-<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>
-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
-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.
+<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
+<!ENTITY % authors SYSTEM "authors.sgml">
+ <sect><heading>DMA: What it is and how it works<label id="dma"></heading>
+ <p><em>Copyright © 1995 &a.uhclem;, All Rights Reserved.<newline>
+ 18 October 1995.</em>
+<!-- Version 1(1) -->
+ Direct Memory Access (DMA) is a method of allowing data to
+ be moved from one location to another in a computer without
+ intervention from the central processor (CPU).
+ The way that the DMA function is implemented varies between
+ computer architectures, so this discussion will limit
+ itself to the implementation and workings of the DMA
+ subsystem on the IBM Personal Computer (PC), the IBM PC/AT
+ and all of its successors and clones.
+ The PC DMA subsystem is based on the Intel 8237 DMA
+ controller. The 8237 contains four DMA channels that can
+ be programmed independently and any of the channels may be
+ active at any moment. These channels are numbered 0, 1, 2
+ and 3. Starting with the PC/AT, IBM added a second 8237
+ chip, and numbered those channels 4, 5, 6 and 7.
+ The original DMA controller (0, 1, 2 and 3) moves one byte
+ in each transfer. The second DMA controller (4, 5, 6, and
+ 7) moves 16-bits in each transfer. The two controllers are
+ identical and the difference in transfer size is caused by
+ the way the second controller is wired into the system.
+ The 8237 has two electrical signals for each channel, named
+ DRQ and -DACK. There are additional signals that with the
+ names HRQ (Hold Request), HLDA (Hold Acknowledge), -EOP
+ (End of Process), and the bus control signals -MEMR (Memory
+ Read), -MEMW (Memory Write), -IOR (I/O Read), and -IOW (I/O
+ The 8237 DMA is known as a ``fly-by'' DMA controller. This
+ means that the data being moved from one location to
+ another does not pass through the DMA chip and is not
+ stored in the DMA chip. Subsequently, the DMA can only
+ transfer data between an I/O port and a memory address, but
+ not between two I/O ports or two memory locations.
+ <quote><em>Note:</em> The 8237 does allow two channels to
+ be connected together to allow memory-to-memory DMA
+ operations in a non-``fly-by'' mode, but nobody in the PC
+ industry uses this scarce resource this way since it is
+ faster to move data between memory locations using the
+ In the PC architecture, each DMA channel is normally
+ activated only when the hardware that uses that DMA
+ requests a transfer by asserting the DRQ line for that
+ <sect1><heading>A Sample DMA transfer</heading>
+ <p>Here is an example of the steps that occur to cause a
+ DMA transfer. In this example, the floppy disk
+ controller (FDC) has just read a byte from a diskette and
+ wants the DMA to place it in memory at location
+ 0x00123456. The process begins by the FDC asserting the
+ DRQ2 signal to alert the DMA controller.
+ The DMA controller will note that the DRQ2 signal is asserted.
+ The DMA controller will then make sure that DMA channel 2
+ has been programmed and is enabled. The DMA controller
+ also makes sure none of the other DMA channels is active
+ or has a higher priority. Once these checks are
+ complete, the DMA asks the CPU to release the bus so that
+ the DMA may use the bus. The DMA requests the bus by
+ asserting the HRQ signal which goes to the CPU.
+ The CPU detects the HRQ signal, and will complete
+ executing the current instruction. Once the processor
+ has reached a state where it can release the bus, it
+ will. Now all of the signals normally generated by the
+ CPU (-MEMR, -MEMW, -IOR, -IOW and a few others) are
+ placed in a tri-stated condition (neither high or low)
+ and then the CPU asserts the HLDA signal which tells the
+ DMA controller that it is now in charge of the bus.
+ Depending on the processor, the CPU may be able to
+ execute a few additional instructions now that it no
+ longer has the bus, but the CPU will eventually have to
+ wait when it reaches an instruction that must read
+ something from memory that is not in the internal
+ processor cache or pipeline.
+ Now that the DMA ``is in charge'', the DMA activates its
+ -MEMR, -MEMW, -IOR, -IOW output signals, and the address
+ outputs from the DMA are set to 0x3456, which will be
+ used to direct the byte that is about to transferred to a
+ specific memory location.
+ The DMA will then let the device that requested the DMA
+ transfer know that the transfer is commencing. This is
+ done by asserting the -DACK signal, or in the case of the
+ floppy disk controller, -DACK2 is asserted.
+ The floppy disk controller is now responsible for placing
+ the byte to be transferred on the bus Data lines. Unless
+ the floppy controller needs more time to get the data
+ byte on the bus (and if the peripheral needs more time it
+ alerts the DMA via the READY signal), the DMA will wait
+ one DMA clock, and then de-assert the -MEMW and -IOR
+ signals so that the memory will latch and store the byte
+ that was on the bus, and the FDC will know that the byte
+ has been transferred.
+ Since the DMA cycle only transfers a single byte at a
+ time, the FDC now drops the DRQ2 signal, so that the DMA
+ knows it is no longer needed. The DMA will de-assert the
+ -DACK2 signal, so that the FDC knows it must stop placing
+ data on the bus.
+ The DMA will now check to see if any of the other DMA
+ channels have any work to do. If none of the channels
+ have their DRQ lines asserted, the DMA controller has
+ completed its work and will now tri-state the -MEMR,
+ -MEMW, -IOR, -IOW and address signals.
+ Finally, the DMA will de-assert the HRQ signal. The CPU
+ sees this, and de-asserts the HOLDA signal. Now the CPU
+ activates its -MEMR, -MEMW, -IOR, -IOW and address lines,
+ and it resumes executing instructions and accessing main
+ memory and the peripherals.
+ For a typical floppy disk sector, the above process is
+ repeated 512 times, once for each byte. Each time a byte
+ is transferred, the address register in the DMA is
+ incremented and the counter that shows how many bytes are
+ to be transferred is decremented.
+ When the counter reaches zero, the asserts the EOP
+ signal, which indicates that the counter has reached zero
+ and no more data will be transferred until the DMA
+ controller is reprogrammed by the CPU. This event is
+ also called the Terminal Count (TC). There is only one
+ EOP signal, because only one DMA channel can be active at
+ any instant.
+ If a peripheral wants to generate an interrupt when the
+ transfer of a buffer is complete, it can test for its
+ -DACK signal and the EOP signal both being asserted at
+ the same time. When that happens, it means the DMA won't
+ transfer any more information for that peripheral without
+ intervention by the CPU. The peripheral can then assert
+ one of the interrupt signals to get the processors'
+ attention. The DMA chip itself is not capable of
+ generating an interrupt. The peripheral and its
+ associated hardware is responsible for generating any
+ interrupt that occurs.
+ It is important to understand that although the CPU
+ always releases the bus to the DMA when the DMA makes the
+ request, this action is invisible to both applications
+ and the operating systems, except for slight changes in
+ the amount of time the processor takes to execute
+ instructions when the DMA is active. Subsequently, the
+ processor must poll the peripheral, poll the registers in
+ the DMA chip, or receive an interrupt from the peripheral
+ to know for certain when a DMA transfer has completed.
+<sect1><heading>DMA Page Registers and 16Meg address space limitations</heading>
+ <p>You may have noticed earlier that instead of the DMA
+ setting the address lines to 0x00123456 as we said
+ earlier, the DMA only set 0x3456. The reason for this
+ takes a bit of explaining.
+ When the original IBM PC was designed, IBM elected to use
+ both DMA and interrupt controller chips that were
+ designed for use with the 8085, an 8-bit processor with
+ an address space of 16 bits (64K). Since the IBM PC
+ supported more than 64K of memory, something had to be
+ done to allow the DMA to read or write memory locations
+ above the 64K mark. What IBM did to solve this problem
+ was to add a latch for each DMA channel, that holds the
+ upper bits of the address to be read to or written from.
+ Whenever a DMA channel is active, the contents of that
+ latch is written to the address bus and kept there until
+ the DMA operation for the channel ends. These latches
+ are called ``Page Registers''.
+ So for our example above, the DMA would put the 0x3456
+ part of the address on the bus, and the Page Register for
+ DMA channel 2 would put 0x0012xxxx on the bus. Together,
+ these two values form the complete address in memory that
+ is to be accessed.
+ Because the Page Register latch is independent of the DMA
+ chip, the area of memory to be read or written must not
+ span a 64K physical boundary. If the DMA accesses memory
+ location 0xffff, the DMA will then increment the address
+ register and it will access the next byte at 0x0000, not
+ 0x10000. The results of this are probably not intended.
+ <quote><em>Note:</em> ``Physical'' 64K boundaries should
+ not be confused with 8086-mode 64K ``Segments'', which
+ are created by adding a segment register with an offset
+ register. Page Registers have no address overlap.</quote>
+ To further complicate matters, the external DMA address
+ latches on the PC/AT hold only eight bits, so that gives
+ us 8+16=24 bits, which means that the DMA can only point
+ at memory locations between 0 and 16Meg. For newer
+ computers that allow more than 16Meg of memory, the
+ PC-compatible DMA cannot access locations above 16Meg.
+ To get around this restriction, operating systems will
+ reserve a buffer in an area below 16Meg that also doesn't
+ span a physical 64K boundary. Then the DMA will be
+ programmed to read data to that buffer. Once the DMA has
+ moved the data into this buffer, the operating system
+ will then copy the data from the buffer to the address
+ where the data is really supposed to be stored.
+ When writing data from an address above 16Meg to a
+ DMA-based peripheral, the data must be first copied from
+ where it resides into a buffer located below 16Meg, and
+ then the DMA can copy the data from the buffer to the
+ hardware. In FreeBSD, these reserved buffers are called
+ ``Bounce Buffers''. In the MS-DOS world, they are
+ sometimes called ``Smart Buffers''.
+ <sect1><heading>DMA Operational Modes and Settings</heading>
+ <p>The 8237 DMA can be operated in several modes. The main
+ ones are:
+ <tag/Single/ A single byte (or word) is transferred.
+ The DMA must release and re-acquire the bus for each
+ additional byte. This is commonly-used by devices
+ that cannot transfer the entire block of data
+ immediately. The peripheral will request the DMA
+ each time it is ready for another transfer.
+ The floppy disk controller only has a one-byte
+ buffer, so it uses this mode.
+ <tag>Block/Demand</tag> Once the DMA acquires the
+ system bus, an entire block of data is transferred,
+ up to a maximum of 64K. If the peripheral needs
+ additional time, it can assert the READY signal.
+ READY should not be used excessively, and for slow
+ peripheral transfers, the Single Transfer Mode should
+ be used instead.
+ The difference between Block and Demand is the once a
+ Block transfer is started, it runs until the transfer
+ count reaches zero. DRQ only needs to be asserted
+ until -DACK is asserted. Demand mode will transfer
+ one more bytes until DRQ is de-asserted, then when
+ DRQ is asserted later, the transfer resumes where it
+ was suspended.
+ Older hard disk controllers used Demand mode until
+ CPU speeds increased to the point that it was more
+ efficient to read the data using the CPU.
+ <tag>Cascade</tag> This mechanism allows a DMA channel
+ to request the bus, but then the attached peripheral
+ device is responsible for placing addressing
+ information on the bus. This is also known as ``Bus
+ When a DMA channel in Cascade Mode receives control
+ of the bus, the DMA does not place addresses and I/O
+ control signals on the bus like it normally does.
+ Instead, the DMA only asserts the -DACK signal for
+ this channel.
+ Now it is up to the device connected to that DMA
+ channel to provide address and bus control signals.
+ The peripheral has complete control over the system
+ bus, and can do reads and/or writes to any address
+ below 16Meg. When the peripheral is finished with
+ bus, it de-asserts the DRQ line, and the DMA
+ controller can return control to the CPU or to some
+ other DMA channel.
+ Cascade Mode can be used to chain multiple DMA
+ controllers together, and this is exactly what DMA
+ Channel 4 is used for in the PC. When a peripheral
+ requests the bus on DMA channels 0, 1, 2 or 3, the
+ slave DMA controller asserts HLDREQ, but this wire is
+ actually connected to DRQ4 on the primary DMA
+ controller. The primary DMA controller then requests
+ the bus from the CPU using HLDREQ. Once the bus is
+ granted, -DACK4 is asserted, and that wire is
+ actually connected to the HLDA signal on the slave
+ DMA controller. The slave DMA controller then
+ transfers data for the DMA channel that requested it,
+ or the slave DMA may grant the bus to a peripheral
+ that wants to perform its own bus-mastering.
+ Because of this wiring arrangement, only DMA channels
+ 0, 1, 2, 3, 5, 6 and 7 are usable on PC/AT systems.
+ <quote><em>Note:</em> DMA channel 0 was reserved for
+ refresh operations in early IBM PC computers, but
+ is generally available for use by peripherals in
+ modern systems.</quote>
+ When a peripheral is performing Bus Mastering, it is
+ important that the peripheral transmit data to or
+ from memory constantly while it holds the system bus.
+ If the peripheral cannot do this, it must release the
+ bus frequently so that the system can perform refresh
+ operations on memory.
+ Since memory read and write cycles ``count'' as refresh
+ cycles (a refresh cycle is actually an incomplete
+ memory read cycle), as long as the peripheral
+ controller continues reading or writing data to
+ sequential memory locations, that action will refresh
+ all of memory.
+ Bus-mastering is found in some SCSI adapters and
+ other high-performance peripheral cards.
+ <tag>Autoinitialize</tag> This mode causes the DMA to
+ perform Byte, Block or Demand transfers, but when the
+ DMA transfer counter reaches zero, the counter and
+ address is set back to where they were when the DMA
+ channel was originally programmed. This means that
+ as long as the device requests transfers, they will
+ be granted. It is up to the CPU to move new data
+ into the fixed buffer ahead of where the DMA is about
+ to transfer it for output operations, and read new
+ data out of the buffer behind where the DMA is
+ writing on input operations. This technique is
+ frequently used on audio devices that have small or
+ no hardware ``sample'' buffers. There is additional
+ CPU overhead to manage this ``circular'' buffer, but in
+ some cases this may be the only way to eliminate the
+ latency that occurs when the DMA counter reaches zero
+ and the DMA stops until it is reprogrammed.
+ <sect1><heading>Programming the DMA</heading>
+ <p>The DMA channel that is to be programmed should always
+ be ``masked'' before loading any settings. This is because
+ the hardware might assert DRQ, and the DMA might respond,
+ even though not all of the parameters have been loaded or
+ Once masked, the host must specify the direction of the
+ transfer (memory-to-I/O or I/O-to-memory), what mode of
+ DMA operation is to be used for the transfer (Single,
+ Block, Demand, Cascade, etc), and finally the address and
+ length of the transfer are loaded. The length that is
+ loaded is one less than the amount you expect the DMA to
+ transfer. The LSB and MSB of the address and length are
+ written to the same 8-bit I/O port, so another port must
+ be written to first to guarantee that the DMA accepts the
+ first byte as the LSB and the second byte as the MSB.
+ Then, be sure to update the Page Register, which is
+ external to the DMA and is accessed through a different
+ set of I/O ports.
+ Once all the settings are ready, the DMA channel can be
+ un-masked. That DMA channel is now considered to be
+ ``armed'', and will respond when DRQ is asserted.
+ Refer to a hardware databook for precise programming
+ details for the 8237. You will also need to refer to the
+ I/O port map for the PC system. This map describes where
+ the DMA and Page Register ports are located. A complete
+ table is located below.
+ <sect1><heading>DMA Port Map</heading>
+ <p>All systems based on the IBM-PC and PC/AT have the DMA
+ hardware located at the same I/O ports. The complete
+ list is provided below. Ports assigned to DMA Controller
+ #2 are undefined on non-AT designs.
+<sect2><heading>0x00 - 0x1f DMA Controller #1 (Channels 0, 1, 2 and 3)</heading>
+<p>DMA Address and Count Registers
+0x00 write Channel 0 starting address
+0x00 read Channel 0 current address
+0x02 write Channel 0 starting word count
+0x02 read Channel 0 remaining word count
+0x04 write Channel 1 starting address
+0x04 read Channel 1 current address
+0x06 write Channel 1 starting word count
+0x06 read Channel 1 remaining word count
+0x08 write Channel 2 starting address
+0x08 read Channel 2 current address
+0x0a write Channel 2 starting word count
+0x0a read Channel 2 remaining word count
+0x0c write Channel 3 starting address
+0x0c read Channel 3 current address
+0x0e write Channel 3 starting word count
+0x0e read Channel 3 remaining word count
+DMA Command Registers
+0x10 write Command register
+0x10 read Status register
+0x12 write Request Register
+0x12 read -
+0x14 write Single Mask Register Bit
+0x14 read -
+0x16 write Mode Register
+0x16 read -
+0x18 write Clear LSB/MSB Flip-Flop
+0x18 read -
+0x1a write Master Clear/Reset
+0x1a read Temporary register
+0x1c write Clear Mask Register
+0x1c read -
+0x1e write Write All Mask Register Bits
+0x1e read -
+<sect2><heading>0xc0 - 0xdf DMA Controller #2 (Channels 4, 5, 6 and 7)</heading>
+<p>DMA Address and Count Registers
+0xc0 write Channel 4 starting address
+0xc0 read Channel 4 current address
+0xc2 write Channel 4 starting word count
+0xc2 read Channel 4 remaining word count
+0xc4 write Channel 5 starting address
+0xc4 read Channel 5 current address
+0xc6 write Channel 5 starting word count
+0xc6 read Channel 5 remaining word count
+0xc8 write Channel 6 starting address
+0xc8 read Channel 6 current address
+0xca write Channel 6 starting word count
+0xca read Channel 6 remaining word count
+0xcc write Channel 7 starting address
+0xcc read Channel 7 current address
+0xce write Channel 7 starting word count
+0xce read Channel 7 remaining word count
+DMA Command Registers
+0xd0 write Command register
+0xd0 read Status register
+0xd2 write Request Register
+0xd2 read -
+0xd4 write Single Mask Register Bit
+0xd4 read -
+0xd6 write Mode Register
+0xd6 read -
+0xd8 write Clear LSB/MSB Flip-Flop
+0xd8 read -
+0xda write Master Clear/Reset
+0xda read Temporary register
+0xdc write Clear Mask Register
+0xdc read -
+0xde write Write All Mask Register Bits
+0xde read -
+<sect2><heading>0x80 - 0x9f DMA Page Registers</heading>
+0x87 r/w DMA Channel 0
+0x83 r/w DMA Channel 1
+0x81 r/w DMA Channel 2
+0x82 r/w DMA Channel 3
+0x8b r/w DMA Channel 5
+0x89 r/w DMA Channel 6
+0x8a r/w DMA Channel 7
diff --git a/handbook/scsi.sgml b/handbook/scsi.sgml
index d6c4efb91c..48cd4aaf57 100644
@@ -1,4 +1,4 @@
-<!-- $Id: scsi.sgml,v 220.127.116.11.4.2 1995-10-12 03:16:32 jfieber Exp $ -->
+<!-- $Id: scsi.sgml,v 18.104.22.168.4.3 1995-10-30 15:23:57 jfieber Exp $ -->
<!-- The FreeBSD Documentation Project -->
@@ -464,7 +464,7 @@ Feb 9 19:33:46 yedi /386bsd: sd0: 636MB (1303250 total sec), 1632 cyl, 15 head,
The multi level design allows a decoupling of low-level bit
banging and more high level stuff. Adding support for another
- piece of hardware is a much more manageable problem.
+ piece of hardware is a much more managable problem.
@@ -484,7 +484,7 @@ Feb 9 19:33:46 yedi /386bsd: sd0: 636MB (1303250 total sec), 1632 cyl, 15 head,
system boot messages will be displayed to indicate whether
the configured hardware was actually found.
- An example based on the FreeBSD 2.0.5-Release kernel config
+ An example loosely based on the FreeBSD 2.0.5-Release kernel config
file LINT with some added comments (between ):
@@ -501,12 +501,6 @@ Feb 9 19:33:46 yedi /386bsd: sd0: 636MB (1303250 total sec), 1632 cyl, 15 head,
# sea: Seagate ST01/02 8 bit controller (slow!)
# wds: Western Digital WD7000 controller (no scatter/gather!).
-# Note that the order is important in order for Buslogic cards to be
-# probed correctly.
-[For a Bustek controller]
-controller bt0 at isa? port "IO_BT0" bio irq ? vector btintr
[For an Adaptec AHA274x, 284x etc controller]
controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem?
@@ -514,29 +508,30 @@ controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem?
[For an Adaptec AHA174x controller]
controller ahb0 at isa? bio irq ? vector ahbintr
-[For an Adaptec AHA154x controller]
-controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr
[For an Ultrastor adapter]
controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr
-controller scbus0 #base SCSI code
+# Map SCSI buses to specific SCSI adapters
+controller scbus0 at ahc0
+controller scbus2 at ahb0
+controller scbus1 at uha0
+# The actual SCSI devices
disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0]
disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted]
-disk sd2 at scbus0 target 3
-disk sd3 at scbus0 target 4
+disk sd2 at scbus1 target 3 [SCSI disk on the uha0]
+disk sd3 at scbus2 target 4 [SCSI disk on the ahb0]
tape st1 at scbus0 target 6 [SCSI tape at target 6]
device cd0 at scbus? [the first ever CDROM found, no wiring]
- The example above tells the kernel to look for a bt (Bustek)
- controller, then for an Adaptec 274x, 284x etc board, and
+ The example above tells the kernel to look for a ahc (Adaptec 274x)
+ controller, then for an Adaptec 174x board, and
so on. The lines following the controller specifications
tell the kernel to configure specific devices but
<em>only</em> attach them when they match the target ID and
- LUN specified.
+ LUN specified on the corresponding bus.
So, if you had a SCSI tape at target ID 2 it would not be
configured, but it will attach when it is at target ID 6.