cheung@moncskermit.oz (Lawrence Cheung) (12/02/85)
In our image processing work, we are trying to interface a frame
grabber to a National Semiconductor VR32 unix machine running on
System V R 2. In order to have very fast access to the frame store,
we intend to put the frame grabber in the physical memory map and
access the frame grabber through its PHYSICAL ADDRESS, so the question
is:
1) Can we access a physical address directly in UNIX without using a
device driver?
2) Can we have fast access to the frame grabber using other means?
PS. NS VR32 is a 2 users machines and using multibus and NS32016
processor.
Djsdy@hadron.UUCP (Joseph S. D. Yao) (12/03/85)
In article <270@moncskermit.oz> cheung@moncskermit.oz (Lawrence Cheung) writes: >we intend to put the frame grabber in the physical memory map and >access the frame grabber through its PHYSICAL ADDRESS, ... >1) Can we access a physical address directly in UNIX without using a > device driver? Hard to answer. To access anything in UNIX, you have to use some kind of code, which can be construed as a device driver. If you are asking, can you access it directly without the overhead of indexing through the device driver table, then you can use a separate system call; and if you want to avoid that overhead, then you will have to map the memory pages into your process's address space, which can be done, but ... You probably will want your "open" routine (Oh, here we are in a driver again) to lock the frame buffer from other access, put your process close to the kernel in physical memory (to reduce fragmentation), lock it against swapping or paging, and then modify your segment addresses so that the buffer is in your address space, when you are scheduled to run. You will have to make sure that the "close" routine undoes all this. Just to be safe, you should make sure that the scheduler and swapper/ pager are happy with pages that shouldn't be touched in your address space. And there are probably a few other things I've forgotten off the top of my head. >2) Can we have fast access to the frame grabber using other means? You could also set up kernel routines that will double- (or n-)buffer frames for you and pass them back. This can be done with n buffers in the kernel, passed back via a copyout() on demand, which may lose data if you are trying an N-per-second grab. This can also be done with buffers that your user program provides. In this case, the program must again be locked against swapping and paging (at least the buffers must); and you will have to provide some sort of signalling mechanism to let the user program know when a buffer is filled. Incidentally, all of these techniques require additions to kernel code that may be considered "driver" code: classic read, direct access via system call, asynchronous read, mapped memory; and each of these can be set up for read on demand or n-buffered storage. I don't know what extra hooks the National VR32 might or might not have; but any of these techniques on baseline VAX sVr2 would require kernel mods (if only just the addition of the driver). -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
lasse@daab.UUCP (Lars Hammarstrand) (12/04/85)
> >System V R 2. In order to have very fast access ...... >....... > >1) Can we access a physical address directly in UNIX without using a > device driver? Yepp, use the PHYS(2) system call (you have to be a "su" to do that). It works like this: phys(key, virtual_address, size_to_map, physical_address) where: - key is a number from 0-3 where each key represents an address map in memory. (max 4 can be active at the same time). - virtual_address is the address in your program that you want to map to a physical address. - physical_address is the "true" address in memory that will be mapped to the virtual address in your program. ** IMPORTANT **, both addresses must be at an address multiple of the resolution of the MMU (i.e. 512,1024,2048,4096) - size_to_map is the number of bytes to map. Also, this value is rounded up to the next MMU resolution. Size of zero means that system will unmap this key. Lars Hammarstrand
campbell@sauron.UUCP (Mark Campbell) (12/09/85)
In article <177@daab.UUCP> lasse@daab.UUCP (Lars Hammarstrand) writes: >> >>System V R 2. In order to have very fast access ...... >>....... >> >>1) Can we access a physical address directly in UNIX without using a >> device driver? > >Yepp, use the PHYS(2) system call (you have to be a "su" to do that). "Phys" was a 7th edition feature...it is not supported in System V. -- Mark Campbell Phone: (803)-791-6697 E-Mail: {decvax!mcnc, ihnp4!msdc}!ncsu!ncrcae!sauron!campbell
paul@unisoft.UUCP (n) (12/09/85)
<oog> Someone suggested the PHYS(2) system call for accessing physical + addresses from user processes. This is a Uniplus 'feature', not a System V 'feature'. Don't expect to see it in a port done by someone other than Unisoft. (Mind you it is a neat idea, just right for mapping in such things as bit mapped graphics, device registers, floating point boards .....) Paul Campbell ..!ucbvax!unisoft!paul ..!houxj!fafnir!pc
jdb@mordor.UUCP (John Bruner) (12/10/85)
In article <612@unisoft.UUCP> paul@unisoft.UUCP (n) writes: > Someone suggested the PHYS(2) system call for accessing physical > + >addresses from user processes. This is a Uniplus 'feature', not a System >V 'feature'. Although the semantics may have been different, wasn't phys() a V7 "feature"? I remember writing a reboot program for the PDP-11 that used this system call. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
campbell@maynard.UUCP (Larry Campbell) (12/10/85)
> Someone suggested the PHYS(2) system call for accessing physical > addresses from user processes. This is a Uniplus 'feature', not a System > V 'feature'. Don't expect to see it in a port done by someone other than > Unisoft. (Mind you it is a neat idea, just right for mapping in such things > as bit mapped graphics, device registers, floating point boards .....) > Paul Campbell > ..!ucbvax!unisoft!paul > ..!houxj!fafnir!pc Uh, VENIX also has a PHYS(2) call that seems to do the same thing. -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
jk@plx.UUCP (jk) (12/12/85)
> > Someone suggested the PHYS(2) system call for accessing physical > + > addresses from user processes. This is a Uniplus 'feature', not a System > V 'feature'. Don't expect to see it in a port done by someone other than > Unisoft. (Mind you it is a neat idea, just right for mapping in such things > as bit mapped graphics, device registers, floating point boards .....) > > > Paul Campbell > ..!ucbvax!unisoft!paul > ..!houxj!fafnir!pc wrong paul, phys(2) was a V7 "feature" (and a bad one at that!).
lasse@daab.UUCP (Lars Hammarstrand) (12/13/85)
> Someone suggested the PHYS(2) system call for accessing physical > + >addresses from user processes. This is a Uniplus 'feature', not a System V.. That's right folks, I didn't look close enought in manual. Sorry ! So you shouldn't be sorry if you didn't find in your manual! Lars Hammarstrand.
jans@mako.UUCP (Jan Steinman) (12/16/85)
I'm suprised no one has mentioned this, and perhaps I'm being naive in suggesting it, but can't one simply open /dev/mem and lseek() to the desired physical address? I realize this requires suid root, but the other solutions apparently do also. From my UTek manual, section 4: MeM is a special file that is an image of the main memory of the computer. It may be used, for example, to examine (and even to patch) the system. Byte addresses in mem are interpreted as physical memory addresses. References to non-existant locations cause errors to be returned. Am I missing something, or is this not the most simple way to "get at the RAW BITS". It may well be a Berkleyism, SysV folk care to comment? -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::