From stan@rti.com Fri Apr 1 00:15:44 1994 From: stan@rti.com (Stan Schneider) Date: Fri Apr 1 00:15:57 PST 1994 Subject: Re: Slow backplane net in vxWorks 5.0.2b >> Submitted-by LAJOIE@yalph2.physics.yale.edu Thu Mar 31 14:31:03 1994 >> Does anyone have any suggestions for improving the backplane performance with >> vxWorks 5.0.2b? >> If you have any way of causing interrupts, don't use polling. It can make a huge difference. -- 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 daemon@vxw.ee.lbl.gov Sat Apr 2 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 2 04:00:31 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 2 04:00:13 PST 1994 Subject: Re: VxWorks rshd? Subject: IDE/floppy Device Drivers for I960 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks rshd? Date: 01 Apr 1994 20:51:36 GMT From: pjg@parint.esl.com (Paul Gyugyi) Organization: ESL, Inc. Message-ID: References: <9403311855.AA13012@rti.com> >> We have targets running VxWorks that I would like to set up for >> manufacturing test, by loading a diagnostic RPC server that I wrote for >> the test application. The way it works now, a test technician would >> have to run the commands needed to start the server (nfsMount(), cd(), >> ld(), rpcInit() and sp()) by logging in to the vxWorks shell. There are ... >> server to handle the requests from the Sun. Does anybody know a way to >> do this? There are three ways I know of... 4) Write a program on the SUN that calls fp=popen("rlogin target","w") to open a connection to the target. You can then call fprintf(fp,"< script_file") just as if you were in the shell. The following code snippet will rlogin into a target and do an "i" command. The output of the i command will appear in stdout, so you can pipe it to grep, etc. One warning, sometimes characters get lost in transmission without the fflush and sleep calls. I'm not sure this is the most reliable way of doing things, but what do you expect from a dozen lines of code? :). # UNIX/SUN4.1.3 program to get a list of tasks running on the target. #include #include main() { FILE *fp; fp = popen("rlogin target","w"); fprintf(fp,"i\n"); fflush(fp); sleep(2); fprintf(fp,"logout\n"); fflush(fp); pclose(fp); } - -- =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= | Paul Gyugyi scrabble...click...snap... | | gyugyi@earthsea.stanford.edu Paul_Gyugyi@smtp.esl.com | =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= --------------------------- Newsgroups: comp.os.vxworks Subject: IDE/floppy Device Drivers for I960 Date: Fri, 1 Apr 1994 23:33:53 GMT From: allender@caffeine.tucson.ibm.com (Mark Allender) Organization: IBM System Storage Division -- Device Driver Development Keywords: Device Driver, IDE, floppy, i960 Message-ID: Reply-To: allender@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) Has anyone written a device driver for an IDE controller and/or a floppy driver under the i960 platform for VxWorks runtime? I have heard that Wind River has an IDE/floppy driver for the 486 chip, but I don't know if there is one for the 960. If the 486 is the only IDE dd that is available from Wind River, has anyone looked into porting that driver to the 960 platform? Any comments or help would be appreciated. - -- - -Mark Allender < insert standard disclaimer here > - -IBM -- SSD Tucson - -Device Driver Development - -allender@vnet.ibm.com --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Apr 3 04:00:24 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Apr 3 04:00:33 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 3 04:00:15 PDT 1994 Subject: Debugging/Purifying a multi-tasking application Subject: booting vxWorks V5.1.1 from backplane network ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Debugging/Purifying a multi-tasking application Date: 2 Apr 1994 13:34:19 GMT From: chandy@hellix.inria.fr (Chandra Shekhar) Organization: INRIA, Sophia-Antipolis (Fr) Keywords: debugging, multi-tasking, memory Message-ID: <2njs8r$f7r@sophia.inria.fr> Hi folks, I am working on a VxWorks application that involves several interacting tasks. There is an error in my code somewhere which causes a hard system crash, without telling me where the fault occurred. Whenever I try to debug it, either using VxGDB or the VxWorks shell debugger, no error occurs, and the application runs smoothly. I guess when I am in the debug mode, the timing of the tasks gets changed, so the crash-causing condition does not occur. So how do I go about localising the fault? What I would like to do is to "step" through the entire application, and find out precisely what combination of circumstances causes the crash. Unfortunately, I know no way of doing this. I can only step through one task at a time, and that disrupts the normal scheduling of tasks. One way of detecting memory usage errors (which are the probable cause of system crashes) is to use the "Purify" program. However, I don't know if I can use this with a VxWorks program. Any ideas will be greatly appreciated. Chandra Shekhar --------------------------- Newsgroups: comp.os.vxworks Subject: booting vxWorks V5.1.1 from backplane network Date: Fri, 1 Apr 1994 01:57:34 GMT From: rick@neopath.wa.com (Rick Bauer) Organization: NeoPath Inc. Keywords: backplane network Message-ID: <1994Apr1.015734.20073@neopath.wa.com> Reply-To: rick@neopath.wa.com Sender: news@neopath.wa.com We are attempting to boot a multi-CPU system, 680x0 series, using a back plane network with VxWorks, "version 5.1.1". The Host CPU, procnum 0, is a Force FRC30 CPU board, and the slave CPU, procnum 1, is a Motorola MVME162 CPU board. The Host CPU has an ethernet connection to our SUN4 network. We are using the new smNetLib to boot the MVME162 from the backplane network using the HOST CPU as a gateway to our Sun4 development network. We can boot the FRC30 CPU successfully, but we have not been able to boot the MVME162. We have configured the Host CPU as a gateway on the Sun network to our VmeBus backplane network. The Host is configured to establish the back plane network memory pool in its Dual Ported RAM. The Host CPU seems to initialize the backplane network correctly: we have examined the memory locations recommended by WindRiver and the values agree with the documentation. To simplify our configuration, we have disabled all MMU and CACHE support in the kernel for the FRC30 and the MVME162. We also configured the backplane network to use polling. We have configured the slave CPU to boot from the shared memory device, "sm0". From the slave CPU we are able to examine successfully the backplane network memory locations on the Host CPU corresponding to backplane anchor memory address that we established in the MVME162 boot parameters. When we boot the MVME162 after booting the FRC30, the MVME162 attaches to the backplane network, "sm0", and then attaches the network interface, "lo0". The slave does seem to wait for the Host CPU to initialize the backplane network with the values described by the "5.1.1" documentation. However, the boot sequence fails as soon as the MVME162 attempts loading the VxWorks kernel from the network. The error message is: Error loading file: errno = 0xd Can't load boot file!! If we query the backplane network, smNetShow, after the MVME162 boot fails, the report inidicates that only CPU 0 is attached to sm0. This seems to contradict the boot messages from the MVME162 indicating that the CPU succesfully attached to both sm0 and lo0. The boot files for the FRC30 and the MVME162 are both on the same sun4 host. The sun4 host has been configured to allow both target CPUs access to the workstation as remote hosts. The FRC30 CPU also appears as the gateway to our backplane network in the routing tables displayed by our network server. We are stumped!!! Everthing seems configured correctly, yet the MVME162 won't boot. If anyone has experience with back plane networks in a similar configuration, we would greatly appreciate any help you can give us in solving this problem. Thanks, Rick Bauer NeoPath 1750 112th Ave NE Suite B101 Bellevue WA 98004 Phone: 206-455-5932 Email: rick@neopath.wa.com --------------------------- End of New-News digest ********************** From pardo@sun-valley.stanford.edu Sun Apr 3 21:22:23 1994 From: pardo@sun-valley.stanford.edu (Gerardo Pardo-Castellote) Date: Sun Apr 3 21:22:31 PDT 1994 Subject: Re: Debugging/Purifying a multi-tasking application >I am working on a VxWorks application that involves several >interacting tasks. There is an error in my code somewhere >which causes a hard system crash, without telling me where >the fault occurred. Whenever I try to debug it, either >using VxGDB or the VxWorks shell debugger, no error occurs, >and the application runs smoothly. If your tasks are accesing shared data (as opposed to just communicating with messages) you may be experiencing a race condition where if one task happens to be scheduled while the other was modifying the shared data structures in such a way that the "state" was inconsistent (e.g. one task is adding something to a linked lists anw while the list is temporarily 'inconsistent' the other task takes the processor and tries to traverse the list.). >One way of detecting memory usage errors (which are the probable >cause of system crashes) is to use the "Purify" program. However, >I don't know if I can use this with a VxWorks program. If you may have a memory thrasing problem, It shouldn't be too hard to trace it down with an appropriate tool. We use HeapCheck a tool that comes with the RTILib package from Real-Time Innovations. It allows you to determine if your heap is corrupted and trace down the task that corrupts the memory. I've tracked down several memory thrasing problem in our systems with it. Other than that I would suggest trying to simplify your code to the minimum # of tasks that still exhibit the problem or, suspend from the shell one task at at time in the hope of isolating a single one whose presence exhibits the problem and then look at the data it accesses and protect it with locks. You could also try setting break-points at diferent places from the shell (or vxgdb) but as you mentioned, this may make the problem go away (which is why I think you have a race condition). > I can only step through one task at a time, and that disrupts the normal > scheduling of tasks. That's not totally correct. you can start several concurent vxgdb sessions and and step on both tasks simultaneously. It is quite painful though. Good luck, Gerardo. ------------------------------------------------------------------- Gerardo Pardo-Castellote [ pardo@sun-valley.stanford.edu ] Aerospace Robotics Laboratory [ (415) 723-3677 ] ---- From daemon@vxw.ee.lbl.gov Mon Apr 4 04:00:18 1994 From: daemon@vxw.ee.lbl.gov Date: Mon Apr 4 04:00:27 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Apr 4 04:00:10 PDT 1994 Subject: fork/exec/wait in VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: fork/exec/wait in VxWorks Date: Mon, 4 Apr 1994 03:00:14 GMT From: ericp@netcom.com (Eric Peterson) Organization: NETCOM On-line Communication Services (408 241-9760 guest) Message-ID: Is there an easy (or at least straightforward) method for emulating the Unix fork/exec/wait tasking primitives in VxWorks? I'm doing some porting of some Unix apps, and I would think that this pops up quite often (I searched the FAQ without luck). Also, is the SIGCHLD signal really implemented to be generated upon (sub)-task exit, or is it just there to make things compile :-)? The man pages aren't too clear on signal behavior. Thanks in advance, Eric - -- Eric Peterson WB6PYK AX.25: wb6pyk@n6mbr AMPRNET: [44.6.0.133] ericp@netcom.com --------------------------- End of New-News digest ********************** From prb@aplexus.jhuapl.edu Mon Apr 4 05:14:13 1994 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Mon Apr 4 05:14:22 PDT 1994 Subject: Re: Debugging/Purifying a multi-tasking application > Newsgroups: comp.os.vxworks > Subject: Debugging/Purifying a multi-tasking application > Date: 2 Apr 1994 13:34:19 GMT > From: chandy@hellix.inria.fr (Chandra Shekhar) > Organization: INRIA, Sophia-Antipolis (Fr) > Keywords: debugging, multi-tasking, memory > Message-ID: <2njs8r$f7r@sophia.inria.fr> > > > Hi folks, > > I am working on a VxWorks application that involves several > interacting tasks. There is an error in my code somewhere > which causes a hard system crash, without telling me where > the fault occurred. Whenever I try to debug it, either > using VxGDB or the VxWorks shell debugger, no error occurs, > and the application runs smoothly. > > I guess when I am in the debug mode, the timing of the tasks > gets changed, so the crash-causing condition does not occur. > > So how do I go about localising the fault? What I would like > to do is to "step" through the entire application, and find > out precisely what combination of circumstances causes the > crash. Unfortunately, I know no way of doing this. I can only > step through one task at a time, and that disrupts the normal > scheduling of tasks. > > One way of detecting memory usage errors (which are the probable > cause of system crashes) is to use the "Purify" program. However, > I don't know if I can use this with a VxWorks program. > > Any ideas will be greatly appreciated. > > Chandra Shekhar > You might try getting a copy of WindView from vxWorks. You could configure it in the instrumentation mode. Then after a crash you can reset, upload the windview buffer and look at a graphical representation of what was happening prior to the crash. This assumes that you set windview up so that the windview buffer doesn't get cleared on powerup. Paul Bade From leonid@rst.co.il Mon Apr 4 05:34:25 1994 From: leonid@rst.co.il (Leonid Rosenboim) Date: Mon Apr 4 05:34:41 PDT 1994 Subject: Re: fork/exec/wait in VxWorks >ericp@netcom.com (Eric Peterson) writes: > Is there an easy (or at least straightforward) method for emulating the > Unix fork/exec/wait tasking primitives in VxWorks? I'm doing some > porting of some Unix apps, and I would think that this pops up quite > often (I searched the FAQ without luck). Also, is the SIGCHLD signal > really implemented to be generated upon (sub)-task exit, or is it just > there to make things compile :-)? The man pages aren't too clear on > signal behavior. Please excuse me saying so, but this question clearly shows that Eric doesn't really understand what VxWorks is, (or what Unix is for that matter, or both). The whole idea behind fork() is to create an exact duplicate of the parent process, but which is entirely independent of it, i.e. all the child's writable memory is its own private copy. Nower days fork(0 doesn't really copy the entire parent data and stack memory, but uses the Virtual Memory mechanism to duplicate only those pages which are subsequently modified by either the parent or child processes. This saves a lot of juice, but the semantics are the same. Here is an example, before calling fork() the parent had a global variable xxGlobal with value of say 11. After fork returns, both the parent and child view of this variable shows the same vaue, 11. But should either child or parent change this variable at any time, that change will not be reflected to the other, because although in those two processes the address of xxGlobal is the same, these addresses refer to distinct physical addresses in memory. In order to be able to implement such semantics to the full extent, one needs complete VIrtual Memory with On-Demand Paging mechanism undeneath. VxWorks does not support such a Virtual Memory scheme, and I doubt that any OS that does implement VM can be called Real-Time in the true sense of the term. VM adds enourmous context switching overhead, and increases inter-task resource sharing overhead by an order of magnitude. As to exec(), it can be simulated with moduleLib() (e.g. ld() ) functions, but without fork() that won't be the same thing ever. wait() and SIGCHLD have no meaning within VxWorks tasking scheme, but they both can be easily implemented using taskDeleteHooks. In VxWorks there are no parent-child relations between tasks, but that can be added quite easily to emulate wait() and SIGCHILD semantics. I hope this clarifies some points. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@rst.co.il [ Wind River Systems Distributor and Systems Integrator ] From ma@tadpole.com Mon Apr 4 06:55:36 1994 From: ma@tadpole.com (Mark Armitage) Date: Mon Apr 4 06:55:44 PDT 1994 Subject: Re: Memory Problems: Copyback vs Writethrough > Enabling the MMU to use writethrough mode (or no caching at all) > resulted in success. Mind you, this is a single processor > system. Also, you MUST write something to every memory location > in order to set the parity bits BEFORE you can do a read. We > used bzero() to do this before adding the memory to the system > pool, and all worked ell for writethrough mode, but it still > blew chunks in copyback mode. > > Heurikon was extremely helpful in finding the problem; however, > we're still not sure WHY it happens. I think that your problem is because the 040 has to have a whole cache line valid (or invalid). So if the processor writes to part of the line, the cache has to read the rest of the line from memory to get valid data for the whole line! I know it sounds a bit perverse, but I think that's the right explanation. Mark Armitage Tadpole Technology ma@tadpole.com From daemon@vxw.ee.lbl.gov Tue Apr 5 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Apr 5 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 5 04:00:13 PDT 1994 Subject: NVRAM Help! Subject: Re: Debugging/Purifying a multi-tasking application ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: NVRAM Help! Date: Mon, 4 Apr 1994 15:57:05 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: BNR Inc., RTP, NC Message-ID: Sender: billag@b4pphff (Bill Gutknecht) I have an application that needs to store some information in NVRAM (btw ... I'm using a MVME162-13 ...) and that address space is around 0xfffc0000 ... but guess what ... that's where vxWorks boot info is ... Anyone know where this ends and a safe place to start is? Thanks! - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will BNR/Northern Telecom ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Debugging/Purifying a multi-tasking application Date: 4 Apr 1994 19:47:41 GMT From: schuweil@forge.fnal.gov (greg schuweiler) Organization: FERMILAB, Batavia, IL Keywords: debugging, multi-tasking, memory Message-ID: <2npqst$l9k@fnnews.fnal.gov> References: <2njs8r$f7r@sophia.inria.fr> In article <2njs8r$f7r@sophia.inria.fr>, chandy@hellix.inria.fr (Chandra Shekhar) writes: |> |> Hi folks, |> |> I am working on a VxWorks application that involves several |> interacting tasks. There is an error in my code somewhere |> which causes a hard system crash, without telling me where |> the fault occurred. Whenever I try to debug it, either |> using VxGDB or the VxWorks shell debugger, no error occurs, |> and the application runs smoothly. |> |> I guess when I am in the debug mode, the timing of the tasks |> gets changed, so the crash-causing condition does not occur. |> |> So how do I go about localising the fault? What I would like |> to do is to "step" through the entire application, and find |> out precisely what combination of circumstances causes the |> crash. Unfortunately, I know no way of doing this. I can only |> step through one task at a time, and that disrupts the normal |> scheduling of tasks. |> |> One way of detecting memory usage errors (which are the probable |> cause of system crashes) is to use the "Purify" program. However, |> I don't know if I can use this with a VxWorks program. |> |> Any ideas will be greatly appreciated. |> |> Chandra Shekhar - -- You might try compiling the offending code with both -g and -O. This will cause some surprizing results as the next statement to execute may not be the one you expect. Some variables may no longer exist, and some statements many possibly be outside of loops. But it is very possible to debug optimized code. You will just need to run through the code with vxgdb a few times. Good luck ========================================================================= Greg Schuweiler The standard disclaimer applies schuweil@forge.fnal.gov to all I may have said, may say, (708) 840-2665 and/or may do. It does not reflect, the feelings of my employer. Heck, if it did, we would lose our funding. Like a rock, I stand against the wind ========================================================================= --------------------------- End of New-News digest ********************** From kruk@lannet.com Tue Apr 5 04:30:09 1994 From: kruk@lannet.com (Meir Kruk) Date: Tue Apr 5 04:30:18 PDT 1994 Subject: WindC++ version of VxGDB on i960 does not work Hello, I have a question to you vxWorks/C++ users out there. Has anyone worked with the VxGDB on a C++ application? My problem is as follows: I have installed an evaluation copy of WindC++ 1.0 beta on Sun4 station running VxWorks 5.1.1 , for i960CA custom target. I have started VxGDB, attached to the target, attached to tasks, etc. VxGDB recognizes the C++ language , but I could not make it recognize line numbers of C++ source, nor could I make VxGDB display the C++ source in any way. DEMONSTRATION PROCEDURE : Compile/link a C++ application with -g, by using the following makefile: INC = -I$(VW)/h ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS all: myProg.C CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C gnm960 -pv myProg.o | munch960 > __ctordtor.c gcc960 -g $(ARCH) -c __ctordtor.c gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o Start VxGDB : vxgdb -t 960++ Attach target: target vxworks target_ip_addr vxWorks.st Load the C++ application into the target from VxGDB and issue the command "list" with either file name or function name. The debugger reports: "No line number information" Does this sound familiar to anybody? Any help or suggestions would be appreciated. Thanks, Meir. -------------------------------------------------------------------- Meir Kruk | Email: kruk@lannet.com LANNET Data Communication Ltd. | Tel: 972-3-6458398 Atidim Technology Park,Bldg. 3 | Fax: 972-3-6487146 Tel Aviv 61131, Israel | -------------------------------------------------------------------- From tweadon@sadira.gb.nrao.edu Tue Apr 5 06:00:49 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Tue Apr 5 06:00:57 PDT 1994 Subject: Re: WindC++ version of VxGDB on i960 does not work I posted something on this a few weeks ago, it was about the shell but sounds like it applies here also. When using C++ you either choose "INCLUDE _CPLUS" or "INCLUDE_CPLUS_MIN". inside your configAll.h file. In VW5.1.1 WRS made a BOO-BOO! They force you to include only one or the other. If you choose both then you get a compile error in usrConfig.c. But in src/config/usrExtra.c they make a compile time check to see if they both are defined. If so then they set sysCplusEnable = TRUE; sysCplusEnable must = TRUE for the shell, and probably the debugger, to try to interpret C++ commands and display C++ lines and variables. First, set sysCplusEnable = TRUE from the shell. If this fixes your problem then you know that it is your only problem. If it doesn't then you know it is only one of your problems. If you are going to use C++ you must modify usrExtra.c and change the line which checks (INCLUDE_CPLUS) && (INCLUDE_CPLUS_MIN) is true to (INCLUDE_CPLUS) || (INCLUDE_CPLUS_MIN). Tim Weadon National Radio Astronomy Observatory Green Bank, WV. 24944 (304) 456-2120 From daemon@vxw.ee.lbl.gov Wed Apr 6 04:00:27 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 6 04:00:38 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 6 04:00:16 PDT 1994 Subject: Setting the MVME167 clock chip? Subject: Fixed: memPartFree error with copyback caching enabled (167) Subject: BOOTP server on VxWorks target Subject: Re: Memory Problems: Copyback vs Writethrough Subject: unsupported software for DT1492 Subject: How to install a digital to analog board for a sun1e target? Subject: References Subject: Naming System Objects ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Setting the MVME167 clock chip? Date: Tue, 5 Apr 1994 15:30:17 GMT From: curry@tc.fluke.COM (John Curry) Organization: Fluke Corporation, Everett, WA Message-ID: Before getting too deep into the documentation, does anyone out there have any information on setting and retrieving the time of day from the MVME167 clock chip? What I looking for is some way to maintain the time between VxWorks boots without having to access a host computer. Thanks for any help. John Curry - -- - ---------------------------------------------------------------------------- John Curry Fluke Corporation curry@tc.fluke.com 6920 Seaway Blvd m/s 178D 206-356-5708 Everett, Wa. 98206 - ---------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Fixed: memPartFree error with copyback caching enabled (167) Date: Tue, 5 Apr 1994 20:23:51 GMT From: georg@sgl.ists.ca (Georg Feil) Organization: Institute for Space and Terrestrial Science Keywords: VxWorks bug Message-ID: Sender: news@newshub.ists.ca This is a followup to an earlier message describing a nasty memPartFree bug under VxWorks 5.1.1 on the MVME167 with the CPU data cache enabled in copyback mode. We have now found a workaround for the bug, which appears to be inside VxWorks. No exact cause yet, we have opened a TSR with Wind River and they are looking into it. The situation which triggers the bug is a long series of reads from a dosFs file on a SCSI disk. The data is passed through rpc stuff by our application (an NFS server) and then returned via sockets to the external client. Occasionally new dosFs files are opened and read, and there is lots of unrelated malloc() activity such as performed by rpc/network routines. The 68040 data cache is enabled with the 167's DRAM set for copyback caching. The effect of the bug is corruption of the system memory pool leading to memPartFree errors and errors in the file data read from disk. It was discovered fairly early that changing the entire system memory pool's cache attributes to writethrough made the problem disappear. Therefore it is due to a cache inconsistency. A subsequent exhaustive search was made for the particular malloc() buffers which need to be made writethrough by replacing specific pairs of malloc()/free() calls with alternate calls named valloc3() and vfree3(). The alternate calls change the cache attributes of the memory obtained by malloc() to writethrough, and then restore the attributes to copyback when freeing. We found that none of our application malloc() calls were causing the problem. This was as suspected, since cache inconsistency is most likely related to DMA, which VxWorks does internally. We finally found that the internal buffer used by VxWorks for dosFs read() calls was the problem. Data is copied from the VxWorks internal buffer to the user's buffer during read() calls using bcopy(). The VxWorks internal buffer was found to have regular cache attributes (copyback). When patched to use the alternate valloc3()/vfree3() calls, the memory problems disappeared. Information on the exact patching process and the VxWorks malloc()/free() call locations is available to anyone who wants to know. The memory errors seemed to happen when some other task independently performing malloc()/free() happened to re-use the same memory area as previously used for the internal I/O buffer. Therefore an unrelated task generates the actual error message on a free() call. What we suspect is happening is that information from the data cache is being written out after the original I/O buffer has been freed. Our system is a 33 MHz MVME167 with 32 Mbytes of memory (16 MB of which are in a separate memory pool and not available to VxWorks), a Seagate Barracuda 2.1 GB SCSI disk, and no other processors. We do have some memory and custom cards sitting on VME but the memory is not used and the custom cards are not believed to be a factor. Some mention was made of a VMEchip2 TAS problem affecting the data cache, but we don't use TAS over VME. I'll post a quick note if we find out the actual cause of this bug... Georg. - -- Georg Feil Space Geodynamics Laboratory | Internet: georg@sgl.ists.ca Institute for Space and Terrestrial Science | Phone: (416) 665-5458 4850 Keele St./North York/Ont/Canada/M3J 3K1 | Fax: (416) 665-1815 --------------------------- Newsgroups: comp.os.vxworks Subject: BOOTP server on VxWorks target Date: Mon, 4 Apr 1994 15:26:17 GMT From: pnarayan@hns.com (Padmini Narayan) Organization: Hughes Network Systems Inc. Keywords: VxWorks, BOOTP Message-ID: <1994Apr4.152617.15454@hns.com> Sender: news@hns.com (USENET news system) At HNS we might require VxWorks targets to act as BOOTP servers off of which other VxWorks targets can boot. As of now, only thr BOOTP client features have been implemented in VxWorks. Does any one out there know of a BOOTP server implementation on VxWorks targets? I would really like to know if this is possible at all. Any thoughts/information on this will be much appreciated. (Please e-mail responses to pnarayan@hns.com) Thanks in advance - -- Padmini ^^^^^^^^^^^^^^^^^^^^^^^ Padmini Narayan pnarayan@hns.com Embedded Software Group Hughes Network Systems --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Memory Problems: Copyback vs Writethrough Date: Tue, 5 Apr 1994 22:49:31 GMT From: jfinley@netcom.com (John Finley) Organization: NETCOM On-line Communication Services (408 241-9760 guest) Message-ID: References: <199404010251.VAA19381@piglet.INS.CWRU.Edu> Erik C. Orange (ah442@cleveland.freenet.edu) wrote: : We have had similar experiences with the copyback vs writethrough : memory problem. : Our situation: Our CPU is a Heurikon HKV4F 68040. We purchased : a Micro Memory 8MB dynamic RAM board. After properly configuring : VxWorks 5.1 to access address space in extended VME space, we : added the board to our system and tried to utilize it as VxWorks : system pool. We found that we could NOT enable copyback mode : on the MMU; any attempt to access the memory caused a parity : error on the memory board (and a VxWorks bus error). : Enabling the MMU to use writethrough mode (or no caching at all) : resulted in success. Mind you, this is a single processor : system. Also, you MUST write something to every memory location : in order to set the parity bits BEFORE you can do a read. We : used bzero() to do this before adding the memory to the system : pool, and all worked ell for writethrough mode, but it still : blew chunks in copyback mode. : Heurikon was extremely helpful in finding the problem; however, : we're still not sure WHY it happens. When you write to a memory location set in copyback mode and there's a cache miss, the MMU first reads the whole cache line into the cache, then updates the location you're writing to. That's where the parity error is coming from. You ought to be able to clear the board uncached, then turn on copyback. - -John jfinley@netcom.com : Erik : -- : Erik C. Orange FRD Industrial Automation : Systems Engineer Avery-Dennison Corporation : ah442@cleveland.Freenet.Edu Concord, OH --------------------------- Newsgroups: comp.os.vxworks Subject: unsupported software for DT1492 Date: 5 Apr 94 15:51:21 PDT From: meier@rogue.llnl.gov Organization: Lawrence Livermore National Laboratory, NCD Message-ID: <1994Apr5.155121.1@rogue.llnl.gov> I am relatively new to VxWorks and am trying to put together a little data acquisition system. I have a Data Translations DT1492 multi-function board and would like to use the a/d's. I am aware that there is supposed to be some software in the "unsupported" directory, but I can't manage to find it. Is there an ftp site I could download some code, and what files do I need?. I am using VxWorks ver 5.0.1. Any other experience you can share would be helful, thanks. - -- Timothy A. Meier meier3@llnl.gov Lawrence Livermore National Laboratory University of California --------------------------- Newsgroups: comp.os.vxworks Subject: How to install a digital to analog board for a sun1e target? Date: 5 Apr 1994 23:19:06 GMT From: letchu@zoe.as.utexas.edu (Lakshmanan Narayanan) Organization: University of Texas, McDonald Observatory Message-ID: <2nsrla$lkm@geraldo.cc.utexas.edu> I am using a sun1e target and my host is Sun4. Presently I'm trying to install a digital to analog board (DVME-622) which is factory configured for A24/D16 address space. The base address on this board is $fc0100. I tried to configure this board for the VME A24/D16 address space defined in the memDesc.c file, but am having difficulty in accessing the registers on the board. Whenever I tried doing a memory dump on the registers on this board I get a "Data Access Exception" error from vxworks. The size of the board is 256 bytes. If anyone has experienced a similar problem or have any suggestions regarding this problem, your help would be much appreciated. Thanks. Lakshmanan Narayanan (letchu@seuss.cc.utexas.edu) University of Texas at Austin Department of Astronomy --------------------------- Newsgroups: comp.os.vxworks Subject: References Date: Mon, 4 Apr 1994 16:44:52 GMT From: dowlati@claude.ma30.bull.com (Saadat Dowlati) Organization: Bull HN Information Systems Inc. Message-ID: <1994Apr4.164452.23292@claude.ma30.bull.com> Sender: news@claude.ma30.bull.com (Network News) I would appreciate any pointers to papers/books on VxWorks. - -- Thanks, - -- Saadat Dowlati Affiliation: Zenith Data Systems, Groupe Bull Voice: (508) 294-3426 Technology Park, MA02-400S Fax: (508) 294-3054 Billerica, Massachusetts 01821-4199 E-mail: S.Dowlati@bull.com --------------------------- Newsgroups: comp.os.vxworks Subject: Naming System Objects Date: 5 Apr 1994 23:33:07 -0400 From: alexm@shakespeare.gsfc.nasa.gov (Alex Measday) Organization: NASA Goddard Space Flight Center Message-ID: <2ntahj$2hm@shakespeare.gsfc.nasa.gov> In a number of library functions I have written, I make use of "named" system objects (e.g., semaphores): the object's name is stored in the system symbol table with its value being the object's ID (or a suitable handle). Different tasks can then access the object by name. When an object is first referenced by a task, the library function must determine if the object already exists (i.e., is in the symbol table). If so, the function simply returns the handle retrieved from the symbol table. If the object doesn't exist yet, the function must create the object and enter its name-handle mapping in the symbol table. Because creating the object and entering its name in the symbol table are two separate operations, there is a problem with multiple tasks trying to simultaneously create an object. I describe my single-CPU approach below, but I'm wondering (1) if there are better ways of doing this, and (2) how do I handle it in a multi-processing configuration using VxMP? Using the example of a named semaphore, my code would do the following (in PDL): CALL taskLock() to lock the processor. Lookup the semaphore's name in the system symbol table. IF found THEN The name's value is the semaphore ID. ELSE Create a new semaphore. Store its name and ID in the system symbol table. ENDIF CALL taskUnlock() to unlock the processor. My real code is somewhat more complicated, but follows the basic outline. For instance, my implementation of event flags allocates a memory structure which contains two semaphore IDs (an update semaphore and a wait-for-change semaphore) and a reference counter (so I know when to finally delete an event flag cluster). The task locking approach works on a single CPU. The code is conditionally compiled so that, under VxMP (which we will be getting), the shared memory versions of the memory allocation, semaphore creation, and symbol table functions are used. However, locking a single CPU won't work in a multi-CPU setup. Any ideas? Thanks Alex Measday Integral Systems, Inc. alexm@milton.gsfc.nasa.gov - -- Alex Measday Integral Systems, Inc. alexm@milton.gsfc.nasa.gov --------------------------- End of New-News digest ********************** From rmk@ssd.ray.com Wed Apr 6 05:46:55 1994 From: Kulakowski Date: Wed Apr 6 05:47:02 PDT 1994 Subject: D/A Needed HELP! I'm looking for a D/A module, hopefully with vxWorks support, with the following characteristics: * At least 260kHz sample clock * Preferably at least 8 channels per module (we need 24 total) * Either DMA or fifo per channel (This is the hardest requirement!) * 12 bit samples or better. * Analog output going right into a big amp so drive less important Any pointers to just vendors are appreciated but if you've used them and can give experience data, better yet. Thanks in advance! Rich ---------------------------------------------------------------------- * Rich Kulakowski * Raytheon ED, Portsmouth Facility * * * 1847 West Main Road, Mail Stop 177 * * rmk@ssd.ray.com * Portsmouth, RI 02871-1087 * * * (401) 842-4210 * ---------------------------------------------------------------------- From LAHTINEN@tsl.uu.se Wed Apr 6 07:39:43 1994 From: LAHTINEN@tsl.uu.se Date: Wed Apr 6 07:39:55 PDT 1994 Subject: Thanks I want to thank Victor Potter, John Carroll and Michael Hanson for their advice about how to configure VxWorks boot PROMs on an MVME167. Now we are booting VxWorks from the second bank of sockets and having 167-Bug PROMs on the original sockets. Best regards, Mikko Lahtinen The Svedberg Laboratory Uppsala Sweden From howard@sidney.nosc.mil Wed Apr 6 07:46:55 1994 From: howard@sidney.nosc.mil (Mike Howard) Date: Wed Apr 6 07:47:05 PDT 1994 Subject: FDDI Driver The project I am working on uses a FDDI ring for broadcast data transmission from the sensor terminus to several processing sub-systems. I currently have this up and working with a Force 30 CPU (68030), an Interphase 4211 FDDI board, vxWorks 5.0.2b and the AP Labs FDDI driver ver 1.4. However, we are switching over to vxWorks 5.1.1 and a Synergy SV400 CPU (68040). I have source for the FDDI driver and have hacked at it to get it to compile for 5.1.1 but still am not able to get it working properly (hangs in the ifAddrSet call). Before I expend more time time on this, does anyone know if there is an updated driver for the 4211 FDDI and vxWorks 5.1.X already in existance?? Thanks in advance __ __ __ / \/ \/ \ o /_ /^\ / / / / /__) __ / / / / / / / \ /__) /---/ / / /__/\__/ /___\___ / / o ------------------------------------------------------------------ | ^ ^ | G. "Mike" Howard (o) (o) You want it WHEN???? | NRad Code 714 - ^ - | Rm 234, Bldg 106, Bayside \ O / | (619) 553-1524 - | e-mail howard@sidney.nosc.mil | ------------------------------------------------------------------ From prb@aplexus.jhuapl.edu Wed Apr 6 08:30:31 1994 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Wed Apr 6 08:30:40 PDT 1994 Subject: Re: FDDI Driver Mike Howard writes: > > The project I am working on uses a FDDI ring for broadcast data transmission from the sensor terminus to several processing sub-systems. I currently have this up and working with a Force 30 CPU (68030), an Interphase 4211 FDDI board, vxWorks 5.0.2b and the AP Labs FDDI driver ver 1.4. However, we are switching over to vxWorks 5.1.1 and a Synergy SV400 CPU (68040). I have source for the FDDI driver and have hacked at it to get it to compile for 5.1.1 but still am not able to get it working properly (hangs in the ifAddrSet call). Before I expend more time time on this, does anyone know if there is an updated driver for the 4211 FDDI and vxWorks 5.1.X already in existance?? > I will be looking for an FDDI board in the near future. One requirement is that there is a driver available that is compatible with 5.1.1. So, any information about the interphase board or other vendor's boards would be appreciated. Thanks, +====================================================================+ | __ ____ __ __ | | /\ \ / \ \ /\_\__ /\ \ Johns Hopkins University | | / \_\ | /\ \ \ / / /\_\\ \ \ Applied Physics Lab. | | / /\ | |\ \/ \ \ / / / / / \ \ \ | | / \/ |_| \ /\ \_\ / / / / / \ \ \ Paul R. Bade | | / /\__/_/ \ \ \/_// / / / / / / / (301)-953-6000 x8681 | | / / / \ \_\ \ \/ / / / / / prb@aplexus.jhuapl.edu | | \/_/ \/_/ \__/_/ \/_/ | | __ ____ __ __ | | /\ \ / \ \ /\ \ /\ \ | | / \_\ | /\ \ \ / \_\ / \ \ | | / /\ | |\ \/ \ \ / /\ |_| / /\ \ \ | | / \/ |_| \ /\ \_\ / / / | | \/ / \ \ | | / /\ / / \ \ \/_// / / / / / /\ \_\ | | \ \/ / / \ \_\ \ \/ / / \/ / / / | | \__/_/ \/_/ \__/_/ /_/_/ | | | +====================================================================+ From dwampl@atl.com Wed Apr 6 09:45:58 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Wed Apr 6 09:46:11 PDT 1994 Subject: Re: WindC++ version of VxGDB on i960 does not work I have not encountered this problem with WindC++ for the 68K. My naive first guess would be that the "coff" format has something to do with it. A few other tidbits to keep in mind: Make sure that you specify the directory where the sources are located (with the "directory name") command. Also, I recall circumstances where there was confusion between the real source file name and the intermediate C file generated by CenterLine's CC. The latter is usually in a tmp directory and has a name w/ the process ID embedded in it. However, normally, the correct C++ file is referenced. (It's been a while since this happened; it may have even occurred will trying to use a generic gdb built from the "net", rather than vxgdb....) Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "We begin bombing in five minutes...." 7:^] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From @sequent.kiae.su,@avdsys.uucp:avd@avdsys.msk.su Wed Apr 6 12:00:49 1994 From: Alexey V. Demyanov Date: Wed Apr 6 12:00:58 PDT 1994 Subject: Hello from Russia Hi I'm VxWorks distributor in Russia. I'm going to build VxWorks Users Group in Russia. Could somebody tell me about how this UG should be arranged and how it is functioning. Thanks in advance Alexey From mea@mclean.sparta.com Wed Apr 6 13:01:59 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Wed Apr 6 13:02:08 PDT 1994 Subject: Re: FDDI Driver Greetings! > Submitted-by: howard@sidney.nosc.mil (Mike Howard) > > The project I am working on uses a FDDI ring for broadcast data >transmission from the sensor terminus to several processing >sub-systems. I currently have this up and working with a Force 30 CPU >(68030), an Interphase 4211 FDDI board, vxWorks 5.0.2b and the AP Labs >FDDI driver ver 1.4. However, we are switching over to vxWorks 5.1.1 >and a Synergy SV400 CPU (68040). I have source for the FDDI driver and >have hacked at it to get it to compile for 5.1.1 but still am not able >to get it working properly (hangs in the ifAddrSet call). Before I >expend more time time on this, does anyone know if there is an updated >driver for the 4211 FDDI and vxWorks 5.1.X already in existance?? > SPARTA has a driver for the 4211/5211 that works with both 5.0.X and 5.1.X. SPARC, 68K and i960 processor flavors are supported. For the 5211, BLT, MBLT and VME64 modes of transfer are supported. There is a charge for the driver but it's CHEAP (we opted for the turbo Pascal pricing model). We're sustaining ~3 MBytes/sec blaster/blastee transfers using a Heurikon HKV4D (33 MHz 68040) and the 5211. We also take Mastercard and Visa :-). Regards and sorry for the sales pitch, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From daemon@vxw.ee.lbl.gov Thu Apr 7 04:00:27 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 7 04:00:41 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 7 04:00:17 PDT 1994 Subject: Puzzling Priorities Subject: EPICS drivers for CAN Subject: vxWorks and mice? Subject: VxWorks rshd? Subject: Re: Setting the MVME167 clock chip? Subject: A token based protocol for VxWorks ??? Subject: Invisible Memory! ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Puzzling Priorities Date: Wed, 6 Apr 1994 14:04:36 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: BNR Inc., RTP, NC Message-ID: References: <1994Apr4.164452.23292@claude.ma30.bull.com> Sender: billag@b4pphff (Bill Gutknecht) I've been working two projects, but they seem to have the same problem. 1) a low level TCP/IP server app. 2) a RPC based server app. In case (1) I must run the task at a priority of 2 to get any response to it. In case (2), I must kill the portmapper and run at priority 2 (its default is 100). This seems odd to me since all of the other tasks are just hanging out and doing nothing. I'd think that higher priorities should work. For the most part, I've been using vxWorks as a weird/wonderful type of Unix ... but now, I think, I am bitten by the RTOS aspects. Any insights as to why I must run these tasks at such a high priority? I use pri=2 because that's what telnetd and rlogind are (and are similar in function) I'd think that if WR sets the portmapper to pri=100, it should work there ... BTW ... In these cases, the applications are running by themselves. (ie. nothing else loaded cept the OS). vvWorks 5.1.1, MVME162-13. Thanx. - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will BNR/Northern Telecom ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.realtime,comp.os.vxworks,comp.arch.bus.vmebus Subject: EPICS drivers for CAN Date: Wed, 6 Apr 1994 15:42:21 GMT From: mpuig@iac.es (Martm Pi ) Organization: Instituto de Astrofmsica de Canarias Keywords: EPICS,CAN,VxWorks,VME Message-ID: Hi all, At IAC we are experimenting using CANbus systems in telescope control applications. Currently we have a PC-CAN node in the system but we are looking for CAN/VME cards with EPICS drivers (running with VxWorks). Somebody know if exist EPICS drivers for CAN, RS-232 and TCP/IP ? Thanks in advance, Martm - -------------------------------------------------------------------------- MARTI PI i PUIG, Software Engineering Department Instituto de Astrofisica de Canarias (IAC) c/ Via Lactea s/n Phone: +34-22-605-355 38200 La Laguna (Tenerife) Fax: +34-22-605-210 Canary Islands. SPAIN Email: mpuig@iac.es --------------------------- Newsgroups: comp.os.vxworks Subject: vxWorks and mice? Date: 6 Apr 1994 18:10:58 GMT From: cro@pathos.caltech.edu (John Cromer) Organization: California Institute of Technology, Pasadena Keywords: mouse Message-ID: <2nutvi$c2b@gap.cco.caltech.edu> Greetings vxworkers. Does anyone know of any mouse-support functions available for VxWorks -- either for a serial mouse (Motorola or Heurikon CPU serial ports) or special boards with custom mouse input? Email or net pointers appreciated. John --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks rshd? Date: 6 Apr 1994 18:45:51 GMT From: mmccrore@tpd.dsccc.com (Martin McCrorey) Organization: DSC Communications Corporation, Plano, Texas USA Message-ID: <2nv00v$6fq@tpd.dsccc.com> Thanks for all the suggestions. The popen() idea looked like the best bet, since I was trying to avoid adding to or changing the production software load (e.g., adding vxrshd), so I started with that idea. I ended up opening a pair of pipes, forking, duping the pipes to the stdin and stdout of the child and using execl() to rlogin. Then I wrote a state machine in the parent process to interact with the vxWorks target (via the pipes) and set up my RPC server. Works great, and I got to learn some basic Unix IPC stuff that I needed to know anyway. - --Martin McCrorey --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Setting the MVME167 clock chip? Date: Wed, 6 Apr 1994 22:59:05 GMT From: winans@xray.aps.anl.gov (John R. Winans) Organization: Argonne National Laboratory, Chicago Illinois Message-ID: References: Sender: usenet@mcs.anl.gov In article curry@tc.fluke.COM (John Curry) writes: >Before getting too deep into the documentation, does anyone out there >have any information on setting and retrieving the time of day from the >MVME167 clock chip? What I looking for is some way to maintain the >time between VxWorks boots without having to access a host computer. It is well shown on page 1-32 of the mv167 'grey book' named "Single Board Computers Programmer's Reference Guide." FFFC1FF0 8080 8080 8080 803D 0014 5517 0406 0494 .......=..U..... | | | | | | | | CONTROL ---------------| | | | | | | | SECONDS -----------------+ | | | | | | MINUTES --------------------+ | | | | | HOURS ----------------------+ | | | | DAY -------------------------+ | | | DATE ---------------------------+ | | MONTH ------------------------------+ | YEAR --------------------------------+ The control bits are discussed there as well, but all you wanna do is read it, here is all you probably need. - --John - -- ! John Winans Advanced Photon Source (Controls) ! ! winans@phebos.aps.anl.gov Argonne National Laboratory, Illinois ! ! ! !"The large print giveth, and the small print taketh away." - Tom Waits ! --------------------------- Newsgroups: comp.os.vxworks Subject: A token based protocol for VxWorks ??? Date: 7 Apr 1994 01:42:38 GMT From: segrest@bobseg.enet.dec.com () Organization: Me and only Me Message-ID: <2nvoee$hf7@sousa.ako.dec.com> Reply-To: segrest@bobseg.enet.dec.com () Greetings, Does anyone know of a token oriented network interface that has been developed for VxWorks? A client of mine needs to use a unique hardware interface and is looking for a way to interface the IP+ICMP layer in the VxWorks stack to his hardware. The hardware attaches to a bus type architecture that does not have any form of collision detection. As a result we are looking for a token oriented solution. My hope is that someone else might have implemented a token oriented interface and would be willing to make the source code available for a reasonable fee. - -- Bob Segrest --------------------------- Newsgroups: comp.os.vxworks Subject: Invisible Memory! Date: Thu, 7 Apr 1994 10:04:21 GMT From: ebg@hoshi.hip.atr.co.jp (Ed Gamble) Organization: ATR Human Information Processing Research Labs., Japan Message-ID: Sender: news@hip.atr.co.jp (USENET News System) Well not quite invisible... but inaccessible. We've got a problem with vxWorks 5.1 interboard memory access: given a 16Mb MVME 167 (board 'A') and a 16Mb MVME 167 (board 'B'), board A can only access the lower 8 Mb of board B and visa-versa. Both boards boot successfully over the shared memory network from an 8 Mb MVME 147 in slot 0. I'm sure this is really simple... It is only the upper 8 Meg that can't be accessed (with vxMemProbe() or d() for example) from another board. Below is our sysProcNumSet(). VMECHIP2_VSAR1, VMECHIP2_VSATR1 and VMECHIP2_VSAMSR seem to be set correctly? We have also modified (and examined) sysPhysMemDesc; the non-local addresses and sizes seem correct and are consistent/identical accross boards. We have not modified sysHwInit() or sysHwInit2(). Presumably unrelated - we have also modified sysBusToLocalAdrs() and sysLocalToBusAdrs() to do things more reasonably with a boards' own VME address. The config.h variable LOCAL_MEM_BUS_A24 is ignored (since 16Meg is not in A24 space) and has a value unrelated to 16Meg. Our sysHwConfigShow() routine illustrates our configuration. We've presented this problem to support@wrs.com with no results; presumably the problem it is either too trivial or too difficult? void sysProcNumSet (int procNum) { int memsize; sysProcNum = procNum; memsize = (4 << (*MEMC_MCR & 0x07)); /* Value agrees with below */ { /* Megabytes */ int its_mem_base = ITS_MEMORY_ADRS; int its_mem_top = ITS_MEMORY_ADRS + ITS_MEMORY_SIZE - 1; /* 64k Blocks */ int its_mem_base_block = 0x0000ffff & (its_mem_base >> 16); int its_mem_top_block = 0x0000ffff & (its_mem_top >> 16); *VMECHIP2_VSAR1 = (its_mem_top_block << 16) | its_mem_base_block; *VMECHIP2_VSATR1 = its_mem_base_block; } *VMECHIP2_VSAMSR |= (VSAMSR1_SNP_WSD | VSAMSR1_WP | VSAMSR1_SUP | VSAMSR1_USR | VSAMSR1_A32 | VSAMSR1_D64 | VSAMSR1_BLK | VSAMSR1_PGM | VSAMSR1_DAT); /* all but A24 */ if (sysProcNum < 15) { memsize = *VMECHIP2_LBTVCR; memsize &= ~(0xfff00000); /* clear bits */ *VMECHIP2_LBTVCR = (memsize | (sysProcNum << 20) | (GCSR_GROUP_ADDR << 24)); } } AAAA > sysHwConfigShow () Processor 1 Hardware Configuration Model : Motorola MVME167 CPU Speed (MHz) : 33 Local Memory Address : 0x00000000 /* 0 always */ Memory Size : 0x01000000 /* sysMemTop() */ VME Memory Start : 0x02800000 /* ITS_MEMORY_ADRS */ VME Memory End (+ 1) : 0x03800000 /* ITS_MEMORY_SIZE */ Hardware Registers VME Chip2 VSAR1 : 0x037f0280 /* Read from VMECHIP2_VSAR1 */ VME Chip2 VSATR1 : 0x00000280 /* Read from VMECHIP2_VSATR1*/ Other ITS Processors : Start Size 0 : 0x02000000 0x00800000 /* Used in ... */ 1 (A) : 0x02800000 0x01000000 /* ... sysPhysMemDesc */ 2 (B) : 0x03800000 0x01000000 BBBB > sysHwConfigShow () Processor 2 Hardware Configuration Model : Motorola MVME167 CPU Speed (MHz) : 33 Local Memory Address : 0x00000000 Memory Size : 0x01000000 VME Memory Start : 0x03800000 VME Memory End (+ 1) : 0x04800000 Hardware Registers (read) VME Chip2 VSAR1 : 0x047f0380 VME Chip2 VSATR1 : 0x00000380 Other ITS Processors : Start Size 0 : 0x02000000 0x00800000 1 (A) : 0x02800000 0x01000000 2 (B) : 0x03800000 0x01000000 0 > sysHwConfigShow () Processor 0 Hardware Configuration Model : Motorola MVME147 CPU Speed (MHz) : 0 Local Memory Address : 0x00000000 Memory Size : 0x00800000 VME Memory Start : 0x02000000 VME Memory End (+ 1) : 0x02800000 Other ITS Processors : Start Size 0 : 0x02000000 0x00800000 1 (A) : 0x02800000 0x01000000 2 (B) : 0x03800000 0x01000000 - -- Ed Ed Gamble Invited Researcher ATR Human Information Processing Research Laboratory Phone: +81-7749-5-1036 2-2 Hikari-dai, Seika-cho, Soraku-gun Fax: +81-7749-5-1008 Kyoto 619-02 JAPAN Email: ebg@hip.atr.co.jp --------------------------- End of New-News digest ********************** From rab@csg.lbl.gov Thu Apr 7 09:16:53 1994 From: rab@csg.lbl.gov (Robert Belshe) Date: Thu Apr 7 09:17:01 PDT 1994 Subject: Re: FDDI Driver We are also planning to use FDDI soon. We are using vxWorks 5.1 and will use a MVME166 processor for the FDDI. In this application, data will be sent from the VME data acquisition system ( via UDP multicast, if possible) to a small number of sparcStations located nearby. We have identified 3 possibilities at this point: AP Labs 5.1 driver with Interphase 5211 Radstone Technology 5.1 driver with PME FDDI-1 Ross Microsystem driver with Rockwell CMC1156 Any information or suggestions on these or other solutions would be greatly appreciated. Thanks, Bob +----------------------------------------------------------+ | Robert Belshe rab@lbl.gov | | 50B-4235 Voice 510-486-7509 | | Lawrence Berkeley Laboratory FAX 510-486-5977 | | Berkely, CA 94720 | +----------------------------------------------------------+ From daemon@vxw.ee.lbl.gov Fri Apr 8 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 8 04:00:34 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 8 04:00:13 PDT 1994 Subject: X input extension Subject: Final answer on copyback memPartFree problem Subject: Re: Slow backplane net in vxWorks 5.0.2b Subject: Re: booting vxWorks V5.1.1 from backplane network Subject: Re: fork/exec/wait in VxWorks Subject: MVME167 Clone ? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: X input extension Date: 7 Apr 1994 11:59:18 GMT From: hcl@vmsfo.vingmed.no (Hans Chr. Loenstad) Organization: VINGMED SOUND A/S Keywords: X11 Message-ID: <2o0sim$iea@vmsfo.lys.vingmed.no> Reply-To: hcl@vingmed.no Sender: hcl@vmsfo (Hans Chr. Loenstad) Has anyone ported the X11R5 input extension client side library to vxworks? Regards --------------------------- Newsgroups: comp.os.vxworks Subject: Final answer on copyback memPartFree problem Date: Thu, 7 Apr 1994 17:37:51 GMT From: georg@sgl.ists.ca (Georg Feil) Organization: Institute for Space and Terrestrial Science Keywords: bug bug bug Message-ID: Sender: news@newshub.ists.ca Well, I think we now know everything there is to know about the memPartFree() problem we were having. The original subject here was "memPartFree error with copyback caching enabled (167)". Other past subjects that possibly related to the same problem include "Large disk writes w/cache cause MVME167 to freeze". Apparently the root cause is a snooping problem related to TAS on the VME bus, and is Motorola's fault. The solution to the problem is the "MV167 VME TAS patch" from Wind River. It consists of a number of configuration changes (config.h, usrConfig.c etc.) and is reproduced below. Strangely, it has not been assigned an SPR number because, according to Wind River, the new version of the 167 BSP has fixed the problem so no SPR is necessary(?). This situation may have changed since the memos I received were written. Our related TSR number was 16443, which may help others to track things down. I had already come up with my own patch that worked in a completely different (and very specific) way, and the WRS patch seemed not to apply to our problem. However I tested the patch anyway and sure enough it fixes our problem. As a bonus, SCSI performance seems to have improved slightly. This whole affair stinks as far as I'm concerned. I wish Wind River had been much more specific about who could be affected by this bug (i.e. potentially anybody doing SCSI I/O on a 162 or 167) and had publicized the problem and the patch at a much higher priority. Although the bug stems from a hardware problem, the bottom line is VxWorks doesn't work without the patch. Thanks to Jerald Pendleton at Wind River and Margaret Votava at Fermilab. Georg. - --------------------------- MV162/167 VME TAS patch ------------------------ ] Date: 03-02-1994 ] Submitted by: Vinai Kolli ] ] ] Sub: Configuration changes ] which provide workaround for the ] back plane problem for the motorolla mvme162. ] ----------------------------------------------------------------------------- ] ] Due to snoop problems with the Test And Set (TAS) command from the ] VMEbus the following modifications are necessary until the TAS ] command can be snooped from the VMEbus. The shared memory pool ] will be defined in low memory, and will be marked as non-cacheable ] by the local processor. The VMEchip will have the snoop control ] bits turned off. This will not effect the cache and snooping for ] the on-board devices such as ethernet and SCSI, as snooping will ] still be turned on for those devices. ] The size of the memory required for the shared memory should be a multiple ] of 8k which is the default page size for the mmu. ] Any interprocessor communication which is done through a shared memory ] should make sure that the cache is disabled for that shared memory location. ] These changes would be in effect until motorolla fixes the snooping ] problems. The following changes apply to mvme162 and mvme167 ] ] File Changes ] ------------------------------------------------------------------------------ ] config.h define RAM_LOW_ADRS as 0x20000 ] define SM_MEM_SIZE as 0xe000 (64k -8k) ] define SM_OBJ_MEM_SIZE as 0x10000 (64k) ] define SM_MEM_ADRS as ] RAM_LOW_ADRS - (SM_MEM_SIZE + SM_OBJ_MEM_SIZE) ] define SM_OBJ_MEM_ADRS as ] RAM_LOW_ADRS - SM_OBJ_MEM_SIZE ] Specifically to mvme167 the macro ] USER_D_CACHE_MODE should be defined as ] (CACHE_COPYBACK | CACHE_SNOOP_ENABLE) ] ] MakeSkel change RAM_LOW_ADRS to 0x20000 ] ] sysLib.c In the function sysHwInit2() add a function code ] shown below to the end of the function which disables ] the cache for the pages dedicated to the shared ] memory. ] ] void sysHwInit2 (void) ] { ] ] .... ] .... ] .... ] ] #ifdef INCLUDE_MMU_BASIC ] (void) vmBaseStateSet (NULL, (void *)SM_MEM_ADRS, ] SM_MEM_SIZE + SM_OBJ_MEM_SIZE, ] VM_STATE_MASK_CACHEABLE, ] VM_STATE_CACHEABLE_NOT); ] #endif /* INCLUDE_MMU_BASIC */ ] ] #ifdef INCLUDE_MMU_FULL /* unbundled mmu product */ ] (void) vmStateSet (NULL, (void *)SM_MEM_ADRS, ] SM_MEM_SIZE + SM_OBJ_MEM_SIZE, ] VM_STATE_MASK_CACHEABLE, ] VM_STATE_CACHEABLE_NOT); ] #endif /* INCLUDE_MMU_FULL */ ] } ] ] sysLib.c In the function sysProcNumSet() inhibit the snooping ] by programming the snoop bits in the vmechip2 as ] shown below ] change the following Macros ] from to ] ----------------------------------------------- ] (write sink data) (snoop inhibit) ] VSAMSR2_SNP_WSD VSAMSR2_SNP_INHIBIT ] VSAMSR1_SNP_WSD VSAMSR1_SNP_INHIBIT ] ] ] - -- Georg Feil Space Geodynamics Laboratory | Internet: georg@sgl.ists.ca Institute for Space and Terrestrial Science | Phone: (416) 665-5458 4850 Keele St./North York/Ont/Canada/M3J 3K1 | Fax: (416) 665-1815 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Slow backplane net in vxWorks 5.0.2b Date: 7 Apr 1994 23:39:40 GMT From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae) Organization: Silicon Graphics, Inc., Mountain View, CA Message-ID: <2o25js$l9h@fido.asd.sgi.com> References: <01HAMP4HXGPCI2IK63@yalph2.physics.yale.edu> In article <01HAMP4HXGPCI2IK63@yalph2.physics.yale.edu>, wrote: >We have a backplane network under vxWorks 5.0.2b that includes 10 processors >(4 Matrix MD-CPU338's and 6 GMS v49's). The master processor has 512k >allocated for the shared memory, and all processors ar using mailbox >interrupts. Due to a bug with the Matrix CPU's, we are forced to use the >software TAS. > software TAS is a very slow mechanism (it is a dumb spin-lock). it's unfortunate that both the old and new BP drivers in vxworks use TAS at all. one way to make things go much faster would be to eliminate any need for TAS. a pair of simple shared, half-duplex message queue with a set of pointers can be used to construct such a device driver. this will work well even on CPU's that have problems supporting RMW cycle in hardware. another area that can be improved is eliminating unnecessary copies (this is not the cause of your performance problem). both the old and new BP drivers copy the data from sender to the receiver, while reception code is optimized to avoid copying when possible. when i last optimized the old BP driver, i did the reception side copy-avoidance, which helped a lot, but i didn't do the same for the sender side, because it required a significant rewrite. considering that WRS has recently re-written the BP driver (SM driver), it's surprising that they did not do this work to help the performance. hwajin PEACEFUL STAR --------------------------- Newsgroups: comp.os.vxworks Subject: Re: booting vxWorks V5.1.1 from backplane network Date: 7 Apr 1994 23:44:01 GMT From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae) Organization: Silicon Graphics, Inc., Mountain View, CA Keywords: backplane network Message-ID: <2o25s1$lgr@fido.asd.sgi.com> References: <1994Apr1.015734.20073@neopath.wa.com> In article <1994Apr1.015734.20073@neopath.wa.com>, Rick Bauer wrote: > > Error loading file: errno = 0xd > Can't load boot file!! > > If we query the backplane network, smNetShow, after the MVME162 >boot fails, the report inidicates that only CPU 0 is attached to sm0. >This seems to contradict the boot messages from the MVME162 indicating >that the CPU succesfully attached to both sm0 and lo0. > i'll make an obvious suggestion: in situations like this, it helps to bring up two boards independently (i.e. boot each one over ethernet or by some other means) and initialize the BP network interface by hand, verifying step by step what occurs. once you get the BP network to communicate properly this way, you can attempt to boot. you can set breakpoints in the code, examine BP memory pool for heartbeat, excercise various functionalities to get confidence before you attempt the boot up sequence. trying to debug when booting process fails is hard; you have no resort. hwajin PEACEFUL STAR --------------------------- Newsgroups: comp.os.vxworks Subject: Re: fork/exec/wait in VxWorks Date: 7 Apr 1994 23:56:39 GMT From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae) Organization: Silicon Graphics, Inc., Mountain View, CA Message-ID: <2o26jn$lsn@fido.asd.sgi.com> References: In article , Eric Peterson wrote: > Is there an easy (or at least straightforward) method for emulating the > Unix fork/exec/wait tasking primitives in VxWorks? I'm doing some > porting of some Unix apps, and I would think that this pops up quite > often (I searched the FAQ without luck). Also, is the SIGCHLD signal > really implemented to be generated upon (sub)-task exit, or is it just > there to make things compile :-)? The man pages aren't too clear on > signal behavior. as far as i know this is not easy in vxworks. there is no resource management or reclamation per task in vxworks tasking model. implementing this correctly will require a significant rewrite, or addtion of code, or uglification. i believe SIGCHLD does not work, based on my experiences on vxworks 5.0 (last one i've worked on years ago), there is no parent/child relationship between tasks. nor is there group/session, nor is there inheritable resources (such as descriptors), etc. vxworks indeed is very different from UNIX... although i've heard that WRS is working on POSIX compatibility issues. hwajin PEACEFUL STAR --------------------------- Newsgroups: comp.realtime,comp.os.vxworks,comp.os.lynx,comp.sys.m68k Subject: MVME167 Clone ? Date: Thu, 7 Apr 1994 21:39:41 GMT From: mmourier@atmsys.com (Marcelo C Mourier) Organization: AMP/ATM Systems Inc. Message-ID: Followup-To: comp.realtime Reply-To: mmourier@atmsys.com Sender: news@isthmus.atmsys.com I just found out the price of the MVME167-002A boards... :-( Does anybody know of another board with similar characteristics? I don't even need all the features of the MVME167... Specifically, I'm looking for a board with a 68LC040 @ 25MHz, 8MB RAM, EPROM, UART, timer, and Ethernet. Ideally, the UART and Ethernet would be the same type used in the MVME167. I don't need SCSI and don't need VME either... :-) Any help will be greatly appreciated! +---------------------------------+-----------------------------------------+ | Marcelo Mourier | | | ATM Systems | (this space intentionally left blank) | | A division of Connectware, Inc. | | | mmourier@atmsys.com | | +---------------------------------+-----------------------------------------+ --------------------------- End of New-News digest ********************** From ddavies@sim.es.com Fri Apr 8 07:51:12 1994 From: ddavies@sim.es.com (Doug Davies) Date: Fri Apr 8 07:51:25 PDT 1994 Subject: Re: comp.os.vxworks newsdigest > Marcelo Mourier writes: > > I just found out the price of the MVME167-002A boards... :-( > > Does anybody know of another board with similar characteristics? I don't > even need all the features of the MVME167... Specifically, I'm looking for > a board with a 68LC040 @ 25MHz, 8MB RAM, EPROM, UART, timer, and Ethernet. > Ideally, the UART and Ethernet would be the same type used in the MVME167. > I don't need SCSI and don't need VME either... :-) Take a look at the Motorola MVME162. It has the features that you are after at a significantly lower cost. We've used it and are quite pleased. It is closely compatible with the MVME167. Good luck. -Doug -------------------------------------------------------------------------------- Douglas Davies (software engineer) | Evans & Sutherland | "Never underpay your software engineers" INTERNET: ddavies@jaba.sim.es.com | -Jurassic Park Moral From daemon@vxw.ee.lbl.gov Sat Apr 9 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 9 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 9 04:00:13 PDT 1994 Subject: ld error Subject: Motorola 162 with Octal 422 IP Subject: Ethernet network lockout during application execution Subject: h Subject: VxWorks memory/rom requirements ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: ld error Date: Fri, 8 Apr 1994 14:05:12 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: BNR Inc., RTP, NC Message-ID: Sender: billag@b4pphff (Bill Gutknecht) - -> ld < coatd value = 3782388 = 0x39b6f4 - -> perror S_objLib_OBJ_ID_ERROR value = 22 = 0x16 - -> This seemed to show up when I added an additional procedure to the object module. I'm at a loss as to what is really the problem (and I don't want to take the procedure back out.) Can someone give me some insight on how to figure out what this really means? Thanks. [vxWorks5.1.1 MVME162-13] - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will BNR/Northern Telecom ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: Motorola 162 with Octal 422 IP Date: Thu, 7 Apr 1994 17:52:15 GMT From: davel@fairmpc.fairfld.mcd.mot.com (David Lowery) Organization: Motorola Computer Group, Fairfield Sales Office Message-ID: <1994Apr7.175215.3211@phx.mcd.mot.com> Sender: davel@fairmpc (David Lowery) I have a customer who is having some problems using the Greensprings Octal 422 IP on our 162. Has anyone out there had any experience with this IP using the VxWorks drivers? Octal 232 seems to work ok. Any info would be appreciated. Thanks, Dave - -- [ David W. Lowery Voice: 201-808-2436 ] [ Motorola Computer Group Fax : 201-808-0359 ] [ 100 Passaic Ave. Pager: 1-800-SKY-PAGE Pin#: 8551615 ] [ Fairfield, NJ 07004 Email: davel@fairfld.mcd.mot.com ] --------------------------- Newsgroups: comp.os.vxworks Subject: Ethernet network lockout during application execution Date: Thu, 31 Mar 1994 19:30:16 GMT From: jhgriff@sed.csc.com (Jeffery H. Griffith) Organization: Computer Sciences Corporation Keywords: ethernet Message-ID: Our system is configued as follows: Heurikon hkv960d board running VxWorks 5.1.1 in a VME chassis booting over the backplane. Problem: After booting vxWorks over the VME backplane, the ethernet interface is enabled using the "if" routines. Routes are set up properly and data flows successfully through the ethernet interface, UNLESS a process on the i960 begins execution and does not block. The executing task is set at the lowest priority yet is never interrupted and the ethernet traffic completely stops. Adding taskDelay to the task does allow ethernet traffic to get through but are unacceptable for our application. It is my understanding that the low priority task should always be interrupted by the netTask. In all other instances, this task does indeed get interrupted by every other task on the system. Any suggestions? (email reply would be appreciated). Thanks, Jeffery Griffith Computer Sciences Corporation jhgriff@sed.csc.com - -- - -- Jeffery Griffith | Computer Sciences Corporation | jhgriff@sed.csc.com | --------------------------- Newsgroups: comp.os.vxworks Subject: h Date: Fri, 08 Apr 1994 22:34:05 GMT From: hschneid@gauss.cfm.udec.cl (Heinz Schneider F.) Organization: Universidad de Concepcion, Concepcion - Chile Message-ID: <1994Apr08.223405.141164@halcon.dpi.udec.cl> Sender: usenet@halcon.dpi.udec.cl gdhsdjfsduud kdfjslkduier dfklsdgs$lkdgs --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks memory/rom requirements Date: 8 Apr 94 14:56:09 From: jmorris@hot.caltech.edu (John Morris) Organization: Caltech Control Lab Message-ID: I've got a couple of questions on VxWorks memory/rom requirements: * how much RAM is necessary to support the standard development environment with backplane/serial/ethernet drivers and shared memory * how much ROM is necessary to boot VxWorks from either the backplane or serial port Thanks, John C. Morris -----|----- e-mail: jmorris@hot.caltech.edu Caltech, M/C 116-81 *>=====[_][ ) work: (818) 395-4855,3218,2179 Pasadena, CA 91125 _'_`_ FAX: (818) 795-1547 --------------------------- End of New-News digest ********************** From stan@rti.rti.com Sat Apr 9 10:45:29 1994 From: stan@rti.rti.com (Stan Schneider) Date: Sat Apr 9 10:45:39 PDT 1994 Subject: Re: Ethernet network lockout during application execution >> Date: Thu, 31 Mar 1994 19:30:16 GMT >> From: jhgriff@sed.csc.com (Jeffery H. Griffith) >> ...The executing task is set at the >> lowest priority yet is never interrupted and the ethernet traffic completely >> stops. Adding taskDelay to the task does allow ethernet traffic to get >> through but are unacceptable for our application. It is my understanding >> that the low priority task should always be interrupted by the netTask. Sounds like you're using polling communications for your backplane net. The poll task runs at the lowest priority (255); anything that uses all the CPU will lock it out, thereby never giving the tNetTask any reason to wake up. You have three choices. 1) configure your backplane to use interrupt communications (best). 2) put both tasks at the same prio & turn on time-slicing (may work, but net latency will be increased). 3) live with the taskDelays. -- 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 rdmacko@somnet.sandia.gov Mon Apr 11 08:10:50 1994 From: RD Mackoy Date: Mon Apr 11 08:10:59 PDT 1994 Subject: User Group Meeting? Hello, Have there been any plans made for the west coast user group meeting yet? Thanks, RD Mackoy rdmacko@somnet.sandia.gov Sandia National Labs 505-844-1911 PO Box 5800 505-844-4797 Albuquerque, NM 87185-0635 From GNPW81A@prodigy.com Mon Apr 11 20:53:00 1994 From: GNPW81A@prodigy.com (MR ROBERT D STEELE) Date: Mon Apr 11 20:53:09 PDT 1994 Subject: taskDelay The system I have inherited has a low priority task polling on a socket with a 0 wait. For reference this low priority task is name ui_task (user interface). There is a higher priority task which is consuming 92% of the CPU. This high priority task is name ctrl_task (control). Timing ui_task from an external bus analyzer shows that is takes as long as 700 milliseconds to complete. When I suspend ctrl_task and time ui_task it takes 0.17 milliseconds to complete. I have a lower priority task yet that is getting completely starved by the ui_task. In an attempt to get this task to have a little time to run I added a taskDelay(1) to the loop in ui_task. Not only did this low priority task get a chance to run, but the ui_task now took only 150-200 milliseconds to complete. My question is: "Why the apparent improvement in ui_task when I am running it as a periodic task running at 60 Hertz. I am using vxWorks version 5.1.1 and the system is running on a MVME 167-31A processor. The system clock is set to 60 Hertz. ctrl_task is running off of the auxillary clock and is running at 400 Hertz. If anyone has any ideas and/or need any more information to help me feel free to write or call. Robert Steele steele@telerobotics.jpl.nasa.gov (818) 354-4847 From daemon@vxw.ee.lbl.gov Tue Apr 12 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Apr 12 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 12 04:00:15 PDT 1994 Subject: ??? driver for HP VME laser interferometer boards??? Subject: Green Card Lottery- Final One? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: ??? driver for HP VME laser interferometer boards??? Date: 11 Apr 1994 18:03:37 GMT From: EJMOLER@lbl.gov (edward moler) Organization: Lawrence Berkeley Laboratory Message-ID: <2oc3dp$6it@overload.lbl.gov> Sender: eddie@ux5.lbl.gov (edward moler) Howdy. Are there any drivers out there written for the Hewlett-Packard Laser Interferometer boards for VME??? I know that HP doesn't have any. Thanks in advance, Eddie Moler Lawrence Berkeley Laboratories EJMOLER@LBL.GOV --------------------------- Newsgroups: comp.os.vxworks,maus.sys.atari.okami Subject: Green Card Lottery- Final One? Date: 12 Apr 1994 07:56:14 GMT From: nike@indirect.com (Laurence Canter) Organization: Canter & Siegel Message-ID: <2odk6u$36u@herald.indirect.com> Green Card Lottery 1994 May Be The Last One! THE DEADLINE HAS BEEN ANNOUNCED. The Green Card Lottery is a completely legal program giving away a certain annual allotment of Green Cards to persons born in certain countries. The lottery program was scheduled to continue on a permanent basis. However, recently, Senator Alan J Simpson introduced a bill into the U. S. Congress which could end any future lotteries. THE 1994 LOTTERY IS SCHEDULED TO TAKE PLACE SOON, BUT IT MAY BE THE VERY LAST ONE. PERSONS BORN IN MOST COUNTRIES QUALIFY, MANY FOR FIRST TIME. The only countries NOT qualifying are: Mexico; India; P.R. China; Taiwan, Philippines, North Korea, Canada, United Kingdom (except Northern Ireland), Jamaica, Domican Republic, El Salvador and Vietnam. Lottery registration will take place soon. 55,000 Green Cards will be given to those who register correctly. NO JOB IS REQUIRED. THERE IS A STRICT JUNE DEADLINE. THE TIME TO START IS NOW!! For FREE information via Email, send request to cslaw@indirect.com - -- ***************************************************************** Canter & Siegel, Immigration Attorneys 3333 E Camelback Road, Ste 250, Phoenix AZ 85018 USA cslaw@indirect.com telephone (602)661-3911 Fax (602) 451-7617 --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Wed Apr 13 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 13 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 13 04:00:14 PDT 1994 Subject: Any horror stories about 5.1.1 vs 5.1 Subject: Looking for Xm/Xt libraries for vxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Any horror stories about 5.1.1 vs 5.1 Date: 12 Apr 1994 15:02:55 GMT From: bt@ssec.wisc.edu (Bill Taylor) Organization: University of Wisconsin, Madison, Space Science and Engr Cntr Message-ID: <2oed6v$j0b@spool.cs.wisc.edu> I have a client who must get a fix to the ethernet driver in the Mot 167 card board support and it was combined with a 5.1 to 5.1.1 change. Should I be concerned about two changes at once to them. Time is pressing so I can not test it as long as I might like. ??????? --------------------------- Newsgroups: comp.os.vxworks Subject: Looking for Xm/Xt libraries for vxWorks Date: 12 Apr 1994 20:33:20 GMT From: ahein@bssv01.hac.com (Alan Hein) Organization: Hughes Aircraft Company Keywords: vxworks motif Message-ID: <2of0ig$3id@hacgate2.hac.com> We're developing a Motif application for use under vxWorks, and we are seeing crashes which look like they might be re-entrancy problems within Xm/Xt. We use several processes, each with their own display connection, but running at different priorities. We don't access widgets created within a process in any other process. Apparently, however, when a higher priority process activates while a lower priority process was in the middle of doing something, we sometimes crash within an Xm/Xt routine, due to corrupted data base. We began our development with Wind River's windX package, and we had good success up to the point where we just couldn't live with some of the problems in Motif 1.1. Apparently, Wind River decided to drop X/Motif as a product line, and we had to make a hasty switch to Motif 1.2.3 from another Vendor. Has anyone experienced such problems with Motif under vxworks? Were you able to work around it? Can you point me towards any vendors which supply re-entrant Xm/Xt libraries for vxWorks? (Motif 1.2.3 or later). We're also worried about memory leaks and fragmentation over long periods of use. Is anyone aware of any 3rd party memory management packages which might help us out here? Thanks! --------------------------- End of New-News digest ********************** From hebo@mbari.org Wed Apr 13 10:07:52 1994 From: Bob Herlien Date: Wed Apr 13 10:08:00 PDT 1994 Subject: Re: comp.os.vxworks newsdigest > We're developing a Motif application for use under vxWorks, and we are > seeing crashes which look like they might be re-entrancy problems within > Xm/Xt. We use several processes, each with their own display connection, > but running at different priorities. We don't access widgets created > within a process in any other process. Apparently, however, when a higher > priority process activates while a lower priority process was in the > middle of doing something, we sometimes crash within an Xm/Xt routine, due > to corrupted data base. I've never used X/Motif under VxWorks, so take this with a grain of salt (i.e., WRS may have an improved Motif). But neither Motif nor the Xt Intrinsic library is reentrant, at least in their standard Unix form. They're also synchronous -- you can't make Xt/Motif calls from within a signal handler, for example, due to lack of reentrancy. The standard answer for "how do I update my display to reflect a real-time event?" is to use a TimeOutProc or WorkProc. XtAppAddTimeOut and XtAppAddWorkProc can be called asynchronously, I believe. -------------------------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@mbari.org From sugar2!focal.com!john@netcom.com Wed Apr 13 18:09:57 1994 From: john@focal.com (John Calvin) Date: Wed Apr 13 18:10:06 PDT 1994 Subject: Remember this one? (Scripts) A while back (last August I think) there was some discussion about starting up a script file from within a program, and how to handle the standard I/O redirections. Can anyone refresh me on how this is done? I've tried the following, but its as if the redirected script file is never being run. The test script file is being accessed over NFS and is set to 777 but has'nt improved matters. Regretably with the shell gone when this is running, its a little hard to tell whats going on inside. ~Code Segment. /* open test file */ inFd1 = open ("test.vxw", READ, 0); /* * Kill the interactive shell session. * and flush any outstanding io operations */ oldShellId = taskNameToId (shellTaskName); taskDelete (oldShellId); ioctl ( STD_IN, FIOFLUSH, OPT_TERMINAL ); /* * Save old I/O pointers. */ old = ioGlobalStdGet (STD_IN); /* * Fire off a new shell, with redirected input. */ shellInit (SHELL_STACK_SIZE, FALSE); shell (FALSE) /*<- Do I need this or does shellInit do spawn the shell?*/ /* * ID the newly spawned shell, so we can direct its input. */ newShellId = taskNameToId (shellTaskName); ioTaskStdSet (newShellId, inFd1, 0); /* Specify task specific input */ /*ioGlobalStdSet (STD_IN, inFd1);*/ /* Specify global input source */ /* Neither seem to work. */ /* * Hang around untill spawned shell exits on its own. */ do { taskDelay ((sysClkRateGet ())/2); } while (IdtaskNameToId (shellTaskName) != ERROR); /* * After script processor shell ends, restart an interactive one */ shell (TRUE); ioGlobalStdSet (STD_IN, old); /* Return to old I/O paths */ close (inFd1); Any Ideas or comments would be appreciated, and would certainly save some time. The key thing here is in the redirections, as I want to modify this once it works to take input from a pipe fd, rather than a file fd. Thanks in advance. John Calvin Calvin@netcom.com --------------------------------------------------------------------------------- From daemon@vxw.ee.lbl.gov Thu Apr 14 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 14 04:00:34 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 14 04:00:14 PDT 1994 Subject: WindC++ GateWay for i960 and CenterLine S/W Products ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: WindC++ GateWay for i960 and CenterLine S/W Products Date: Wed, 13 Apr 1994 14:09:58 GMT From: ihab@bcarh52d.bnr.ca (Ihab Mahna) Organization: Bell-Northern Research, Ottawa, Canada Message-ID: <1994Apr13.140958.3561@bcarh54a.bnr.ca> Sender: ihab@bcarh52d (Ihab Mahna) Hello, I am going to install the evaluation copy of WindC++ Gateway and CenterLine software (ObjectCenter,CodeCenter, ObjectCenter). Here is My Setup:- Host : Sun sparc + Sun OS (4.1.3) Target : i960 + VxWorks 5.1.1 Currently we are using VxGDB+GNU compiler as a development environment, all our code for the target is written in C and assembly. We are thinking about switching to a more integrated development environment that works with VxWorks (As far as I know CenterLine products is the only choice). Is there any one up there has a similar setup ? Please give me your opinion about it. Regards, Ihab, Mahna Phone:(613) 765-4284 Bell-Northern Research Ltd. Fax: (613) 763-2626 Ottawa, Ontario, Canada (K1Y 4H7) Email: "ihab@bnr.ca" --------------------------- End of New-News digest ********************** From pak@rtp.co.uk Thu Apr 14 05:25:21 1994 From: pak@rtp.co.uk (Paul Keir) Date: Thu Apr 14 05:25:32 PDT 1994 Subject: Profibus Hi there, Can anyone help ? I'm trying to find out if there is any VxWorks support for Profibus. Any information regarding VxWorks drivers/boards or whatever would be useful. Thanks. Paul Keir pak@rtp.co.uk From dwampl@atl.com Thu Apr 14 09:21:28 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Thu Apr 14 09:21:46 PDT 1994 Subject: Re: Vx Exploder Digest > Subject: WindC++ GateWay for i960 and CenterLine S/W Products > ... > I am going to install the evaluation copy of WindC++ Gateway and CenterLine software (ObjectCenter,CodeCenter, ObjectCenter). > > Here is My Setup:- > > Host : Sun sparc + Sun OS (4.1.3) > Target : i960 + VxWorks 5.1.1 > ... > Is there any one up there has a similar setup ? > Please give me your opinion about it. > I am using the same setup, with the exception that we use the 68K. I use objectcenter for testing and evaluating our code on the Sun before moving it to the target. It is a wonderful environment, but it is a real resource code. Make sure that you have lots of RAM in your workstation. A relatively fast SPARC would help, too. On the Vxworks side, the full functionality of OC isn't available. You can only use their so-called "process-debugging mode" (pdm), which is basically a very- nice front end for gdb (more useful than vxgdb). It is bigger and more resource hungry than vxgdb, but is much better for complex debugging sessions, especially when you need to display complex data, such as objects. I have had occasional problems w/ OC crashing will debugging Vxworks code, and it really would be nice if all of OC's functionality could be used. Never the less, I strongly recommend it for working with WindC++. By the way, a suggestion WindC++. The "munching" of global, static objects is a pain; be sure that you not only munch your own C++ code, but also the C++ libraries, especially "iostreams". If you don't, you can't use "cout", etc. Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "I feel your pain...." =:O] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From franks@se01.wg2.waii.com Thu Apr 14 09:40:32 1994 From: franks@se01.wg2.waii.com (Jeffrey L. Franks) Date: Thu Apr 14 09:40:42 PDT 1994 Subject: Questions About Real-time C++ VxWorks Embedded Systems We are contemplating using C++ (CenterLine C++ & gcc) with VxWorks in a VME environment using 68030 or better. Our application will make heavy use of iostreams class library, NFS, sockets, etc. Are there any developers who would like to share their experiences of using C++ with VxWorks in a real-time environment? Can you brielfy describe your application(s)? What were the severe gotcha's? Have you found the CenterLine/gcc/VxWorks development environment to be stable? What's been your experience with debugging the target using Vxgdb++ and CenterLine on the target. Any gotcha's or insurmountable problems. Does the iostreams class library work as expected? What 3rd party class libraries are you using? Have you discovered any problems using 3rd party class libraries, i.e.: re-entrancy or thread-safe issues, other? Has anyone ported or used RogueWave class libraries with VxWorks? ---------------- Jeff Franks Western Geophysical Exploration Products ____ ____ ____ a division of Western Atlas International Inc. \ \ / /\ / /\ \ \/ / \ / / \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \ / / \ / /\ \ Internet : franks@wg2.waii.com \/___/ \/___/ \___\ Voice : (713) 964-6199 From westley@hercules.calspan.com Thu Apr 14 13:17:49 1994 From: westley@hercules.calspan.com (Terry J. Westley) Date: Thu Apr 14 13:18:09 PDT 1994 Subject: help wanted: floating point does not work in MVME167 Floating point does not work correctly on at least two MVME167s we have running VxWorks 5.0.2b. I haven't tested the other ones, but they are running the same kernel. The following program was compiled with the VxWorks distributed GNU C compiler as well as with the Sun/SPARC compiler: ---------------------- cut here --------------------------- #include #include main() { double a, b, c; a = -11.00557; b = 6.28319; c = fmod (a, b); printf ("%f\n", c); } ---------------------- cut here --------------------------- The results are as follows: -> ld < fmod value = 0 = 0x0 -> sp _main task spawned: id = 0xfbaaac, name = t1 value = 16493228 = 0xfbaaac -> -.155999 When run in the Sun, this program yields the following (correct) result: -4.722380 As far as I can tell from the manuals I have, the kernel was built correctly for floating point by defining the following: #define INCLUDE_MC68881 /* MC68881/2 float point co-processor */ #define INCLUDE_FLOATING_POINT /* floating point I/O */ Yes, I know that the 68040 basic floating point is built-in and the high-level operations are done in software, but the manual says to use these ifdefs. In addition, lkup confirms that "mathHardInit" is in the symbol table and "mathSoftInit" is not. Any ideas? From stan@rti.com Thu Apr 14 14:19:24 1994 From: stan@rti.com (Stan Schneider) Date: Thu Apr 14 14:19:40 PDT 1994 Subject: Re: Remember this one? (Scripts) >> Submitted-by sugar2!focal.com!john@netcom.com Wed Apr 13 18:09:57 1994 >> A while back (last August I think) there was some discussion about >> starting up a script file from within a program, and how to handle the >> standard I/O redirections. >> One way to do this is to just read the file yourself, and call "execute(line)" for each line. It's a lot easier than redirection. I.e: char line[256]; fp = fopen("test.vxw", "r"); while (fgets(line, 255, fp) != EOF) { if (execute(line) == ERROR) {barf; break;} } fclose(fp); You may want to call "shellLock" around this. >> Regretably with the shell gone when this is running, its a little hard >> to tell whats going on inside. You should take a look at "rshell", the reentrant shell program in RTILib. It lets you open multiple connections to your target. It can also execute a file of simple "shell" commands directly. Hope this helps, -- 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 ddavies@sim.es.com Thu Apr 14 14:47:45 1994 From: ddavies@sim.es.com (Doug Davies) Date: Thu Apr 14 14:48:08 PDT 1994 Subject: Re: help wanted: floating point does not work in MVME167 The "fmod" thang... > The results are as follows: > > -> ld < fmod > value = 0 = 0x0 > -> sp _main > task spawned: id = 0xfbaaac, name = t1 > value = 16493228 = 0xfbaaac > -> -.155999 > > When run in the Sun, this program yields the following (correct) result: > > -4.722380 Once again, "fmod" on 68040 base machines is broken in the 5.0.2 release of vxWorks. As many times as this has come up here recently, I think that WRS ought to alert their customers using 5.0.2 on 68040 based machines that "fmod" is broken (and also that there are other floating point problems with 5.0.2), with a general announcement. It seems to me that many vxWorks users have wasted a *LOT* of time debugging the "fmod" thang on 5.0.2. What a waste... Of course the solution is to move to 5.1.1. We are currently in the middle of that "move" which has cost us almost 3 months so far on a project that couldn't afford the delay, and we're not there yet... Anyway, as far as your floating point problem goes... don't rely on "fmod" in 5.0.2 on a 68040 based machine. -Doug -------------------------------------------------------------------------------- Douglas Davies (software engineer) | Evans & Sutherland | "Never underpay your software engineers" INTERNET: ddavies@jaba.sim.es.com | -Jurassic Park Moral From daemon@vxw.ee.lbl.gov Fri Apr 15 04:00:19 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 15 04:00:27 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 15 04:00:11 PDT 1994 Subject: Motorola MVME162 Real Time Clock and VxWorks clock Subject: Motorola/GreenSpring IEEE-488 IP driver Subject: Unloading .o files ? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Motorola MVME162 Real Time Clock and VxWorks clock Date: 14 Apr 1994 12:18 PST From: cadfael@reg.triumf.ca (MORRIS, DAVID) Organization: TRIUMF: Tri-University Meson Facility Keywords: VxWorks, Real Time Clock, MVME162 Message-ID: <14APR199412184604@reg.triumf.ca> When VxWorks boots, should it look at the Real Time Clock chip on the Motorola MVME162 and initialize the internal clock routine automatically? It does not appear to in my installation and I have not found an explanation. If anyone has the answer and a code example... Thanks! Dave Morris TRIUMF-UBC 604-222-1047 --------------------------- Newsgroups: comp.os.vxworks Subject: Motorola/GreenSpring IEEE-488 IP driver Date: 14 Apr 1994 13:14 PST From: cadfael@reg.triumf.ca (MORRIS, DAVID) Organization: TRIUMF: Tri-University Meson Facility Keywords: MVIP300, IP-488, IEEE-488 Message-ID: <14APR199413144688@reg.triumf.ca> Has anyone got a VxWorks compatible driver written for the Motorola MVIP300 or GreenSpring IP-488 IEEE-488 IP module? A WindRiver tech at a Real Time Tradeshow in Vancouver mentioned there might be a quasi-sanctioned driver out there. If anyone has experiences (hopefully happy ones) with either of these products (they are identical) please contact me. I am using an MVME-162 with VxWorks 5.1 Dave Morris TRIUMF-UBC 604-222-1047 --------------------------- Newsgroups: comp.os.vxworks Subject: Unloading .o files ? Date: 14 Apr 1994 19:30:32 GMT From: worrall@scrap.ssec.wisc.edu (Thomas Worrall) Organization: Space Science & Engr. Ctr. Message-ID: <2ok5ko$lhe@spool.cs.wisc.edu> Reply-To: worrall@ssec.wisc.edu Say I load a .o file -> ld < DANGEROUS.o and I run some DANGEROUS functions. But then I want the system to be wholesome and safe again. Is there anyway to "unload" these functions so some innocent passer by couldn't accidentally type in a DANGEROUS function and be maimed or worse? Besides rebooting the system, I mean. That's what we do now. - -- Thomas Worrall Internet: worrall@ssec.wisc.edu Space Science and Engineering Center 1225 West Dayton Tel. 608-263-2566 University of Wisconsin, Madison 53706 Fax 608-262-5974 --------------------------- End of New-News digest ********************** From dwampl@atl.com Fri Apr 15 10:10:33 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Fri Apr 15 10:10:42 PDT 1994 Subject: More on C++ and Vxworks > From rdmacko@somnet.sandia.gov Fri Apr 15 06:12:38 1994 > Date: Fri, 15 Apr 1994 07:13:33 -0600 > From: RD Mackoy > To: dwampl@atl.com > Subject: Re: Vx Exploder Digest > Newsgroups: comp.os.vxworks > Organization: Sandia National Laboratories > Cc: > Content-Length: 350 > > Could you please expound on the munching the libraries? When you use "CC" (i.e. "cfront") on the Sun, the link step performed by CC invokes a tool called "munch", which reads the object code, finds all global, static objects, and creates a startup function (called before "main") which will invoke all the constructors for those objects. A comparable function is created to call all the corresponding destructors when "exit" is called. All of this is transparent to us developers. Since VxWorks doesn't require the same "all-in-one" link philosophy, it is necessary for the developer to do this "munch" step. It can only be done ONCE, because it creates two global C functions, one that invokes all the constructors and one that invokes all the destructors. This is true even if your approach is to do a complete link of a bootable kernel, and then download object code on top of it; you get only one "munch". The basic algorithm for the munch process is as follows: 1) Run "nm68k" on all the object code (kernel - if you put the C++ libs. there, your application code, etc....). 2) Pipe the output of (1) through "munch68k", and redirect the output to a C file. 3) Compile the C file with gcc68k (NOT CC68k). 4) Do an incremental link of the output object file with the rest of the object code. Since there is no "main" in your code, you have to invoke the two, aforementioned global constructor and destructor functions explicitly. This is done either using an "automatic" strategy or by calling the functions "cplusCtors()" and "cplusDtors()", respectively. All of this confusion is described in the WindC++ users guide. > Also, I have a > problem using vxgdd and c++ code. Every time I try to run a routine on > the target ('030) it says it cannot create task on target. Any ideas? Vxgdb has problems with mangled function names. If you have a C++ function, it understands what to do if you issue the command "break func_name", but the command "run func_name" doesn't work (you get that cryptic message about not being able to create a task). Go figure.... However, it does understand the mangled version of the name. (In fact, for member functions, even "break class::member" may not work; I can't recall just now....) In our case, most of our subsystem-to-subsystem interactions are done through non-member functions with C-name "binding" (most of the subsystems are actually in C, so this is mandatory.) When I want to step through C++ code w/ vxgdb, I usually do "break C_func", or list the C++ file and set a breakpoint on the appropriate line number. ObjectCenter is a little better at handling C++ debugging on VxWorks, but I've had problems w/ it crashing occasionally. I'm also posting other information to the "exploder" in response to another query. Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "I feel your pain...." =:O] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From dwampl@atl.com Fri Apr 15 10:35:21 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Fri Apr 15 10:35:30 PDT 1994 Subject: Re: Questions About Real-time C++ VxWorks Embedded Systems > Subject: Questions About Real-time C++ VxWorks Embedded Systems > > We are contemplating using C++ (CenterLine C++ & gcc) with VxWorks in a VME > environment using 68030 or better. Our application will make > heavy use of iostreams class library, NFS, sockets, etc. > > Are there any developers who would like to share their experiences of > using C++ with VxWorks in a real-time environment? OK. > Can you brielfy describe your application(s)? A fairly large and complicated medical application using the 68k. > What were the severe gotcha's? The file iostreams were broken in the beta of WindC++. It reflected a bug in the implementation of multiple inheritance (a lesson for those who want to use multiple inheritance!). I believe that the "V1.0" version is supposed to be fixed. See also the following. > > Have you found the CenterLine/gcc/VxWorks development environment to be stable? It feels like beta-ware, but it is stable enough. We are avoiding multiple inheritance, for safety. Also, we decided not to use the template mechanism in cfront. It is confusing, slow, and the error checking seems to be poor. We decided that it was too risky for our novice environment. Your mileage may vary.... > > What's been your experience with debugging the target using Vxgdb++ and > CenterLine on the target. Any gotcha's or insurmountable problems. > It doesn't handle mangled names very well. For example, you can set a break point in a C++ function, but to actually "run func", you have to use the mangled version of the name. Use ObjectCenter if you can. It handles names better and its data display is much better. However, it is a resource hog, is a bit slow, and occasionally crashes while debugging. > Does the iostreams class library work as expected? > Except for the aforementioned bugs, yes. Note that you have to "munch" the streams library yourself to get "cout", "cin", etc. to work. The WindC++ docs. don't make this requirement clear. (I'm posting a separate note on "munching".) > What 3rd party class libraries are you using? > None right now. We didn't have the time to evaluate them, or the critical need. However, our next round of development will address this issue. On libraries, if you are thinking about using X, be warned that we had memory leak problems with "WindX", the Vxworks X library port. We switched to an X/Motif port from a company named "Visicom". > Have you discovered any problems using 3rd party class libraries, i.e.: > re-entrancy or thread-safe issues, other? > Can't offer any help here. > Has anyone ported or used RogueWave class libraries with VxWorks? > I would like to try this one myself.... > Another point, I don't know if speed of compilation and size of code is critical, but I think you pay a penalty in both areas if you use "cfront". I can't really say how big the "size" penalty is, but compile times aren't speedy. Hope this helps. I think that I can safely recommend WindC++. Plan on spending some time figuring it out and getting it working. Also, using ObjectCenter is definitely recommended. We try to test our code on the Sun before downloading to the target. On the Sun, you can at least use the full power of OC, while only a subset is available on the Vxworks target. Even there, it offers many advantages over vxgdb. Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "We begin bombing in five minutes...." 7:^] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From stan@rti.com Fri Apr 15 11:23:47 1994 From: stan@rti.com (Stan Schneider) Date: Fri Apr 15 11:23:56 PDT 1994 Subject: Re: Unloading .o files ? >> Date: 14 Apr 1994 19:30:32 GMT >> From: worrall@scrap.ssec.wisc.edu (Thomas Worrall) >> Say I load a .o file >> >> -> ld < DANGEROUS.o >> >> and I run some DANGEROUS functions. But then I want the system to >> be wholesome and safe again. Is there anyway to "unload" these functions >> so some innocent passer by couldn't accidentally type in a DANGEROUS >> function and be maimed or worse? >> Under VxWorks 5.1.x, you can use 'unld "DANGEROUS.o"' (or use the module id, see "moduleShow"). Under 5.0.x, you can't unload the object & reclaim the space, but you could remove the symbols from the symbol table with symRemove. That would prevent unnecessary maiming. -- 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 daemon@vxw.ee.lbl.gov Sat Apr 16 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 16 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 16 04:00:10 PDT 1994 Subject: HDLC for the 85230 Subject: dosFs questions ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: HDLC for the 85230 Date: Fri, 15 Apr 1994 18:40:56 GMT From: maillet@wrs.com (Al Maillet) Organization: Wind River Systems, Inc. Message-ID: Hi, Does anyone out there have an HDLC (synchronous) serial driver written for the 85230 duart. Any help would be greatly appreciated. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Al Maillet al@wrs.com Wind River Systems, Inc. Southwest Application Engineer 8910 University Center Lane Phone: (619)597-2477 Suite 300 Fax: (619)558-8918 San Diego, CA 92122-2477 - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Al Maillet al@wrs.com Wind River Systems, Inc. Southwest Application Engineer --------------------------- Newsgroups: comp.os.vxworks Subject: dosFs questions Date: Sat, 16 Apr 1994 03:28:37 GMT From: dfox@netcom.com (Don Fox) Organization: NETCOM On-line Communication Services (408 241-9760 guest) Message-ID: Has anyone been successful at getting floppies (formatted on a vxworks target) to be readable on a PC running DOS 5.0? The floppies will be read fine by the target if they are formatted on the PC. The configuration information If I were to believe ndd, then the cause would be an invalid disk table in the boot record. When I looked at the disk via HEX edit, I noticed that the media descriptor was 0x00 instead of 0xF0. The media byte via the dosFsConfigShow command was 0xf0. I haven't looked at many of the other bytes yet (only because I didn't have a handy reference for "DOGFS".) I plan to look into this further, however, I have to believe that this problem has been encountered more than once! I would also like to format a harddrive and pass it between a PC and the target. I realize there are some problems with this as well, but I have to ask if anyone has successfully done this too. I am running a MV147 target under 5.1 with a TEAC SCSI drive. I am using dosFsDevInit, and the FIODISKFORMAT, FIODISKINIT ioctl calls. ( I can be more specific if need be.) Any help would be appreciated. Thanks in advance. -Don Fox (dfox@netcom.com) Also: Does anyone have any information on the dosFsSysId and dosFsSysExtId commands? I did see any docs or man pages for these. --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Apr 17 04:00:19 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Apr 17 04:00:27 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 17 04:00:11 PDT 1994 Subject: re: FDDI Driver ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: re: FDDI Driver Date: Sat, 16 Apr 1994 19:35:21 +0000 From: pdg@samal.demon.co.uk (Paul Goffin) Organization: Home Message-ID: <766524921snz@samal.demon.co.uk> References: <9404071616.AA20009@csg.lbl.gov> Reply-To: pdg@samal.demon.co.uk Sender: usenet@demon.co.uk In article <9404071616.AA20009@csg.lbl.gov> rab@csg.lbl.gov "Robert Belshe" writes: >We are using vxWorks 5.1 and will use a MVME166 processor for the >FDDI. >In this application, data will be sent from the VME data acquisition >system ( via UDP multicast, if possible) to a small number of >sparcStations located nearby. > Radstone Technology 5.1 driver with PME FDDI-1 We (Radstone) also have Solaris drivers for this card. Handy if you're using FORCE SPARC VME cards. We're also close to having a vxWorks BSP for the FDDI-1. Paul (working for, but not posting from Radstone Technology). - -- - --- Paul D. Goffin + pdg@samal.demon.co.uk +44 525 373931 + my system; my opinions. --------------------------- End of New-News digest ********************** From visicom!VisiCom.COM!trest@lbl.gov Sun Apr 17 08:14:56 1994 From: Mike Trest Date: Sun Apr 17 08:15:06 PDT 1994 Subject: re: comp.os.vxworks newsdigest > > We're developing a Motif application for use under vxWorks, and we are > > seeing crashes which look like they might be re-entrancy problems ... > > I've never used X/Motif under VxWorks, so take this with a grain of salt > (i.e., WRS may have an improved Motif). But neither Motif nor the Xt > Intrinsic library is reentrant, at least in their standard Unix form. The VX-Windows product from VisiCom Laboratories provides a fully "reentrant-safe" X and Motif. The product is mature, having been in the field for several years with both small project and large OEM applications. We have never had a reported corruption due to the X or Motif libraries or from using the VX-Windows server. > They're also synchronous -- you can't make Xt/Motif calls from within > a signal handler, for example, due to lack of reentrancy. You can with VX-Windows, however, a preferred design would be to keep the interrupt or signal handler routine very small by simply setting a flag or giving a semaphore which is acted upon by another task outside of the interrupt context. It could be done in signal handlers, it but should not be done in interrupt handlers. > . ... . The standard > answer for "how do I update my display to reflect a real-time event?" is > to use a TimeOutProc or WorkProc. XtAppAddTimeOut and XtAppAddWorkProc > can be called asynchronously, I believe. Good answer, for UNIX. In VX-Windows you can make any call almost anytime when to do so would not violate common practice and rules of VxWorks. The VX-Windows server and all provided X/Motif libs are VxWorks "safe". Likewise, your client application programs automatically become VxWorks "safe" when compiled with the VX-Windows provided Makefiles and *.h files. In fact, VX-Windows provides automatic protection for closing all files and freeing all un-freed malloc's when you exit your client or your client task aborts. Yes, this even includes the malloc's which X/Motif lib routines do internally without your knowledge. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 VisiCom Laboratories Fax: 619 457 0888 10052 Mesa Ridge Court San Diego, CA 92121 ==================================================== From mea@mclean.sparta.com Mon Apr 18 08:33:13 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Mon Apr 18 08:33:24 PDT 1994 Subject: Re: Teac SCSI Floppy problems Greetings! > From: dfox@netcom.com (Don Fox) > > Has anyone been successful at getting floppies (formatted on a vxworks target) > to be readable on a PC running DOS 5.0? The floppies will be read fine by > the target if they are formatted on the PC. The configuration information > If I were to believe ndd, then the cause would be an invalid disk table > in the boot record. When I looked at the disk via HEX edit, I noticed that > the media descriptor was 0x00 instead of 0xF0. The media byte via the > dosFsConfigShow command was 0xf0. I haven't looked at many of the other > bytes yet (only because I didn't have a handy reference for "DOGFS".) > I plan to look into this further, however, I have to believe that this problem > has been encountered more than once! > > I would also like to format a harddrive and pass it between a PC and the > target. I realize there are some problems with this as well, but I have > to ask if anyone has successfully done this too. > > I am running a MV147 target under 5.1 with a TEAC SCSI drive. I am using > dosFsDevInit, and the FIODISKFORMAT, FIODISKINIT ioctl calls. ( I can be > more specific if need be.) > We use these floppy drives all the time in my intermediate real-time training course wherein we use the floppies in both Sun and PC (MSDOG 5.0 and 6.X) drives as data exchange. We set them up as boot devices for VxWorks and make new boot roms, etc. as part of the class labs. The secret is to program all of the page 1 parameters (about 32 Bytes worth) not just the page 0 (4 bytes). I have a working driver that I'd be happy to send you if you're interested. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From daemon@vxw.ee.lbl.gov Tue Apr 19 04:00:33 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Apr 19 04:01:09 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 19 04:00:13 PDT 1994 Subject: reboot entire vme crate? Subject: Re: reboot entire vme crate? Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG] ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: reboot entire vme crate? Date: 18 Apr 1994 15:06:31 GMT From: worrall@scrap.ssec.wisc.edu (Thomas Worrall) Organization: Space Science & Engr. Ctr. Message-ID: <2ou7ln$8f3@spool.cs.wisc.edu> Reply-To: worrall@ssec.wisc.edu We have several boards running vxworks in a vme crate. Is there anyway to make the master processor reboot the other boards remotely? In fact when I reboot() just the master, I can no longer talk to the other boards. That doesn't seem right. Am I doing something wrong. Many thanks for your sage advice. - -- Thomas Worrall Internet: worrall@ssec.wisc.edu Space Science and Engineering Center 1225 West Dayton Tel. 608-263-2566 University of Wisconsin, Madison 53706 Fax 608-262-5974 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: reboot entire vme crate? Date: Mon, 18 Apr 1994 21:53:42 GMT From: ChatterjeeS@lfwc.lockheed.com (Shash Chatterjee) Organization: Lockheed Fort Worth Company Message-ID: References: <2ou7ln$8f3@spool.cs.wisc.edu> Reply-To: ChatterjeeS@lfwc.lockheed.com Sender: news@butch.lmsc.lockheed.com In article <2ou7ln$8f3@spool.cs.wisc.edu>, worrall@scrap.ssec.wisc.edu (Thomas Worrall) writes: |> We have several boards running vxworks in a vme crate. Is there |> anyway to make the master processor reboot the other boards remotely? |> |> In fact when I reboot() just the master, I can no longer talk to the |> other boards. That doesn't seem right. Am I doing something wrong. |> |> Many thanks for your sage advice. |> |> -- |> Thomas Worrall Internet: worrall@ssec.wisc.edu |> Space Science and Engineering Center |> 1225 West Dayton Tel. 608-263-2566 |> University of Wisconsin, Madison 53706 Fax 608-262-5974 Check your CPU users manual. The boards we use, Force CPU-30s, 31s, etc have a jumper that selects whether RESET drives the VME RESET as well. - -- +--------------------------------------------------------------------+ + EMAIL: ChatterjeeS@lfwc.lockheed.com + +--------------------------------------------------------------------+ + Shash Chatterjee + + Electronic Systems Design & Integration + + Lockheed Fort Worth Company + + P.O. Box 748, MZ1719 VOICE: (817) 763-1495 + + Ft. Worth, TX 76101 FAX: (817) 777-2115 + +--------------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks,comp.answers,news.answers Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG] Date: Tue, 19 Apr 1994 09:27:46 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded Message-ID: Followup-To: comp.os.vxworks Reply-To: hjb@netcom.com Sender: hjb@netcom.com Archive-name: vxworks-faq Maintained-by: hjb@netcom.com Last-modified: April 17, 1994 Version: 1.5 This is the list of frequently asked questions (and their answers) for the newsgroup comp.os.vxworks. Where possible, pointers to existing information are included here, rather than rehashing that information again. If you haven't already done so, now is as good a time as any to read the guide to Net etiquette which is posted to news.annouce.newusers regularly. You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know about smileys, followups and when to reply by email to postings. The FAQ is currently posted to comp.os.vxworks, news.answers and comp.answers on the 15th of every month. This FAQ was compiled by hjb@netcom.com using comments by readers of comp.os.vxworks as well as his own limited knowledge of VxWorks. Credits appear at the end. Comments and indications of doubt are enclosed in []s in the text. Each section begins with dashes ("-") on a line of their own, then the section number. This should make searching for a specific section easy. This FAQ is also available via anonymous ftp in: rtfm.mit.edu:/pub/usenet/news.answers/vxworks-faq.Z ftp.uu.net:/usenet/news.answers/vxworks-faq.Z cs.toronto.edu:/pub/usenet/comp.answers/vxworks-faq.Z netcom.com:/pub/hjb/vxfaq.gz - ------------------------------------------------------------------------- TABLE OF CONTENTS 1. What is VxWorks? 2. Brief History of VxWorks 3. What are some of the major features of VxWorks? 4. What are the Latest versions of VxWorks? 5. Where is the archive site for user-contributed code? 6. What application notes are available from Wind River? 7. How can I join the VxWorks user's group? 8. Is comp.os.vxworks also available via a mailing list? 9. Can I use gcc or g++ with VxWorks? 10. Other C/C++ Compiler tools for VxWorks? 11. Which cross-debuggers can I use with VxWorks? 12. What are differences between traditional UNIX and VxWorks? 13. What are the performance/benchmark numbers for WIND kernel? 14. What are the performance/benchmark numbers for VxWorks TCP/IP? 15. What is the VxSim VxWorks Simulator? 16. Can I use one boot EPROM for multiple boards on the same net? 17. What's the deal with 68881 FPU code in interrupt handlers? 18. Why does ls() not work on netDrv devices? 19. Why can't I do ".." at top level directories or NFS mount points? 20. Why do I have trouble using relative symbolic links with NFS? 21. X for VxWorks 22. IEEE-488 (GPIB) driver for VxWorks 23. How does one disable NFS client caching? 24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption? 25. How does one get better network I/O performance? 26. How does one troubleshoot a backplane driver malfunction? 27. How do I add select support to my driver? 28. bind() gets EADDRINUSE, how do I fix it? 29. Common errors in interrupt handlers with floating point co-proc hardware 30. Finding entry point of a given module using its name 31. The problem with irint() in earlier (5.0.2 ?) releases 32. What are +T, +I thingies in the "i" output? 33. Gotchas w.r.t watchdogs 34. Is it possible to delete a memory partition in VxWorks? 35. rename() does not work in netDrv and nfsDrv filesystems, why? 36. Free NFS Server for VxWorks 37. Free SNMP for VxWorks 38. What third party products are available for VxWorks? 39. What kind of products have been developed using VxWorks? 40. A complete list of CPU hardware supported by VxWorks 41. A complete list of peripheral devices supported by VxWorks 42. What's with these unbundled "accessories"? 43. How come my 5.0.2 BSP isn't available in 5.1, damn it? 44. How much is VxWorks? 45. What is MicroWorks? 46. Other Unbundled Products for VxWorks? 47. How can I find out more about VxWorks? 48. What other net.resources are available on real-time systems? 49. How do i use FIONBIO in 5.0.2 when there is no fcntl()? 50. Free lex and yacc for use with VxWorks 51. timer_gettime() bug 52. bogus INCLUDE_TCP_DEBUG 53. free ppp for VxWorks 54. how to disable cache on mc68040 or mc68030 using TT regs? 55. work-arounds for ms-dos filesystem bug when lseek() past eof 56. TCL for VxWorks 57. adding default route 58. adjusting network driver MTU size 59. tcpdump like utility for vxworks 60. VxWorks performance on i960 -- unofficial benchmark 61. VxWorks SCSI Performance -- unofficial benchmark [new] 62. VME bus arbitration gotchas [new] 63. 5.1.X new MMU supporting code gotchas, as explained in the Manual [new] 64. "Cannot Boot. Error 0x1a9" while downloading/booting [new] 65. problem with qsort in some versions of VxWorks [new] 66. fmod fiasco [new] 67. MVME167 copyback cache and various problems [new] 68. unloading objects 9999. Contributions to comp.os.vxworks FAQs. - ------------------------------------------------------------------------- 1. What is VxWorks? VxWorks, from Wind River Systems, is a networked real-time operating system designed to be used in a distributed environment. It runs on a wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems. It requires a host workstation for program development; supported host platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS. It does not run development systems software such as compiler, linker and editor on the target machine. The development environment is based on cross-development or remote-development method. You will need a UNIX machine of some sort (e.g. SUN's) to run the compilers and debuggers. The compiled application code can be downloaded to the target and runs as part of the VxWorks image. During the development phase or thereafter, individual object code (.o files) can be downloaded dynamically to running target system. Finished applications can be ROM'ed or whatever. - ---------------------------- 2. Brief History of VxWorks Based on what I have heard from David Wilner and others, WRS was started by Jerry Fiddler and David Wilner in Jerry's garage as a contract/consultant shop for realtime, embedded systems and other fun things. Francis Coppola was one of the earlier customers. They wrote a bunch of neat programs for their work and found that they liked them a great deal themselves, and added more excellent features to the system, eventually adding some things unheard of in embedded/realtime market in those days such TCP/IP networking. And continued to pioneer in this area by adding NFS, etc. VxWorks was the name given the collection of software which ran on top of various realtime kernels including VRTX and pSOS as well an earlier slower version of WIND kernel. [ editorial: VxWorks no longer runs on other kernels; it now runs exclusively on its own WIND kernel since the 5.0 release, for which the WIND was rewritten by John Fogelin. ] They got more people interested in the system and became successful. And moved from a little building in Emeryville to a larger one. And eventually to the present site in Alameda. And hired a lot of people. WRS sold many many more copies of this system and continues to grow like a real successful company. - ----------------------------- 3. What are some of the major features of VxWorks? In Version 5.1: - wind kernel unlimited tasks - 256 priorities - binary, counting mutex semaphores - message q's - POSIX pipes - sockets - shared memory - profiling utilities - ethernet support (i596, LANCE, NIC, SONIC) - SLIP (no PPP yet) - backplane driver for network - rlogin (server & client) - telnet (server only) - rpc (no rpcgen) - nfs (client) - ftp (server & client) - tftp (client & server) - rsh - bootp - proxyarp - C-interpreter shell (incomplete but useful) - symbolic debugging - disassembly - performmance monitoring tools - exception handling - signal handling (not quite UNIX compatible) - dynamic object image loader - system symbol table - system info utilities - libraries of 600+ utility routines - remote source level debugger(VxGDB) - SCSI support - DOS & RT11 & Raw filesystems. - "full ANSI" - "POSIX I/O" It is a good idea to get a copy of VxWorks manuals before purchasing the system. WRS can provide you with such documentation. As far as I know there is no "VxBook" in the bookstores. - ---------------------------- 4. What are the Latest versions of VxWorks? As as of June 1993, 5.0.3.: TRON will be discontinued. 5.0.3 : i386 5.0.5 : r3000 5.1 : 680x0, 683xx, i960, SPARC i386 and r3000 will be upgraded to 5.1. - ------------------------------ 5. Where is the archive site for user-contributed code? The VxWorks archive system is available for FTP as thor.atd.ucar.edu. It is also accessible via email server at vxworks_archive@ncar.ucar.edu. Questions should be directed to its maintainer, Richard Neitzel . 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 A summary of the archives is periodically posted to comp.os.vxworks. Some of the usual titles available: ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2 lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar vxtool, vxview, xc - ------------------------------ 6. What application notes are available from Wind River? List of Wind Technical Notes Motorola MV147 Slave Base Control 9-1 System hang during lkup( ) output 10-1 Reserving Memory 11-1 Serial IO Vanishing 13-1 NFS: problems with writing files 14-1 Which interrupts does VxWorks use? 15-1 Debugging ftp problems 18-1 Interrupt handlers, floating point 19-1 Booting From a Memory Board 22-1 Changing Network Interfaces 23-1 Writing Non-buffered Sockets 24-1 RPC and VxWorks 25-1 Using SCSI devices with VxWorks 5.x 26-1 The Select Facility in VxWorks 28-1 Using on-board Serial Ports 29-1 Problems with ls() 30-1 SCSI 31-1 Trouble Shooting Booting Problems 32-1 - ----------------------------- 7. How can I join the VxWorks user's group? For User Group info contact WRS or Eric Rabinowitz of Panoramic Systems at: elr@netcom.com or ericr@wrs.com phone: 408-289-7757 - ------------------------------ 8. Is comp.os.vxworks also available via a mailing list? Lawrence Berkeley Labs maintains an automated mailing list which is bi-directionally gatewayed to comp.os.vxworks It is called the 'VxWorks Exploder'. Mail to vxwexplo@lbl.gov is automatically mailed to a number of sites, including Wind River. Send subscription request to vxwexplo-request@lbl.gov. - ------------------------------ 9. Can I use gcc or g++ with VxWorks? WRS's gcc GNU Toolkit distribution can be reshipped in its entirety. WRS charges are for media and support, so obviously copies thereof don't matter to them. Lots of customers use g++ as provided by the "net" -- see the VxWorks Archive information below. You can get a generic freely distributable GCC/G++ and compile your code for VxWorks. Or you can just get a copy from someone who has a working GCC cross-development setup from WRS. WRS worked with Cygnus to polish up their release of GCC but a generic GCC distribution works just fine as well. For MC68K targets: You can also use native SunOS 4.X cc running on Sun-3's. You can also use various other free m68k C compilers such as lcc, sozobon, etc. provided that you're willing to hack on them. Richard Neitzel (thor@thor.atd.ucar.edu) writes, Thanks to some feedback I've corrected the archive instructions on how to build gcc, libgcc and libg++ for VxWorks. To make my life simpler the patches referenced are no longer included in the vx_cplusplus file. Instead there are now seperate patch files for the effected parts: libg++-2.5-src.patch: Patches libg++/src. libgcc2-2.5.0.patch: Patch libgccc2.c for gcc-2.5.0. libgcc2-2.5.2.patch: Patch libgcc2.c for gcc-2.5.2. libio-2.5.patch: Patch the stream library. See VxWorks Archive information in this FAQ for details on how to get these files. - --------------------------------------- 10. Other C/C++ Compiler tools for VxWorks? WRS re-sells (re-engineered?) CenterLine cfront product and WindC++ Gateway for CenterLine ObjectCenter. They come with browsers, etc. Not free. Wind C++ Gateway for ObjectCenter sold by WRS: $995 / user 1-4 copies $875 / user 5-9 copies Note that this is the cost over and above ObjectCenter. - ------------------------------ 11. Which cross-debuggers can I use with VxWorks? GDB & other more expensive tools from WRS, MicroTec Research, etc. WRS sells a lightly modified version of xxgdb which has a lousy GUI interface. In 5.1 xvxgdb may have been slightly improved -- but the ObjectCenter C++ with VxWorks solution provides better GUI interface. With a little bit of hacking, regular GDB works just fine. Personally, I find GUI to a debugger gets in the way of real work. I use GNU Emacs GDB interface which works well and can be easily customized. There might be some old VxWorks customers that also use VxWorks-aware dbxtool on Sun machines. This used to be maintained and sold by SUN Consulting. If you're only interested in debugging your "application" on VxWorks, the vxgdb approach (using RPC) works just fine. If you are rather more interested in the guts of the system as well as your application you might want to spend some time building cross-debugging tools from generic GDB distribution into VxWorks. - ------------------------------------ 12. What are differences between traditional UNIX and VxWorks? They're both hacks. UNIX has a larger installed base. :-) Seriously though, similarities end there, IMHO. VxWorks does have a lot of UNIX "compatible" routines in the user libraries. So porting a UNIX application is not that hard. But there are enough differences to make such a port take longer than normally expected. VxWorks runs in one mode. No protected vs. user mode switching is done. Running in supervisor mode on most processors, and not using traps for system calls, VxWorks can achieve minimal overhead on a given piece of hardware than UNIX. Programming on VxWorks can be more tricky than UNIX for the same reason. UNIX provides resource reclamation; by default, VxWorks does not. [ editorial: using deleteHooks or whatever, you could implement this on your own.] Instead programmers write what they need as needed. As a result, the context switch time in VxWorks is on the order of a few micro-seconds (since there is a lot smaller context to save and restore). VxWorks does not have full "process"; it only has tasks, or "threads", or light weight processes as some people like to call them. Like any other multi-threaded environments (or MP environments), care should be taken when writing multi-tasking code. Each routine should be written carefully to be re-entrant (if it is going to be called from multiple contexts), semaphores are used a lot for this. And static variables are frowned upon. Sometimes, when porting a UNIX application, you may need to add "task variables" for this reason (as done for rpcLib in VxWorks). VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented as semaphores). Traditional UNIX: high interrupt latency (e.g. spl's are implemented as interrupt lock and unlock calls). VxWorks: priority interrupt-driven preemption, optional round-robin time-slicing. Traditional UNIX: prioritized round-robin preemptive time-slicing. Since VxWorks is just a glorified "program" it can be changed and customized pretty easily. Task scheduling can be customized as desired, for example. VxWorks networking code, however, is very UNIX compatible [editorial: it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe release ]. It is relatively easy to port socket based code to VxWorks. [ editorial: except the not-so-compatible hostLib routines, etc.] VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX as often misunderstood by some people. The confusion perhaps is due to the fact that UNIX hosts are used most widely to develop applications for VxWorks (and VxWorks itself). There are a lot more differences! In short, UNIX is a nice system to run emacs on. VxWorks is much better at playing pin-ball game machines. Having said all this, I should also note that there are Realtime capable UNIX systems out there. Most of these systems do not come close to the capabilities and performance of VxWorks in realtime processing. An exception to this might be QNX, which is a very well designed Realtime POSIX operating system. - ---------------------------- 13. What are the performance/benchmark numbers for WIND kernel? A WRS VxWorks 5.1 Benchmark Report hot off the press: Benchmark numbers based on: mv167-25Mhz, 5.1 Cache Cache Key Measurements Enabled Disabled Raw Context Switch Time 4 us 14 us Cyclic Test Time 172 us 638 us Suspend/Switch/Resume/Switch 23 us 86 us Kernel Timings Task Related taskSpawn 124 us 370 us taskInit 58 us 181 us taskActivate 12 us 33 us taskDelete 101 us 303 us Task Create / Delete 249 us 684 us taskLock CASE 1: no lock 3 us 4 us CASE 2: lock exists 2 us 5 us taskUnlock CASE 1: no lock 2 us 12 us CASE 2: lock exists 5 us 6 us taskSuspend CASE 1: ready task 11 us 30 us CASE 2: pended task 9 us 19 us CASE 3: suspended task 8 us 19 us CASE 4: delayed task 9 us 19 us taskResume CASE 1: ready task 6 us 19 us CASE 2: pended task 10 us 19 us CASE 3: suspended task 13 us 30 us CASE 4: delayed task 9 us 18 us Semaphore Related semBCreate 66 us 152 us semCCreate 46 us 150 us semMCreate 45 us 139 us semDelete Binary 49 us 157 us Counting 49 us 163 us Mutual Exclusion 48 us 157 us semGive CASE 1: tasks in queue Binary 18 us 44 us Counting 20 us 46 us Mutual Exclusion 25 us 59 us CASE 2: no tasks in queue Binary 4 us 8 us Counting 5 us 11 us Mutual Exclusion 6 us 15 us semTake CASE 1: semaphore available Binary 4 us 9 us Counting 5 us 11 us Mutual Exclusion 5 us 13 us CASE 2: semaphore unavailable Binary 10 us 25 us Counting 11 us 27 us Mutual Exclusion 4 us 12 us Semaphore Give / Take Binary 7 us 15 us Counting 9 us 21 us Mutual Exclusion 10 us 26 us semFlush Binary 11 us 20 us Counting 11 us 20 us Mutual Exclusion 10 us 16 us Miscellaneous Operating System Timings Message Queue Related msgQCreate 93 us 280 us msgQDelete 71 us 229 us msgQSend CASE 1: task pending 39 us 102 us CASE 2: no tasks pending 23 us 64 us CASE 3: queue full 14 us 45 us msgQReceive CASE 1: message available 20 us 62 us CASE 2: message unavailable 15 us 41 us Memory Related malloc 28 us 81 us free 32 us 104 us Watchdog Related wdCreate 42 us 106 us wdDelete CASE 1: timer started 48 us 160 us CASE 2: timer not started 44 us 150 us wdStart CASE 1: timer in queue 20 us 70 us CASE 2: no timer in queue 18 us 55 us wdCancel 11 us 34 us Floating-Point robot application 18 sec 51 sec [ editorial: If you care enough to count pico-seconds in comparing realtime kernels, you might want to actually get each of the evaluation copies from various vendors and test them yourself. But remember benchmarks are misleading and almost always biased and inaccurate. Given similar benchmark numbers, give or take a few microseconds, etc., your dollars are better spent in getting something you'll enjoy using. ] - ----------------------------- 14. What are the performance/benchmark numbers for VxWorks TCP/IP? According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet) w/ cache w/o cache enabled TCP/IP Throughput (KB/sec) 859 KB/sec 682 KB/sec No numbers available on latency. Using a reasonably fast processor 25Mhz MC68040 and a reasonably well made ethernet chip like SONIC or LANCE put together on a reasonable board design will achieve TCP throughput close to full bandwidth of ethernet. [ editorial: This, of course, is rather slow in comparison with other fast implementations, since a 16Mhz MC68020 with onboard LANCE or a PeeCee with an ethernet board can easily do the same. I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC that does: 1170KB/sec. ] - --------------------------------- 15. What is the VxSim VxWorks Simulator? Propaganda from WRS: It really is VxWorks running under UNIX! So sure it is not realtime, although all tasks and resources interact in the same way -- great for prototyping "high-level" code. Using the simulator saves wear and tear on h/w. It (only) allows sytem level debugging with native GDB. Portably written object code compiled for VxSim (for SunOS SPARC) will usually load without recompilation on a SPARC target. And, BTW under 5.1 switching from one architecture to anthoer really is pretty painless. - ------------------------------ 16. Can I use one boot EPROM for multiple boards on the same net? WRS provides EPROMs with a default bogus bootline, virtually all boards come with non-valiatile RAM which is set as soon as the user fills in his parameters (which include CPU #). Therefore 1 EPROM may be duplicated and used in all boards at a site. If the board does not contain nvram then ROMs have to be specially blown, unless a custom scheme for reading some switches or something is coded to index into a bootline table. In 5.1 BOOTP is supported -- no more repeated EPROM burning is necessary. - ------------------------------ 17. What's the deal with 68881 FPU code in interrupt handlers? In general, FP context is optimally saved only when the scheduler notices that the new task coming in also uses the fpu (VX_FP_TASK). ISRs don't. If no tasks are using the FPU then ISRs may go ahead, unless different levels of ISRs could interrupt each other and again cause a protocol violation. And Stan Schneider says, You have to set the "VX_FP_TASK" option flag when you spawn your task. You also need to make sure you don't use the FPU in any interrupt service routines. Even if your code uses no floating point, some (brain-dead) compilers save some FPU registers at the start of all routines if there's any floating point in the file. That's not usually a problem if you're using the gcc compiler (at least with the "-O" flag on). A sure way to check is via the dissassembler. And Leonid Rosenboim says, This problem is quite common, and really simple to fix, all you have to do is make sure that all tasks that do a float operation ever, will be spawned with the VX_FP task option set. This is the best and only solution. Also, if you run floating operations in ISRs care must be taken, to call fppSave() and fppRestore(). Also if you are using 5.1 on a 68040, there is a bug in the compiler that you must work around: If you write an ISR that uses float instructions, it is not enougth just to call fppSave()/fppRestore(), since the compiler for 68040 inserts FP instructions BEFORE your first line of C code, hence you need to write a dummy ISR that: dummyIsr() { fppSave( .. ); yourRealISR(); fppRestore( ... ); } And Kent Long says, This was indeed a real problem in the context switch code in 5.0.x which was corrected in 5.1. In both OS versions, there is an optimization that causes the FP context to be swapped only when the incoming task has been spawned with the floating point (VX_FP) flag set. In 5.0.x, the copying-in of the FP context was done via an fppSave() call. This created problems if a new FP task was created after a previous FP task had been pre-empted by a non-FP task in the middle of an instruction. The new task ended up with a mid-instruction context (which causes the protocol violation), and the old swapped-out FP task ultimately ended up with its context set to IDLE (which is equally incorrect). In 5.1, the FP context initialization was changed so that when a task is created, a pre-defined IDLE frame is copied into that tasks's context. Since there is no assumption about current FP state (as with fppSave), task creation is now decoupled from the regular switch logic. - ------------------------------ 18. Why does ls() not work on netDrv devices? Because the way directory information retrieval IOCTL calls are not acompatible between different types of "filesystems" in VxWorks. Another reason why some think VxWorks filesytem does not exist; they're just a collection of ioDevice drivers, and there is not a real consistent "design" to it. The lsOld() should work on "filesystems" that does not support ls(). Chuck Mead proposes the following special routine in case lsOld() does not work for you: #include "vxWorks.h" #include "bootLib.h" #define RSHD 514 STATUS lsHost(path) char *path ; { char *lsString; int dataSock ; int n ; char nextChar ; extern BOOT_PARAMS sysBootParams ; extern char *sysBootHost ; if (path == (char *) NULL) { lsString = (char *) malloc(4) ; strcpy(lsString, "ls") ; } else { lsString = (char *) malloc(strlen(path) + 5) ; sprintf(lsString, "%s%s", "ls ", path) ; } dataSock = rcmd (sysBootHost, RSHD, sysBootParams.usr, sysBootParams.usr, lsString, (int *) NULL) ; if (dataSock == ERROR) { printf("Error opening socket") ; return (ERROR) ; } n = fioRead(dataSock, &nextChar, 1) ; while (n == 1) { printf("%c",nextChar) ; n = fioRead(dataSock, &nextChar, 1) ; } close(dataSock) ; } - ------------------------------ 19. Why can't I do ".." at top level directories or NFS mount points? Because, again, VxWorks does not really have a "filesystem" as most people understand it. The top level directories are just implemented as device driver "node", which is used to identify the ioDev associated with the specific VxWorks "filesystem". Since there is no underlying filesystem layer, the story ends there. When you're at the top of the directory hierarchy within a given ioDev/filesytem, you simply cannot do "..". - ------------------------------ 20. Why do I have trouble using relative symbolic links with NFS? See [Q: Why can't I do ".." at top level directories or NFS mount points?] above. This is just another problem caused by the fact that a real filesystem does not exist for VxWorks. NFS client implementation actually does implement the symbolic links correctly, using lookup and readlink. The problem is due to the fact that, for some relative links that use ".." or whatever, that crosses over filesystems, VxWorks cannot have underlying subsystem that will handle file pathname to device mapping. Using absolute symbolic links work just fine (i.e. full path name from top). - ------------------------------ 21. X for VxWorks WRS has a product called windX which supports Motif. There is also libX11 contribution in the VxWorks Archive. This package is perhaps fairly old and out of date. Essentially, to port X stuff to VxWorks you'll need to do make sure code is re-entrant everywhere. There is a "multi-thread" safe version of Xlib available somewhere on the net, one might try porting that. There are also vendors that have built X servers using VxWorks. Jupiter Systems, in Alameda, makes high-end X server machines based on VxWorks. Other X terminal vendors (HP?) also use VxWorks. - ----------------------------- 22. IEEE-488 (GPIB) driver for VxWorks - National Instruments has lots of GPIB stuff - THEMIS computers has TSVME-409 whic hincludes a GPIB interface. - APLABS probably has some GPIB stuff too. - ----------------------------- 23. How does one disable NFS client caching? VxWorks caches read and write requests in NFS client code. To completely disable read and write cache, set nfsCacheSize to 0. To just flush the write cache as needed, use nfsCacheFlush() or FIOSYNC ioctl(). - ------------------------------ 24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption? This is due to a bug in slipDelete() and/or if_dettach(). slipDelete() calls if_dettach() to clean up after itself (SLIP network interface driver). Not only is if_dettach() misspelled, it also doesn't do a complete job. One deficiency is that it does not delete routes that are pointing to the interface being deleted. This is remedied via another function that deletes all routes for a give netif device driver. [ ifRouteDelete() ??? ] slipDelete() does call this routine to delete routes. Another problem is that if_dettach() does not delete a pointer to the netif device driver structure in the global in_ifaddr linked list. The in_ifaddr list is used by the network kernel code to find IP addresses of available network interfaces, among other things. This lack of proper cleanup turns out to be a rather hard-to-find memory corruption problem in network code, and usually manifests itself as routing table corruptions. To fix this add the following routine, and call it right after calling slipDelete: void in_ifaddr_remove(ifp) struct ifnet *ifp; /* ifp = ifunit("sl0") before slipDelete() called */ { struct in_ifaddr *ia, *prev_ia; if (!ifp) return; prev_ia = 0; for (ia = in_ifaddr; ia; ia = ia->ia_next) { if (ia->ia_ifp == ifp) { if (prev_ia) prev_ia->ia_next = ia->ia_next; else in_ifaddr = ia->ia_next; return; } prev_ia = ia; } } This, along with the route cleanup, should be incorporated into if_detach(). - ------------------------------ 25. How does one get better network I/O performance? Most of the overhead is due to socket to network core interface overhead. The copy that happens between the socket layer and network core code can be avoided by using the routines in uipc_socket.c (as in BSD tahoe release code available on various archive sites) and using mbufs directly. You can also try using raw etherLib routines. However, etherLib also does copying between user application and network driver. If you must use the socket interface (sockLib), make sure you tune the socket level buffers sizes to optimal values using setsockopt() calls SO_SNDBUF and SO_RCVBUF. You might also just try changing the globals that control the following default parameters to larger numbers (all the way upto 48K): tcp_sendspace (default 4K) tcp_recvspace (default 4K) udp_sendspace (default 2K) udp_recvspace (default 4K) To get around extra latency in some cases, you might turn on TCP_NODELAY option on TCP sockets. - ------------------------------ 26. How does one troubleshoot a backplane driver malfunction? There are a few rules of thumb: 1) Try the simplest case first -- use polling instead of bus or mailbox interrupts and software test-and-set instead of hardware test-and-set. See if this works first. And then try hardware test-and-set and then the desired mailbox or bus interrupt. 2) Use bpShow() to see what's up. Also look for magic code 0x1234 in share mem area being used for messages, and verify heartbeat is being incremented. At the "anchor" you should see the magic code (4 bytes) followed by a long word which should be incrementing (the heartbeat) every second. 3) Verify all memory mapping and make sure there's no address conflicts on the bus, and the anchor area is properly set up. If the anchor and ring buffer area is on a CPU, make sure the sysLib.c:sysHwInit() does the right thing to allow access to on-board memory by other CPU's in the chassis. Be careful, as some VxWorks BSP's turn off on-board memory access by other CPU's if the CPU is not processor 0. This should be changed if your anchor CPU is not processor 0 (first CPU in VME chassis/backplane) -- this is a boot time configuration parameter [ based on the assumption that bpInit() will be done by the processor 0 ]. 4) Make sure bus controller is functioning properly. Some combinations of boards might not work well especially if your system controller board arbitrates the bus in one way and other boards expect to be arbitrated in a different way. Sometimes you might need to use a separate system controller. Of course, also make sure you only have one bus master. And that your VME bus strappings (BREQ, IACK daisychains) are right. 5) Call Wind River's VxWorks tech-support... - ------------------------------ 27. How do I add select support to my driver? #include "selectLib.h" ... xxx_init(...) { ... selWakeupListInit(&xxxdev->selwakeupList); ... } xxx_ioctl(...) { ... switch(request_type) { ... case FIOSELECT: selNodeAdd(&xxxdev->selwakeupList, (SEL_WAKEUP_NODE *)request_arg); if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD) && readable_condition_is_met) selWakeup((SEL_WAKEUP_NODE*)request_arg); if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE) && writable_condition_is_met) selWakeup((SEL_WAKEUP_NODE*)request_arg); break; ... case FIOUNSELECT: selNodeDelete(&xxxdev->selWakeupList, (SEL_WAKEUP_NODE*)request_arg); break; ... } } And, add calls to selWakeup() as appropriate in your interrupt handlers and read/write routines as selective conditions are toggled or satisfied. - ------------------------------ 28. bind() gets EADDRINUSE, how do I fix it? Fix: do setsockopt() SO_REUSEADDR - ------------------------------ 29. Common errors in interrupt handlers with floating point co-proc hardware Don't forget to use: fppSave() fppRestore() Interrupt handler encapsulation code doesn't always save fpp registers for you. - ------------------------------ 30. Finding entry point of a given module using its name Example from a poster in vxworks newsgroup (who?): FUNCPTR start; /* found entry point goes here */ UINT8 symType; int tid; if(symFindByName(sysSymTbl,"_nlos_start",(char**)&start,&symType)==OK){ /* taskSpawn(name,priority,options,stacksize,entryAddress,arg1,..) */ tid = taskSpawn("nlos",TASK_PRI_NLOS,SPAWN_OPTS,STACK_SIZE_NLOS,start, arg1,arg2,.....); } - ------------------------------ 31. The problem with irint() in earlier (5.0.2 ?) releases The problem: /* Include Files */ #include "vxWorks.h" #include "math.h" long irint_count = 0; sinTest() { int sinTable; while(1) { sinTable = irint(sin(4./1024.*(2.*3.14))*10.); irint_count++; } } % cc68k -I/vxworks/vw/h -c sinTest.c -> ld < sinTest.o /* 0x08 Option = VX_FP_TASK within taskLib.h */ -> taskSpawn ("sinTest", 100, 0x08, 4000, sinTest) /* OR without the Floating Point Option */ -> sp sinTest -> irint_count Bus Error Program Counter: 0xb0ac0124 Status Register: 0x3004 Access Address : 0xb0ac0120 Special Status : 0x01e6 Task: 0xfcb82c "sinTest" The answer: Submitted-by wrs!yuba!kent@uunet.uu.net Fri Sep 27 18:55:25 1991 Submitted-by: wrs!yuba!kent@uunet.uu.net (Kent Long) > In the function irint, there is a bug that sets the floating point > Exception enable byte register to random values. Here is the > disasembled code: > > _irint: > 00e034 4e56 0000 LINK .W A6,#0 > 00e038 f227 6b80 FMOVE .X F7,-(A7) > 00e03c f22e 5780 0008 FMOVE .D ($8,A6),F7 > 00e042 f22e 6380 0008 FMOVE .L F7,($8,A6) > 00e048 202e 0008 MOVE .L ($8,A6),D0 > > 00e04c f201 9000 FMOVE .L D1,# > 00e050 504f ADDQ .W #8,A7 > 00e052 4e5e UNLK A6 > 00e054 4e75 RTS > > Line 0e04c is the line that sets the FPCR to some random value, > as D1 is unknown going into the function. I rewrote the routine, > without line 0e4c, and everything works fine. > If anyone out there knows why this line was put in, I would > appreciate knowing. Hope this may keep someone else from spending > a couple of days tracking down this problem. I have confirmed that this is a bug in all 5.x versions of VxWorks for the 68k. (In fact, it's in 4.0.2 as well.) As Mark correctly observed, the problem is that the FPCR register is erroneously being set. This was a simple cut-and-paste error in the VxWorks source module. The line which sets the FPCR should instead be restoring the value of FP7, which was saved on the stack earlier (as you can see in the code above). So, it would appear that another side effect of this bug is to clobber FP7. The fix is pretty simple. The following patch scripts should get things back to what they should be. (You can just include the appropriate lines in your startup script, or enter them from the VxWorks shell.) For VxWorks 5.0.1 and 5.0.2: pMathPatch = mathHardIrint + 0x18; *pMathPatch = (short) 0xf21f; pMathPatch = mathHardIrint + 0x1a; *pMathPatch = (short) 0x4b80; This bug does NOT affect VxWorks 5.1. The disassembled code for Vx5.1, (HK68K/V3D) is: _mathHardIrint: 2042e58 4e56 0000 LINK .W A6,#0 2042e5c f227 6800 FMOVE .X F0,-(A7) 2042e60 f22e 5400 0008 FMOVE .D (0x8,A6),F0 2042e66 f22e 6000 0008 FMOVE .L F0,(0x8,A6) 2042e6c 202e 0008 MOVE .L (0x8,A6),D0 2042e70 f21f 4800 FMOVE .X (A7)+,F0 2042e74 4e5e UNLK A6 2042e76 4e75 RTS Kent Long further clarifies, This was indeed a real problem in the context switch code in 5.0.x which was corrected in 5.1. In both OS versions, there is an optimization that causes the FP context to be swapped only when the incoming task has been spawned with the floating point (VX_FP) flag set. In 5.0.x, the copying-in of the FP context was done via an fppSave() call. This created problems if a new FP task was created after a previous FP task had been pre-empted by a non-FP task in the middle of an instruction. The new task ended up with a mid-instruction context (which causes the protocol violation), and the old swapped-out FP task ultimately ended up with its context set to IDLE (which is equally incorrect). In 5.1, the FP context initialization was changed so that when a task is created, a pre-defined IDLE frame is copied into that tasks's context. Since there is no assumption about current FP state (as with fppSave), task creation is now decoupled from the regular switch logic. - ------------------------------ 32. What are +T, +I thingies in the "i" output? The following is an excellent description of all these symbols by many people on the net, including "Fred J. Roeber" and others: Description Status symbol ===================================== =============== and task's priority inherited + I Delayed and suspended DELAY+S Pended and suspended PEND+S Pended and Delayed PEND+T Pended, delayed and suspended PEND+S+T The DELAY state indicates that the task has done some sort of delayed call while PEND means the task has done something that caused it to block like trying to semTake a semaphore someone else was holding. PEND+T means that the task is both delaying and pending; it has done a semTake with a timeout. +I means that the task has (temporarily) inherited a higher priority through the use of a mutex semaphore. The priority inheritance protocol also accounts for the ownership of more than one mutual exclusion semaphore at a given time. A task in such a situation will execute at the priority of the highest priority task blocked on any of the owned resources. The task will return to its normal, or standard, priority only after relinquishing all of the mutual exclusion semaphores with the inversion safety option enabled. If you use nested mutex semaphores with priority inheritance turned on then when a task inherits a high priority due to some inner semaphore it owns, it doesn't lose that priority until it relinquishes all the semaphores it holds. This doesn't quite follow the rules for priority inheritance (to the extent that there really are any rules) in that normally, a task's inherited priority should decrease as it releases each nested semaphore to whatever the priority ceiling is for the semaphores it still holds. Getting this incremental priority reduction to work right in practice, though, is extremely difficult (some of the SUN papers on the Solaris real time scheduling indicate that this was one of the hardest things for SUN to get right in their OS upgrades). Given that VxWorks is a real time embedded OS, I, for one, don't care if WRS uses the current implementation even though it isn't "pure" because the result is a more reliable implementation that runs more deterministically. Anyway, my guess is that you will find that you have some nested semaphore code where you are doing something after releasing one of the nested semaphores that shouldn't be done at a high priority. - ------------------------------ 33. Gotchas w.r.t watchdogs watchdog handlers run at interrupt level. You should not use routines that can block in interrupt level code. Frequent mistakes: using printf() in watchdog routines -- use logMsg() instead. - ------------------------------ 34. Is it possible to delete a memory partition in VxWorks? No. memPartDestroy() is not really implemented. Perhaps it will be in the future. Currently it just returns ERROR. - ------------------------------ 35. rename() does not work in netDrv and nfsDrv filesystems, why? Because rename() is not implemented for netDrv (although it could be), and nfsDrv does not implement rename() completely either. Talk to WRS to get these fixed. - ------------------------------ 36. Free NFS Server for VxWorks A free, incomplete, sample implementation (i.e. hack) of NFS Server for VxWorks is available in: netcom.com:/pub/hjb/vxnfsd.tar.gz There is a README file there that describes further details. The current snapshot of this implementation is a result of a couple of days of hacking, doesn't do everything right, and intended for educational and further hacking purpose. There is someone else who's porting the MS-DOS PC-based nfs server (SOSS?) to VxWorks. Not clear on its availability yet (let me know!) - ------------------------------ 37. Free SNMP for VxWorks hoff@bnlux1.bnl.gov (Lawrence T. Hoff) reports, We ported the CMU SNMPv2 code to vxWorks 5.1. This latest round of posts has prompted me to put it in anonymous ftp (ctrldev1.rhic.bnl.gov -- 130.199.96.82). SNMP Research sells VxWorks compatible port of their SNMP implementation with support. Their's cost $$$$$, though. - ------------------------------ 38. What third party products are available for VxWorks? I tried to include the third party products, list of consultants, services, goodies, etc. available for VxWorks from various sources but... there are too many to list here. Instead, the file: netcom.com:/pub/hjb/vxworkers.gz is updated in realtime to contain a list of individuals and companies that offer help, services (paid or unpaid), and goods for VxWorks. To get a copy (if you don't have ftp access) or to be listed in this file, please contact or send info in ASCII to: hjb@netcom.com. - ------------------------------ 39. What kind of products have been developed using VxWorks? - Flight simulators - Radio and optical telescopes - Automative ABS & realtime suspension - Naviation systems - Deep sea instrumentation - PBXs - Traffic lights - Modems - Sonar systems - Comm/weather satellite test equipment. - X terminals - PostScript laser printers - --------------------------------- 40. A complete list of CPU hardware supported by VxWorks Complete list of WRS supported BSP's are available in: netcom.com:/pub/hjb/vxbsp.gz VxWorks runs on a lot of different hardware. Majority of hardware supported is based on VME bus. Porting VxWorks to a new VME board based on MC68K takes only a few days, give or take a week, depending on your karmic condition at the time. A lot of the ports are initially done by the customers and later "approved" by WRS, for which they charge, in order to keep them on "supported" list. Porting to a new "architecture" (new processor) takes longer. This varies more widely -- from a few months to a few years. - --------------------------------- 41. A complete list of peripheral devices supported by VxWorks Complete list of WRS supported BSP's are available in: netcom.com:/pub/hjb/vxbsp.gz VxWorks supports a wide variety of devices. A lot of device drivers are written both by customers and WRS staff. There are device drivers for almost popular available ethernet chips (except perhaps SEEQ and Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async COMM chip, etc.), little I/O thingies in micro-controllers (MC68302 serial I/O, etc.), SCSI, etc. Customers of VxWorks, hackers and other hardware vendors (especially VME) usually have a VxWorks driver for their board. There are drivers for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers, frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch toy games. A list of available device driver for VxWorks can be found in: netcom.com:/pub/hjb/vxdrivers.gz - ---------------------------------- 42. What's with these unbundled "accessories"? Propaganda from WRS: The new product/feature doesn't need to wait for the next OS release. Only the users who want/need it pay for it lengthens price list which keeps individual items lower but still enhances WRS revenue growth. Please Note: WRS still always adds features to the core product, and has never taken items out of core product to make them unbundled. Unlike UNIX vendors and others. - ----------------------------------------- 43. How come my 5.0.2 BSP isn't available in 5.1, damn it? Propaganda from WRS: WRS tries to give customers 1 year warning when any product may be discontinued. Unfortunately, all the bugs in the notification system are still to be worked out. Complain vehemently to your sales rep. if he didn't keep you informed. WRS BSP obsoletion policy is primarily based on BSP volume and h/w avalability. The 5.1 Guide and Release Notes provide a step by step recipe to upgrade from 5.0.2 -- minimal changes, start by ANISifying. The BSP Port Kit 1.1 provides extensive info for the masochist. - ---------------------------------------- 44. How much is VxWorks? In general: Not free, in fact, quite the opposite. - Development License $23.5K (per project?) - Source $120K. - Target Licenses from $1000 for single quantity to $10 for 100,000+. - ------------------------------ 45. What is MicroWorks? VxWorks is also available as a kernel-only product (MicroWorks 1.0) for the following processors: i960, 680x0, 683xx MicroWorks is -- half the product at a half the price. It has no network, native debug, shell, or profiling. Comes with VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0 also included -- this is the debug agent which allows true system level debugging in ISR or wherever. In future, VxWorks may also be able to work with VxMon. Development License $12,500. - ------------------------------------ 46. Other Unbundled Products for VxWorks? Other unbundled "accessory" products are: VxMP ($4K) which is an extended shared memory capabilities for the kernel allowing semaphores and other objects to be manipulated over the backplane transparently (really!). VxVMI ($3K) is a library of virtual memory interface routines allowing text & kernel data protection. complementary products: BSP Port Kit 1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++ Gateway for ObjectCenter ($?K's), and Realtime Innovations StethoScope (3K). - ----------------------------- 47. How can I find out more about VxWorks? Read: comp.os.vxworks Email: inquiries@wrs.com Call: 1-800-KIK-WIND - ------------------------------ 48. What other net.resources are available on real-time systems? There is at least one other newsgroup devoted exclusively to a particular vendor's real-time operating system: comp.os.os9 Discussions about the OS/9 operating system. Here are some other related newsgroups: comp.arch Computer architecture. comp.arch.bus.vmebus Hardware and software for VMEbus Systems. comp.os.misc General OS-oriented discussion not carried elsewhere. comp.realtime Issues related to real-time computing. comp.os.os9 Issues related to OS9 and OS9000 realtime OS. There are too many other newsgroups devoted to computer operating systems to list here. The interested reader is advised to check the "newsgroups" file on a local news service machine. The automatic server for users of pSOS RTOS is now in place. PSOSUSER - A list intended for the discussion of topics relating to pSOSystem and other products of Integrated Systems Inc., Software Components Group. Send articles to psosuser@isi.com and administrative requests to listserver@isi.com. If you aren't already subscribed and would like to, please send a mail message to listserv@isi.com containing the following in the body of the message SUBSCRIBE PSOSUSER - ------------------------------ 49. How do i use FIONBIO in 5.0.2 when there is no fcntl()? Use ioctl() instead. ... { ... int on = 1; /* turn it on */ ... ioctl(fd, FIONBIO, &on); ... } - ------------------------------ 50. Free lex and yacc for use with VxWorks John Winas (winas@phebos.aps.anl.gov) writes, I just (moments ago) uploaded the two packages to thor.ncar.ucar.edu where the vxWorks archive is. When ever the maintainer moves it into the release area they will be available to everyone. I named the file lexyacc.tar.Z and it contains all of the sources and make files for you to build them. It all seems to work perfectly on my sun sparc running 4.1.3. The only thing you have to configure is the full path name to where you wish to keep flex so that it can find its skeleton file when you use it to lexify your .l files. Byacc has no skeleton files and simply needs to be in your path. This file is now available in: epics.aps.anl.gov:/pub/lexyacc.tar.Z I am interested in any bugs found in because we are using them here. Feel free to email me at winans@phebos.aps.anl.gov. - ------------------------------ 51. timer_gettime() bug [ From: kent@wrs.com (Kent Long) ] In article <9311230139.AA21147@focal.com> bobk@focal.com (Bob Klawuhn) writes: >I am currently trying to user the timerLib to obtain >the amount of time that a timer has left before it >expires. I am trying to use the timer_gettime function. >The value that it seems to return is always the time >that the start timer was given, not what is left on the >timer. This is indeed a bug in the 5.1 and 5.1.1 VxWorks versions. It is now being tracked as WRS SPR #2673. As a workaround, the following could be done following the timer_gettime() call, to convert the erroneous results into the desired remainder value: #include "private/timerLibP.h" struct timespec timeNow; (void) clock_gettime (CLOCK_REALTIME, &timeNow); TV_SUB (timerid->exp.it_value, timeNow); ...which leaves the remainder in it_value. - ------------------------------ 52. bogus INCLUDE_TCP_DEBUG [ From: hipp@wrs.com (Emily Hipp) ] >Bus Error >Program Counter: 0x0001c738 >Status Register: 0x3000 >Access Address : 0xbfbfbfd3 >Special Status : 0x0505 >Task: 0x3dcc54 "tExcTask" >TCP tracing not enabled (use INCLUDE_TCP_DEBUG). This is misleading information. INCLUDE_TCP_DEBUG is not supported as a configAll.h include option. [ editorial: INCLUDE_TCP_DEBUG never got integrated into VxWorks config files. To get around this bug, until WRS fixes it, either unset SO_DEBUG socket option using getsockopt()/setsockopt(), or call tcpTraceInit() (sp?) which will drag in tcp_debug.o and set the tcp_trace() routine to be called when debug option is set on TCP sockets. ] - ------------------------------ 53. free ppp for VxWorks Is available via anonymous ftp netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz - ------------------------------ 54. how to disable cache on mc68040 or mc68030 using TT regs? [ From: Steve Morris ] /**************************/ /* for 68030 (e.g. mv147) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_tt () { register int *pVal; int ttVal; pVal = &ttVal; ttVal = TT0_VALUE; asm ("pmove %0,tt0" : : "g" (*pVal)); ttVal = TT1_VALUE; asm ("pmove %0,tt1" : : "g" (*pVal)); } /**************************/ /* for 68040 (e.g. mv167) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_dtt () { asm ("movec %0,dtt0" : : "r" (DTT0_VALUE)); asm ("movec %0,dtt1" : : "r" (DTT1_VALUE)); } - ------------------------------ 55. work-arounds for MS-DOS filesystem bug when lseek() past eof [From: georg@sgl.ists.ca (Georg Feil)] [editorial: This is a workaround for the bug in VxWorks ms-dos implementation which produces incorrect error return on write() after lseek() beyond eof. N.B.: VxWorks versions upto 5.1.1 have buggy IO system layer that does not support "correct" write() to normal files. When writing to a file via write() expect to check the return value even if it is not ERROR. Unlike most other systems (e.g. UNIX) VxWorks write() upto version 5.1.1 will return number of bytes actually written even when write() was not completely successful on devices that are not marked non-blocking and/or are subject to flow control. ] There's been enough heated debate on this so I'm sending out my brute force workaround. Thanks to Kent Long who managed to let slip enough information on the bug to identify the prerequisite: lseek() past the end of file. My workaround simply extends a file by writing 0's on the end whenever there is a seek past the end. (This may result in a file being extended when it shouldn't have been, i.e. no write follows the seek, but what the hell.) Use file_seek() below instead of lseek() to seek. Note that file_seek() is not meant to be plug-replaceable with lseek(), that feature is not required in our system. 'zero8k' is a character array of 8192 zero bytes. int file_seek(int fd, int offset) /* * Sets the byte offset for the next write or read from a file. * Simple interface to lseek() function. This returns ERR_NONE iff the actual * actual seek offset returned by lseek() exactly matches the desired offset. * 'fd' is the file descriptor to seek on. * 'offset' is the absolute file position to seek to in bytes, where 0 is * the beginning of file. * Return value is error code (not a VxWorks error code, another type). */ { STATUS st; struct stat filestat; /* file status info obtained from fstat() */ int aoff; /* actual seek offset returned by lseek() */ long int fillsz; /* (***) for SPR #2739 kludge */ long int fillamt; /* (***) for SPR #2739 kludge */ if (FileDebug && Verbose>=2) { wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n", offset,fd); } /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with transfer count too low but errno not set after seeking past current end of file). Note that this may extend the file prematurely, i.e. even if no write() calls follow the seek. */ /* get current file size */ st=fstat(fd, &filestat); if (st==VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n", fd, vw_errmsg(0)); } return(ERR_VXIO); } /* manually extend file using zero writes if seek offset past end of file (note: tried ioctl() with FIOTRUNC, but this only works to shorten files! */ if (offset>filestat.st_size) { /* seek to the end of the file first */ errno=0; aoff=lseek(fd, filestat.st_size, SEEK_SET); if (aoff != filestat.st_size) { /* returned value should always match 'filestat.st_size' */ if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n", fd, aoff, filestat.st_size, vw_errmsg(0)); } return(ERR_VXIO); } /* fill file with zeroes to bring length up to 'offset' */ fillsz=offset-filestat.st_size; while (fillsz>0) { if (fillsz>8192) fillamt=8192; else fillamt=fillsz; errno=0; aoff=write(fd, zero8k, fillamt); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } if (aoff != fillamt) { if (Verbose>0) { wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n", fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0)); } return(ERR_VXIO); } fillsz -= fillamt; } /* flush the output to disk immediately */ st=ioctl(fd, FIOFLUSH, 0); if (st!=VX_OK) { if (Verbose>0) { wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } } /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */ errno=0; aoff=lseek(fd, offset, SEEK_SET); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n", offset, fd, vw_errmsg(0)); } return(ERR_VXIO); } /* returned value should always match 'offset' */ if (aoff != offset) { if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n", fd, aoff, offset, vw_errmsg(0)); } return(ERR_VXIO); } return(ERR_NONE); } - ------------------------------ 56. TCL for VxWorks [ From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) ] Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz If you've ever been frustrated that the VxWorks shell is not re-entrant, and has no control flow (e.g. if then else, switch, case ), then you will find TCL very useful since it is a very complete language, that allows you to add your own application specific commands to the interpreter. I find it invaluable for system testing, since I register TCL commands for all major functionality of my real-time application. This allows me to test most pieces of my data acquisition system from a command line, and build nice flexible scripts to test and operate my system. As a matter of fact, I can even invoke specific methods of C++ classes via TCL. Also, you can control your real-time system from a Unix workstation by sending TCL commands from either a TCL or Tk/TCL application (via tclTCP). I find that sending TCL commands (which are just strings) is much easier and more flexible than writing a Remote Procedure Call (RPC) for each piece of functionality that I need to remotely invoke. - ------------------------------ 57. adding default route A default route is a route table entry with destination field set to 0. To do the equivalent of "route add default gateway metric" in VxWorks, do: routeAdd("0",addr_of_gateway); - ------------------------------ 58. adjusting network driver MTU size VxWorks network driver are compatible (mostly) with tahoe BSD drivers. To change MTU you should modify "if_mtu" field of "struct ifnet" you pass to ether_attach() or if_attach(). - ------------------------------ 59. tcpdump like utility for vxworks Take a look at a hacked up packet trace program in: netcom.com:/pub/hjb/vxsniff.c.gz [editorial: if you have something better, let me know] - ------------------------------ 60. VxWorks performance on i960 -- unofficial benchmark [ From: djanssen@mswe.dnet.ms.philips.nl (Ton Janssen, 62203 (TSSW)) ] We did some measurements on a Heurikon HK80/V960E. Equiped with I960CA on 33MHz. Here they are: Test-item Conditions Time in us ========================================================================== - - semGive/semTake pair (binary semaphore) 11,2 - - taskSpawn (+/- 8 processes active) 790,0 - - taskIdVerify 0,72 - - taskSuspend/taskResume pair (+/- 8 processes active) 32,6 - - lstAdd/lstDelete pair (10 nodes in list) 3,9 - - msgQNumMsgs 1,2 - - msgQReceive (NOWAIT, no message available) 16,8 - - rngBufPut/rnBufGet pair (0x20 bytes) 24,5 - - msgQSend/msgQReceive pair (NOWAIT, no arguments) 65,7 - - bcopy (Quad aligned data) 0,515/Quad - - mutliply two floats (depends on the value!) 1,6 - - multiply two doubles ( '' '' ) 2,6 - - Raw context switch (8 processes active) 34,0 - ------------------------------ 61. VxWorks SCSI Performance -- unofficial benchmark [ From: mea@mclean.sparta.com (Mike Anderson) ] System : Heurikon HK68G/V4D (33 MHz 68040, 16 MB RAM, NCR53C710 SCSI w/ Hk SCSI DMA routines in Asynchronous SCSI mode) VxWorks : 5.1.1 (Yes, using Heurikon VxWorks 5.1 BSP) Disk : Seagate ST11200N (1 GB SCSI) File System: VxWorks RAW partition mounted as "/sd1/" Clock Rate : 60 Hz Approach: My application has the data coming in in 16Kbyte chunks. So, I devised a piece of test code that would allow me to specify how many 16K chunks I sent to the disk in each write and how many total bytes to write. The actual number of bytes written is generally a little larger (typically one more block size) due to the quick and dirty way I wrote the code, but the calculations are based on the actual number of bytes written to the disk. The technique I used was to write a block to the disk starting at the end of the last write and then seek back to relative zero and write the current pointer (just as I would in real life to know how many bytes had been streamed total). Also, you may notice the disk seek time coming into effect in the 200MByte files. Here are the results: Buffer Size Total Requested Bytes/sec total secs 16K 1024000 (1 MB) 1,032,192 1.000 secs 10240000 (10 MBs) 1,036,087 9.883 secs 102400000 (100 MBs) 1,049,538 97.566 secs 204800000 (200 MBs) 1,043,123 196.333 secs 32K 1024000 1,613,193 0.650 secs 10240000 1,627,997 6.300 secs 102400000 1,627,980 62.900 secs 204800000 1,610,485 127.166 secs 48K 1024000 1,935,360 0.533 secs 10240000 1,994,712 5.150 secs 102400000 1,992,209 51.416 secs 204800000 1,970,335 103.950 secs 64K 1024000 2,169,467 0.483 secs 10240000 2,244,905 4.583 secs 102400000 2,246,332 45.600 secs 204800000 2,216,450 92.400 secs 96K 1024000 2,495,409 0.433 secs 10240000 2,580,480 4.000 secs 102400000 2,571,534 39.833 secs 204800000 2,533,374 80.866 secs 128K 1024000 2,621,440 0.400 secs 10240000 2,761,250 3.750 secs 102400000 2,771,147 36.983 secs 204800000 2,726,693 75.133 secs 256K 1024000 2,859,752 0.366 secs 10240000 3,130,077 3.350 secs 102400000 3,139,304 32.650 secs 204800000 3,083,428 66.483 secs 512K 1024000 3,145,728 0.333 secs 10240000 3,346,519 3.133 secs 102400000 3,361,846 30.566 secs 204800000 3,298,416 62.150 secs 1024K 1024000 3,311,292 0.316 secs 10240000 3,475,942 3.016 secs 102400000 3,487,345 29.466 secs 204800000 3,416,806 60.150 secs - ------------------------------ 62. VME bus arbitration gotchas [ From: mea@mclean.sparta.com (Mike Anderson) ] > Sender: Rob Steele, e-mail: steele@telerobotics.jpl.nasa.gov > > > I have the following VME hardware configuration: > > VME MOTES chassis: > 1 Motorola system controller card, > 6 Huerikon 68020 CPU boards (HKV2A), > 1 Micro Memory shared memory cards, > 1 Bit-3 memory interface card, > 2 XYCOM parallel boards, and > 1 Excelan ethernet cards. > > VadsWorks 2.0.1 (equivalent to vxWorks 5.0). > > I am unable to consistently boot the chassis. I will get bus errors and file > not present errors during the boot process on different boards. On rare > occasions it will boot. To get it to boot I halt the boot process on the last > 4 boards in the chassis and let the first two boot. After that I boot the > last 4 one at a time. > This sounds like the bus arbitration bug biting. If the Heurikon boards are all at the same bus grant level (they typically come from the factory set for BG3) then you will experience "random" failures that manifest themselves as bus errors when a board is requesting access to the bus and the bus is so busy that the bus watchdog timer (1.6ms on the HKV2F I think) expires. This is proper behaviour. The watchdog timer is designed to alert the task that it was unsuccessful in accessing a VME address in the alotted time and to signal that failure with a bus error. Now, there are several ways to fix this problem. One which I heard about was to modify the boot ROMs to insert a variable length delay so the first CPU booted immediately, the second booted 30 secs later the third 60 secs later, etc. This approach was clearly a software hack trying to get around a hardware problem that was obviously not understood. This approach *may* get the boards to boot, but with heavy bus traffic during execution, they will continue to exhibit bus errors. You see, because the VMEbus is a daisy chain, the first CPU in the chain has an inherently higher priority than all others that follow it. The 2nd board gets the next highest priority, etc. This means that a graph of bus access at a given BG level looks something like this: % 60 | | A 50 | * | C 40 | | C 30 | | * E 20 | | * S 10 | | * S 0 |------------------*---*-- 1 2 3 4 5 6 # CPUs @ BG level I.e., it is roughly an exponential decay such that, given that the level of bus activity is moderately high, the first 1-3 CPUs will hog 85-95% of the bus cycles and CPUs 4 and beyond will exhibit bus errors. If the bus activity level is very high such as during a boot up via the backplane, you may not be able to get past CPU 2 before bus errors manifest themselves. Now, as I said, there are other ways to circumvent this problem. Boards equipped with the VIC68 VMEbus interface, for instance, can have their bus timeouts changed to the point of an infinite wait (i.e., the bus watchdog is disabled). This is still just a kludge that masks the real problem of a poorly thought-out arbitration scheme. With this approach, *real* bus errors resulting from errant pointers and/or failed boards are never reported and the system just seems to hang. The REAL solution to this problem is to adjust the arbitration levels of the CPUs. In the VMEbus, there are 4 levels of arbitration (0-3) where level 3 is the highest priority. By default, virtually all manufacturers ship their boards configured for BG3. Therein lies the problem. What the real-time designer needs to do is to realize this and make adjustments. Within the 4 BG levels, there are two modes of operation: 1) priority and 2) round robin. Priority mode means that requests at level 3 will be honored before requests at level 2. Level 2 before level 1 and so on. This means that with priority mode arbitration, put your highest priority boards at level 3 and distribute the other boards at the other levels according to their relative priorities. On the other hand, round robin arbitration mode means that all 4 BG levels are treated equally and each level gets a fair slice of the pie so to speak. Use this mode when you have lots of boards, but no one has an inherently higher priority than any other. With this approach, we've been able to get as many as 16 CPUs running in the same backplane (4 at each level) without experiencing bus error problems due to arbitration. Remember, just because the boards are at different BG levels doesn't circumvent the implied priorities of the CPUs at the *same* level based on the bus daisy chain. Typically, these modes are configurable on the system controller either through a jumper, PAL or software bit twiddling. However, there are boards that are hardwired for arbitration level 3 and they can't be changed. The Force SPARC 1E board is one of them. This means that you'll have to use these boards sparingly in VxWorks chassis (i.e., probably no more than 3-4 booting up from the backplane but probably more if you boot each of them up from local Ethernet). I understand that the SPARC 2CE board uses the same VMEbus interface as the 1E which simply means that the bus errors will happen twice as fast. Hopefully, the 3E board will get a real bus interface on it if it ever comes out. - ------------------------------ 63. 5.1.X new MMU supporting code gotchas, as explained in the Manual Carl Lacy points out: 1) Programmer's Guide, Chapter 8.3, page 319 How to setup the the MMU for VMEbus address spaces 2) 5.1 Known Problems, Apr '93, page 5 "Several BSPs turn on basic MMU support ... even if this option is not specified in configAll.h" - ------------------------------ 64. "Cannot Boot. Error 0x1a9" while downloading/booting This is usually due to the built-in 'feature' inside UNIX inetd program. The inetd tries to protect itself against clients that tries to connect too often too quick as a security measure, and disallows more than a certain number of connections per given period. When this happens, you will usually see some error messages about "looping..." in syslog (if your syslog is configured correctly) on your UNIX server (where inetd is running). You can either try "kill -HUP inetd_process_id" to get out of this looping mode by sending HUP signal to inetd, or try and install the patched version of inetd that has larger default limit for looping detection (some OS vendors will supply this to you), or just get a copy of BSD UNIX distribution of inetd source code and compile it with larger default values for looping and use it instead. - ------------------------------ 65. problem with qsort in some versions of VxWorks Some version of VxWorks are shipped with incorrect qsort(), to remedy this problem, get a copy of qsort() from BSD UNIX distribution and compile it. - ------------------------------ 66. fmod fiasco From: jbrandt@sadira.gb.nrao.edu (JOE BRANDT) remainder = fmod(value, divisor) - floating point modulus routine. The fmod math subroutine for MC68040 (mv167) based systems has been a topic of discussion on the exploder for many months now. The first discussions centered around the routine's accuracy (or even correctness). Recently I found that the execution time for the fmod subroutine is highly dependent upon the ratio of the values passed as arguments. At a ratio of about 50,000 I was seeing execution times of 30ms! The VxWorks exploder FAQ now includes a proposed replacement routine for 68040 systems, however, I have examined this routine and found it to be grossly in error in cases where the divisor is less than 1.0. Fortunately, I have found public domain source, authored by Sun Micro, for an alternative algorithm. This algorithm claims an exact result. It can be found at: ftp: plan9.att.com in /netlib/fdlibm/e_fmod.c.Z (I believe ftp.uu.net has copies also). This appears to be a ieee 754 compliant routine. (I'm not sure what that means, but it sounds good). Execution times for this routine are in the range of 7.6 to 100 usec's. From: vince@rti.com (Vince Chen) > Submitted-by jbrandt@sadira.gb.nrao.edu Thu Mar 24 12:41:16 1994 > Submitted-by: jbrandt@sadira.gb.nrao.edu (JOE BRANDT) > > While I currently am not questioning the accuracy of the fmod() function, > the performance of it on the mv167 card (68040) is certainly an issue. > > Here's some benchmarks from my 5.1/mv167 system: > > -> timexN(fmod, 49999.9, 1.0) > timex: 25 reps, time per rep = 30661 +/- 666 (2%) microsecs > > -> timexN(fmod, 2.0, 1.0) > timex: 50000 reps, time per rep = 9 +/- 0 (0%) microsecs > > -> timexN(fmod, 499.9, 1.0) > timex: 2525 reps, time per rep = 305 +/- 6 (1%) microsecs > > Note the dependency on value. Unfortunately I am doing an fmod on the > modified julian date (which is currently in the 50,000 range). which > took an amazing 30ms/call ! > > Wow, can some elaborate on the algorithm being used here. seems like it's > a straight while loop! I believe it is a while loop. A while loop is faster in some situations, but obviously no in yours! Until WindRiver resolves the problem w/ the Motorola Floating Point Exception library, you may want to roll your own on this one. The code below on our 167/25MHz VxWorks 5.1 consistently results in 30 usecs. double myfmod1( double arg1, double arg2 ) { return (arg1 - ((int) (arg1 / arg2)) * arg2); } - ------------------------------ 67. MVME167 copyback cache and various problems From: georg@sgl.ists.ca (Georg Feil) Well, I think we now know everything there is to know about the memPartFree() problem we were having. The original subject here was "memPartFree error with copyback caching enabled (167)". Other past subjects that possibly related to the same problem include "Large disk writes w/cache cause MVME167 to freeze". Apparently the root cause is a snooping problem related to TAS on the VME bus, and is Motorola's fault. The solution to the problem is the "MV167 VME TAS patch" from Wind River. It consists of a number of configuration changes (config.h, usrConfig.c etc.) and is reproduced below. Strangely, it has not been assigned an SPR number because, according to Wind River, the new version of the 167 BSP has fixed the problem so no SPR is necessary(?). This situation may have changed since the memos I received were written. Our related TSR number was 16443, which may help others to track things down. I had already come up with my own patch that worked in a completely different (and very specific) way, and the WRS patch seemed not to apply to our problem. However I tested the patch anyway and sure enough it fixes our problem. As a bonus, SCSI performance seems to have improved slightly. - ------------------------------ 68. unloading objects From: stan@rti.com (Stan Schneider) Under VxWorks 5.1.x, you can use 'unld "file.o"' (or use the module id, see "moduleShow"). Under 5.0.x, you can't unload the object & reclaim the space, but you could remove the symbols from the symbol table with symRemove. That would prevent unnecessary maiming. - ------------------------------ 9999: Contributions to comp.os.vxworks FAQs. The following net.folks, among others, have contributed to this posting: [ If you have contributed, but are not listed here please me know. ] Name email address ------------ ---------------------------- Mike Anderson mea@mclean.sparta.com Mark Linimon linimon@nominil.lonestar.org Geoff Espin geoff@wrs.com Rev. Bob Crispen crispen@foxy.boeing.com Stan Schneider stan@rti.com Fred J Roeber fjr@ssd.ray.com Marc Friedman maf@verdix.com Joe Van Andel vanandel@ncar.ucar.edu Emily Hipp hipp@wrs.com Bob Marino ram@mr.picker.com Richard Kowalsky cmdorat@tc.fluke.com Kent Long kent@wrs.com James Moore james@wrs.com Chuck Meade chuckm@verdix.com Patrick T. Pinkowski ppinkow@jupiter.ksc.nasa.gov D'Anne Thompson dat@noao.edu Leonid Rosenboim leonid@rst.hellnet.org David Lim lim@robotics.jpl.nasa.gov Richard Neitzel thor@thor.atd.ucar.edu John Winas winas@phebos.aps.anl.gov Lawrence T. Hoff hoff@bnlux1.bnl.gov Georg Feil georg@sgl.ists.ca Steve Morris morriss@smtplink.indigo.co.il Don Brooks dab@netcom.com Ton Janssen djanssen@mswe.dnet.ms.philips.nl Brian Brunner brunner%mother@icarus.ssd.loral.com Carl Lacy lacy@draper.com Joe Brandt jbrandt@sadira.gb.nrao.edu Vince Chen vince@rti.com I welcome flames, insults, accusations, reactions, additions, and corrections to this posting via email: Hwa-Jin Bae PEACEFUL STAR hjb@netcom.com - ------------------------------ =============================================================================== - -- hwajin PEACEFUL STAR --------------------------- End of New-News digest ********************** From vx_list@mars.psf.ge.com Tue Apr 19 05:20:02 1994 From: vx_list@mars.psf.ge.com Date: Tue Apr 19 05:20:17 PDT 1994 Subject: Posting rejected Your posting to list VX_LIST was rejected. Reason: message size limit exceeded (maximum allowed: 65536 bytes) The first few lines of your message are included herein for reference: Submitted-by daemon@vxw.ee.lbl.gov Tue Apr 19 04:00:33 1994 Submitted-by: daemon@vxw.ee.lbl.gov Comp.Os.Vxworks Daily Digest Tue Apr 19 04:00:13 PDT 1994 Subject: reboot entire vme crate? Subject: Re: reboot entire vme crate? Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG] ------------------------------------------------------- From vx_list@mars.psf.ge.com Tue Apr 19 05:20:07 1994 From: vx_list@mars.psf.ge.com Date: Tue Apr 19 05:20:26 PDT 1994 Subject: Posting rejected Your posting to list VX_LIST was rejected. Reason: message size limit exceeded (maximum allowed: 65536 bytes) The first few lines of your message are included herein for reference: Submitted-by daemon@vxw.ee.lbl.gov Tue Apr 19 04:00:33 1994 Submitted-by: daemon@vxw.ee.lbl.gov Comp.Os.Vxworks Daily Digest Tue Apr 19 04:00:13 PDT 1994 Subject: reboot entire vme crate? Subject: Re: reboot entire vme crate? Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG] ------------------------------------------------------- From sstern@atl.com Tue Apr 19 14:58:13 1994 From: sstern@atl.com (Steven Stern) Date: Tue Apr 19 14:58:30 PDT 1994 Subject: DOS Partitioning hard disks from VxWorks 5.1 Hello: Does anyone have any code or information they would like to share regarding DOS partitioning hard disks from VxWorks 5.1? Thank you, sjs /=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\ | Steven Stern email: sstern@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7002 | | 22100 Bothell Everett Highway fax: (206) 486-5220 | | Bothell, WA 98041-3003 | \=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/ From daemon@vxw.ee.lbl.gov Wed Apr 20 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 20 04:00:38 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 20 04:00:14 PDT 1994 Subject: Re: ld error Subject: Please check your mailers! Subject: Re: HDLC for the 85230 Subject: Re: Questions About Real-time C++ VxWorks Embedded Systems Subject: MARKET SURVEY ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: ld error Date: Tue, 19 Apr 1994 16:46:02 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems Message-ID: References: Reply-To: james@wrs.com Sender: news@wrs.com (News Manager) billag@b4pphff.bnr.ca (Bill Gutknecht) writes: >-> ld < coatd >value = 3782388 = 0x39b6f4 >-> perror >S_objLib_OBJ_ID_ERROR ld() returns MODULE_ID, so the load is succeeding. The error number is left over from some earlier error in the task. - -- James Moore /|\ james@wrs.com Wind River Systems \|/ Alameda, California Why in the world is Volkswagen so obsessed with far fig newtons? --------------------------- Newsgroups: comp.os.vxworks Subject: Please check your mailers! Date: 19 Apr 1994 17:48:34 GMT From: thor@ymir.atd.ucar.edu (Rich Neitzel) Organization: National Center for Atmospheric Research Message-ID: <2p15hi$otu@ncar.ucar.edu> Sender: thor@ymir (Rich Neitzel) Periodically the archive's email server receives mail that does not have a fully qualified retrun host address. This causes the request to bounce. Some times I can figure out where the mail arrived from by looking at the sendmail log, but some mailers aren't even giving me enough to work on. For example: cadfael@decu16 Whoever you are, your mail isn't going to get answered! Please check with your systems administrator about this! - -- 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 Gjx'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: HDLC for the 85230 Date: 19 Apr 1994 11:07 PST From: waters@reg.triumf.ca (WATERS,GRAHAM) Organization: TRIUMF: Tri-University Meson Facility Message-ID: <19APR199411070474@reg.triumf.ca> References: In article , maillet@wrs.com (Al Maillet) writes... >Does anyone out there have an HDLC (synchronous) serial driver >written for the 85230 duart. Any help would be greatly appreciated. > > Al Maillet al@wrs.com > Wind River Systems, Inc. Southwest Application Engineer I have drivers/libraries and application software for the Siemens 82532 multiprotocal chip (SYNC/ASYNC serial communication HDLC/SDLC protocol). Maybe there is some compatibility. This is running well in our inhouse designed VME module running vxWorks for the mc68332. Graham Waters waters@reg.triumf.ca TRIUMF Control Systems Engineer. Meson Research Facility, 4004 Wesbrook Mall, Vancouver, B.C. Canada. V6T 2A3 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Questions About Real-time C++ VxWorks Embedded Systems Date: 17 Apr 1994 11:54:59 +1000 From: rjl@f111.iassf.easams.com.au (Rohan LENARD) Organization: EASAMS (Australia) Pty Ltd Message-ID: <2oq4tj$qvr@f111.iassf.easams.com.au> References: <9404151734.AA01489@atl.com> Hi there folks, In article <9404151734.AA01489@atl.com>, Dean Wampler (dwampl@atl.com) wrote: > >> Subject: Questions About Real-time C++ VxWorks Embedded Systems >> >> We are contemplating using C++ (CenterLine C++ & gcc) with VxWorks in a VME >> environment using 68030 or better. Our application will make >> heavy use of iostreams class library, NFS, sockets, etc. >> >> Are there any developers who would like to share their experiences of >> using C++ with VxWorks in a real-time environment? > >OK. > >> Can you brielfy describe your application(s)? > >A fairly large and complicated medical application using the 68k. > A fairly large aircraft avionics simulator using the 68k. >> What were the severe gotcha's? > >The file iostreams were broken in the beta of WindC++. It reflected a bug in >the implementation of multiple inheritance (a lesson for those who want to use >multiple inheritance!). I believe that the "V1.0" version is supposed to be >fixed. > We use gcc on its own, with support from Cygnus (info@cygnus.com), and have a fully working libg++ for vxworks. Infact we've built libg++ into our kernel, so we don't have to link against it. >> Have you found the CenterLine/gcc/VxWorks development environment to be stable? > >It feels like beta-ware, but it is stable enough. We are avoiding multiple >inheritance, for safety. Also, we decided not to use the template mechanism in cfront. It is confusing, slow, and the error checking seems to be poor. We >decided that it was too risky for our novice environment. Your mileage may >vary.... > With support from Cygnus we get fast patches to the compiler / libraries when their is a problem. IMHO WRS are not really interested in gcc for VxWorks (as a C++ compiler) as they've got other products of their own. >> >> What's been your experience with debugging the target using Vxgdb++ and >> CenterLine on the target. Any gotcha's or insurmountable problems. >> >It doesn't handle mangled names very well. For example, you can set a break >point in a C++ function, but to actually "run func", you have to use the >mangled version of the name. > I expect this will be fixed in a newer version of vxgdb. vxgdb is supported by cygnus (ie. they write the code for it and the rdb support for the kernel - - or at least that's what the source suggests). >> What 3rd party class libraries are you using? >> Booch Components, with lots of success. Had to add #pragma's everywhere to make them work with gcc, though. > >> Have you discovered any problems using 3rd party class libraries, i.e.: >> re-entrancy or thread-safe issues, other? >> The Booch Components provide classes which are guarded and synchronised. This allows you to specify different types of MUTEX's. I think guarded just prevents you reading when someone else is writing, but synchronised allows only on user in a critical section at a time. >Can't offer any help here. > >> Has anyone ported or used RogueWave class libraries with VxWorks? >> >I would like to try this one myself.... >> I seem to remember that RogueWave does not work with gcc, or something like that they wouldn't support it with gcc. > >Another point, I don't know if speed of compilation and size of code is >critical, but I think you pay a penalty in both areas if you use "cfront". >I can't really say how big the "size" penalty is, but compile times aren't >speedy. > Get a faster cross development machine :-). We're using HP700 series machines, and get very quick compilations consistantly. >Hope this helps. I think that I can safely recommend WindC++. Plan on spending >some time figuring it out and getting it working. Also, using ObjectCenter is >definitely recommended. We try to test our code on the Sun before downloading >to the target. On the Sun, you can at least use the full power of OC, while >only a subset is available on the Vxworks target. Even there, it offers many >advantages over vxgdb. > Not trying to be a spoiler, but I think that ObjectCenter has a reputation for getting very slow as the application size grows. However it does have some nice features... Regards, Rohan - -- - ---------------------------------------------------------------------------- rjl@iassf.easams.com.au | "In the beginning there was cave man, and he had a Rohan Lenard | club, which he used to seduce woman. Hence the +61-2-367-4555 | saying `not tonight dear I've got a headache'" --------------------------- Newsgroups: comp.os.vxworks Subject: MARKET SURVEY Date: Wed, 20 Apr 1994 03:17:06 GMT From: sngmedia@world.std.com Organization: The World Public Access UNIX, Brookline, MA Message-ID: We are a small, dedicated group of people desperately trying to get a video production company off the ground. Recently, we secured enough financial backing to produce several videos on the subject of personal computing. Because we don't have the financial resources to perform a traditional market analysis, we considered several alternatives and concluded that we should consult the people of the Internet, who are technically proficient and tend to be enthusiastic personal computer users. We would like you to indicate which three of the below described videos would appeal to you most. Please note that each video synopsis is numbered. When you are ready to send your response, please specify the numbers corresponding to your three video selections, and use commas to separate the numbers. For example, if you choose selections four, eight, and eleven, the body of your letter would simply be: 4,8,11 and nothing more. When you send back your response, please specify "MARKET SURVEY" in the subject field. Then, direct your response back to sngmedia@world.std.com. Please realize that this is not an advertisement, or solicitation. We simply would like to know your response. You will not be contacted further. Thank you in advance for your help and cooperation. Tom and Randi Fecker sngmedia@world.std.com. Please select three videos that interest you most: 1. The Internet Pilot's Guide A plain English guide to getting around on the Internet by veteran users. How to use Internet resources to send/receive e-mail, and to search for documents and files relating to a particular subject. How to use LISTSERVs, GOPHER, ARCHIE, WWW and WAIS. How to use FTP and Telnet to access remote computers for file transfers, remote logins, etc. Also, learning how to observe Internet's "netiquette." And how to access multimedia Mosaic bulletin boards. 2. How to Make Money at Home With Your PC I -- Successful PC-Based Businesses Meet five successful entrepreneurs who started their own home-based businesses using a PC. Includes businesses that provide typing services, mailing list management, horoscopes, bookkeeping, and even a software developer who does not know how to program -- he hires other people to implement his software designs. Includes ideas for two dozen home-based businesses you can start using your PC. 3. How to Make Money at Home With Your PC II: Portfolio Management. Whether you manage your own portfolio for investment gains, or you take on clients for a consulting fee, a PC can give you powerful tools for portfolio management. Meet three successful home-based portfolio managers who use their PCs to maximize profits. They'll inspire you, and share some tricks of the trade that can help you land clients and get started. We'll also show you how to determine which software applications will meet your needs, and which online services will satisfy your requirements. 4. How to Make Money at Home With Your PC III: Telecommuting Learn how to use your PC to telecommute to companies across America that are looking for specialized consultants with skills like bookkeeping, software design and programming, editorial and script writing, technical proofreading, graphic design, copywriting, and more. Includes interviews with three successful telecommuters who use their PCs, faxes, modems and phones to serve distant clients, and information about a telecommuting referral service that could help you find employers. 5. How to Upgrade Your Hard Drive, Step-By-Step From choosing your new hard drive, through ordering, installing and testing it. This plain English video shows you how to do the job correctly, one simple step at a time. Using industry-wide standards, we'll show you what all hard drives have in common. Includes how to determine if your controller will support a particular hard drive. How to remove the old drive, and install, format and test the new drive. Includes a discussion on the differences between the various standards. 6. How to Design Your Own PC You don't have to be an engineer to design and build the PC of your dreams. This plain English video shows you how to figure out the PC design that is best for you, how to specify components, how to make sure they'll work together, and where to buy them. You'll end up with a top quality system that will save you money. 7. How to Build Your Own PC Once you've designed your PC, we'll show you how to build it. The actual process will take you only a few hours. Using an easy-to- understand method, we'll show you how to inspect, install and test components. Includes tips and tricks from computer production experts. The technical skills can be easily mastered by almost anyone, and you probably already own most of the tools you would need. 8. How to Increase Your Computer's Memory This plain English video shows you how to determine whether your computer memory can be increased, and how to do the job correctly, one step at a time. You'll learn about industry-wide standards for memory, how to configure additional RAM and cache, how and where to buy RAM chips, and three ways to eliminate low-quality RAM chips. Covers all phases of the process from opening your computer, to testing your memory. Includes discussions on how to ensure your DOS set-up is able to access all available memory, and how to use various memory management software applications. 9. How to Use MS-Windows 3.1 This powerful graphical user interface can help you work smarter and faster, but the manual and the online tutorial that come with Windows leave many questions unanswered. This plain English, step- by-step video will show you how to install Windows on your computer and set it up to get optimum performance. 10. How to Find a Job in the Information Age A PC can give you an incredible advantage when you're searching for a new job -- or even a new career. But you have to know just how it can help you. In this video, an experienced employment counselor will show you how to tap the power in your PC to find job leads, create a winning resume and customized cover letters, tap into databases and find bulletin boards that will lead you to job openings, and use online services to research potential employers. 11. How to Install a Sound Card in Your Computer Here's how to add incredible stereo sound to your computer with step-by-step help. In plain English, you'll learn how to determine if your computer can support a sound card, how and where to buy a high-quality sound card. How to open your computer, and install and test the sound card. 12. How to Install a CD-ROM Drive in Your Computer Using simple tools, this plain English video shows you how to install a CD-ROM Drive in your computer. You'll learn how to make sure your computer can support a CD-ROM drive -- and what to do if it can't. Covers internal vs. external drives, how and where to buy a high quality CD-ROM drive, what you need to know about differing industry standards, preparing the drive bay, testing and trouble-shooting. Covers SCSI and IDE. 13. How to Fix the Most Common Computer Problems Your computer serviceman may not want you to know this, but all you need is the know-how you'll get from this video, simple tools, and easily-obtainable diagnostic software -- and you can fix most common problems you'll ever encounter with a PC. 14. What to Do When a Virus Strikes Your Computer Viruses can come from almost anywhere: a colleague or friend's disks, a network, a bulletin board, even commercial software. If you ignore the first warning signs, a virus can wipe out your data and permanently damage your computer's memory. In plain English, this video will tell you how to scan disks for viruses, how to check downloaded files from bulletin boards, how to set up a virus prevention program for your home or office computer, and how and where to buy the best anti-virus software. We'll also cover the pros and cons of the antivirus software in DOS 6.X and Windows 3.X, how to use antivirus software, and more. 15. How Your PC Works: Inside the Case Here's a down-to-earth explanation of how your PC actually processes information, and what really goes on inside the case. You'll get a guided tour of the insides of a PC, learn about how the various components work and how they communicate with each other, and get a clear explanation of technical terms. A must for anyone who wants to really understand how to program, use and repair a PC. 16. How to Create Config.Sys, Autoexec.Bat and Batch Files These basic files can make it much easier to use your computer -- or cause incredible headaches if they are not written properly for your particular software and peripherals. Now you don't have to be at the mercy of murky tech manuals, because we'll show you how to create files that work for your system -- step-by-step, in plain English. You'll learn how to write, modify and test Autoexec.Bat and Config.Sys files; and how to create batch files. 17. How to Add a Modem or Faxmodem to Your Computer Here's the easy way to add a modem or faxmodem to your computer, with step-by-step guidance from this plain English video. You'll learn how to determine if your computer can support a modem or faxmodem, and what to do if it can't, how to choose and buy the best modem or faxmodem, how to open your computer, and install the modem or faxmodem, how to test it, how to quickly eliminate common problems, and how to set your modem or faxmodem correctly. 18. How to Make Money at Home With Your Computer The information age is opening up incredible new opportunities for PC owners to make undreamed of money, using skills and knowledge you may already have! Here's inside information on the ten most promising telecommuting jobs and 12 small businesses you can run right from your home, using your PC. Includes profiles of PC owners who are actually running PC-based home businesses. 19. The Super-Highway Roadmap This is your guide to where to go and what to see. You can make incredible contacts and gather powerful, valuable information on the Internet, but the problem is that most people can't begin to imagine the potential of something that seems so abstract. This plain English video will introduce you to the Internet, and make these opportunities concrete. Includes interviews with 7 people who did the impossible by gathering information and making contacts on the Internet. 20. How to Upgrade and Repair Your PC I: Basic This is the video your repairman doesn't want you to know about! Since the components of most PCs are highly modular, PC repair is easier than you think. Just pinpoint the problem component, unplug it, remove a few screws, replace it, and presto! You're in business again. This step-by-step video shows you how to pinpoint problems and replace your PC's components, using ordinary household tools. 21. How to Upgrade and Repair Your PC II: Multimedia Here's how to save big money on a PC with all the latest multimedia peripherals. You learn how to determine if your PC can be upgraded, how to upgrade your video card and bus, and how to add a CD-ROM drive, sound card, video accelerator, and more. Presented in plain English. The procedures you'll learn require ordinary household tools -- nothing fancy! 22. Plain English Guide to DOS 6+. The powerful sub-programs buried deep within DOS 6.0 and higher can help you work smarter and faster, but the manual and the online tutorial that come with DOS leave many questions unanswered. This plain English, step-by-step video will show you how to install DOS on your computer and set it up to get optimum performance. In addition to DOS commands, you'll learn how to use the shell, defragmentation, scan and antivirus programs that come with DOS. 23. Home Financial Management on a PC. Your computer can help you create and manage a budget, keep track of your credit card accounts, handle your tax deductions, and reconcile your bank accounts. But that's not all! You can also determine whether you should pay down your mortgage, finance a new car or pay cash, buy or rent your home, and how much you'll need for retirement. The financial information your computer can give you might mean the difference between just getting by and a very comfortable lifestyle -- if you ask the right questions and use your PC to develop a financial strategy. 24. The Online Bulletin Board Guide Bulletin boards can be the on-ramps to the Information Super Highway -- if you know how to access and use them. This step-by- step guide shows you how to find bulletin boards, set-up your modem, log on, find out what they have to offer, find bulletin board users who share your interests, search for information, and upload and download files. Thank you. --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Thu Apr 21 04:00:28 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 21 04:00:41 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 21 04:00:14 PDT 1994 Subject: Re: WindC++ version of VxGDB on i960 does not work Subject: Re: More on C++ and Vxworks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: WindC++ version of VxGDB on i960 does not work Date: Mon, 18 Apr 1994 14:20:49 GMT From: ckolli@hns.com (Chakravarthy Kolli) Organization: Hughes Network Systems Inc. Message-ID: <1994Apr18.142049.8098@hns.com> References: <9404051135.AA09511@zoo.lannet.com> Sender: news@hns.com (USENET news system) In article <9404051135.AA09511@zoo.lannet.com>, kruk@lannet.com (Meir Kruk) writes: |> Hello, |> |> I have a question to you vxWorks/C++ users out there. Has anyone worked |> with the VxGDB on a C++ application? |> |> My problem is as follows: |> |> I have installed an evaluation copy of WindC++ 1.0 beta on Sun4 station |> running VxWorks 5.1.1 , for i960CA custom target. |> I have started VxGDB, attached to the target, attached to tasks, etc. |> VxGDB recognizes the C++ language , but I could not make it recognize |> line numbers of C++ source, nor could I make VxGDB display the C++ |> source in any way. Shouldn't you be using VxGDB++?. VxGDB shuld not have a problem with the excutable as 'c' is involved, but to display line info. you need VxGDB++. chak kolli |> |> DEMONSTRATION PROCEDURE : |> |> Compile/link a C++ application with -g, by using the following makefile: |> INC = -I$(VW)/h |> ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS |> all: myProg.C |> CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C |> gnm960 -pv myProg.o | munch960 > __ctordtor.c |> gcc960 -g $(ARCH) -c __ctordtor.c |> gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o |> |> Start VxGDB : |> vxgdb -t 960++ |> |> Attach target: |> target vxworks target_ip_addr vxWorks.st |> |> Load the C++ application into the target from VxGDB and issue the |> command "list" with either file name or function name. |> |> The debugger reports: |> "No line number information" |> |> Does this sound familiar to anybody? |> |> |> Any help or suggestions would be appreciated. |> |> Thanks, |> |> Meir. |> |> -------------------------------------------------------------------- |> Meir Kruk | Email: kruk@lannet.com |> LANNET Data Communication Ltd. | Tel: 972-3-6458398 |> Atidim Technology Park,Bldg. 3 | Fax: 972-3-6487146 |> Tel Aviv 61131, Israel | |> -------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: More on C++ and Vxworks Date: 21 Apr 1994 07:35:04 +1000 From: rjl@f111.iassf.easams.com.au (Rohan LENARD) Organization: EASAMS (Australia) Pty Ltd Message-ID: <2p4768$kfg@f111.iassf.easams.com.au> References: <9404151709.AA01331@atl.com> In article <9404151709.AA01331@atl.com>, >Since there is no "main" in your code, you have to invoke the two, >aforementioned global constructor and destructor functions explicitly. >This is done either using an "automatic" strategy or by calling the functions >"cplusCtors()" and "cplusDtors()", respectively. All of this confusion is >described in the WindC++ users guide. With gcc from Cygnus or from the appropriate ftp site, you can have a main, and you just do _main to run it. No big deal (global and static constructors are AUTOMATICALLY done for you) > >> Also, I have a >> problem using vxgdd and c++ code. Every time I try to run a routine on >> the target ('030) it says it cannot create task on target. Any ideas? > >Vxgdb has problems with mangled function names. If you have a C++ >function, it understands what to do if you issue the command "break func_name", >but the command "run func_name" doesn't work (you get that cryptic message >about not being able to create a task). Go figure.... However, it does >understand the mangled version of the name. (In fact, for member functions, >even "break class::member" may not work; I can't recall just now....) > There's a simple solution here. When you do run func_name it sends a command to the VxWorks machine to spawn the task (using the rdb support in the kernel). The kernel doesn't really know about C++, thus it needs the mangled names - in the same way that starting a function from the debug login needs mangled C++ names. vxgdb is doing the right thing. Now maybe I should ask cygnus to get gdb to mangle the names before sending the request, but then that doesn't help many other people :-) Regards, Rohan - -- - ---------------------------------------------------------------------------- rjl@iassf.easams.com.au | "In the beginning there was cave man, and he had a Rohan Lenard | club, which he used to seduce woman. Hence the +61-2-367-4555 | saying `not tonight dear I've got a headache'" --------------------------- End of New-News digest ********************** From cpd@one.one.com Thu Apr 21 05:17:54 1994 From: cpd@one.com (Chris P. Domin) Date: Thu Apr 21 05:18:04 PDT 1994 Subject: 68k a.out to COFF conversion utility Greetings. I am a developer using Wind River's VxWorks development platform on a Sun-4. I am currently trying to find a utility program, runnable on a Sun-4 workstation, which will convert a file from a.out format (in actuality, VxWorks 68K object) to Unix System V COFF format (also 68K). Does anyone know if there is a standard utility which will do this conversion? Regards, Chris Domin ================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-================= Open Networks Engineering (ONE) Fax: (313) 996-9908 777 Eisenhower Pkwy, Suite 650 Voice: (313) 996-9900 ext. (1) 232 Ann Arbor, Michigan 48108 Internet: cpd@one.com ================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-================= From dwampl@atl.com Thu Apr 21 09:55:40 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Thu Apr 21 09:55:57 PDT 1994 Subject: Re: WindC++ version of VxGDB on i960 does not work > Subject: Re: WindC++ version of VxGDB on i960 does not work > ... > |> I have installed an evaluation copy of WindC++ 1.0 beta on Sun4 station > |> running VxWorks 5.1.1 , for i960CA custom target. > |> I have started VxGDB, attached to the target, attached to tasks, etc. > |> VxGDB recognizes the C++ language , but I could not make it recognize > |> line numbers of C++ source, nor could I make VxGDB display the C++ > |> source in any way. > > Shouldn't you be using VxGDB++?. VxGDB shuld not have a problem with > the excutable as 'c' is involved, but to display line info. you need > VxGDB++. > > chak kolli The invocation of vxgdb for the 68k is "vxgdb -t 68k++". Hence, I think that his invocation (shown below) "vxgdb -t 960++" is correct. > |> > |> DEMONSTRATION PROCEDURE : > |> > |> Compile/link a C++ application with -g, by using the following makefile: > |> INC = -I$(VW)/h > |> ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS > |> all: myProg.C > |> CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C > |> gnm960 -pv myProg.o | munch960 > __ctordtor.c > |> gcc960 -g $(ARCH) -c __ctordtor.c > |> gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o > |> > |> Start VxGDB : > |> vxgdb -t 960++ > |> > |> Attach target: > |> target vxworks target_ip_addr vxWorks.st > |> > |> Load the C++ application into the target from VxGDB and issue the > |> command "list" with either file name or function name. > |> > |> The debugger reports: > |> "No line number information" > |> > |> Does this sound familiar to anybody? > |> My 68k versions of the above commands look the same, except for the "coff" and "-ACA". I am not experiencing this problem. I assume that -ACA flag is for the "960CA" processor. I would guess that the "coff" format has something to do with this problem, but I don't know enough about either gdb or coff to know.... Has WRS been any help? > |> > |> Any help or suggestions would be appreciated. > |> > |> Thanks, > |> > |> Meir. > |> > |> -------------------------------------------------------------------- > |> Meir Kruk | Email: kruk@lannet.com > |> LANNET Data Communication Ltd. | Tel: 972-3-6458398 > |> Atidim Technology Park,Bldg. 3 | Fax: 972-3-6487146 > |> Tel Aviv 61131, Israel | > |> -------------------------------------------------------------------- > Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "We begin bombing in five minutes...." 7:^] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From dwampl@atl.com Thu Apr 21 09:56:33 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Thu Apr 21 09:57:04 PDT 1994 Subject: Re: More on C++ and Vxworks > Subject: Re: More on C++ and Vxworks > ... > In article <9404151709.AA01331@atl.com>, > > >Vxgdb has problems with mangled function names. If you have a C++ > >function, it understands what to do if you issue the command "break func_name", > >but the command "run func_name" doesn't work (you get that cryptic message > >about not being able to create a task). Go figure.... However, it does > >understand the mangled version of the name. (In fact, for member functions, > >even "break class::member" may not work; I can't recall just now....) > > > > There's a simple solution here. When you do run func_name it sends a command > to the VxWorks machine to spawn the task (using the rdb support in the kernel). > The kernel doesn't really know about C++, thus it needs the mangled names - > in the same way that starting a function from the debug login needs mangled > C++ names. vxgdb is doing the right thing. Now maybe I should ask cygnus to > get gdb to mangle the names before sending the request, but then that doesn't > help many other people :-) There would be a problem if gdb tried to do this; gcc and "cfront" use slightly different name-mangling algorithms. Gdb would need to support both, since "WindC++" uses cfront, while many people use the gcc for C++. > > > Regards, > Rohan > > > - -- > - ---------------------------------------------------------------------------- > rjl@iassf.easams.com.au | "In the beginning there was cave man, and he had a > Rohan Lenard | club, which he used to seduce woman. Hence the > +61-2-367-4555 | saying `not tonight dear I've got a headache'" > Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "I feel your pain...." =:O] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From enorgren@ehsl.mitre.org Thu Apr 21 12:45:53 1994 From: enorgren@ehsl.mitre.org (Eric J Norgren) Date: Thu Apr 21 12:46:02 PDT 1994 Subject: Serial I/F Boards / Drivers Any assistance with the following questions would be greatly appreciated. Please send responses to the following: enorgren@ehsl.mitre.org Thank you in advance for your help. Eric Norgren ********************************************************************* 1. Has anyone purchased, developed, +/or implemented a VxWorks driver for a PTI-330 board? Any information regarding work in progress on any PTI-330 VxWorks drivers would also be helpful. 2. In a more general sense does anyone have any information on an intelligent ( microprocessor-based ) 8 serial port or better ( ideally 16 ports ) VME-based communications interface board with the following critical requirements: a. each serial port must support the "transparent" mode of operation. This "transparent" mode is the transmission and reception of raw data without the application of any serial protocol. b. the source clock frequency for each serial channel must be able to be sourced from an external clock source. c. VxWorks driver support Features which would be nice: a. DMA transfer capability b. VME-64 support c. Maximum baud rate of up to 1 Megabit/channel ********************************************************************* From daemon@vxw.ee.lbl.gov Sat Apr 23 04:00:21 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 23 04:00:30 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 23 04:00:12 PDT 1994 Subject: NFS Download to memory Subject: Re: NFS Download to memory ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: NFS Download to memory Date: 20 Apr 1994 16:06:21 GMT From: breen@inetgw.fsc.ibm.com () Organization: IBM Message-ID: <2p3jtt$p61@eagle.bet.ibm.com> Reply-To: breen@vnet.ibm.com I need to download a large file, ~500 meg, from my host, a RS/6000, to global memory on my VME chasis. Currently I am using 'open' and 'fioread' to perform this download. The file is mounted via nfs and I can load it at a rate of .415 megabytes/sec, which is too slow. Is there a way to speed this transfer up by using some sort of caching? I would appreciate it if anyone that had ideas on how to speed up this transfer from the host to the chassis could them to me or post them to the group. Thanks in advance. Scott Scott Breen RSCS: breen@owego Loral Federal Systems Email: breen@vnet.ibm.com D/324 B/304A MD/0534 External phone: 607-751-6217 Owego, NY 13827 Tieline: 662-6217 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: NFS Download to memory Date: Fri, 22 Apr 1994 17:33:34 From: anj@mail.ast.cam.ac.uk (Andrew Johnson) Organization: Royal Greenwich Observatory Message-ID: References: <2p3jtt$p61@eagle.bet.ibm.com> Scott Breen writes: >I need to download a large file, ~500 meg, from my host, a RS/6000, to >global memory on my VME chasis. Currently I am using 'open' and 'fioread' >to perform this download. The file is mounted via nfs and I can load it >at a rate of .415 megabytes/sec, which is too slow. Is there a way to >speed this transfer up by using some sort of caching? >I would appreciate it if anyone that had ideas on how to speed up this >transfer from the host to the chassis could them to me or post them >to the group. Thanks in advance. You look like you're doing pretty well at the moment if you've got an Ethernet cable in there (10 Mega-bits per second raw physical rate). I can't comment on how fast you could go, but I guess you'd find it hard to go very much faster. If you need anything like an order of magnitude speedup, you'll have to use a hardware solution, and connect your RS/6000 to the VMEbus directly. Bit-3 sell a suitable MCA to VMEbus adapter card-pair which should give you up to something like 26 Mbytes/second. I would also check out Performance Technologies, and there may be other suppliers of similar adapters. _ _ _ _ / \ ___ _| |_ _ ___ _ _ | |___| |_ ___ ___ ___ ___ | - | | . | ~_| -_| |~| | _| | . | | |_ -| . | | |_|_|_|_|___|_| |___|_____| |___|___|_|_|_|_|___|___|_|_| anj@mail.ast.cam.ac.uk Royal Greenwich Observatory Tel 0223-374823 Fax 0223-374700 Cambridge, UK --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Mon Apr 25 04:00:28 1994 From: daemon@vxw.ee.lbl.gov Date: Mon Apr 25 04:00:37 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Apr 25 04:00:15 PDT 1994 Subject: Re: X input extension Subject: Re: More on C++ and Vxworks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: X input extension Date: 22 Apr 1994 21:17:14 GMT From: gene@visicom.com (Gene Kennon) Organization: VisiCom Laboratories, Inc. Message-ID: <2p9esq$9vt@corona.VisiCom.COM> References: <2o0sim$iea@vmsfo.lys.vingmed.no> Sender: -Not-Authenticated-[7339] VisiCom has ported the X11R5 input extension client-side library to VxWorks 5.1.1. Although, not shipped with VX-Windows 2.0, it, along with other extensions, will be included in the next release (also to support Motif 1.2.4 for more memory leak fixes). VX-Windows customers can contact me for more details at (619) 457-2111. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: More on C++ and Vxworks Date: 25 Apr 1994 09:24:17 +1000 From: rjl@f111.iassf.easams.com.au (Rohan LENARD) Organization: EASAMS (Australia) Pty Ltd Message-ID: <2pev31$8fl@f111.iassf.easams.com.au> References: <9404211653.AA02139@atl.com> In article <9404211653.AA02139@atl.com>, Dean Wampler (dwampl@atl.com) wrote: >:> Subject: Re: More on C++ and Vxworks [..snip..] > >There would be a problem if gdb tried to do this; gcc and "cfront" use slightly >different name-mangling algorithms. Gdb would need to support both, since >"WindC++" uses cfront, while many people use the gcc for C++. > Maybe, maybe not. Since vxgdb already supports both arm and gnu style name demangling. Once the name has been mangled, both schemes look identical under VxWorks. So all that is needed is to add support for arm style mangling. Information on demangling from info page for gdb - :: `set demangle-style STYLE' :: Choose among several encoding schemes used by different compilers :: to represent C++ names. The choices for STYLE are currently: :: :: `auto' :: Allow GDB to choose a decoding style by inspecting your :: program. :: :: `gnu' :: Decode based on the GNU C++ compiler (`g++') encoding :: algorithm. :: :: `lucid' :: Decode based on the Lucid C++ compiler (`lcc') encoding :: algorithm. :: :: `arm' :: Decode using the algorithm in the `C++ Annotated Reference :: Manual'. *Warning:* this setting alone is not sufficient to :: allow debugging `cfront'-generated executables. GDB would :: require further enhancement to permit that. :: Regards, Rohan - -- - ---------------------------------------------------------------------------- rjl@iassf.easams.com.au | "In the beginning there was cave man, and he had a Rohan Lenard | club, which he used to seduce woman. Hence the +61-2-367-4555 | saying `not tonight dear I've got a headache'" --------------------------- End of New-News digest ********************** From kruk@lannet.com Tue Apr 26 07:56:44 1994 From: kruk@lannet.com (Meir Kruk) Date: Tue Apr 26 07:57:06 PDT 1994 Subject: WindC++ version of VxGDB on i960 works I would like to thank all who responed to my mail about "WindC++ version of VxGDB on i960", especially Dean Wampler. I have succeeded in activating the VxGDB on a C++ source files. As I see, there is a problem in the compilation process. I have changed the make file for the compilation process as following: Old makefile: ------------- INC = -I$(VW)/h ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS all: myProg.C CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C gnm960 -pv myProg.o | munch960 > __ctordtor.c gcc960 -g $(ARCH) -c __ctordtor.c gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o New makefile: ------------- C1FLAGS = -ACA -Fcoff -g -I$(VW)/h -ansi -Wall -DCPU=I960CA -pipe -nostdinc -DVX_IGNORE_GNU_LIBS -c -E CFLAGS = -ACA -Fcoff -g -I$(VW)/h -ansi -Wall -DCPU=I960CA -pipe -nostdinc -DVX_IGNORE_GNU_LIBS -c LDFLAGS = -ACA -r -Fcoff CCFLAGS = +V -F -.i .SUFFIXES : .o .C .C.o: CC960 $(CCFLAGS) $(CFLAGS) $*.C /bin/cat $*.i | awk '{ if ((index ($$3, "__builtin_") > 0) || (index ($$3, "__alignof__") > 0) ) {next} else {print} }' > $*.c $(gcc960) $(C1FLAGS) -o $*.i $*.c sed -e '1d' $*.i > $*.i.tmp mv $*.i.tmp $*.i $(gcc960) $(CFLAGS) -o $*.o $*.i all: myProg.out myProg.out: myProg.o gnm960 -pv myProg.o | munch960 > __ctordtor.c gcc960 -ACA -Fcoff -DCPU=I960CA -pipe -c __ctordtor.c gld960 $(LDFLAGS) -o myProg.out __ctordtor.o myProg.o SPR 2496 in "WindC++ Gateway for i960 - Release Notes" describe's this solution for another problem. Meir. -------------------------------------------------------------------- Meir Kruk | Email: kruk@lannet.com LANNET Data Communication Ltd. | Tel: 972-3-6458398 Atidim Technology Park,Bldg. 3 | Fax: 972-3-6487146 Tel Aviv 61131, Israel | -------------------------------------------------------------------- From LAJOIE@yalph2.physics.yale.edu Tue Apr 26 13:01:53 1994 From: LAJOIE@yalph2.physics.yale.edu Date: Tue Apr 26 13:02:06 PDT 1994 Subject: backplane load errors I have a backplane network with 10 processors ( 4 Matrix MX330's and 6 GMS V49's); the network is set up to use mailbox interrupts and for the most part seems to work fine. However, abot 30% of the time when I try to load an object file I get the following error message after a LONG pause (about 4 minutes): -> ld < aioTest.o can't open input 'aioTest.o' errno = 0x36 (S_errno_ECONNRESET) I'm not sure what this means, or how to fix the problem. Any ideas? John Lajoie Yale University Physics Department lajoie@yalph1.physics.yale.edu From daemon@vxw.ee.lbl.gov Wed Apr 27 04:00:26 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 27 04:00:37 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 27 04:00:17 PDT 1994 Subject: ntp for VxWorks Subject: Re: More on C++ and Vxworks Subject: VxWorks emacs users - check out cc-mode Subject: How to cancel a message? Subject: Re: ntp for VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.protocols.time.ntp Subject: ntp for VxWorks Date: 26 Apr 1994 17:29:42 GMT From: michael@arc.nasa.gov Organization: NASA Ames Research Center, Moffett Field, CA Message-ID: <2pjj26$bre@news.arc.nasa.gov> Reply-To: michael@arc.nasa.gov Is there a version of ntp out there that will allow a VxWorks (Sun 1/E) system to be an ntp server for some Sun Workstations? Michael Pruznick Sterling Software NASA AMES Research Center. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: More on C++ and Vxworks Date: Tue, 26 Apr 1994 18:02:15 GMT From: scotth@snake.com (Scott Herzinger) Organization: Wind River Systems Message-ID: References: <9404211653.AA02139@atl.com> Sender: news@wrs.com (News Manager) In article <9404211653.AA02139@atl.com> dwampl@atl.com (Dean Wampler (dwampl@atl.com)) writes: :> >Vxgdb has problems with mangled function names. If you have a C++ :> >function, it understands what to do if you issue the command "break func_name", :> >but the command "run func_name" doesn't work (you get that cryptic message :> >about not being able to create a task). Go figure.... However, it does :> >understand the mangled version of the name. (In fact, for member functions, :> >even "break class::member" may not work; I can't recall just now....) :> > .... There would be a problem if gdb tried to do this; gcc and "cfront" use slightly different name-mangling algorithms. Gdb would need to support both, since "WindC++" uses cfront, while many people use the gcc for C++. In general, both the VxWorks shell and the WindC++ version of VxGDB 2.0 understand cfront-mangled names. If the VxGDB command "run func_name" doesn't work, it's likely a configuration problem, or maybe you're using a beta version (this feature was somewhat broken during beta). By the same token, you should be able to invoke, disassemble, etc. functions from the VxWorks shell in the same way, e.g. "l func_name" or "sp func_name". If func_name is overloaded, the user is prompted with a menu containing the signatures of the various versions, and is permitted to choose the desired one. Some folks have noted the known problem in VxWorks 5.1.1 in which C++ support is not correctly initialized in src/config/usrExtra.c. This problem, and the solution are documented in a Read Me First page in the WindC++ package. It's important to go through the simple procedure (one page, just a couple steps). Failing to do so will cause the shell to fail to recognized cfront-mangled names. Hope this helps. Scott Herzinger Wind River Systems --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks emacs users - check out cc-mode Date: Tue, 26 Apr 1994 16:54:54 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems Message-ID: Reply-To: james@wrs.com Sender: news@wrs.com (News Manager) If you use emacs to write code using WRS coding conventions, you should check out cc-mode (in the archives, and recently posted to gnu.emacs.sources). It understands all of the WRS conventions, unlike c-mode. It's slower than c-mode, but not intolerably so. Here's the entry from my .emacs file that I'm using to get WRS style: (autoload 'c++-mode "cc-mode" "C++ Editing Mode" t) (autoload 'c-mode "cc-mode" "C Editing Mode" t) (setq auto-mode-alist (append '(("\\.C$" . c++-mode) ("\\.cc$" . c++-mode) ("\\.c$" . c-mode) ; to edit C code ("\\.h$" . c-mode) ; to edit C code ) auto-mode-alist)) (defconst wrs-c-style '("WRS Coding conventions" (c-tab-always-indent . t) (c-hanging-braces-alist . ((block-open after before) (brace-list-open))) (c-hanging-colons-alist . ((member-init-intro before) (inher-intro) (case-label after) (label after) (access-key after))) (c-cleanup-list . (scope-operator empty-defun-braces defun-close-semi)) (c-offsets-alist . ((statement-block-intro . 0) (defun-open . 4) (arglist-close . 0) (arglist-intro . 0) (class-open . 4) (class-close . 4) (topmost-intro-cont . 4))) (c-echo-semantic-information-p . t) ) "WRS Coding Conventions") (defun wrs-c-mode-common-hook () ;; set up for my perferred indentation style, but only do it once (let ((my-style "WRS Coding conventions")) (or (assoc my-style c-style-alist) (setq c-style-alist (cons wrs-c-style c-style-alist))) (c-set-style my-style)) ;; keybindings for both C and C++. We can put these in c-mode-map ;; because c++-mode-map inherits it (define-key c-mode-map "\C-m" 'newline-and-indent) ) (add-hook 'c-mode-common-hook 'wrs-c-mode-common-hook) - -- James Moore /|\ james@wrs.com Wind River Systems \|/ Alameda, California Why in the world is Volkswagen so obsessed with far fig newtons? --------------------------- Newsgroups: comp.os.vxworks Subject: How to cancel a message? Date: 26 Apr 1994 22:12:27 GMT From: kendalla@pogo.wv.tek.com (Kendall P Auel) Organization: Tektronix, Inc., Wilsonville, OR Message-ID: <2pk3kb$q2g@gazette.wv.tek.com> Reply-To: kendalla@pogo.WV.TEK.COM If I have posted a message (msgQSend) and then later decide to cancel it, is there an accepted method to remove it from the message queue? I can think of one or two ways to hack out a solution but thought I would check here to see if others have come up with a better way. Thanks! - -- Kendall Auel Tektronix, Inc. kendalla@pogo.wv.tek.com Wilsonville, OR --------------------------- Newsgroups: comp.os.vxworks,comp.protocols.time.ntp Subject: Re: ntp for VxWorks Date: Wed, 27 Apr 1994 02:36:04 GMT From: jfinley@netcom.com (John Finley) Organization: NETCOM On-line Communication Services (408 241-9760 guest) Message-ID: References: <2pjj26$bre@news.arc.nasa.gov> Followup-To: comp.os.vxworks,comp.protocols.time.ntp michael@arc.nasa.gov wrote: : Is there a version of ntp out there that will allow a VxWorks (Sun 1/E) : system to be an ntp server for some Sun Workstations? : Michael Pruznick : Sterling Software : NASA AMES Research Center. I guess you'd get synchronization, but for accuracy, the clock chip on the 1E is pretty lousy off-the-shelf (the MK48T02, not the ticker) You can tune it by poking some register, but I've never tried that. Has anyone else tried tuning it? ("You can tune a 1E, but you can't tune a" ... never mind.) - --- John Finley jfinley@netcom.com john@sd.aplabs.com --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Thu Apr 28 04:00:30 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 28 04:00:38 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 28 04:00:15 PDT 1994 Subject: Re: ntp for VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.protocols.time.ntp Subject: Re: ntp for VxWorks Date: Wed, 27 Apr 1994 13:16:28 From: anj@mail.ast.cam.ac.uk (Andrew Johnson) Organization: Royal Greenwich Observatory Message-ID: References: <2pjj26$bre@news.arc.nasa.gov> In article <2pjj26$bre@news.arc.nasa.gov> michael@arc.nasa.gov writes: >Is there a version of ntp out there that will allow a VxWorks (Sun 1/E) >system to be an ntp server for some Sun Workstations? Yes, look in the VxWorks archive (thor.atd.ucar.edu, although I haven't been able to connect to it recently) for ntpv3.1.tar. It's not the latest version of ntp, and I think it's aimed at VxWorks 5.0.2 only. I haven't actually tried it, I just know it's there. _ _ _ _ / \ ___ _| |_ _ ___ _ _ | |___| |_ ___ ___ ___ ___ | - | | . | ~_| -_| |~| | _| | . | | |_ -| . | | |_|_|_|_|___|_| |___|_____| |___|___|_|_|_|_|___|___|_|_| anj@mail.ast.cam.ac.uk Royal Greenwich Observatory Tel +44 223-374823 Fax +44 223-374700 Cambridge, UK --------------------------- End of New-News digest ********************** From hebo@mbari.org Thu Apr 28 09:01:51 1994 From: Bob Herlien Date: Thu Apr 28 09:01:59 PDT 1994 Subject: Re: comp.os.vxworks newsdigest > In article <2pjj26$bre@news.arc.nasa.gov> michael@arc.nasa.gov writes: > > >Is there a version of ntp out there that will allow a VxWorks (Sun 1/E) > >system to be an ntp server for some Sun Workstations? > > Yes, look in the VxWorks archive (thor.atd.ucar.edu, although I haven't > been able to connect to it recently) for ntpv3.1.tar. It's not the latest > version of ntp, and I think it's aimed at VxWorks 5.0.2 only. Yes, Steve Layton did the NTP 3.1 port for VxWorks. His code uses my original usrTime library which I did 2.5 years ago for the NTP 1.0 port. I *think* (but haven't used it) that Steve's code was for 5.0.2, but I would guess it should work on 5.1 just fine. *My* code, however, was written for VxWorks 4.x. I mailed a version of usrTime for VxWorks 5.1.1 to the archive administrator over a month ago, but I haven't seen it show up in the archives. Paging Richard Neitzel... If anybody wants a copy of the updated usrTime for vxWorks 5.1.1, send me an email request. [Note - usrTime is a libary of Unix compatible time functions for VxWorks. It includes time(), stime(), adjtime(), asctime(), ctime(), gmtime(), localtime(), gettimeofday(), and settimeofday()]. -------------------------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@mbari.org From busch@daacdev1.stx.com Thu Apr 28 12:51:25 1994 From: Jim Busch Date: Thu Apr 28 12:51:37 PDT 1994 Subject: interrupt processing on a Heurikon/5.1 When running a Heurikon 68040 and processing level 2 or level 3 interrupts of the values 64, 128 and 192 with a VxWorks 5.1 kernel, a bus error is received which suspends the "tNetTask". The processor continues processing the interrupts until a second bus error is received which suspends the "tLogTask" and halts the processor. The aforementioned interrupts function perfectly on a Heurikon 68040 which is executing a VxWorks 5.0.2 kernel. Why does this function properly with a 5.0.2 kernel but not with the 5.1 kernel? Are there files in VxWorks which need to be explicitly included when building the kernel in order to handle interrupts? Is there some limitation in the Heurikon BSP with respect to interrupts? Thanks...Jim From hill@luke.atdiv.lanl.gov Thu Apr 28 17:21:37 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Thu Apr 28 17:21:45 PDT 1994 Subject: assert() Hello all, Perhaps it would be useful if the __assert() implementation under vxWorks had a run time option that caused it to call logMsg() instead of fprintf()? It also might be be useful if __assert() could be configured to call taskSuspend(taskIdSelf()) instead of abort() when debugging? Jeff ______________________________________________________________________ Jeffrey O. Hill Internet hill@atdiv.lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos, NM USA 87545 FAX 505 665 5107 From daemon@vxw.ee.lbl.gov Fri Apr 29 04:00:20 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 29 04:00:29 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 29 04:00:12 PDT 1994 Subject: re: comp.os.vxworks newsdigest Subject: Heurikon vs Motorola? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: re: comp.os.vxworks newsdigest Date: 28 Apr 1994 18:07:18 GMT From: thor@ymir.atd.ucar.edu (Rich Neitzel) Organization: National Center for Atmospheric Research Message-ID: <2pou0m$oj4@ncar.ucar.edu> References: <199404281601.JAA24891@nak.berkeley.edu> Sender: thor@ymir (Rich Neitzel) In article <199404281601.JAA24891@nak.berkeley.edu>, Bob Herlien writes: |> > In article <2pjj26$bre@news.arc.nasa.gov> michael@arc.nasa.gov writes: |> > |> written for VxWorks 4.x. I mailed a version of usrTime for VxWorks 5.1.1 |> to the archive administrator over a month ago, but I haven't seen it show |> up in the archives. Paging Richard Neitzel... |> It's in there now. Sorry, but the switch to Solaris 2 has been a higher priority. Not to mention the flurry of updates wu-ftp has gone through :-{. - -- 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 Gjx'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------- Newsgroups: comp.os.vxworks Subject: Heurikon vs Motorola? Date: 28 Apr 1994 21:42:04 GMT From: cro@pathos.caltech.edu (John Cromer) Organization: California Institute of Technology, Pasadena Message-ID: <2ppajc$ik9@gap.cco.caltech.edu> I'm having a difficult time choosing between Motorola and Heurikon CPUs for a VxWorks VME system. The MV167 family seems to get the latest releases of VxWorks first and to be discussed frequently on this group as well as at the VxWorks users group meetings. But, I guess since we're not going to buy a hundred of them, Motorola seems to be fairly unresponsive with information, quotes, etc. On the other hand, Heurikon has a good reputation and they seem to be more responsive to our inquiries. The boards themselves (MVME167-032a vx HK68G/V4D) don't seem to be that different technically. Any of you VxWorks users have any comments in this regard -- testimonials, flames, experiences pleasant and unpleasant? Email or posts welcome. John --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Fri Apr 29 04:09:41 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Apr 29 04:09:56 PDT 1994 Subject: Re: interrupt processing on a Heurikon/5.1 Greetings! > Submitted-by: Jim Busch > > When running a Heurikon 68040 and processing level 2 or level 3 > interrupts of the values 64, 128 and 192 with a VxWorks 5.1 kernel, > a bus error is received which suspends the "tNetTask". The processor > continues processing the interrupts until a second bus error is received > which suspends the "tLogTask" and halts the processor. The aforementioned > interrupts function perfectly on a Heurikon 68040 which is executing a > VxWorks 5.0.2 kernel. > > > Why does this function properly with a 5.0.2 kernel but not with the 5.1 > kernel? > > Are there files in VxWorks which need to be explicitly included when > building the kernel in order to handle interrupts? > > Is there some limitation in the Heurikon BSP with respect to interrupts? Well, one possibility is that you have the CMC ENP10 card support routines turned on. They use Interrupt level 3 and Interrupt Vector 192 as their defaults. Check your VxWorks by doing a: -> lkup "attach" If you see an enpattach, exattach or anything like that other than eiattach, then you may be experiencing a conflict. To solve this, simply go into the config.h in the Heurikon's directory and do a: #ifdef INCLUDE_ENP #undef INCLUDE_ENP #endif If this is not the case and the Heurikon board is the V4D (the one with the VIC64 interface chip), then the problem could be a bug in the VIC64 arbiter. There is a known problem with two signals (BBSY* and AM5) which can occasionally glitch high. This can cause bus errors because it can result in two masters being on the bus at the same time. The cause of the problem is noise as a result of ground bounce due to an inadequate supply of ground pins in close proximity to those two signal pins. Cypress is currently revising the VIC64 to ignore this noise. A temporary fix for the BBSY* glitch is to use a separate system controller. As for the AM5 glitch (a problem for D64 block transfers), it causes the slave VIC64 to see a different address modifier code during the cycle when AM codes are supposed to be stable. The symptom is a bus error on the *master's* cycle. A temporary fix is to disable the enhanced turbo mode in the block transfer definition register (bit 5) (I believe that 5.0.2 didn't enable this bit in the first place). A 10-layer backplane has also proven to be an effective measure against both of these problems. I assume that this could be a problem for any board that uses the VIC64 chipset. For a replacement VIC64 as soon as Cypress can do the rev, contact Heurikon (provided that it's a Heurikon board ;-) at (800) 327-1251. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From rcm@ssd.ray.com Fri Apr 29 06:05:55 1994 From: Mandler Date: Fri Apr 29 06:06:02 PDT 1994 Subject: Ethernet driver code Greetings! For an existing in-house project, we purchased a VxWorks source license to build in enhanced libraries and make some other custom changes. One of the changes was to the 'if_ln.c' ethernet driver to allow modification of the logical address filter bits on the LANCE chip to support multicasting. At present, I would like to incorporate similar changes into the mvme167 driver for another project which has no source license. I thought I remembered that driver code was available even without a source license, but I don't see it in my 167 package. Am I remembering incorrectly, or is that code available? _____________________________________________________________________ | Roland C Mandler, Raytheon Equipment Division Portsmouth facility | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 842-4228 | | | | rcm@ssd.ray.com | |_____________________________________________________________________| From mea@mclean.sparta.com Fri Apr 29 08:05:23 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Apr 29 08:05:32 PDT 1994 Subject: Re: Ethernet driver code That driver is not included in source form for the MV167 BSP. However, it is available from Wind River for extra $$$. I think that the 167 uses the Intel 82596 (if_ei.c) driver. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From hlg%matrx@concert.net Fri Apr 29 08:11:48 1994 From: hlg@matrx.matrix.com (Louis Gray) Date: Fri Apr 29 08:11:56 PDT 1994 Subject: Re: comp.os.vxworks newsdigest Bob, If it wouldn't be too much trouble, I would like to get a copy of your usrTime library. My user address is: hlg@matrix.com Thanks In advance, -- - HL - =============================================================================== "We conclude that the Texas Constitution accords individuals greater safeguards to their personal freedom than its federal counterpart does." - Texas Third Court of Appeals, 1992 From mea@mclean.sparta.com Fri Apr 29 08:18:25 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Apr 29 08:18:36 PDT 1994 Subject: RE: Heurikon vs. Motorola Greetings! Here at SPARTA, we use oodles of the Heurikon boards in our projects. I have always had quite good responsiveness from Heurikon sales critters as well as Heurikon hardware/software tech support. Their warranty is 1 year on the boards and they provide free tech support for that year via their 800 number. Yes, they tend to lag behind WRS in their release shedule by 2-4 months. However, when you get the BSP, it also tends to be both better debugged and well tuned to take advantage of the on-board features such as DMA controllers. Motorola has NEVER been very responsive to me. Of course, I only use a few hundred CPUs a year, so I don't tend to attract their attention. You may also notice that you see more problems regarding Motorola products here on the net. Whether that's due to just more Motorola boards being out there, or there really are more problems with them is unclear, however. For my money (and sanity) I'd pick Heurikon over Motorola every time. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From tweadon@sadira.gb.nrao.edu Fri Apr 29 10:31:33 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Fri Apr 29 10:31:42 PDT 1994 Subject: RE: Heurikon vs. Motorola We don't have the number of cards that SPARTA does but I have to say that we have had excellent technical support on all our Motorola products. Tim Weadon National Radio Astronomy Observatory Green Bank, WV. From daemon@vxw.ee.lbl.gov Sat Apr 30 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 30 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 30 04:00:13 PDT 1994 Subject: VxWorks and BOOTP information needed Subject: Help! How to run code in ROMs but not is OS. Subject: Re: Heurikon vs Motorola? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks and BOOTP information needed Date: Fri, 29 Apr 1994 14:08:27 GMT From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld) Organization: Hollandse Signaal apparaten BV Message-ID: <1994Apr29.140827.23919@hgl.signaal.nl> Sender: usenet@hgl.signaal.nl (USENET News System) Hello, I need to use a VxWorks target on ethernet via a 'bootp' server. The server is a SUN workstation (SunOS 4.1.x). The VxWorks 5.1.1 target has 'bootp' functionality built in the bootprom. question : ********* "is there someone out there who has got vxworks and bootp working on SUN ?" We tried the 'unsupported' VxWorks 5.1.1 version of the 'bootp' software. It will not work. Please email me. --Ben-- - -- ============================================================================== = B.J.M. Vloedbeld Dept:SDA-DID-DIM Org:Hollandse Signaalapparaten B.V. = = Adress : P.O.box 42 7550 GD Hengelo, The Netherlands = = Phone :+31-74-483994 FAX:+31-74-484009 email:bjm_vloedbeld@hgl.signaal.nl = =============================================================[Unclassified]=== --------------------------- Newsgroups: comp.os.vxworks Subject: Help! How to run code in ROMs but not is OS. Date: 29 Apr 1994 11:20:47 -0500 From: sabolcik@natinst.com (Ross Sabolcik) Organization: National Instruments, Austin, TX Message-ID: <2prc4v$4ne@eagle.natinst.com> Hello: I am currently trying to find out if there is a way to determine if I am running code from within the Bootroms, or in the loaded version of the Operating System. My problem is that I need to perform some system initialization only once during the boot-up procedure. Currently this initialization is being done in sysHwInit() in sysLib.c. sysHwInit() is called by usrInit() in both bootConfig.c and usrConfig.c. I want a piece of code within sysHwInit to be run only in the bootConfig case. I am trying to determine if there are any global variables which tell me if bootConfig or usrConfig is the calling routine? Another possible solution is to modify the Makefile to only conditionally include the code if sysLib.c is being built for the bootRom target or the vxWorks(.st) target. This final solution is less than ideal since this code is destined for the BSP which must use all of the default vxWorks stuff for the directory tree outside of vw/config/target. Any suggestions? - -------------------------------------------------------------------------------- Ross Sabolcik VXI Software Engineer National Instruments 6504 Bridge Point Parkway Austin, TX 78730-5039 - -------------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Heurikon vs Motorola? Date: 29 Apr 1994 17:29:45 GMT From: mwette@mr-ed.jpl.nasa.gov (Matt Wette) Organization: Jet Propulsion Laboratory Message-ID: <2prg69$so@grover.jpl.nasa.gov> References: <2ppajc$ik9@gap.cco.caltech.edu> In article <2ppajc$ik9@gap.cco.caltech.edu>, cro@pathos.caltech.edu (John Cromer) writes: |> I'm having a difficult time choosing between Motorola and Heurikon CPUs |> for a VxWorks VME system. The MV167 family seems to get the latest |> releases of VxWorks first and to be discussed frequently on this group |> as well as at the VxWorks users group meetings. But, I guess since we're |> not going to buy a hundred of them, Motorola seems to be fairly |> unresponsive with information, quotes, etc. On the other hand, Heurikon |> has a good reputation and they seem to be more responsive to our |> inquiries. The boards themselves (MVME167-032a vx HK68G/V4D) don't seem |> to be that different technically. |> |> Any of you VxWorks users have any comments in this regard -- testimonials, |> flames, experiences pleasant and unpleasant? |> |> Email or posts welcome. While I have had no experience w/ Motorola, I will say something about Heurikon. A while ago I bitched on the net about lack of support for our VxWorks/Heurikon combination. I would have to say that Heurikon took this very seriously and took care of our immediate problems right away and then took action to solve the problems overall. Matt - -- mwette@csi.jpl.nasa.gov --------------------------- End of New-News digest ********************** From stan@rti.com Sat Apr 30 14:41:23 1994 From: stan@rti.com (Stan Schneider) Date: Sat Apr 30 14:41:33 PDT 1994 Subject: Re: VxWorks and BOOTP information needed >> Date: Fri, 29 Apr 1994 14:08:27 GMT >> From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld) >> question : >> ********* "is there someone out there who has got vxworks and >> bootp working on SUN ?" >> >> We tried the 'unsupported' VxWorks 5.1.1 version of the 'bootp' software. >> It will not work. >> We have bootp working from both SunOS 4 and Solaris hosts. This is from the notes, it was some time ago (i.e. no promises)... 1. Create a file called "strings.h" with these contents (optional on SunOS4): #define bcopy(s, d, n) memmove(d, s, n) #define bzero(d, n) memset(d, 0, n) #define bcmp(b1, b2, n) memcmp(b1, b2, n) #include 2. Change '#include ' to '#include "strings.h"' in all .c files 3. Add '#include ' and '' to bootpd.c 4. >>>> Change "char buf[1024]" to "int buf[1024]" in bootpd.c ^^^^ ^^^ This is the real problem---otherwise you get an alignment fault. The code uses buf[] in all sorts of unorthodox ways; it has to be quad aligned! 5. Change the makefile (Solaris only): Add "-lnsl -lsocket" to the link libraries. 6. Uncomment CONFFILE and DUMPFILE & set to local files (optional) 7. make CC=gcc 8. Add bootps and bootpc to NIS or NIS+ services database. 9. Add your target to the ethers database. 10. Make sure the permissions on the boot files, etc. are set so anyone can read them! 11. Follow the normal instructions (i.e. set up your bootptab, su root, run "./bootpd -s", ...) Drop me an email if you have any trouble; I can send you our complete sources & makefile. The real gotcha is #4; that took us a few hours to figure out. -- 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 thor@thor.atd.ucar.edu Sat Apr 30 23:00:15 1994 From: thor@thor.atd.ucar.edu (Rich Neitzel) Date: Sat Apr 30 23:00:24 PDT 1994 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 ------------------------------------------------ VxWorks sources: total 8508 -rw-r--r-- 1 thor staff 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor staff 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor staff 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor staff 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor staff 37126 Jun 12 1992 ansilib01 -rw-r--r-- 1 thor staff 18913 Jun 12 1992 ansilib02 -rw-r--r-- 1 thor staff 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor staff 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor staff 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor staff 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor staff 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor staff 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor staff 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor staff 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor staff 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor staff 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor staff 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor staff 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor staff 41669 Dec 6 1991 dhrystones01 -rw-r--r-- 1 thor staff 19170 Apr 1 1993 dirlib01 -rw-r--r-- 1 thor staff 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor staff 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor staff 11561 Nov 1 1991 flags_class.shar -rw-r--r-- 1 thor staff 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor staff 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor staff 80491 May 8 1989 force.shar -rw-r--r-- 1 thor staff 2453 Mar 10 1993 gcc+68040 -rw-r--r-- 1 thor staff 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor staff 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor rsf 12427 Apr 28 11:53 index -rw-r--r-- 1 thor staff 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor staff 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor staff 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor staff 9079 Apr 2 1990 lclflag.shar -rw-r----- 1 thor rsf 174829 Dec 3 15:49 lexyacc.tar.gz drwxr-xr-x 2 thor staff 512 Mar 21 12:15 libX11 -rw-r--r-- 1 thor staff 10747 Nov 3 11:54 libg++-2.5-src.patch lrwxrwxrwx 1 root other 20 Mar 19 19:08 libg++-2.5.1-src.patch -> libg++-2.5-src.patch lrwxrwxrwx 1 root other 20 Mar 19 19:08 libg++-2.5.2-src.patch -> libg++-2.5-src.patch -rw-r--r-- 1 thor staff 1568 Nov 3 11:54 libgcc2-2.5.0.patch -rw-r--r-- 3 thor staff 1545 Nov 3 11:55 libgcc2-2.5.2.patch lrwxrwxrwx 1 root other 19 Mar 19 19:08 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch -rw-r--r-- 3 thor staff 1545 Nov 3 11:55 libgcc2-2.5.5.patch -rw-r--r-- 3 thor staff 1545 Nov 3 11:55 libgcc2-2.5.6.patch lrwxrwxrwx 1 root other 15 Mar 19 19:07 libio-2.5.1.patch -> libio-2.5.patch lrwxrwxrwx 1 root other 15 Mar 19 19:08 libio-2.5.2.patch -> libio-2.5.patch -rw-r--r-- 1 thor staff 1228 Dec 29 09:51 libio-2.5.patch lrwxrwxrwx 1 root other 6 Mar 19 19:07 libx11 -> libX11 -rw-r--r-- 1 thor staff 3515 Mar 16 1993 loadmeter.shar -rw-r--r-- 1 thor staff 10399 May 4 1989 math.shar -rw-r--r-- 1 thor staff 11950 May 30 1989 math2 -rw-r--r-- 1 24 40 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor staff 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor staff 829713 Dec 17 08:10 ntpv3.1.tar.gz -rw-r----- 1 thor staff 1010176 Nov 8 13:42 ntpv3.tar.gz -rw-r--r-- 1 thor staff 1082 Dec 14 09:09 objc.patch -rw-r--r-- 1 thor staff 19422 Mar 1 07:25 ping01 -rw-r--r-- 1 thor staff 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor staff 15418 May 30 1989 poolLib lrwxrwxrwx 1 root other 7 Mar 19 19:07 poollib -> poolLib -rw-r--r-- 1 thor staff 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor staff 6614 May 31 1989 semCnt lrwxrwxrwx 1 root other 6 Mar 19 19:07 semcnt -> semCnt -rw-r--r-- 1 thor staff 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor staff 41196 Oct 16 1992 stevie01 -rw-r--r-- 1 thor staff 35279 Oct 16 1992 stevie02 -rw-r--r-- 1 thor staff 35278 Oct 16 1992 stevie03 -rw-r--r-- 1 thor staff 35012 Oct 16 1992 stevie04 -rw-r--r-- 1 thor staff 34502 Oct 16 1992 stevie05 -rw-r--r-- 1 thor staff 37476 Oct 16 1992 stevie06 -rw-r--r-- 1 thor staff 30073 Oct 16 1992 stevie07 -rw-r--r-- 1 thor staff 31562 Oct 16 1992 stevie08 -rw-r--r-- 1 thor staff 37360 Oct 16 1992 stevie09 -rw-r--r-- 1 thor staff 20662 Oct 16 1992 stevie10 -rw-r--r-- 1 thor staff 25717 Oct 16 1992 stevie11 -rw-r--r-- 1 thor staff 28075 Oct 16 1992 stevie12 -rw-r--r-- 1 thor staff 31852 Oct 16 1992 stevie13 -rw-r--r-- 1 thor staff 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor staff 8424 Apr 1 1992 syslog.shar -rw-r--r-- 1 thor staff 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor staff 16171 Oct 9 1990 taskmon.shar -rw-rw-r-- 1 root other 416642 Jan 7 14:41 tclvx7.0v4.tar.gz -rw-r--r-- 1 thor staff 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor staff 19912 Aug 27 1992 tp41.shar -rw-r--r-- 1 thor staff 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor rsf 44371 Apr 28 11:35 usrTime.shar -rw-r--r-- 1 thor rsf 4945 Apr 28 11:31 veclist01 -rw-r--r-- 1 thor staff 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor staff 43671 Nov 22 1991 vwcurses01 -rw-r--r-- 1 thor staff 40180 Nov 22 1991 vwcurses02 -rw-r--r-- 1 thor staff 38308 Nov 22 1991 vwcurses03 -rw-r--r-- 1 thor staff 31181 Nov 22 1991 vwcurses04 -rw-r--r-- 1 thor staff 31798 Nov 22 1991 vwcurses05 -rw-r--r-- 1 thor staff 31459 Nov 22 1991 vwcurses06 -rw-r--r-- 1 thor staff 24279 Nov 22 1991 vwcurses07 -rw-r--r-- 1 thor staff 5491 Dec 8 10:40 vx_cplusplus -rw-r--r-- 1 thor staff 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor staff 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor staff 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor staff 4702 Jan 16 1992 wdog_class -rw-r--r-- 1 thor rsf 6851 Apr 28 11:53 xxx