From mitchell@aaec1.aaec.com Mon Feb 1 16:18:47 1993 From: mitchell@aaec1.aaec.com Date: Mon Feb 1 16:18:54 PST 1993 Subject: Re: Backplane Net to SPARC/UNIX Hwa-Jin Bae confirmed (from his WRS days) that the backplane driver worked for VME-VME BIT-3 links worked with UNIX, and that the SUN-3e worked with the bp net (even though we didn't have time to get it right - I remember the vxWorks board that they were using did not have NVRAM for booting - it needed new PROMs to permanently change the boot params and they decided it was't worth it). As much as I'd like to, I don't have time to develop my own BP driver or lean on WRS and insist that they get this to work. But if anybody else has some time... Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | Opinions expressed here are my own, and often differ from those of AAEC From tm@syncom.lanl.gov Mon Feb 1 18:45:26 1993 From: tm@syncom.lanl.gov (Troy Moore) Date: Mon Feb 1 18:45:34 PST 1993 Subject: VxWorks space applications Hello, I am interested in corresponding with individuals involved in the development or planning of VxWorks / MicroWorks based systems for space applications. Both ground and flight applications are of interest. Thank you, Troy K. Moore Space Science and Technology Division Los Alamos National Laboratory Mail Stop D440 Los Alamos, New Mexico 87545 Tel: (505)665-3482 FAX: (505)665-4197 e-mail: tm@syncom.lanl.gov From baumann@proton.llumc.edu Mon Feb 1 19:22:11 1993 From: baumann@proton.llumc.edu (Michael Baumann) Date: Mon Feb 1 19:22:20 PST 1993 Subject: SUMMARY:Building G++ 2.3.3 Thanks to all who replied, I am in the process of fixing those things that broke between 1.40 and 2.3.3 (porting is such fun :-( ) Special thanks to Aron Bennet, who solved the libgcc1.a problems as well as giving wonderfully clear and concise directions, which I appended to this message. No debugger tho... BTW dont forget fixincludes! Helpful responses from : vanandel@wabbit4.atd.ucar.edu hoff@bnlux1.bnl.gov abenett@sadira.gb.nrao.edu Original Query: >We are now in the mode of developing code on a MVME167 and would like to >Continue to use G++. We are currently using a g++ built on gcc/g++ 1.40 >I would like to use one based on gcc 2.3.3. This would cross-compile from >a SS2 to the 167. >Has anyone gone to the pains of building such, and if so please talk to me. And the clearest directions to doing such: >From abenett@sadira.gb.nrao.edu Mon Feb 1 06:23:43 1993 >To: baumann@proton.llumc.edu >Subject: Re: G++ Cross compiler >Content-Length: 2426 >X-Lines: 47 > >I used configure --host=sun4 --target=sun3. Three things you must do are: > >1) in the file config/sun3.h which is linked to tm.h after the configure > you must comment out the following line > > #define TARGET_MEM_FUNCTIONS > > this generates calls to memcpy, memcmp and memset, but vxWorks uses > bcopy, bcmp etc. > >2) The next step is get the cross-linker running. This is a two stage process. > First get the latest version of the GNU binary utilities, binutils-2.0. > Follow the instructions for building ld targeting the sun3. Decide where > you want it installed (something like /local/bin/ld68k). Now go back to > the gcc directory and add the following define to the collect2.o rule: > >- -DREAL_LD_FILE_NAME=\"your_name_here\" > > and do a make ld. You now have a cross-linker. What actually is now happening is collect2 is installed as ld in the /local/lib/gcc-lib/sun3/2.3.3 > directory. When you link, it builds any global constructor and destructor > tables you need and then calls the REAL ld. Now install the binaries. > If you built the host version of gcc, when you installed you should have run > make install-fixincludes. You should use this include file directory in > your include path when you compile. Next you need to build a cross-assembler. Get gas-1.38.1 and build for a 68k target. Install the cross-assembler in the same location as the gcc binaries with the name 'as'. > >3) to get libgcc.a to compile be sure to add LIBGCC1=libgcc1.a OLDGCC=./xgcc > to the make command line. > >Hope this is what you need. One note, we are now trying to compile the RPC++ >libraries that were built by Michael Lipp with our new cross compiler. It >compiles everything fine until it comes to his test server and then goes into >an endless loop. We had no problem cross compiling this with gcc-2.3.2. We have >put in a bug report to GNU but have not heard anything as of yet. We are >considering going back to gcc-2.3.2. The steps I have outlined are the same >for either version so you can make the version of your choice. >Good luck, > > Aron J. Benett > abenett@nrao.edu > National Radio Astronomy Observatory > P. O. Box 2 > Green Bank, WV 24944-0002 > (304) 456-2214 > > > > > >From abenett@sadira.gb.nrao.edu Mon Feb 1 06:34:06 1993 >To: baumann@proton.llumc.edu >Subject: Re: G++ Cross compiler >Content-Length: 777 >X-Lines: 25 > >I forgot to mention one other thing, when building the ld in gcc-2.3.x in the >file collect2.c you must comment out the following line > > > /* If -r, don't build the constructor or destructor list, just return now. */ > if (rflag) > return 0; > >It should become > > /* If -r, don't build the constructor or destructor list, just return now. > if (rflag) > return 0; >*/ > >this is line 792 of collect2. What this is doing is if you link with the -r >flag, collect2 won't build the global lists you need. We want it to do this >even with the -r flag. You should also get and build the builtin++ code from >the vxWorks archives and link this in when you cross compile. This contains >the code to step through the global tables and call the constructors and >destructors. > >See ya, >Aron > > From daemon@vxw.ee.lbl.gov Thu Feb 4 04:00:44 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Feb 4 04:00:54 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Feb 4 04:00:36 PST 1993 Subject: Driver needed for MVME331 Intelligent Communication Controller Subject: Re: scsi driver needed Subject: VxWorks performance ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Driver needed for MVME331 Intelligent Communication Controller Date: Thu, 4 Feb 1993 10:31:43 GMT From: vreeburg@fys.ruu.nl (Jurriaan Vreeburg) Organization: Physics Department, University of Utrecht, The Netherlands Keywords: driver mvme331 vxworks serial Message-ID: <1993Feb4.103143.9355@fys.ruu.nl> Currently I'm looking for a driver for some VME-board which has 6 or 8 serial ports. I do have two MVME331-boards, but do not have a driver for vxWorks 5.0. Maybe someone has a driver for the MVME331, otherwise any pointers to others boards with drivers are welcome. Thanks, - -- Jurriaan Vreeburg email: vreeburg@fys.ruu.nl Department of Physics and Astronomy tel.: (+31)-(0)30-534566 P.O. Box 80.000 3508 TA Utrecht Holland --------------------------- Newsgroups: comp.sys.m68k,comp.sys.m88k,comp.realtime,comp.os.vxworks Subject: Re: scsi driver needed Date: 2 Feb 93 15:57:17 GMT From: billc@motatl.UUCP (Bill Cutts) Organization: Motorola MCG, Atlanta, GA Message-ID: <191@motatl.UUCP> References: <1993Jan29.200950.22529@adi.com> wybo@adi.com (Dave Wybo) writes: : : I am looking for some SCSI code to handle the NCR 53C710 or 53C720 SCSI chip. : If anyone has information regarding the availabliity of a driver for this chip, : I would really appreciate hearing from you. Thanks in advance. Wind River has a board support package for Motorola's MVME167 board which uses the 53C710. You could ask WRS about getting this driver. However, Wind River's driver for this chip is not a high performance driver. I have a customer using VxWorks on an MVME167 and the SCSI throughput is much lower than on the same board with other operating systems. If anyone has any information about speeding up this driver or, almost as good, a faster driver that they would share please contact me. Please contact via e-mail as I do not read this newsgroup regularly. If there is sufficient information I will summarize to the group. Thanks, Bill. - -- ______________________________________________________________________ Bill Cutts | INET : billc@atl.mcd.mot.com | Systems Engineer | UUCP : gatech!motatl!billc | Motorola Technical Systems Division | #include | --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks performance Date: 4 Feb 93 13:49:56 GMT From: andym@fulcrum.co.uk (Andrew McDermott) Organization: Fulcrum Communications Message-ID: Sender: news@fulcrum.co.uk Does anybody know of any benchmark programs for evaluating VxWorks. We are trying to evaluate it against pSOS, VRTX, OS-9. Thanks. Andy. andym@fulcrum.co.uk - ----------------------------------------------------------- Fulcrum Communications Ltd., Birmingham. B9 5LD. England. ========================================================================= Fulcrum Communications LTD., Fordrough Lane, Birmingham, B9 5LD, ENGLAND. --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Fri Feb 5 04:00:31 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Feb 5 04:00:43 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Feb 5 04:00:21 PST 1993 Subject: Re: G++ Cross compiler Subject: need suggestions for 6U VME frame grabber Subject: Re: G++ Cross compiler Subject: Re: G++ Cross compiler ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: G++ Cross compiler Date: Fri, 5 Feb 1993 14:19:12 GMT From: ameres@ithaca.cat.rpi.edu (Eric Ameres) Organization: Rensselaer Polytechnic Institute, Troy, NY Message-ID: References: <9301292142.AA17375@luke.atdiv.lanl.gov> In article <9301292142.AA17375@luke.atdiv.lanl.gov> zander@luke.atdiv.lanl.gov (Mark Zander) writes: >> Michael Baumann writes: > >> We are now in the mode of developing code on a MVME167 and would like to >> continue to use G++. We are currently using a g++ built on gcc/g++ 1.40 >> I would like to use one based on gcc 2.3.3. This would cross-compile from >> a SS2 to the 167. > >I'm currently developing code in C++ and running it on the sun. The >target environment is vxworks however so we are interested in C++ >on a 167 as well. > Is there a FAQ on this (i.e. how to setup g++ to work with vxworks)? With all the turmoil surrounding it, one would think a FAQ would make life alot easier for a lot of people. ( WRS, are you listening ? ) I'd be interested in using g++-2.3.3 with vxworks if someone could explain the nuances of setting it up. Thanks in advance, Eric. - -- - ---------------------------------------------------------------------- Eric Ameres, Software Engineer ameres@cat.rpi.edu New York State Center for Advanced Technology in Automation & Robotics Rensselaer Polytechnic Institute - CII 8313, Troy, NY 12180-3590 --------------------------- Newsgroups: comp.os.vxworks Subject: need suggestions for 6U VME frame grabber Date: Fri, 5 Feb 1993 17:39:59 GMT From: doctor@kronos.arc.nasa.gov (Terry Fong) Organization: NASA/ARC Information Sciences Division Keywords: frame grabber Message-ID: <1993Feb5.173959.13468@kronos.arc.nasa.gov> Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov) Hi all, Can anyone point me to a relatively cheap (i.e., < $8K) 6U VME frame grabber with support for VxWorks? I am interested in a very simple board (i.e., do not need image processing capabilities). Please send any replies to . If there is interested, I'll summarize and post. Thanks in advance! - -Terry - -- _______________________________________________________________________________ A straight line may be the shortest Terry Fong distance between 2 points, but it is NASA-AMES M/S 269-3, Moffett Field, CA by no means the most interesting-Dr. Who (415) 604-6063 office, 604-6081 lab --------------------------- Newsgroups: comp.os.vxworks Subject: Re: G++ Cross compiler Date: Fri, 5 Feb 1993 18:04:44 GMT From: winans@xray.aps.anl.gov (John R. Winans) Organization: Argonne National Laboratory, Chicago Illinois Message-ID: <1993Feb5.180444.16549@mcs.anl.gov> References: <9301291944.AA24699@proton.llumc.edu> Sender: usenet@mcs.anl.gov In article <9301291944.AA24699@proton.llumc.edu> baumann@proton.llumc.edu (Michael Baumann) writes: >We are now in the mode of developing code on a MVME167 and would like to >continue to use G++. We are currently using a g++ built on gcc/g++ 1.40 >I would like to use one based on gcc 2.3.3. This would cross-compile from >a SS2 to the 167. > >Has anyone gone to the pains of building such, and if so please talk to me. > I have done this and it is rather simple because the MVMW167 has an 040 on it (read as no floation point fiascos to handle.) First of all, you should know that g++ is now shipped with gcc (as of the 2.0 time frame) and as such is MUUUUCCCHHH easier to build/install. Everything will compile on a SPARC running SunOs (we don't have solaris, so I can't comment about that.) just fine. The first thing to do is make sure you have the latest version of GAS. I just untarred it and did a "make a68". When done, you will have to copy a68 into your g++ compiling area as "as" so that it can find it when building the compiler's components. (It should be in the same directory that you run the gcc configure command.) What I did is untar the gcc2.3.3 file, go somewhere else and do the configure as spec'd in the GNU INSTALL file. I specified that I wanted a sun3 cross compiler that runs on a sun4. Here is my configure command that I used. ../gcc-2.3.3/configure --with-gnu-as --with-gnu-ld --host=sparc-sun-sunos4.1 --target=m68k-sun Now your problem will be that build will stop and expect you to cough up a libgcc1.a file because it can't do that part w/o an already existing cross-compiler. If you look into what goes into that library, you will see that it is all the math functions that a machine w/o any floating point hardware can not do. But since the 040 CAN do them, you don't need that library. What I did is 'touch libgcc1.a' before I did the make. By the way... the fact that we vxWorks users don't really fully resolve our .o files (note the -r flag and possibly the -nostdlib swtiches you use in your ld commands) So spending too much time worrying about the libs is not worth your time. All you will ever use out of them would be the g++ things from libgcc2.c anyway. And even then you will have some interesting experiences when it comes to multiple copies of global variable names in the vxWorks area. Ok, so you have an empty (unneeded) libgcc1.a file. You will want to compile libgcc2.c into libgcc2.a in order to get the g++ parts. And in doing it you will get errors with eprintf()... just take it out of your Makefile's LIBGCC2 list. Then you will have trouble with builtin_new() because it wants stdio.h (same problem with eprintf). I rewrote the thing w/o the error message and removed the need for stdio.h. And ended up with a usable system. You will have to decide where the installation location should be and specify it by the "prefix" parm on your make command. My make command looked like this: make prefix="/home/winans/GNU/gcc-2.3.3Install/" LANGUAGES="c c++" You will have to mkdir the thing first and the make command will have some trouble because it will think that a section of that tree already exists and has the assembler, and loader in it already. I just waited for it to gripe and then did a mkdir on what it croaked on and then copied in the assembler and the "ld", "nm", "ar", "ranlib"... commands that came with the WRS distribution of gcc-1.40. You will find a whole directory full of things like "ld" and "strip" along with gcc-1.40's "gcc" command... just copy them all over to the magic directory that you see your make command die on. (I think it will be something like $prefix/gcc-sun3/bin or $prefix/gcc-sun3/lib.) I suggest that you ftp over the g++ files from thoratd.ucar.edu and look at the file "vx_cplusplus" It talks about the 1.40 version of g++ (or did the last time I looked at it.) It will very useful in teaching you what the important library functions are that are needed to handle the construction and destruction of objects. My gutt feeling is that you should try to use the functions from libgcc2.c that are described in that document. Because GNU could change them, and you should know where to look for the final word on how they are expected to work by the g++ compiler. Now if you do all the things mentioned here, the build will run to the point where it tries to test the cross-compiler's interaction with libgcc1.a. It will assume that you have a crt0.o file and that you want a fully resolved a.out file... This is not true for us vxWorks users. So you should remove the line in the Makefile that does the loading-step of cross-test. Go ahead and build cross-test.o though... you will want to compile cross-test.c into a .o file and then run "nm" on it to make sure there are no unresolved references to floating point stuff. Because the floating point junk should have been compiled in directly. (The float stuff have names that are listed in your Makefile as the members of LIBGCC1 and have names like "muldi" and "divdi".) By the way, when I compile MY files I use the -m68040-20 switch. Because GAS does not seem to understand the 040 floating point mneumonics, but the 030/881 code seems to work fine. I suspect you also could use -m68030 and get the same thing. This info, along with the thor.* doc file(s), should get you going to the point where you can build and run your g++-2.3.3 programs. Good luck! If you are serious (try it before asking) about using g++ and are totally stuck on something related to compiling/linking/loading your files, I'd be happy to help you out, but email me because I don't always keep up with news.. I read too many groups. I will post anything that might be useful to others. Other g++ questions are welcome too, but be warned, I am far from posessing a GOOD understanding of the language itself. - --John - -- ! John Winans Advanced Photon Source (Controls) ! ! winans@mcs.anl.gov Argonne National Laboratory, Illinois ! ! ! !"The large print giveth, and the small print taketh away." - Tom Waits ! --------------------------- Newsgroups: comp.os.vxworks Subject: Re: G++ Cross compiler Date: Fri, 5 Feb 1993 23:41:09 GMT From: bard@cutter.ssd.loral.com (J H Woodyatt) Organization: Abiogenesis 4 Less Message-ID: <1993Feb5.234109.21717@wdl.loral.com> References: <9301292142.AA17375@luke.atdiv.lanl.gov> Reply-To: bard@cutter.ssd.loral.com Sender: news@wdl.loral.com ameres@ithaca.cat.rpi.edu (Eric Ameres) writes: # Is there a FAQ on this (i.e. how to setup g++ to work with vxworks)? # With all the turmoil surrounding it, one would think a FAQ would make # life alot easier for a lot of people. ( WRS, are you listening ? ) # # I'd be interested in using g++-2.3.3 with vxworks if someone could # explain the nuances of setting it up. Wind River Systems strongly recommends that you use the C cross-compiler they supply, and I have heard unsubstantiated rumors of their intentions to use cfront for optionally allowing C++ development under VxWorks 5.1. If you use g++-2.3.3, you're doing something WRS recommends against, so keep your WRS support in mind if you're planning on doing this. Here's an outline of what I had to do to get a G++ cross-compiler from SPARC to MC68030 working: Build a GCC-2.3.3 cross-compiler with ./configure --host=sun4 --target=sun3. Make sure that the ANSI builtin functions that GCC/G++ expects are available. VxWorks 5.0.2b doesn't have a memcpy() function, for instance. Write routines that construct and destruct all global objects that have constructors and destructors. Write the builtin operators new and delete and supporting routines. Make sure the GCC command driver is called with the right arguments at link-time, e.g.: gcc -b sun3 -V2.3.3 -o program -nostdlib -r -e _program program.o foo.o bar.o baz.o (The -e is necessary, because otherwise the linker references an undefined symbol `start.' Get used to the fact that VxWorks 5.0's header files don't really support C++, i.e. the delete() function. They come close enough so that they require minimal modification to work, though. You'll just have to slug through it. Make sure you always #include them while inside extern "C" { } constructs. Apply the following patch to gcc-lib/sun3/2.3.3/specs to silence annoying messages from the VxWorks dynamic loader: - --- specs.ORIG Thu Jan 7 09:03:27 1993 +++ specs Thu Jan 14 17:26:30 1993 @@ -17,7 +17,7 @@ *link: - -%{!nostdlib:%{!r*:%{!e*:-e start}}} -dc -dp %{static:-Bstatic} %{assert*} +%{!e*:-e start} %{!r*:-dc -dp} %{static:-Bstatic} %{assert*} *lib: Alternatively, you could ignore the patch above, and call the cross-linker directly with the appropriate arguments. A patch for GCC-2.3.3 exists for enabling the `-fno-builtin' flag in G++. I might still have it somewhere. I got it from Mike Stump, I think. There are more elegant ways to do this, but I was in hack-mode. Elegance would be modifying GCC so that VxWorks is one of the OS's that ./configure supports, so that it could be invoked with gcc -b vxworks-mc68030 or something. - -- +---------------------------+ ``When giving us dominion over the | J H Woodyatt | Earth, did God choose an appropriate | bard@cutter.ssd.loral.com | technology?'' +---------------------------+ -- Senator Albert Gore --------------------------- End of New-News digest ********************** From etnibsd!steve@uunet.uu.net Sun Feb 7 14:50:59 1993 From: etnibsd!steve@uunet.uu.net (Steve Myers) Date: Sun Feb 7 14:51:08 PST 1993 Can anyone give me some information about this error message we are seeing: t4: panic: netJobAdd: ring buffer overflow We are still running 4.2 on an MVME133XT board. Under what circumstances is netJobAdd called? We have been running 4.2 for a few years now on two cards in a VME chassis with both backplane and ethernet communications using UDP sockets and this is a new one on us. Any help would be greatly appreciated. Thanks. Steve From murad@mars.dgrc.doc.ca Sun Feb 7 16:59:57 1993 From: murad@mars.dgrc.doc.ca (Murad Mirza) Date: Sun Feb 7 17:00:09 PST 1993 Subject: Port from iRMX-II Hi, I am starting to port PLM/iRMX-II applications to C/VxWorks. Has anybody in VxWorld done such Work(s). If yes, can you provide your opinion(s)? Thanks in advance. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Murad Mirza + I'll get a lot of plus CRC/Dept. of Communication + points for this one. Ottawa, Ontario + (anonymous) Ph: (613) 998-2423 + Fax: 990-7987 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From harvey@wrs.com Sun Feb 7 22:40:59 1993 From: harvey@wrs.com Date: Sun Feb 7 22:41:09 PST 1993 Subject: Token ring and floppy Dear VxWorks Users, Does anyone know of a VxWorks driver for Token ring (either supported or share-ware)? I'm also looking for any drivers for floppy disk controllers. Thanks in advance... Sincerely, Harvey Wong Wind River Systems, Inc. harvey@wrs.com From daemon@vxw.ee.lbl.gov Mon Feb 8 04:00:28 1993 From: daemon@vxw.ee.lbl.gov Date: Mon Feb 8 04:00:37 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Feb 8 04:00:20 PST 1993 Subject: Serial driver request: SCC 269[12]; 85C30 Subject: Info Wanted: PLC's and VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Serial driver request: SCC 269[12]; 85C30 Date: 8 Feb 93 18:43:07 GMT From: kab@strl.labs.tek.com (Kent Black) Organization: STRL, Tektronix, Inc. Message-ID: <5138@crl.LABS.TEK.COM> Sender: news@crl.LABS.TEK.COM I am requesting drivers or pointers to BSP's for: Signetics SCC 2691 UART -- unknown if it is with any BSP Signetics SCC 2692 DUART -- unknown if it is with any BSP Also, I know that the Zilog 8530 is common and I believe the 85C30 is pin compatible (CMOS version): is the 8530 driver sufficient for the 85C30? Thanks, - -- kab Kent Black ----------------------------------------------------------------- STRL, Tektronix Inc. | Email: kab@crl.labs.tek.com P.O. Box 500, M/S 50-662 | Voice: (503) 627-6280 Beaverton, OR 97077 | FAX: (503) 627-5502 ----------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks,comp.realtime Subject: Info Wanted: PLC's and VxWorks Date: Mon, 8 Feb 1993 23:51:34 GMT From: dat@noao.edu (D'Anne Thompson) Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Message-ID: <1993Feb8.235134.11227@noao.edu> Sender: news@noao.edu We are looking to integrate a PLC with our real-time system (VxWorks, 68K, Ethernet TCP/IP). We want to read/write i/o points and to receive unsolicited alarm messages from the PLC (i.e. non-polling). Does anyone have information about a PLC system which might suit our needs ? D'Anne Thompson National Optical Astronomy Observatories P.O. Box 26732, Tucson, AZ 85726 (602) 325-9335 dat@noao.edu {...}!uunet!noao.edu!dat - -- D'Anne Thompson National Optical Astronomy Observatories P.O. Box 26732, Tucson, AZ 85726 (602) 325-9335 dat@noao.edu {...}!uunet!noao.edu!dat --------------------------- End of New-News digest ********************** From kwaldman@bbn.com Mon Feb 8 16:17:07 1993 From: kwaldman Date: Mon Feb 8 16:17:17 PST 1993 Subject: Using MV167 and a Exabyte 8500 When using an Exabyte 8500 drive with a Motorola MVME167 (68040) and Paul Baade's driver program and VxWorks 5.02b. There are two changes that need to be done : 1. Get the new ncr710Lib.o file from WRS. (this fixes the floating point/scsi problem) I hesitate to call this a bug, but I didn't think C would allow you to return anything bigger than 32 bits? I could be wrong here but if I don't have this fix the program doesn't work, if I have this change it does work. I'd welcome any input on this one. 2. Change the EXB_STATUS structure in exabyte.h to The number of bits for reserved should be 20 so change reserved :21, to reserved :20, This will allow the struct to fit into an long int (32 bits ) instead of the 33 bits it is now. I suspect this worked on the 147 because caching is done on the data as well as the instructions in the 167 but on the 147 only instructions are cached. Here's the complete unmodified structure. (from Exabyte.h) >/**********************************************************/ > > >typedef struct >{ > unsigned senseDataValid :1, /* indicates if bits 1-7 are valid */ > tapeNotPresent :1, > writeProtect :1, > endOfMedia :1, /* Logical EOT or BOT */ > bot :1, /* beginning of tape */ > peot :1, > filemark :1, /* read a filemark */ > ili :1, /* incorrect logical blk length req. */ > reserved :21, <-------------------------CHANGE THIS TO 20 > errorCode :4; /* error code is always valid */ >}EXB_STATUS; Thanks to Paul for the driver program and Phil Perillat for his settings on the Exabyte 8500. I actually am beating the Spec, of course we shall see what happen's when I put two drives on it.:-) Hope's this help's somebody. Thanks Karl P.S. Here's the needed info I got from Phil Perillat For the mode select i'm transfering 17 bytes. 4 bytes from parameter list header 12.2 pg 12-7 of manual 8 bytes from block descriptor 12.3 pg 12-9 5 bytes from vendor unique params 12.4 pg 12-12 i'm using the non-page format since it is then compatible with the 8200. There's many more setting which I'd be glad to forward to anyone of interest. From mitchell@aaec1.aaec.com Mon Feb 8 22:22:27 1993 From: mitchell@aaec1.aaec.com Date: Mon Feb 8 22:22:37 PST 1993 Subject: Re: panic: netJobAdd: >Can anyone give me some information about this error message >we are seeing: > >t4: panic: netJobAdd: ring buffer overflow I saw similar errors when first working on a network device driver with 4.0.2. The netJobAdd is called by any network device driver that wants a function to be executed at task level. In our driver, the ISR that handles the network board would add a function call to the netTask job queue. If the netTask was blocked or simply overran with interrupts, the queue would fill and we would get panic logMsgs from the interrupt level. It looks like your 't4' task is calling a device driver (socket calls to ethernet) faster than it can keep up. I guess I can beleive this since UDP (datagram) transfers don't have to wait around and see that that the "etherOutput" call was completed. It could just hand it over to the netTask and go on its way. Is t4 at higher priority than netTask? That could be a bad thing. good luck - acm. Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | Opinions expressed here are my own, and often differ from those of AAEC From mitchell@aaec1.aaec.com Mon Feb 8 23:18:23 1993 From: mitchell@aaec1.aaec.com Date: Mon Feb 8 23:18:31 PST 1993 Subject: Re: Serial driver request: SCC 269[12]; 85C30 >I am requesting drivers or pointers to BSP's for: > Signetics SCC 2691 UART -- unknown if it is with any BSP > Signetics SCC 2692 DUART -- unknown if it is with any BSP Synergy uses the 2692 for their console and tty1, so its in their BSP. I don't know if its available from WRS or Synergy (619)753-2191. Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | Opinions expressed here are my own, and often differ from those of AAEC From daemon@vxw.ee.lbl.gov Tue Feb 9 04:00:29 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Feb 9 04:00:39 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Feb 9 04:00:21 PST 1993 Subject: Jerry Fiddler at Real-time Symposium Subject: mvme-167 tips requested ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Jerry Fiddler at Real-time Symposium Date: 10 Feb 93 02:41:53 GMT From: smith@ampersand.com (Steve Smith) Organization: Ampersand Inc., Westford, Mass. Message-ID: Hi all, Thought I'd write a quick note letting comp.os.vxworks and comp.realtime know about a Real-time Technical Computing Symposium that's coming up on Feb 23 here in Boston. Jerry Fiddler of Wind River Systems is giving the keynote address. The symposium then splits into three tracks; real-time, DSP, and computer math. The tracks run twice (once in the morning and once in the afternoon), so you can catch two out of the three. In the real-time track two of the six speakers are presenting information about VxWorks. Tony Barbagallo of Wind River Systems is going to present information about VxWorks 5.1 features. Mark Miller of Target Technologies is going to talk about application development under a VME & VxWorks environment. Both will be available to handle questions. The symposium is fairly inexpensive - $35 for advance registration. Further information, including an agenda, is available from: ESI Computing 468 Westford Road Carlisle, MA 01741-1504 Phone: (508) 369-8499 Fax: (508) 369-7612 Financial Disclaimer: I am volunteering some time to help run this thing but in no way am I being compensated for such activities. (O.K, well maybe the guys at ESI will buy me a beer when it's over :-) ). For the VxWorks crowd: I spoke at the symposium last year and found there to be quite a number of the local VxWorks users present. It's awhile until the next East Coast VxWorks User's Group meeting; this might be a good chance to get some current Wind River Systems info. I'd enjoy seeing any of the crew that make it! Hope to see some of you there! Steve Smith Ampersand, Inc. --------------------------- Newsgroups: comp.os.vxworks,comp.realtime Subject: mvme-167 tips requested Date: 9 Feb 93 16:47:49 GMT From: kearns@budoe.bu.edu (Ed Kearns) Organization: Boston University Physics Department Message-ID: <109834@bu.edu> Followup-To: comp.os.vxworks Sender: news@bu.edu Hello net! I have a MVME-167, some home-built VME boards that I am trying to test. I have the Motorola documentation, including the programmers reference. Although the documentation seems complete, it is rather dense and devoid of examples. I am writing to see if anyone can provide helpful information about some of the operations I am working on. 1) DMA Block Transfers: I am doing these almost successfully. I am transferring 64K from VMEbus to the localbus memory. When I check the local memory to see if every word was written correctly, I often find a sequence of 5-50 longwords have not been transferred. Before and after that sequence of addresses everything is A-OK. This sounded like the known bug mentioned by phil @ arecibo; however disabling interrupts did not help. 2) VME interrupts: I am not having much success. I enable the registers as it seems correct to me. With a scope, I see the IRQ1 line go high and then get acknowledged. In the meantime I'm polling the status register but the bit for IRQ1 is never set. I would also be interested in clues about how to properly use the programmable map decoders (eg to do A32/D32 transfers) and how to properly do fast timing with the tick timer. Thanks, --------------------------- End of New-News digest ********************** From rebibo%cesar@crbca1.sinet.slb.com Tue Feb 9 10:22:45 1993 From: rebibo%cesar@crbca1.sinet.slb.com (NICOLAS REBIBO) Date: Tue Feb 9 10:22:57 PST 1993 Subject: New to driver development Hi, I am new to real-time and to vxWorks. My boss asked me to have a look at the development of drivers with vxWorks (mainly Centronics and RS232). I will be interested in some code examples, with a clear separation between hardware dependant code and pure protocol implementation (to have an idea of their respective size). As I do not subscribe (yet) to this mailing list, please email directly to me. Thanks for any help, Nicholas Rebibo Internet: rebibo@crbca1.sinet.slb.com From daemon@vxw.ee.lbl.gov Wed Feb 10 04:00:40 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Feb 10 04:00:50 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Feb 10 04:00:30 PST 1993 Subject: Re: panic: netJobAdd: ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: panic: netJobAdd: Date: 10 Feb 93 16:37:54 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star Project -- Oakland, CA Message-ID: <1993Feb10.163754.7639@netcom.com> References: <9302100204.AA12265@sparky.noname> In article <9302100204.AA12265@sparky.noname> mitchell@aaec1.aaec.com writes: >>t4: panic: netJobAdd: ring buffer overflow > >I saw similar errors when first working on a network device driver with >4.0.2. The netJobAdd is called by any network device driver that wants a >function to be executed at task level. this is true. netJobAdd is also used by a few other things... various network related timers: tcp fast (200ms) and slow (500ms) timeout, arp timer, etc. >In our driver, the ISR that handles >the network board would add a function call to the netTask job queue. If >the netTask was blocked or simply overran with interrupts, the queue would >fill and we would get panic logMsgs from the interrupt level. this can be prevented by only enqueuing a new job for the same 'type' of network interrupt from the driver; the job added should handle all available input/output conditions. newer netif drivers do this. >It looks >like your 't4' task is calling a device driver (socket calls to ethernet) >faster than it can keep up. I guess I can beleive this since UDP >(datagram) transfers don't have to wait around and see that that the >"etherOutput" call was completed. this sounds believable... but UDP code will go through normail netif interface, not etherLib routines (you probably mean ether_output which is different from etherOutput). :-) and udp_output -> ip_output -> ifxx_output -> ether_output -> ifxx_start sequence will complete all the way once invoked. so the caller will wait to see that ether_output has completed. also, depending on how big the send side socket buffer is for the UDP transfer, the application can be blocked (at the sosend level) when buffer runs out until the lower level code (system network code) drains the output buffer of the socket if multiple tasks use the same socket. since the default send side buffer size for the UDP socket is 2K, this would happen quite frequently in a busy system. this size is adjusted by using setsockopt() calls so the behavior may differ depending on each application... but the user task will block. however if there's one task simply sending UDP data of precise size that fits the socket lever send buffer and does this sending out continuously at a higher priority than netTask, things may not work. netTask needs to be able to service tx completion, rx ready interrupts from the netif drivers, various timeouts, etc. if not, eventually the netJob queue will overflow. there are ways to get around this problem as well but it's not in the latest vxworks release as far as i know. > Is t4 at higher priority than netTask? That >could be a bad thing. this is true. in general, keep the network app tasks' priorities lower than that of netTask.... love hwajin - -- H. J. Bae / Peaceful Star Project / 2899 Ford Street, Oakland CA 94601 hjb@netcom.com (510) 536-7607 --------------------------- End of New-News digest ********************** From tlusco@inquisitor.gsfc.nasa.gov Wed Feb 10 11:09:24 1993 From: tlusco@inquisitor.gsfc.nasa.gov (C. Tom Lusco) Date: Wed Feb 10 11:09:34 PST 1993 Subject: bcopy reads with 68040 Hello! We have been having some problems with the behavior of 68040 CPUs when doing a bcopy from global memory. After attaching a VMETRO, we learned the following: instruction: bcopy ( globalAddr, localAddr, 1104 ) expected bus activity: long read from globalAddr by processor long read from globalAddr+4 by proc. long read from globalAddr+8 by proc. ... long read from globalAddr+1100 by proc. instead, we actually see: long read from globalAddr by proc. long read from globalAddr by proc. long read from globalAddr+4 by proc. long read from globalAddr+4 by proc. long read from globalAddr+8 by proc. long read from globalAddr+8 by proc. ... long read from globalAddr+1100 by proc. long read from globalAddr+1100 by proc. Why is the 68040 doing multiple bus reads? This does not occur with our 68030 boards. Caching modes are all set to INHIBIT_SERIALIZED. We are very puzzled by this behavior. Comments, on exploder or personal, are welcomed. Tom Lusco NASA/GSFC tlusco@inquisitor.gsfc.nasa.gov From harvey@wrs.com Wed Feb 10 14:50:45 1993 From: harvey@wrs.com Date: Wed Feb 10 14:50:54 PST 1993 Subject: real-time symposium Dear VxWorks Users and Partners, Wind River Systems will be participating in a real-time symposium on Tuesday, February 23 at the Burlington Marriott Hotel in Burlington, Massachusetts and would like to invite all interested customers and potential customers to attend. The symposium is organized by ESI Computing and will include presentations and demos from Wind River Systems, Force Computers, AP Labs, Trilogic, Mercury Computers, Heurikon, National Instruments, Motorola, Sun Microsystems, CSPI, Hewlett Packard, Target Technologies and a variety of other vendors. The symposium will allow vendors and developers discuss and demonstrate the latest technologies for real-time, DSP, and computer mathematics. Speakers from Wind River Systems will include Jerry Fiddler, CEO, who will give the keynote presentation on "Software Development Issues in Real-Time Applications", and Tony Barbagallo, Director of Product Marketing, who will present "VxWorks 5.1 Features and Future Directions." To register for the symposium or for more detailed info, please contact ESI Computing at phone 508/369-8499 or fax 508/369-7612. Cost is $35 and includes lunch. Sincerely, Harvey Wong Wind River Systems, Inc. Ph: 510/814-2051 harvey@wrs.com P.S. - I'd be glad to fax a full agenda to any interested parties. From mea@sparta.com Wed Feb 10 19:54:36 1993 From: mea@sparta.com (Mike Anderson) Date: Wed Feb 10 19:55:02 PST 1993 Subject: Re: Token ring and floppy Harvey et al, We have drivers for Teac 3.5" (and it seems to work for the 5 1/4") SCSI floppy drives. Can't help you on the Token Ring (I assume you mean IBM Token Ring). We do have Proteon Token Ring (ProNet-80) working and we're trying to get the Interphase 4211 FDDI to work with the i960 (byte ordering on the i960 from the VMEbus coupled with gcc's crazy byte alignment is driving us nuts). BTW, is there anyone who knows if the gcc960 compiler has a "packed" mode for data alignment? The gcc960 compiler is aligning variables on double word boundaries that make it very difficult to pass a structure across the bus to a byte-aligned machine like a 68k or the Interphase FDDI board's AMD 29K. Thanks, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From daemon@vxw.ee.lbl.gov Thu Feb 11 04:00:42 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Feb 11 04:00:53 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Feb 11 04:00:33 PST 1993 Subject: 167/EXB-8500 problem Subject: Re: Token ring and floppy Subject: Re: Token ring and floppy ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: 167/EXB-8500 problem Date: 11 Feb 1993 22:36:18 GMT From: slimmer@fndaud.fnal.gov (Dave Slimmer) Organization: Fermi National Accelerator Laboratory, Batavia IL Keywords: vxworks Message-ID: <1lekd2$3ut@fnnews.fnal.gov> Has anyone else seen this .... Our engineers have been analyzing SCSI bus activity between a EXB-8500 and a MVME167. There seems to be an automatically generated Test Ready command from the MVME167 NCR710 driver software every time a SCSI command returns a Check Condition status. As the SCSI bus trace below indicates, this test involved a MVME167 writing test data to the EXB-8500 until a Write command returned a Check Condition status. At that point, the next command generated under test software control is a Request Sense command. As the "<********" arrow indicates, the MVME unexpectedly generated a Test Ready command with invalid data in the command block. The Request Sense command correctly identifies that the Test Ready command was an illegal command. This behavior causes other information returned in the sense buffer to be masked - in this case that the Check Condition status was returned because the tape had reached the logical end of media. We have also observed the MVME 167 generating an illegal Test Ready command with invalid data in the command block after issuing a scsiPhysDevCreate command. Is this a known problem, and if so, is there a patch available? I don't believe we have the patch for the floating point problem, but I'm not sure at this point that the problems are directly related. I have included additional configuration information from the MVME 167 and EXB-8500 that follows the SCSI bus trace. SCSI Bus Analyzer Trace (partial) ================================= 07F36: Bus free 07F37: Arbitration /80 (7) 07F3A: Select /81 (0,7) 07F3D: Command /0A (Write/Send)00 01 00 00 00 07F43: Data-Out/00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 07F53: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 07F63: Status /00 (Good) 07F64: Message-In /00 (Cmd Cmplt) 07F65: Bus free 07F66: Arbitration /80 (7) 07F69: Select /81 (0,7) 07F6C: Command /0A (Write/Send)00 01 00 00 00 07F72: Data-Out/00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 07F82: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 07F92: Status /00 (Good) 07F93: Message-In /00 (Cmd Cmplt) 07F94: Bus free 07F95: Arbitration /80 (7) 07F98: Select /81 (0,7) 07F9B: Command /0A (Write/Send)00 01 00 00 00 07FA1: Data-Out/00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 07FB1: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 07FC1: Status /02 (Chk Cond) 07FC2: Message-In /00 (Cmd Cmplt) 07FC3: Bus free 07FC4: Arbitration /80 (7) 07FC7: Select /81 (0,7) 07FCA: Command /00 (Test U Rdy)FC F0 84 00 01 <************ 07FD0: Status /02 (Chk Cond) 07FD1: Message-In /00 (Cmd Cmplt) 07FD2: Bus free 07FD3: Arbitration /80 (7) 07FD6: Select /81 (0,7) 07FD9: Command /03 (Req Sen)00 00 00 1D 00 07FDF: Data-In /70 00 45 00 00 00 00 15 00 00 00 01 25 00 00 00 07FEF: 00 37 6C 00 00 00 00 FF FC 31 00 00 D1 07FFC: Status /00 (Good) 07FFD: Message-In /00 (Cmd Cmplt) 07FFE: Bus free 07FFF: ---- end of recording ---- MVME 167 ======== Struct version: 0.10 Board serial # 1085100 Board identification: MVME167B Printed Wiring Assembly # 01-W3632B03F Board speed (MHz): 25.00 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]] ]]]] ]]]]]]]]]] ]] ]]]] TM ] ]]]]]]]]] ]]]]]] ]]]]]]]] ]] ]]]] ]] ]]]]]]] ]]]]]]]] ]]]]]] ] ]] ]]]] ]]] ]]]]] ] ]]] ] ]]]] ]]] ]]]]]]]]] ]]]] ]] ]]]] ]] ]]]]] ]]]] ]]] ]] ] ]]] ]] ]]]]] ]]]]]] ]] ]]]]]]] ]]]] ]] ]]]] ]]]]] ] ]]]] ]]]]] ]]]]]]]] ]]]] ]] ]]]] ]]]]]]] ]]]] ]]]]]] ]]]]] ]]]]]] ] ]]]]] ]]]] ]] ]]]] ]]]]]]]] ]]]] ]]]]]]] ]]]]] ] ]]]]]] ] ]]] ]]]] ]] ]]]] ]]]] ]]]] ]]]] ]]]]]]]] ]]]]] ]]] ]]]]]]] ] ]]]]]]] ]]]] ]]]] ]]]] ]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]] Development System ]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]] VxWorks version 5.0.2b-68040 Release-1. ]]]]]]]]]]]]]]]]]]]]]]]]]] KERNEL: WIND version 2.0. ]]]]]]]]]]]]]]]]]]]]]]]]] Copyright Wind River Systems, Inc., 1984-1991 CPU: Motorola MVME167. Processor #0. Memory Size: 0x1000000. EXB-8500 Inquiry Output ======================= Peripheral Qualifier = 0 Peripheral Device Type = 1 RMB = 1 Device-Type Modifier = 0 ISO Version = 0 ECMA Version = 0 ANSI Version = 2 AENC = 0 TrmIOP = 0 Reserved = 0 Response Data Format = 2 Additional Length = 65 reserved1 = 0 reserved2 = 0 RelAdr = 0 WBus32 = 0 WBus16 = 0 Sync = 1 Linked = 0 RSVD = 0 CmdQue = 0 SftRe = 0 Vender Identification = EXABYTE RSVD = 0 CmdQue = 0 SftRe = 0 Vender Identification = EXABYTE Product Identification = EXB-850085BANXR5 Product Revision Level = 042C Vender Specific = Reserved Space = Unit Serial Number = 00264ED9 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Token ring and floppy Date: Fri, 12 Feb 1993 00:45:19 GMT From: lapp@waterloo.hp.com (David Lapp) Organization: HP Panacom Div Waterloo ON Canada Message-ID: References: <9302112338.AA00279@borg> Sender: news@waterloo.hp.com (NetNews) Mike Anderson (mea@sparta.com) wrote: : BTW, is there anyone who knows if the gcc960 compiler has a "packed" : mode for data alignment? The gcc960 compiler is aligning variables on : double word boundaries that make it very difficult to pass a structure : across the bus to a byte-aligned machine like a 68k or the Interphase : FDDI board's AMD 29K. Try #pragma align 1 before the declarations you want to be byte aligned. A #pragma align 0 returns to the previous alignment. Dave Lapp lapp@waterloo.hp.com Standard Disclaimer etc... --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Token ring and floppy Date: Fri, 12 Feb 1993 01:48:17 GMT From: rypma@waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: References: <9302112338.AA00279@borg> Sender: news@waterloo.hp.com (NetNews) Mike Anderson (mea@sparta.com) wrote: : BTW, is there anyone who knows if the gcc960 compiler has a "packed" : mode for data alignment? The gcc960 compiler is aligning variables on : double word boundaries that make it very difficult to pass a structure : across the bus to a byte-aligned machine like a 68k or the Interphase : FDDI board's AMD 29K. Intel added a '#pragma align n' to the 960 gcc compiler, where n is the number of bytes to which to padd. We compile all of our LAN controller driver structures with '#pragma align 1'. It's in 1.37 and up. There's also a '#pragma pack n' in 2.0. Ted Rypma HP Panacom Division Waterloo, Ontario --------------------------- End of New-News digest ********************** From m_wk@unibw-hamburg.de Thu Feb 11 06:22:47 1993 From: Michael Date: Thu Feb 11 06:22:55 PST 1993 Subject: Graphics Display Card Force AGC 3/4 Hi folks, I am looking for information concerning a FORCE AGC3/4 graphical VMEbus-Board. The board is included in a VMEbus-System having a FORCE CPU40 as master board. We would like to do rapid data visualization of process parameters. This task could be made much easier if the card acts as an X server. If not, we would have to write a VxDriver for the card which might already exist. Bye M.P. Witzak University of Federal Forces(FRG), Hamburg From tlusco@inquisitor.gsfc.nasa.gov Thu Feb 11 12:50:41 1993 From: tlusco@inquisitor.gsfc.nasa.gov (C. Tom Lusco) Date: Thu Feb 11 12:50:51 PST 1993 Subject: bcopy problem resolved Fellow vxWorks users! I would like to thank all of you that responded to my bcopy error report. Now I would also like to report that the problem has been solved. The first time we did a bcopy from global memory ( A32 space ) the bcopy did as we expected: it generated multiple read cycles on the VME, each reading 32 bits and following 4 bytes in address space from the previous read. However, each bcopy thereafter was different, with 2 32-bit reads for each address,except for the very first cycle. Illustration: Address Read ------ ---- 0x44000000 D32 0x44000004 D32 0x44000008 D32 0x4400000C D32 0x44000000 D32 0x44000004 D32 ... 1st bcopy done 0x4400044C D32 2nd bcopy started 0x44000450 D32 2nd bcopy doing double 0x44000454 D32 0x44000454 D32 0x44000458 D32 0x44000458 D32 0x4400045C D32 0x4400045C D32 0x44000460 D32 0x44000460 D32 0x44000464 D32 0x44000464 D32 ... 2nd bcopy done 0x4400089C D32 This behavior was very puzzling, until we learned the following. The pointer to global memory was being incremented by a fixed amount 0x450. However, if the data to be read did not lie evenly on a 0x450 boundary, the pointer would be moved to the actual begin location. If this did not lie on a longword boundary, we would see the above strange behavior. The reason for this lies in the way bcopy functions. If source pointer is on a long word boundary, bcopy will do successive longword reads with 4 byte address increments between each read. However, if source pointer is word- aligned, bcopy will do a longword read twice for each 4-byte incremented address: once to get the first word, once to get the second word. Each read, although 32-bit in nature, actually resulted in only 16-bits being copied to local RAM. Similarly, if source pointer was on a byte boundary, bcopy would actually do four reads for each address!! We saw this behavior too, but only after we really looked for it ( the data tended to begin on word boundaries). Note that the flavor of the reads (32 bit reads to get 16 bits) seems to be related to the CPU architecture. We ran the same code on some 68030 boards, and they did a 16 bit read to get 16 bits of data. I tstill resulted in the same number of VME reads as the 040's 32bits to get 16, just looked different on the analyzer. We are now in the process of updating the source to account for data shifted, to read the beginning to the longword boundary and only THEN do a bcopy, then finish up reading the rear. This seems like it will work fine. I hope this was clearly explained. If it wasn't ( and you care ) say so and I'll try to explain furthur. Tom Lusco NASA/GSFC VxWorks sufferer Thank you VMETRO! tlusco@inquisitor.gsfc.nasa.gov From visicom!VisiCom.COM!trest@nosc.mil Sun Feb 14 14:11:51 1993 From: Mike Trest Date: Sun Feb 14 14:12:00 PST 1993 Subject: MVME167/NCR710 TEST_UNIT_READY garbage > From: slimmer@fndaud.fnal.gov (Dave Slimmer) > Has anyone else seen this .... > > Our engineers have been analyzing SCSI bus activity > between a EXB-8500 and a MVME167. There seems to be > an automatically generated Test Ready command from the MVME167 > NCR710 driver software every time a SCSI command returns a Check Condition > status. Question: Are you using scsiLib.o? Are using the WRS provided NCR710 driver? It is my experience that any transaction which results in a Check Condition will cause a scsiLib STATUS_CHECK_CONDITION transaction which will result in a REQUEST_SENSE being seen at the SCSI level. I know this may not be your garbage TEST_UNIT_READY but if your driver or application software is calling the routine referenced in pScsiBlkDev->blkDev.bd_statusChk as a response to the CHECK_CONDITION that routine [scsiStatusCheck()] will issue a TEST_UNIT_READY. > > We have also observed the MVME 167 generating an illegal Test > Ready command with invalid data in the command block after > issuing a scsiPhysDevCreate command. > The scsiStatusCheck() (referenced in pScsiBlkDev->blkDev.bd_statusChk), which issues a TEST_UNIT_READY, is called indirectly by the VxWorks file system support before doing open() or creat(). This check can be avoided by scsiLib users by making sure the block device is marked as NOT REMOVABLE when the device is created. I have recently encountered a similar problem when I was doing an explicit loop of TEST_UNIT_READY commands to determine the status of several SCSI devices. The routine works on every SCSI board and driver combination from WRS except the MV167/NCR710. I ,too, got garbage on TEST_UNIT_READY commands but I also see a MV167/NCR710 driver error message. Since I enjoy the benefits of a support contract, I contacted WRS to describe my problem. WRS provided a "latest and greatest" driver (which I understand has a corrected NCR710 SCRIPT) which does fix my problem. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From xhd@zfssun1.tz.rus.uni-stuttgart.de Sun Feb 14 15:21:58 1993 From: xhd@zfssun1.tz.rus.uni-stuttgart.de (Nikolaus Hild / ZFS) Date: Sun Feb 14 15:22:11 PST 1993 Subject: Documentation Tool Hello vxw users, I'm looking for a source code documentation tool running under unix, which can do things like extract trees of routine calls extract the shape of complex data structures The tool should be able to handle a system of C source modules and headers and produce a fomatted well readable output. Kind regards, ____________________________________________________________________ | | | N. Hild | | Centre for Manufacturing Technologies Stuttgart | | Nobelstr. 15 | | 7000 Stuttgart 80 | | Germany | |____________________________________________________________________| | | | Phone: 0711 13162-41 | | Fax: 0711 13162-11 | | Email: xhd@zfssun1.tz.rus.uni-stuttgart.de | |____________________________________________________________________| From daemon@vxw.ee.lbl.gov Mon Feb 15 04:00:49 1993 From: daemon@vxw.ee.lbl.gov Date: Mon Feb 15 04:00:59 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Feb 15 04:00:40 PST 1993 Subject: Global Variable Initialization ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Global Variable Initialization Date: Mon, 15 Feb 1993 19:49:35 GMT From: geger@hellcat.den.mmc.com (George Eger (303) 971-6974) Organization: Martin Marietta Astronautics Group Keywords: Kernel Init Linker Message-ID: <1993Feb15.194935.27296@den.mmc.com> Sender: news@den.mmc.com (News) I have just spent 4 hours debugging something that appears to be a GNU linker error, but I would appreciate some comments. It concerns how and when global variables are initialized in the VxWorks kernel. We are using the mpLib code (from Alain Ninane) on a mv167. In part of the initialization code, a routine to catch mailbox writes (that make up the multiprocessor semaphores) is attached to a vmechip2 interrupt. This routine is like sysMailboxConnect and uses a sysMailboxConnected-like flag to warn of multiple attempts to connect the ISR. As long as this flag was declared inside the routine, it was initialized correctly to FALSE (0). But if it was a global variable in the file that used it, it wasn't initialized correctly. The kernel linked correctly, but the code to initialize either never executed something or else overwrote that variable. We fixed the problem by declaring the variable in usrConfig.c and declaring it "extern" everywhere else. I guess my question is, if you have multiple files/modules with global variables linked into the kernel, how do you make sure that the global variables get initialized correctly? Shouldn't the initializing code be coelesced from all routines to make sure all of the kernel data segment variables are initialized correctly? Puzzled, GWE ||========================================================================== ||George Eger / geger@den.mmc.com || Voice - (303) - 971 - 6974 || ||Fault Tolerant Avionics || Fax - (303) - 977 - 1145 || ||Launch Systems || MS T320 || ||Martin Marietta Astro Group || P.O. Box 179, Denver CO 80201 || ||========================================================================== ||We are at a cusp - between the past when humans were more reliable than || ||computers and the future when computers are more reliable than humans. || ||========================================================================== ||All opinions (however truthful or misinformed) are my own. || ||========================================================================== --------------------------- End of New-News digest ********************** From hill@luke.atdiv.lanl.gov Mon Feb 15 13:04:39 1993 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Mon Feb 15 13:04:47 PST 1993 Subject: Re: Documentation Tool > > I'm looking for a source code documentation tool running under unix, > which can do things like > > extract trees of routine calls > extract the shape of complex data structures > > The tool should be able to handle a system of C source modules and > headers and produce a fomatted well readable output. Please summarize back to the exploder. Thanks. Jeff From andy@sealink1.oe.fau.edu Mon Feb 15 13:38:12 1993 From: andy@sealink1.oe.fau.edu (Mr.Andrew Shein) Date: Mon Feb 15 13:38:21 PST 1993 Subject: Re: comp.os.vxworks newsdigest Hi Is there any way for an ethernet interface in vxWorks to know if it is connected to the network, and if it is not, shutdown the interface? I was hoping to have my system boot off an EEPROM unless the ethernet was connected. If the ethernet was connected then I want the system to boot off the network. I looked in bootConfig and see how the interface is attached but i didn't see how to detach it without rebooting the system Thanks Andy Shein Florida Atlantic University From woody@sparta.com Mon Feb 15 13:57:17 1993 From: woody@sparta.com (Robert "Woody" Woodburn) Date: Mon Feb 15 13:57:28 PST 1993 Subject: i960 board and VIC068 inconsistancies Hi, We're porting the AP Labs device driver for the 4211 FDDI board to the hkv960. The 4211 wants to see the vme address to use for DMA from the host i960. sysLocalToBusAddr puts everything at 0x01000000, since that is the location for LOCAL_MEM_BUS_ADRS. But the CIO_DATA_A_ADRS register for the slave access in extended space is set at 0x40000000. This latter value is consistant with the manual for the hkv960 (HK80/V960E) on page 6-15, which states that the extended address space must start at 0x40000000. Now these two values are inconsistant. If I reset the CIO Port A compare back to 0x01000000, The 4211 board can access the 960's memory just fine, but is this kosher to do? Is there some routine that I should be calling to sync this register with the location of memory? Thanks woody From daemon@vxw.ee.lbl.gov Tue Feb 16 04:00:43 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Feb 16 04:00:53 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Feb 16 04:00:34 PST 1993 Subject: FDDI card and VxWorks BSP evaluation Subject: Re: Serial driver request: SCC 269[12]; 85C30 ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus Subject: FDDI card and VxWorks BSP evaluation Date: Tue, 16 Feb 1993 14:00:00 GMT From: nina@fynu.ucl.ac.be (Alain Ninane - FYNU) Organization: University of Louvain (LLN) - Nuclear Physics Dept. Message-ID: <1993Feb16.140000.6002@info.ucl.ac.be> Followup-To: comp.os.vxworks Sender: news@info.ucl.ac.be (News Administrator) I have received a price offer for the following card: Single attach FDDI board 68030 25 MHz 4 MB DRAM cpu 2 KB NVRAM 1 MB EPROM National Semiconductor FDDI chip set with 83231 CRD, 83241 CDD, 83251 PLAYER,83261 BMAC and BSI chips 1) Does anybody has any experiences with this FDDI controller 2) It seems that there is a VxWorks BSP for the card, does anybody use it ? Thanks, Alain - -- Dr. Alain H. Ninane | Tel : +32-10-47.32.32 - Fax: +32-10-45.21.83 University of Louvain | Internet: Ninane@fynu.ucl.ac.be Nuclear Physics Dept. | Ch. du Cyclotron, 2 B-1348 Louvain-la-Neuve | BELGIUM --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Serial driver request: SCC 269[12]; 85C30 Date: 16 Feb 93 16:59:02 GMT From: davids@nobby.gvg.tek.com (David B. Smith) Organization: Grass Valley Group, Grass Valley, CA Message-ID: <6038@gold.gvg.tek.com> References: <5138@crl.LABS.TEK.COM> Sender: news@gold.gvg.tek.com In article <5138@crl.LABS.TEK.COM> kab@strl.labs.tek.com (Kent Black) writes: >I am requesting drivers or pointers to BSP's for: > Signetics SCC 2691 UART -- unknown if it is with any BSP > Signetics SCC 2692 DUART -- unknown if it is with any BSP > >Also, I know that the Zilog 8530 is common and I believe the 85C30 is >pin compatible (CMOS version): is the 8530 driver sufficient for the >85C30? > >Thanks, >-- kab > >Kent Black > ----------------------------------------------------------------- > STRL, Tektronix Inc. | Email: kab@crl.labs.tek.com > P.O. Box 500, M/S 50-662 | Voice: (503) 627-6280 > Beaverton, OR 97077 | FAX: (503) 627-5502 > ----------------------------------------------------------------- I beleive that the Z8530 Driver that comes with the MVME147 BSP works just fine. I have checked with the schematics for the MVME147S-1 and found that the 147 board uses the Z85c30 serial chip. We successfully used the driver without any drawbacks. Dave Smith PSD, The Grass Valley Group Inc. davids@gold.gvg.tek.com P.O. Box 1114, M/S N3-2B (916) 478-4125 Grass Valley, CA 95945-1114 --------------------------- End of New-News digest ********************** From prb@aplexus.jhuapl.edu Tue Feb 16 12:56:09 1993 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Tue Feb 16 12:56:19 PST 1993 Subject: New Processors with more Power ( SPECmarks) Hi, Current projects that I am working use many many Motorola MC68040 boards. But some of our future projects that are in the pipe require much more power. So we are looking to RISC processors for a solution. I was looking at some SPECmark results that were published in Oct, 1991 in Microprocessor Report (They are probably SPECmark89 results). Although old, it is only now that I am beginning to see real product on the VMEbus with this type of performance. Motorola Motorola Intel HP Mips MC68040 88000 i860XR PA-RISC R4000PC 25MHZ 33MHZ 40MHZ 66MHZ 50/100 ------------------------------------------------------------------------ Integ 12.9 21.4 19.9 51.0 39.7 Float 11.0 15.8 32.4 91.0 46.8 SPEC 11.8 17.8 26.7 72.2 43.8 On another chart, I saw HP 9000 Series 700 Model 710 @50MHZ ----------------------------------- SPECint92 31.6 SPECfp92 47.6 SPECint89 35.4 SPECfp89 62.4 SPECmark89 49.7 Thus, HP's 9000 Series 700rt Model 742rt board looks real good to us. I also saw a publication from Motorola that announced the MV197 with a 50 MHZ 88110. This announcement claimed that the MVME197 achieved more than 70 SPECmark89 in simulated testing. These numbers are way out of line with the earlier SPECmarks shown above. Does anyone know why? Does anyone have SPECmark results for the 88110 on any other VME boards? Thanks, +====================================================================+ | __ ____ __ __ | | /\ \ / \ \ /\_\__ /\ \ Johns Hopkins University | | / \_\ | /\ \ \ / / /\_\\ \ \ Applied Physics Lab. | | / /\ | |\ \/ \ \ / / / / / \ \ \ | | / \/ |_| \ /\ \_\ / / / / / \ \ \ Paul R. Bade | | / /\__/_/ \ \ \/_// / / / / / / / (301)-953-6000 x8681 | | / / / \ \_\ \ \/ / / / / / prb@aplexus.jhuapl.edu | | \/_/ \/_/ \__/_/ \/_/ | | __ ____ __ __ | | /\ \ / \ \ /\ \ /\ \ | | / \_\ | /\ \ \ / \_\ / \ \ | | / /\ | |\ \/ \ \ / /\ |_| / /\ \ \ | | / \/ |_| \ /\ \_\ / / / | | \/ / \ \ | | / /\ / / \ \ \/_// / / / / / /\ \_\ | | \ \/ / / \ \_\ \ \/ / / \/ / / / | | \__/_/ \/_/ \__/_/ /_/_/ | | | +====================================================================+ From ma@tadpole.com Tue Feb 16 14:18:01 1993 From: ma@tadpole.com (Mark Armitage) Date: Tue Feb 16 14:18:10 PST 1993 Subject: Re: New Processors with more Power ( SPECmarks) Hi, > Motorola Motorola Intel HP Mips > MC68040 88000 i860XR PA-RISC R4000PC > 25MHZ 33MHZ 40MHZ 66MHZ 50/100 > ------------------------------------------------------------------------ > Integ 12.9 21.4 19.9 51.0 39.7 > Float 11.0 15.8 32.4 91.0 46.8 > SPEC 11.8 17.8 26.7 72.2 43.8 > > > On another chart, I saw > > HP 9000 Series 700 Model 710 @50MHZ > ----------------------------------- > SPECint92 31.6 > SPECfp92 47.6 > > SPECint89 35.4 > SPECfp89 62.4 > SPECmark89 49.7 > > Thus, HP's 9000 Series 700rt Model 742rt board looks real good to us. > > I also saw a publication from Motorola that announced the MV197 with > a 50 MHZ 88110. > This announcement claimed that the MVME197 achieved more than > 70 SPECmark89 in simulated testing. > > These numbers are way out of line with the earlier SPECmarks shown above. > Does anyone know why? Does anyone have SPECmark results for the 88110 > on any other VME boards? The 88000 SPECmarks that you show above are for the 88100 processor. The 88110 is the next generation of Motorola's RISC. The 70 SPECmark figure is about right. The simulator used is an accurate clock by clock simulator. I have run Dhrystone 2.1 on Tadpole's TP810V (at 40MHz) using Diab Data's 88110 C compiler, and seen 168000 dhrystones/s which equates to 208000 dhrystones at 50MHz. Tadpole (for whom I work) have been shipping a single/dual processor 88110 VME board for several months now which will be able to give you up to 200MIPS / 200MFLOPS peak performance. Mark Armitage Third Party Software Manager, Tadpole Technology, Inc Tel: (512) 219 2200 Email: ma@tadpole.com From murad@mars.dgrc.doc.ca Tue Feb 16 17:49:44 1993 From: murad@mars.dgrc.doc.ca (Murad Mirza) Date: Tue Feb 16 17:49:59 PST 1993 Subject: Notion of Jobs/Tasks & Scheduling Hi VxWorkers, Is Task and Job one and the same thing in VxWorld? or can we say that there are multiple Tasks within a Job (and there are multiple Jobs within an application). I know (?) there are RR and Priority for Vx tasks' scheduling on a single processor, but what about local and global scheduling [where local and global schedulers take care of Jobs (with multiple tasks) in a multiprocessing/parallel system]? Thanks in advance. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Murad Mirza + one of bluecollared VxWorkers' (Presently at) + CRC/Dept. of Communication + Ottawa, Ontario + Ph: (613) 998-2423 + Fax: 990-7987 + @Networks Interoperability Project +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From visicom!VisiCom.COM!trest@nosc.mil Tue Feb 16 17:54:03 1993 From: Mike Trest Date: Tue Feb 16 17:54:20 PST 1993 Subject: Re: New Processors with more Power ( SPECmarks) > Paul R. Bade > > Thus, HP's 9000 Series 700rt Model 742rt board looks real good to us. Looks good to me too. However, my evaluation board is not in house yet so I cannot speak from experience. > This announcement claimed that the MVME197 achieved more than > 70 SPECmark89 in simulated testing. > > These numbers are way out of line with the earlier SPECmarks shown above. Paul, believe the numbers! Even though the figures are projections from the simulator, our experience that the simulation is right on the money. Likewise, ask your Motorola rep for the whole study because there are some very important application profiles which you *must* meet to get this performance. This application profile is not much different that what you expect from anything in the RISC class. I have not been able to get my 88110 board yet from Motorola. VisiCom is supposed to be on the BETA list because we are a large 88k user. However, I do have an early [engineering] Tadpole 88110 dual processor board at 40MHZ. As an early board we have a few things broken but they do not affect our processing. Our Clinton, MD office is doing the testing. It really smokes. We have not attempted SPECmark but if you talk to Tadpole they may be able to produce some SPECmark numbers. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From schadeb@trg.saic.com Tue Feb 16 21:42:13 1993 From: schadeb@trg.saic.com (Bart Schade) Date: Tue Feb 16 21:42:22 PST 1993 register me please From schadeb@netboss1.trg.saic.com Tue Feb 16 22:58:44 1993 From: schadeb@netboss1.trg.saic.com (Bart Schade) Date: Tue Feb 16 22:58:54 PST 1993 I would like to subscribe From daemon@vxw.ee.lbl.gov Wed Feb 17 04:00:44 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Feb 17 04:00:54 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Feb 17 04:00:35 PST 1993 Subject: Relational Database on VxWorks? Subject: Exabyte SCSI tape driver Subject: netif detach (was Re: comp.os.vxworks newsdigest) ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Relational Database on VxWorks? Date: Wed, 17 Feb 1993 11:37:21 GMT From: ebcplh@ebc.ericsson.se (BO/EBC/KX/DH Peter Hoegfeldt 08-682 4915) Organization: Ericsson Business Communications, AB, Sweden Keywords: database, vxworks Message-ID: <1993Feb17.113721.21288@ericsson.se> Reply-To: ebcplh@ebc.ericsson.se Sender: news@ericsson.se We have a telecom application running on VxWorks. For the Operations and Maintenance part we want a data storage function that 1) organizes data in "tables of rows", each row containing a fixed number of fields, where 2) some fields are primary keys (uniqueness), some fields are searchable, and that has 3) matching search, "get next", "get previous". Is there any relational (or relational-like) database running on VxWorks? Regards, Peter Hoegfeldt --------------------------- Newsgroups: comp.os.vxworks Subject: Exabyte SCSI tape driver Date: Wed, 17 Feb 1993 17:35:34 GMT From: schadeb@trg.saic.com (Bart Schade) Organization: SAIC, Technology Research Group, San Diego, CA Message-ID: <10780636@MVB.SAIC.COM> - -- I am looking for this driver for the force1e CPU running 5.0.2b. Has tape I/O been any trouble? Comments and suggestions are appreciated. Also, what is and where can I subscribe to "exploder"? - -- Bart Schade Science Applications International Corporation schadeb@trg.saic.com --------------------------- Newsgroups: comp.os.vxworks Subject: netif detach (was Re: comp.os.vxworks newsdigest) Date: Thu, 18 Feb 1993 05:48:59 GMT From: hjb@netcom.com (Hwa-Jin Bae) Organization: Peaceful Star Project -- Oakland, CA Message-ID: <1993Feb18.054859.9506@netcom.com> References: <9302161716.AA09218@sealink1> In article <9302161716.AA09218@sealink1> andy@sealink1.oe.fau.edu (Mr.Andrew Shein) writes: >Hi > Is there any way for an ethernet interface in vxWorks to know if it is >connected to the network, and if it is not, shutdown the interface? some of the network drivers will logMsg() errors detected from ethernet hardware when carrier is not present (cable is not connected). lance and intel ethernet drivers currently do that. unfortunately, lance driver doesn't keep track of carrier error in separate area (it's incorporated as if_ierror or if_oerror.) the intel driver will keep it in es_tnocar in its softc structure. if you really want to do this you can write your own interrupt handler for the network device interrupts and do a intConnect(). your handler can examine error status coming from the chips upon interrupt, and then call original handler for the netif drivers. (you'll need to talk to wrs to get all the relevant info). > I was hoping to have my system boot off an EEPROM unless the ethernet >was connected. If the ethernet was connected then I want the system to boot >off the network. I looked in bootConfig and see how the interface is attached but i didn't see how to detach it without rebooting the system > there is a companion routine to if_attach(). it is unfortunately mispelled as if_dettach() (extra 't'). :-) sorry about that. - -- Hwa-Jin Bae / Peaceful Star Project / 2899 Ford Street, Oakland CA 94601 hjb@netcom.com, hjb@hybrid.com, hwajin@iphasew.com --------------------------- End of New-News digest ********************** From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com Wed Feb 17 06:19:27 1993 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Wed Feb 17 06:19:41 PST 1993 Subject: Re: Serial driver request: SCC 269[12]; 85C30 In article <5138@crl.LABS.TEK.COM> kab@strl.labs.tek.com (Kent Black) writes: >I am requesting drivers or pointers to BSP's for: > Signetics SCC 2691 UART -- unknown if it is with any BSP > Signetics SCC 2692 DUART -- unknown if it is with any BSP > >Also, I know that the Zilog 8530 is common and I believe the 85C30 is >pin compatible (CMOS version): is the 8530 driver sufficient for the >85C30? > The Z85C30 is quite popular, it's used on many boards supported by WRS BSPs, e.g. HKV960, MV147 and more. As to Signetics UARTs, they are sometimes software compatible with other UARTs. I remember using one which was MC68681 almost compatible except it had four of those on a single chip. Sorry I dont remember the number. Another point that might be interesting, is that the BSP Porting Kit should incude a variety of UART and TIMER driver code in source form. Leonid From daemon@vxw.ee.lbl.gov Thu Feb 18 04:00:50 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Feb 18 04:00:59 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Feb 18 04:00:41 PST 1993 Subject: booting from a floppy drive Subject: Re: Serial driver request: SCC 269[12]; 85C30 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: booting from a floppy drive Date: Thu, 18 Feb 93 14:13:39 GMT From: rajesh@shakti.bellcore.com (Rajesh Khandelwal) Organization: Morristown Research and Engineering Message-ID: <1993Feb18.141339.8428@walter.bellcore.com> Sender: rajesh@shakti (Rajesh Khandelwal) Hi, I had read a few weeks back somebody mentioning about booting from a floppy drive. I enquired with my local vendor, and he says he has never heard of a scsi floppy drive. Could that person send me make and model # of that floppy drive. Thanx, Rajesh --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Serial driver request: SCC 269[12]; 85C30 Date: Thu, 18 Feb 1993 18:25:02 GMT From: chris@wrs.com (Chris Ford) Organization: Wind River Systems, Inc. Message-ID: References: <9302180803.AA00280@RST.HellNet.org> Sender: news@wrs.com (News Manager) leonid@rst.hellnet.org (Leonid Rosenboim) writes: >to Signetics UARTs, they are sometimes software compatible with >other UARTs. I remember using one which was MC68681 almost compatible >except it had four of those on a single chip. That's Signetics SCC2698. >Another point that might be interesting, is that the BSP Porting Kit >should incude a variety of UART and TIMER driver code in source form. The BSP Porting Kit contains a complete BSP for the Motorola MVME147, including source code for the Zilog Z8530 tty driver. - -Chris Ford Engineer Wind River Systems --------------------------- End of New-News digest ********************** From xhd@zfssun1.tz.rus.uni-stuttgart.de Thu Feb 18 09:42:52 1993 From: xhd@zfssun1.tz.rus.uni-stuttgart.de (Nikolaus Hild / ZFS) Date: Thu Feb 18 09:43:27 PST 1993 Subject: Re: New Processors with more Power Is the 88000 architecture supported (support planned, scheduled) by vxWorks? If yes, what targets and hosts? ____________________________________________________________________ | | | Nikolaus Hild | | Centre for Manufacturing Technologies Stuttgart | | Nobelstr. 15 | | 7000 Stuttgart 80 | | Germany | |____________________________________________________________________| | | | Phone: 0711 13162-41 | | Fax: 0711 13162-11 | | Email: xhd@zfssun1.tz.rus.uni-stuttgart.de | |____________________________________________________________________| From xhd@zfssun1.tz.rus.uni-stuttgart.de Thu Feb 18 11:04:13 1993 From: xhd@zfssun1.tz.rus.uni-stuttgart.de (Nikolaus Hild / ZFS) Date: Thu Feb 18 11:04:34 PST 1993 Subject: Performance 68030/68040 Hi, we are running vxWorks (68k40Rel.5.0.2b) on FORCE CPU30 (68030) and CPU40 (68040) targets. Our software performs robotic control. When running benchmarks I found, that the 68040 board isn't any faster than the 68030 board. Until now the GNU Toolkit (GNU68k40Rel.1.37.1) supplied by WRS only supports 68020. I'm not familiar with the Motorola 68020/30/40 architecture but it seems to me that our processors are running in "68020-mode" and additional features like registers or asm-instructions of the 68030/68040 processors are not available for vxWorks users. Any experiences, ideas, solutions ... ? ____________________________________________________________________ | | | Nikolaus Hild | | Centre for Manufacturing Technologies Stuttgart | | Nobelstr. 15 | | 7000 Stuttgart 80 | | Germany | |____________________________________________________________________| | | | Phone: 0711 13162-41 | | Fax: 0711 13162-11 | | Email: xhd@zfssun1.tz.rus.uni-stuttgart.de | |____________________________________________________________________| From dit@bach.jhuapl.edu Thu Feb 18 12:27:58 1993 From: dit@bach.jhuapl.edu (Daryl I. Tewell) Date: Thu Feb 18 12:28:07 PST 1993 Subject: Re: Documentation Tool Regarding: > I'm looking for a source code documentation tool running under unix, > which can do things like > > extract trees of routine calls > extract the shape of complex data structures > > The tool should be able to handle a system of C source modules and > headers and produce a fomatted well readable output. Unix systems I've used have commands called cflow and cxref, which provide calling trees and cross-reference lists, respectively, for C-language source (single or multiple files). They use a syntax similar to that of cc and, so, are most easily used when incorporated into your makefile. Daryl Tewell From shaffer@ada3.ae.ge.com Thu Feb 18 12:56:47 1993 From: shaffer@ada3.ae.ge.com (Phil Shaffer) Date: Thu Feb 18 12:56:57 PST 1993 Subject: FIP boards for VMEbus Does anyone know of any FIP bus (French Fieldbus) boards for VMEbus? Vxworks drivers would be nice, but not essential. (I am aware of two previous articles mentioning PROFIBUS boards. PROFIBUS is the German fieldbus standard.) Thanks. Phillip L. Shaffer shaffer_phillip@ae.ge.com GE Aircraft Engines, MS G57 1 Neumann Way Cincinnati, OH 45215 From dit@bach.jhuapl.edu Thu Feb 18 13:26:05 1993 From: dit@bach.jhuapl.edu (Daryl I. Tewell) Date: Thu Feb 18 13:26:14 PST 1993 Subject: Re: Re: Mysterious task crashes Regarding: > Sounds like you have the clasic "uninitalized pointer" problem that is clobering > your memory. > > Go through all your code and check that all pointers are initalized before use! > It looks like the pointer is writing an instruction to jump to location 0x0006 > where the illegal instruction is generated. ( I beleive this is the vector table?) > > Hope this helps, any body else agree ? I agree that this is a good idea whether you have a problem or not! Let me add, though, that lint programs "Go through all your code" for you, checking for such oversights. Gimpel Software's FlexeLint even flags cases in which (because of the control structure) a variable "MAY not have been initialized." Daryl Tewell P.S. Not to pick on anybody, but misspellings (such as uninitalized vs. uninitialized) sometimes make it difficult to search for key words in the log of very important exploder messages. Folks using vi on UNIX can type ":w !spell" for a list of suspicious words. From mickel@digitailor.se Thu Feb 18 13:30:46 1993 From: mickel@digitailor.se (Mikael Liden) Date: Thu Feb 18 13:30:59 PST 1993 Subject: Re: Performance 68030/68040 Hi, I have had the privilege of testing the forthcoming version 5.1 of VxWorks on a FORCE Cpu-40. V5.1 includes a number of changes that really works miracle for the cpu-40 - essentially improved floating-point support, and the possibility of enabling the data cache. In version 5.0.2 you can't enable data cache on the cpu-40 if you are using the Lance ethernet driver - this was a limitation caused by the implementation of the driver. Exactly how much improvement data cache will mean for you, is of course depending a bit on your application. Some applications will benefit more from data cache than others, but in general I would say it will make a significant change. If you study the BSP for cpu-30 you will notice that it too disables the data cache when you include the Lance driver in the configuration. However, the cpu-30 will not benefit as much as the cpu-40 from data cache, because the data cache is much smaller on the 68030. The implementation of the floating-point support was a bit sluggish in V5.0.2 - causing run-time traps for unimplemented floating-point instructions. This was because the GNU compiler didn't know anything about 68040 floating-point capabilities. V5.1 includes a new release of GNU which knows how to deal with a 68040. If your application uses a lot of floating-point calculations (which I guess a robotic control application does), V5.1 will probably mean a lot of improvement for you. Best regards, Mikael o==================================================================o | Mikael Liden mickel@digitailor.se | o==================================================================o | Digitailor AB phone: +46-8 744 53 00 | | A Microtec Research Company fax: +46-8 645 53 36 | o==================================================================o From fwr8bv@fin.af.mil Thu Feb 18 15:00:50 1993 From: Chatterjee S Date: Thu Feb 18 15:01:03 PST 1993 Subject: Trying to contact.... r) Thanks, Shash. +-----------------------------------------------------------------------------+ + Shash Chatterjee EMAIL: fwr8bv@fin.af.mil + + EC Software PHONE: (817) 763-1495 + + General Dynamics, Ft. Worth Div. FAX: (817) 777-2115 + + P.O. Box 748, MZ1719 + + Ft. Worth, TX 76101 + +-----------------------------------------------------------------------------+ From stan@rti.com Thu Feb 18 16:58:13 1993 From: stan@rti.com (Stan Schneider) Date: Thu Feb 18 16:58:23 PST 1993 Subject: Re: Re: Mysterious task crashes >> Submitted-by dit@bach.jhuapl.edu Thu Feb 18 13:26:05 1993 >> >> Regarding: >> >> > Sounds like you have the clasic "uninitalized pointer" problem that is >> > clobering your memory. Go through all your code and check that all >> > pointers are initalized before use! It looks like the pointer is >> > writing an instruction to jump to location 0x0006 where the illegal >> > instruction is generated. ( I beleive this is the vector table?) >> > >> > Hope this helps, any body else agree ? >> RTI has a memory-integrity test program that will let you know if the cause is clobbered memory. However, a much more common cause of illegal instruction errors in low memory is jumping through a null pointer. That can happen if you pass a NULL to a task-switch hook, etc., instead of a valid routine. One easy way to catch these is to install a trap at address 0. This code is a bit of a hack, but will do the trick for 68k processors: /* * nullPtrTrap - Installs a jmp instruction at 0x00000000 to trap execution * through a NULL pointer. * * Marc Ullman, Stanford University Jan. 22, 1991 */ #include #include "vxWorks.h" #include "logLib.h" #include "taskLib.h" #include "package.h" #define BRA_L 0x60ff public int nullPtrTrapFlag = 0; private void nullPtrTrap(void) { nullPtrTrapFlag++; /* This is to allow us to verify that this code has executed even if we don't see the logMsg */ logMsg("\aAttempt to execute NULL pointer detected\n"); taskSuspend(0); } public int nullPtrTrapInit(void) { *( (unsigned short *) 0x0) = BRA_L; *( (unsigned long *) 0x2) = (unsigned long) (nullPtrTrap - 0x2); return(OK); } >> I agree that this is a good idea whether you have a problem or not! >> Let me add, though, that lint programs "Go through all your code" >> for you, checking for such oversights. Gimpel Software's FlexeLint >> even flags cases in which (because of the control structure) a >> variable "MAY not have been initialized." >> Gcc does this too, if you use the "-Wall" flag. I heartily recommend it. -- 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 markm@trilogic.com Thu Feb 18 20:26:17 1993 From: markm@trilogic.com (Mark W. Miller) Date: Thu Feb 18 20:26:31 PST 1993 Subject: MVME-165 VSB Problems I am trying to use the VSB on a Motorola MVME-165 without much success so far. I have found a couple problems with the BSP, but I still cannot get the interface working. Specifically, I am using the lower half of the memory map in what is called "bounce" mode by Motorola, whereby a transfer is first attempted to the VSB and then "bounces" to the VME if the VSB fails. Whatever I try results in a Bus Error, even though the VME memory is definitely mapped at that address. Monitoring the VME with a bus analyzer confirms that no access is even attempted. Any help would be much appreciated. I'll post a summary when I get it working. Thanks. Mark. ================================================================ Mark W. Miller markm@world.std.com Target Technologies, Inc. Real-Time System Integration, Atkinson, NH Design, and Consulting Services (603)362-4973 ================================================================ From daemon@vxw.ee.lbl.gov Fri Feb 19 04:00:54 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Feb 19 04:01:04 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Feb 19 04:00:45 PST 1993 Subject: Re: Performance 68030/68040 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Performance 68030/68040 Date: Fri, 19 Feb 1993 17:17:55 GMT From: mwette@csi.jpl.nasa.gov (Matt Wette) Organization: Jet Propulsion Laboratory Message-ID: <1993Feb19.171755.16712@csi.jpl.nasa.gov> References: <9302191445.AA28683@zfssun1.tz.rus.uni-stuttgart.de> Sender: usenet@csi.jpl.nasa.gov (Network Noise Transfer Service) In article <9302191445.AA28683@zfssun1.tz.rus.uni-stuttgart.de>, xhd@zfssun1.tz.rus.uni-stuttgart.de (Nikolaus Hild / ZFS) writes: |> Hi, |> |> we are running vxWorks (68k40Rel.5.0.2b) on FORCE CPU30 (68030) and |> CPU40 (68040) targets. Our software performs robotic control. When |> running benchmarks I found, that the 68040 board isn't any faster than |> the 68030 board. |> |> Until now the GNU Toolkit (GNU68k40Rel.1.37.1) supplied by WRS only |> supports 68020. I'm not familiar with the Motorola 68020/30/40 |> architecture but it seems to me that our processors are running in |> "68020-mode" and additional features like registers or asm-instructions |> of the 68030/68040 processors are not available for vxWorks users. |> |> Any experiences, ideas, solutions ... ? You need to 1. build gcc-2.3.3 (get it from your nearest GNU ftp site). 2. build gas-1.93 (get it from ftp.uu.net). 3. put the assembler where the compiler will find it (usually /usr/local/lib/gcc-lib/68k/2.3.3/as). 4. fix the specs file to pass the proper flags to the assembler. Here's a diff if what I did: *** specs-orig Sun Dec 27 18:55:34 1992 - --- specs Sat Feb 6 14:59:07 1993 *************** *** 1,5 **** *asm: ! %{m68000:-mc68010}%{mc68000:-mc68010}%{!mc68000:%{!m68000:-mc68020}} %{fpic:-k} %{fPIC:-k} *asm_final: - --- 1,5 ---- *asm: ! %{m68040:-mc68040}%{m68000:-mc68010}%{mc68000:-mc68010}%{!m68040:%{!mc68000:%{!m68000:-mc68020}}} %{fpic:-k} %{fPIC:-k} *asm_final: Matt Wette - -- mwette@csi.jpl.nasa.gov --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sat Feb 20 04:00:50 1993 From: daemon@vxw.ee.lbl.gov Date: Sat Feb 20 04:01:00 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Feb 20 04:00:42 PST 1993 Subject: booting vxWorks from SCSI floppy ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: booting vxWorks from SCSI floppy Date: 19 Feb 93 14:14:13 GMT From: junel@bilbo.heurikon.com (June Liesch) Organization: Heurikon Corporation, Madison, WI Message-ID: <2124@heurikon.heurikon.com> Reply-To: junel@heurikon.heurikon.com (June Liesch) Sender: news@heurikon.heurikon.com In Article 1173, Rajesh Khandelwal asks what embedded SCSI floppy drive to use to boot vxWorks. At Heurikon, we use a TEAC model 711. June - -------------------------------------------------------------------------------- June Liesch | "I don't think much of our profession, but con- Software Customer Support | trasted with respectability, it's comparatively Heurikon Corporation | honest." - The Pirate King, from G&S's junel@heurikon.com | "The Pirates of Penzance" - -------------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From @advanced-robotics-research-centre.salford.ac.uk,@subnode.arrc.salf.ac.uk:Denis.Riley@advanced-robotics-research-centre.salford.ac.uk Sat Feb 20 12:20:05 1993 From: "Denis.Riley" Date: Sat Feb 20 12:20:18 PST 1993 Subject: Serial Interface (HK80/V960E) Please help, I am new to using vxw but I am now faced with interfacing an RS232 device to the HK80/V960E serial port. I have been trying to use the vxw device drivers (tyCo... etc.) but have had no luck. At this stage all I want to do is open the serial port at 9600 baud, 8 bits, 1 stop bit and No parity and read and write data from and to the RS232 device. Other than the baud rate, I cannot see how I can set the other line parameters (stop bits parity etc) and I don't even know what the default settings for the board are. From visicom!VisiCom.COM!trest@nosc.mil Sat Feb 20 18:20:23 1993 From: Mike Trest Date: Sat Feb 20 18:20:32 PST 1993 Subject: Re: Serial Interface (HK80/V960E) >"Denis.Riley" > ... Other than the baud rate, I cannot see how > I can set the other line parameters (stop bits parity etc) and I don't even > know what the default settings for the board are. The tyCoDrv driver is provided in source format because a VxWorks universal console driver cannot do everything you may need in your application. Driver writers provide the "usual" capabilities expected by Wind River (which are minimal). Therefore, you are expected to change the driver to meet the needs of your application. The usual method is by extending the ioctl() to support your desired operations. If your needs are complex (i.e. special hardware or software flow control or synchronous protocols), you may need driver writer skills. But for simple modifications, get the uart chip manual and go for it! ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From @advanced-robotics-research-centre.salford.ac.uk,@subnode.arrc.salf.ac.uk:Denis.Riley@advanced-robotics-research-centre.salford.ac.uk Sun Feb 21 05:15:45 1993 From: "Denis.Riley" Date: Sun Feb 21 05:15:58 PST 1993 Subject: Serial Interface (HK80/V960E) Please help, I am new to using vxw but I am now faced with interfacing an RS232 device to the HK80/V960E serial port. I have been trying to use the vxw device drivers (tyCo... etc.) but have had no luck. At this stage all I want to do is open the serial port at 9600 baud, 8 bits, 1 stop bit and No parity and read and write data from and to the RS232 device. Other than the baud rate, I cannot see how I can set the other line parameters (stop bits parity etc) and I don't even know what the default settings for the board are. From @advanced-robotics-research-centre.salford.ac.uk,@subnode.arrc.salf.ac.uk:Denis.Riley@advanced-robotics-research-centre.salford.ac.uk Sun Feb 21 05:38:47 1993 From: "Denis.Riley" Date: Sun Feb 21 05:39:01 PST 1993 Subject: Serial Interface (HK80/V960E) Please help, I am new to using vxw but I am now faced with interfacing an RS232 device to the HK80/V960E serial port. I have been trying to use the vxw device drivers (tyCo... etc.) but have had no luck. At this stage all I want to do is open the serial port at 9600 baud, 8 bits, 1 stop bit and No parity and read and write data from and to the RS232 device. Other than the baud rate, I cannot see how I can set the other line parameters (stop bits parity etc) and I don't even know what the default settings for the board are. From mea@sparta.com Sun Feb 21 19:41:17 1993 From: mea@sparta.com (Mike Anderson) Date: Sun Feb 21 19:41:57 PST 1993 Subject: Re: Serial Interface (HK80/V960E) Greetings! > Submitted-by: "Denis.Riley" > > Please help, > > I am new to using vxw but I am now faced with interfacing an RS232 device to the > HK80/V960E serial port. I have been trying to use the vxw device drivers > (tyCo... etc.) but have had no luck. At this stage all I want to do is open the > serial port at 9600 baud, 8 bits, 1 stop bit and No parity and read and write > data from and to the RS232 device. Other than the baud rate, I cannot see how > I can set the other line parameters (stop bits parity etc) and I don't even > know what the default settings for the board are. My settings in the tyCo driver for the HK80/V960E show 8 data bits, no parity (2 stop bits) as the default settings for the RS-232 ports. This is found by looking at the tyCoHrdInit function in the tyCo driver. To get 1 stop bit, simply replace the SCC_WR4_2_STOP option with SCC_WR4_1_STOP. You should contact Zilog for the 85C30 data sheets that will explain the programming of the chip and make appropriate mods to the tyCo driver for your applications. Actually, you should make extensions to the tyCo driver to use ioctls to change these things ;-). When you're writing your application, remember that the tyCo devices have ring buffers associated with them so just because you write data to the device doesn't mean it gets clocked out. You'll need to issue the appropriate flush command or ioctl to get the data to pop out on the other end. Good luck, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From mea@sparta.com Sun Feb 21 19:54:00 1993 From: mea@sparta.com (Mike Anderson) Date: Sun Feb 21 19:54:12 PST 1993 Subject: Re: Notion of Jobs/Tasks & Scheduling Greetings! > > Submitted-by murad@mars.dgrc.doc.ca Tue Feb 16 17:49:44 1993 > > Is Task and Job one and the same thing in VxWorld? or can we say > that there are multiple Tasks within a Job (and there are multiple > Jobs within an application). > > I know (?) there are RR and Priority for Vx tasks' scheduling on a > single processor, but what about local and global scheduling [where > local and global schedulers take care of Jobs (with multiple tasks) > in a multiprocessing/parallel system]? > Since no on else has responded to this one, I thought I'd take a stab. VxWorks deals with tasks, not jobs. If a job is comprised of several tasks, then it is the responsibility of the programmer to provide some means of coordinating the tasks to perform work. There are no mechanisms built into VxWorks to perform global, multi-CPU task scheduling. Such things are why people invented techniques like "time-warp" and the so-called distributed operating systems like CEDAR, EDEN and the V-System. Not that it wouldn't be interesting to do some sort of global scheduler (anybody willing to fund me in some research? ;-), but it just doesn't exist currently. Load balancing algorithms with process migration would be nice for that matter, too. Now that 5.1 is supposed to have an unload feature, at least the load balancing and processing migration begin to become conceivable. In fact, we're looking at approaches for this in a future release of ARTSE(R). Have fun, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From daemon@vxw.ee.lbl.gov Tue Feb 23 04:00:42 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Feb 23 04:00:52 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Feb 23 04:00:33 PST 1993 Subject: i960 GCC2.0 (gcc1.37) generates funky symbols: e.g., sym.file_name ------------------------------------------------------- Newsgroups: comp.os.vxworks,gnu.gcc.help,comp.sys.intel Subject: i960 GCC2.0 (gcc1.37) generates funky symbols: e.g., sym.file_name Date: 23 Feb 93 17:27:27 GMT From: kab@strl.labs.tek.com (Kent Black) Organization: STRL, Tektronix, Inc. Keywords: gcc, 960, vxworks, symbol table Message-ID: <5189@crl.LABS.TEK.COM> Followup-To: kab@strl.labs.tek.com Sender: news@crl.LABS.TEK.COM Gcc for the i960 is creating symbols with '.' and intermediate file name attached. VxWorks massages its own symbol table from the output of gnm960, and breaks on the '.' notation (looks like a struct/union ref). Can't just remove the '.' and trailer because objects still use the whole symbol name which breaks the final symbol table. The example below shows a file-scope static char [] being mangled, but occassionally other symbols get mangled as well, and I haven't looked far enough yet to determine exact conditions. Is there a way to suppress appending filenames to symbols? Please reply as I don't follow all these newsgroups. Thanks, - -- kab An example: <5> cat foo.c static char copyright[] = "hello kent"; /* NOTE WELL */ extern t(); int a,b,c; main() { foo(); } int foo() {} <6> gcc960 -v -ACA -c foo.c gcc version 1.37 /usr/local/gnu9602.0/sun4/lib/cpp.960 -v -undef -D__GNUC__ -Di960 -Di80960 -DI960 -DI80960 -D__i960__ -D__i80960__ -D__I960__ -D__I80960__ -D__CHAR_UNSIGNED__ -nostdinc -I/usr/local/gnu9602.0/sun4/include -D__i960CA__ -D__i960_CA__ foo.c /tmp/cca06727.cpp GNU CPP version 1.37 (intel 80960) compiled by CC. /usr/local/gnu9602.0/sun4/lib/cc1.960 /tmp/cca06727.cpp -mca -msoft-float -mstrict-align -quiet -dumpbase foo.c -bname _tmp_foo -version -o /tmp/cca06727.s GNU C version 1.37 (intel 80960) compiled by CC. default target switches: -mleaf-procedures -mtail-call /usr/local/gnu9602.0/sun4/bin/gas960 -ACA /tmp/cca06727.s -o foo.o <7> gnm960 foo.o 00000004 C _a 00000004 C _b 00000004 C _c 00000020 D _copyright._tmp_foo <<<<< RIGHT HERE 00000010 T _foo 00000000 T _main 00000000 t gcc_compiled. --------------------------- End of New-News digest ********************** From howard%sidney.nosc.mil@nosc.mil Tue Feb 23 12:17:01 1993 From: howard%sidney.nosc.mil@nosc.mil (Mike Howard) Date: Tue Feb 23 12:17:15 PST 1993 Subject: High speed serial synchronous input for vxWorks One of the projects I am currently working on involves the input and recording of several (4 to 5) serial synchronous channels of information, each channel operating at approximately 2.5 megabits per second. Does anyone out there have any suggestions for a candidate I/O board, supported (or supportable) under vxWorks, that will accept multiple high speed serial channels, scan the incoming data stream for a frame sync pattern (32 to 64 bits), establish frame lock and initiate data input when the sync pattern is detected. Candidates currently under consideration include a Berg Systems 4411 decommutator (single channel, high cost) and a Cyclone uSystems SQSIO5 serial I/O module (8 channel, no sync detecton). Also, any info on alternatives to Exabytes as a recording medium would be appriciated. __ __ __ / \/ \/ \ 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@marlin.nosc.mil | ------------------------------------------------------------------ From fwr8bv@fin.af.mil Tue Feb 23 12:28:06 1993 From: Chatterjee S Date: Tue Feb 23 12:28:15 PST 1993 Subject: Symbol table problems with GNU as68k & ld68k We have a multiprocessor 68k/VxWorks system that we program using C and FORTRAN. Since FORTRAN does not "share" global variables with other languages very well, we use the following "trick" to put data-structures in shared-memory: 1) Put variables in one or more common blocks 2) Common blocks cause FORTRAN to declare a global symbol in the symbol table 3) Use assembler directives to force the symbol at an absolute addr. 4) Link the FORTRAN and ASSEMBLER objects together This works with Sun-3 as/GNU ld68k! However, when we use the GNU as68k/GNU ld68k combo, we get two global symbols using the same name!!!! I provide details below. Since we would like to use the GNU tools exclusively (except for FORTRAN), can anybody provide a solution/work-around to this problem? Thanks, Shash (fwr8bv@fin.af.mil) ************************************************** ******** Here's the test FORTRAN program ******** ************************************************** subroutine test integer i !Declare the test variable common /testcomm/i !and put it in a common block. !The compiler should create a global symbol !called _testcomm_ end ******* Here's the symbol table from FORTRAN object (using nm68k) 00000000 T _test_ 00000004 C _testcomm_ ************************************************** ************************************************** ******** Here's the test ASSEMBLER code ******** ************************************************** .globl _testcomm_ _testcomm_ = 0xd7000000 ******** Here's the symbol table from the ASSEMBLER (Sun-3 as) object ******** using the cmd "as -mc68020 -o testasm.o testasm.s" d7000000 A _testcomm_ <== Note the capital A ******** Here's the symbol table from the ASSEMBLER (as68k) object ******** using the cmd "as68k -mc68020 -o testasm.o testasm.s" d7000000 a _testcomm_ <== Note the lower-case a ************************************************** The objects above were linked using ld68k as follows: ld68k -o test -r -d -X -L/home/prog/lang/SC1.0/f68881 \ -L/home/prog/lang/SC1.0 test.o testasm.o \ -lF77wrap -lF77 -lm -llocal_vx -lmissing ************************************************** ******** Here's the symbol table from the linked object (using Sun3 as) ************************************************** 00000000 T _test_ d7000000 A _testcomm_ <===This is what I want 00000000 t test.o VxWorks loads this as 00000020 t testasm.o _testcomm_ 0xd7000000 abs ************************************************** ************************************************** ******** Here's the symbol table from the linked object (using as68k) ************************************************** 00000000 T _test_ d7000000 a _testcomm_ <==== 00000020 B _testcomm_ <====This is the problem 00000000 t test.o VxWorks loads this as 00000020 t testasm.o _testcomm_ 0xnnnnnnnn bss ************************************************** +-----------------------------------------------------------------------------+ + Shash Chatterjee EMAIL: fwr8bv@fin.af.mil + + EC Software PHONE: (817) 763-1495 + + General Dynamics, Ft. Worth Div. FAX: (817) 777-2115 + + P.O. Box 748, MZ1719 + + Ft. Worth, TX 76101 + +-----------------------------------------------------------------------------+ From mea@sparta.com Tue Feb 23 14:51:29 1993 From: mea@sparta.com (Mike Anderson) Date: Tue Feb 23 14:51:51 PST 1993 Subject: Re: Symbol table problems with GNU as68k & ld68k Greetings! > > Submitted-by fwr8bv@fin.af.mil Tue Feb 23 12:28:06 1993 > Submitted-by: Chatterjee S > > > We have a multiprocessor 68k/VxWorks system that we program using > C and FORTRAN. Since FORTRAN does not "share" global variables with > other languages very well, we use the following "trick" to put data-structures > in shared-memory: > > ... deleted for brevity ... I can't really address the common block problem for you, but I can offer up a FORTRAN to C translator that I hacked to support VxWorks. It's based on the public domain AT&T translator with appropriate mods to support VxWorks I/O. I've used it several times to convert FORTRAN to C and then use the gcc compiler to produce VxWorks code. In all of the cases I've ran across so far, it's worked without any further modification of the resulting C code. It's a brute force translation (if you write bad FORTRAN code you'll get bad C code ;-), but it works real quick. I translated 5,000 lines of FORTRAN code to C in about 4 minutes on a SPARC 2. That code then compiled under gcc and ran without modification under VxWorks. Once in C, you don't have to trick the assembler into anything :-). ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From rebibo%cesar@crbca1.sinet.slb.com Wed Feb 24 09:35:59 1993 From: rebibo%cesar@crbca1.sinet.slb.com (NICOLAS REBIBO) Date: Wed Feb 24 09:36:08 PST 1993 Subject: archives of this mailing list Hi, I have had a look at the archives on thor.atd.ucar.edu and it seems out of date: The last archive of the mailing list is dated vxwexplo_9103b. The more recent code contribution is dated Apr92. Is there a new place where I can find theses archives and some kind of FAQ. As I do not receive this mailing list, please email directly to me. Thanks for your help, Nicolas Rebibo Internet: rebibo@crbca1.sinet.slb.com From interf!zeus!brackett@uunet.uu.net Wed Feb 24 09:43:25 1993 From: interf!zeus!brackett@uunet.uu.net (Todd Brackett) Date: Wed Feb 24 09:43:33 PST 1993 Subject: Rockwell T1 chipset Hi Folks, Anybody out there ever work with the Rockwell/Brooktree T1 chip set? We could use a little help..... Thanks, ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From biocca@csg.lbl.gov Wed Feb 24 12:34:57 1993 From: biocca@csg.lbl.gov (Alan K Biocca) Date: Wed Feb 24 12:35:06 PST 1993 Subject: Re: archives of this mailing list try: ftp vxw-ftp.lbl.gov cd pub/vxwexplo there are archives there from 9108 to 9302, and indexes for 91..3. there is currently no FAQ. Alan K Biocca vxWorks Exploder Maintainer ----- Begin Included Message ----- From: rebibo%cesar@crbca1.sinet.slb.com (NICOLAS REBIBO) Subject: archives of this mailing list Content-Length: 424 Hi, I have had a look at the archives on thor.atd.ucar.edu and it seems out of date: The last archive of the mailing list is dated vxwexplo_9103b. The more recent code contribution is dated Apr92. Is there a new place where I can find theses archives and some kind of FAQ. As I do not receive this mailing list, please email directly to me. Thanks for your help, Nicolas Rebibo Internet: rebibo@crbca1.sinet.slb.com ----- End Included Message ----- From daemon@vxw.ee.lbl.gov Thu Feb 25 04:00:46 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Feb 25 04:00:55 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Feb 25 04:00:38 PST 1993 Subject: VxWorks Programming Guide ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks Programming Guide Date: 25 Feb 93 19:07:54 GMT From: syong@railroad.ardfa.calpoly.edu (sHaNe S Yong) Organization: Applied Research and Development, San Luis Obispo CA Message-ID: <1993Feb25.190754.1023@rat.csc.calpoly.edu> Hello, I am trying to find a programming manual for VxWorks (aside from WRS's Programmer's Guide). I need a manual with examples of how to spawn tasks, use sockets and so on. ^^^^^^^^ I have not been able to find a FAQ-posting for this news group. So, apologies if this is a FAQ. Please reply through email if possible. By the way, I have already asked our WRS representative and he was not aware of any such book. Thank you. sHaNe Yong syong@autobahn.ardfa.calpoly.edu ARDFA, Cal Poly State University, San Luis Obispo, CA 93407 Disclaimer: All opinions are my own and do not reflect those of my employer. --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Fri Feb 26 04:00:45 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Feb 26 04:00:55 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Feb 26 04:00:36 PST 1993 Subject: Re: booting from a floppy drive Subject: wanted: sun4/f77 -target sun3 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: booting from a floppy drive Date: 26 Feb 93 19:16:56 GMT From: davids@nobby.gvg.tek.com (David B. Smith) Organization: Grass Valley Group, Grass Valley, CA Message-ID: <6104@gold.gvg.tek.com> References: <1993Feb18.141339.8428@walter.bellcore.com> Sender: news@gold.gvg.tek.com In article <1993Feb18.141339.8428@walter.bellcore.com> rajesh@shakti.bellcore.com (Rajesh Khandelwal) writes: >Hi, > > I had read a few weeks back somebody mentioning about >booting from a floppy drive. I enquired with my local vendor, >and he says he has never heard of a scsi floppy drive. Could >that person send me make and model # of that floppy drive. > >Thanx, >Rajesh One type of SCSI floppy is the TEAC FD-235HS/FD-235JS 3.5" Micro Floppy Disk Drive. I have used this floppy with VxWorks and a Motorola MVME147 VME board. I suggest calling TEAC to get more information on this drive. This floppy drive is really an FDD drive with a SCSI controller attached. It is a little slower than would be expected for a SCSI device but acceptable. I used it for installing new software including VxWorks. From TEAC literature: TEAC America Inc. Data Storage Sales Offices Montebello, CA (213) 726-0303 San Jose, CA (408) 437-9055 Chicago, IL (708) 490-5311 Austin, TX (512) 329-1037 Boston, MA (508) 683-8322 I had to get the TEAC FC-1-01 FDD SCSI Interface Unit Software Specification manual from TEAC to modify the code in usrConfig.c to send the proper mode select command and to build the block structure for the PC-DOS file system. I also needed the SCSI Floppy Disk Drive Integration Application notes from TEAC technical support to be able to interchange disks between VxWorks and a PC-DOS 1.44M floppy. This particular floppy can be configured for 500Kb, 1Mb, 2Mb, or 4Mb modes. The FD-235HS works with media up to 2Mbytes. The FD-235JS works up to 4Mbytes. - -------------------------------------------------------------------- Dave Smith Production Systems Division Senior Engineer The Grass Valley Group Inc. davids@gold.gvg.tek.com P.O. Box 1114, M/S N3-2B (916) 478-4125 Grass Valley, CA 95945-1114 A Tektronix Company - -------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks,comp.lang.fortran Subject: wanted: sun4/f77 -target sun3 Date: Fri, 26 Feb 1993 21:18:25 GMT From: mwette@csi.jpl.nasa.gov (Matt Wette) Organization: Jet Propulsion Laboratory Message-ID: <1993Feb26.211825.5361@csi.jpl.nasa.gov> Sender: usenet@csi.jpl.nasa.gov (Network Noise Transfer Service) We're looking for a fortran cross compiler which runs on a sun4 and generates code for a 68k. Anybody know of such a beast? We know about the possiblities of using f2c+gcc but would rather have a real compiler. Matt - -- mwette@csi.jpl.nasa.gov --------------------------- End of New-News digest ********************** From thor@thor.atd.ucar.edu Sun Feb 28 03:17:32 1993 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Sun Feb 28 03:17:45 PST 1993 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 2091 -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 37126 Jun 12 1992 ansilib01 -rw-r--r-- 1 thor 18913 Jun 12 1992 ansilib02 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 41669 Dec 6 1991 dhrystones01 -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 11561 Nov 1 1991 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 10049 Dec 2 08:45 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 1991 libx11 -> libX11 -rw-r--r-- 1 thor 25077 Oct 9 1990 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 41667 Feb 5 1992 ntpvx01 -rw-r--r-- 1 thor 38524 Feb 5 1992 ntpvx02 -rw-r--r-- 1 thor 41997 Feb 5 1992 ntpvx03 -rw-r--r-- 1 thor 39218 Feb 5 1992 ntpvx04 -rw-r--r-- 1 thor 39625 Feb 5 1992 ntpvx05 -rw-r--r-- 1 thor 28741 Feb 5 1992 ntpvx06 -rw-r--r-- 1 thor 32516 Feb 5 1992 ntpvx07 -rw-r--r-- 1 thor 37119 Feb 5 1992 ntpvx08 -rw-r--r-- 1 thor 41643 Feb 5 1992 ntpvx09 -rw-r--r-- 1 thor 19593 Oct 27 07:47 ping01 -rw-r--r-- 1 thor 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 1991 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 1991 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 41196 Oct 16 09:43 stevie01 -rw-r--r-- 1 thor 35279 Oct 16 09:43 stevie02 -rw-r--r-- 1 thor 35278 Oct 16 09:43 stevie03 -rw-r--r-- 1 thor 35012 Oct 16 09:43 stevie04 -rw-r--r-- 1 thor 34502 Oct 16 09:43 stevie05 -rw-r--r-- 1 thor 37476 Oct 16 09:43 stevie06 -rw-r--r-- 1 thor 30073 Oct 16 09:43 stevie07 -rw-r--r-- 1 thor 31562 Oct 16 09:43 stevie08 -rw-r--r-- 1 thor 37360 Oct 16 09:43 stevie09 -rw-r--r-- 1 thor 20662 Oct 16 09:43 stevie10 -rw-r--r-- 1 thor 25717 Oct 16 09:43 stevie11 -rw-r--r-- 1 thor 28075 Oct 16 09:43 stevie12 -rw-r--r-- 1 thor 31852 Oct 16 09:43 stevie13 -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 8424 Apr 1 1992 syslog.shar -rw-r--r-- 1 thor 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 19912 Aug 27 1992 tp41.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 5608 Dec 2 08:43 veclist01 -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 1991 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 1991 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 1991 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 1991 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 1991 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 1991 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 1991 vwcurses07 -rw-r--r-- 1 thor 4636 Feb 4 1992 vx_cplusplus -rw-r--r-- 1 thor 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor 4702 Jan 16 1992 wdog_class -rw-r--r-- 1 thor 5070 Dec 2 08:45 xxx Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Mar 17 1992 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar drwxr-xr-x 2 thor 512 Feb 11 1990 xdbx From mea@sparta.com Sun Feb 28 09:43:18 1993 From: mea@sparta.com (Mike Anderson) Date: Sun Feb 28 09:43:27 PST 1993 Subject: Re: comp.os.vxworks newsdigest Greetings! > From: mwette@csi.jpl.nasa.gov (Matt Wette) > Organization: Jet Propulsion Laboratory > > We're looking for a fortran cross compiler which runs on a sun4 and > generates code for a 68k. > > Anybody know of such a beast? > The folks at Oasys (617-862-2002) had such a creature that they were putting the finishing touches on around last December. You might contact them. If they have anything, pls inform the net. ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From baumann@proton.llumc.edu Sun Feb 28 20:12:48 1993 From: baumann@proton.llumc.edu (Michael Baumann) Date: Sun Feb 28 20:12:57 PST 1993 Subject: TIRPC/rpcgen.new Has anyone successfully ported TIRPC to VxWorks? We would like to use rpcgen.new. If so please talk to me! Michael Baumann Radiation Research Lab |Internet: baumann@proton.llumc.edu Loma Linda Universtiy Medical Center | UUCP: ...ucrmath!proton!baumann Loma Linda, California. (714)824-4077|