Mega Code Archive

Configwin2khardware

Armin wrote: >I need to access I/O ports as well as memory locations of some special hardware under NT/2000. I know, this usually has to >be done by a ring-0 driver. However, I don't want to go through the DDK hell ;-) >I know that there are some "generic" drivers around that can be used at least for I/O port access. But in addition I need to >access memory locations - some "old" DOS programmers might remember expressions like mem[A000:0000]..... >Does anyone know something to do this?? Freeware would be mostly appreciated. >Thank's for any help!!!! >Armin In any event you will have to develop a service module that talks to your card. From the user application point of view, your application cannot directly talk to I/O ports. From the Win2k DDK: http://www.microsoft.com/DDK/DDKdocs/Win2k/ <http://www.microsoft.com/DDK/DDKdocs/Win2k/> Chapter 1 Summary of Kernel-Mode Support Routines This chapter summarizes the kernel-mode support routines that can be called by Microsoft® Windows NT®/Windows® 2000 and WDM kernel-mode drivers. Drivers can also use routines provided by a compiler, such as C string manipulation routines. Support routines are categorized as follows: * Initialization and unload in Section 1.1 <k101_0jzm.htm> * IRPs in Section 1.2 <k101_5stu.htm> * Synchronization in Section 1.3 <k101_4gqa.htm> * Memory in Section 1.4 <k101_84z6.htm> * DMA in Section 1.5 <k101_1noy.htm> * PIO in Section 1.6 <k101_03w2.htm> * Driver-managed queues in Section 1.7 <k101_37oy.htm> * Driver-dedicated system threads and system worker threads in Section 1.8 <k101_8zle.htm> * Strings in Section 1.9 <k101_6zw2.htm> * Data conversions in Section 1.10 <k101_0x82.htm> * Access to and access rights on driver-managed objects in Section 1.11 <k101_3dwy.htm> * Handling errors in Section 1.12 <k101_9auq.htm> Some routines are listed in more than one section or subsection of this chapter. 1.3.3 I/O Ports In the MS-DOS environment, a peripheral board typically has a range of I/O ports to which it can respond. These ports are often configured by jumpers on the board or through software setup. Special-purpose application programs control and communicate with the board by performing 80386/80486 assembly IN and OUT instructions to the ports supported by the board. In Windows NT/Windows 2000, application programs have insufficient processor privilege to access I/O ports. Therefore, the VDM intercepts IN and OUT instructions from MS-DOS application programs and attempts to find an I/O handler registered by a VDD for the specified port. Each VDD installs I/O handlers (also known as I/O hooks) for one or more ranges of port addresses. For example, a VDD could install I/O handlers for the port range 0x220-0x227 and 0x2F0-0x2F7. The VDM keeps track of all I/O port handlers installed by VDDs in that VDM. When the VDM intercepts an IN or OUT instruction from an MS-DOS application, it looks at all the installed I/O handlers to see if the current port being accessed falls within one of the installed port ranges. A VDD must install I/O port handlers for the ports used by its application. The handlers are called each time there is an IN or OUT instruction on one of the designated ports. A VDD OUT handler typically gathers several OUT calls into a single complete command and then translates that command into a Win32 DeviceIoControl call to the kernel-mode device driver for the board. Likewise, a single driver call might require a VDD IN handler to be called several times to completely transfer the information back to the application. A VDD installs its I/O port handlers within the VDD initialization routine, explained in Registering the Driver <vdd_30rj.htm> . Initialize a VDD_IO_HANDLERS structure with pointers to the VDD's I/O port handlers, specifying one or more ranges of I/O ports the VDD responds to, and call the VDDInstallIOHook function. The VDD_IO_HANDLERS structure contains slots for IN and OUT handlers for byte, word, and string operations. The VDD must supply at least byte-in and byte-out handlers. If you supply a NULL function pointer for the word and string operations, the VDM automatically emulates them by calling the byte operation functions the VDD provides, although it is often more efficient to implement word and string operations yourself. A particular VDD can only have one set of I/O handler functions for all the I/O ports it uses. That is, a VDD cannot install one set of functions for one I/O port range and another set of functions for another port range. Of course, other VDDs can install their own functions for other ranges, although two VDDs in the same VDM cannot use overlapping port ranges. A VDD's main entry point function is also called when the VDD is about to be terminated. At that time, the VDD can deinstall its I/O hooks by calling VDDDeinstallIOHook. Note A VDD should never directly hook the I/O ports for DMA or Video. Video is handled by the VDM. See DMA <vdd_8f4x.htm> for a discussion of how to facilitate DMA transfers in the VDM environment. The following functions are used with I/O hooks: Function Description VDDInstallIOHook Hooks the I/O ports the VDD is responsible for. VDDDeinstallIOHook Unhoooks the I/O ports previously hooked by a VDD. http://www.microsoft.com/DDK/DDKdocs/Win2k/vmport_3yuf.htm <http://www.microsoft.com/DDK/DDKdocs/Win2k/vmport_3yuf.htm> 6.4.2 Claiming Legacy Resources A video miniport driver must claim and report all legacy resources in its VIDEO_HW_INITIALIZATION_DATA <vstrcts_750n.htm> structure during driver initialization. Legacy resources are those resources not listed in the device's PCI configuration space but that are decoded by the device. Windows NT/Windows 2000 will disable power management and docking when it encounters legacy resources that are not reported in the manner outlined in this section. Miniport drivers must do the following to report such legacy resources: * If the legacy resource list for the device is known at compile time, fill in the following two fields of the VIDEO_HW_INITIALIZATION_DATA <vstrcts_750n.htm> structure that is created and initialized in the DriverEntry <vmpfncs_06g7.htm> routine: Structure Member Definition HwLegacyResourceList Points to an array of VIDEO_ACCESS_RANGE <vstrcts_6h0n.htm> structures. Each structure describes a device I/O port or memory range for the video adapter that is not listed in PCI configuration space. HwLegacyResourceCount Is the number of elements in the array to which HwLegacyResourceList points. * If the legacy resource list for the device is not known at compile time, implement a HwVidLegacyResources <vmpfncs_9nl3.htm> function and initialize the HwGetLegacyResources member of VIDEO_HW_INITIALIZATION_DATA to point to this function. For example, a miniport driver that supports two devices with different sets of legacy resources would implement HwVidLegacyResources to report the legacy resources at run time. The video port driver will ignore the HwLegacyResourceList and HwLegacyResourceCount members of VIDEO_HW_INITIALIZATION_DATA when a miniport driver implements HwVidLegacyResources. * Fill in the RangePassive field for each VIDEO_ACCESS_RANGE structure defined in the miniport driver accordingly. Setting RangePassive to VIDEO_RANGE_PASSIVE_DECODE indicates that the region is decoded by the hardware but that the display and video miniport drivers will never touch it. Setting RangePassive to VIDEO_RANGE_10_BIT_DECODE indicates that the device decodes ten bits of the port address for the region. Again, a driver should only include resources that the hardware decodes but that are not claimed by PCI. Code in a driver that needs to claim minimal legacy resources might look something like the following: // RangeStart RangeLength // | | RangeInIoSpace // | | | RangeVisible // +-----+-----+ | | | RangeShareable // low high | | | | RangePassive // v v v v v v v VIDEO_ACCESS_RANGE AccessRanges[] = { // [0] (0x3b0-0x3bb) {0x000003b0, 0x00000000, 0x0000000c, 1, 1, 1, 0}, // [1] (0x3c0-0x3df) {0x000003C0, 0x00000000, 0x00000010, 1, 1, 1, 0}, // [2] (0xa0000-0xaffff) {0x000A0000, 0x00000000, 0x00010000, 1, 0, 0, 0}, }; // Within the DriverEntry routine: VIDEO_HW_INITIALIZATION_DATA hwInitData; hwInitData.HwLegacyResourceList = AccessRanges; hwInitData.HwLegacyResourceCount = 3; The miniport driver can "reclaim" legacy resources again in subsequent call(s) to VideoPortVerifyAccessRanges <vpfncs_0x7r.htm> ; however, the video port driver will just ignore requests for any such previously claimed resources. Power management and docking will be disabled in the system if the miniport driver attempts to claim a legacy access range in VideoPortVerifyAccessRanges that was not previously claimed in the HwLegacyResourceList during DriverEntry <vmpfncs_06g7.htm> or returned in the LegacyResourceList parameter of HwVidLegacyResources <vmpfncs_9nl3.htm> . If you don't want to wade through all the DDS or SDK stuff, you would be better served to get a kernel driver developer to help you out. Try http://www.jungo.com/ <http://www.jungo.com/> http://www.bsquare.com/default.asp <http://www.bsquare.com/default.asp> http://www.chsw.com/ddk/ <http://www.chsw.com/ddk/> All the best David*Vukovic Harris county Juvenile Probation Department Houston, Texas [eof]