PC Hacks 100 Industrial-Strength Tips and Tools

< Day Day Up >

Hack 12 Manage Devices

Take control of device configuration.

One of the basic functions of the PC's BIOS is to identify and provide access to a variety of core components and I/O devices, whether they are embedded on the system board or plugged into an I/O card slot. Core components include the CPU, memory, internal system clocks and timers, and the I/O bus itself. Simple I/O devices supported by every BIOS include the keyboard, mouse, video adapter, I/O ports (serial, parallel, USB, and/or FireWire), and disk drive adapters. All of these devices have very predictable but limited places to be, including:

• Preset and expected hardware addresses (to access and get data to or from the device)

• Interrupt Request (IRQ) signals so devices can tell the CPU and programs they need attention

• Direct Memory Access (DMA) request and acknowledgment signals for devices and the CPU to communicate with each other, allowing high-speed data transfers directly to and from device memory

The earlier, or legacy, BIOS dealt with the hardware as provided, and the hardware configurations were preset or manually altered using switches and jumpers. When all you had were simple I/O devices, configuring a PC was manageable but admittedly not easy for those not inclined to get inside a PC and work with wires and jumpers. As PCs got more popular, more and more nontechnical users were exposed to them, and configuring a PC started to become a major frustration and technical support nightmare for PC vendors. As technology advanced, users wanted more, faster, and better things from the PC. The simple, aging, and slow I/O devices and limitations of the PC and BIOS had to be rethought.

To be able to advance, the PC had to change, but because so many people and companies had so much invested in the PC hardware and software status quo, any new PC technology had to accommodate the old as well as the new. The goals of any technology advances were based on experience and history, leading to the following goals for PCs:

• Detection, recognition, and cooperation with any ISA devices [Hack #11]

• No hardware-based configuration—everything must be software-configurable

• Automatic device detection, identification, and configuration, whether a new device is added or an existing one is removed

• Avoidance of duplication, overlap, and conflicts with address, IRQ, and DMA signals

• Notification to the operating system of hardware changes

Fast-forward through a few less-than-successful PC technology changes like the VESA Local Bus (VLB), IBM's MicroChannel Architecture (MCA), and the Enhanced Industry Standard Architecture (EISA), and you come to the long-standing period of current technologies. These include the Peripheral Component Interconnect (PCI) I/O bus, Advanced Graphics Port (AGP), Universal Serial Bus (USB), and IEEE-1394 (aka FireWire, aka i.Link)—and more recently Serial ATA and PCI-X data buses.

None of these current technologies would have been possible or flourished if it were not for significant changes and additions to the PC BIOS—specifically, creating and adding what is known as Plug and Play capabilities.

The Plug and Play spec is available for download from Microsoft's web site (http://download.microsoft.com/download/whistler/hwdev3/1.0/WXP/EN-US/pnpbios.exe). It makes an interesting read if you're into technical jargon and hardware and software interactions. Amidst all of the technical and process jargon, the most salient content you will find is that Plug and Play BIOS first looks and acts like the old BIOS: it detects the presence and configuration of any legacy devices (configured by hardware switches, jumpers, or software programs that flip virtual switches in the device) in the PC and reserves those configuration settings to avoid having them used by Plug and Play devices. After discovering legacy devices, Plug and Play BIOS determines the configuration of Plug and Play devices. It evaluates what it finds for any changes to hardware settings—the addition or subtraction of devices—to determine if it should initiate automatic configuration of the new device or any previously existing devices to make sure every device has a nonconflicting configuration.

You may encounter a Plug and Play device, or its device driver, that simply insists on using the resources of an existing device, ignoring a legacy or other Plug and Play device that is using the resources. This problem might be corrected by reconfiguring the settings for the new device with Device Manager [Hack #75], [Hack #76], and [Hack #77]]. Reconfiguring a device does not take effect until the system is restarted and Windows accepts the new configuration based on updated Plug and Play BIOS data.

The Plug and Play specification does not tell you exactly how or why Plug and Play BIOS or various Plug and Play devices work. The actual implementation of Plug and Play is somewhat left up to interpretation by the programmers and engineers at dozens of vendors. Without hard and fast rules to go by, the resulting BIOS and hardware implementations can vary and affect the experiences you will have adding and configuring devices for your PC.

Plug and Play devices come in a variety of flavors, specifically, those that may only report their configuration but cannot be reconfigured, which is typical for fixed resource system board components, and those that can both report their configuration and reconfigure themselves to avoid conflicts. There have been reports of early implementations of Plug and Play devices that supposedly reconfigure themselves but, in fact, only report their configuration and will not budge a single bit to avoid conflicts. Video cards, as a basic system device, are usually not reconfigurable and should not tell the BIOS that they are reconfigurable. If you plug in a new PCI network adapter and suddenly find that either the network adapter is not recognized or that your PCI video card no longer works, you have probably encountered a bug in the firmware code in one of the devices. The only remedy is to find out from the manufacturer of both devices if a firmware upgrade exists to solve this problem and upgrade the adapters, or to change to another model or brand of either card.

2.3.1 Improving Your Odds with Plug and Play

Plug and Play is not perfect. Trying to accommodate the needs and wishes of dozens of hardware and software makers in arriving at a single set of BIOS functionality that would support and dictate the capabilities of PCs for many years could not have been an easy task. Plug and Play is quite amazing, but could do a lot more for all of us. Instead it has specific limitations in what it can do. These limitations will become apparent as you deal with the PC's I/O system, connect devices to it, and see how operating systems deal with it all together.

Functionally, a Plug and Play BIOS pits devices against one another in a race against time to fight for available resources. A Plug and Play BIOS automatically determines which devices can change configuration, allows each device to settle on a configuration, and then stores the data to present these devices to the operating system. True Plug and Play devices are supposed to work with the BIOS to figure out device settings that do not conflict with already-configured devices and set devices (legacy devices and settings that absolutely cannot be changed, such as keyboards, mice, timers, CPU numeric processors, and disk drive interfaces). Unfortunately, some Plug and Play devices do not play nice: they do not have the ability to be reconfigured during bootup to work around already-configured devices because they are not fully compatible with Plug and Play. This happens quite often with a combination of cheap network cards and some video cards, or when mixing cheap and name-brand network cards in the same system.

If you get lucky and don't have your network and video adapters fighting with each other, you may find that the built-in Plug and Play serial/COM ports will fight with add-in COM ports such as modems, and you will end up with a COM port set to some obscure logical device name like COM13 using nonstandard I/O addresses and an IRQ that conflicts with something else. If you are really unlucky at this high-tech roulette game, you won't notice anything is wrong until the operating system is done loading and has found all of the new hardware and claimed it is ready for use—only to discover when you need to run a specific program that it cannot find or use the nonstandard settings. To correct these abnormalities you need to know the basics of resource configuration, which built-in devices to reconfigure, and how all devices should be properly configured. In effect, you will find times when it is necessary to override Plug and Play's automatic settings. One example of this is demonstrated in [Hack #75] . In some cases, you may need to convince Plug and Play to question all its assumptions [Hack #18] .

2.3.2 Unnatural Resources

In order to hack I/O settings that have run amok, you first have to know the main players and their device addresses, IRQ settings, and DMA channels. Every I/O device in your system has a physical address to which it responds and through which it passes data. The I/O address resources for Industry Standard Architecture (ISA) or legacy devices are well known (at least to your operating system and drivers), quite limited, and typically not tampered with or changed, but it is possible to improperly configure multiple devices with the same or overlapping addresses and cause conflicts that will render those devices useless.

PCI, PCI-X, AGP, IEEE-1394, and SATA devices also have physical hardware addresses, but they are built on a much larger (32- and 64-bit) and faster data bus than ISA (8- and 16-bit) devices were. Rarely will you ever see two Plug and Play devices fighting for the same I/O address, but it can happen.

Going beyond hardware I/O addresses, we find two other resources for hardware devices: Interrupt Request (IRQ) signals and Direct Memory Address (DMA) signals. These are also well known in the realm of legacy or ISA systems and have a minor role with PCI devices. Unlike I/O addresses, which are not plentiful but of which there are enough to go around, there are only sixteen IRQ signals and eight DMA signals, called "channels."

Of these, in a 16-bit ISA system and systems that have legacy devices but no ISA add-in slots, nine of the IRQ signals are reserved for system board and CPU functions: timers, memory, keyboard/mouse ports, numeric data processing, diskette drive, and commonly two disk drive interfaces. Some of the DMA signals are also reserved for system functions, but there is little chance of not having enough DMA signals.

This leaves a mere seven IRQ signals to be parceled out to several possible built-in or add-in I/O devices—serial/COM ports, parallel/LPT ports, sound, SCSI, network, and video adapters. At some point while expanding your system, you may run out of unique IRQ assignments for legacy devices (and some Plug and Play devices) and oddly enough find some devices must share an IRQ signal.

IRQ assignment problems are insignificant or nonexistent with PCI devices. The PCI bus is separate from the ISA bus and was designed with a lot more capabilities and possibilities, though some PCI devices do use virtual ISA IRQ assignments to maintain compatibility with DOS and DOS-based programs. It is the fact that PCI devices have to share some configurations with ISA (like a PCI-based Plug and Play modem that mimics being a COM port) to maintain compatibility with operating systems and applications that drives us to consider legacy and ISA issues and work around them.

2.3.3 Logically Speaking

Whether you're adding or changing a modem card, connecting a PDA, or trying to hook up that old Iomega Zip drive so you can recover some valuable files, you'll probably need to know something about the COM or LPT ports in your system to finish configuring the software so things work right. The configuration of the four COM ports and two LPT ports are well known because they were actually dictated in the design of the original IBM PC.

COM and LPT port numbering always seems a bit of a mystery because the COM port numbers do not follow specific pieces of hardware or settings; instead they follow a logical numbering scheme. If you only have one COM port in a system, regardless of its address or IRQ assignment, it becomes COM 1—logical because it's the first and only port. If you add a second COM port, provided it does not use the same address as the existing COM port, it may become COM 1 or be COM 2, depending on the address used. Similar logical assignments happen with LPT ports, and you even see a hint of this with disk drive letter assignments. (Between diskette drives A: and B:, the first hard drive is C:, and so on.)

No matter what the COM port's hardware address is, BIOS, DOS, Windows, and most programs expect that COM 1 will always use IRQ 4, and COM 2 will always use IRQ 3. Mix up the IRQ assignments and your software may have a problem communicating with the ports. You do not need to be as picky about LPT ports and their IRQ assignments in most cases, but all core system devices—clocks, timers, keyboard, mouse, and disk drive interfaces—have fixed, unchangeable IRQ settings.

To determine resource use and device conflicts under Windows, follow these steps:

Figure 2-3. Device Manager console showing Resources by Type

If you're using Linux, you can find out a lot about your system devices at the command prompt with a couple of simple commands. The first, lspci, lists PCI devices:

[root@rh9-lt root]# lspci

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge

   (rev 03)

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge

   (rev 03)

00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)

00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)

00:03.0 Communication controller: Lucent Microelectronics WinModem 56k

   (rev 01)

00:06.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 

[CrystalClear SoundFusion 

Audio Accelerator] (rev 01)

00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)

01:00.0 VGA compatible controller: Neomagic Corporation NM2360 

[MagicMedia 256ZX]

05:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)

To find out which resources are being used by what devices, change to the /proc directory and inspect the ioports and interrupts files:

[root@rh9-lt root]# cd /proc

[root@rh9-lt proc]# cat ioports

0000-001f : dma1

0020-003f : pic1

0040-005f : timer

0060-006f : keyboard

0070-007f : rtc

0080-008f : dma page reg

00a0-00bf : pic2

00c0-00df : dma2

00f0-00ff : fpu

01f0-01f7 : ide0

03c0-03df : vga+

03f6-03f6 : ide0

03f8-03ff : serial(auto)

0cf8-0cff : PCI conf1

4000-401f : Intel Corp. 82371AB/EB/MB PIIX4 USB

  4000-401f : usb-uhci

4400-44ff : Lucent Microelectronics WinModem 56k

4500-4507 : Lucent Microelectronics WinModem 56k

4800-48ff : PCI CardBus #02

4c00-4cff : PCI CardBus #02

5000-50ff : PCI CardBus #05

  5000-507f : PCI device 115d:0003

    5000-507f : xircom_cb

5400-54ff : PCI CardBus #05

d000-dfff : PCI Bus #01

ef00-ef3f : Intel Corp. 82371AB/EB/MB PIIX4 ACPI

efa0-efbf : Intel Corp. 82371AB/EB/MB PIIX4 ACPI

fcf0-fcff : Intel Corp. 82371AB/EB/MB PIIX4 IDE

  fcf0-fcf7 : ide0

[root@rh9-lt proc]# cat interrupts

           CPU0

  0:    7292143          XT-PIC  timer

  1:        705          XT-PIC  keyboard

  2:          0          XT-PIC  cascade

  8:          1          XT-PIC  rtc

 11:       9534          XT-PIC  usb-uhci, 

Texas Instruments PCI1450, Texas Instruments 

PCI1450 (#2), eth0

 12:      32040          XT-PIC  PS/2 Mouse

 14:     650116          XT-PIC  ide0

NMI:          0

ERR:         80

< Day Day Up >