I’m writting driver and application that needs to read I/O ports (sth like read-write everything does). Is it possible to map i/o ports to the memory? Or do I need to use functions like READ_PORT_UCHAR in loop to read data from all ports and then send data to user mode?
xxxxx@gmail.com wrote:
I’m writting driver and application that needs to read I/O ports (sth like read-write everything does). Is it possible to map i/o ports to the memory? Or do I need to use functions like READ_PORT_UCHAR in loop to read data from all ports and then send data to user mode?
Before we address your questions, we need to have a short side trip in
which we all make sure you are asking the right questions.
What I/O ports are you hoping to access? No modern hardware design uses
I/O ports. Access to I/O ports can be as much as 100 times slower than
access to memory-mapped regions. There is NO justification for using
them any more. If you are trying to access a parallel port for
laboratory use, that’s one thing, and we can help you with that. But if
you have a new design, it almost certainly does not HAVE I/O ports.
So, please give us a little more information, and we can guide you in
the right direction.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’m assuming you have a PnP device for which you are writing a device device driver. Given that you access it’s IO ports usually as memory mapped IO using the READ_PORT_XXXX commands after yo have received your resources and you have done the appropriate mapping and set up of those ports. ALL of your IO will be done in the driver with the application passing requests to the driver for input/output data and status and control data.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Apr 10, 2012, at 11:35 AM, xxxxx@gmail.com wrote:
I’m writting driver and application that needs to read I/O ports (sth like read-write everything does). Is it possible to map i/o ports to the memory? Or do I need to use functions like READ_PORT_UCHAR in loop to read data from all ports and then send data to user mode?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
My driver is a non PnP driver - I’m creating a software device for it. I use it to map memory from given physical address to user mode application. And I also need to be able to read I/O space, because sometimes device’s registry are kept in there. My application (and driver) will be a kind of tool to test device’s drivers.
And I hope to get access to all I/O ports, like “RW everything” does.
When you open Windows Device Manager and set View option to “Resouces by type”, you can expand “Input/output (IO)” tree to see range of port associated to particular devices. I’d like to be able to read data from all of that ports.
Tim was right, most of your access is going to be via memory mapped access and not IO ports, unless you have a legacy device that is older than I am.
Basically you cannot achieve your desired objective. A driver is ASSIGNED it’s resources and is the soul owner of those resources, with the expectation that NO OTHER drivers will never attempt to access those resources. You have no idea what actions will be triggered simply by reading a given device, nor even if you CAN read that device when you decide to read that device. What you HOPE to get and what you WILL get are really two entirely different things, with the end result most likely a lovely shade of blue.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Apr 10, 2012, at 3:20 PM, xxxxx@gmail.com wrote:
My driver is a non PnP driver - I’m creating a software device for it. I use it to map memory from given physical address to user mode application. And I also need to be able to read I/O space, because sometimes device’s registry are kept in there. My application (and driver) will be a kind of tool to test device’s drivers.
And I hope to get access to all I/O ports, like “RW everything” does.
When you open Windows Device Manager and set View option to “Resouces by type”, you can expand “Input/output (IO)” tree to see range of port associated to particular devices. I’d like to be able to read data from all of that ports.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Well, the only thing I can say here is “where is Chris”…
Anton Bassov
anton bassov wrote:
Well, the only thing I can say here is “where is Chris”…
Sounds like malware to me. This guy wants unfettered access to start stomping on other device’s address space. Well, no thank you.
So you want a driver that allows you unlimited and uncontrolled access
to the kernel and device space, this definitely is not a testing tool.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> My driver is a non PnP driver - I’m creating a software device for it. I use it to map memory from given physical address to user mode application. And I also need to be able to read I/O space, because sometimes device’s registry are kept in there. My application (and driver) will be a kind of tool to test device’s drivers.
> And I hope to get access to all I/O ports, like “RW everything” does.
> When you open Windows Device Manager and set View option to “Resouces by type”, you can expand “Input/output (IO)” tree to see range of port associated to particular devices. I’d like to be able to read data from all of that ports.
xxxxx@gmail.com wrote:
My driver is a non PnP driver - I’m creating a software device for it. I use it to map memory from given physical address to user mode application. And I also need to be able to read I/O space, because sometimes device’s registry are kept in there. My application (and driver) will be a kind of tool to test device’s drivers.
And I hope to get access to all I/O ports, like “RW everything” does.
You can’t go mucking around with registers that are owned and being
managed by other drivers.
Having said that, our company developed and distributes a “general
purpose hardware debugger” application that does essentially what you
describe. It is intended for early PCI hardware debugging, where there
is no driver, or the driver can be disabled. To support that debugger,
I wrote a simple kernel driver that maps BARs and allows read/write
access, and also allows read/write access to I/O ports. We even have a
Forth interpreter add-on and a C interpreter add-on, for scripting
diagnostics.
In the proper hands, it is a very useful tool, but you have to be
constantly aware of what you are doing so you don’t step on resources
that are being managed by someone else.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> My driver is a non PnP driver - I’m creating a software device for it.
Software device with IO ports???
And I hope to get access to all I/O ports, like “RW everything” does.
Hardware non-PnP drivers are obsoleted for 12 years.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>soul owner of those resources
“sole owner”?
Interesting typo.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Sounds like malware to me. This guy wants unfettered access to start stomping on other
device’s address space.
Well, this is already a different part of the story…
What I was amused by is the very concept of mapping _ IO ports_ to memory, in the first place - it just shows the level of the poster’s overall knowledge. Taking into consideration the above, the fact that he/she/it wants
“to use functions like READ_PORT_UCHAR in loop to read data from all ports and then send data to user mode”
does not already seem that funny…
Anton Bassov
xxxxx@hotmail.com wrote:
What I was amused by is the very concept of mapping _ IO ports_ to memory, in the first place - it just shows the level of the poster’s overall knowledge.
It could just mean a different background (although I don’t think that’s
the case here). Remember that this is EXACTLY what you do on the
non-x86 architectures. ISA and PCI I/O ports are mapped to memory on
the Alpha, MIPS, and PowerPC implementations of NT.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> It could just mean a different background (although I don’t think that’s the case here).
Remember that this is EXACTLY what you do on the non-x86 architectures.
Well, Windows NT versions >=4 don’t seem to support anything other than x86,x86_64 and IA64, right…
ISA and PCI I/O ports are mapped to memory on the Alpha, MIPS, and PowerPC implementations of NT.
What I really appreciate is bus_space and bus_dma abstractions of NetBSD and OpenBSD kernels that allow
you to insulate a driver from the specifics of underlying bus …
Anton Bassov
Good that we no longer bother about VME with its dozens of address
spaces and cycle types.
– pa
>he/she/it wants
“It”? Is it aboud Lois Bujold’s “ba” from the “Cetaganda” book? 
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Well, Windows NT versions >=4 don’t seem to support anything other than x86,x86_64 and IA64,
=2000
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
He may be confused by the documentation of READ_PORT_xxx
“Parameters - Port - Specifies the port address, which must be a mapped
memory range in I/O space.”
I think they got that wrong and just copied over the documentation from
READ_REGISTER_xxx. Since we call MmMapIoSpace on device memory only and not
on I/O ports.
//Daniel
wrote in message news:xxxxx@ntdev…
> What I was amused by is the very concept of mapping _ IO ports_ to memory,
> in the first place - it just shows the level of the poster’s overall
> knowledge. Taking into consideration the above, the fact that he/she/it
> wants
> “to use functions like READ_PORT_UCHAR in loop to read data from all ports
> and then send data to user mode”
> does not already seem that funny…
Some devices use I/O ports (READ_PORT_*) to maintain backward
compatibility for some reason. Most devices map the control, status, and
data values as offsets from soe memory base, and you use READ_REGISTER_*
calls for these (in kernelspeak, “register” means “memory”, for reasons
nobody can explain).
I am uncertain as to why you think you need a loop to read these
registers, because there are usually very few of them. For example, I
might use two READ_REGISTER_UCHAR calls because I neither know nor care
that the offsets of the two registers differ by 1.
I/O ports cannot be mapped to memory addresses “after the fact”. If all
you have are port numbers, you have to do READ_PORT_* calls, period. If,
however, the hardware designer has provided a memory address which aliases
the base of the ports, then you ignore the ports and use the memory
address. But it has to be designed into the hardware.
So, do you actually have specs on the device or are you expected to infer
its behavior from its aura, or possibly from tea leaves? (And I’m not
being sarcastic here–I’ve had to write (non-Windows) drivers from specs
written on the back of a Denny’s Restaurant placemat…and could not
extract the specs from the vendor. I had originally thought this was
because they had sone warped notion of protecting intellectual prperty,
but the real truth was that the only “documentation” existed in the head
of the designer. When my code didn’t work, the conversation was “Oh,
yeah, forgot to tell you about that!”)
joe
I’m writting driver and application that needs to read I/O ports (sth like
read-write everything does). Is it possible to map i/o ports to the
memory? Or do I need to use functions like READ_PORT_UCHAR in loop to read
data from all ports and then send data to user mode?NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Well, there are so many things wrong with this idea it is hard to know
where to start…
First, why would anyone write a non-PnP driver today? AFAIK, even the
legacy serial port, parallel port, and keyboard drivers are PnP-compliant,
but are “root enum” devices, because they have no “plug” event to announce
their presence.
Mapping memory from physical addresses to user mode is something that is
exceedingly dangerous, and at the level of questions you are asking, you
don’t understand enough to keep you out of trouble. If you need to read
I/O space, then you read I/O space, which is not addressible memory, nor
can it be made into addressible memory (altough there are some devices
that alias I/O space registers and mappable memory, these are now
uncommon)
I have no idea how any of this can possibly help you test “device’s
driver”. Either this is a driver, or it isn’t. If it is connected to
your device, it is your device’s driver, but it can’t touch hardware owned
by any other driver. If you have to ask “why” this is proof that you
really don’t have a clue as to what is going on. If you are trying to
create some kind of test harness for YOUR driver, this is about as wrong
as you can get. It won’t work (again, if you have to ask “why” then this
proves that you don’t know enough to make the attempt. As an Exercise For
The Student, ten points, write a paragraph or two outlining the most
obvious failure modes of this approach; extra points if you can say it in
one sentence).
Access to all ports is just silly; it is dangerous beyond comprehension.
Exercise For The Student: write a paragraph explaining, as simply as
possible, why this is one of the most incredibly stupid ideas presented in
this newsgroup. Extra points if you can say it in one word.
Note that you don’t even know how to find them, and if you think you do,
please complete the exercise in the preceding paragraph.
The idea makes no sense, and you should abandon it.
joe
My driver is a non PnP driver - I’m creating a software device for it. I
use it to map memory from given physical address to user mode application.
And I also need to be able to read I/O space, because sometimes device’s
registry are kept in there. My application (and driver) will be a kind of
tool to test device’s drivers.
And I hope to get access to all I/O ports, like “RW everything” does.
When you open Windows Device Manager and set View option to “Resouces by
type”, you can expand “Input/output (IO)” tree to see range of port
associated to particular devices. I’d like to be able to read data from
all of that ports.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer