Commit Graph

96 Commits

Author SHA1 Message Date
Peter Wemm
6182fdbda8 Bring the 'new-bus' to the i386. This extensively changes the way the
i386 platform boots, it is no longer ISA-centric, and is fully dynamic.
Most old drivers compile and run without modification via 'compatability
shims' to enable a smoother transition.  eisa, isapnp and pccard* are
not yet using the new resource manager.  Once fully converted, all drivers
will be loadable, including PCI and ISA.

(Some other changes appear to have snuck in, including a port of Soren's
 ATA driver to the Alpha.  Soren, back this out if you need to.)

This is a checkpoint of work-in-progress, but is quite functional.

The bulk of the work was done over the last few years by Doug Rabson and
Garrett Wollman.

Approved by:	core
1999-04-16 21:22:55 +00:00
Mike Smith
facdaf9e33 Remove inactive pmap_setdevram()/pmap_setvidram consumer code. 1999-04-07 03:59:13 +00:00
Doug Rabson
7845080b68 Add support for Compaq ProLiant 1200 host to PCI bridge.
Obtained from: 2.2 branch
Reviewed by: Benjamin Lewis <bhlewis@gte.net>
1999-02-21 11:39:37 +00:00
Nick Hibma
47fd282734 Undo Nicolas' changes (1.91->1.92, added USB controller in pcisupport.c).
Please don't.
1999-02-18 18:48:01 +00:00
Nicolas Souchu
5ca2e94010 Add alpm.c, Aladdin Power Management SMBus support for the SMBus framework.
Update pcisupport.c with NALPM and Aladdin USB detection printf.
1999-02-13 17:51:46 +00:00
Peter Wemm
811d024014 Back out rev 1.89. The #include is necessary for the #if that tests
the value that config(8) provides when intpm is configured.  It seems
that somebody forgot to rerun config at the time and commented this out
instead.
1999-02-06 02:28:52 +00:00
Matthew Dillon
8aef171243 Fix warnings in preparation for adding -Wall -Wcast-qual to the
kernel compile
1999-01-28 00:57:57 +00:00
Matthew Dillon
b4e36adf1c Fix warnings preparing for -Wall -Wcast-qual
Also disable one usb module in LINT due to fatal compilation errors,
    temporary.
1999-01-27 20:09:21 +00:00
Peter Wemm
5581e43bbf Check if the intpm controller is configured first before stopping
recognition of the 82371AB device.
1999-01-26 04:54:38 +00:00
Nicolas Souchu
04fb1490a0 Terminate commit for the Intel PIIX4 SMBus support. Already committed files
are sys/pci/intpm*

Submitted by: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
1999-01-25 19:34:27 +00:00
Foxfair Hu
c78e2203d9 Turn the VIA chipset ,<<IDE/USB>> controller probing off.
It might cause some problem and something like USB has its
own driver.
1998-12-27 07:59:25 +00:00
Foxfair Hu
b7f854eed2 Add Matrox Mystique 1064/1164SG chips info. By the datasheet from Matrox,
they use the same value in the VID register.

PR		kern/9137: Matrox Mystique chip name typo error
Submitted by:	Alex D. Chen <dhchen@Canvas.dorm7.nccu.edu.tw>
1998-12-23 14:28:37 +00:00
Foxfair Hu
dc0ba36f4d Add more non-Intel family ((new)) chipset, just like VIA technology MVP3
AcerLabs Aladdin-V. It makes the PCI probing work when system booting. I
will try to merge some additional funtion(i.e. wdc1 problem cause tons of
PR appear :<) ASAP if I could.

Remind me if something wrong after committing, thanks!
1998-12-19 16:05:19 +00:00
Julian Elischer
57b59a8762 Remove the bogus charracters "42" from the beginning of the first line.
looks like "editor turd".
1998-12-19 08:35:30 +00:00
Mike Smith
6417da252f Fix for bogus BIOS configuration of the 450NX PCI interface on some
systems (eg. Dell 6300).

PR:		kern/8928
Submitted by:	David Malone <dwmalone@maths.tcd.ie>
1998-12-19 02:58:29 +00:00
Mike Smith
02489dd737 Support for Intel 450NX-based systems with more than one PCI bus (ie.
most of them).

Many thanks to Kevin Van Maren for the work here, Intel for lending us
a 450NX system to work this out on, and several other folks for testing
the patches.  See the PR for an extensive discussion of the nature of
the problem and resolution.

PR:		kern/8928
Submitted by:	Kevin Van Maren <vanmaren@fast.cs.utah.edu>
1998-12-19 02:51:22 +00:00
Nick Hibma
527e2883c3 Removed probe for VIA 82C586B OHCI controller (is done in ohci_pci.c now) 1998-12-14 09:46:31 +00:00
Matthew Dillon
35f069d08b pci_device pd_probe function changed from returning char * to returning
const char *.  Originally I was going to add casts from const char * to
    char * in some of the pci device drivers, but the reality is that the
    pci device probes return constant quoted strings.
1998-12-14 05:47:29 +00:00
Eivind Eklund
cd0f360aeb Check return value of malloc. 1998-12-09 01:33:03 +00:00
Archie Cobbs
f1d19042b0 The "easy" fixes for compiling the kernel -Wunused: remove unreferenced static
and local variables, goto labels, and functions declared but not defined.
1998-12-07 21:58:50 +00:00
Archie Cobbs
2127f26023 Examine all occurrences of sprintf(), strcat(), and str[n]cpy()
for possible buffer overflow problems. Replaced most sprintf()'s
with snprintf(); for others cases, added terminating NUL bytes where
appropriate, replaced constants like "16" with sizeof(), etc.

These changes include several bug fixes, but most changes are for
maintainability's sake. Any instance where it wasn't "immediately
obvious" that a buffer overflow could not occur was made safer.

Reviewed by:	Bruce Evans <bde@zeta.org.au>
Reviewed by:	Matthew Dillon <dillon@apollo.backplane.com>
Reviewed by:	Mike Spengler <mks@networkcs.com>
1998-12-04 22:54:57 +00:00
Søren Schmidt
e4ef2ec1ed The Neomagic chip is a 2160 not a 3160. 1998-12-01 21:50:58 +00:00
Nick Hibma
48ecb15bdc Removed probes for USB chips 82371xB (done in dev/pci/uhci_pci.c) 1998-11-26 21:57:52 +00:00
Doug Rabson
57250ffb42 * Fix vga_probe() so that it doesn't report a non-vga display adapter as
a vga.
* Fix broken logic in syscons for a failed probe.
* Fix AlphaStation 500/600 so that non-serial consoles are supported.

Submitted by: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu> (vga bits),
	      Andrew Gallatin <gallatin@cs.duke.edu> (AS500/AS600)
1998-10-31 10:35:24 +00:00
Mike Smith
85dc1320dc Add 450NX chipset components. 1998-09-16 20:29:22 +00:00
Bruce Evans
6aa42d9a4e Changed #if defined(i386)' to #ifdef __i386__'.
`#if defined(ONE_THING)' is a style bug, and i386 instead of __i386__
is a bug, since i386 is never defined when the kernel is compiled
by with the default flags (`gcc -ansi ...').  Here the bug disabled
the call to pmap_setvidram(), so ISA video memory was not mapped
WC on 686's.  The bug may have been masked by bugs in the committer's
version of gcc - `gcc -ansi' incorrectly defines i386 for gcc = the
version of egcs on the 2.2.6 cdrom.
1998-07-07 05:00:09 +00:00
John-Mark Gurney
e261d589ff document PCI_QUIET that prevents pci from compiling in so many strings 1998-06-30 08:13:27 +00:00
John Dyson
7ebee558ec Disable attempted write combining support. This probably
causes more trouble than help (for now.)
1998-06-08 04:07:51 +00:00
John Dyson
f0175db1ee Attempt to set write combining mode for graphics devices. 1998-05-11 01:06:08 +00:00
Bruce Evans
53a867d577 Translated to C (parameters in a function definition have the same scope
as variables declared in the main block in the function, so shadowing
of parameters by variables declared in the main block is not just an
obfuscation).

Found by:	lint
1998-05-08 07:56:48 +00:00
KATO Takenori
841691ff66 Added another PCI to C-bus (ISA bus like 16 bit bus of PC-98) bridge. 1998-05-04 08:16:03 +00:00
KATO Takenori
b6f8b29d08 Add NEC PC-98 chipsets. 1998-05-04 01:39:48 +00:00
Poul-Henning Kamp
b24afdcba1 Patches are given here for pcisupport.c to recognise most of VIA
Technologies' Socket 7 chipsets. This covers all of the Apollo chipsets
except the Master (82C570) and the MVP3, and it also covers the cheap
VXPro and VXTWO knockoffs of the VP1 and VPX.

PR:		6481
Reviewed by:	phk
Submitted by:	Lee Cremeans <lcremean@tidalwave.net>
1998-05-03 08:35:05 +00:00
Stefan Eßer
fabdb7f671 Add PCI device IDs for Intel BX PCI chip-set components.
Submitted by:	Steinar Haug <sthaug@nethelp.no>
1998-05-02 22:19:33 +00:00
Stefan Eßer
a0f4d79940 Add two VLSI chip set components: 82C592 and 82C593
Submitted by:	Warner Losh <imp@village.org>
1998-03-27 20:36:54 +00:00
Søren Schmidt
ff86df5bb2 Undo the previous commit which was NOT for -current.
Rearrange a few lines for better order.
1998-03-01 17:29:25 +00:00
Satoshi Asami
fc6ffbcae9 Add Intel 430TX chipset, namely 82439TX system controller and four
incarnations of 82371AB (P/I bridge, IDE, USB and power management).

Tested by:	jkh
1998-03-01 10:10:31 +00:00
Søren Schmidt
fffdf6c1e0 Add the Intel 82371SB USB host controller to the known list. 1998-02-24 12:15:34 +00:00
Garrett Wollman
b537e731a2 Attempt to tell the user precisely what sort of VGA-like PCI device is
in their system.  The list comes originally from XFree86's SuperProbe
program.
1997-11-11 01:50:06 +00:00
Garrett Wollman
19716f65c5 Oops... back out the change to recognize the TI 1131; there's a better place. 1997-10-17 16:26:14 +00:00
Garrett Wollman
cf8dfa04fe Teach the PCI code about the TI 1131 and NeoMagic NM2160 in my laptop. 1997-10-17 16:15:43 +00:00
Satoshi Asami
02e3504927 Add IDs for Intel 82371MX/82437MX (mobile PCI chipset).
Reviewed by:	se
1997-10-10 11:52:17 +00:00
Poul-Henning Kamp
70a99d052e Remove the 82371 IDE devices.
Add Intel 82439TX System Controller (MTXC)
fix a whitespace problem.
1997-09-24 07:37:56 +00:00
John Dyson
7197c8af33 SMP Natoma motherboards cannot know if you are booting a UP or SMP OS. This
mod makes sure that the Natoma chipset is set into the correct mode.  In
the case of my P6DNF, when booting a UP kernel, I see a substantial improvement
in the latency of certain operations.   It appears that the cache hit
latency is curiously improved the most, per lat_mem_rd.
1997-08-16 07:18:51 +00:00
Poul-Henning Kamp
2d4fbd8761 Fix the VLSI chipset name from "Eagle" to "Eagle II". 1997-08-10 09:33:21 +00:00
Poul-Henning Kamp
fdfbeb33ae Add ID's for 5 VLSI chips. They're not very friendly, so this info was
found by taking my HP800CT apart, perusing HPs (Very good!) service
manual and inference from a bad gif file I found in Finland.
Sigh...  But it's a nice machine :-)
1997-08-08 21:11:40 +00:00
Bruce Evans
1fd0b0588f Removed unused #includes. 1997-08-02 14:33:27 +00:00
Søren Schmidt
8b8a0b53b1 Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.

It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.

Submitted by:cgull@smoke.marlboro.vt.us <John Hood>

Original readme:

*** WARNING ***

This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.

This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do.  It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still.  Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment.  It's a disk driver.  It has bugs.  Disk drivers with bugs
munch data.  It's a fact of life.

I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.

*** END WARNING ***

that said, i happen to think the code is working pretty well...

WHAT IT DOES:

this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard.  (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.)  it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets.  specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine).  it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.

it cuts CPU usage considerably and improves drive performance
slightly.  usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load.  cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%.  (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.

real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds.  it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.

THE CODE:

this code is a patch to wd.c and wd82371.c, and associated header
files.  it should be considered alpha code; more work needs to be
done.

wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).

wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.

the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place.  there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks.  whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.

timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup.  i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.

does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?

error recovery is probably weak.  early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain.  i haven't got a drive with bad sectors i can
watch the driver flail on.

complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced.  if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it.  i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.

i have maintained wd.c's indentation; that was not too hard,
fortunately.

TO INSTALL:

my dev box is freebsd 2.2.2 release.  fortunately, wd.c is a living
fossil, and has diverged very little recently.  included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace).  most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'.  apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0.  you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.

to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag.  the driver
will then turn on DMA support if your drive and controller pass its
tests.  it's a bit picky, probably.  on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.

'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.

i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only.  this should be
fairly safe, even if the driver goes completely out to lunch.  it
might save you a reinstall.

one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.

boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives.  refer to your ATA and chipset documentation to
interpret these.

WHAT I'D LIKE FROM YOU and THINGS TO TEST:

reports.  success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.

i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.

i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly.  i'm also interested in hearing about other chipsets.

i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.

UltraDMA-33 reports.

interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)

i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors.  i haven't been able to find any such yet.

success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.

failure reports on operation with more than one drive would be
appreciated.  the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...

any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).

performance reports.  beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe.  performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.

THINGS I'M STILL MISSING CLUE ON:

* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?

* is there a spec for dealing with Ultra-DMA extensions?

* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?

* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?

FINAL NOTE:

after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically.  the IDE bus is best modeled as an
unterminated transmission line, these days.

for maximum reliability, keep your IDE cables as short as possible and
as few as possible.  from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree.  using two cables means you double the length of this bus.

SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable.  IDE passed beyond the veil two
years ago.

  --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
Stefan Eßer
478f9549f4 Assign correct chip set register dump functions to Triton II device IDs.
PR:		i386/4092
Submitted by:	Steve Bauer <sbauer@rock.sdsmt.edu>
1997-07-18 19:47:23 +00:00
Stefan Eßer
8e1b97b626 Add code to correctly probe all buses on the Intel XXPRESS motherboard.
Add a few Intel PCI chip-set names (VX) and fix Orion entries.
1997-05-30 21:01:47 +00:00