First, some background. I’ve got a custom pcmcia card based on an old
memory card. The card contains the usual flash memory for the disk (which
I do NOT use or even care about) and then some custom stuff that hangs off
of I/O space. The tuples in the CIS are correct but do not contain the
required resources.
My driver is implemented as a filter driver on top of memcard.sys. I
handle IRP_MN_FILTER_RESOURCE_REQUIREMENTS to add my I/O requirement and
also add the DevicePrivate resource that dictates stuff like wait states
and width. I then get the assigned I/O resources when START_DEVICE comes
through my filter. Looking at a debug version of pcmcia.sys with the debug
mask turned on full, everything looks ok as my card is installed. It sees
my memory window, it sees my I/O range, it has the right values in the
config resource section of the output, it correctly reads my tuples and
knows that I have one function control register (FCR). It seems happy.
Now for the “but” everyone is expecting. Part of the project’s
functionality requires that I be able to change that first FCR (the
Configuration Option Register) dynamically as dictated by the actions in a
user program. Everything I’ve read says the function control registers are
part of attribute memory and sit just after the 512k area reserved for the
CIS tuples. My approach is to issue an IRP_MN_READ_CONFIG to device I’m
filtering to read all of attribute memory (length of 513 - 512 for CIS and
1 for FCR), change my single register and issue an IRP_MN_WRITE_CONFIG to
change attribute memory. Doesn’t work - if I issue a second READ_CONFIG
after I’ve done the WRITE (which returns STATUS_SUCCESS), the data
starting after the CIS area is back to its old value. In fact, I issued a
READ_CONFIG with a big buffer and it contains the 512 CIS area repeated
over and over for as big as the buffer. My WRITE has no affect. If I can’t
set this register on the fly, this whole effort is useless.
My question - how do I write to that first FCR?
Windows XP, SP1
Thanks,
Judy
(cross posted to microsoft.public.development.device.driver)
Hello
Do you have memory window for attribute memory?
If yes, what the problem?
You can ask the PCMCIA driver to provide the PCMCIA_INTERFACE_STANDARD
interface. Using this interface
you can tune memory windows.
If you have no the memory window, ask PCMCIA to give the
BUS_INTERFACE_STANDARD. Get/SetBusData methods of this interface can help
you
Good luck
wrote in message news:xxxxx@ntdev… > > First, some background. I’ve got a custom pcmcia card based on an old > memory card. The card contains the usual flash memory for the disk (which > I do NOT use or even care about) and then some custom stuff that hangs off > of I/O space. The tuples in the CIS are correct but do not contain the > required resources. > > My driver is implemented as a filter driver on top of memcard.sys. I > handle IRP_MN_FILTER_RESOURCE_REQUIREMENTS to add my I/O requirement and > also add the DevicePrivate resource that dictates stuff like wait states > and width. I then get the assigned I/O resources when START_DEVICE comes > through my filter. Looking at a debug version of pcmcia.sys with the debug > mask turned on full, everything looks ok as my card is installed. It sees > my memory window, it sees my I/O range, it has the right values in the > config resource section of the output, it correctly reads my tuples and > knows that I have one function control register (FCR). It seems happy. > > Now for the “but” everyone is expecting. Part of the project’s > functionality requires that I be able to change that first FCR (the > Configuration Option Register) dynamically as dictated by the actions in a > user program. Everything I’ve read says the function control registers are > part of attribute memory and sit just after the 512k area reserved for the > CIS tuples. My approach is to issue an IRP_MN_READ_CONFIG to device I’m > filtering to read all of attribute memory (length of 513 - 512 for CIS and > 1 for FCR), change my single register and issue an IRP_MN_WRITE_CONFIG to > change attribute memory. Doesn’t work - if I issue a second READ_CONFIG > after I’ve done the WRITE (which returns STATUS_SUCCESS), the data > starting after the CIS area is back to its old value. In fact, I issued a > READ_CONFIG with a big buffer and it contains the 512 CIS area repeated > over and over for as big as the buffer. My WRITE has no affect. If I can’t > set this register on the fly, this whole effort is useless. > > My question - how do I write to that first FCR? > > Windows XP, SP1 > > Thanks, > Judy > (cross posted to microsoft.public.development.device.driver) > >