home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vxworks / 1008 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.4 KB
  1. Path: sparky!uunet!hela.iti.org!cs.widener.edu!icf.hrb.com!els
  2. From: els@icf.hrb.com (Eric L. Schott)
  3. Newsgroups: comp.os.vxworks
  4. Subject: Re: VMEbus slot number (not strictly VxWorks)
  5. Message-ID: <1992Nov11.145052.19749@icf.hrb.com>
  6. Date: 11 Nov 92 14:50:52 EST
  7. References: <1992Nov10.163644.18883@alcatel.ch>
  8. Distribution: comp.os.vxworks
  9. Organization: HRB Systems, Inc.
  10. Lines: 41
  11.  
  12. In article <1992Nov10.163644.18883@alcatel.ch>, ross@srxvb303.alcatel.ch (David Ross) writes:
  13. >  
  14. > We're using VxWorks with Heurikon HK80/V960 VMEbus boards, and 
  15. > we want to get rid of the boot parameters required for each 
  16. > node. We can see a way to do this, by adding RARP code to 
  17. > the boot ROM backplane driver (yes, quite a bit of work), but 
  18. > the one boot parameter we can't see how to deal with is the 
  19. > "processor number". This is required so that processor 0 can 
  20. > export some of its local RAM to one of the VME address
  21. > spaces so that the other boards can use it for the backplane 
  22. > comms, and also so that the other boards can access their
  23. > own structures in the shared memory (using processor number as 
  24. > an index). 
  25. >  
  26. > So, is there any way a VMEbus board can determine which slot it
  27. > is in? I'm not too optimistic as the VMEbus specification doesn't 
  28. > provide any "geographical address" signals, but I thought that 
  29. > somebody may have dealt with this before.
  30.  
  31. The slot 0 board must be system controller.  Typically this is also
  32. processor 0.  Some boards have a register which indicates if the
  33. CPU is the system controller.
  34.  
  35. One board I have used has a parallel printer port which goes out the
  36. P2 connecter.  We were able to uniquely identify cards by tying the
  37. pins either high or low.
  38.  
  39. Yes, the entire concept of NVRAM boot parameters is a pain.  This is
  40. especially true when cards need to be swapped.  Even RARP has problems
  41. here in that the database on the host CPU needs changed when cards move.
  42. The best approach we have found is to use this printer port to uniquely
  43. identify each card.  This id is broadcast on the network.  A daemon
  44. running on the host the responds with an ethernet packet which has
  45. the entire boot string.  Then cards can be swapped without changing
  46. any databases.
  47.  
  48. -- 
  49.  
  50. Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  51.   "As we acquire more knowledge, things do not become more comprehensible
  52.    but more mysterious."                  Albert Schweitzer, "Paris Notes"
  53.