larry@focsys.UUCP (Larry Williamson) (07/26/88)
How does one get access to a memory buffer that is hard wired to a
physical memory location outside of the normal system memory?
I have a video frame grabber that uses an onboard 1Meg buffer. This
buffer is available to the system the 10meg address boundry (ie, at
0xa00000). This is well passed the 2.5Meg of system ram that is in the
system.
I must write a driver that will give a user process access to this
memory.
I expect to provide two device entry points, /dev/vidreg & /dev/vidmem
for the video registers and memory respectively that are on the board.
When a user wants access to some of the video information, they would
lseek() on /dev/vidmem to the location of interest and then read() the
data. When they want to get a new frame from the camera, they would
ioctl() on /dev/vidreg to set the appropriate command bits.
If I use this technique, I must tell my driver to use a physical memory
buffer, but I do not understand how to tell my driver to read from
physical address 0xa00000.
As an alternative, I would consider mounting the 1 meg of memory as a
shared memory segment that the user process would attach and simply use
like a 1 meg buffer in their own space. This is a good idea for efficiency,
but it might be more difficult to restrict access at critical times.
But in this case, I don't know how to tell the system to mount the
physical memory as a shared memory segment (In uport V/AT, I'd just use
/etc/shmcreate)
I am using Bell Tech's Unix system V/386.
I have poured through the book "Writing a Unix Device Driver" by Janet
Egan and Thomas Teixeira. And although this book is a gold mine of
information, it does not seem to address my problem (or more likely, I
have not figured out what it is that they are saying!).
Any help would be appreciated.
Thanks,
Larry
--
Larry Williamson Focus Automation Systems
UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4
+1 519 746 4918mikep@ism780c.isc.com (Michael A. Petonic) (07/28/88)
In article <193@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: >How does one get access to a memory buffer that is hard wired to a >physical memory location outside of the normal system memory? > [...] >If I use this technique, I must tell my driver to use a physical memory >buffer, but I do not understand how to tell my driver to read from >physical address 0xa00000. > >I am using Bell Tech's Unix system V/386. > >Thanks, > Larry Since Bell Tech's UNIX system V/386 is close to our's (INTERACTIVE's 386/ix (see various articles describing the ancestry)), I looked in our ``Writing 386/ix Device Drivers'' book and it mentions the macros ``phystokv()'' and ``kvtophys()'' which map between physical addresses and kernel virtual addresses. They are defined in <sys/immu.h>. This should be relevant to Bell Tech's system. -MikeP -------- Michael A. Petonic (213) 453-8649 x3247 INTERACTIVE Systems Corporation "My opinions in no way influence 2401 Colorado Blvd. the price of tea in China." Santa Monica, CA. 90404 {sdcrdcf|attunix|microsoft|sfmin}!ism780c!mikep
dave@micropen (David F. Carlson) (07/28/88)
Why do smart mailers mess things up nearly 100% of the time? > > How does one get access to a memory buffer that is hard wired to a > physical memory location outside of the normal system memory? > > Larry Williamson Focus Automation Systems > UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4 > +1 519 746 4918 Larry, First, there is no need for two devices. vidbuf can contain both your memory map and the ioctl interface to the registers. Good coding practice dicates an abstraction level from your physical registers to the actual ioctl functions your define. For 386 unix in the kernel: char *sptalloc( int size /* in 4k pages */, int mode /* PG_P in immu.h */, int base /* physical address in 4k pages (ie << 12 ) */, int flag /* don't care for non-zero base */ ) void sptfree(vaddr, size, flag) /* similarly to above */ alloc can be an init routine in the driver or on first open. I have never used free because I want the mapping to be for the lifetime of the kernel. Good luck. David F. Carlson, Micropen, Inc. ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll -- David F. Carlson, Micropen, Inc. ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll