I am developing GPIO driver. The GPIO pin is Memory mapped. I use the WDK sample driver and do the modifications as in this link.
http://support2.microsoft.com/default.aspx?scid=kb;en-us;Q323595
But when I install the driver I am getting Code 12 error code. But when I check the device manager ( Resource View) I did not see any such conflicting region. How can I resolve this issue ?
On Nov 27, 2014, at 9:54 PM, xxxxx@yahoo.com wrote:
I am developing GPIO driver. The GPIO pin is Memory mapped. I use the WDK sample driver and do the modifications as in this link.
http://support2.microsoft.com/default.aspx?scid=kb;en-us;Q323595
But when I install the driver I am getting Code 12 error code. But when I check the device manager ( Resource View) I did not see any such conflicting region. How can I resolve this issue ?
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Actually I want to control a GPIO pin. I can control the PIN using assembly on DOS. I am using the same address.
On Nov 30, 2014, at 7:44 PM, xxxxx@yahoo.com wrote:
Actually I want to control a GPIO pin. I can control the PIN using assembly on DOS. I am using the same address.
That doesn’t answer any of my questions. I understand clearly what you are trying to do. Let me repeat the questions.
Where did you find the physical address of the memory you wanted to grab? How do you know it wasn’t assigned to someone else? If this is not on a traditional bus, it’s possible the address is being assigned by the ACPI BIOS to some system device.
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hello Tim,
If that perticuler address is assigned to other device it shod by shown in the Device manager (Windows 7) am I right ?
At the moment according the device manager that particular address is not assigned to any address…
Pra
Implicit in Tim’s post is the fact that you can’t just grab and use arbitrary hardware resources in Windows. Those resources must be ASSIGNED to your driver. You get these resources in your EvtDevicePrepareHardware Event Processing Callback.
Yes, this is even true for GPIOs.
You can NOT just use some manifestly constant address and expect it to work. If that’s what you’re doing (and if you’re using PORTIO, it sure seems like it is).
Finally, the Port I/O Sample is *not* how you access GPIOs on Windows. In general, the portio sample is evil and in hindsight never should have been published. It was published with all good intentions to help folks who had a particular need. But you know, there’s an old English saying that says “the road to hell is paved with good intentions” – that’s the road you’re currently on.
Peter
OSR
@OSRDrivers
xxxxx@yahoo.com wrote:
If that perticuler address is assigned to other device it shod by shown in the Device manager (Windows 7) am I right ?
That depends. Device Manager shows PnP devices. There are many drivers
that don’t appear in Device Manager.
I notice that you still haven’t answered any of my questions. Where did
you get the address? Are you just hard-coding a physical address as a
hex constant? If this is a resource being handed out by the ACPI DSDT,
then you may need to alter the BIOS to become the driver for that resource.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> That depends. Device Manager shows PnP devices. There are many drivers
that don’t appear in Device Manager.
Hardware drivers are nearly always all PnP for 14 years now.
Hardware-less kernel modules can be non-PnP.
you get the address? Are you just hard-coding a physical address as a
hex constant?
I saw at least one motherboard temperature/fan speed monitor with its C# source.
In the final end, it was calling IOCTLs to PortIO driver, but all logic about determining port addresses and values to be read/written from them was in C#, with a beautiful polymorphic OO architecture 
And, this logic was just poking hardcoded port addresses from some table to determine the kind of GPIO chip (can be some WinBond WDxxxx or such) and its revision this way.
How robust
It is extremely evil that companies like Asus do not define their temperature/fan speed/voltage sensors in the ACPI table the way the ACPI -> WMI bridge will auto-pick them.
This would allow writing the MB monitor in VBScript/C++/C#/PowerShell in more-or-less trivial robust and stable code.
More so: this stuff is defined in the ACPI table some way, just too lame a way to be auto-picked by ACPI -> WMI stuff. It is defined as ACPI-provided “ATK0110” devnode, with AsAcpi.sys driver loaded for it, and Asus’s MB monitor apps accessing this driver.
If the table entries were not lame - there would be no need in AsAcpi.sys at all.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi All,
Thank you for replying me.
I am using the PortIO driver. I can define the address/Port or Memory in the inf of the driver. See the below link.
http://support2.microsoft.com/default.aspx?scid=kb;en-us;Q323595
I have a assembly code which is working on this system in DOS. I use the address in the assembly code… The driver use MmMapIoSpace function to retrieve relevant virtual address to call physical address provided in the inf.
Regards…
No kidding? That’s amazing. Wow.
That was sarcasm there.
So, if you want to use a manifestly constant address, go right ahead and do that and use DOS to talk to the device. No problem, you’re good to go.
If you want to do so under Windows, please refer to my previous posts… which you either didn’t read or read and obviously disregarded.
You came here for advice. We gave you advice. You’re ignoring the advice.
Do you want to do this for some hacky personal project, or are you trying to make a commercial product? For the former, who cares. For the latter… see my previous posts.
Peter
OSR
@OSRDrivers
xxxxx@yahoo.com wrote:
I am using the PortIO driver. I can define the address/Port or Memory in the inf of the driver. See the below link.
http://support2.microsoft.com/default.aspx?scid=kb;en-us;Q323595
I have a assembly code which is working on this system in DOS. I use the address in the assembly code… The driver use MmMapIoSpace function to retrieve relevant virtual address to call physical address provided in the inf.
That works fine in DOS, which has no central resource management. It
does not work in a real operating system.
I’ll bet money that your ACPI BIOS has assigned the address you’re
stealing to an ACPI device in its DSDT. The CORRECT way to handle this
is to find out what device that is, and make yourself the driver for
that device. Then, the operating system will HAND you the resource you
need. You don’t need to steal it.
Or, if you really don’t care about reliability and don’t intend to
release this in the wild, don’t mention the address in your INF at all.
Just hard-code the address in the driver. If you decide to ship this,
please tell us which device it is so we can be sure not to buy one.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I’ll bet money that your ACPI BIOS has assigned the address you’re
stealing to an ACPI device in its DSDT. The CORRECT way to handle this
Sometimes the things are worse, like on Asus MBs (and probably Asus laptops too).
Yes, DSDT entry is there. And the vendor’s AsAcpi.sys (through which the vendor’s monitoring tools work) is the FD for it.
The IOCTL interface to AsAcpi is undocumented for sure. And no, it does not present the sensors in WMI.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Dear All,
Thank you very much for replying me. How can I check the ACPI BIOS allocations ?
If it is declared by BIOS, still can I claim it dynamically using EvtDevicePrepareHardware ?
Regards…
On Dec 3, 2014, at 9:32 PM, xxxxx@yahoo.com wrote:
Thank you very much for replying me. How can I check the ACPI BIOS allocations ?
If you know this hardware well enough to know a fixed physical address, then you ought to have a relationship with the BIOS author, and they should be able to share this information with you.
If it is declared by BIOS, still can I claim it dynamically using EvtDevicePrepareHardware ?
You can, of course, map the physical address yourself, even if you don’t own it. By doing so, you take the risk of conflicting with the driver that legitimately owns the address. You’ll have to judge the danger.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.