home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / sysv386 / 17481 < prev    next >
Encoding:
Text File  |  1992-12-17  |  4.0 KB  |  77 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!mcsun!Germany.EU.net!urmel.informatik.rwth-aachen.de!solaris.rz.tu-clausthal.de!unios!lysithea.rz.Uni-Osnabrueck.DE!rlammers
  3. From: rlammers@lysithea.rz.Uni-Osnabrueck.DE (R. Lammers FB Physik)
  4. Subject: ISC and mapping of physical memory
  5. Message-ID: <BzEtu2.J7I@unios.rz.Uni-Osnabrueck.DE>
  6. Sender: news@unios.rz.Uni-Osnabrueck.DE
  7. Organization: University of Osnabrueck, FRG
  8. Date: Thu, 17 Dec 1992 15:32:26 GMT
  9. Lines: 66
  10.  
  11. Hi all,
  12.  
  13. I'm just trying to port a device driver from SCO UNIX to Interactive UNIX
  14. (version 3.0). But I encountered some problems. Perhaps someone on this
  15. newsgroup can help me to solve them.
  16.    I've got several i860 CPU cards with dual ported RAM located at the
  17. physical address 0xd0000. This piece of memory is used for communication
  18. between an 860 CPU and an i386 executable called Server which is responsible
  19. for loading and starting an 860 program and which performs all I/O requests.
  20. To access the dual ported memory the Server first calls the open routine
  21. of the device driver to get a handle and then makes an ioctl function call
  22. which maps the dual ported RAM into the Server's address space. Now the
  23. Server has got direct access to the memory at 0xd0000.
  24.    And here is where I'm having the trouble with ISC:
  25. How can I map physical memory into the address space of a user process ???
  26.    I need something equivalent to SCO's vas*() kernel functions (vasbind(),
  27. vasmalloc(), vasmapped(), vasunbind()). These routines allow a driver to map
  28. physical memory so that it can be read from or written to by both a driver
  29. and a calling _user_ process. Memory that has been mapped is visible to the
  30. kernel and to a _calling_ process. However, the mapping is not globally
  31. visible to all processes.
  32.    Well, I first asked my local dealer for help. But all I got from him
  33. is the incomplete description of two functions:
  34.  
  35.    mappages(begmapaddr, length, begphysaddr)
  36.    caddr_t begmapaddr;
  37.    int length;
  38.    paddr_t begphysaddr;
  39.  
  40.    freemappages(begmapaddr, length, dzero)
  41.    caddr_t begmapaddr;
  42.    int length, dzero;
  43.    
  44. According to my investigation these functions are not part of the kernel
  45. library but of the keyboard/display driver (kd). I think they are used by
  46. the ioctl calls KPMAPDISP/KDUNMAPDISP (see display(7)) which allow direct
  47. access to the video memory for a user process.
  48.    My question is whether there's anybody who has experience with mappages()/
  49. freemappages() ? Is the parameter 'begmapaddr' an address in the user's or
  50. kernel's address space ? Must it be on a page boundary ? Must 'length' be
  51. a multiple of a page size ? How can I reserve the memory in the address space
  52. of the user process (via malloc?) ? And what about the return values of these
  53. functions ? What are their meanings ?
  54.    You see, a lot of questions and I do not have any answer for them. I hope
  55. someone out there can help. Thanks in advance. Please respond via e-mail as
  56. I do not subscribe to this newsgroup.
  57.  
  58. Ralf Lammers
  59.  
  60. PS: BTW, does anybody know an e-mail address of Interactive (SunSoft) where
  61.     to report bugs ? I found a lot of them in ISC's version 3.0. Well, I
  62.     already reported them to your local distributer but it seems to me they
  63.     send them to /dev/null.
  64.  
  65. --
  66. *******************************************************************************
  67. * Ralf Lammers                                                                *
  68. * Universitaet Osnabrueck         Phone:    +49 541 969 2621                  *
  69. * Fachbereich Physik              Fax:      +49 541 969 2670                  *
  70. * Barbarastrasse 7                Internet: rlammers@physik.uni-osnabrueck.de *
  71. * W-4500 Osnabrueck, Germany      Bitnet:   rlammers@dosuni1                  *
  72. *******************************************************************************
  73. * "We must fall back on the old axiom that when other contingencies fail      *
  74. *  whatever remains - however improbable - must be the truth."                *
  75. *                                                  (Lt. Cmdr. Data in ST:TNG) *
  76. *******************************************************************************
  77.