IBM supplied driver that keeps book over detected devices and their resources,
and registered devices and their resource use. The advantage of the Resource
Manager is that a central interface knows what it in use instead of every
single driver reimplementing this. For example the Xircom CardBus driver try
and fail to detect used resources. Disadvantage is that the Resource Manager
interface does not have the possibility to tell where you want a specific
resource. For PCI devices behind bridges, the choice of possible memory and
I/O resource ranges is limited.
OS2Krnl and OS2LDR have an embedded OEMHLP$ device driver that is responsible
for PCI device configuration space access and search functions. The OEMHLP$
driver seem to forward the calls to the PCI BIOS. On most machines - notably
IBM - there is no problem, but on cheap closes - like the one using a
SystemSoft BIOS - the PCI BIOS may only search on the first two PCI busses,
ignoring CardBus busses. The description of the interface is documented in
the PDDREF.INF documentation, chapter Generic IOCtl Commands.
Looks for PCI devices that remain "undetected" after all other snoopers have
been run. It adds a generic (classcode based) adapter node, I/O, memory and
interrupt resources to the knowledge of the Resource Managers Detection Tree.
Original snooper driver is done by IBM, i have an mutch improved version in
the PCIConf package.
To see what PCIBus.SNP has detected, run RMVIEW.EXE /DC, it
could for example contain this detected adapter node in its output:
Detected Hardware Function: PCI Device 04-01-00 Multimedia: Audio
PCI Device ID: 125D1978
IRQ Level = 5 PCI Pin = A Flg = SHARED
I/O = 0X3100 Len = 256 Flg = EXCLUSIVE Addr Lines = 16
Completes generic PCI configuration at boot time:
- PCI power management
- assignment of PCI Bus numbers
- PCI latency timers
- memory and I/O resources
It continues to offer its services after boot to other drivers:
- configuration/deconfiguration of devices - for example CardBus cards
- copy CardInformationStructure data
These functions are available via an IOCtrl and IDC documented interface
that is available to other device drivers.
PCIConf hides the complexity of resource assignements behind PCI bridges.
It uses the Resource Manager and own inspections on the PCI hardware
to make sure to not assign conflicting resources.
This component consists of two parts: one is for reimplementing the PCI functions
of the OEMHLP$ driver:
- can be called anytime, even in interrupt context
- faster implementation
- scans on all PCI busses for devices
Drivers and applications that previously used the OEMHLP$ driver in OS2Krnl
will automaticly use the new OEMHLP$ driver since it does renames the original
driver and then renames itself to OEMHLP$.
This is different from previous versions. Patching drivers to use
OEMHL2$ instead OEMHLP$ are no longer needd and useful.
All non-PCI functions like Read EISA Slot Configuration Information
are forwarded to the original driver.
The other functionality is for patching filtering write actions done by the Socket Services driver
to prevent it from altering the device configuration done by calls to PCIConf.SNP,
for example by disabling bridge windows in the CardBus chip.
Driver providing Socket Services to the Card Services.
Examples for known Socket service drivers are:
- IBM2SS14 - by IBM. Mostly for Texas Instruments chips
- SS2TICB.SYS - by Daniela Engert. modified IBM2SS14.SYS for more chips
- TI1130CB.SYS - TI Chips (Dell). Caution. The original version of the driver assigns likely wrong bus numbers to the CardBus busses
- TI1225CB.SYS - TI Chips (Dell). Caution. The original version of the driver assigns likely wrong bus numbers to the CardBus busses
- SSPCIC.SYS - ApSoft - for example Toshiba, TI, Cirrus, O2 Micro, DataBook
- PIC95SS.SYS - Toshiba
There are more (older) Socket services drivers, but they are not useful for our purpose, since
they will unlikely support CardBus functionality.
Reading the CardBus Card Information Structure (tuples) causes configuration and deconfigurations
actions like write to bridge window registers by the Socket Services.
These changes interfere with the normal working of the enabled cards with their drivers,
and sometimes even the configuration do not work (Socket Services drivers do not use PCIConf.SNP).
And there are cards that do not provide a Card Information Structure.
These cards will show up as Memory in the IBM Card Director application.
The CBCIS.SYS driver reroutes code in PCMCIA.SYS to its own procedures to:
- configure the device and request a CIS copy using the PCIConf.SNP services
- provide a fake CIS derived from PCI configuration space data, if no CIS is present
The Card Services provide the recommended interface to operate PCCard and CardBus cards.
The interface tries to abstract from where the physical sockets are located the cards are in.
On thing that prevents the use of the Card Services to assign I/O, Memory and IRQ resources
is that PCMCIA.SYS tries to register them exclusivly to the Resource Manager.
This may be ok for PCCard (ISA based) cards and for I/O and memory addresses, but has three problems:
- CardBus cards can use use PCI IRQ routing, and share IRQs.
- Some drivers, for example the USB[EOU]HCD.SYS
chip drivers expect that their devices resources are not
registered in Resource Manager.
They use this to find out the next free/unused controller, for each
controller a new driver instance must be loaded in config.sys.
- Card Services only handle the chip function 0. The USB has two OHCI and
one EHCI controlles at functions addresses 0,1 and 2.
It is assumed that the Card Services version is either the
last 5.00 (released about 2002-03-20) version
or the latest of the 8.00 series (buildlevel 10.148).
Purpose of this driver is to let inserted CardBus cards look like their normal
PCI counterparts.
A bit similar to the AUTODRVD.SYS driver.
Instead of adding support for Card Services to you driver and then trying to
power on and configure a card, you simply react on configuration complete/card
removed events.
CBEnable only processes events for CardBus cards, and ignores other card types.
To say it in other words: CBEnable takes over the generic configuration of
an CardBus, and the specific driver can ignore where the chip is located and
do the chip specific work, like configuring send/receive queues for an network
card.
For reasons explained in the Card Services paragraph,
CBEnable can not use the resource assignment services of the Card Services and
just use them to power on the card.
Instead, it used PCIConf.SNP services to assign
resources.
To protect the configured cards from unwanted changes by socket drivers it
activates the OEMHLP2.SYS PCI write protection filter.
Interested drivers may register with CBEnable.SYS
to get notification calls when a new card was enabled, or when an previously
configured card was removed or powered down.
There are additional functionality to query current CBEnable state and to send
artifatial insertion/removal events.
This interface is documented and available for
writers of other device drivers.
Extending the Realtek 8139 PCI chip NDIS driver to have very good support for
the CardBus card variant of the network device was on of the main reasons to
the CBEnable package development. Rtsnd.os2 supports removal and insertion of
the card at any time, the machine can be booted without the card inserted
(but the EtherID value known by configuring it) and later inserted and used.
This is because the driver registers with CBEnable
to get "card inserted and configured comple" and "card removed" events.
Unfortunaly the driver is closed source, so it can not provided as an example.
This driver stands as an example for any other driver that be used, with restricted functionality.
The USB host controller drivers USBEHCD/USBOHCD/USBUHCD.SYS
and their presence checker HCIMONIT.EXE use the OEMHLP$ driver interface,
so the OEMHLP2.SYS driver can make sure that the host controller
drivers and the presence checker can find the USB controllers, regardless on which bus they are located.
The host controller drivers are written with PCI chips on the motherboard or on add-in cards in mind,
so they do expect that the cards are present at boot (driver initialisation) time, and
the the user does not open the machine and rip out the card as would correspond to
removing the CardBus card. To overcome the limiation that the card must be enabled
(consume power) all the time since booting the device, the USB host controller driver
or any other similar driver would have to install register a notification handler
with CBEnable.SYS (dotted line). Or at least be prepared for sudden unavailable
hardware. Unavailable hardware causes non-mapped resources, and reads from unmapped I/O and memory
ranges are usualy of value FF... which may cause wrong interpreatations about device state and
enless loops. To prevent this, add timeout functions and/or add sanity checks that force exits
from such loops when the hardware is not ready.
