From biocca@bevsun.bev.lbl.gov Thu Oct 3 12:50:19 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Oct 3 12:50:26 PDT 1991 Subject: Exploder Failure It appears that a bug in the beginning-of-month script for the exploder shut it down until now. Sorry about the inconvenience -- please resend any articles that bounced or didn't show up. Alan K Biocca From markb@slc.unisys.com Thu Oct 3 19:32:04 1991 From: markb@slc.unisys.com (Mark Baranowski) Date: Thu Oct 3 19:32:19 PDT 1991 Subject: Client-side RPC problem Dear Fellow VxWorkers: I'm having problems with a client-side RPC program using VxWorks 5.0. My RPC server program is on machine "V" running VxWorks 5.0 on a TSVME-133 board. I have two machines running my RPC client program: Machine "S" is a Sun/4e running SunOS 4.1 Machine "V" is the same host as is running the RPC server program When the client on machine "S" calls the server on machine "V", everything works fine. But when the client on machine "V" calls the server which is also on machine "V", I get a bus error in the routine pmap_getport(). (Before you tell me about rpcTaskInit() let me tell you that, yes, I am calling it in both the server and in the client.) Here is the strange part: as soon as I nfs mount a disk using nfsMount() everything starts working -- the client on machine "V" can now call the server on the same machine. I suspect that nfsMount() is initializing some RPC code that I don't know about. Does anyone know what that initialization might be? Thanks. From muts@fysap.fys.ruu.nl Fri Oct 4 02:10:10 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Fri Oct 4 02:10:21 PDT 1991 Subject: spy problem in version 5.0 In version 5.0 (and I think I noticed this already in version 4.x), when I use spy, after 3 or three reports spy, nor repeat, nor any watchdog timer is functioning anymore, it seems. This is on a Eurocom 6 (68030) processor card. Is this a known problem, and is there a fix? _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From thor@thor.atd.ucar.edu Fri Oct 4 05:34:07 1991 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Fri Oct 4 05:34:17 PDT 1991 Subject: Monthly posting of archive holdings Hopefully you will soon see the first monthly posting of the holdings of the VxWorks archive. If you have comments about the format used please let me know. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. From thor@thor.atd.ucar.edu Fri Oct 4 05:35:07 1991 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Fri Oct 4 05:35:23 PDT 1991 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 1341 -rw-r--r-- 1 thor 2070 Sep 23 10:48 README -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 5396 Apr 4 1990 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 8263 Oct 2 09:11 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 27824 May 30 1989 jobCondLib -rw-r--r-- 1 thor 25014 May 30 1989 jobLib lrwxrwxrwx 1 root 10 Aug 14 07:11 jobcondlib -> jobCondLib lrwxrwxrwx 1 root 6 Aug 14 07:11 joblib -> jobLib -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 07:11 libx11 -> libX11 -rw-r--r-- 1 thor 25077 Oct 9 1990 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 122509 Oct 2 08:59 ntp.vx.tar.Z -rw-r--r-- 1 thor 14124 Apr 4 1990 pipe_class.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 07:11 poollib -> poolLib -rw-r--r-- 1 thor 10687 Apr 4 1990 ringbuffer_class.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 07:11 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 15096 Oct 2 08:55 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 44454 Aug 12 10:09 vw_curses.p1 -rw-r--r-- 1 thor 50053 Aug 12 10:07 vw_curses.p2 -rw-r--r-- 1 thor 62453 Aug 12 10:11 vw_curses.p3.uu -rw-r--r-- 1 thor 93789 Aug 1 21:11 vw_curses.tar.Z -rw-r--r-- 1 thor 29720 Aug 28 14:10 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 14:10 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 14:10 vxrsh.p3 Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Oct 26 1989 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar drwxr-xr-x 2 thor 512 Feb 11 1990 xdbx Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. From wrs!yuba!ehipp@uunet.uu.net Fri Oct 4 13:04:44 1991 From: wrs!yuba!ehipp@uunet.uu.net (Emily Hipp) Date: Fri Oct 4 13:04:55 PDT 1991 Subject: Re: Client-side RPC problem > My RPC server program is on machine "V" running VxWorks 5.0 on > a TSVME-133 board. > > I have two machines running my RPC client program: > Machine "S" is a Sun/4e running SunOS 4.1 > Machine "V" is the same host as is running the RPC server program > >Here is the strange part: as soon as I nfs mount a disk using nfsMount() >everything starts working -- the client on machine "V" can now call the >server on the same machine. I suspect that nfsMount() is initializing I don't believe so. The only RPC specific initialization that nfsMount (or anything called by nfsMount) does is call rpcTaskInit. In addition, I have tested this out by running a RPC client and server both on the same target running vxWorks 5.0 (however, not on the target listed above) with out mounting a NFS filesystem and it works fine for me. Emily Hipp ehipp@wrs.com From hmp@frc2.frc.ri.cmu.edu Fri Oct 4 13:41:14 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Fri Oct 4 13:41:25 PDT 1991 Subject: WHAT? No more CMC Ethernet boards? I just heard that Motorola is no longer selling MV330 ethernet boards, which are actually manufactured by CMC, I believe. Can anyone confirm this, and tell me whether it's just Motorola no longer carrying it under their name or if it is really not made any more? In the former case, can one buy these boards directly from CMC, or what would be an appropriate source? In general, what other ethernet boards are people using out there? We have used the MV330 ever since we started using vxWorks, and never had one fail on us or give us problems otherwise; I'd be looking for a replacement with the same kind of proven track record. -Henning +-------------------+-----------------------------+--------------------------+ |Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center| |Research Programmer|(412) 268-7088 |Carnegie-Mellon University| +-------------------+-----------------------------+--------------------------+ Just because I don't care doesn't mean I don't understand! -- Homer Simpson From wrs!yuba!ricks@uunet.uu.net Mon Oct 7 12:30:49 1991 From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek) Date: Mon Oct 7 12:31:04 PDT 1991 Subject: Re: ENET boards I suppose I'll put in a plug for my prior employer, SBE Inc. They make a VME board called the VLAN-E that is solid and affordable. We use them here at WRS. Call them at 5106807722. Rick ricks@wrs.com From smb@afterlife.ncsc.mil Mon Oct 7 21:14:08 1991 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Date: Mon Oct 7 21:14:20 PDT 1991 Subject: FDDI board support The latest edition of EDN has a survey of FDDI boards now on the market. Although device driver support isn't specified for most of the boards, one or two mention VRTX support. Anyone know of any FDDI boards with VxWorks driver support? Anyone have any experience with such boards (under VxWorks or otherwise)? Thanks, Steve smb@afterlife.ncsc.mil From barry@cod.nosc.mil Tue Oct 8 08:50:03 1991 From: barry@cod.nosc.mil (Barry L. Smith) Date: Tue Oct 8 08:50:17 PDT 1991 Subject: Re: FDDI board support There is a VxWorks driver available for the Interpahse 4211 from Interphase. I have also ported the 4211 driver for a customer and it works find. By the way the Interphase 4211 is now on special if you are considering buying them. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ rip here /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Barry L. Smith | Computer Sciences Corp. e-mail barry@cod.nosc.mil (Primary) | 4045 Hancock St. -OR- | San Deigo, CA 92110 [ e-mail barry@dcon.nosc.mil ] | 619.225.2747 619.553.1439 | FAX: 619.226.0462 From biocca@bevsun.bev.lbl.gov Tue Oct 8 11:53:50 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Tue Oct 8 11:53:58 PDT 1991 Subject: Administrivia Early in the process of setting up the new software for the exploder we had a discussion about what to do with the addressing of the mail. I collected the comments and took an informal vote and it was slightly in favor of staying the way it is now, so I didn't change things. Other changes in process now may appeal to those who preferred the 'from' to refer to the original poster rather than back to the exploder. There will soon be a new service available -- it is under test now -- that will provide a daily digest form of the exploder traffic. This is mailed out early in the morning each day (if there's anything to mail) and reduces the annoyance factor for those who don't want interruptions. All articles for the previous day are contained in one mailing. The archive system is building monthly archives, and soon we'll set them up for anon ftp. The format is mail compatible, and when displayed the mail tool picks up the author as the 'from' field, which was what some wanted the regular mailings to do. Perhaps we can undertake to recover the old archives and massage them into the same format (if they're not already) and make them available there also. The request periodically is made to create a newsgroup, probably comp.realtime.vxworks, to move this traffic to. This has been discussed at various user group conferences and the consensus seems to be that this is a good idea but it won't alleviate the need for the exploder. The best setup would be both a newsgroup and the exploder tied together so that postings either side would propagate to the other. I'm willing to tackle the interconnection between the exploder and the newsgroup, but we need someone who is willing to go through the process of proposing, posting, collecting votes, etc., to create the group. This would preferrably be a person experienced in this process -- doing it wrong results in no group and a waiting period before trying again. The exploder list is currently over 250 names and perhaps 10 percent of them are lists that have in turn an unknown number of members -- if we have good support within the list for a newsgroup there should be no problem getting the requisite number of YES votes. I've been getting some help here with the exploder lately. Maury McEvoy, our LBL VxWorks support person (following in Sypko Andreae's footsteps) has been handling the subscription list the last several weeks. Thanks, Maury. Alan K Biocca From wrs!yuba!ricks@uunet.uu.net Tue Oct 8 16:30:54 1991 From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek) Date: Tue Oct 8 16:31:04 PDT 1991 Subject: Re: FDDI board support We just announced FDDI support with the Interphase product. Call sales dept. for details. Rick ricks@wrs.com From hmp@frc2.frc.ri.cmu.edu Wed Oct 9 08:32:53 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Wed Oct 9 08:33:12 PDT 1991 Subject: ioctl FIOFLUSH on NFS files Has anyone devised a clever way of accomplishing the equivalent of an ioctl(fd,FIOFLUSH) on an open NFS file? The man page on nfsDrv says that it doesn't support it. I would like to avoid closing and reopening the file if possible - are there any IO system gurus out there who can clue me in? Thanks, -Henning +-------------------+-----------------------------+--------------------------+ |Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center| |Research Programmer|(412) 268-7088 |Carnegie-Mellon University| +-------------------+-----------------------------+--------------------------+ Fast, Cheap, Good: Choose Any Two From hmp@frc2.frc.ri.cmu.edu Wed Oct 9 09:02:14 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Wed Oct 9 09:02:28 PDT 1991 Subject: Correction of previous msg (Re: FIOFLUSH) Oops, I didn't really mean "ioctl FIOFLUSH", but rather the equivalent action of fflush on a stream; the problem seems to be that the NFS driver only actually writes the file to disk in certain increments (something like 8192 bytes, I think), and I would like to trigger this explicitly so that our log file is current on disk in case of a system crash. -Henning +-------------------+-----------------------------+--------------------------+ |Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center| |Research Programmer|(412) 268-7088 |Carnegie-Mellon University| +-------------------+-----------------------------+--------------------------+ Fast, Cheap, Good: Choose Any Two From hill@luke.atdiv.lanl.gov Wed Oct 9 09:59:02 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Wed Oct 9 09:59:10 PDT 1991 Subject: Re: ioctl FIOFLUSH on NFS files I solved this problem by opening a socket on vxWorks to a server running under UNIX which takes input from several sockets and writes it all to a common log file for our many vxWorks based io controllers. Each entry is prefixed by the time and date. We reroute logMsg() on each vxWorks system to this common file. Jeff From litwin@robotics.jpl.nasa.gov Wed Oct 9 10:49:45 1991 From: litwin@robotics.jpl.nasa.gov (Todd Litwin) Date: Wed Oct 9 10:50:01 PDT 1991 Subject: Radstone rs41 VxWorks board support Does anyone have the bootrom.hex file for Radstone's (not Wind's) alpha version of the board support package for the rs41: Radstone 68-41. For some reason, the sources supplied by Radstone won't compile on my system. Radstone tells me that everyone else who has tried was able to get it to work -- I think you need 5.0.1 and I only have 5.0.2 -- but was unable to give me names, phone numbers, email addresses, etc. If any of you are out there, could you please email me a copy of bootrom.hex? Thanks. Todd Litwin Jet Propulsion Laboratory (818) 354-5028 litwin@robotics.jpl.nasa.gov From omni!hwajin@apple.com Wed Oct 9 14:27:48 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Oct 9 14:27:57 PDT 1991 Subject: Re: ioctl FIOFLUSH on NFS files Try setting nfsCacheSize to zero before opening any nfs files. A good place is right after a call to nfsDrv() and before calling nfsMount(). An alternative which may or may not work is to call nfsSeek() with some big number (> 8196) and calling ioctl() with FIOSYNC. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From kozubal@luke.atdiv.lanl.gov Wed Oct 9 15:28:19 1991 From: kozubal@luke.atdiv.lanl.gov (Andy Kozubal) Date: Wed Oct 9 15:28:28 PDT 1991 Subject: Re: ioctl FIOFLUSH on NFS files According to WRS the call ioctl(fd, FIOSYNC) does work for NFS file writes. I tried it in my application, and it works fine. I'm not sure what the overhead is for completing this call, so you will probably not want to use it in a time-critical section of code. You could put in a separate task that executes periodically at a lower priority. ------------------------------------------------------------------ Andy Kozubal | Mail Stop H820 Phone: (505) 667-6508 | Los Alamos National Laboratory E-mail: kozubal@lanl.gov | Los Alamos, New Mexico 87545 ------------------------------------------------------------------ From litwin@robotics.jpl.nasa.gov Wed Oct 9 16:12:55 1991 From: litwin@robotics.jpl.nasa.gov (Todd Litwin) Date: Wed Oct 9 16:13:05 PDT 1991 Subject: DDCMP Do you know of anyone that has written a VxWorks driver to deal with DDCMP protocol over a serial line? We would much rather find code to do this than write it ourselves! DDCMP (Digital Data Communications Message Protocol) is DEC's protocol for handling the low-level error-free transmission as part of their DECNet system. It involves CRC checking, ACKs, NAKs, and resending. When DECNet runs over serial lines this is the low-level protocol that they use. Thanks. Jonathan Cameron jmc@robotics.jpl.nasa.gov Todd Litwin litwin@robotics.jpl.nasa.gov Jet Propulsion Laboratory From lambert@grumpy.ssc.gov Thu Oct 10 07:23:59 1991 From: lambert@grumpy.ssc.gov (David Lambert) Date: Thu Oct 10 07:24:08 PDT 1991 Subject: NFS garbage collecting We are having problems when accessing NFS files. Consider the following trivial code extract: FILE *fp; . . . fp=fopen("/etc/services","r"); . . . fclose(fp); This code initially appeared to work O.K.. However, over an extended period of time we noticed (using iosFdShow) a large number of socket fds. It appears that the fopen() generated two fds, one which contains the filename, and a second for a socket connection. The fd associated with the filename gets removed by the fclose(), but the socket fd remains! Is this a bug? If so, is there a fix or workaround? If not any ideas? From lambert@grumpy.ssc.gov Thu Oct 10 08:00:32 1991 From: lambert@grumpy.ssc.gov (David Lambert) Date: Thu Oct 10 08:00:41 PDT 1991 Subject: NFS garbage collecting (last message got garbled) NFS garbage collecting We are having problems when accessing NFS files. Consider the following trivial code extract: FILE *fp; . . . fp=fopen("/etc/services","r"); . . . fclose(fp); This code initially appeared to work O.K.. However, over an extended period of time we noticed (using iosFdShow) a large number of socket fds. It appears that the fopen() generated two fds, one which contains the filename, and a second for a socket connection. The fd associated with the filename gets removed by the fclose(), but the socket fd remains! Is this a bug? If so, is there a fix or workaround? If not any ideas? From lambert@grumpy.ssc.gov Thu Oct 10 08:44:50 1991 From: lambert@grumpy.ssc.gov (David Lambert) Date: Thu Oct 10 08:44:58 PDT 1991 Subject: NFS garbage collecting (last 2 messages got garbled) Subject: NFS garbage collecting We are having problems when accessing NFS files. Consider the following trivial code extract: FILE *fp; fp=fopen("/etc/services","r"); etc. fclose(fp); This code initially appeared to work O.K.. However, over an extended period of time we noticed (using iosFdShow) a large number of socket fds. It appears that the fopen() generated two fds, one which contains the filename, and a second for a socket connection. The fd associated with the filename gets removed by the fclose(), but the socket fd remains! Is this a bug? If so, is there a fix or workaround? If not any ideas? From OWENS@lodtm.llnl.gov Thu Oct 10 09:22:28 1991 From: OWENS@lodtm.llnl.gov Date: Thu Oct 10 09:22:39 PDT 1991 Subject: RPC service on vxWorks I am considering replacing the graphics terminal on my vxWorks based data acquistion system with a Sun workstation. At first glance it seems that I could use the Sun as a user interface and data display. I was considering using RPC from the user interface to invoke the realtime 'services' on the vxWorks system. After looking at the examples and trying unsuccessfully to compile and run them on the vxWorks system I am becoming less and less enthusiastic about the idea. It appears that the code generated by rpcgen is not compatable with gcc/vxWorks, are there any examples of working RPC services on vxWorks systems out there (preferably something simple like the message demo) ? Thanks, Doug Owens Lawrence Livermore National Lab From hill@luke.atdiv.lanl.gov Thu Oct 10 10:11:45 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Thu Oct 10 10:11:54 PDT 1991 Subject: Re: NFS garbage collecting (last 2 messages got garbled) > The fd associated with the filename gets removed by the fclose(), but > the socket fd remains! The socket option `SO_LINGER' determines whether a TCP socket lingers after it is closed when undelivered data is present. Jeff From dcarr%donut.gandalf.ca@Csa2.LBL.Gov Thu Oct 10 10:19:12 1991 From: dcarr%donut.gandalf.ca@Csa2.LBL.Gov (Dave Carr) Date: Thu Oct 10 10:19:24 PDT 1991 Subject: Re: DDCMP If you manage to get a driver, could you pass it on to me too. Thanks. -- Dave Carr | dcarr@gandalf.ca | If you don't know where Principal Designer | TEL (613) 723-6500 | you are going, you will Gandalf Data Limited | FAX (613) 226-1717 | never get there. From vanandel@rsf.atd.ucar.edu Thu Oct 10 10:56:25 1991 From: vanandel@rsf.atd.ucar.edu Date: Thu Oct 10 10:56:39 PDT 1991 Subject: Re: RPC service on vxWorks We use RPC with rpcgen on VxWorks all the time. You do have to massage the output of rpcgen, as shown below. The use of is to avoid pulling in the Unix version of the rpc header files, which aren't quite compatible with the vxworks provided version. pctl_clnt.c + pctl_svc.c + pctl.h + pctl_xdr.c : \ pctl.x unix.svc.patch vx.header.patch rm -f pctl.h ../include/pctl.h pctl_clnt.c pctl_svc.c pctl_xdr.c rm -f tmp.h rm -f /mhr/src/include/mhr/pctl.h rpcgen pctl.x sed -f vx.header.patch pctl.h >tmp.h mv tmp.h pctl.h cp -p pctl.h ../include cp -p pctl.h /mhr/src/include/mhr sed -f unix.svc.patch pctl_svc.c >tmp.c mv tmp.c pctl_svc.c --------------------------- vx.header.patch contains: \?rpc/types.h?d 1i\ #ifdef VX\ #include \ #else\ #include \ #endif unix.svc.patch contains: s/main()/initPctlSvr()/ s/svc_run();/return;/ s/exit(*)/return/ /svc_run returned/d Joe VanAndel Internet:vanandel@ncar.ucar.edu NCAR / RSF P.O Box 3000 Fax: 303-497-2044 Boulder, CO 80307-3000 Voice: 303-497-2071 From thor@thor.atd.ucar.edu Thu Oct 10 12:25:54 1991 From: thor@thor.atd.ucar.edu Date: Thu Oct 10 12:26:14 PDT 1991 Subject: Re: RPC service on vxWorks In message <9110101622.AA01271@vxw.ee.lbl.gov> you wrote: > > >Submitted-by OWENS@lodtm.llnl.gov Thu Oct 10 09:22:28 1991 >Submitted-by: OWENS@lodtm.llnl.gov > >I am considering replacing the graphics terminal on my vxWorks based >data acquistion system with a Sun workstation. At first glance it >seems that I could use the Sun as a user interface and data display. >I was considering using RPC from the user interface to invoke the >realtime 'services' on the vxWorks system. After looking at the >examples and trying unsuccessfully to compile and run them on >the vxWorks system I am becoming less and less enthusiastic about >the idea. It appears that the code generated by rpcgen is not >compatable with gcc/vxWorks, are there any examples of working >RPC services on vxWorks systems out there (preferably something >simple like the message demo) ? Well, depending on how ANSI-fied you want to get things can be a little complex. We're using g++ for our project, so all functions must be prototyped. This means a bit more modification of the rpcgen output files. What we have found works well is the following: 1> Write a header file that defines the data type(s) to be passed and lists the RPC program/procdure(s) in rpcgen format. 2> Encapsulate the program/procedure definitions in an #ifndef. This means that you can use the header for both rpcgen & g++. 3> Run the header through rpcgen and then apply the changes to the header. This mainly entails adding prototype infromation to the function declarations. However, note that the client and server functions have the same names but different parameters. Use an #ifdef to distingish them. 4> Fix the include file references. We use #ifdefs in the main header to chose between Unix and VxWorks and change the .c files to use only the main header file. 5> Protoize the functions in the .c files. The nice thing about this is that your header file takes the place of the .x file, so you can put comments in without having them lost each time you run rpcgen. I've appended an example header file. Note that to use for the Unix side you need to say: #define OK_RPC #define UNIX #define CLIENT_SIDE #include "TapeHeader.h" For VxWorks: #define OK_RPC #include "TapeHeader.h" ------------------------------------------------------------------- /* * $Id: tapeControl.h,v 1.3 1991/09/06 16:34:06 thor Exp $ * * Module: tapeControl.h * Original Author: Richard E. K. Neitzel * Copywrited by the National Center for Atmospheric Research * Date: $Date: 1991/09/06 16:34:06 $ * * revision history * ---------------- * Revision 1.1 1991/08/28 19:49:14 thor * Initial revision * * * * description: * */ #ifndef INCtapeControlh #define INCtapeControlh #ifdef OK_RPC #ifndef UNIX #include "vxWorks.h" #include "rpc/rpc.h" #include "taskLib.h" #else #include #define FAST register #endif /* UNIX */ #endif /* OK_RPC */ struct TapeCommand { u_long cmd; u_long count; int unit; }; struct TapeError { int error; }; struct ScsiError { int error; }; struct TapeStatus { u_long status; u_long count; u_long failures; u_long attempts; int eot_warning; int unit; struct TapeError terr; struct ScsiError serr; }; #ifdef OK_RPC #include "tapeCommands.h" #include "tapeStatus.h" typedef struct TapeCommand TapeCommand; bool_t xdr_TapeCommand(XDR *, TapeCommand *); typedef struct TapeError TapeError; bool_t xdr_TapeError(XDR *, TapeError *); typedef struct ScsiError ScsiError; bool_t xdr_ScsiError(XDR *, ScsiError *); typedef struct TapeStatus TapeStatus; bool_t xdr_TapeStatus(XDR *, TapeStatus *); #define TapeControl ((u_long)0x30000300) #define TapeCtrlVers ((u_long)1) #define SendCommand ((u_long)1) #define GetTapeStatus ((u_long)2) #ifdef CLIENT_SIDE extern struct TapeStatus *sendcommand_1(TapeCommand *, CLIENT *); extern struct TapeStatus *gettapestatus_1(void *, CLIENT *); #else extern struct TapeStatus *sendcommand_1(TapeCommand *, struct svc_req *); extern struct TapeStatus *gettapestatus_1(void *, struct svc_req *); #endif void startControl(void); #else program TapeControl { version TapeCtrlVers { struct TapeStatus SendCommand(struct TapeCommand) = 1; struct TapeStatus GetTapeStatus(void) = 2; } = 1; } = 0x30000300; #endif /* OK_RPC */ #endif /* INCtapeControlh */ From thor@thor.atd.ucar.edu Thu Oct 10 12:47:27 1991 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Thu Oct 10 12:47:41 PDT 1991 Subject: Fixes to rpc headers We've found that the following patches need to be applied to the files in /vx/h/rpc if you are going to be using an ANSI C compiler or a C++ compiler. They can be applied by the patch utility. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------------------------- --- clnt.h.orig Fri Nov 9 00:21:39 1990 +++ clnt.h Thu Feb 7 07:17:06 1991 @@ -359,9 +359,9 @@ extern char * clnt_spcreateerror (char *s); extern void clnt_pcreateerror (char *s); extern CLIENT * clntraw_create (u_long prog, u_long vers); -extern int callrpc (char *host, int prognum, int versnum, - xdrproc_t in procnum, char *inproc, int in, - xdrproc_t outproc, char *out); +extern int callrpc (char *host, u_long prognum, u_long versnum, + u_long procnum, char *in, xdrproc_t inproc, + char *out, xdrproc_t outproc); extern void clnt_tcpInit (void); extern CLIENT * clnttcp_create (struct sockaddr_in *raddr, u_long prog, u_long vers, int *sockp, u_int sendsz, --- svc.h.orig Fri Nov 9 00:21:44 1990 +++ svc.h Thu Feb 7 07:17:05 1991 @@ -296,11 +296,13 @@ extern void svc_getreqset (fd_set *rdfds); extern void svc_run (void); extern SVCXPRT * svcraw_create (void); -extern int registerrpc (int prognum, int versnum, xdrproc_t in procn um, int progname, int inproc, xdrproc_t outproc); +extern int registerrpc (u_long prognum, u_long versnum, + u_long procnum, char *progname, + xdrproc_t inproc, xdrproc_t outproc); extern SVCXPRT * svctcp_create (int sock, u_int sendsize, u_int recvsize); extern SVCXPRT * svcfd_create (int fd, u_int sendsize, u_int recvsize); extern SVCXPRT * svcudp_bufcreate (int sock, u_int sendsz, u_int recvsz); -extern SVCXPRT * svcudp_create (int sock, int sendsz, int recvsz); +extern SVCXPRT * svcudp_create (int sock); extern int svcudp_enablecache (SVCXPRT *transp, u_long size); #else --- xdr.h.orig Fri Nov 9 00:21:45 1990 +++ xdr.h Tue Jun 18 11:14:20 1991 @@ -275,7 +275,7 @@ extern bool_t xdr_short (XDR *xdrs, short *sp); extern bool_t xdr_u_short (XDR *xdrs, u_short *usp); extern bool_t xdr_char (XDR *xdrs, char *cp); -extern bool_t xdr_u_char (XDR *xdrs, char *cp); +extern bool_t xdr_u_char (XDR *xdrs, u_char *cp); extern bool_t xdr_bool (XDR *xdrs, bool_t *bp); extern bool_t xdr_enum (XDR *xdrs, enum_t *ep); extern bool_t xdr_opaque (XDR *xdrs, caddr_t cp, u_int cnt); Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. From blair@titan.boeing.com Thu Oct 10 12:51:00 1991 From: blair@titan.boeing.com (Rick Blair) Date: Thu Oct 10 12:51:09 PDT 1991 Subject: Re: DDCMP ;;;Submitted-by dcarr%donut.gandalf.ca@Csa2.LBL.Gov Thu Oct 10 10:19:12 1991 ;;;Submitted-by: dcarr%donut.gandalf.ca@Csa2.LBL.Gov (Dave Carr) ;;;If you manage to get a driver, could you pass it on to me too. ;;;Thanks. ;;;-- ;;;Dave Carr | dcarr@gandalf.ca | If you don't know where ;;;Principal Designer | TEL (613) 723-6500 | you are going, you will ;;;Gandalf Data Limited | FAX (613) 226-1717 | never get there. DITTO Rick Blair blair@boeing.com From omni!hwajin@apple.com Thu Oct 10 14:46:35 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Thu Oct 10 14:46:49 PDT 1991 Subject: Re: RPC service on vxWorks There's a version of rpcgen that knows how to generate VxWorks compatible output. Unfortunately I have since left WRS and WRS isn't distributing that code yet. You might be able to talk them into giving you a copy. Or just do it yourself. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From omni!hwajin@apple.com Thu Oct 10 17:51:34 1991 From: hwajin@omni.com Date: Thu Oct 10 17:51:43 PDT 1991 Subject: Re: NFS garbage collecting (last 2 messages got garbled) >> The fd associated with the filename gets removed by the fclose(), but >> the socket fd remains! >The socket option `SO_LINGER' determines whether a TCP socket lingers >after it is closed when undelivered data is present. Since NFS uses UDP, SO_LINGER doesn't apply here. To solve the problem, set the global BOOL variable "nfsAutoClose" to TRUE (i.e. 1) before closing the file. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From sharpster@hns.com Fri Oct 11 06:47:25 1991 From: sharpster@hns.com (Steve Harpster) Date: Fri Oct 11 06:47:39 PDT 1991 Subject: sscanf() return value In version 5.0 (beta), I see the following (simplified) call to sscanf() return different values at different times: string = "1.2"; retval = sscanf(string, "%1d", &value); Sometimes retval is 1, but sometimes it's 0. Is this a well known bug? I can easily code around it, but I thought you people would like to be aware of it. (BTW, yes I know there are better ways to code. The above is just an example.) -- From rml@mpl.ucsd.edu Fri Oct 11 10:28:39 1991 From: rml@mpl.ucsd.edu (Bob Lawhead) Date: Fri Oct 11 10:28:51 PDT 1991 Subject: subscription request Please add me (rlawhead.ucsd.edu) to your distribution list. Thanks. From blair@titan.boeing.com Fri Oct 11 14:53:58 1991 From: blair@titan.boeing.com (Rick Blair) Date: Fri Oct 11 14:54:07 PDT 1991 Subject: DDCMP In a paper titled "An Object-Oriented Environment for Robot Architectures" by David J. Miller and R. Charleene Lennox that was in thee 1990 IEEE conference on Robotics and Automation the authors made reference to a DDCMP driver for VxWorks!! The authors are from the Sandia National Laboratories so maybe of of the VXUG members there could help us out. Thank In advance ------- Rick Blair blair%titan@boeing.com (206)865-3056 From leonid@amil.co.il Sun Oct 13 07:04:02 1991 From: leonid@amil.co.il (Leonid Rosenboim) Date: Sun Oct 13 07:04:12 PDT 1991 Subject: SECS 1 & 2 Have anybody written an implementation of SECS 1 protocol under VxWorks ? I am supposed to start writing one very soon now, and if there's anybody with whom I can share code and experience, please drop me a line. For the rest of you, SECS is a protocol over async RS232 that interconnects various semiconductor manufacturing equipment types. The spec is controlled by SEMATEC. The fiurst leve, SECS-1 is a simple framing data-link protocol, and the SECS-2 is the application layer equipped with data respresentation and session functionality. --------------------------------------------------------------------- | Leonid Rosenboim Internet: leonid@amil.co.il | | System Administrator Fax: +972-3498-078 | | Applied Materials (Israel) LTD. Phone: +972-3498-201 | --------------------------------------------------------------------- From ast0!caf@ub.com Mon Oct 14 15:14:05 1991 From: ast0!caf@ub.com (Cory Fasbender) Date: Mon Oct 14 15:14:15 PDT 1991 Subject: mv167 and VME I have a 8M MV167 card with vxWorks 5.02(beta-1). I am tring to access an address(0x810000) accross a 24 bit VME. With the 167 and vxWorks I get a bus error, but with the 167 and te 167Bug proms or a 147 with vxWorks I have no bus error. I was just wondering if anyone else has seen this problem, or if anyone has any hints on where to start looking. Cory (caf!ast0@ub.com) #define BOARD_ID (char *)0x810000 foobar () { logMsg ("board id is :%x\n", *BOARD_ID); } For 147:vxWorks board id is :XXXX For 167:167Bug No problems. For 167:vxWorks Bus Error Program Counter: 0x007feec2 Status Register: 0x3004 Access Address : 0x00810000 Special Status : 0x0125 -- -------------------------------------------------------------------------- Cory Fasbender UUCP : ...!{ames | pacbell}!ub-gate!ast0!caf (408) 522-3344 USENET: ast0!caf@ub.com Applied Signal Technology Advanced Communications Sunnyvale, CA Fax (408) 730-8537 -------------------------------------------------------------------------- From gordon@tpocc.gsfc.nasa.gov Tue Oct 15 05:07:36 1991 From: gordon@tpocc.gsfc.nasa.gov (Gordon Miller) Date: Tue Oct 15 05:07:46 PDT 1991 Subject: Re: mv167 and VME Date: Mon, 14 Oct 91 15:14:19 PDT Message-Id: <9110142214.AA02984@vxw.ee.lbl.gov> Subject: mv167 and VME Submitted-by ast0!caf@ub.com Mon Oct 14 15:14:05 1991 Submitted-by: ast0!caf@ub.com (Cory Fasbender) I have a 8M MV167 card with vxWorks 5.02(beta-1). I am tring to access an address(0x810000) accross a 24 bit VME. With the 167 and vxWorks I get a bus error, but with the 167 and te 167Bug proms or a 147 with vxWorks I have no bus error. I was just wondering if anyone else has seen this problem, or if anyone has any hints on where to start looking. --- End included message --- You should look at the configuration of your MV167's SLAVE BASE ADDRESS REGISTER. I know from experience on a MV147, that the value used by the Moto 147Bug (and modified by the command "OBA") is frequently different from the value set in sysLib.c of the vxWorks distribution. For the MV147 the preprocessor variable for this address is "SLAVE_BASE_CTL" and the address is 0xFFFE102B (for the MV147, your system may be different). This register controls the address that onboard memory is visable across the VME bus. gordon Gordon Miller Integral Systems, Inc. 1100 West Street CSC/LR Lanham, MD 20707 (301) 497-2416 From biocca@bevsun.bev.lbl.gov Tue Oct 15 07:58:10 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Tue Oct 15 07:58:17 PDT 1991 Subject: Subject: Re: mv167 and VME Carl: This one didn't make it through the exploder because the exploder thought it was a bounce (it had the exploder's trailer on it). Please edit off the trailers in included text. Thanks, --Alan K Biocca ----- Begin Included Message ----- From: wrs!yuba!carl@uunet.uu.net (Carl Chesbrough) Subject: Re: mv167 and VME Status: R Cory, The MV167 has the A24 address space at an address starting with 0xf0xxxxxx. So you need to have: #define BOARD_ID (char *)0xf0810000 in order to have the '167 to put the A24 address modifier on the bus. Carl C. Chesbrough Wind River Systems. > >I have a 8M MV167 card with vxWorks 5.02(beta-1). I am tring to access an >address(0x810000) accross a 24 bit VME. With the 167 and vxWorks I get a bus >error, but with the 167 and te 167Bug proms or a 147 with vxWorks I have no >bus error. I was just wondering if anyone else has seen this problem, or if >anyone has any hints on where to start looking. > > Cory (caf!ast0@ub.com) > >#define BOARD_ID (char *)0x810000 >foobar () >{ > logMsg ("board id is :%x\n", *BOARD_ID); >} > >For 147:vxWorks >board id is :XXXX > >For 167:167Bug >No problems. > >For 167:vxWorks >Bus Error >Program Counter: 0x007feec2 >Status Register: 0x3004 >Access Address : 0x00810000 >Special Status : 0x0125 > >-- > >-------------------------------------------------------------------------- >Cory Fasbender UUCP : ...!{ames | pacbell}!ub-gate!ast0!caf >(408) 522-3344 USENET: ast0!caf@ub.com >Applied Signal Technology Advanced Communications >Sunnyvale, CA Fax (408) 730-8537 ----- End Included Message ----- From wrs!yuba!carl@uunet.uu.net Tue Oct 15 09:32:22 1991 From: wrs!yuba!carl@uunet.uu.net (Carl Chesbrough) Date: Tue Oct 15 09:32:32 PDT 1991 Subject: Re: mv167 and VME > I have a 8M MV167 card with vxWorks 5.02(beta-1). I am tring to access an > address(0x810000) accross a 24 bit VME. With the 167 and vxWorks I get a bus > error, but with the 167 and te 167Bug proms or a 147 with vxWorks I have no > bus error. I was just wondering if anyone else has seen this problem, or if > anyone has any hints on where to start looking. > >--- End included message --- >You should look at the configuration of your MV167's SLAVE BASE ADDRESS >REGISTER. I know from experience on a MV147, that the value used by the >Moto 147Bug (and modified by the command "OBA") is frequently different >from the value set in sysLib.c of the vxWorks distribution. For the MV147 >the preprocessor variable for this address is "SLAVE_BASE_CTL" and the >address is 0xFFFE102B (for the MV147, your system may be different). > >This register controls the address that onboard memory is visable >across the VME bus. The MV167 board has the A24 space at address 0xf0xxxxxx. So to access address 0x810000 from the monitor you must do the following: -> m 0xf0810000 This would give you access to 0x810000 with A24 modifiers. The problem is that existing code which has the address 0x810000 without the leading 0xf0 will not run. The addresses will have to be changed to include the leading 0xf0 (0xf0810000). However, if the code was written to convert a local address to a VMEbus address the code would have run without any problem. This is done with the sysBusToLocalAdrs() routine as follows: char *busAddressStd; sysBusToLocalAdrs (VME_AM_STD_SUP_DATA, (char *) 0x810000, &busAddressStd); This will return a status, and if OK then busAddressStd will contain the address to use to access 0x810000 in A24 supervisor data area. You could convert the address once at the beginning of your code. This way your code will run on any vxWorks system without having to worry about where the A24 space is located. This should also be done for any SHORT_IO boards in your system, as the SHORT_IO address varies from board to board. Thanks, Carl C. Chesbrough Wind River Systems From marc@sun-valley.stanford.edu Tue Oct 15 10:49:58 1991 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Tue Oct 15 10:50:06 PDT 1991 Subject: Re: mv167 and VME > >The MV167 board has the A24 space at address 0xf0xxxxxx. So to access >address 0x810000 from the monitor you must do the following: > >-> m 0xf0810000 > >This would give you access to 0x810000 with A24 modifiers. > >The problem is that existing code which has the address 0x810000 without >the leading 0xf0 will not run. The addresses will have to be changed >to include the leading 0xf0 (0xf0810000). The 147 has a very elegant solution to this problem (which I have been begging WRS to document in config/mv147/sysLib.c for over three years). Here is a tiny code fragment we have added: /* Modified to support 16 bit VME bus (no P2 backplane) (See Pg. 3-41) */ #ifdef P2_BACKPLANE *LCSR_MASTER_CONF = 0; /* simple A32 D32 master */ #else *LCSR_MASTER_CONF = 3; /* simple A24 D16 master */ #endif I would be shocked if Motorola removed this very useful feature from the 167 but since I do not yet have one, I can not verify its presence or absence. Could someone who has one check for this functionality? It sure as heck beats modifying all your code. Note: Of course this assumes that all of your VME devices are connected via an 16/24 bit bus (ie. a P1 only bus). If this is not the case, ie, you have a mixture of 16/24 and 32/32 bit boards in a P1/P2 system then you will have to resort to the address modification scheme described above to address the 16 bit boards. --Marc Ullman Stanford University From djc@oxygen.aps1.anl.gov Tue Oct 15 11:10:50 1991 From: djc@oxygen.aps1.anl.gov (Daniel J. Ciarlette) Date: Tue Oct 15 11:11:00 PDT 1991 Subject: vxWorks, VME, VXI, & MXI together We are looking into using MXI in our VME - VXI bus based systems. Has anyone worked with using MXI to interconnect multiple VME crates in a vxWorks environment. MXI allows you to tie multiple computer buses together to form one big bus. I have a few questions about MXI: 1. What types of hassles have you encountered with MXI. 2. Are there any incompatibilities or nuances that you have encountered? 3. What types of buses have you connected together. 4. Did you have to write your own MXI resource manager? By the looks of it National Instruments doesn't have MXI resource manager capability on their VME-MXI board (page 3-4 in their VME-MXI manual). 5. Would you recommend MXI or not? If not what would you recommend I'll summarize the responses into one informational message in about a week. Thanks, Dan Ciarlette Advanced Photon Source e-mail: djc@tardis.aps1.anl.gov Diagnostics Group Phone: (708) 972-4015 Argonne National Laboratory 9700 South Cass Avenue Argonne, IL 60439 From OWENS@lodtm.llnl.gov Tue Oct 15 11:31:24 1991 From: OWENS@lodtm.llnl.gov Date: Tue Oct 15 11:31:36 PDT 1991 Subject: Motorola 167 I have one of the 167 boards and the support chips are very different between the 147 and 167, the 167 uses the VME64 and PCC2, the 147 the VME and PCC chips. People who are anticipating acquiring a 167 board should know that, in spite of a statement in the flyer that an order "includes documentation", the only documentation included with the board is a very brief 'installation guide. A note is included listing the order numbers for a documentation set. I contacted the Motorola sales rep and he said that he would forward a documentation set to me, I assume at no charge. Every manufacturer of single board computers that I have dealt with has always included thorough documentation with its products, including Motorola (until now)> I hope this does not become a company policy. Doug Owens From chinacat!nominil!linimon@cs.utexas.edu Tue Oct 15 19:51:33 1991 From: linimon@nominil.lonestar.org (Mark Linimon) Date: Tue Oct 15 19:51:42 PDT 1991 Subject: Re: including support manuals with boards (was Re: Motorola 167) Doug Owens writes: > Every manufacturer of single board computers that I have dealt with has > always included thorough documentation with its products, including Motorola > (until now). I hope this does not become a company policy. The answer may be "it depends." When I was at Mizar I seem to recall that we recognized that, for certain OEM customers (who would incorporate the board into a packaged product), that manuals need not be shipped. However, the default was always to ship them for small-quantity orders, or for any customer that had not explicitly requested not to get the manuals. Perhaps Motorola just got their wires crossed on this one. From hebo@mbari.org Wed Oct 16 09:19:36 1991 From: hebo@mbari.org (Bob Herlien) Date: Wed Oct 16 09:19:44 PDT 1991 Subject: NTP on archive is broken Having just returned from a two week business/vacation trip, I filtered through the exploder messages and noticed that, in the archive summary that Richard Neitzel sent, ntp.vx.tar.Z is too small! So I ftp'd it from the archive and, indeed, part of it is missing. If you've taken ntp.vx.tar.Z from the archive, and haven't been able to figure out how to make it run, it's because an entire subdirectory and a README file are missing from it. I sent email to Richard on Monday, but haven't gotten a reply yet. In the meantime, if anyone wants a correct version of NTP for vxWorks, send me email. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From blair@titan.boeing.com Thu Oct 17 09:34:31 1991 From: blair@titan.boeing.com (Rick Blair) Date: Thu Oct 17 09:34:41 PDT 1991 Subject: DDCMP I dont know if this made it out. If you recieved two of these, sorry. In a paper titled "An Object-Oriented Environment for Robot Architectures" by David J. Miller and R. Charleene Lennox that was in the 1990 IEEE conference on Robotics and Automation the authors made reference to a DDCMP driver for VxWorks!! The authors are from the Sandia National Laboratories so maybe of of the VXUG members there could help us out. Thank In advance ------- Rick Blair blair%titan@boeing.com (206)865-3056 From sharpster@hns.com Thu Oct 17 09:59:29 1991 From: sharpster@hns.com (Steve Harpster) Date: Thu Oct 17 09:59:39 PDT 1991 Subject: sscanf() bug Consider the follow routine: ------------------------------------------------------ #include #define TRYS 1000000 scantest() { unsigned long int tests = TRYS, errs = 0; int retval, val; char *string = "1"; printf("Total tests: %ld\n", tests); while (--tests > 0) { if ((retval = sscanf(string, "%1d", &val)) != 1) { errs++; } if (tests % 1000 == 0) { printf("%ld tests remaining\n", tests); printf("%ld errors so far\n", errs); } } printf("%ld errors in %ld attempts (%f%% success)\n", errs, TRYS, 100.0 - (errs * 100.0 / (double) TRYS)); } ------------------------------------------------------ Running this under VxWorks 5.0 beta on an i960, I get 23 errors in 1000000 attempts (99.997700% success) Very odd. You would think that if sscanf() were returning garbage, the error rate would be much higher. However, something is clearly wrong. The smallest number I've seen is 15 in a 1M; 23 is the largest. Does this bug still exist in newer versions of VxWorks? -- Stephen Harpster Hughes Network System, Inc. sharpster@hns.com From hebo@mbari.org Thu Oct 17 10:37:12 1991 From: hebo@mbari.org (Bob Herlien) Date: Thu Oct 17 10:37:20 PDT 1991 Subject: Re: sscanf() bug Steve, Just ran your scantest twice on VxWorks 5.0 (released version) on an SBE VPU-30 (a 25 MHz 68030). No errors. Speculation: this was either a beta (and pre-5.0?) bug, or it's a bug in the i960 port. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From muts@fysap.fys.ruu.nl Thu Oct 17 10:59:40 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Thu Oct 17 10:59:52 PDT 1991 Subject: Did anyone make deadman implementation for 'eurocom 6'? We use eurocom 6 cards with vxworks 5.0. I'd like to use the taskmon/deadman package by 'wbrown' (that's all I know). The package only contains deadman, which is HW dependent, of MVME143 and 147. Did anyone accidentally make an implementation for Eurocom 6? _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From stan@rti.com Thu Oct 17 12:49:43 1991 From: stan@rti.com (Stan Schneider) Date: Thu Oct 17 12:49:56 PDT 1991 Subject: Re: sscanf on i960 >> 23 errors in 1000000 attempts (99.997700% success) This sounds like a re-entrancy (or lack thereof) problem. What else is running while you did your test? Did you set the VX_STDIO bit in all tasks (I'm not sure it's needed for sscanf, but...)? I couldn't recreate the problem on a 68k machine either (even with several copies running simultaneously), so I agree with Bob's analysis (a bug in the i960 port). -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From jvdwerf@mmra1.ms.philips.nl Fri Oct 18 01:09:52 1991 From: jvdwerf@mmra1.ms.philips.nl Date: Fri Oct 18 01:10:10 PDT 1991 Subject: RE: sscanf() bug Stephen, I ran your scantest() on our Heurikon HK80/V960E board (i960) under VxWorks 5.0.3 beta. I tried my best to make it return more than 0 errors, but it wouldn't. +-----------------------------------------------------------------------------+ | | Johan van der Werf | | | | Philips Medical Systems | tel: +31-40-763407 | | //Only | MR-TSSW QR-1134 | fax: +31-40-763459 | | \X/Amiga | Postbus 10.000 | | | | 5680 DA Best | email: jvdwerf@mmra1.ms.philips.nl | | | The Netherlands | | +-----------------------------------------------------------------------------+ From pdw@pat.mc.duke.edu Fri Oct 18 06:32:39 1991 From: pdw@pat.mc.duke.edu (Patrick D. Wolf) Date: Fri Oct 18 06:32:50 PDT 1991 Subject: slip-slip I know this is unsolicited but I received several inquires at the users group meeting and thought it would be of enough general interest to send out. .PP This note describes the procedures we used to boot and operate a vxWorks target CPU over SLIP net through a second vxWorks target CPU attached to an ethernet network. In our configuration, the front end of a data acquisition system is the SLIP target system connected to the outiside world using only a serial line. This CPU is a Matrix MX220 named "mapfe.sl". The other end of the serial line is connected to a second vxWorks target called "map". This CPU is a Heurikon HKV30XE which has an ethernet interface to our laboratory Sun network using a host called "pat". The HKV30 target acts as a gateway to a backplane as well as a gateway to the SLIP line. Both of the target CPU's are running 5.01 with the SLIP patch taken from the vxWorks BBS. The patch consists of a new configAll.h, a new bootConfig.h and a new usrConfig.c. The only change to the patch that we needed to make was to set: SL_TY_DEV "/tyCo/1" instead of "/tyCo/0" as it appeared in the new configAll.h. .PP The following hosts were configured on the sun network: .nf pat- the vxWorks sun host-diskless. sunbar- sun system with a disk. map- the vxWorks CPU 0 as seen from the sun network. map.bp- the vxWorks CPU 0 as seen from the backplane. map.sl- the vxWorks CPU 0 as seen from the slip interface. mapfe.sl - the remote vxWorks target. map2 - vxWorks target on the backplane net (CPU 1). .PP On the target CPU "map", vxWorks was rebuilt after making appropriate changes in the patched configAll.h file. If you have made extensive changes to this file its easier to add the few lines in the patched version to your current version than to try and change the patched version to include your changes. The same goes for bootConfig and usrConfig. The boot parameters on "map" were unchanged from a normal backplane 0 CPU. The slip interface had to be initialized, after doing the appropriate hostAdds: .sp 1 slipInit (0,"/tyCo/1","map.sl","mapfe.sl",0) .sp 1 for those interested, the first argument is the slip unit number, this is used, I think, when there is more than one slip interface, and the final argument is the baud rate. If this argument is 0 the rate is not changed and the default is 9600. .PP Next, the patch was added to the "mapfe.sl" target files, both vxWorks and bootrom.hex were rebuilt and new boot ROMS were created. The boot parameters for "mapfe.sl" were: (instead of inet addresses I put [name], because I think its more easily understood, not because its some hidden feature) .sp 1 .nf boot device: sl processor number: 0 host name: pat filename: /VXC/mx220/vxWorks inet on ethernet: [mapfe.sl] inet on bp: host inet: [pat] gateway inet: [map.sl] targetname: mapfe.sl .PP A route to "mapfe.sl" through "map" was added to the sun network. Once the system was booted, it was possible to rlogin to "mapfe.sl" from the host "pat", or from the target "map". We could use the netDriver to ld or copy files from "pat:", we could rlogin from "mapfe.sl" to "pat" or "map", we could open a socket between "mapfe.sl" and "pat". Another use we made of the SLIP interface was to nfsMount a disk for use on "mapfe.sl" . The disk node was called "sunbar". A route was added to "mapfe.sl" thru "map" on "sunbar", "mapfe.sl" was added to the access list on "sunbar", "sunbar" was added as a host on "mapfe.sl" and the file system on "sunbar" could then be nfsMounted. .PP Another communication link was made between "mapfe.sl" and "map2" a target on the backplane network. All that was needed to estiblish this path was: routeAdd ("mapfe.sl", "map.bp") on "map2" so that it would know how to get packets to "mapfe.sl". .PP The interface is fairly robust, somtimes time delays during rlogin to the front end are a little long but all in all the interface is transparent, useful and (best of all) inexpensive. .sp 1 .nf Patrick Wolf Duke University Medical Center Durham, NC 27707 pdw@sunbar.mc.duke.edu (919)-660-5114 From DIXON@crdgw2.crd.ge.com Fri Oct 18 07:27:31 1991 From: DIXON@crdgw2.crd.ge.com (DIXON WALTER V) Date: Fri Oct 18 07:27:42 PDT 1991 Subject: problem loading symbol table  Date: 18-OCT-1991 10:26 From: walt dixon (dixon@crd.ge.com) Sender: DIXON Subject: problem loading symbol table To: vxwexplo%lbl.gov@smtp@tcpgateway -------- Whe have been having intermittent problems booting vxWorks. I've talked to WRS Tech Support and they are clueless. I was wondering if any one else has seen this problem: auto-booting... boot device : ln host name : ra file name : /usr/athena2/vw/5.0.2/config/mv147/vxWorks inet on ethernet (e) : 3.1.7.102:fffffc00 inet on backplane (b) : 3.1.116.1:fffffc00 host inet (h) : 3.1.5.236 user (u) : username ftp password : password here processor number : 0 Attaching network interface ln0... done. Loadding... 249856 + 60376 + 21548 Starting at 0x1000... Attaching network interfac ln0 done. Initializing backplane net with anchor at 0x18000000... done. Attaching backplane interface bp0 at 0x18000000... done. Attaching network interface lo0... done. Loading symbol table from ra:/usr/athena2/vw/5.0.2/config/mv147/vxWorks.sym ... Error opening ra:/usr/athena2/vw/5.0.2/config/mv147/vxWorks.sym: status = 0x1a9 If I reboot the system after getting this error, it boots cleanly. I see this problem maybe 10% of the times I boot. System configuration: 1 mvme147 system controller 2 mvme135 3 mvme135 4 mvme165 5 mvme165 nvram 2.0MB I'd really like to track this one down. Any suggestions? Thanks in advance Walt Dixon {internet: dixon@crd.ge.com } {us mail: ge crd } { po box 8 } { schenectady, ny 12301 } {phone: 518-387-5798 } -------- From georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov Fri Oct 18 08:32:22 1991 From: georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov (Georg Feil) Date: Fri Oct 18 08:32:36 PDT 1991 Subject: Re: problem loading symbol table Sorry, this is totally off topic, but you mentioned > nvram 2.0MB We use non-volatile RAM in our application as well, specifically 2 and 3 MB versions of the Matrix MD-RAM battery-backed-up static RAM card. Makes a dandy hard-disk substitute. I'm interested in what you use for your nvram, and whether you've had any problems with it. Thanks in advance, Georg. From georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov Fri Oct 18 09:17:22 1991 From: georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov (Georg Feil) Date: Fri Oct 18 09:17:33 PDT 1991 Subject: Re: problem loading symbol table Sorry about broadcasting that last message about nvram, it was meant to go only to Walt Dixon (dixon@crd.ge.com). I'm not used to having my 'r' key act that way. Georg. From bean@pslnm.NMSU.Edu Fri Oct 18 09:48:59 1991 From: bean@pslnm.nmsu.edu Date: Fri Oct 18 09:49:08 PDT 1991 Subject: Sun Sparcstation to Sun 2(3) C cross compilers Hi, I'm using VADSworks 2.0.1, an Ada cross development system, (Sun 4 IPC => mvme147 68030) that uses vxWorks 5.0 as the target os. Included in the vxWorks distribution are some unsupported directories that include some minimal files for putting vxWorks on an mvme333 serial card. This might be very useful as the final system has a mvme333 card in it. However, after I generated the makefile it tries to use a Sun 2 (68010) cross compiler that used to be part of Sun 4 os but has since been deleted. I use a Sun 3 (68030) to recompile vxWorks for the mvme147, but I don't have access to a Sun 2 to try the same trick for the mvme333. What I want to know is: 1) Can I use the Sun 3 or will there be too many incompatable operations ('10 vs '30)? or even better, 2) Does anyone know if the cross compilers are available somewhere? Ftp'able? Sun? Gcc? I haven't been able to get any help from Sun, (they will call me back Real Soon Now). or, 3) Has anyone set up vxWorks on a mvme333? Does it work well? Fair? Not worth the effort? Any help at all will be greatly appreciated, e-mail to me or vxwexplo if you think there is enough interest. Thanks, Merrill Bean Physical Science Lab. New Mexico State University PSL/NMSU PO Box 300002 Las Cruces NM 88003-0002 ph (505) 522-9446 fax (505) 522-9389 e-mail bean@psl.nmsu.edu or bean@bongo.nmsu.edu IP psl (128.123.15.4), bongo (128.123.15.14) From mcevoy@bevsun.bev.lbl.gov Fri Oct 18 10:15:12 1991 From: mcevoy@bevsun.bev.lbl.gov (Maurice McEvoy) Date: Fri Oct 18 10:15:20 PDT 1991 Subject: New "Daily Digest" Mailings Current Subscribers: The vxWorks exploder now offers a new "Daily Digest" subscription list in addition to the traditional "ASAP" subscription list. Some vxWorks exploder users requested less frequent mailings. We are now collecting articles and mailing the collection once each day. The new "Daily Digest" mailings now occur at 4AM Pacific Time. If you would like to subscribe to the new "Daily Digest", send requests to vxwexplo-request@lbl.gov. -- Maury McEvoy From Ninane%fynu.ucl.ac.be@Csa3.LBL.Gov Fri Oct 18 10:21:47 1991 From: Ninane%fynu.ucl.ac.be@Csa3.LBL.Gov Date: Fri Oct 18 10:21:59 PDT 1991 Subject: Problems with SCSI devices on vxWorks 5.0.1 Folks, I have been using for months vxWorks 5.0.0 on an MVME147 board with autoconfiguration of two SCSI devices: - 150 MB Disk CDC; - Tape archive VIPER 150. The devices where autoconfigured in usrConfig.c by defining SCSI_AUTO_CONFIG together with INCLUDE_SCSI/DMA in my target config.h file. Unfortunately, two weeks ago, I switched to vxWorks 5.0.1 ! The problem is that with this release, the SCSI autoconfiguration blocks. I got no messages but: Auto-Configuring SCSI bus... What has changed between 5.0.0 and 5.0.1 ? Is there a fix for this. Sincerely, ------------------- Dr. Alain H. Ninane, University of Louvain, Nuclear Physics Dept. Ch. du Cyclotron, 2 - B-1348 Louvain-la-Neuve, BELGIUM Tel: +32-10-47.32.73, Fax: +32-10-45.21.83, Internet: Ninane@fynu.ucl.ac.be From scotth@rocco.labs.tek.com Fri Oct 18 11:39:28 1991 From: scotth@rocco.labs.tek.com Date: Fri Oct 18 11:39:55 PDT 1991 Subject: Re: Sun Sparcstation to Sun 2(3) C cross compilers > has a mvme333 card in it. However, after I generated > the makefile it tries to use a Sun 2 (68010) cross > compiler that used to be part of Sun 4 os but has since > been deleted. I use a Sun 3 (68030) to recompile vxWorks > for the mvme147, but I don't have access to a Sun 2 to > try the same trick for the mvme333. > What I want to know is: > 1) Can I use the Sun 3 or will there be too many > incompatable operations ('10 vs '30)? > or even better, > 2) Does anyone know if the cross compilers are available > somewhere? Ftp'able? Sun? Gcc? I haven't been > able to get> any help from Sun, (they will call me > back Real Soon Now). WRS is now distributing gcc and related GNU tools, now, for Sun4x68k cross development to VxWorks platforms. If you don't have a direct relationship with WRS, then I would hope Verdix would help you get the gcc distribution if it doesn't just come with your v5.0.x distribution (note that I'm not a Verdix customer and don't speak for them). There are a bunch of code generation options to use depending on your target. Use -m68000 for 68000s, 68010s, and 68302s. Use -m68020 (the default, I think) for 68020s, 68030s, and CPU32-based uPs. scotth@crl.labs.tek.com Scott Herzinger Computer Research Lab, Tektronix, Inc. PO Box 500 MS 50-662, Beaverton, OR 97077 From susanna@tomato.lbl.gov Fri Oct 18 11:44:44 1991 From: susanna@tomato.lbl.gov (Susanna Jacobson) Date: Fri Oct 18 11:44:57 PDT 1991 Subject: Re: problem loading symbol table Walt Dixon writes: >Whe have been having intermittent problems booting vxWorks. I've talked >to WRS Tech Support and they are clueless. I was wondering if any one >else has seen this problem: > >auto-booting... > > >boot device : ln >host name : ra >file name : /usr/athena2/vw/5.0.2/config/mv147/vxWorks >inet on ethernet (e) : 3.1.7.102:fffffc00 >inet on backplane (b) : 3.1.116.1:fffffc00 >host inet (h) : 3.1.5.236 >user (u) : username >ftp password : password here >processor number : 0 > >Attaching network interface ln0... done. >Loadding... 249856 + 60376 + 21548 >Starting at 0x1000... > >Attaching network interfac ln0 done. >Initializing backplane net with anchor at 0x18000000... done. >Attaching backplane interface bp0 at 0x18000000... done. >Attaching network interface lo0... done. >Loading symbol table from ra:/usr/athena2/vw/5.0.2/config/mv147/vxWorks.sym ... >Error opening ra:/usr/athena2/vw/5.0.2/config/mv147/vxWorks.sym: status = 0x1a9 > >If I reboot the system after getting this error, it boots cleanly. I see >this problem maybe 10% of the times I boot. > > ... I suggest you talk to Motorola and see if your MVME147 has a defective Ethernet interface. We had a similar problem with one of our 147's, which would sometimes hang during the boot process, while either loading the kernel or loading the symbol table. An additional symptom was that after some (unpredictable number of) hours on line, the 147 would stop Ethernet communication while otherwise continuing to function. We learned from Motorola that one revision of the 147's Ethernet interface can be flaky. (My recall is hazy on the details now -- something about the PROM I think.) In our case the solution was that Motorola sent us a replacement board after we shipped the defective one back. ======================================================================== Susanna Jacobson MS 46A-1123 Lawrence Berkeley Laboratory SRJacobson@LBL.Gov 1 Cyclotron Road (510) 486-7801 Berkeley, CA 94720 ======================================================================== From bgeer@beorn.sim.es.com Fri Oct 18 12:41:20 1991 From: bgeer@beorn.sim.es.com (bob geer) Date: Fri Oct 18 12:41:33 PDT 1991 Subject: Re: Problems with SCSI devices on vxWorks 5.0.1 >Folks, >I have been using for months vxWorks 5.0.0 on an MVME147 board >... >Unfortunately, two weeks ago, I switched to vxWorks 5.0.1 ! There is a patch that corrects version 5.0.1's scsi code. We have received 5.0.2, but haven't actually used it yet. You may want to obtain this version & skip 5.0.1. From susanna@tomato.lbl.gov Fri Oct 18 13:14:27 1991 From: susanna@tomato.lbl.gov (Susanna Jacobson) Date: Fri Oct 18 13:14:35 PDT 1991 Subject: Re: Problems with SCSI devices on vxWorks 5.0.1 >>Folks, >>I have been using for months vxWorks 5.0.0 on an MVME147 board >>... >>Unfortunately, two weeks ago, I switched to vxWorks 5.0.1 ! > >There is a patch that corrects version 5.0.1's scsi code. We have >received 5.0.2, but haven't actually used it yet. You may want to >obtain this version & skip 5.0.1. > Here is a quick patch (in VxWorks shell script form) that worked for us until we got the SCSI patch tape from WRS: # apply patch to system controller init routine. m wd33c93CtrlInit + 0x22c 0x67f6 . m wd33c93CtrlInit + 0x2c2 0x67f6 . ======================================================================== Susanna Jacobson MS 46A-1123 Lawrence Berkeley Laboratory SRJacobson@LBL.Gov 1 Cyclotron Road (510) 486-7801 Berkeley, CA 94720 ======================================================================== From erik!dan@uunet.uu.net Tue Oct 22 15:47:43 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Oct 22 15:47:54 PDT 1991 Need advice for implementing a new member of the IP protocol suite which would be similar to RARP, in this case maybe it should be called, "IMLOST". The scenario is this: Client(vxWorks target) boots up and does'nt know its IP address nor its bootline data. Therefor it creates an IMLOST packet (similar to RARP ) and broadcasts it on the network. (Packet has its Ethernet address in it) Server(big bad Sun) receives IMLOST packet on a "well know socket" and checks to see if the Ethernet address is in its local table: if ( Ethernet address in local table) { server responds with BOOTLINE and any other data necessary } else { server DOES NOTHING, it assumes some other server will respond } Now, back at the ranch (client side): if ( client receives reply) { client boots up, spawns 2.5 tasks and lives happily ever after} else { client sends message periodically until it receives a reply} The particular application for this type of service is a X-Ray Flourescence analyzer, which may be connected to its host on a network with other analyzers, and has no local serial port. NOTE: Instrument users like to belive that they are operating an instrument and not a computer, i.e. why use a serial port just to get the darn thing working. Other uses include the removal of a need for NVRAM for storing a BOOTLINE. Dan Downing Kevex Instruments 415-591-3600 ext 442 (ddowning@kevex.com). From erik!dan@uunet.uu.net Tue Oct 22 15:48:02 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Oct 22 15:48:16 PDT 1991 Need advice for implementing a new member of the IP protocol suite which would be similar to RARP, in this case maybe it should be called, "IMLOST". The scenario is this: Client(vxWorks target) boots up and does'nt know its IP address nor its bootline data. Therefor it creates an IMLOST packet (similar to RARP ) and broadcasts it on the network. (Packet has its Ethernet address in it) Server(big bad Sun) receives IMLOST packet on a "well know socket" and checks to see if the Ethernet address is in its local table: if ( Ethernet address in local table) { server responds with BOOTLINE and any other data necessary } else { server DOES NOTHING, it assumes some other server will respond } Now, back at the ranch (client side): if ( client receives reply) { client boots up, spawns 2.5 tasks and lives happily ever after} else { client sends message periodically until it receives a reply} The particular application for this type of service is a X-Ray Flourescence analyzer, which may be connected to its host on a network with other analyzers, and has no local serial port. NOTE: Instrument users like to belive that they are operating an instrument and not a computer, i.e. why use a serial port just to get the darn thing working. Other uses include the removal of a need for NVRAM for storing a BOOTLINE. Dan Downing Kevex Instruments 415-591-3600 ext 442 (ddowning@kevex.com). From erik!dan@uunet.uu.net Tue Oct 22 15:48:35 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Oct 22 15:48:51 PDT 1991 Need advice for implementing a new member of the IP protocol suite which would be similar to RARP, in this case maybe it should be called, "IMLOST". The scenario is this: Client(vxWorks target) boots up and does'nt know its IP address nor its bootline data. Therefor it creates an IMLOST packet (similar to RARP ) and broadcasts it on the network. (Packet has its Ethernet address in it) Server(big bad Sun) receives IMLOST packet on a "well know socket" and checks to see if the Ethernet address is in its local table: if ( Ethernet address in local table) { server responds with BOOTLINE and any other data necessary } else { server DOES NOTHING, it assumes some other server will respond } Now, back at the ranch (client side): if ( client receives reply) { client boots up, spawns 2.5 tasks and lives happily ever after} else { client sends message periodically until it receives a reply} The particular application for this type of service is a X-Ray Flourescence analyzer, which may be connected to its host on a network with other analyzers, and has no local serial port. NOTE: Instrument users like to belive that they are operating an instrument and not a computer, i.e. why use a serial port just to get the darn thing working. Other uses include the removal of a need for NVRAM for storing a BOOTLINE. Dan Downing Kevex Instruments 415-591-3600 ext 442 (ddowning@kevex.com). From erik!dan@uunet.uu.net Tue Oct 22 15:48:46 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Oct 22 15:49:03 PDT 1991 Need advice for implementing a new member of the IP protocol suite which would be similar to RARP, in this case maybe it should be called, "IMLOST". The scenario is this: Client(vxWorks target) boots up and does'nt know its IP address nor its bootline data. Therefor it creates an IMLOST packet (similar to RARP ) and broadcasts it on the network. (Packet has its Ethernet address in it) Server(big bad Sun) receives IMLOST packet on a "well know socket" and checks to see if the Ethernet address is in its local table: if ( Ethernet address in local table) { server responds with BOOTLINE and any other data necessary } else { server DOES NOTHING, it assumes some other server will respond } Now, back at the ranch (client side): if ( client receives reply) { client boots up, spawns 2.5 tasks and lives happily ever after} else { client sends message periodically until it receives a reply} The particular application for this type of service is a X-Ray Flourescence analyzer, which may be connected to its host on a network with other analyzers, and has no local serial port. NOTE: Instrument users like to belive that they are operating an instrument and not a computer, i.e. why use a serial port just to get the darn thing working. Other uses include the removal of a need for NVRAM for storing a BOOTLINE. Dan Downing Kevex Instruments 415-591-3600 ext 442 (ddowning@kevex.com). From erik!dan@uunet.uu.net Tue Oct 22 15:49:05 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Oct 22 15:49:24 PDT 1991 Need advice for implementing a new member of the IP protocol suite which would be similar to RARP, in this case maybe it should be called, "IMLOST". The scenario is this: Client(vxWorks target) boots up and does'nt know its IP address nor its bootline data. Therefor it creates an IMLOST packet (similar to RARP ) and broadcasts it on the network. (Packet has its Ethernet address in it) Server(big bad Sun) receives IMLOST packet on a "well know socket" and checks to see if the Ethernet address is in its local table: if ( Ethernet address in local table) { server responds with BOOTLINE and any other data necessary } else { server DOES NOTHING, it assumes some other server will respond } Now, back at the ranch (client side): if ( client receives reply) { client boots up, spawns 2.5 tasks and lives happily ever after} else { client sends message periodically until it receives a reply} The particular application for this type of service is a X-Ray Flourescence analyzer, which may be connected to its host on a network with other analyzers, and has no local serial port. NOTE: Instrument users like to belive that they are operating an instrument and not a computer, i.e. why use a serial port just to get the darn thing working. Other uses include the removal of a need for NVRAM for storing a BOOTLINE. Dan Downing Kevex Instruments 415-591-3600 ext 442 (ddowning@kevex.com). From gdfwc3!billb@texsun.central.sun.com Tue Oct 22 15:49:29 1991 From: gdfwc3!billb@texsun.central.sun.com (Bill Baumann) Date: Tue Oct 22 15:49:42 PDT 1991 Subject: FDDI device drivers... Hello there, I'm looking for FDDI device drivers on a VME backplane using VxWorks on a 68040 board. For the FDDI board, I'm considering using Interphase's Pereguin board, but other boards are still in the running. Has anybody done any FDDIing with VxWorks? Any suggestions where to look to get source to such a driver? many thanks, Bill Baumann (texsun!gdfwc3!kuwait!billb) From WILLIAM@keck.hawaii.edu Tue Oct 22 15:51:06 1991 From: WILLIAM@keck.hawaii.edu (William Lupton: WLupton@Keck.Hawaii.Edu) Date: Tue Oct 22 15:51:24 PDT 1991 Subject: Problems with console i/o and Force CPU/30 I am running VxWorks V4.0.2 on a Force CPU/30. Output from "version": VxWorks (for Force SYS68K/CPU-30) version 4.0.2/VMS-1.3. Kernel: VRTX32/68020 version 1.05. Made on 9-FEB-1990 22:39:40.47. My application does most of its work in two interrupt routines. o One is called from the system clock interrupt (running at 200 Hz; level 4) and typically takes 1.5 ms. o The other is generated from an external timer (running at 5 kHz; level 6) and typically takes 25 us. When I do console output, whether within the context of the shell or another process, there is a high probability that this will hang the shell at some arbitrary stage of the output. When this happens, the shell does not respond to anything and I cannot connect a Telnet session. HOWEVER, both my interrupt routines are still running correctly (as I can tell from an attached oscilloscope). I am using the standard console driver (for the Force CPU-30 DUSCC chips). This takes its interrupts at level 3 and so I suspect that the problem is related to the locking out of DUSCC interrupts for too long. I have looked at the code and that of the associated generic tyLib, but see nothing obvious. I have not done tests with playing with interrupt levels. An obvious test would be to run the system clock interrupt at a lower level than the DUSCC interrupts. I suspect that this would reduce but not eliminate the problem, since until very recently my 200 Hz interrupt was a 200 Hz priority 0 task and the problem occurred then as well. Any suggestions or similar experiences would be very useful. William Lupton, W. M. Keck Observatory, Wlupton@Keck.Hawaii.Edu From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net Tue Oct 22 15:55:10 1991 From: fjr@ss4u02.ssd.ray.com (Roeber) Date: Tue Oct 22 15:55:32 PDT 1991 Subject: Re: Sun Sparcstation to Sun 2(3) C cross compilers > > > or even better, > > 2) Does anyone know if the cross compilers are available > > somewhere? Ftp'able? Sun? Gcc? I haven't been > > able to get> any help from Sun, (they will call me > > back Real Soon Now). > > WRS is now distributing gcc and related GNU tools, now, for Sun4x68k > cross development to VxWorks platforms. If you don't have a direct > relationship with WRS, then I would hope Verdix would help you get the > gcc distribution if it doesn't just come with your v5.0.x distribution > (note that I'm not a Verdix customer and don't speak for them). We are a Verdix VADSWorks customer who are using SUN4s to support development using various 680X0 boards with VxWorks. As Scott suggests we are using the GNU toolset for our SPARC cross 680X0 code generation. Unfortunately, we did not get it from Verdix or WRS. We had to put it together ourselves with much trouble. The problem is that VADSWorks is still based on the pre-GNU version 5.0 of VxWorks. We have been told by Verdix that they are in the process of transitioning to VxWorks 5.0.2 which supports the GNU toolset. The new release might be ready in the February time frame. When delivered it will supposedly include the GNU toolset. In the mean time I don't know what to suggest. Putting together your own GNU toolset, as we did, is quite an undertaking. This is partly because the WRS version of the GNU tools is a "somewhat unique" version based on a fairly old release of the GNU tools (in the world of GNU, months is a long time) with certain local fixes put in. In addition, Verdix uses a modified object file format as compared to SUN so that futher complicates things. Finally, some of the problems we had required source level VxWorks changes. All in all I really think you will have to wait for a future VADSWorks release to do what you want. Sorry about the bad news. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From leonid@amil.co.il Wed Oct 23 00:19:07 1991 From: leonid@amil.co.il (Leonid Rosenboim) Date: Wed Oct 23 00:19:16 PDT 1991 Subject: Re: booting without NVRAM setup > Submitted-by: erik!dan@uunet.uu.net (Dan Downing) > > Need advice for implementing a new member of the IP protocol suite which > would be similar to RARP, in this case maybe it should be called, "IMLOST". > ... First, I would like to say that we would like that functionality as well, except this item is not on top of our priority list at the moment. So Dan, if you end up with something working, please share it with us, if you can. Now I have a couple of suggestions: I know the whole scenario how diskless Sun work stations boot, and it seems doable but rather hard to implement. For once you need to have RPC in the EPROMs, then you have to first issue RARP etc. The other option I have thought but never really checked out is the BOOTP protocol. There are many PD implementations of BOOTP daemon, so if there's anybody who already looked at this, please respond, and share your views. --------------------------------------------------------------------- | Leonid Rosenboim Internet: leonid@amil.co.il | | System Administrator Fax: +972-3498-078 | | Applied Materials (Israel) LTD. Phone: +972-3498-201 | --------------------------------------------------------------------- From muts@fysap.fys.ruu.nl Wed Oct 23 01:29:29 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Wed, 23 Oct 91 01:29:50 PDT Subject: should I use gcc or sun cc as cross compiler> We use vxworks on 680x0 processors, and have a sun sparc as host. I can use suns 'cc' with -target sun3 switch as cross compiler, but I have also installed gnu cc being set up to produce 68000 code. Can anyone tell me if one of these methods has a clear advantage over the other? _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From leonid@amil.co.il Wed Oct 23 04:09:16 1991 From: leonid@amil.co.il (Leonid Rosenboim) Date: Wed Oct 23 04:09:31 PDT 1991 Subject: Re: should I use gcc or sun cc as cross compiler> > Submitted-by: muts@fysap.fys.ruu.nl (Peter Mutsaers) > > We use vxworks on 680x0 processors, and have a sun sparc as host. I > can use suns 'cc' with -target sun3 switch as cross compiler, but I > have also installed gnu cc being set up to produce 68000 code. > Can anyone tell me if one of these methods has a clear advantage over > the other? As far as I know, you don't really have a choise: if you use a pre 5.0.1 VxWorks version, you have to use Sun's cross compiler, and after 5.0.1 you have to use WRS's GNU distribution. On the other hand I hear that Sun's new Sun-C ANSI C compiler has not cross compilation available, while the older C Cross Compiler product is not supported on the newer SunOS versions. July STB issue claims that C Cross COmpiler version 3.0 is not supported on SunOS 4.1.1. Leonid From KADIONIK@frcpn11.in2p3.fr Wed Oct 23 04:23:08 1991 From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik) Date: Wed Oct 23 04:23:57 PDT 1991 Subject: Re: should I use gcc or sun cc as cross compiler> It is preferable to use gnu cc because it generates a more optimized code than the sun cross compiler. It is also more efficient. Gurus may say you why... Patrice Kadionik. kadionik@frcpn11.in2p3.fr From crispen%foxy.boeing.com@ada3.ca.boeing.com Wed Oct 23 05:27:35 1991 From: crispen%foxy.boeing.com%ada3.ca.boeing.com@Csa2.LBL.Gov (crispen) Date: Wed Oct 23 05:27:51 PDT 1991 Subject: Re: FDDI device drivers... Bill Baumann writes: >I'm looking for FDDI device drivers on a VME backplane using VxWorks on a >68040 board. For the FDDI board, I'm considering using Interphase's >Pereguin board, but other boards are still in the running. >Has anybody done any FDDIing with VxWorks? Any suggestions where >to look to get source to such a driver? Enoch Suen of Interphase (and others) has written a Sun driver for the 4211 which is dead easy to port to VxWorks. I did it here at Boeing, and I had to use VxWorks 4.0.2 (which is a lot harder because it doesn't have clusters which I gather 5.0 does). If you have to use 4.0.2, you might try calling Enoch for advice. We're in a situation now where it's a little difficult for me to share my port with anyone, or I'd offer it. But wait, there's more! Jacob Hsu of Interphase is out in California and his gang have allegedly finished their port of the Peregrine driver for VxWorks 5.0, so that's available from your favorite gang of hippies. The original FDDI VxWorks port I did was for the Interphase 3211, which was a dog, IMHO. To be fair, the design wasn't Interphase's; I can't say whose it was, because it's a competitor and we aren't allowed to say bad stuff about competitors. The 4211 seems to be a real joy, again IMHO. We've got it running on a modular flight simulator (we've divided a flight simulator into 11 different boxes and had them talk together to produce a flying F-16). Hope this helps, Bob Crispen (205)461-3296 Boeing Huntsville From crispen%foxy.boeing.com@ada3.ca.boeing.com Wed Oct 23 05:34:58 1991 From: crispen%foxy.boeing.com%ada3.ca.boeing.com@Csa2.LBL.Gov (crispen) Date: Wed Oct 23 05:35:16 PDT 1991 Subject: Re: Problems with console i/o and Force CPU/30 William Lupton writes: > My application does most of its work in two interrupt routines. > > o One is called from the system clock interrupt (running at 200 Hz; level 4) > and typically takes 1.5 ms. > > o The other is generated from an external timer (running at 5 kHz; level 6) > and typically takes 25 us. I don't know your application, so I'm in an ideal position to comment on it ;-). But is there any reason why you can't get out of interrupt level? In VxWorks's network drivers, interrupt handlers use a routine called netJobAdd to put a subprogram and its arguments in a ring buffer which is then executed by the netTask. That way the code gets executed in an orderly fashion, you get out of interrupt level fast, and you code can use all the bells and whistles (like printf, semTake, and so on). It's not that big a trick to figure out how to do that, but I bet if you talk nice to Wind River, they'll let you see the code for netTask and netJobAdd. Bob Crispen (205)461-3296 Boeing Huntsville From muts@fysap.fys.ruu.nl Wed Oct 23 06:02:22 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Wed Oct 23 06:02:38 PDT 1991 Subject: should I use gcc or sun cc as cross compiler> >>Op Wed, 23 Oct 91 04:09:35 PDT schreef u: > As far as I know, you don't really have a choise: if you use a pre 5.0.1 > VxWorks version, you have to use Sun's cross compiler, and after 5.0.1 > you have to use WRS's GNU distribution. > On the other hand I hear that Sun's new Sun-C ANSI C compiler has not > cross compilation available, while the older C Cross Compiler product > is not supported on the newer SunOS versions. July STB issue claims that > C Cross COmpiler version 3.0 is not supported on SunOS 4.1.1. Well, I am using both at the moment and both work. But I have not tested them for speed or reliability, that is why I asked the question. I also got a reply from Patrice Kadionik who told that gcc is better, so I will do that. Thanks, _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From sgc@msel.unh.edu Wed Oct 23 06:29:22 1991 From: sgc@msel.unh.edu (Steven G. Chappell) Date: Wed Oct 23 06:29:31 PDT 1991 Subject: please add me Please add me to the VxWorks exploder mail group thank you Steven G. Chappell -- sgc@msel.unh.edu Marine Systems Engineering Laboratory Marine Program Building 603-862-4600 University of New Hampshire Durham, NH 03824-3525 From lapp@waterloo.hp.com Wed Oct 23 06:59:02 1991 From: lapp@waterloo.hp.com (David Lapp) Date: Wed Oct 23 06:59:11 PDT 1991 Subject: Re: booting without NVRAM setup BOOTP does what you want so you won't need to invent a new Internet protocol and you you should be able to leverage some code. Checkout RFCs 951 and 1048. Dave Lapp lapp@waterloo.hp.com From biocca@bevsun.bev.lbl.gov Wed Oct 23 09:53:15 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Wed Oct 23 09:53:21 PDT 1991 Subject: exploder problems Due to the Oakland fire, which approached LBL, the computer that handles the exploder was shut down sunday afternoon. It had some hardware problems coming back up. Some disk reconfiguration is being done now but outages should be short. Since the incoming messages are actually received by lbl.gov they will wait in the queue there while vxw.ee is temporarily unavailable. These reconfigurations are planned for evening hours and should not take longer than a couple of hours. Thanks for your patience. Alan K Biocca From biocca@bevsun.bev.lbl.gov Wed Oct 23 09:56:37 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Wed Oct 23 09:56:44 PDT 1991 Subject: VxWorks Booting Dan Downing's recent article regarding client booting by getting boot info from boot host is a topic we have discussed with WRS and users before. The beta versions of 5.0 had such a system partially in place -- it was dropped for reasons I don't completely recall. It was a custom system -- not utilizing the standard bootp protocol. WRS indicated that they had looked at bootp and perhaps even experimented a bit with it but the fields in the very specific bootp protocol packet were incompatible with the boot line and not large enough. I made a presentation about 'Reliable & Available' real-time systems at the last user's group meeting in Emeryville, and it was discussed again. It remains an unsolved problem. Perhaps a discussion within the exploder can help crystallize a set of requirements and guidelines that might lead to a solution either from WRS or from the users. Another poster here mentioned that they have similar concerns but not enough priority to solve them now -- that is the same for us. We have multiple online realtime systems here at the BEVALAC control system. Getting the boot info correct in the NVRAM when changing boards or configuring new systems is a source of difficulty. It would be much more efficient to manage this centrally with backup copies maintained in our multiple 'realtime servers' (the Sun SLC's that boot the realtime vxworks crates). I think it is important to stay with standards -- perhaps bootp should be revisited, or perhaps there are alternate upcoming standards that could be considered... Mapping the ethernet address to the boot information is not a total solution either -- it won't work for processors without ethernets, like secondary processors. In our case we don't necessarily want to associate boot information with a particular board -- we must associate it with a particular crate and slot. The techs should be able to swap a cpu and repower the crate and voila! There are devices that contain id numbers and attach to serial ports for software locking schemes that could be attached to the rear of the crate-slots to generate the unique id. That, combined with the type of cpu could map to the bootline in the bootp database. I think a quality solution to this problem would encompass both scenarios. This fits in well with the next step in improving system availability -- providing multiple boot hosts with automatic switchover. This can be accomplished by tweaking the bootp server so that for each entry in its database it has a delay factor. Thus you can designate primary/secondary servers and the crate takes the first reply. If the primary is down, the crate boots from the secondary host, who replies with a longer delay than the primary. Alan K Biocca From stan@rti.com Wed Oct 23 11:02:06 1991 From: stan@rti.com (Stan Schneider) Date: Wed Oct 23 11:02:19 PDT 1991 Subject: Re: should I use gcc or sun cc as cross compiler >> > We use vxworks on 680x0 processors, and have a sun sparc as host. I >> > can use suns 'cc' with -target sun3 switch as cross compiler, but I >> > have also installed gnu cc being set up to produce 68000 code. >> > Can anyone tell me if one of these methods has a clear advantage over >> > the other? >> As far as I know, you don't really have a choise: if you use a pre 5.0.1 >> VxWorks version, you have to use Sun's cross compiler, and after 5.0.1 >> you have to use WRS's GNU distribution. We've been using gcc to cross-compile for several years (since 4.0.2). We've only had two problems: 1) You have to "fix" several header files (a believe there's a set in the archives). 2) You have to "fix" the makefiles if you want to rebuild a kernel. We have had trouble building boot ROMs. I hear WRS welded on the code generator to make this work. Gcc has the clear advantages of being ANSI-compliant & free. -- Stan P.S. I don't recall seeing the original message from "muts@fysap.fys.ruu.nl". Am I missing exploder traffic? =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From scotth@rocco.labs.tek.com Wed Oct 23 11:03:23 1991 From: scotth@rocco.labs.tek.com Date: Wed Oct 23 11:03:33 PDT 1991 Subject: Re: Vx Exploder Digest > to suggest. Putting together your own GNU toolset, as we did, is quite > an undertaking. This is partly because the WRS version of the GNU tools > is a "somewhat unique" version based on a fairly old release of the GNU > tools (in the world of GNU, months is a long time) with certain local > fixes put in. In addition, Verdix uses a modified object file format > as compared to SUN so that futher complicates things. Finally, some > of the problems we had required source level VxWorks changes. All in > all I really think you will have to wait for a future VADSWorks > release to do what you want. Sorry about the bad news. Fred I'd like to report just a bit more experience with regard to the gnu toolset. WRS is currently distributing v1.37 of the C compiler and v3.2 of the debugger. At Tek, we've been using v1.37 for well over a year and have found it to be pretty stable and reliable. We used v1.35 for the year previous. We initially did our own cross-development configuration (Sun4 x 68k) and are now in the process of making the WRS configuration available (hopefully reducing the cost of support the tools ourselves). My group supports software development tools for the rest of the company, and we've evaluated GNU versions 1.38 through 1.40 and have decided not to distribute any of these. v1.38 was totally broken, followed quickly by v1.39 and later by v1.40. For 680x0 targets, these versions didn't add anything significant. We rely heavily on v1.37 for code running in many Tek products. I can't say as much with regard to the debugger. We're currently using a heaving modified version of v3.5. 95% of the modifications provide better support for C++; this is the main reason we continue to support gdb ourselves, we are doing a lot in C++. A secondary reason is that our version of gdb supports remote vxworks debugging in a way that requires less target resources than the WRS version does (theirs requires TCP/IP, dbgLib, and a server task to handle debugger requests; ours uses a 2.5KB ROM monitor). Don't know how interesting this is to all, but wanted to provide a small report of some of our experience using GNU tools at Tek. scotth@crl.labs.tek.com Scott Herzinger Computer Research Lab, Tektronix, Inc. PO Box 500 MS 50-662, Beaverton, OR 97077 From bard@cutter.ssd.loral.com Wed Oct 23 11:20:12 1991 From: bard@cutter.ssd.loral.com (James Woodyatt) Date: Wed Oct 23 11:20:28 PDT 1991 Subject: Re: should I use gcc or sun cc as cross compiler> #> > As far as I know, you don't really have a choise: if you use a pre 5.0.1 #> > VxWorks version, you have to use Sun's cross compiler, and after 5.0.1 #> > you have to use WRS's GNU distribution. #> #> > On the other hand I hear that Sun's new Sun-C ANSI C compiler has not #> > cross compilation available, while the older C Cross Compiler product #> > is not supported on the newer SunOS versions. July STB issue claims that #> > C Cross COmpiler version 3.0 is not supported on SunOS 4.1.1. #> #> Well, I am using both at the moment and both work. But I have not #> tested them for speed or reliability, that is why I asked the #> question. #> #> I also got a reply from Patrice Kadionik who told that gcc is better, #> so I will do that. Thanks, Good choice. Incidentally, we're using VxWorks 4.0.2 still (arrrggghhh!!!!) and we've been using gcc-1.40 on sun4's for months. Works great. I'd scream bloody murder if I had to go back to that *other* compiler. Making gcc into a cross compiler is not that hard if you follow the procedure we obtained from the VxWorks archives. -- -- James Woodyatt -- bard@cutter.ssd.loral.com -- Space Systems/Loral (Palo Alto, CA) -- From omni!hwajin@apple.com Wed Oct 23 12:17:15 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Oct 23 12:17:25 PDT 1991 Subject: Re: booting without NVRAM setup Your message dated: Wed, 23 Oct 91 06:59:16 PDT >BOOTP does what you want so you won't need to invent a new Internet protocol >and you you should be able to leverage some code. Checkout RFCs 951 and >1048. Several different incantations of BOOTP and customized BOOTP-like protocols have been implemented within WRS. Due to the complication involved in booting backplane targets via gateway and benign pursuit of perfection, WRS has not decided to release them until everything just perfect. Better to ask for help from WRS than try to waste time doing your own. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From rau@sj.ate.slb.com Wed Oct 23 13:05:28 1991 From: rau@sj.ate.slb.com (Santosh R. Rau) Date: Wed Oct 23 13:07:46 PDT 1991 Subject: mailing list Can you please remove my name from the mailing list ? Thanks - Santosh R Rau rau@sj.ate.slb.com From crispen%foxy.boeing.com@ada3.ca.boeing.com Wed Oct 23 13:36:37 1991 From: crispen%foxy.boeing.com%ada3.ca.boeing.com@Csa2.LBL.Gov (crispen) Date: Wed Oct 23 13:36:57 PDT 1991 Subject: FDDI -- to Bill Baumann Sorry for burdening the mailing list with this, but I got the following when I tried to reply to Bill: ----- Transcript of session follows ----- Connected to snail: >>> RCPT To: <<< 554 ... Unknown UUCP host : dfwc3 554 ... Service unavailable Here's my note: I'm sorry that I can't be real specific, but there's an issue of giving away trade secrets. Fortunately, what follows is in the public domain. The Air Force Mod Sim program (HAVE MODULE) published a final report and a series of ISWG (Interface Standard Working Group) reports. I don't have a copy here on my desk -- someone stole it -- but you can contact your favorite SIMSPO (or whatever they call it) officer. Phil Peppler at AFHRL is another point of contact. Now, everything I'm about to say is in these reports, and alas it applies to VxWorks 4.0.2. You're right that UDP/IP is way too slow. What we did is to pre-build an FDDI packet -- FDDI header, LLC header, IP header and UDP header. Only the IP checksum counts, and it's the header checksum Make the UDP checksum zero. This is from memory -- I think it's the UDP checksum that's allowed to be zero. If this isn't true any more in VxWorks 5.0, you'll have to compute a UDP checksum each time. Then we shoved the pre-built packet (different message each time) into a routine called "fddi_fastwrite" which put the packet on the board. On the receive side, we had a hook routine that intercepted all the packets. If the packet was an IP packet, and a UDP packet, and was to a port we were interested in, we copied it straight to a static memory buffer. Otherwise, we let it go up to the protocol stacks. We used the famous "xxxHookAdd" paradigm -- if there isn't any hook routine address, obviously we don't call the hook routine. Using that method we can easily send 10K bytes in a small number of milliseconds. Exact timing data is in the (lost) final report, but I think you'll be happy. BTW, Hwajin Bae did a bunch of speeding up of the net stuff between VxWorks 4.0 and 5.0, so this may even be unnecessary. Anyhow, you can tell your boss that you have a fallback position in case you can't make the numbers the regular way. If you want to pay me back, email me a copy if you have one of RFC 1216, "Gigabit Network Economics and Paradigm Shifts". Thanks. Hope this helps. Bob Crispen (205)461-3296