home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / wizards / 3591 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  4.1 KB
  1. Path: sparky!uunet!sun-barr!ames!nsisrv!mimsy!blenny!gobi!stevek
  2. From: stevek@gobi.UUCP (Stephen Kogge)
  3. Newsgroups: comp.unix.wizards,alt.unix.wizards
  4. Subject: Re: SBus device driver questions
  5. Message-ID: <64@gobi.UUCP>
  6. Date: 13 Aug 92 01:06:47 GMT
  7. References: <1997@tycho.UUCP>
  8. Organization: Underwater Imaging
  9. Lines: 89
  10.  
  11.  
  12.     I have been working on a Bit3 to Multibus device driver. Not
  13. finished yet...
  14.  
  15. In article <1997@tycho.UUCP> coltoff@tycho.UUCP (Joel Coltoff) writes:
  16. >
  17. >I'm attempting to write a loadable device driver for a Sparc Station
  18. >SBus adapter. It isn't one that we designed so there is a suprise
  19. >here and there. It's a Bit3 card for a remote VME bus. The driver
  20. >actually controls the cards in the remote VME backplane. At least
  21. >for now they are all the same type If anyone has done this and would
  22. >like to share their experiences I'd be happy to listen.
  23. >
  24. >The first set of problems deals with addresses. The adapter card
  25. >has a set of registers at offset 0x200000. At offset 0x1000000
  26. >is the area that maps to the remote VME bus. I've walked the devinfo
  27. >tree a little bit but can't seem to get at the base address of the
  28. >Sbus card. Am I going to get burned by doing the following to get
  29. >the base address of my VME cards?
  30. >
  31. >    u_int * bit3_addr;
  32. >
  33. >    bit3_addr = (caddr_t) devinfo_p->devi_reg->reg_addr;  
  34. >    bit3_addr = (caddr_t) ((u_int) bit3_addr & ~(0x200000));  
  35. >    bit3_addr = (caddr_t) ((u_int) bit3_addr | 0x1000000);
  36. >
  37.  
  38.     The Multibus and VME systems look the same from the
  39. Sun/bit3/sbus side.
  40.  
  41.     You will need to have two kernel mapped regions. One for the
  42. bit3 control registers and the other for your VME memory space.
  43. No problem with the control region, but the memory region presents
  44. problems for the kernel.
  45.  
  46.     Sun only lets the kernel map in 8 (I think it is only 8) meg max
  47. so you cannot just map in the entire VME space.  My first attempts
  48. tried to just map in all 16meg of my Multibus space, it took a while
  49. to realize that this approach would not work.
  50.     The solution is to set up the sbus card to map in say 64k and use the
  51. bit3 map registers to look into any part of the VME space.
  52.     Problems:
  53.     1) you have to lock the bit3/sbus/VME map register so that a second
  54.     call does not change it out from under you. You do your IO
  55.     to your IO VME memory registers mapped via the bit3 "map".
  56.     2) to transfer data between the VME and the Sun you change the bit3
  57.     "map" and do a "bcopy". Again you will need to lock the sbus
  58.     bit3 "map" with software.
  59.     3) The user is allowed to map in the entire VME (multibus)
  60.     space but to do so you will have to change those bit3 mapping
  61.     registers, again the code that allows these changes must remember
  62.     what the kernel set them to.
  63.  
  64.     Messy no matter how you do it. Time keeps me from finishing
  65. my driver. Simple user mmaps lets me get away with fake drivers from
  66. user code == motivation to get the driver done is low. I sure would
  67. like the interrupts to work ;-)
  68.  
  69. >Secondly, I'd like to be able to use as much of the Sun VME driver
  70. >as possible. However, that deals with virtual addresses and what
  71. >I get from above is a physical address. I know that you can use
  72. >map_regs() to get a virtual address but that's where my knowledge
  73. >ends. The Sun SBus driver manual shows an example driver that
  74. >when unloaded does an unmap_regs(). Is the unmap_regs() strictly
  75. >necessary? This is important becuase if it is I can't jam the return
  76. >value of map_regs() into a automatic variable. Is there another approach
  77. >to doing this? Physical memory is contiguous but what about mapped
  78. >virtual memory? Given the word "map" in the function calls I would be
  79. >surprised if it is.
  80. >
  81.  
  82.     Remember that this is a kernel routine and each map_regs() uses
  83. resources and you really ought to unmap them else after a few "loads"
  84. of your driver you will use up all the kernel map resources.
  85.  
  86. >Lastly, at least for now, is there anything that falls in the category
  87. >of EVERY NOVICE SBUS DEVICE DRIVER WRITER FORGETS TO DO THIS?
  88. >
  89. >    Thanks,
  90. >      - Joel Coltoff
  91. >      tycho!coltoff@cs.widener.edu
  92.  
  93.  
  94.     Maybe it's is time to start annoying Chris Torek again and finish
  95. up my bit3-multibus driver. I got a lot more done when he was in Maryland and
  96. came over to watch Quantum leap.
  97.  
  98.     Steve Kogge
  99.     stevek@uimage.com
  100.