to the FreeBSD ahd driver:
Correct spelling errors.
Switch to handling bad SCSI status as a sequencer interrupt
instead of having the kernel proccess these failures via
the completion queue. This is done because:
o The old scheme required us to pause the sequencer and clear
critical sections for each SCB. It seems that these pause
actions, if coincident with a sequencer FIFO interrupt, would
result in a FIFO interrupt getting lost or directing to the
wrong FIFO. This caused hangs when the driver was stressed
under high "queue full" loads.
o The completion code assumed that it was always called with
the sequencer running. This may not be the case in timeout
processing where completions occur manually via
ahd_pause_and_flushwork().
o With this scheme, the extra expense of clearing critical
sections is avoided since the sequencer will only self pause
once all pending selections have cleared and it is not in
a critical section.
aic79xx.c
Add code to handle the new BAD_SCB_STATUS sequencer
interrupt code. This just redirects the SCB through
the already existing ahd_complete_scb() code path.
Remove code in ahd_handle_scsi_status() that paused
the sequencer, made sure that no selections where
pending, and cleared critical sections. Bad
status SCBs are now only processed when all of these
conditions are true.
aic79xx.reg:
Add the BAD_SCB_STATUS sequencer interrupt code.
aic79xx.seq:
When completing an SCB upload to the host, if
we are doing this because the SCB contains non-zero
SCSI status, defer completing the SCB until there
are no pending selection events. When completing
these SCBs, use the new BAD_SCB_STATUS sequencer
interrupt. For all other uploaded SCBs (currently
only for underruns), the SCB is completed via the
normal done queue. Additionally, keep the SCB that
is currently being uploaded on the COMPLETE_DMA_SCB
list until the dma is completed, not just until the
DMA is started. This ensures that the DMA is restarted
properly should the host disable the DMA transfer for
some reason.
In our RevA workaround for Maxtor drives, guard against
the host pausing us while trying to pause I/O until the
first data-valid REQ by clearing the current snapshot
so that we can tell if the transfer has completed prior
to us noticing the REQINIT status.
In cfg4data_intr, shave off an instruction before getting
the data path running by adding an entrypoint to the
overrun handler to also increment the FIFO use count.
In the overrun handler, be sure to clear our LONGJMP
address in both exit paths.
Perform a few sequencer optimizations.
aic79xx.c:
Print the full path from the SCB when a packetized
status overrun occurs.
Remove references to LONGJMP_SCB which is being
removed from firmware usage.
Print the new SCB_FIFO_USE_COUNT field in the
per-SCB section of ahd_dump_card_state(). The
SCB_TAG field is now re-used by the sequencer,
so it no longer makes sense to reference this
field in the kernel driver.
aic79xx.h:
Re-arrange fields in the hardware SCB from largest
size type to smallest. This makes it easier to
move fields without changing field alignment.
The hardware scb tag field is now down near the
"spare" portion of the SCB to facilitate reuse
by the sequencer.
aic79xx.reg:
Remove LONGJMP_ADDR.
Rearrange SCB fields to match aic79xx.h.
Add SCB_FIFO_USE_COUNT as the first byte
of the SCB_TAG field.
aic79xx.seq:
Add a per-SCB "Fifos in use count" field and use
it to determine when it is safe (all data posted)
to deliver status back to the host. The old method
involved polling one or both FIFOs to verify that
the current task did not have pending data. This
makes running down the GSFIFO very cheap, so we
will empty the GSFIFO in one idle loop pass in
all cases.
Use this simplification of the completion process
to prune down the data FIFO teardown sequencer for
packetized transfers. Much more code is now shared
between the data residual and transfer complete cases.
Correct some issues in the packetized status handler.
It used to be possible to CLRCHN our FIFO before status
had fully transferred to the host. We also failed to
handle NONPACKREQ phases that could occur should a CRC
error occur during transmission of the status data packet.
Correct a few big endian issues:
aic79xx.c:
aic79xx_inline.h:
aic79xx_pci.c:
aic79xx_osm.c:
o Always get the SCB's tag via the SCB_GET_TAG acccessor
o Add missing use of byte swapping macros when touching
hscb fields.
o Don't double swap SEEPROM data when it is printed.
Correct a big-endian bug. We cannot assign a
o When assigning a 32bit LE variable to a 64bit LE
variable, we must be explict about how the words
of the 64bit LE variable are initialized. Cast to
(uint32_t*) to do this.
aic79xx.c:
In ahd_clear_critical_section(), hit CRLSCSIINT
after restoring the interrupt masks to avoid what
appears to be a glitch on SCSIINT. Any real SCSIINT
status will be persistent and will immidiately
reset SCSIINT. This clear should only get rid of
spurious SCSIINTs.
This glitch was the cause of the "Unexpected PKT busfree"
status that occurred under high queue full loads
Call ahd_fini_scbdata() after shutdown so that
any ahd_chip_init() routine that might access
SCB data will not access free'd memory.
Reset the bus on an IOERR since the chip doesn't
seem to reset to the new voltage level without
this.
Change offset calculation for scatter gather maps
so that the calculation is correct if an integral
multiple of sg lists does not fit in the allocation
size.
Adjust bus dma tag for data buffers based on 39BIT
addressing flag in our softc.
Use the QFREEZE count to simplify ahd_pause_and_flushworkd().
We can thus rely on the sequencer eventually clearing ENSELO.
In ahd_abort_scbs(), fix a bug that could potentially
corrupt sequencer state. The saved SCB was being
restored in the SCSI mode instead of the saved mode.
It turns out that the SCB did not need to be saved at all
as the scbptr is already restored by all subroutines
called during this function that modify that register.
aic79xx.c:
aic79xx.h:
aic79xx_pci.c:
Add support for parsing the seeprom vital product
data. The VPD data are currently unused.
aic79xx.h:
aic79xx.seq:
aic79xx_pci.c:
Add a firmware workaround to make the LED blink
brighter during packetized operations on the H2A.
aic79xx_inline.h:
The host does not use timer interrupts, so don't
gate our decision on whether or not to unpause
the sequencer on whether or not a timer interrupt
is pending.
NCR 53C80/53C400 driver
BACKGROUND
----------
The NCR 53C80 SCSI Bus Controller (SBC) is an early single-chip solution
which formed the basis of many early SCSI host adapters for both the
i386 and m68k platforms. The NCR 53C400 is a slightly more advanced
chip which retains backward compatibility with the 53C80.
On the PC, the NCR 53C80 was most commonly used to implement simple, cheap
SCSI host adapters that were bundled with tape and CD-ROM drives. Since
these controllers were not bus-mastering (and in some cases were not even
interrupt-driven), they (like IDE adapters) required the CPU to perform
much of the actual processing. These days, these controllers are cheap
and plentiful since many are not supported by Windows 95.
Similarly, NetBSD, although it has had an MI 53C80 driver (used by the
Sun3 and Mac68k ports) for some time, has not had a i386 driver.
Until now, that is...
OVERVIEW
--------
The NCR 53C80/53C400 driver (the 'nca' device) consists of two pieces:
1) Patches for the 53C80 MI driver to make it use bus_space()
functions. (This requires an optional define. By default,
the driver will compile in "legacy" memory-mapped mode.
2) A machine-dependent driver (nca) containing probe and
attachment routines.
This driver has bene tested with the following adapters:
NCS-250 (Chinon) 53C80, port-mapped, polled-mode
(This is used in my primary development
box to drive an external Zip drive.)
Sumo SCSI-AT 53C80, port-mapped, interrupt driven
(Note: This is an odd card in that its
own firmware seems to have trouble detecting
attached drives. Under NetBSD, however,
it operates with no problems.)
Trantor T-160 53C400, port-mapped, interrupt driven
This card was often bundled with NEC
CD-ROM drives. (My standalone test box
is using this as its primary adapter.)
DTC 3150V 53C400, memory-mapped, interrupt driven
This a simple card designed to drive
a CD-ROM.
CONFIGURATION
-------------
To setup the nca driver, the configuration file must contain the following:
options NCR5380_USE_BUS_SPACE
This line is required to add bus_space() compatibility to the MI driver.
Next you need to add one or more configuration lines for the nca devices:
nca0 at isa? port 0x360 irq 15
nca1 at isa? iomem 0xd8000 irq 5
The first is for a port-mapped controller at 0x360, IRQ 15. The second line
is for a memory-mapped controller (Trantor T128 or equivalent) at
0xd800-0xdff, IRQ 5.
You can also set up the driver in "polled" mode (i.e., no interrupts) by
leaving off the "irq" portion of the line:
nca0 at isa? port 0x360
nca1 at isa? iomem 0xd8000
Lastly, you need to add a scsibus attachment line for the nca device:
scsibus* at nca?
The following is the probe output from my test system:
Copyright (c) 1996, 1997, 1998
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 1.3.2 (GENERIC) #2: Sun Oct 4 17:11:43 EDT 1998
root@hefalump:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel 486DX (486-class)
real mem = 7995392
avail mem = 5349376
using 123 buffers containing 503808 bytes of memory
mainbus0 (root)
isa0 at mainbus0
com1 at isa0 port 0x2f8-0x2ff irq 3: ns8250 or ns16450, no fifo
com2 at isa0 port 0x3e8-0x3ef irq 5: ns8250 or ns16450, no fifo
lpt0 at isa0 port 0x378-0x37b irq 7
nca0 at isa0 port 0x360-0x36f irq 15
nca0: NCR 53C400 detected
scsibus0 at nca0: 8 targets
sd0 at scsibus0 targ 0 lun 0: <HP, C2235, 0B11> SCSI2 0/direct fixed
sd0: 402MB, 1574 cyl, 9 head, 58 sec, 512 bytes/sect x 825012 sectors
cd0 at scsibus0 targ 6 lun 0: <CHINON, CD-ROM CDS-535, Q20> SCSI2 5/cdrom removable
nca1 at isa0 iomem 0xdb878-0xdb887 irq 5
nca1: NCR 53C400 detected
scsibus1 at nca1: 8 targets
sd1 at scsibus1 targ 5 lun 0: <IOMEGA, ZIP 100, J.02> SCSI2 0/direct removable
sd1: 96MB, 96 cyl, 64 head, 32 sec, 512 bytes/sect x 196608 sectors
npx0 at isa0 port 0xf0-0xff: using exception 16
pc0 at isa0 port 0x60-0x6f irq 1: color
pc0: console
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
biomask 8060 netmask 8460 ttymask 84e2
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs
In this output, nca0 is a Trantor T-160 and nca1 is a DTC 3150V. Both happen
to be 53C400-based controllers.
LIMITATIONS
-----------
As of this writing, the nca driver has two known limitations:
1) No DMA or pseudo-DMA support
This is unfortunate, but may be remedied in a later release. I would welcome
any help by someone more familiar with DMA, particularly in relation to
bus_space().
As it is, however, performance of the nca driver is acceptable, though some
of that may depend on one's definition of "acceptable". Remember that these
were not high speed controller under the best conditions, so much of it is
really the nature of the beast. It should be adequate for tapes, CD-ROMS,
and low-usage disk devices (e.g., Zip drives). If you want to drive a CD-R
drive, then invest in an Adaptec 154X or a PCI controller.
2) No support for the SCSI port of the Pro AudioStudio 16.
This is also unfortunate and may not be able to be remedied withing the
current framework of the bus_space() functions and the nca driver.
The problem is this: In most adapters, the eight 53C80 registers are mapped
to eight sequential locations, either ports or memory addresses. On the
PAS-16, however, the registers are mapped to two sets of ports- four
sequential ports at the base address and four sequential ports located
0x2000 higher. As I currently understand it, this is not supportable by
the current bus_space() implementation nor is it possible for the driver
to allocate a second bus_space_tag and _handle itself to accomodate the
second set of ports. Without either, it is very difficult to imagine how
a portable linkage to the MI driver could be made.
Again, I welcome suggestions.
HISTORY
-------
An nca driver first appeared in FreeBSD.
This particular one borrows a little code from it and some from the i386
'esp' and sun3 'si' drivers. It, like many things in the free unix world,
was written because it solved a problem- mine! In my case, it was a need
of a SCSI card and a lack of IRQs. The good news was that I had one
(NCS-250); the bad news was that it was not supported under NetBSD. The
rest is history.
DISCLAIMER
----------
Like most things, you should take this code with a grain of salt. I have
tried to test it sufficiently, but it is always possible that it is not
compatible with some aspect of your system. If you end up suffering
massive data loss and destruction, you have my sympathies, but I do not
and will not allow myself to be held responsible.
CREDITS
-------
My thanks to Jason Thorpe and the rest of the NetBSD team for making it
so easy to write this driver. My thanks also to the authors of the
FreeBSD nca driver for inspiration and 53C400 support.
In the end, I hope that someone else can find this driver as useful as I
have. If so, please drop me a line at jruschme@exit109.com and let me
know about it.
Share and enjoy
John Ruschmeyer (jruschme@exit109.com)
11 October 1998
e88c8722b7