Thanks Alberto,
I’ll be experimenting as per your suggestions and let see how far I can go 
Regards,
Alan
Alberto Moreira wrote:
Just map the memory in the simulator, and stick its address and stuff into the right i/o manager structures so that it can be picked up by the driver at DriverEntry and AddDevice time. You basically have to find a way to fool the OS into believing that you are really a device on the other side of the PCI bus, but that can be done. Handling I/O is a bit more tricky, because you may have to fiddle with the TSS’s I/O map so that you get interrupted every time the driver issues an I/O to your pseudo device and you can produce or consume the I/O information inside your ISR or even DPC. DMA in a simulator is just a memory copy. You may also have to worry about resource translation and about generating the right interrupts at the right time.
This may be an interesting project, but people write hardware simulators all the time, this is not a new idea. Back in 1993 I worked on a Windows 95 display driver for a chip that didn’t exist yet, and the simulator was a layer that intercepted all accesses, packaged it into TCP/IP messages, and forwarded those to the hw simulator that lived on a Unix machine somewhere else in the network. Slow as molasses, but hey, beats nonexistent hardware hands down.
Now, if you can come up with a new idea about simulating hardware, yes, that’s more like something that could be a target of a degree project!
Alberto.
----- Original Message -----
From: Alan Dart
To: Windows System Software Devs Interest List
Sent: Saturday, September 24, 2005 1:20 PM
Subject: Re: [ntdev] How to Assign IO resources to virtual device
Guys,
As far as I know (which is very less so please set me straight if I am wrong) there is three ways a driver can interact with hardware:
1. I/O Port
2. Mapped memory
3. DMA
I won’t bother what way I use, just want make FDO feel that this is dealing with real device. Also I am doing this just for experimentation (I am searching a good idea for my degree project).
Alberto, please explain a bit more about bus memory simulation?
Thanks,
Alan
Alberto Moreira wrote:
In this day and age it’s probably not that good an idea to
design hardware that operates on I/O space anyway, and I’d fight
my hw engineers tooth and nail if they wanted to slip in that
kind of kluge into a contemporary design. Now, bus memory is
easy to simulate through virtual memory interrupts, and in fact,
a little bit of enterprising curiosity might figure out how to
use that TSS bit to generate exceptions on I/O instructions too.
Although I don’t know it for sure, I believe that’s how things
like VMWare work, no ?
You are right however that it’s not that good an idea, because
hardware is nondeterministic, while software emulators rarely
are. Yet having a simulator allows us to debug before the chip
and the board are available. Another good step is to convince
the hw guys to build an FPGA board, on a Xilinx chip for
example, with a partial implementation of the future hardware:
although you don’t get the full functionality, you get plenty of
it, enough to make yourself dangerous. And that helps them
debugging the hw too, many bus interface problems can be caught
rather early at the FPGA stage. And if that kind of work avoids
one rev of the chip, it’ll have paid itself royally many times
over.
Alberto.
----- Original Message -----
From: “Loren Wilton”
To: “Windows System Software Devs Interest List”
Sent: Friday, September 23, 2005 10:31 PM
Subject: RE: [ntdev] How to Assign IO resources to virtual
device
> Alan, the only you can make that work would be with a tad of
> real hardware. You would have to have some sort of dev card
> that had some ram backing actual IO ports. There probably
> wouldn’t have to be anything else there in a lot ! of cases, but
> you would need at least that much.
>
> Short of that, you can still make the driver look the same or
> almost the same, but you are going to have to do a little
> creative work with macros to change xx_PORT_ to actually talk
> to a little memory someplace.
>
> You may also need some external emulation to emulate the
> device you are pretending to control. After all, it probably
> raises interrupts, and they probably hang around until some
> bit is changed in a register someplace in the device. The
> data in the IO ports and memory may also change from external
> state changes.
>
> I remember doing software emulation of hardware boards using a
> funny glue board back in the ISA days, so that we could debug
> device drivers before the real hardware board was built.
> Didn’t really help much, because it resulted in a driver that
> worked correctl! y per the hardware spec. Of course the
> hardware designers had changed the hardware three times over
> without ever updating the spec, and that was even before the
> timing and logic bugs in the hardware that we had to work
> around. Overall, it was deemed to be a waste of time and
> resources, since we generally ended up having to redesign the
> driver from scratch along totally different lines than those
> implied by the original design spec.
>
> Loren
>
>
> Doron, Loren,
> What I am trying to do is simulating a hardware in such a way
> that function driver never come to know that it is dealing
> with virtual hardware. That’s why I wanted to return resources
> in IRP_MN_QUERY_RESOURCE_REQUIREMENTS. But seems that this is
> not possible as in both the ways you guys suggested function
> driver will know that it is not dealing with real device or I
> am missi! ng something?
>
> Thanks,
> Alan
>
> Doron Holan wrote:
> If you are going to just use plain memory, you don’t even need
> to claim
> them using pnp arbitrated resources. In start device of the
> “toaster”,
> just send an IOCTL down to the PDO have the PDO hand back an
> address
> (which can be a pointer into the device external or a piece of
> pool from
> ExAllocatePool).
>
> In addition to the memory, the PDO will give back a set of
> function
> pointers (read byte, write byte, read word, write word, etc).
> Instead of
> using WRITE_PORT_UCHAR and friends, you use the function
> pointers
> provided by the PDO in the toaster FDO. This way there is no
> polling,
> you immediately know that a read or write occurred. This will
> work at
> dispatch_level, the polling method in a thread will ! only work
> at
> passive_level.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Loren
> Wilton
> Sent: Friday, September 23, 2005 2:33 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] How to Assign IO resources to virtual
> device
>
>>The problem is, no matter what I write (using
>>WRITE_PORT_UCHAR)on this
>>address, Bus driver thread is getting 0xFF only.
>
> You have a serious basic problem here. You are writing data
> into outer
> space, and the bits fall off the end of the universe. They are
> not
> going to
> come back.
>
> Stated another way, there is no hardware at the addresses you
> are
> writing
> to, so there is nothing to store the bits. They just vanish
> into the> night.
> When you read from the IO port, there is nothing to drive the
> bus, so
> the
> lines float high, and you read FF back.
>
>> Any suggestion?
>
> If you really want to share data, you are going to have to
> substitute a
> region of memory for the IO ports. Which means you can’t use
> READ/WRITE_PORT_xxx, since the port wont be where the data is.
>
> However, virtually all modern PCI cards will map their
> register space
> into
> memory as well as into registers. In fact new PCI cards aren’t
> supposed
> to
> require IO resources, at least on server platforms. So you
> could write
> code
> to deal with the IO ports in memory space in most cases
> without
> problems.
> Only if you are intending this to be something that talks to
> ancient
> legacy
> devices will this be a real problem.
>!
> Loren
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@microsoft.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@earthlink.net
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort. — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@ieee.org To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com