I've been tasked with writing a GPIO driver for the Winbond 83627. This is
my first foray into "big Windows" (I'm coming from the CE world), and also
my first foray into x86 (coming from the ARM world). So the questions are
probably pretty basic, but any insight you can provide would be much
appreciated.

The basic problem I've got is that the GPIO on this part can't be mapped
into regular IO space by the BIOS (or so I'm told). We (someone else who is
no longer here) did a legacy driver for a different Winbond chip, but that
one allowed the GPIO register to be mapped into IO space. The driver just
blasted the port, and everyone was happy (no support for PnP, WDM etc, but
got the job done).

The data sheet for this part indicates that you have to enter "Compatible
PNP mode" by writing some magic numbers to 0x2E, and then use 0x2E/0x2F as a
address/data pair to hit the various registers. I'm thinking there are
several possible problems with this:

- Will XP allow me to just blast those registers? They show up as
motherboard resources in the device manager, and I'm thinking XP might
protect them somehow.
- There are other devices that could theoretically want access to this
magical space. If I'm allowed to just enter it at will, who is preventing
the other drivers and I from messing each other up?
- Is this Compatible PNP mode related to the regular ISA PNP mechanism, or
just a copycat mechanism used to try to protect the registers from
inadvertent writes?
- If this area is protected, what is the recommended method of accessing
these registers?

I'll write a little test driver to see what happens if I just write to this
space. But anything anyone cares to add would be greatly appreciated...

--
Dean Ramsier

Is it a PCI card?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:O$%23tn2EaFHA.1456@TK2MSFTNGP15.phx.gbl...

No, the W83627 is on the LPC interface of the south bridge.

--
Dean Ramsier - eMVP


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:ORiplkGaFHA.3976@TK2MSFTNGP15.phx.gbl...

Any ISAPnP support there?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:OIBk11GaFHA.3132@TK2MSFTNGP09.phx.gbl...

I'm not sure exactly what you mean by ISAPnP support, but I believe the
hardware and BIOS are ISA PNP capable, and I assume that's been
implemented in general. However, the GPIO is muxed with a couple of
other devices (GAME and MIDI) in this Winbond chip, so I (or the BIOS)
needs to ensure the GPIO is the one that is exposed. How this affects
PnP, I don't know.

I have some opportunity to have the BIOS modified, as long as it isn't
too major. But, I need to tell the BIOS guy what needs done, and I'm
not sure what that should be...

- Dean

how are you synchronizing access to the GPIO between GAME and MIDI? in the
hardware or do you control the drivers for both of these components? What
it sounds like you want is that the BIOS enumerate a new device w/a unique
HW ID and the hw resources you want to use assigned to it so that you can
load your driver and control the hw.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Dean Ramsier" <dramsier@gmail.com> wrote in message
news:1117889534.008569.101420@o13g2000cwo.googlegr oups.com...

For such a device maybe you need an ACPI driver?
( just a wild guess, I never did these )

-PA

"Dean Ramsier" wrote:

We don't need GAME or MIDI, just GPIO. If the BIOS could make the GPIO
appear as a device, and make it appear somewhere in the IO space that I
can get at easily I'd be happy. However, the BIOS guy (someone from
the board vendor who can make limited, minor changes to the BIOS) is
telling me he doesn't have any way to make the GPIO appear anywhere
else in the address space. I don't know enough about the architecture
to have an opinion on that.

My understanding from reading the chip spec is that the device exposes
it's ISA configuration space area through another IO port range at
0x2E/0x2F. They (WinBond) have defined a mechanism that looks a little
like ISA PNP (without the commands, isolation etc) to get access to
these registers. The GPIO registers are in this area. A previous chip
had a conf register that allowed the GPIO data register (located in
this space) to be mapped somewhere else in IO space. This chip doesn't
have that register, so the BIOS guy is telling me the only way to
control GPIO is to go through the 0x2E/0x2F register pair. Note that
the other two functions (GAME and MIDI) do have config registers that
allow their data regs to be mapped. A pity they decided to leave the
GPIO out this time...

I'm missing some big picture stuff here somewhere. In XP, what is the
mechanism that stops me from just blindly writing the ports at
0x2E/0x2F? It appears that in, say, DOS I can hit these registers
directly, but XP doesn't like it. I can understand that someone else
might already have requested this space, although I don't know who. Is
this area a known system area that the WinBond chip is making use of,
and XP is protecting? In general, is it possible for two different
drivers to get access to the same physical IO space, and if so how? If
I could just get at 0x2E/0x2F I should be ok.

I just stumbled across information in the DDK last night that indicated
I need to use translated IO addresses instead of the known physical
address. I haven't done that (used physical IO addresses directly).
Maybe that is related to my failure to write to these ports?

Thanks for the help!
- Dean

"Dean Ramsier" wrote:
...........
Just break into a kernel debugger right now, and try to r/w these ports.
Does it work?

--PA

Let's hope not... If I understand correctly, you're talking about an ACPI
function driver. Perusing the docs on this, it seems it would need to be
written in conjunction with an ACPI BIOS, which is probably beyond the scope
of what's possible. Also, it looks to me like an ACPI function driver only
works in "cooked" format, which only allows it to read data?? This being a
GPIO device, I'd need to be able to write it. Doesn't look like that's
supported yet (although I could be completely missing something here...)

- Dean


"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:F4EAB3DE-48C4-4F27-8F6C-F5417BD68270@microsoft.com...

Haven't tried the debuggers yet, I guess I should figure out how to do that.

One thing I have tried is to just use the genport driver in the DDK samples,
and load it at 0x2E-0x2F. It wouldn't load, unable to get the resources...
--
Dean Ramsier

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:2A316C3D-5D6A-47CF-900A-8B9A9C658CFF@microsoft.com...

I've confirmed I can access the GPIO registers through 0x2E/0x2F in Windows
CE. I can't access them in XP, because XP (or someone) already owns these
registers. Any ideas on a route to take that would allow me access to this
area?

--
Dean Ramsier - eMVP

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:upNJTxraFHA.584@TK2MSFTNGP15.phx.gbl...

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message news:uQ4K21taFHA.3488@tk2msftngp13.phx.gbl...
Dean, can you just do a quick try *with a kernel debugger* please?
Five minutes setup and two minutes test?
Hope you already found how to setup windbg or softice.

--PA

I'll give it a try, as soon as I figure out how to setup/use Windbg... BTW,
do I need all the symbols installed, etc that is documented in the windbg
help for this experiment?

- Dean

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:usI6BwvaFHA.3848@TK2MSFTNGP10.phx.gbl...

Well, if I've done this correctly I'm getting 0xFF back from the IO port
that I know to contain an ID. The port containing the ID info is accessed
via the same 0x2E/0x2F mechanism, which I can access just fine in CE ( I get
the expected ID info in CE). I'm not getting any kind of exception writing
to this area that I know of, or any other complaints from the debugger. Is
this what you would expect?

I've attached the debugger, broken in, and issued port reads and writes (ib,
ob) to these addresses in the command window. Did I miss anything?

--
Dean Ramsier


"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:ONQLKD2aFHA.348@TK2MSFTNGP14.phx.gbl...

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message news:ekBRIs3aFHA.3280@TK2MSFTNGP12.phx.gbl...
Great. You did it!

Uhm well, this didn't work... Without knowing the chipset details,
I can't tell whether the thing behind these ports is
powered down, or locked thru some configuration mechanism,
and how to set it to respond.

--PA

There is a mechanism in this chip to lock these registers. Exactly what
gets locked isn't very clear, the docs are pretty sparse. If this is what
is going on, that would explain the problem. Since I think these registers
can be accessed by the normal PnP mechanism or this backdoor route, the
normal PnP might be able to get in and modify this bit, and it might only
lock out the back door mechanism. Who knows...

One last related question on general architecture - Is there anything in the
x86 architecture or the XP operating system by itself that would prevent me
from accessing any arbitrary IO port? I know that the hardware behind a
particular port can effect the result (like the potential lock described
above), but is there another level of protection in the CPU or OS like there
is for memory accesses?

Thanks!
Dean

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:%23Dk2Pk5aFHA.1660@tk2msftngp13.phx.gbl...

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message news:ei4UgTDbFHA.2128@TK2MSFTNGP15.phx.gbl...
No - unless these ports belong to a device that is disabled by some PnP mechanism
or powered down (b/c OS believes that nobody uses it).
Otherwise everybody has total freedom to clobber whatever he wants.

No protection

--PA

Thanks for the help!

--
Dean

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:eDQDC1EbFHA.3132@TK2MSFTNGP09.phx.gbl...

No. Writing to nonexisting port number will be a no-op, while reading will
usually provide 0xff.

The exception is word-wide (16bit) port accesses which span devices. This can
merrily cause a PCI master abort and thus BSOD. For instance, reading a word
from 0x60 will do so (explained in Mindshare's book on PCI bus).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com