Share via


Driver Loading Process

At OEMInit time, debugging services such as Ethernet debugging and serial debugging need to be started. You can retrieve the resource information for these devices in the following ways:

  • Boot arguments from the boot loader provide resource information to set up the hardware in a particular way. For example, the interrupt request (IRQ) for the Ethernet debugging adapter can be passed as a boot argument.
  • Hard-coded resource information in the OAL.
  • Resources necessary for debugging services discovered by the OAL.

The OAL may need to configure and enumerate a bus, such as the PCI bus, to operate a device used for debugging services. For example, an Ethernet adapter on the PCI bus that is for Ethernet debugging services needs its resources and intermediary bridges to be configured to be functional. You can ignore other devices because the PCI bus driver performs the configuration and enumeration.

The resource information configures the debugging devices and initializes their associated services. The OAL is responsible for putting this resource information in a registry key and making it accessible to the driver. The OAL can use the Registry Helper Routines to fill out the device's information in a PCI_REG_INFO structure, defined in PCIReg.h, and then the OS calls KernelIoControl with IOCTL_HAL_INITREGISTRY to enable the helper function PCIReg be called to populate the registry. This method is preferred if the debugging resources are selectable at boot time, discovered through bus enumeration, or both.

Optionally, the resource information can be duplicated in the system registry. This method is easier if the debugging resources are fixed and known in advance.

Then, Device.exe is loaded and executed. It starts the I/O Resource Manager to read a list of available resources from the registry.

Device.exe loads the registry enumerator from HKEY_LOCAL_MACHINE\RootKey where RootKey is a value defined under the HKEY_LOCAL_MACHINE\Drivers key. If the RootKey value is not defined, it defaults to Drivers. Currently, Common.reg sets RootKey equal to Drivers\BuiltIn. This means that Device.exe looks for the Dll value to load the registry enumerator under HKEY_LOCAL_MACHINE\Drivers\BuiltIn. The Registry Enumerator (RegEnum.dll) initializes the process of scanning the registry for additional buses and devices to be loaded for subkeys of the RootKey.

Some of the RootKey subkeys describe built-in or possibly fixed ISA buses. The DLL loaded may be RegEnum.dll, or any other bus driver that you choose.

One of the RootKey subkeys may be PCI. Typically, the DLL listed under the PCI key is the PCI bus driver, which is loaded by RegEnum.dll. Registry entries for the PCI bus driver include resources available to the PCI bus. The HKEY_LOCAL_MACHINE\RootKey\PCI\Order value is set so that the PCI bus driver is typically loaded last. This is so all of the fixed resources are allocated before the flexible resources of the PCI devices are configured. Driver registry entries are listed under the PCI key, which represent devices that reside on the PCI bus.

Drivers with associated physical devices use or generate with a bus driver the values in the following table.

Subkey Type Description
MemBase DWORD or MULTI_SZ Base addresses of memory-mapped I/O.
MemLen DWORD or MULTI_SZ Length of memory-mapped ranges corresponding to Membase.
IoBase DWORD or MULTI_SZ Base address of port-mapped I/O.
IoLen DWORD or MULTI_SZ Length of port-mapped ranges corresponding to IoBase.
InterfaceType DWORD or MULTI_SZ Hardware interface type. For more information see INTERFACE_TYPE.
Irq DWORD or MULTI_SZ Optional. Logical IRQ numbers.
SysIntr DWORD or MULTI_SZ System interrupt numbers corresponding to the IRQs.

The SysIntr value is a mapping of the Irq as specified by the OAL. Some bus drivers, such as the PCI bus driver, generate both the Irq and SysIntr values and write them to the registry. If RegEnum.dll enumerates the registry key, you are required to set the SysIntr value in the appropriate registry file.

Some bus drivers, such as the PCI bus driver, may require additional values. For example, the PCI bus driver has to distinguish between instances of the same device. The following table describes these additional identification values.

Subkey Type Description
BusNumber DWORD PCI bus number of the device.
DeviceNumber DWORD Number of the device on the bus.
FunctionNumber DWORD Identifies one of the eight possible functions implemented on the device.

See Also

PCI Bus Configuration and Enumeration

 Last updated on Tuesday, May 18, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.