Access GPIO on W83627
in [Device Drivers]
|
From: Pavel A. on 7 Jun 2005 15:39 "Dean Ramsier" <ramsiernospam(a)nospam.com> wrote in message news:ekBRIs3aFHA.3280(a)TK2MSFTNGP12.phx.gbl... > 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? Great. You did it! > 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? 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
From: Dean Ramsier on 8 Jun 2005 10:17 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(a)NOwritemeNO.com> wrote in message news:%23Dk2Pk5aFHA.1660(a)tk2msftngp13.phx.gbl... > "Dean Ramsier" <ramsiernospam(a)nospam.com> wrote in message news:ekBRIs3aFHA.3280(a)TK2MSFTNGP12.phx.gbl... > > 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? > > Great. You did it! > > > 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? > > 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 > > >
From: Pavel A. on 8 Jun 2005 13:09 "Dean Ramsier" <ramsiernospam(a)nospam.com> wrote in message news:ei4UgTDbFHA.2128(a)TK2MSFTNGP15.phx.gbl... > 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? 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. > 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? No protection --PA
From: Dean Ramsier on 8 Jun 2005 14:14 Thanks for the help! -- Dean "Pavel A." <pavel_a(a)NOwritemeNO.com> wrote in message news:eDQDC1EbFHA.3132(a)TK2MSFTNGP09.phx.gbl... > "Dean Ramsier" <ramsiernospam(a)nospam.com> wrote in message news:ei4UgTDbFHA.2128(a)TK2MSFTNGP15.phx.gbl... > > 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? > > 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. > > > 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? > > No protection > > --PA > > >
From: Maxim S. Shatskih on 9 Jun 2005 01:02
> 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? 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(a)storagecraft.com http://www.storagecraft.com |