From leonid@rst.hellnet.org Sun Jan 2 06:38:48 1994 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Sun Jan 2 06:38:57 PST 1994 Subject: Re: Where is Leonid Rosenboim? I am still here folks, live and kicking. If e-mail fails for whatever reason, you're welcome to send me a fax. Happy New Year to All ! ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@RST.HellNet.Org From morriss@smtplink.indigo.hellnet.org Mon Jan 3 04:25:36 1994 From: Steve Morris Date: Mon Jan 3 04:25:46 PST 1994 Subject: Re: Where is Leonid Rosenboim? Text item: Text_1 >Has anybody heard from or talked with Leonid Rosenboim? I can no >longer send him Email at his last known address: RST.HellNet.org. Having just spoken to him, I can assure you that he is well and still living at RST@HellNet.org. The only possible cause for concern was a slight garbling of his voice, but I suspect he was eating a sandwich at the time. ---------------------------------------------------------------------- Steve Morris voice: (8)-381055 Software Team Manager (8)-381818 Indigo Graphic Systems Fax: (8)-408091 P.O. Box 150, Rehovot, Israel e-mail: morriss@smtplink.indigo.hellnet.org ---------------------------------------------------------------------- From daemon@vxw.ee.lbl.gov Tue Jan 4 04:01:31 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 4 04:01:39 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 4 04:01:23 PST 1994 Subject: MVME167 MK48T08 TOD ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: MVME167 MK48T08 TOD Date: Mon, 3 Jan 1994 18:23:47 GMT From: steve@aplexus.jhuapl.edu (Steven Kahn) Organization: Johns Hopkins U. Applied Physics Lab Message-ID: Sender: usenet@netnews.jhuapl.edu Does anyone happen to know of interface software for getting/setting the MVME167 MK48T08 Time-of-Day clock? Thanks in advance. - -- ============================================================================= Steven Kahn, room 6-103 Steven_Kahn@jhuapl.edu Johns Hopkins University Applied Physics Lab Laurel, MD 20723-6099 +1 301 953 6812 ============================================================================= --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Wed Jan 5 04:01:28 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 5 04:01:36 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 5 04:01:19 PST 1994 Subject: Fast Ethernet-FDDI? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Fast Ethernet-FDDI? Date: Tue, 4 Jan 1994 18:45:48 GMT From: davew@rsgi02.rhic.bnl.gov (David Whitehouse) Organization: Brookhaven National Laboratory Keywords: ethernet,fddi,atm Message-ID: <1994Jan4.184548.26933@bnlux1.bnl.gov> Sender: news@bnlux1.bnl.gov (Usenet news) Hi, I am currently invlvolved in a costing exercise for a VxWorks based system scheduled to be operational in 1998. I am interested in projections, guesses etc. relating high speed networking between about 12 VME crates and 12 workstations. The system analysis and design hasn't proceeded to the point where we have a realistic model of the network traffic patterns but the general characteristics are 1) It isn't a realtime problem 2) There will be both point to point broadcast traffic. 3) A rough calculation suggests that about 100Mbits/sec is sufficient for the highest bandwidth part of the system. 4) TCP/IP must be supported. Questions: 1) how much does a VME based FDDI interface cost today? 2) Are there any plans to support one of the fast ethernet or ATM protocols? If so how much will the interfaces cost in 1997-1998? Thanks, David Whitehouse --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Wed Jan 5 07:09:57 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Wed Jan 5 07:10:07 PST 1994 Subject: Re: Fast Ethernet-FDDI? (long) Greetings! > > From: davew@rsgi02.rhic.bnl.gov (David Whitehouse) > < Text deleted to save bandwidth...> > 1) It isn't a realtime problem > 2) There will be both point to point broadcast traffic. > 3) A rough calculation suggests that about 100Mbits/sec is sufficient > for the highest bandwidth part of the system. > 4) TCP/IP must be supported. > > Questions: > > 1) how much does a VME based FDDI interface cost today? > 2) Are there any plans to support one of the fast ethernet > or ATM protocols? If so how much will the interfaces cost > in 1997-1998? > A few things to take note of: 1) Using TCP/IP, a 100 MBit/s pipe can be choked back to as little as 16-24 MBits/sec. 2) You can get fairly *close* to 100 MBits/s (i.e., full bandwidth) if you bypass the TCP stack completely. 3) UDP can support broadcast, but multicasting is still not a distributed part of the protocol stack. Also, you'd be surprised about just how many UDP packets get dropped on LANs. There are several protocols such as IP Multicast and XTP(?) that do support multicast, but you have to hack them in yourself. Besides, in a non-broadcast sort of media such as FDDI or ATM, you'll have to take propagation times into account. (Is multicast what you meant when you said "point to point broadcast traffic"?) 4) Here at SPARTA, we're just finishing modifications to our Interphase 5211 FDDI driver to support VME64 block mode transfers. No performance numbers yet (I'm waiting on a second 5211 to do the tests), but the bus analyzer shows a 5x improvement in transfer times over standard VME32 non-block transfers. FDDI using VME32 transfers and a 68040 (33 MHz), you can get only about a 50-200% improvement over Ethernet speeds, but you do get some level of determinism (The speed variability stems from the sophistication of the '040 manufacturer's bus interface). UltraNet is faster, but not a "standard" with other companies producing boards for it. 5) We sell the 5211 DAS-Fiber for about $5,100 (retail $5,795). The driver is $200 per target. You can get cheaper by going to single attached stations (SAS), but then you'll need a concentrator. Copper versions are not that much less expensive due to lower production volumes. 6) ATM is coming soon. In spite of the lack of firm standards, the ATM community is pushing hard to get products out the door. The current ATM data rates are in the 155 MBits/sec range. We will be working on the VxWorks driver for the Interphase ATM board as soon as we get a couple of boards from Interphase. The costs for ATM will probably start in the $5-8K range per interface (I'm just guessing here 'cause we don't have firm pricing from Interphase yet) and fall off rapidly by 1997-1998 to just a couple hundred bucks range as quantities ramp up, and R&D costs are amortized (just as Ethernet did in the '80s). 7) (Engaging crystal ball ...) Fast-Ethernet looks like it could be a non-player in the long run. ATM is moving fast with a lot of support behind it. Fast-Ethernet will enjoy a brief period of use because it will initially be cheaper than ATM, but I feel that Fast-Ethernet will eventually suffer the same fate as IBM's Token Ring. There will be a few users, but nothing representing a "mass" market. (Initiating crystall ball shutdown ;-). Hope this helps, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From robert@orincon.com Wed Jan 5 11:59:49 1994 From: robert@orincon.com (Robert Redfield) Date: Wed Jan 5 11:59:58 PST 1994 Subject: FDDI VME Can anybody recommend vendors for VME FDDI boards? Thanks, Rob Redfield robert@orincon.com From daemon@vxw.ee.lbl.gov Thu Jan 6 04:01:29 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 6 04:01:37 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 6 04:01:21 PST 1994 Subject: Booting from CDROM ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Booting from CDROM Date: Wed, 5 Jan 1994 15:02:05 GMT From: NSEMICH@relay.nswc.navy.mil (Neal Semich) Organization: NSWCDD, Dahlgren, VA 22448 Message-ID: Sender: news@relay.nswc.navy.mil (newserver) I thought I posted this before Christmas and I left for a week and I did not see it. So I am sorry if this is a repost. I have a VME-based system that has three Motorola 68040 processors. Currently we boot the processors via Ethernet (files are located on a BriteLite). This is only for the development cycle. We have looked at delivering the program using flash memory or removable hard drives. These are not feasible methods for delivering the program. It looks like the best method is from CDROM. If it is of any use, I am developing this using VADSWorks and the version of of VxWorks is 5.0.3. My questions are : 1) Has anyone ever done this? 2) Should the CDROM be DOS formated (we read that VxWorks likes SCSI devices that way) ? 3) What do I need to do for the boot parameters on the boards? Thanks, Neal Neal Semich nsemich@relay.nswc.navy.mil ; My opinion and only my opinion!!!! --------------------------- End of New-News digest ********************** From morriss@smtplink.indigo.hellnet.org Thu Jan 6 06:23:29 1994 From: Steve Morris Date: Thu Jan 6 06:23:47 PST 1994 Subject: transparent translation registers Text item: Text_1 I am using gcc version cygnus-2.2.3 from VxWorks 5.1, cross-compiling to 68030 and 68040 boards. I need to use the transparent translation registers directly. For the 68040 boards I have no problems setting DTT0 and DTT1. /* read/write enable, cache disable $40000000-$77ffffff */ #define DTT0_VALUE 0x403fc060 asm( "movec %0,dtt0" : : "r" (DTT0_VALUE) ) ; However the equivalent instruction for the 68030 registers TT0 and TT1 does not seem to assemble. /* read/write enable, cache disable $40000000-$77ffffff */ #define TT0_VALUE 0x403f8507 asm( "movem %0,tt0" : : "r" (TT0_VALUE) ) ; This results in "operands mismatch" Can anyone help me? Steve Morris ---------------------------------------------------------------------- Steve Morris voice: (972)-8-381055 Software Team Manager (972)-8-381818 Indigo Graphic Systems Fax: (972)-8-408091 P.O. Box 150, Rehovot, Israel e-mail: morriss@smtplink.indigo.hellnet.org ---------------------------------------------------------------------- From clegg@tesla.elen.ssd.fsi.com Thu Jan 6 13:01:25 1994 From: ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg) Date: Thu Jan 6 13:01:37 PST 1994 Has anybody attempted to read, write and format MS-DOS (3.3-5.0) compatible 1.4Meg 3.5" disks using VxWorks? More specifically, has anyone ever mounted a MVME884K scsi drive to a MVME167 and successfully formatted a 1.4Meg disk and then read and written files on it using both VxWorks and MS-DOS? I am currently attempting to read MS-DOS (5.0) compatible 1.4Meg 3.5" floppy disks using VxWorks (for Motorola MVME167) version 5.0.2-68040 beta-1 with a scsi disk drive (MVME884K). I have been able to "successfully" mount the disk and read and write data to it, but it seems to ignore the blksPerTrack parameter I hand it in scsiBlkDevInit() and assume that it is writing to a 1.2Meg 5.25" floppy instead (i.e. 15 blksPerTrack). This, coincidently is the exact setup used for the example in usrConfig.c. I have carefully checked the disk via Norton Utilities on my PC and have discovered that every every 15 sectors it skips 3 sectors. Below is a copy of the source I am using to create the "/fd0/" device to access the disk. NOTE: You will be able to read and write to the disk from VxWorks, but no where else. Thanks in advance, R. Clegg FSI-SSD "The best safety device in any plane is a well trained pilot" int initFloppy() { char modeData [4]; /* array for floppy MODE SELECT data */ /* configure floppy at busId = 3, LUN = 1 */ if ((pSpd31 = scsiPhysDevCreate (pSysScsiCtrl, 3, 0, 0, NONE, 0, 0, 0)) == (SCSI_PHYS_DEV *) NULL) { printErr ("usrScsiConfig: scsiPhysDevCreate failed for Floppy.\n"); return (ERROR); } /* Zero modeData array, then set byte 1 to "medium code" (0x1b). NOTE: * MODE SELECT data is highly device-specific. If your device requires * configuration via MODE SELECT, please consult the device's Programmer's * Reference for the relevant data format. */ bzero (modeData, sizeof (modeData)); modeData [1] = 0x1b; /* issue the MODE SELECT command to correctly configure floppy controller */ scsiModeSelect (pSpd31, 1, 0, modeData, sizeof (modeData)); /* delete and re-create the SCSI_PHYS_DEV so that INQUIRY will return the * new device parameters, i.e., correct number of blocks */ scsiPhysDevDelete (pSpd31); if ((pSpd31 = scsiPhysDevCreate (pSysScsiCtrl, 3, 0, 0, NONE, 0, 0, 0)) == (SCSI_PHYS_DEV *) NULL) { printErr ("usrScsiConfig: scsiPhysDevCreate failed for Floppy(2)\n"); return (ERROR); } if ( (pSbdFloppy = scsiBlkDevCreate (pSpd31, 0, 0)) == NULL) { printErr ("usrScsiConfig: scsiBlkDevCreate failed.\n"); return (ERROR); } /* Fill in the (blocks (or sectors) per track) and * (number of heads) BLK_DEV fields, since it is impossible to ascertain * this information from the SCSI adapter card. This is important for * PC compatibility, primarily. */ scsiBlkDevInit ((SCSI_BLK_DEV *)pSbdFloppy, 18, 2); /* Initialize as a dosFs device */ if (dosFsDevInit ("/fd0/", pSbdFloppy, NULL) == NULL) { printErr ("usrScsiConfig: dosFsDevInit failed.\n"); return (ERROR); } } From briggs@saturnv.jpl.nasa.gov Thu Jan 6 15:29:41 1994 From: briggs@saturnv.jpl.nasa.gov (Clark Briggs #3-1019) Date: Thu Jan 6 15:29:50 PST 1994 Subject: request for info on porting to ibm I have two questions to pose to the realm seeking info to help us decide what to do. 1)has VxWorks been ported to any IBM RS6000 (or derivative, eg. PowerPc 60X or 40X or RSC) as a real-time target. The question is not can the RS6000 workstation be used as a development host. I need VxWorks running on a CPU board built with the RSC single chip implementation. Given a negative answer to #1 which is my expectation, 2) Which companies would be likely candidates to accomplish such a port in the near future quickly and without messing up? Please email responses to me directly at briggs@saturnv.jpl.nasa.gov not to the exploder (that is dont compose your response to the sender automatically since you are presumably reading this in the exploder). If there is enough interest I will post a summary to the exploder or respond directly to requests for a summary. Thanks in advance for your help clark briggs briggs@saturnv.jpl.nasa.gov From daemon@vxw.ee.lbl.gov Fri Jan 7 04:08:24 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 7 04:12:00 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 7 04:01:44 PST 1994 Subject: write() transfer count wrong, but errno not set Subject: Realtime and SBus Questions ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: write() transfer count wrong, but errno not set Date: Thu, 6 Jan 1994 19:08:42 GMT From: georg@sgl.ists.ca (Georg Feil) Organization: Institute for Space and Terrestrial Science Keywords: errno write Message-ID: Sender: news@newshub.ists.ca I am encountering a problem writing files where the write() call returns a value less than the desired write count (sometimes even 0), yet the errno variable is not set. This is on VxWorks 5.1.1 writing to a dosFs file system on a SCSI disk which is nowhere near full. My questions: - -Does this indicate a VxWorks bug, or is it normal? - -Under what circumstances might this happen? It may be that the file system I am writing to is somehow corrupted, as the problem does not appear on another file system. Also each write is preceded by a seek, and in some cases the seek goes past the current end of file. Still, I think VxWorks should report as an error anything which prevents the write from completing. Is there something similar to fsck that I can use to check the consistency of a VxWorks DOS file system? I haven't heard of anything. Thanks, Georg. - -- Space Geodynamics Laboratory | Internet: georg@sgl.ists.ca Institute for Space and Terrestrial Science | Phone: (416) 665-5458 4850 Keele St./North York/Ont/Canada/M3J 3K1 | Fax: (416) 665-1815 --------------------------- Newsgroups: comp.os.vxworks Subject: Realtime and SBus Questions Date: Thu, 6 Jan 1994 23:13:27 GMT From: dog@xdev.sunspot.noao.edu (Fritz Stauffer) Organization: Computer, Hardware and Observatory Support Message-ID: <1994Jan6.231327.9595@noao.edu> Sender: news@noao.edu I am interested in using a SBC with both VME and SBus. Does anyone have any recommendations? Also, I am looking for pointers to list of SBus card manufacturers. thanks, fritz stauffer sac peak obs. sunspot, nm --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Fri Jan 7 06:48:21 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Jan 7 06:48:30 PST 1994 Subject: RE: Floppy Disk Drive Greetings! > From root@vxw.ee.lbl.gov Thu Jan 6 16:19:14 1994 > To: vxworks_users@vxw.ee.lbl.gov > Content-Length: 3463 > X-Lines: 93 > > Submitted-by clegg@tesla.elen.ssd.fsi.com Thu Jan 6 13:01:25 1994 > Submitted-by: ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg) > > Has anybody attempted to read, write and format MS-DOS (3.3-5.0) compatible > 1.4Meg 3.5" disks using VxWorks? More specifically, has anyone ever > mounted a MVME884K scsi drive to a MVME167 and successfully formatted a > 1.4Meg disk and then read and written files on it using both VxWorks and > MS-DOS? > Is the MVME884K actually a Teac FD-235HF floppy drive? If so, then your mode select is woefully inadequate. That floppy requires the full page one mode select (about 32+ bytes of data sent to page one rather than page zero) information in order to be able to format the 3.5" floppy and function as a proper MSDOG drive. I have code that demonstrates this and can send it to you if you'd like. Hope this helps, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mea@mclean.sparta.com Fri Jan 7 10:03:22 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Jan 7 10:03:30 PST 1994 Subject: Synchronous on 68302 Greetings! Does anyone in netland have a snippet of code that puts a Mot 68302 serial port into any of the synchronous modes of operation that they'd be willing to share? Any help would be greatly appreciated, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From bgeer@beorn.sim.es.com Fri Jan 7 12:01:20 1994 From: bob geer Date: Fri Jan 7 12:01:32 PST 1994 Subject: VxMemProbe on VW5.1 on MVME147 I unexpectedly got the rush job of upgrading from 5.0.2 to 5.1 on our MVME147 boards. Most everything works for me except vxMemProbe() -- it always returns ERROR when trying to access ram across the VME bus. The same hardware works everytime for 5.0.2; also, if I vxMemProbe() (using 5.1) the memory on the 147, OK is the status returned. If there's any trick I need to know here that any of you have already overcome I'd appreciate hearing about it. For the record, my current situation is this: We (the co.) now gets a single copy of upgrades instead of our dept. getting its own, & while I managed to get my hands on the 5.1 installation tape, I've never seen the 5.1 documents (manuals, release notes, whatever) & the guy that's *supposed* to have them isn't available. The guy who did our dept's 5.0.2 config isn't available, either. I've compared our 5.0.2 & 5.1 various config files & haven't identified any obvious inconsistencies. I've cruised the VW man pages for both 5.0.2 & 5.1. I did change READ & WRITE to VX_READ & VX_WRITE. I've cruised the .h files. My applications compile without warning messages. I've tried 3 different 147 boards & VME crates -- all work fine with 5.0.2, Bob From baumann@proton.llumc.edu Fri Jan 7 13:28:06 1994 From: baumann@proton.llumc.edu (Michael Baumann) Date: Fri Jan 7 13:28:14 PST 1994 Subject: Re: VxMemProbe on VW5.1 on MVME147 > >I unexpectedly got the rush job of upgrading from 5.0.2 to 5.1 on our >MVME147 boards. Most everything works for me except vxMemProbe() -- >it always returns ERROR when trying to access ram across the VME bus. >The same hardware works everytime for 5.0.2; also, if I vxMemProbe() >(using 5.1) the memory on the 147, OK is the status returned. > >If there's any trick I need to know here that any of you have already >overcome I'd appreciate hearing about it. > Sure, you need to configure some addresses out there on the bus. Although not well documented (like, not at all even :-( ) they use the MMU even if you don't purchase the VxVMI interface. There is a table in usrConfig.c that you need to update to get to the VME. If you don't configure it, is shows as a bus error. Michael Baumann Electus Technology Inc. / Loma Linda University Medical Center San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu From bgeer@beorn.sim.es.com Fri Jan 7 14:55:12 1994 From: bob geer Date: Fri Jan 7 14:55:32 PST 1994 Subject: Re: VxMemProbe on VW5.1 on MVME147 Thanks to Peregrine & Tim I figger'd out I should eliminate the INCLUDE_MMU_BASIC & now things work as they did with 5.0.2. Now to figure out how to utilize the MMU capability to our best advantage; in particular, we have a lot of boards whose DRAM is addressed from 0x40000000 thru 0xe8000000 & maybe beyond (not sure if 0xe8000000 is the low or hi end of the new board's address space). Now, to track down the 5.1 docs... Oh, yeah, & thanks to Mr. Rosenboim for his 5.1 upgrade write-up. I do love this 'net! Bob From rh@spacenet.lanl.gov Fri Jan 7 16:28:57 1994 From: rh@spacenet.lanl.gov (Rick Hodson) Date: Fri Jan 7 16:29:05 PST 1994 Subject: Re: VxMemProbe on VW5.1 on MVME147 Ok....it will take about 20 mins. From accom!tbm%accom@uunet.uu.net Fri Jan 7 17:27:09 1994 From: accom!tbm%accom@uunet.uu.net (Tom McCurdie) Date: Fri Jan 7 17:27:20 PST 1994 Subject: RPC communications with Macintosh Hello. I was wondering if anybody out there has successfully communicated with a vxWorks server from a Macintosh via RPCs. I have located one organization (Netwise) which provides their own proprietary flavor of RPCs for the Mac platform but it is not ONC compliant, and therefore would require porting some of their libraries onto our target which I would rather not do. It also requires you to run their own protocol compiler which they assure me is superior to but in no way compatible with rpcgen. So my questions are: 1) Is there a ONC compliant RPC implementation which does not require any modifications on the vxWorks target? and, failing that: 2) Has anybody successfully used the Netwise implementation to communicate to a vxWorks target? Thank you. Tom McCurdie Accom Inc. From rh@spacenet.lanl.gov Fri Jan 7 17:51:59 1994 From: rh@spacenet.lanl.gov (Rick Hodson) Date: Fri Jan 7 17:52:07 PST 1994 Subject: Re: VxMemProbe on VW5.1 on MVME147 Apologies for last irrelative mail message...please send comment to bit bucket. Rick Hodson From daemon@vxw.ee.lbl.gov Sat Jan 8 04:01:33 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 8 04:01:44 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 8 04:01:23 PST 1994 Subject: "production" release of TCL 7.0 for VxWorks available Subject: comp.os.vxworks FAQ? Subject: Re: write() transfer count wrong, but errno not set Subject: Re: Fast Ethernet-FDDI? (long) ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: "production" release of TCL 7.0 for VxWorks available Date: 7 Jan 1994 22:10:40 GMT From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Message-ID: <2gkml0$bvh@ncar.ucar.edu> I've made a few fixes to my previous beta release, and am now announcing a "production" release of TCL7.0 for VxWorks. I've been using this port for 3 months, and it is quite stable. Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz 1) What is it? TCL is a library that lets you embed an interpeter in your application. 2) What good is it? Why would I want to have a "real-time" interpreter? If you've ever been frustrated that the VxWorks shell is not re-entrant, and has no control flow (e.g. if then else, switch, case ), then you will find TCL very useful since it is a very complete language, that allows you to add your own application specific commands to the interpreter. I find it invaluable for system testing, since I register TCL commands for all major functionality of my real-time application. This allows me to test most pieces of my data acquisition system from a command line, and build nice flexible scripts to test and operate my system. As a matter of fact, I can even invoke specific methods of C++ classes via TCL. Also, you can control your real-time system from a Unix workstation by sending TCL commands from either a TCL or Tk/TCL application (via tclTCP). I find that sending TCL commands (which are just strings) is much easier and more flexible than writing a Remote Procedure Call (RPC) for each piece of functionality that I need to remotely invoke. 3) How big is it? On the 68K architecture: % size libTcl7.0.o text data bss dec hex 104272 5880 980 111132 1b21c Certainly not tiny, but once you've used it, you'll never give it up! 4) Where do I find out more? Get the TCL Frequently Asked Questions list from harbor.ecn.purdue.edu:~pub/tcl/docs/tcl-faq.part0[1-5] Get the draft of TCL's author's book. harbor.ecn.purdue.edu:~pub/tcl/sprite-mirror/book.p[1-4].ps.Z Send me mail, if you have more questions. - -- Joe VanAndel Internet: vanandel@ncar.ucar.edu National Center for Web http://www.atd.ucar.edu/jva/home.html Atmospheric Research --------------------------- Newsgroups: comp.os.vxworks Subject: comp.os.vxworks FAQ? Date: Fri, 7 Jan 1994 23:01:35 GMT From: borchew@storage.tandem.com (Howard Borchew) Organization: Tandem Computers Inc. Keywords: FAQ Message-ID: Followup-To: borchew@storage.tandem.com Sender: news@tandem.com I'm looking for an FAQ for comp.os.vxworks. Is there one? Can I get it off an ftp server? Can someone mail me a copy? Thanks, - -hjb- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ,__o ,__o "Only from the alliance of the one, working | | -\_<,_-\_<, with and through the other, are great things | | (*)/' -- /'(*) born." - Antoine de Saint-Exupery | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | Howard Borchew | PHONE: (408)285-9919 | | borchew@storage.tandem.com | FAX: (408)285-9924 | | Development Engineer | US MAIL: | | Storage & Printer Systems | Tandem Computers Inc. | | Tandem Computers Inc. | 10555 Ridgeview Court, LOC 100-03 | | | Cupertino, CA 95014-0789 | | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Sat, 8 Jan 1994 08:57:27 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Keywords: errno write Message-ID: References: In article georg@sgl.ists.ca (Georg Feil) writes: > >I am encountering a problem writing files where the write() call returns >a value less than the desired write count (sometimes even 0), yet the errno >variable is not set. This is on VxWorks 5.1.1 writing to a dosFs file system >on a SCSI disk which is nowhere near full. > >My questions: > >-Does this indicate a VxWorks bug, or is it normal? my $.02... normal as documented in vxworks man page. if retval != count, it is considered error. this does not map precisely to unix paradigm, nor is this vx-documented in sufficient detail for different types of devices, or devices in different modes -- e.g. blocking vs. non-blocking. unix will return error (-1) when a write() to file is not completely satisfied, unless it is marked non-blocking i/o and/or the 'file' in question is one of: pipe, socket, stream, etc. vxworks does not always do the same. in case of msdog and rt11 or other filesystem devices, vxworks will return actual number of bytes it was able to write, and set no error code. there is no policy-making layer on top of device drivers which arbitrates the error condition to make io layer interface to callers consistent; io system calls are indirected to lower level device routines, whose return values are then simply forwarded back to the user, who is supposed to figure out what the retval means per given device. a write() to vxworks socket, for example, works more similar to unix counterparts. in any case, given an 'error condition', would one like to know why write() produces such error condition? i would say yes. so the lack of such info would constitute a bug, imho. >-Under what circumstances might this happen? kent long knows more than anyone on this one. prolly some corrupt FAT entries... >It may be that the file system I am writing to is somehow corrupted, as the >problem does not appear on another file system. Also each write is preceded >by a seek, and in some cases the seek goes past the current end of file. >Still, I think VxWorks should report as an error anything which prevents the >write from completing. agreed, but if your filesystem is broken, msdog filesys in vxworks will not know how to fix or make sense of it. >Is there something similar to fsck that I can use to check the consistency >of a VxWorks DOS file system? I haven't heard of anything. i think people use norton utilities under msdog. that is, move the disk to a pc, connect it to its controller and run norton on the disk. fix up the disk, move it back to vxworks target. - -- Hwa-Jin Bae Internet: hjb@netcom.com UUCP(slow!): ...!bdt!peacefulstar!hjb PEACEFUL STAR Consultants, Oakland, CA Vox:510.536.7607 Fax:510.536.5889 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Fast Ethernet-FDDI? (long) Date: Sat, 8 Jan 1994 10:05:48 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <9401051510.AA08254@helios> some additions to mike's excellent article... disregard at will ;-) In article <9401051510.AA08254@helios> mea@mclean.sparta.com (Mike Anderson) writes: >1) Using TCP/IP, a 100 MBit/s pipe can be choked back to as little as 16-24 > MBits/sec. > true, but not always... vernon schryver will prolly tell you more about fddi/ip/tcp performance in sgi systems. near-full bandwidth utilization over tcp/ip/fddi is available elsewhere. >2) You can get fairly *close* to 100 MBits/s (i.e., full bandwidth) if you > bypass the TCP stack completely. > the key to performance bottleneck is not mainly due to tcp stack, although the tcp stack in vxworks does need some tuning. driver/mbuf/ip interface is what needs to be optimized; above all, avoiding copying and using the right size buffers will solve a lot of problems. as is, vxworks network code needs work in this area, especially w.r.t fddi type of medium where mtu is larger than 2k. the fault lies more in the realm of the driver, not tcp/ip stack. and perhaps the socket interface needs some tuning too. >3) UDP can support broadcast, but multicasting is still not a distributed > part of the protocol stack. Also, you'd be surprised about just how > many UDP packets get dropped on LANs. There are several protocols > such as IP Multicast and XTP(?) that do support multicast, but you > have to hack them in yourself. Besides, in a non-broadcast sort of > media such as FDDI or ATM, you'll have to take propagation times > into account. (Is multicast what you meant when you said "point to > point broadcast traffic"?) > udp doesn't care broadcast vs. multicast. if your ip implements deering's ip multicasting, you simply sendto() the multicast address. and if vxworks network code were avaialble in source code format, you could just apply diffs to original bsd code to produce multicast ip capable vxworks network. xtp is essentially an academic issue; nobody uses it, and as beautiful as it is, i think we can all agree it's dead. ;-) talk to bob crispin for xtp on vxworks if you really want. i have no idea how you would support broadcast/multicast in atm. ;-) >4) Here at SPARTA, we're just finishing modifications to our Interphase > 5211 FDDI driver to support VME64 block mode transfers. No performance > numbers yet (I'm waiting on a second 5211 to do the tests), but the > bus analyzer shows a 5x improvement in transfer times over standard > VME32 non-block transfers. FDDI using VME32 transfers and a 68040 > (33 MHz), you can get only about a 50-200% improvement over Ethernet > speeds, but you do get some level of determinism (The speed variability > stems from the sophistication of the '040 manufacturer's bus interface). > UltraNet is faster, but not a "standard" with other companies producing > boards for it. peregrine II is a great board, but unless you perform surgery to fix problems in vxworks network code, especially in mbufs, tcp, driver interface, sockets and write the driver to avoid unnecssary copying, you will not be seeing the 'true' potential of the board. an easy test is: if you add faster cpu and the performance goes up linearly, by noticeably large increments, you have excessive data copying and/or cksum speed problem. > >5) We sell the 5211 DAS-Fiber for about $5,100 (retail $5,795). The > driver is $200 per target. You can get cheaper by going to single > attached stations (SAS), but then you'll need a concentrator. Copper > versions are not that much less expensive due to lower production volumes. > alternatively, if you are not tied to vme, try one of the sbus or eisa fddi cards. you can pick up a cddi card for around 1k. and prices will be dropping more soon. >6) ATM is coming soon. In spite of the lack of firm standards, the ATM > community is pushing hard to get products out the door. The current > ATM data rates are in the 155 MBits/sec range. We will be working on > the VxWorks driver for the Interphase ATM board as soon as we get a > couple of boards from Interphase. The costs for ATM will probably > start in the $5-8K range per interface (I'm just guessing here > 'cause we don't have firm pricing from Interphase yet) and fall off > rapidly by 1997-1998 to just a couple hundred bucks range as quantities > ramp up, and R&D costs are amortized (just as Ethernet did in the '80s). > [trivia...] there is at least one other company that is currently doing atm h.w. system using vxworks as native o.s to drive atm gear. >7) (Engaging crystal ball ...) Fast-Ethernet looks like it could be a > non-player in the long run. ATM is moving fast with a lot of support > behind it. Fast-Ethernet will enjoy a brief period of use because > it will initially be cheaper than ATM, but I feel that Fast-Ethernet > will eventually suffer the same fate as IBM's Token Ring. There will > be a few users, but nothing representing a "mass" market. (Initiating > crystall ball shutdown ;-). > fast ethernet, as i understand it, is not really that faster, in terms of burst bandwidth. it's in a kind of different league all together i think. am i wrong? (i know, of course! ;-) - -- Hwa-Jin Bae Internet: hjb@netcom.com UUCP(slow!): ...!bdt!peacefulstar!hjb PEACEFUL STAR Consultants, Oakland, CA Vox:510.536.7607 Fax:510.536.5889 --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Jan 9 04:01:22 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Jan 9 04:01:30 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jan 9 04:01:13 PST 1994 Subject: Is there a VxWorks Conference ??? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Is there a VxWorks Conference ??? Date: Sun, 9 Jan 1994 00:39:19 GMT From: scoob@bnr.ca (Christian Marcotte) Organization: Bell-Northern Research (Canada) Message-ID: <1994Jan9.003919.22391@bnr.ca> Sender: news@bnr.ca (usenet) I recall hearing something about a user group or some conference about VxWorks. Where can I find more info about it? Can users present papers about their work? Thanks, - -- Scoob - -- - --------------------------------------------------------------------------- Christian Marcotte Bell-Northern Research scoob@bnr.ca 3500 Carling Ave Telephone: (613) 763-2782 Nepean, Ont., Canada K1Y 4H7 --------------------------- End of New-News digest ********************** From vaughnf@ccmsmtp.stpaul.ncr.com Mon Jan 10 08:02:54 1994 From: "Frank Vaughn" Date: Mon Jan 10 08:03:03 PST 1994 Subject: port of vxWorks to multiple custom boards Greetings; I have previously written a BSP for an i960 target. There was only one board, so no file problems/strategies were encountered/needed. I must now port vxWorks to several different boards(custom, non-VME) w/ different processors and very little software in common. I am hoping someone out there has dealt w/ something similiar, and can offer some advice. Question 1: In this case, is it reasonable to maintain the WRS philosophy of creating one target directory for each board under a common /config directory? I don't believe that config/all/usrConfig.c(or the other files in /config/all) will be similiar at all for the different targets. I've toyed w/ the idea of a completely different directory structure(shadowed from /usr/vw) for each target. This could eliminate problems which could perhaps arise if one target needed a different release or update of some/all of the vxWorks files. Is it realistic to maintain one /usr/vw directory tree to support different CPUs? As stated before, my biggest nightmare is the case where one target would require an update that is present in a later release, so a new set of files would perhaps be needed for one target but not for others. Question 2: When doing a BSP for a custom board, do most people continue to use the MakeSkel/mpp technique? or throw this stuff out and build a fixed Makefile. I can see advantages to both methods. Question 3: What do you do about the frequent releases of GNU tools, etc? Do you just stay w/ what you have until you have time to do a "sanity check" to see that they work? I would appreciate any advice that can be given. Thanks; Frank (frank.vaughn@stpaul.ncr.com) From andy@oe.fau.edu Mon Jan 10 11:49:44 1994 From: "Mr.Andrew Shein" Date: Mon Jan 10 11:49:52 PST 1994 Subject: PPP for vxWorks Hi I remember someone saying they had done a port of PPP for vxWorks. If anyone has, could someone post some info on where to get it if it's public. Thanks Andy Shein andy@transquest.oe.fau.edu From daemon@vxw.ee.lbl.gov Tue Jan 11 04:01:23 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 11 04:01:34 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 11 04:01:13 PST 1994 Subject: C++ style Subject: Re: write() transfer count wrong, but errno not set Subject: Re: write() transfer count wrong, but errno not set Subject: Re: write() transfer count wrong, but errno not set Subject: Re: write() transfer count wrong, but errno not set Subject: Re: PPP for vxWorks Subject: Re: write() transfer count wrong, but errno not set ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: C++ style Date: Mon, 10 Jan 1994 14:34:17 GMT From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff) Organization: Brookhaven National Laboratory, Upton, NY 11973 Keywords: C++ style Message-ID: <1994Jan10.143417.23480@bnlux1.bnl.gov> Sender: hoff@bnlux1.bnl.gov (Lawrence T. Hoff) I'm not currently a user of WRS' C++ product(s). Still, I'm a little curious about the "programming style" of C++ code developed at WRS. I am impressed by the level of detail in WRS' style guide for C code, and by the fact that WRS makes that style guide "public". Has anyone seen C++ code from WRS, or an updated style guide which includes C++? Does WRS just extend the C style guide to cover C++? If so, are C++ classes treated like other user-defined types (all capital letters)? Do they have special treatment? What extensions are used for C++ "header" and/or "source" modules? Inquiring minds want to know. - -- _ @_ _@_ _ @_ _@_ _ @_ _@_ _ @_ _@_ / / / \ \ \ / / / \ \ \ / / / \ \ \ / / / \ \ \ >> << >> << >> << >> << \\ // \\ // \\ // \\ // --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Mon, 10 Jan 1994 17:29:39 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems Keywords: errno write Message-ID: References: Reply-To: james@wrs.com Sender: news@wrs.com (News Manager) hjb@netcom.com (squeedy) writes: >In article georg@sgl.ists.ca (Georg Feil) writes: >>-Does this indicate a VxWorks bug, or is it normal? >normal as documented in vxworks man page. Nope, it's a bug. The SPR # is 2739. (It doesn't appear in the currently published bug list as it wasn't reported until Dec 20th, after the 5.1.1 known problems list was printed.) Write() no longer will return fewer bytes than requested, as specified by posix. - -- James Moore /|\ james@wrs.com Wind River Systems \|/ Alameda, California "Half of what he said meant something else, and the other half didn't mean anything at all" --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Tue, 11 Jan 1994 04:23:15 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Keywords: errno write Message-ID: References: In article james@wrs.com writes: >hjb@netcom.com (squeedy) writes: > >>In article georg@sgl.ists.ca (Georg Feil) writes: >>>-Does this indicate a VxWorks bug, or is it normal? > >>normal as documented in vxworks man page. > >Nope, it's a bug. The SPR # is 2739. (It doesn't appear in the >currently published bug list as it wasn't reported until Dec 20th, >after the 5.1.1 known problems list was printed.) Write() no longer >will return fewer bytes than requested, as specified by posix. > >-- >James Moore /|\ james@wrs.com >Wind River Systems \|/ Alameda, California go read the whole article again. you've quoted me out of context. i said it is "normal as documented in vxworks man page" for write() call; i also said that i consider it a bug, no matter what vxworks or vxman seems to think how write() should work. in other words, vxworks and vxman are wrong, and it's a bug, but it still is "normal" as per vxman page (which is wrong w.r.t other write() implementations). while you're at it go check out the io system in general, and find other "bugs". regards, hwajin Hwa-Jin Bae Internet: hjb@netcom.com UUCP(slow!): ...!bdt!peacefulstar!hjb PEACEFUL STAR Consultants, Oakland, CA Vox:510.536.7607 Fax:510.536.5889 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Tue, 11 Jan 1994 05:44:21 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems Keywords: errno write Message-ID: References: Reply-To: james@wrs.com Sender: news@wrs.com (News Manager) hjb@netcom.com (squeedy) writes: >i consider it a bug, no matter what vxworks or vxman seems >to think how write() should work. in other words, vxworks and vxman >are wrong, and it's a bug, but it still is "normal" as per vxman page >(which is wrong w.r.t other write() implementations). When in doubt, RTFM: (most of the rest of the write() man page deleted> RETURNS The number of bytes written (if not equal to , an error has occurred), or ERROR if the file descriptor does not exist or the driver returns ERROR. Seems pretty clear that VxWorks is following standard practice (in this case, a POSIX standard). - -- James Moore /|\ james@wrs.com Wind River Systems \|/ Alameda, California "Half of what he said meant something else, and the other half didn't mean anything at all" --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Tue, 11 Jan 1994 07:49:16 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Keywords: errno write Message-ID: References: In article james@wrs.com writes: >hjb@netcom.com (squeedy) writes: > >>i consider it a bug, no matter what vxworks or vxman seems >>to think how write() should work. in other words, vxworks and vxman >>are wrong, and it's a bug, but it still is "normal" as per vxman page >>(which is wrong w.r.t other write() implementations). > >When in doubt, RTFM: > >(most of the rest of the write() man page deleted> >RETURNS > The number of bytes written (if not equal to , an > error has occurred), or ERROR if the file descriptor does > not exist or the driver returns ERROR. > >Seems pretty clear that VxWorks is following standard practice (in >this case, a POSIX standard). > >-- >James Moore /|\ james@wrs.com >Wind River Systems \|/ Alameda, California > "Half of what he said meant something else, and the other half > didn't mean anything at all" wrong again. you still do not understand. the vxworks write() is wrong and the man page is also wrong. the normal traditional unix write() will return the number of bytes actually written when the write was *successful*. a successful write() varies from one object to another. a successful write() to socket or any other object that is subject to flow control can return number less than requested, at which time the user must retry to send more data. a succesful write() to non-blocking file i/o must either complete successfully with all bytes requested written to the file, or return error (-1) indicating the errno. vxworks does not do this to a normal synch i/o file write(), which was the point of this whole discussion. not only does vxworks write() man page describe none of the object specific behaviors and error cases, the implementation of write() is also incompatible. Hwa-Jin Bae Internet: hjb@netcom.com UUCP(slow!): ...!bdt!peacefulstar!hjb PEACEFUL STAR Consultants, Oakland, CA Vox:510.536.7607 Fax:510.536.5889 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: PPP for vxWorks Date: Tue, 11 Jan 1994 08:00:37 GMT From: dab@netcom.com (Don Brooks) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <199401101946.AA29802@oe.fau.edu> Mr.Andrew Shein (andy@oe.fau.edu) wrote: : Hi : I remember someone saying they had done a port of PPP for : vxWorks. If anyone has, could someone post some info on where to get : it if it's public. : Thanks : Andy Shein : andy@transquest.oe.fau.edu Its available from netcom.com via anonymous ftp. Once there, cd to pub/peacefulstar/dab. The file is pppd-1.3.tar.gz. Don Brooks dab@netcom.com Peaceful Star Consultants 510-536-7607 (office) 510-536-5889 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Tue, 11 Jan 1994 08:21:56 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Keywords: errno write Message-ID: References: In article hjb@netcom.com (squeedy) writes: >varies from one object to another. a successful write() to socket >or any other object that is subject to flow control can return >number less than requested, at which time the user must retry >to send more data. i should add, *if* the object is marked non-blocking >a succesful write() to non-blocking file i/o ^^^^^^^^^^^ i meant normal/blocking -- just thinking one thing and typing another... >must either complete successfully with all bytes requested written >to the file, or return error (-1) indicating the errno. >vxworks does not do this to a normal synch i/o file write(), >which was the point of this whole discussion. Hwa-Jin Bae Internet: hjb@netcom.com UUCP(slow!): ...!bdt!peacefulstar!hjb PEACEFUL STAR Consultants, Oakland, CA Vox:510.536.7607 Fax:510.536.5889 --------------------------- End of New-News digest ********************** From rdmacko@somnet.sandia.gov Tue Jan 11 06:58:11 1994 From: RD Mackoy Date: Tue Jan 11 06:58:20 PST 1994 Subject: VxWorks, VXI, SCRAMNet I am looking for any one who has used the above combination of HW and SW. I would be insterested in even just the VxWorks and SCRAMNet. RD Mackoy rdmacko@somnet.sandia.gov Sandia National Labs 505-844-1911 PO Box 5800 MS 365 505-844-4797 Albuquerque, NM 87185 From visicom!VisiCom.COM!trest@lbl.gov Tue Jan 11 09:14:37 1994 From: Mike Trest Date: Tue Jan 11 09:14:46 PST 1994 Subject: Re: port of vxWorks to multiple custom boards FrankVaughn asks: > Question 1: In this case, is it reasonable to maintain the WRS > philosophy of creating one target directory for each board under a > common /config directory? I don't believe that > config/all/usrConfig.c(or the other files in /config/all) will be > similiar at all for the different targets. I've toyed w/ the idea of > a completely different directory structure(shadowed from /usr/vw) for > each target. This could eliminate problems which could perhaps arise > if one target needed a different release or update of some/all of the > vxWorks files. Is it realistic to maintain one /usr/vw directory tree > to support different CPUs? As stated before, my biggest nightmare is > the case where one target would require an update that is present in a > later release, so a new set of files would perhaps be needed for one > target but not for others. We have followed the WRS approach for a long time and it works. The only real pain is the thought of placing hardware specific stuff in ../all/bootConfig.c ../all/usrConfig.c in the early versions of VxWorks. This has been reorganized in 5.1. This addresses the different CPUs. However our collective problem remains when WRS changes their structure between OS releases. > > Question 2: When doing a BSP for a custom board, do most people > continue to use the MakeSkel/mpp technique? or throw this stuff out > and build a fixed Makefile. I can see advantages to both methods. > I do whenever the BSP is going to be sold to others. I note that other engineers do not use MakeSkel when the BSP is for single-customer or internal use. > Question 3: What do you do about the frequent releases of GNU tools, > etc? Do you just stay w/ what you have until you have time to do a > "sanity check" to see that they work? I started using GNU long before WRS started distributing them. I now use the WRS distributed versions. VisiCom Laboratories has been a BETA site for many of the new releases and products from WRS. We have, therefore, been able to do the sanity check before using the stuff for production work. VisiCom has about 200 employees where 100 (or more) are activly writing VxWorks/pSOS/Lynx/Ada real time kernels, drivers, and applications. We have probably written a hundred BSPs for VME, propritary OEM boards, and other custom [military] hardware platforms. We have found that it is better to stick with the vendor distributed patterns of things (unless they are broken). Sticking with the pattern makes for easier training of new engineers and easier transition to end-user customers. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 VisiCom Laboratories Fax: 619 457 0888 10052 Mesa Ridge Court San Diego, CA 92121 ==================================================== From halecm@cod.nosc.mil Tue Jan 11 09:17:28 1994 From: halecm@cod.nosc.mil (Curtis M. Hale) Date: Tue Jan 11 09:17:37 PST 1994 Subject: g++ question good day, my name is Curtis Hale, halecm@cod.nosc.mil. I work for Naval Research and Development Lab in San Diego, (619) 553-6147. We are running vxWorks applications and are interested in obtaining a C++ compiler for vxWorks development. Pursuing this venture, I am exploring the use of the GNU g++ compiler. I had problems building the cross-compiler from the latest version, 2.5.7, obtained from MIT's GNU area. The configure command doesn't know about m68k-wrs-vxworks as a target platform, which is not surprising. I did get the compiler to build using the GCC Develop Toolkit's source distributed by Wind River. It DID know about configure m68k-wrs-vxworks as a target platform, which perhaps implies that someone at WRS hacked on it a little. Anyway, I seem to have the cross compiler built, v2.2.3 of gnu stuff (there is an executable built anyway), and am wondering about the location of compatible g++ libraries and header files (istream.h,ostream.h, etc...). I got the libg++-2.5.3 from MIT but I believe that is not compatible with the older v2.2.3 compiler I have built. Actually, I am more curious about whether this is a valid approach - is anybody else using the GNU g++ cross compiler or is using WRS Centerline C++ product the better approach. If anybody has information - good,bad,other - on using the GNU g++ compiler on vxWorks applications I would be interested in learning the version you're using, where you got it, could I get it, etc. If anybody has information on Wind River's Centerline C++ product I would appreciate that, too. Thank you, curt hale From technet!gmg%barney.macom.com@uunet.uu.net Tue Jan 11 15:30:31 1994 From: technet!gmg%barney.macom.com@uunet.uu.net (Gary M. Greenberg) Date: Tue Jan 11 15:30:40 PST 1994 Subject: Subscription To . . . Please add me to your exploder subscription database. I was refered to it by TriLogic Inc. Thanks! 2 G gmg@macom.com From john@csd.nad.northrop.com Tue Jan 11 17:11:27 1994 From: John Sicklick Date: Tue Jan 11 17:11:35 PST 1994 Subject: Re: Subscription To . . . Send subscription requests & comments to vxwexplo-request@lbl.gov From morriss@smtplink.indigo.co.il Wed Jan 12 01:29:28 1994 From: Steve Morris Date: Wed Jan 12 01:29:58 PST 1994 Subject: Re[2]: transparent translation registers Text item: Text_1 > I am using gcc version cygnus-2.2.3 from VxWorks 5.1, cross-compiling to > 68030 and 68040 boards. > > I need to use the transparent translation registers directly. > For the 68040 boards I have no problems setting DTT0 and DTT1. > > : > > However the equivalent instruction for the 68030 registers TT0 and TT1 > does not seem to assemble. > Thanks for the useful suggestions from several people. I managed to use TT0 & TT1 in the end. I was asked why I want to use the DTT/TT registers. One reason to use the transparent translation registers directly is that you can "cache disable" large areas without generating correspondingly large MMU translation tables (the 4 areas of 128 MBytes each that I need to cover require either ~300 KBytes of MMU table or a single DTT/TT register) and there is no translation time overhead. The disadvantage is that there are only two DTT/TT registers and they have limited usage. The top 8 bits, the Logical Address Base, are compared with address bits A31-A24 (i.e. multiples of 16 Mbyte). Addresses that match are transparently translated. The next 8 bits, the Logical Address Mask, contain a mask for the Logical Address Base, set bits cause the corresponding bit in the Logical Address Base field to be ignored. Other bits set the access modes, cache mode, etc., and are different for the 68030 and the 68040. You must be careful that the areas covered do not clash with those defined by the MMU tables. For future referance, this is what you do :- /**************************/ /* for 68030 (e.g. mv147) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_tt () { register int *pVal; int ttVal; pVal = &ttVal; ttVal = TT0_VALUE; asm ("pmove %0,tt0" : : "g" (*pVal)); ttVal = TT1_VALUE; asm ("pmove %0,tt1" : : "g" (*pVal)); } /**************************/ /* for 68040 (e.g. mv167) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_dtt () { asm ("movec %0,dtt0" : : "r" (DTT0_VALUE)); asm ("movec %0,dtt1" : : "r" (DTT1_VALUE)); } From daemon@vxw.ee.lbl.gov Wed Jan 12 04:01:37 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 12 04:01:47 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 12 04:01:26 PST 1994 Subject: Problem with cache Subject: Problems with cache Subject: Problem with cache Subject: Re: write() transfer count wrong, but errno not set Subject: Re: write() transfer count wrong, but errno not set Subject: Re: g++ question Subject: Re: "production" release of TCL 7.0 for VxWorks available ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Problem with cache Date: Wed, 12 Jan 1994 02:18:02 GMT From: sterrett@manta.nosc.mil (Anthony E. Sterrett) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Jan12.021802.18732@nosc.mil> Sender: news@nosc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Problems with cache Date: Wed, 12 Jan 1994 02:27:39 GMT From: sterrett@manta.nosc.mil (Anthony E. Sterrett) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Jan12.022739.18805@nosc.mil> Sender: news@nosc.mil Hi all, We're working with VxWorks 5.1.1 sparc host and a mv167 target. We're writing some low level driver these drivers require atomic writes to memory so we have to disable the cache using to write to the correct place in vme memory. A better solution would be to set aside a area of vme memory that would be non-cachable or to flush the cache. Now I know about the cacheFlush command exist however it doesn't seems to have the correct effect. Any ideas? - ------------------------------------------------------------------ Tony"The Tiger" Sterrett NRaD This is my opinion and only mine Reply to:sterrett@nosc.mil Jaya SriSri RadhaKrishna! Nkosi sikelel'iAfrika - --Red Wings,Pistons Rule, Tigers Rule, Lions Rule!----------------- From: sterrett@manta.nosc.mil (Anthony E. Sterrett) Newsgroups: comp.os.vxworks Subject: Problem with cache Summary: Followup-To: Distribution: world Organization: NCCOSC RDT&E Division, San Diego, CA Keywords: --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Wed, 12 Jan 1994 03:37:12 GMT From: kent@wrs.com (Kent Long) Organization: Wind River Systems, Inc. Keywords: errno write Message-ID: References: Sender: news@wrs.com (News Manager) In article hjb@netcom.com (squeedy) writes: > >a succesful write() to [normal, non-blocking] file i/o >must either complete successfully with all bytes requested written >to the file, or return error (-1) indicating the errno. > >vxworks does not do this to a normal synch i/o file write(), >which was the point of this whole discussion. The specific case that started this discussion involved seeking beyond the end of a dosFs file and then writing data. That write() returned prematurely (i.e. before were written), which is a bug. This is apparently due to a problem in the on-the-fly allocation which occurs in this situation, with the result being that the write() only extends to the next disk cluster boundary. This will be fixed. Normally, writes to local files do follow the unix/posix convention and do in fact write the specified number of bytes. Note that this was not always the case in earlier versions of VxWorks, which tended to write a "convenient" amount and expect the user to make a second (third, ...) call to write(). Repeat after me: it's a bug, it's a bug, it's a bug, it's a bug..... - kent Kent Long Wind River Systems kent@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: 12 Jan 1994 04:23:15 GMT From: squeedy@dhokkaebi.wpd.sgi.com (hwajin bae-contractor) Organization: Silicon Graphics, Inc., Mountain View, CA Keywords: errno write Message-ID: <2gvtvj$eem@fido.asd.sgi.com> References: In article , Kent Long wrote: > >Normally, writes to local files do follow the unix/posix convention >and do in fact write the specified number of bytes. Note that this >was not always the case in earlier versions of VxWorks, which tended >to write a "convenient" amount and expect the user to make a second >(third, ...) call to write(). > hmmm...which version of vxworks are you talking about? the ones i have seen all do not work correctly. are you talking about a released version? what is the last version of vxworks that had the wrong/buggy write()? 5.1? is there something newer? > >Repeat after me: it's a bug, it's a bug, it's a bug, it's a bug..... hey, no problem repeating... everybody now... hwajin - speaking for myself only... --------------------------- Newsgroups: comp.os.vxworks Subject: Re: g++ question Date: Tue, 11 Jan 1994 22:22:50 GMT From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff) Organization: Brookhaven National Laboratory, Upton, NY 11973 Message-ID: <1994Jan11.222250.25218@bnlux1.bnl.gov> References: <9401111713.AA10361@cod.nosc.mil> In article <9401111713.AA10361@cod.nosc.mil> halecm@cod.nosc.mil (Curtis M. Hale) writes: > >good day, > >my name is Curtis Hale, halecm@cod.nosc.mil. I work for Naval Research >and Development Lab in San Diego, (619) 553-6147. We are >running vxWorks applications and are interested in obtaining >a C++ compiler for vxWorks development. From my notes : You need to make a file called "cc1plus" (I assume this is the C++ compiler's "first phase"). This file should be copied to '$(GCC_EXEC_PREFIX)/m68k-wrs-vxworks/cygnus-2.2.3', or whatever directory WRS puts the C compiler's "cc1" in. Goto the gcc directory, and configure and make the whole compiler, but only move cc1plus : ../configure --target=m68k-sun-sunos3 --host=sparc-sun-sunos4.1.1 One little kludge..... Comment out the SIZE_T #define in tm.h VxWorks likes size_t to be an "unsigned int", not an "int", To make libio.a (and libstdio++.a and libg++.a), go to the libg++ directory and make them using the newly created cross compiler : make 'CXX=cc68k -I$(VXWORKS)/h' Move libio.a (and libstdio++.a and libg++.a) into same directory as cc1plus (so that the "-l" flag works). Make sure that the C (or C++) runtime libraries don't do foolish things like defining a UNIX-style exit(), or make sure that they don't define exit() at all. >If anybody has information on Wind River's Centerline C++ product >I would appreciate that, too. > Me too. I cobbled the GNU stuff together before this product was available. I'd like to hear real-life experiences. - -- _ @_ _@_ _ @_ _@_ _ @_ _@_ _ @_ _@_ / / / \ \ \ / / / \ \ \ / / / \ \ \ / / / \ \ \ >> << >> << >> << >> << \\ // \\ // \\ // \\ // --------------------------- Newsgroups: comp.os.vxworks Subject: Re: "production" release of TCL 7.0 for VxWorks available Date: 11 Jan 94 19:39:09 GMT From: brown@ftms.UUCP (Vidiot) Organization: Vidiot's Other Hangout Message-ID: <1112@ftms.UUCP> References: <2gkml0$bvh@ncar.ucar.edu> Reply-To: brown@ftms.UUCP (Vidiot) In article <2gkml0$bvh@ncar.ucar.edu> vanandel@rsf.atd.ucar.edu (Joe Van Andel) writes: ld < printReal.o value = 0 = 0x0 -> d 0x20000000, 16 20000000: 0000 0000 0000 0010 0000 0000 ffff fffe *................* 20000010: 4473 c000 40d7 ae14 3c17 e6a3 410d d32f *Ds..@...<...A../* value = 21 = 0x15 -> printReal 0x20000000 Real @ 0x20000000 = 0.000000 value = 29 = 0x1d -> printReal 0x20000010 Real @ 0x20000010 = 975.000000 value = 31 = 0x1f -> m 0x20000000 20000000: 0000-ffff 20000002: 0000-ffff 20000004: 0000-. value = 1 = 0x1 -> printReal 0x20000000 Real @ 0x20000000 = The system hangs at this point, and control-X will reboot it. Is this a known behavior/bug? Shouldn't NaN (not a number) or something informative be printed? Thanks Phillip L. Shaffer shaffer_phillip@ae.ge.com From sblachma@aoc.nrao.edu Wed Jan 12 16:53:55 1994 From: Steve Blachman Date: Wed Jan 12 16:54:04 PST 1994 Subject: Re: System hang printing 0xffffffff as float This is a known bug which is fixed in 5.1. From daemon@vxw.ee.lbl.gov Thu Jan 13 04:01:40 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 13 04:01:52 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 13 04:01:31 PST 1994 Subject: Themis 10HS? Subject: VME Memory Map on a Motorola mvme162 Subject: Re: Problems with cache Subject: pSOS+ to VxWorks porting Subject: Request: Company names that sell VME enclosures Subject: HDLC for VxWorks Subject: Re: write() transfer count wrong, but errno not set Subject: SCSI Disk Drive ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Themis 10HS? Date: Wed, 12 Jan 1994 15:12:03 GMT From: br@cs.cmu.edu (Bill Ross) Organization: CMU Vision and Autonomous Systems Center Message-ID: Reply-To: br@cs.cmu.edu Sender: br@ykm.ius.cs.cmu.edu (Bill Ross) Is anyone running on a Themis 10HS Sparc board? I'd love to ask you some questions... Maybe I could answer some of yours. Send me mail Bill br@cs.cmu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: VME Memory Map on a Motorola mvme162 Date: 12 Jan 1994 16:48:44 GMT From: schuweil@forge.fnal.gov (greg schuweiler) Organization: FERMILAB, Batavia, IL Keywords: VME Message-ID: <2h19lc$q23@fnnews.fnal.gov> I have a question on what controls the memory map with vxWorks/mvme162. The mvme162 has the VMEchip2 located at 0xFFF40000 - 0xFFF400FF (both LCSR and GCSR registers), with the first master register located at 0xFFF40014, (the following is a printing of a range of the VMEchip2 registers and their content: Vme Register Content FFF40000 023f0200 FFF40004 00ff00c0 FFF40008 0000ffc0 FFF4000C 0000ffc0 FFF40010 03df03ef FFF40014 efff0040 FFF40018 00000000 FFF4001C 00000000 FFF40020 00000000 FFF40024 00000000 FFF40028 00000009 FFF4002C c201ad00 FFF40030 00000700 FFF40034 00000000 FFF40038 00000000 FFF4003C 00000000 FFF40040 00000000 FFF40044 00000000 FFF40048 000f0100 According to my figuring I should be able to get off board via the VME backplane starting at 0x400000 and ending at 0xEFFF0000. The slave we are using has its full memory mapped to this setup. Booting the master board via Motorola buggy instead of vxWorks shows that writing to the above range does indeed send the data to the slave. Booting the board via vxWorks and then writing to anywhere in the above range gives a bus error. This happens with the m and d vxWorks commands along with the software I have written. During the vxWorks installation is there something I missed? I have crusied through the various .h and .c files trying to decipher the vme support, but alas I had no luck. ========================================================================= Greg Schuweiler The standard disclaimer applies schuweil@forge.fnal.gov to all I may have said, may say, (708) 840-2665 and/or may do. It does not reflect, the feelings of my employer. Heck, if it did, we would lose our funding. Like a rock, I stand against the wind ========================================================================= --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Problems with cache Date: Wed, 12 Jan 1994 17:16:31 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: Bell-Northern Research, Ottawa, Canada Message-ID: <1994Jan12.171631.27728@nrtpa038.bnr.ca> References: <1994Jan12.022739.18805@nosc.mil> Sender: billag@b4pphff (Bill Gutknecht) In article <1994Jan12.022739.18805@nosc.mil>, sterrett@manta.nosc.mil (Anthony E. Sterrett) writes: |> |> Hi all, |> We're working with VxWorks 5.1.1 sparc host |> and a mv167 target. We're writing some low |> level driver these drivers require atomic |> writes to memory so we have to disable |> the cache using |> to write to the correct place in vme memory. |> |> A better solution would be to set aside a area |> of vme memory that would be non-cachable or to |> flush the cache. Now I know about the cacheFlush |> command exist however it doesn't seems to have |> the correct effect. |> |> Any ideas? |> Would cacheDmaMalloc() work? It supposedly creates a pointer to a "cache-safe" buffer. - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will Bell Northern Research ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: pSOS+ to VxWorks porting Date: Wed, 12 Jan 1994 19:25:05 GMT From: choi@cod.nosc.mil (Sojin Q. Choi) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Jan12.192505.3384@nosc.mil> Sender: news@nosc.mil I have VME-based systems and each system is consist of a MVME167 board, a Interphase 4211 FDDI card, and other VME cards. Application softwares have been developed on pSOS+, but now I am in rush to port VxWorks for these systems(changing softwares based on pSOS+ to VxWorks 5.1.1.) I am hoping someone has done this and offer some advice. My questions are: 1) Anyone has done it? 2) Anyone has the VxWorks source code for Interphase 4211 Perigrine driver? 3) How VxWorks different from pSOS+?? I would appreciate any advice. Thanks, choi@cod.nosc.mil --------------------------- Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks Subject: Request: Company names that sell VME enclosures Date: Wed, 12 Jan 1994 20:27:11 GMT From: scheeff@kraft.ecn.purdue.edu (David T Scheeff) Organization: Purdue University Engineering Computer Network Message-ID: Followup-To: poster Sender: news@noose.ecn.purdue.edu (USENET news) I am looking for companies that would sell a basic VME card cage in an enclosed chassis. Please send names and phone numbers. Any info is appreciated... Thanks, David Scheeff scheeff@ecn.purdue.edu --------------------------- Newsgroups: comp.os.vxworks Subject: HDLC for VxWorks Date: Wed, 12 Jan 1994 22:58:50 GMT From: maillet@wrs.com (Al Maillet) Organization: Wind River Systems, Inc. Message-ID: Hi, Does anyone out there have an HDLC driver written for VxWorks. Either public domain or for sale will do. Thanks in advance, Al Maillet =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Al Maillet al@wrs.com Wind River Systems, Inc. Southwest Application Engineer 4225 Executive Sq. Suite 1200 Phone: (619)558-4165 La Jolla, CA 92037 Fax: (619)558-8918 - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Al Maillet al@wrs.com Wind River Systems, Inc. Southwest Application Engineer --------------------------- Newsgroups: comp.os.vxworks Subject: Re: write() transfer count wrong, but errno not set Date: Thu, 13 Jan 1994 00:10:05 GMT From: georg@sgl.ists.ca (Georg Feil) Organization: Institute for Space and Terrestrial Science Message-ID: Sender: news@newshub.ists.ca Ok, There's been enough heated debate on this so I'm sending out my brute force workaround. Thanks to Kent Long who managed to let slip enough information on the bug to identify the prerequisite: lseek() past the end of file. My workaround simply extends a file by writing 0's on the end whenever there is a seek past the end. (This may result in a file being extended when it shouldn't have been, i.e. no write follows the seek, but what the hell.) Use file_seek() below instead of lseek() to seek. Note that file_seek() is not meant to be plug-replaceable with lseek(), that feature is not required in our system. 'zero8k' is a character array of 8192 zero bytes. Georg. - -------------------------------------------------------------------------- int file_seek(int fd, int offset) /* * Sets the byte offset for the next write or read from a file. * Simple interface to lseek() function. This returns ERR_NONE iff the actual * actual seek offset returned by lseek() exactly matches the desired offset. * 'fd' is the file descriptor to seek on. * 'offset' is the absolute file position to seek to in bytes, where 0 is * the beginning of file. * Return value is error code (not a VxWorks error code, another type). */ { STATUS st; struct stat filestat; /* file status info obtained from fstat() */ int aoff; /* actual seek offset returned by lseek() */ long int fillsz; /* (***) for SPR #2739 kludge */ long int fillamt; /* (***) for SPR #2739 kludge */ if (FileDebug && Verbose>=2) { wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n", offset,fd); } /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with transfer count too low but errno not set after seeking past current end of file). Note that this may extend the file prematurely, i.e. even if no write() calls follow the seek. */ /* get current file size */ st=fstat(fd, &filestat); if (st==VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n", fd, vw_errmsg(0)); } return(ERR_VXIO); } /* manually extend file using zero writes if seek offset past end of file (note: tried ioctl() with FIOTRUNC, but this only works to shorten files! */ if (offset>filestat.st_size) { /* seek to the end of the file first */ errno=0; aoff=lseek(fd, filestat.st_size, SEEK_SET); if (aoff != filestat.st_size) { /* returned value should always match 'filestat.st_size' */ if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n", fd, aoff, filestat.st_size, vw_errmsg(0)); } return(ERR_VXIO); } /* fill file with zeroes to bring length up to 'offset' */ fillsz=offset-filestat.st_size; while (fillsz>0) { if (fillsz>8192) fillamt=8192; else fillamt=fillsz; errno=0; aoff=write(fd, zero8k, fillamt); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } if (aoff != fillamt) { if (Verbose>0) { wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n", fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0)); } return(ERR_VXIO); } fillsz -= fillamt; } /* flush the output to disk immediately */ st=ioctl(fd, FIOFLUSH, 0); if (st!=VX_OK) { if (Verbose>0) { wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } } /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */ errno=0; aoff=lseek(fd, offset, SEEK_SET); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n", offset, fd, vw_errmsg(0)); } return(ERR_VXIO); } /* returned value should always match 'offset' */ if (aoff != offset) { if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n", fd, aoff, offset, vw_errmsg(0)); } return(ERR_VXIO); } return(ERR_NONE); } - -- Space Geodynamics Laboratory | Internet: georg@sgl.ists.ca Institute for Space and Terrestrial Science | Phone: (416) 665-5458 4850 Keele St./North York/Ont/Canada/M3J 3K1 | Fax: (416) 665-1815 --------------------------- Newsgroups: comp.os.vxworks Subject: SCSI Disk Drive Date: Thu, 13 Jan 1994 01:36:59 GMT From: tsai@li.loral.com (Edward Tsai) Organization: Loral Instrumentation Keywords: SCSI Message-ID: Sender: usenet@li.loral.com Has anyone have any experience implementing a SCSI Floppy Drive under VxWorks-5.1 ???. Or, Booting vxworks from a floppy drive ???. If yes, then Questions: 1. How large is the Floppy Device Driver ?. 2. How much E-PROM space is still required for the basic BOOT image ?. 3. Does it support SCSI-2 ? 4. Which types of SCSI Floppy Drive has 5.1 been successful with ? 5. How much work is involved in modifying scsi.c ? A reply is greatly appreciated. Please send reply to: tsai@li.loral.com or feel free to call me at : 1-800-351-8483 extension: 4488 Edward Tsai Loral Instrumentations (619) 674-5100. ext: 4488 --------------------------- End of New-News digest ********************** From rdmacko@somnet.sandia.gov Thu Jan 13 07:44:31 1994 From: RD Mackoy Date: Thu Jan 13 07:44:40 PST 1994 Subject: Booting and rebooting Can a VxWorks image be generated to bring up the minimum functionality to establish ethernet communications to a host, then let the host load a full image and reboot the system? The whys are long and convoluted, but if anyone has done a system this way I would appreciate any input or help. Thank you, RD Mackoy rdmacko@somnet.sandia.gov Sandia National Labs 505-844-1911 PO Box 5800 MS 365 505-844-4797 Albuquerque, NM 87185 From wright@luke.atdiv.lanl.gov Thu Jan 13 08:21:41 1994 From: wright@luke.atdiv.lanl.gov (Rozelle Wright) Date: Thu Jan 13 08:21:49 PST 1994 Subject: Re: VME Memory Map on a Motorola mvme162 > Newsgroups: comp.os.vxworks > Subject: VME Memory Map on a Motorola mvme162 > Date: 12 Jan 1994 16:48:44 GMT > From: schuweil@forge.fnal.gov (greg schuweiler) > Organization: FERMILAB, Batavia, IL > Keywords: VME > Message-ID: <2h19lc$q23@fnnews.fnal.gov> > > I have a question on what controls the memory map with vxWorks/mvme162. > > The mvme162 has the VMEchip2 located at 0xFFF40000 - 0xFFF400FF (both > LCSR and GCSR registers), with the first master register located at > 0xFFF40014, (the following is a printing of a range of the VMEchip2 > registers and their content: > I think the problem is the bundled mmu support. If you look in the default board support package for the 162 in config/mv162/config.h, the line #define INCLUDE_MMU_BASIC /* bundled mmu support */ is included. This means that the MMU maps your memory using the default mapping that comes with the system. On the 167, I was able to get a working system by commenting out that line and including #define INCLUDE_BP_5_0 /* version 5.0 backplane driver */ which seemed to be necessary because I was using eiattach during the boot. I am not really happy with this solution. John Winans from Argonne sent me an assembly routine which does not require the BP_5_0 inclusion which works better. I would appreciate some advice from Wind River experts such as Chris Ford as to the proper way to use the mapping capability of the bundled MMU to allow access to extended memory. Rozelle Wright AOT-8, Los Alamos National Laboratory wright@atdiv.lanl.gov ----- End Included Message ----- From daemon@vxw.ee.lbl.gov Fri Jan 14 04:01:44 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 14 04:01:55 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 14 04:01:35 PST 1994 Subject: Upgrading VXW 4.0.2 to latest version Subject: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare Subject: Phone# WRS Subject: Re: Request: Company names that sell VME enclosures Subject: Re: Phone# WRS Subject: Re: Phone# WRS Subject: signal handler-like action on taskDelete()? Subject: General Micro System V64 Experiences? Subject: Re: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare Subject: Re: Booting and rebooting Subject: Re: signal handler-like action on taskDelete()? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Upgrading VXW 4.0.2 to latest version Date: 13 Jan 1994 13:21:12 GMT From: jka@air77.larc.nasa.gov (J. Keith Alston) Organization: NASA Langley Research Center Message-ID: <2h3hs8$l7e@reznor.larc.nasa.gov> Reply-To: jka@air77.larc.nasa.gov Hi, We currently run VXW 4.0.2. which is a very old version. I`m interested in getting some idea about what the effect on our code would be if we updated to the VXW latest version. I'm wondering if we would have to make major changes to our code or just minor adjustments? I guess the real question is, how much is vxworks backward compatible? Any comments or info would be greatly appreciated. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Keith Alston Lockheed Eng & Sci Co + There's a less than 5% chance of MS 130 Nasa LaRC Hampton VA 23666 = tonight and tomorrow jka@air77.larc.nasa.gov + --------------------------- Newsgroups: comp.os.vxworks Subject: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare Date: 13 Jan 1994 13:47:36 GMT From: jka@air77.larc.nasa.gov (J. Keith Alston) Organization: NASA Langley Research Center Message-ID: <2h3jdo$l7e@reznor.larc.nasa.gov> Reply-To: jka@air77.larc.nasa.gov Hi, I am running VXW 4.0.2 on heurikon 68030 boards. The host computer is another Heurikon 68030 running Unix SYS VR3. I am attempting to write server code for VXW which uses RPC. I am able to create an executable on the host but when I download this executable to VXW I get undefined symbol errors: undefined symbol: __iob undefined symbol: _memset ld error: error reading file. value = -1 = 0xffffffff I am looking for anyone out there with a similar setup who is using RPC or who may be able to shed some light on this problem. Thank You. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Keith Alston Lockheed Eng & Sci Co + There's a less than 5% chance of MS 130 Nasa LaRC Hampton VA 23666 = tonight and tomorrow jka@air77.larc.nasa.gov + --------------------------- Newsgroups: comp.os.vxworks Subject: Phone# WRS Date: 13 Jan 1994 13:55:37 GMT From: jka@air77.larc.nasa.gov (J. Keith Alston) Organization: NASA Langley Research Center Message-ID: <2h3jsp$l7e@reznor.larc.nasa.gov> Reply-To: jka@air77.larc.nasa.gov could someone please post the phone number for Wind River Systems? - --- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Keith Alston Lockheed Eng & Sci Co + There's a less than 5% chance of MS 130 Nasa LaRC Hampton VA 23666 = tonight and tomorrow jka@air77.larc.nasa.gov + --------------------------- Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks Subject: Re: Request: Company names that sell VME enclosures Date: Thu, 13 Jan 1994 16:36:09 GMT From: johnb@fc.hp.com (John Barclay) Organization: Hewlett-Packard Fort Collins Site Message-ID: References: Followup-To: comp.arch.bus.vmebus,comp.os.vxworks Sender: news@fc.hp.com (news daemon) You may want to subscribe to VITA. VITA has a directory, $50, that lists pretty much all VME solutions, including cabinets. Call 602-951-8866. - -- John Barclay Hewlett-Packard Company TN 229-4325 johnb@hpfcjb.fc.hp.com AT&T (303) 229-4325 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Phone# WRS Date: 13 Jan 1994 17:54:37 GMT From: adam@csi.jpl.nasa.gov (Adam Bernstein) Organization: Jet Propulsion Laboratory Message-ID: <2h41st$qib@csi.jpl.nasa.gov> References: <2h3jsp$l7e@reznor.larc.nasa.gov> WRS phone #: 800-545-WIND - ------------------------------------------------------------------------ Adam Bernstein Phone: 818 354-9784 Jet Propulsion Lab Guidance & Control / FAX: 818 393-6105 MS 198-235 Optical Tracking Group 4800 Oak Grove Dr. adam@bloodhound.jpl.nasa.gov Pasadena, CA 91109 - ------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Phone# WRS Date: Thu, 13 Jan 1994 17:59:20 GMT From: jerald@wrs.com (Jerald Pendleton) Organization: Wind River Systems, Inc. Message-ID: References: <2h3jsp$l7e@reznor.larc.nasa.gov> Sender: news@wrs.com (News Manager) jka@air77.larc.nasa.gov (J. Keith Alston) writes: >could someone please post the phone number for Wind River Systems? 1-800-545-WIND (9463) - -- Jerald R. Pendleton (Jerry) - Tech Support Engineer - Wind River Systems Corporate Headquarters: 1010 Alantic Ave, Alameda, Ca. 94501 email: jerald@wrs.com phone: 1-800-545-WIND Non-WRS-email: jrpend@netcom.com "Bullet proof code can't stand up to teflon bullets" - stig --------------------------- Newsgroups: comp.os.vxworks Subject: signal handler-like action on taskDelete()? Date: 13 Jan 94 17:49:36 MST From: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) Message-ID: <1994Jan13.174937.13103@hellgate.utah.edu> Reply-To: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) Is there a way to install a signal handler that will run before a task is deleted or suspended? taskDeleteHookAdd() seems like overkill. - -- Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge" - Rush --------------------------- Newsgroups: comp.os.vxworks Subject: General Micro System V64 Experiences? Date: Fri, 14 Jan 1994 04:10:58 GMT From: dog@xdev.sunspot.noao.edu (Fritz Stauffer) Organization: Computer, Hardware and Observatory Support Keywords: SBus, SPARC, MBus Message-ID: <1994Jan14.041058.25463@noao.edu> Sender: news@noao.edu I am interested in the GMS V64 cpu board and its ability to use different cpus on an mbus card. Does anyone have any experience with the card? Which cpus do you use? What are the pros and cons? Thanks, fritz stauffer sac peak obs. sunspot, nm 88349 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare Date: Fri, 14 Jan 1994 10:52:19 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <2h3jdo$l7e@reznor.larc.nasa.gov> In article <2h3jdo$l7e@reznor.larc.nasa.gov> jka@air77.larc.nasa.gov writes: >Hi, > I am running VXW 4.0.2 on heurikon 68030 boards. The host computer is another >Heurikon 68030 running Unix SYS VR3. I am attempting to write server code for >VXW which uses RPC. I am able to create an executable on the host but when I >download this executable to VXW I get undefined symbol errors: > >undefined symbol: __iob >undefined symbol: _memset >ld error: error reading file. >value = -1 = 0xffffffff memset () can be changed to bzero() if it's setting memory to 0's. otherwise, write your own. 4.0.2 is pretty old, and back then there was no memset() in vxworks library (does it have memset() now?). it also looks as though you might be dragging in some host library routines. in the old days, vxworks linked with host resident libraries as well as its own. if you have stdio routines that are not resolved by vxworks libs, you might be draggin in host's stdio stuff, which will refer to _iob[]. Hwa-Jin Bae PEACEFUL STAR --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Booting and rebooting Date: Fri, 14 Jan 1994 11:00:52 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <199401131547.IAA01094@somnet.sandia.gov> In article <199401131547.IAA01094@somnet.sandia.gov> RD Mackoy writes: >Can a VxWorks image be generated to bring up the minimum functionality to >establish ethernet communications to a host, then let the host load a full >image and reboot the system? i'm not sure what "let the host load a full image" means. if you're using ethernet for download, there needs to be something running on the target reading off of ethernet. given this, you'll be writing code that does essentially the same thing as what vxworks network download does. there are modified versions of vxworks code out there that does something similar to what you describe -- over vme backplane. the host (unix) downloads vxworks image over vme bus to target memory directly and tells the target's monitor rom to go execute the code just loaded (i.e. reboot). this is how sun's network co-processor board works (yes, it runs vxworks). Hwa-Jin Bae PEACEFUL STAR --------------------------- Newsgroups: comp.os.vxworks Subject: Re: signal handler-like action on taskDelete()? Date: Fri, 14 Jan 1994 11:12:12 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <1994Jan13.174937.13103@hellgate.utah.edu> In article <1994Jan13.174937.13103@hellgate.utah.edu> moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) writes: > >Is there a way to install a signal handler that will run before a task >is deleted or suspended? taskDeleteHookAdd() seems like overkill. as far as i know there is no direct way to do this. even unix won't allow you do catch SIGKILL. taskDeleteHooks aren't really that much of an overkill; it doesn't add overhead like switchHooks, and is only called at deletion time. implementing it in any other way than deleteHooks is not impossible, but a bit messy. in most single-mode thread oriented OS'es, like vxworks, task deletion is either done by the calling task's context or a third-party task's context (excTask in vxWorks?) -- because the task at the time which is to be deleted needs to be suspended and set to a state that can be manipulated statically, which means the task will not resume its context to run any more code. one could implement what you're asking, but it's not as clean as deleteHooks, imho. deleteHooks really shouldn't be necessary, but the lack of automatic/ optional resource reclamation in vxworks upon task deletion necessitates it. nevertheless, its overhead really isn't "overkill". Hwa-Jin Bae PEACEFUL STAR --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sat Jan 15 04:01:01 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 15 04:01:10 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 15 04:00:53 PST 1994 Subject: bpAlive Error at Bootup Subject: pcc2 timer int service time ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: bpAlive Error at Bootup Date: Fri, 14 Jan 1994 14:07:36 GMT From: campoe@tommy.jsc.nasa.gov (Alex Campoe) Organization: Johnson Space Center, Houston, Tx Message-ID: <1994Jan14.140736.19783@aio.jsc.nasa.gov> Reply-To: campoe@mickey.jsc.nasa.gov Sender: Alex Campoe Hi, I am working with two Force 30 CPUs connected to a VME backplane. A lot of times when I reboot the systems, the slave board will not find the anchor, printing this 'bpAlive' error once every 30 seconds or so. The manual does not say anything about it. Has anybody seen this before? Thanks. Alex Campoe - -- ^^/^^/^^ /^^/^^/^^ Alex Campoe ^^/ /^^ /^^ Lockheed Engineering and Sciences Co. ^^/^^/^^ /^^ Houston, TX ^^/ /^^ /^^/^^/^^ CAMPOE@MICKEY.JSC.NASA.GOV --------------------------- Newsgroups: comp.os.vxworks Subject: pcc2 timer int service time Date: Fri, 14 Jan 1994 22:54:43 GMT From: geger@den.mmc.com (George Eger (303) 971-6974) Organization: Martin Marietta Astronautics Group Keywords: mv167 pcc2 Message-ID: <1994Jan14.225443.28852@den.mmc.com> Sender: news@den.mmc.com (News) Hi. I am using the usrTime lib from MBARI on a mvme167 and have seen a strange problem. Every once in a while, two adjacent gettimeofday() timestamps (using PCC2 timer1 for usec) will result in the elapsed time being negative. I can only explain this if the time to propagate the interrupt from the PCC2 chip to the 68040 on the mv167 is significant - in this case about a microsecond. It looks like my program is sometimes able to read the timer before the interrupt gets propagated to the kernel to update the accumulated time. Does anybody out there know how much time (nominally) it would take for the '040 to stop processing a normal task after the PCC2 timer matches the value in its compare register? GWE ||========================================================================== ||George Eger / geger@den.mmc.com || Voice - (303) - 971 - 6974 || ||Integ. Fault Tolerant Avionics || Fax - (303) - 977 - 1145 || ||Space Launch Systems || MS T320 || ||Martin Marietta Astronautics || 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 leonid@rst.hellnet.org Mon Jan 17 01:39:59 1994 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Mon Jan 17 01:40:08 PST 1994 Subject: SPOX with VxWorks We are looking for people who use SPOX and VxWorks and have some experience with the interfaces between the two. Those of you who have the relavent experience and wouldn't mind abswering a couple of question, please respond directly to me. W will submit a summary to the exploder if enougth information will come in. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@RST.HellNet.Org From daemon@vxw.ee.lbl.gov Tue Jan 18 04:01:40 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 18 04:01:50 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 18 04:01:31 PST 1994 Subject: Global Alert For All: Jesus is Coming Soon ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Global Alert For All: Jesus is Coming Soon Date: 17 Jan 1994 19:19:24 -0500 From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV) Organization: Andrews University, Berrien Springs, MI, 49104 Message-ID: <2hf9uc$1gd@orion.cc.andrews.edu> The earthquake in Los Angeles, California, the flood in Europe, the seemingly unstoppable war in the former Yugoslavia, the devastating fires in Australia, the flood in the Midwest of the United States of America, the devastating fires near Los Angeles, California, the rapid and appalling increase in violence in cities, towns, villages all over the world, the famines, the diseases, the rapid decline of the family unit, and the destructive earthquake in India (in 1993) are signs that this world's history is coming to a climax. The human race has trampled on God's Constitution, as given in Exodus 20:1-17 (King James Version Bible), and Jesus is coming to set things right. These rapidly accelerating signs are an indication that Jesus is coming soon (Matthew 24). God's Holy Spirit is gradually withdrawing its protection from the earth and the devastating events you see are demonstrations of Satan's power. All those who are not guarded by God are in danger of forever losing eternal life. If you want to know what's about to happen, please study the books of Daniel and Revelation which are located in God's Word, the Bible. They are not sealed or closed books. They can and must be understood by all. Every word in the Bible from Genesis to Revelation is true. The Bible and the Bible only must be your guide. When God's Law (the Constitution for the Universe) is consistently ignored, disregarded, changed, and questioned, He permits certain events to occur to wake us up. I would urge all, wherever you are and regardless of the circumstances, to directly call on Jesus and ask Him to intervene in your life. Jesus who created this planet and every living creature in it and on it, died on the cross, was raised from the dead by God the Father, and is now in Heaven interceding for you. Jesus is the only One who can rescue us from the slavery, misery, and death Satan is causing us. For reference I'm including God's Constitution as given in the King James Version Bible. Please note that when God says the seventh day, he means Sabbath (the 7th day of the week) not Sunday (1st day of the week). Commandment #1: Exodus 20:1-3 (KJV) And God spake all these words, saying, I am the LORD thy God, which have brought thee out of the land of Egypt, out of the house of bondage. Thou shalt have no other gods before me. Commandment #2: Exodus 20:4-6 (KJV) Thou shalt not make unto thee any graven image, or any likeness of any thing that is in heaven above, or that is in the earth beneath, or that is in the water under the earth. And shewing mercy unto thousands of them that love me, and keep my commandments. Commandment #3: Exodus 20:7 (KJV) Thou shalt not take the name of the LORD thy God in vain; for the LORD will not hold him guiltless that taketh his name in vain. Commandment #4: Exodus 20:8-11 (KJV) Remember the sabbath day, to keep it holy. Six days shalt thou labour, and do all thy work: But the seventh day is the sabbath of the LORD thy God: in it thou shalt not do any work, thou, nor thy son, nor thy daughter, thy manservant, nor thy maidservant, nor thy cattle, nor thy stranger that is within thy gates: For in six days the LORD made heaven and earth, the sea, and all that in them is, and rested the seventh day: wherefore the LORD blessed the sabbath day, and hallowed it. Commandment #5: Exodus 20:12 (KJV) Honour thy father and thy mother: that thy days may be long upon the land which the LORD thy God giveth thee. Commandment #6: Exodus 20:13 (KJV) Thou shalt not kill. Commandment #7: Exodus 20:14 (KJV) Thou shalt not commit adultery. Commandment #8: Exodus 20:15 (KJV) Thou shalt not steal. Commandment #9: Exodus 20:16 (KJV) Thou shalt not bear false witness against thy neighbour. Commandment #10: Exodus 20:17 (KJV) Thou shalt not covet thy neighbour's house, thou shalt not covet thy neighbour's wife, nor his manservant, nor his maidservant, nor his ox, nor his ass, nor any thing that is thy neighbour's. I also recommend that the following books be obtained and closely studied: The Great Controversy By Ellen G. White Review and Herald Publishing Association Hagerstown, MD 21740 The Desire of the Ages By Ellen G. White Review and Herald Publishing Association Hagerstown, MD 21740 Patriarchs and Prophets By Ellen G. White Review and Hearld Publishing Association Hagerstown, MD 21740 Daniel and the Revelation By Uriah Smith Review and Herald Publishing Association Hagerstown, MD 21740 - ------- Clarence L. Thomas IV Phone: 616-471-6116 E-mail: thomas@redwood.cc.andrews.edu --------------------------- End of New-News digest ********************** From kwaldman@bbn.com Tue Jan 18 05:15:28 1994 From: Karl Waldman Date: Tue Jan 18 05:15:36 PST 1994 Subject: daemons etc I've had trouble with some vxWorks daemons, perhaps Clarence Thomas would give me some consultation on the problem. Karl Note: for the humor impair please add multiple :-) From mea@mclean.sparta.com Tue Jan 18 06:24:23 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Tue Jan 18 06:24:35 PST 1994 Subject: Re: Global Alert For All: Jesus is Coming Soon Greetings! >From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV) > are signs that this world's history is coming to a climax. The human race > has trampled on God's Constitution, as given in Exodus 20:1-17 (King James > Version Bible), and Jesus is coming to set things right. These rapidly > accelerating signs are an indication that Jesus is coming soon (Matthew 24). Speaking as a Taoist, it simply seems to me that the world is putting back into equilibrium that which man has shifted out of whack. But, if the above is true, does that mean that I can get some relief on my delivery dates ;-)? Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From dwampl@atl.com Tue Jan 18 11:04:11 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Tue Jan 18 11:04:32 PST 1994 Subject: Re: Global Alert For All: Jesus is Coming Soon > From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV) > Organization: Andrews University, Berrien Springs, MI, 49104 > Message-ID: <2hf9uc$1gd@orion.cc.andrews.edu> > ... > These rapidly accelerating signs are an indication that Jesus is > coming soon (Matthew 24).... I was once foolish enough to believe those who claimed that there was something unique about this age which made the return of Christ near. Then I matured enough to realize that we have it *good* compared to some of the periods of history that have come and gone in the last 2000 years. As far as natural disasters are concerned, the last 10,000 or so years have been relatively "uneventful". Please keep your "angry-god" conspiracy theories out of this mail group. Some of us have honest work to do. Thank you, Dean (dwampl@atl.com) From larkin@csd.nad.northrop.com Tue Jan 18 13:02:55 1994 From: "Sean K. Larkin" Date: Tue Jan 18 13:03:18 PST 1994 Subject: Re: comp.os.vxworks newsdigest > wake us up. I would urge all, wherever you are and regardless of the > circumstances, to directly call on Jesus and ask Him to intervene in your life what is his e-mail address? From hjb@dhokkaebi.wpd.sgi.com Tue Jan 18 17:17:00 1994 From: "Hwa-jin Bae -- consultant" Date: Tue Jan 18 17:17:08 PST 1994 Subject: mvme147 i'm looking for a mvme147 for a project. if you have any extras sitting idle, available either for sale or loan, please respond. thanks. hjb@netcom.com PEACEFUL STAR From daemon@vxw.ee.lbl.gov Wed Jan 19 04:01:52 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 19 04:02:21 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 19 04:01:32 PST 1994 Subject: Re: redirecting the shell input, anyone??? Subject: re: Global Alert For All: Jesus is Coming Soon Subject: re : Global Alert For All: Jesus is Coming Subject: Re: re : Global Alert For All: Jesus is Coming Subject: Re: VME Memory Map on a Motorola mvme162 Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG] ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: redirecting the shell input, anyone??? Date: 18 Jan 94 11:39:45 -0400 From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer) Organization: NRL SPACE SYSTEMS DIVISION Message-ID: <1994Jan18.113945.1177@nrlvx1.nrl.navy.mil> References: <1994Jan18.081847.1176@nrlvx1.nrl.navy.mil> Thought I'd clairify things a bit: In article <1994Jan18.081847.1176@nrlvx1.nrl.navy.mil>, dyer@nrlvx1.nrl.navy.mil (Doug Dyer) writes: > Hi folks, > > Has anyone successfully redirected the shell input? I have > strings I want the shell to parse, but I can't seem to get it to work > (in fact, it ignores the string completely). -> cut discussion of problem code <- > > I've tried leaving out the shell locks, the shellOrigStdSet, etc. While > the code above is not exactly slick, its just a proof-of-concept to see > that I can indeed redirect input. The string I sent it was "devs\n" > and I expected to produce the usual devs report, but got nothing :( > Suspecting the memory device and an incompatible ioctl call made by the shell, > I tried this with a pty device too :( > > anyone know what I'm doing/not doing???? > > thanks! currently I am using the "execute()" routine, however this is not the same as controlling standard input. Since execute() just calls the yy* yacc stuff it plays with the shell parser. This works for standard shell work, but does not help me control anything I run from the shell that requires input (ie: help() ). So my original question, "has anyone redirected shell input" should read "standard input" not "shell". I need to replace the keyboard, so to speak. The shell may or may not be running. any feedback would be appreciated! > -- > Doug Dyer * STI * dyer@nrlvax.nrl.navy.mil | "(2B) | !(2B) -> ?" > DISCLAIMER: These are my opinions, and not necessarily | LOWLY SHOPKEEPER, > those of STI, NRL, and most likely you too. | WHERE IS YOUR PEZ! > --------------------------------------------------------+--------------------- - -- Doug Dyer * STI * dyer@nrlvax.nrl.navy.mil | "(2B) | !(2B) -> ?" DISCLAIMER: These are my opinions, and not necessarily | LOWLY SHOPKEEPER, those of STI, NRL, and most likely you too. | WHERE IS YOUR PEZ! - --------------------------------------------------------+--------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: re: Global Alert For All: Jesus is Coming Soon Date: Tue, 18 Jan 1994 21:09:56 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: Bell-Northern Research, Ottawa, Canada Message-ID: <1994Jan18.210956.13190@nrtpa038.bnr.ca> References: <9401181902.AA14366@atl.com> Sender: billag@b4pphff (Bill Gutknecht) In article <9401181902.AA14366@atl.com>, dwampl@atl.com (Dean Wampler (dwampl@atl.com)) writes: |> > From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV) |> > Organization: Andrews University, Berrien Springs, MI, 49104 |> > Message-ID: <2hf9uc$1gd@orion.cc.andrews.edu> |> > ... |> > These rapidly accelerating signs are an indication that Jesus is |> > coming soon (Matthew 24).... |> |> I was once foolish enough to believe those who claimed that there was |> something unique about this age which made the return of Christ near. Then I |> matured enough to realize that we have it *good* compared to some of the periods |> of history that have come and gone in the last 2000 years. As far as natural |> disasters are concerned, the last 10,000 or so years have been relatively |> "uneventful". |> |> Please keep your "angry-god" conspiracy theories out of this mail group. |> Some of us have honest work to do. |> This bozo seems to have cross posted this message to just about every newsgroup I read ... it's quite ridiculous ... - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will Bell Northern Research ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: re : Global Alert For All: Jesus is Coming Date: 18 Jan 1994 22:24:53 GMT From: edwink@orff.NoSubdomain.NoDomain (Edwin Khachatourian) Organization: Image Analysis Systems Group, JPL Message-ID: <2hhnjl$8hc@elroy.jpl.nasa.gov> This is not a religious newsgroup. This guy must have forgotten the 11th commandment. This is how it goes. 11th commandment: Thou shalt not post religious discussions at non religious newsgroups such as comp.os.vxworks. I just hope that he gets flamed by yhe people from all the newsgroups he posted his message on. I sent him a personal copy of the 11th commandment. Edwin Kh. /(o\ \o)/ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: re : Global Alert For All: Jesus is Coming Date: Wed, 19 Jan 1994 00:06:51 GMT From: kent@wrs.com (Kent Long) Organization: Wind River Systems, Inc. Message-ID: References: <2hhnjl$8hc@elroy.jpl.nasa.gov> Sender: news@wrs.com (News Manager) edwink@orff.NoSubdomain.NoDomain (Edwin Khachatourian) writes: > > This is not a religious newsgroup. I would have to say that very much depends on the topic! - kent Kent Long Wind River Systems kent@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VME Memory Map on a Motorola mvme162 Date: Wed, 19 Jan 1994 07:41:04 GMT From: Andreas P. Pauletti Organization: Ascom Tech Ltd. Message-ID: <1994Jan19.074104.10643@hasler.ascom.ch> References: <2h19lc$q23@fnnews.fnal.gov> Sender: news@hasler.ascom.ch We are using also the MVME162 and I had also a problem with the VME controller. I added support for the Industry Pack of the board. And I realiezted that the setup of the VMECHIP2 in the file sysLib.c is not correct. 1. If you are using the MMU of the board than you have to make sure that the structure "sysPhysMemDec" is corrdctly setup. That you don not have any memory overlap. 2. Also check if the LOCAL_MEM_SIZE and corresponding constants are set to the correct value (in the package we got it was configured for 32M allthough the onborad memeory is max 4M) 3. Check also the part of the sysLib.c where the VMECHIP2 is initialised there the comment does not correspond to the settings. 4. When make a remake generate also the bootrom.hex. This is needed for the correct setup of the MMU. I hope it helps regards andreas pauletti --------------------------- Newsgroups: comp.os.vxworks,comp.answers,news.answers Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG] Date: Wed, 19 Jan 1994 06:26:41 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded Message-ID: Followup-To: comp.os.vxworks Reply-To: hjb@netcom.com Sender: hjb@netcom.com (squeedy) Archive-name: vxworks-faq Maintained-by: hjb@netcom.com Last-modified: Jan 18, 1994 Version: 1.2 This is the list of frequently asked questions (and their answers) for the newsgroup comp.os.vxworks. Where possible, pointers to existing information are included here, rather than rehashing that information again. If you haven't already done so, now is as good a time as any to read the guide to Net etiquette which is posted to news.annouce.newusers regularly. You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know about smileys, followups and when to reply by email to postings. The FAQ is currently posted to comp.os.vxworks, news.answers and comp.answers on the 15th of every month. You can retrieve the latest copy of this FAQ via anonymous FTP from rtfm.mit.edu in the directory /pub/usenet-by-group/comp.os.vxworks. Remember to use ASCII mode when transferring. This FAQ was compiled by hjb@netcom.com using comments by readers of comp.os.vxworks as well as his own limited knowledge of VxWorks. Credits appear at the end. Comments and indications of doubt are enclosed in []s in the text. Each section begins with dashes ("-") on a line of their own, then the section number. This should make searching for a specific section easy. This FAQ is also available via anonymous ftp in: netcom.com:pub/hjb/vxfaq - ------------------------------------------------------------------------- TABLE OF CONTENTS 1. What is VxWorks? 2. Brief History of VxWorks 3. What are some of the major features of VxWorks? 4. What are the Latest versions of VxWorks? 5. Where is the archive site for user-contributed code? 6. What application notes are available from Wind River? 7. How can I join the VxWorks user's group? 8. Is comp.os.vxworks also available via a mailing list? 9. Can I use gcc or g++ with VxWorks? 10. Other C/C++ Compiler tools for VxWorks? 11. Which cross-debuggers can I use with VxWorks? 12. What are differences between UNIX and VxWorks? 13. What are the performance/benchmark numbers for WIND kernel? 14. What are the performance/benchmark numbers for VxWorks TCP/IP? 15. What is the VxSim VxWorks Simulator? 16. Can I use one boot EPROM for multiple boards on the same net? 17. What's the deal with 68881 FPU code in interrupt handlers? 18. Why does ls() not work on netDrv devices? 19. Why can't I do ".." at top level directories or NFS mount points? 20. Why do I have trouble using relative symbolic links with NFS? 21. X for VxWorks 22. IEEE-488 (GPIB) driver for VxWorks 23. How does one disable NFS client caching? 24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption? 25. How does one get better network I/O performance? 26. How does one troubleshoot a backplane driver malfunction? 27. How do I add select support to my driver? 28. bind() gets EADDRINUSE, how do I fix it? 29. Common errors in interrupt handlers with floating point co-proc hardware 30. Finding entry point of a given module using its name 31. The problem with irint() in earlier (5.0.2 ?) releases 32. What are +T, +I thingies in the "i" output? 33. Gotchas w.r.t watchdogs 34. Is it possible to delete a memory partition in VxWorks? 35. rename() does not work in netDrv and nfsDrv filesystems, why? 36. Free NFS Server for VxWorks 37. Free SNMP for VxWorks 38. What third party products are available for VxWorks? 39. What kind of products have been developed using VxWorks? 40. A complete list of CPU hardware supported by VxWorks 41. A complete list of peripheral devices supported by VxWorks 42. What's with these unbundled "accessories"? 43. How come my 5.0.2 BSP isn't available in 5.1, damn it? 44. How much is VxWorks? 45. What is MicroWorks? 46. Other Unbundled Products for VxWorks? 47. How can I find out more about VxWorks? 48. What other net.resources are available on real-time systems? 49. How do i use FIONBIO in 5.0.2 when there is no fcntl()? 50. Free lex and yacc for use with VxWorks 51. timer_gettime() bug 52. bogus INCLUDE_TCP_DEBUG 53. free ppp for VxWorks [new] 54. how to disable cache on mc68040 or mc68030 using TT regs? [new] 55. work-arounds for ms-dos filesystem bug when lseek() past eof [new] 56. TCL for VxWorks 9999. Contributions to comp.os.vxworks FAQs. - ------------------------------------------------------------------------- 1. What is VxWorks? VxWorks, from Wind River Systems, is a networked real-time operating system designed to be used in a distributed environment. It runs on a wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems. It requires a host workstation for program development; supported host platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS. It does not run development systems software such as compiler, linker and editor on the target machine. The development environment is based on cross-development or remote-development method. You will need a UNIX machine of some sort (e.g. SUN's) to run the compilers and debuggers. The compiled application code can be downloaded to the target and runs as part of the VxWorks image. During the development phase or thereafter, individual object code (.o files) can be downloaded dynamically to running target system. Finished applications can be ROM'ed or whatever. - ---------------------------- 2. Brief History of VxWorks Based on what I have heard from David Wilner and others, WRS was started by Jerry Fiddler and David Wilner in Jerry's garage as a contract/consultant shop for realtime, embedded systems and other fun things. Francis Coppola was one of the earlier customers. They wrote a bunch of neat programs for their work and found that they liked them a great deal themselves, and added more excellent features to the system, eventually adding some things unheard of in embedded/realtime market in those days such TCP/IP networking. And continued to pioneer in this area by adding NFS, etc. VxWorks was the name given the collection of software which ran on top of various realtime kernels including VRTX and pSOS as well an earlier slower version of WIND kernel. [ editorial: VxWorks no longer runs on other kernels; it now runs exclusively on its own WIND kernel since the 5.0 release, for which the WIND was rewritten by John Fogelin. ] They got more people interested in the system and became successful. And moved from a little building in Emeryville to a larger one. And eventually to the present site in Alameda. And hired a lot of people. WRS sold many many more copies of this system and continues to grow like a real successful company. - ----------------------------- 3. What are some of the major features of VxWorks? In Version 5.1: - wind kernel unlimited tasks - 256 priorities - binary, counting mutex semaphores - message q's - POSIX pipes - sockets - shared memory - profiling utilities - ethernet support (i596, LANCE, NIC, SONIC) - SLIP (no PPP yet) - backplane driver for network - rlogin (server & client) - telnet (server only) - rpc (no rpcgen) - nfs (client) - ftp (server & client) - tftp (client & server) - rsh - bootp - proxyarp - C-interpreter shell (incomplete but useful) - symbolic debugging - disassembly - performmance monitoring tools - exception handling - signal handling (not quite unix compatible) - dynamic object image loader - system symbol table - system info utilities - libraries of 600+ utility routines - remote source level debugger(VxGDB) - SCSI support - DOS & RT11 & Raw filesystems. - "full ANSI" - "POSIX I/O" It is a good idea to get a copy of VxWorks manuals before purchasing the system. WRS can provide you with such documentation. As far as I know there is no "VxBook" in the bookstores. - ---------------------------- 4. What are the Latest versions of VxWorks? As as of June 1993, 5.0.3.: TRON will be discontinued. 5.0.3 : i386 5.0.5 : r3000 5.1 : 680x0, 683xx, i960, SPARC i386 and r3000 will be upgraded to 5.1. - ------------------------------ 5. Where is the archive site for user-contributed code? The VxWorks archive system is available for FTP as thor.atd.ucar.edu. It is also accessible via email server at vxworks_archive@ncar.ucar.edu. Questions should be directed to its maintainer, Richard Neitzel . To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix A summary of the archives is periodically posted to comp.os.vxworks. Some of the usual titles available: ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2 lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar vxtool, vxview, xc - ------------------------------ 6. What application notes are available from Wind River? List of Wind Technical Notes Motorola MV147 Slave Base Control 9-1 System hang during lkup( ) output 10-1 Reserving Memory 11-1 Serial IO Vanishing 13-1 NFS: problems with writing files 14-1 Which interrupts does VxWorks use? 15-1 Debugging ftp problems 18-1 Interrupt handlers, floating point 19-1 Booting From a Memory Board 22-1 Changing Network Interfaces 23-1 Writing Non-buffered Sockets 24-1 RPC and VxWorks 25-1 Using SCSI devices with VxWorks 5.x 26-1 The Select Facility in VxWorks 28-1 Using on-board Serial Ports 29-1 Problems with ls() 30-1 SCSI 31-1 Trouble Shooting Booting Problems 32-1 - ----------------------------- 7. How can I join the VxWorks user's group? For User Group info contact WRS or Eric Rabinowitz of Panoramic Systems at: elr@netcom.com or ericr@wrs.com phone: 408-429-0598 - ------------------------------ 8. Is comp.os.vxworks also available via a mailing list? Lawrence Berkeley Labs maintains an automated mailing list which is bi-directionally gatewayed to comp.os.vxworks It is called the 'VxWorks Exploder'. Mail to vxwexplo@lbl.gov is automatically mailed to a number of sites, including Wind River. Send subscription request to vxwexplo-request@lbl.gov. - ------------------------------ 9. Can I use gcc or g++ with VxWorks? WRS's gcc GNU Toolkit distribution can be reshipped in its entirety. WRS charges are for media and support, so obviously copies thereof don't matter to them. Lots of customers use g++ as provided by the "net" -- see the VxWorks Archive information below. You can get a generic freely distributable GCC/G++ and compile your code for VxWorks. Or you can just get a copy from someone who has a working GCC cross-development setup from WRS. WRS worked with Cygnus to polish up their release of GCC but a generic GCC distribution works just fine as well. For MC68K targets: You can also use native SunOS 4.X cc running on Sun-3's. You can also use various other free m68k C compilers such as lcc, sozobon, etc. provided that you're willing to hack on them. Richard Neitzel (thor@thor.atd.ucar.edu) writes, Thanks to some feedback I've corrected the archive instructions on how to build gcc, libgcc and libg++ for VxWorks. To make my life simpler the patches referenced are no longer included in the vx_cplusplus file. Instead there are now seperate patch files for the effected parts: libg++-2.5-src.patch: Patches libg++/src. libgcc2-2.5.0.patch: Patch libgccc2.c for gcc-2.5.0. libgcc2-2.5.2.patch: Patch libgcc2.c for gcc-2.5.2. libio-2.5.patch: Patch the stream library. See VxWorks Archive information in this FAQ for details on how to get these files. - --------------------------------------- 10. Other C/C++ Compiler tools for VxWorks? WRS re-sells (re-engineered?) CenterLine cfront product and WindC++ Gateway for CenterLine ObjectCenter. They come with browsers, etc. Not free. Wind C++ Gateway for ObjectCenter sold by WRS: $995 / user 1-4 copies $875 / user 5-9 copies Note that this is the cost over and above ObjectCenter. - ------------------------------ 11. Which cross-debuggers can I use with VxWorks? GDB & other more expensive tools from WRS, MicroTec Research, etc. WRS sells a lightly modified version of xxgdb which has a lousy GUI interface. In 5.1 xvxgdb may have been slightly improved -- but the ObjectCenter C++ with VxWorks solution provides better GUI interface. With a little bit of hacking, regular GDB works just fine. Personally, I find GUI to a debugger gets in the way of real work. I use GNU Emacs GDB interface which works well and can be easily customized. There might be some old VxWorks customers that also use VxWorks-aware dbxtool on Sun machines. This used to be maintained and sold by SUN Consulting. If you're only interested in debugging your "application" on VxWorks, the vxgdb approach (using RPC) works just fine. If you are rather more interested in the guts of the system as well as your application you might want to spend some time building cross-debugging tools from generic GDB distribution into VxWorks. - ------------------------------------ 12. What are differences between UNIX and VxWorks? They're both a hack. UNIX has a larger installed base. :-) Seriously though, similarities end there, IMHO. VxWorks does have a lot of UNIX "compatible" routines in the user libraries. So porting a UNIX application is not that hard. But there are enough differences to make such a port take longer than normally expected. For one thing, UNIX definitely is not realtime, whatever that means. [ editorial: To me personally, what realtime means is this -- when there is a spinning process or task running like crazy doing some stuff busily, I still want my system to respond immediately when I type a character on my console keyboard. VxWorks, and other real realtime OS'es, do this. UNIX and MS-DOG don't. ] VxWorks in its original form does not have any memory protection support. It runs in one mode. No protected vs. user mode switching is done. Running in supervisor mode on most processors, and not using traps for system calls, VxWorks can achieve minimal overhead on a given piece of hardware than UNIX. Programming on VxWorks can be more tricky than UNIX for the same reason. UNIX provides resource reclamation; by default, VxWorks does not. [ editorial: using deleteHooks or whatever, you could implement this on your own.] Instead programmers write what they need as needed. As a result, the context switch time in VxWorks is on the order of a few micro-seconds (since there is a lot smaller context to save and restore). VxWorks does not have full "process"; it only has tasks, or "threads", or light weight processes as some people like to call them. Like any other multi-threaded environments (or SMP environments), care should be taken when writing multi-tasking code. Each routine should be written carefully to be re-entrant (if it is going to be called from multiple contexts), semaphores are used a lot for this. And static variables are frowned upon. Sometimes, when porting a UNIX application, you may need to add "task variables" for this reason (as done for rpcLib in VxWorks). VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented as semaphores). UNIX: ridiculous interrupt latency (e.g. spl's are implemented as interrupt lock and unlock calls!). VxWorks: priority preemption, optional round-robin time-slicing. Traditional UNIX: prioritized round-robin time-slicing. Since VxWorks is just a glorified "program" it can be changed and customized pretty easily. Task scheduling can be customized as desired, for example. Most people prefer priority based preemption in the realtime world. UNIX prefers "fair-share time-slicing". VxWorks networking code, however, is very UNIX compatible [editorial: it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe release ]. It is relatively easy to port socket based code to VxWorks. [ editorial: except the not-so-compatible hostLib routines, etc.] VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX as often misunderstood by some people. The confusion perhaps is due to the fact that UNIX hosts are used most widely to develop applications for VxWorks (and VxWorks itself). [ editorial: Realtime UNIX sounds kind of like Military Intelligence to me. (can you say, oxymoron?) ;-) ] There are a lot more differences! In short, UNIX is a nice system to run emacs on. VxWorks is much better at playing pin-ball game machines. - ---------------------------- 13. What are the performance/benchmark numbers for WIND kernel? A WRS VxWorks 5.1 Benchmark Report hot off the press: Benchmark numbers based on: mv167-25Mhz, 5.1 Cache Cache Key Measurements Enabled Disabled Raw Context Switch Time 4 us 14 us Cyclic Test Time 172 us 638 us Suspend/Switch/Resume/Switch 23 us 86 us Kernel Timings Task Related taskSpawn 124 us 370 us taskInit 58 us 181 us taskActivate 12 us 33 us taskDelete 101 us 303 us Task Create / Delete 249 us 684 us taskLock CASE 1: no lock 3 us 4 us CASE 2: lock exists 2 us 5 us taskUnlock CASE 1: no lock 2 us 12 us CASE 2: lock exists 5 us 6 us taskSuspend CASE 1: ready task 11 us 30 us CASE 2: pended task 9 us 19 us CASE 3: suspended task 8 us 19 us CASE 4: delayed task 9 us 19 us taskResume CASE 1: ready task 6 us 19 us CASE 2: pended task 10 us 19 us CASE 3: suspended task 13 us 30 us CASE 4: delayed task 9 us 18 us Semaphore Related semBCreate 66 us 152 us semCCreate 46 us 150 us semMCreate 45 us 139 us semDelete Binary 49 us 157 us Counting 49 us 163 us Mutual Exclusion 48 us 157 us semGive CASE 1: tasks in queue Binary 18 us 44 us Counting 20 us 46 us Mutual Exclusion 25 us 59 us CASE 2: no tasks in queue Binary 4 us 8 us Counting 5 us 11 us Mutual Exclusion 6 us 15 us semTake CASE 1: semaphore available Binary 4 us 9 us Counting 5 us 11 us Mutual Exclusion 5 us 13 us CASE 2: semaphore unavailable Binary 10 us 25 us Counting 11 us 27 us Mutual Exclusion 4 us 12 us Semaphore Give / Take Binary 7 us 15 us Counting 9 us 21 us Mutual Exclusion 10 us 26 us semFlush Binary 11 us 20 us Counting 11 us 20 us Mutual Exclusion 10 us 16 us Miscellaneous Operating System Timings Message Queue Related msgQCreate 93 us 280 us msgQDelete 71 us 229 us msgQSend CASE 1: task pending 39 us 102 us CASE 2: no tasks pending 23 us 64 us CASE 3: queue full 14 us 45 us msgQReceive CASE 1: message available 20 us 62 us CASE 2: message unavailable 15 us 41 us Memory Related malloc 28 us 81 us free 32 us 104 us Watchdog Related wdCreate 42 us 106 us wdDelete CASE 1: timer started 48 us 160 us CASE 2: timer not started 44 us 150 us wdStart CASE 1: timer in queue 20 us 70 us CASE 2: no timer in queue 18 us 55 us wdCancel 11 us 34 us Floating-Point robot application 18 sec 51 sec [ editorial: If you're anal enough to count pico-seconds in comparing realtime kernels, you might want to actually get each of the evaluation copies from various vendors and test them yourself. But remember benchmarks are misleading and almost always biased and inaccurate. Given similar benchmark numbers, give or take a few microseconds, etc., your dollars are better spent in getting something you'll enjoy using. ] - ----------------------------- 14. What are the performance/benchmark numbers for VxWorks TCP/IP? According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet) w/ cache w/o cache enabled TCP/IP Throughput (KB/sec) 859 KB/sec 682 KB/sec No numbers available on latency. Using a reasonably fast processor 25Mhz MC68040 and a reasonably well made ethernet chip like SONIC or LANCE put together on a reasonable board design will achieve TCP throughput close to full bandwidth of ethernet. [ editorial: This, of course, is rather slow in comparison with other fast implementations, since a 16Mhz MC68020 with onboard LANCE or a PeeCee with an ethernet board can easily do the same. I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC that does: 1170KB/sec. ] - --------------------------------- 15. What is the VxSim VxWorks Simulator? Propaganda from WRS: It really is VxWorks running under UNIX! So sure it is not realtime, although all tasks and resources interact in the same way -- great for prototyping "high-level" code. Using the simulator saves wear and tear on h/w. It (only) allows sytem level debugging with native GDB. Portably written object code compiled for VxSim (for SunOS SPARC) will usually load without recompilation on a SPARC target. And, BTW under 5.1 switching from one architecture to anthoer really is pretty painless. - ------------------------------ 16. Can I use one boot EPROM for multiple boards on the same net? WRS provides EPROMs with a default bogus bootline, virtually all boards come with non-valiatile RAM which is set as soon as the user fills in his parameters (which include CPU #). Therefore 1 EPROM may be duplicated and used in all boards at a site. If the board does not contain nvram then ROMs have to be specially blown, unless a custom scheme for reading some switches or something is coded to index into a bootline table. In 5.1 BOOTP is supported -- no more repeated EPROM burning is necessary. - ------------------------------ 17. What's the deal with 68881 FPU code in interrupt handlers? In general, FP context is optimally saved only when the scheduler notices that the new task coming in also uses the fpu (VX_FP_TASK). ISRs don't. If no tasks are using the FPU then ISRs may go ahead, unless different levels of ISRs could interrupt each other and again cause a protocol violation. And Stan Schneider says, You have to set the "VX_FP_TASK" option flag when you spawn your task. You also need to make sure you don't use the FPU in any interrupt service routines. Even if your code uses no floating point, some (brain-dead) compilers save some FPU registers at the start of all routines if there's any floating point in the file. That's not usually a problem if you're using the gcc compiler (at least with the "-O" flag on). A sure way to check is via the dissassembler. And Leonid Rosenboim says, This problem is quite common, and really simple to fix, all you have to do is make sure that all tasks that do a float operation ever, will be spawned with the VX_FP task option set. This is the best and only solution. Also, if you run floating operations in ISRs care must be taken, to call fppSave() and fppRestore(). Also if you are using 5.1 on a 68040, there is a bug in the compiler that you must work around. And Kent Long says, This was indeed a real problem in the context switch code in 5.0.x which was corrected in 5.1. In both OS versions, there is an optimization that causes the FP context to be swapped only when the incoming task has been spawned with the floating point (VX_FP) flag set. In 5.0.x, the copying-in of the FP context was done via an fppSave() call. This created problems if a new FP task was created after a previous FP task had been pre-empted by a non-FP task in the middle of an instruction. The new task ended up with a mid-instruction context (which causes the protocol violation), and the old swapped-out FP task ultimately ended up with its context set to IDLE (which is equally incorrect). In 5.1, the FP context initialization was changed so that when a task is created, a pre-defined IDLE frame is copied into that tasks's context. Since there is no assumption about current FP state (as with fppSave), task creation is now decoupled from the regular switch logic. - ------------------------------ 18. Why does ls() not work on netDrv devices? Because the way directory information retrieval IOCTL calls are not acompatible between different types of "filesystems" in VxWorks. Another reason why some think VxWorks filesytem does not exist; they're just a collection of ioDevice drivers, and there is not a real consistent "design" to it. The lsOld() should work on "filesystems" that does not support ls(). Chuck Mead proposes the following special routine in case lsOld() does not work for you: #include "vxWorks.h" #include "bootLib.h" #define RSHD 514 STATUS lsHost(path) char *path ; { char *lsString; int dataSock ; int n ; char nextChar ; extern BOOT_PARAMS sysBootParams ; extern char *sysBootHost ; if (path == (char *) NULL) { lsString = (char *) malloc(4) ; strcpy(lsString, "ls") ; } else { lsString = (char *) malloc(strlen(path) + 5) ; sprintf(lsString, "%s%s", "ls ", path) ; } dataSock = rcmd (sysBootHost, RSHD, sysBootParams.usr, sysBootParams.usr, lsString, (int *) NULL) ; if (dataSock == ERROR) { printf("Error opening socket") ; return (ERROR) ; } n = fioRead(dataSock, &nextChar, 1) ; while (n == 1) { printf("%c",nextChar) ; n = fioRead(dataSock, &nextChar, 1) ; } close(dataSock) ; } - ------------------------------ 19. Why can't I do ".." at top level directories or NFS mount points? Because, again, VxWorks does not really have a "filesystem" as most people understand it. The top level directories are just implemented as device driver "node", which is used to identify the ioDev associated with the specific VxWorks "filesystem". Since there is no underlying filesystem layer, the story ends there. When you're at the top of the directory hierarchy within a given ioDev/filesytem, you simply cannot do "..". - ------------------------------ 20. Why do I have trouble using relative symbolic links with NFS? See [Q: Why can't I do ".." at top level directories or NFS mount points?] above. This is just another problem caused by the fact that a real filesystem does not exist for VxWorks. NFS client implementation actually does implement the symbolic links correctly, using lookup and readlink. The problem is due to the fact that, for some relative links that use ".." or whatever, that crosses over filesystems, VxWorks cannot have underlying subsystem that will handle file pathname to device mapping. Using absolute symbolic links work just fine (i.e. full path name from top). - ------------------------------ 21. X for VxWorks WRS has a product called windX which supports Motif. There is also libX11 contribution in the VxWorks Archive. This package is perhaps fairly old and out of date. Essentially, to port X stuff to VxWorks you'll need to do make sure code is re-entrant everywhere. There is a "multi-thread" safe version of Xlib available somewhere on the net, one might try porting that. There are also vendors that have built X servers using VxWorks. Jupiter Systems, in Alameda, makes high-end X server machines based on VxWorks. Other X terminal vendors (HP?) also use VxWorks. - ----------------------------- 22. IEEE-488 (GPIB) driver for VxWorks - National Instruments has lots of GPIB stuff - THEMIS computers has TSVME-409 whic hincludes a GPIB interface. - APLABS probably has some GPIB stuff too. - ----------------------------- 23. How does one disable NFS client caching? VxWorks caches read and write requests in NFS client code. To completely disable read and write cache, set nfsCacheSize to 0. To just flush the write cache as needed, use nfsCacheFlush() or FIOSYNC ioctl(). - ------------------------------ 24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption? This is due to a bug in slipDelete() and/or if_dettach(). slipDelete() calls if_dettach() to clean up after itself (SLIP network interface driver). Not only is if_dettach() misspelled, it also doesn't do a complete job. One deficiency is that it does not delete routes that are pointing to the interface being deleted. This is remedied via another function that deletes all routes for a give netif device driver. [ ifRouteDelete() ??? ] slipDelete() does call this routine to delete routes. Another problem is that if_dettach() does not delete a pointer to the netif device driver structure in the global in_ifaddr linked list. The in_ifaddr list is used by the network kernel code to find IP addresses of available network interfaces, among other things. This lack of proper cleanup turns out to be a rather hard-to-find memory corruption problem in network code, and usually manifests itself as routing table corruptions. To fix this add the following routine, and call it right after calling slipDelete: void in_ifaddr_remove(ifp) struct ifnet *ifp; /* ifp = ifunit("sl0") before slipDelete() called */ { struct in_ifaddr *ia, *prev_ia; if (!ifp) return; prev_ia = 0; for (ia = in_ifaddr; ia; ia = ia->ia_next) { if (ia->ia_ifp == ifp) { if (prev_ia) prev_ia->ia_next = ia->ia_next; else in_ifaddr = ia->ia_next; return; } prev_ia = ia; } } This, along with the route cleanup, should be incorporated into if_detach(). - ------------------------------ 25. How does one get better network I/O performance? Most of the overhead is due to socket to network core interface overhead. The copy that happens between the socket layer and network core code can be avoided by using the routines in uipc_socket.c (as in BSD tahoe release code available on various archive sites) and using mbufs directly. You can also try using raw etherLib routines. However, etherLib also does copying between user application and network driver. If you must use the socket interface (sockLib), make sure you tune the socket level buffers sizes to optimal values using setsockopt() calls SO_SNDBUF and SO_RCVBUF. You might also just try changing the globals that control the following default parameters to larger numbers (all the way upto 48K): tcp_sendspace (default 4K) tcp_recvspace (default 4K) udp_sendspace (default 2K) udp_recvspace (default 4K) To get around extra latency in some cases, you might turn on TCP_NODELAY option on TCP sockets. - ------------------------------ 26. How does one troubleshoot a backplane driver malfunction? There are a few rules of thumb: 1) try the simplest case first -- use polling instead of bus or mailbox interrupts and software test-and-set instead of hardware test-and-set. See if this works first. And then try hardware test-and-set and then the desired mailbox or bus interrupt. 2) use bpShow() to see what's up. Also look for magic code 0x1234 in share mem area being used for messages, and verify heartbeat is being incremented. At the "anchor" you should see the magic code (4 bytes) followed by a long word which should be incrementing (the heartbeat) every second. 3) verify all memory mapping and make sure there's no address conflicts on the bus 4) make sure bus controller is functioning properly. Some combinations of boards might not work well especially if your system controller board arbitrates the bus in one way and other boards expect to be arbitrated in a different way. Sometimes you might need to use a separate system controller. Of course, also make sure you only have one bus master. And that your VME bus strappings (BREQ, IACK daisychains) are right. 5) call Wind River's VxWorks tech-support... - ------------------------------ 27. How do I add select support to my driver? #include "selectLib.h" ... xxx_init(...) { ... selWakeupListInit(&xxxdev->selwakeupList); ... } xxx_ioctl(...) { ... switch(request_type) { ... case FIOSELECT: selNodeAdd(&xxxdev->selwakeupList, (SEL_WAKEUP_NODE *)request_arg); if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD) && readable_condition_is_met) selWakeup((SEL_WAKEUP_NODE*)request_arg); if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE) && writable_condition_is_met) selWakeup((SEL_WAKEUP_NODE*)request_arg); break; ... case FIOUNSELECT: selNodeDelete(&xxxdev->selWakeupList, (SEL_WAKEUP_NODE*)request_arg); break; ... } } And, add calls to selWakeup() as appropriate in your interrupt handlers and read/write routines as selective conditions are toggled or satisfied. - ------------------------------ 28. bind() gets EADDRINUSE, how do I fix it? Fix: do setsockopt() SO_REUSEADDR - ------------------------------ 29. Common errors in interrupt handlers with floating point co-proc hardware Don't forget to use: fppSave() fppRestore() Interrupt handler encapsulation code doesn't always save fpp registers for you. - ------------------------------ 30. Finding entry point of a given module using its name Example from a poster in vxworks newsgroup (who?): FUNCPTR start; /* found entry point goes here */ UINT8 symType; int tid; if(symFindByName(sysSymTbl,"_nlos_start",(char**)&start,&symType)==OK){ /* taskSpawn(name,priority,options,stacksize,entryAddress,arg1,..) */ tid = taskSpawn("nlos",TASK_PRI_NLOS,SPAWN_OPTS,STACK_SIZE_NLOS,start, arg1,arg2,.....); } - ------------------------------ 31. The problem with irint() in earlier (5.0.2 ?) releases The problem: /* Include Files */ #include "vxWorks.h" #include "math.h" long irint_count = 0; sinTest() { int sinTable; while(1) { sinTable = irint(sin(4./1024.*(2.*3.14))*10.); irint_count++; } } % cc68k -I/vxworks/vw/h -c sinTest.c -> ld < sinTest.o /* 0x08 Option = VX_FP_TASK within taskLib.h */ -> taskSpawn ("sinTest", 100, 0x08, 4000, sinTest) /* OR without the Floating Point Option */ -> sp sinTest -> irint_count Bus Error Program Counter: 0xb0ac0124 Status Register: 0x3004 Access Address : 0xb0ac0120 Special Status : 0x01e6 Task: 0xfcb82c "sinTest" The answer: Submitted-by wrs!yuba!kent@uunet.uu.net Fri Sep 27 18:55:25 1991 Submitted-by: wrs!yuba!kent@uunet.uu.net (Kent Long) > In the function irint, there is a bug that sets the floating point > Exception enable byte register to random values. Here is the > disasembled code: > > _irint: > 00e034 4e56 0000 LINK .W A6,#0 > 00e038 f227 6b80 FMOVE .X F7,-(A7) > 00e03c f22e 5780 0008 FMOVE .D ($8,A6),F7 > 00e042 f22e 6380 0008 FMOVE .L F7,($8,A6) > 00e048 202e 0008 MOVE .L ($8,A6),D0 > > 00e04c f201 9000 FMOVE .L D1,# > 00e050 504f ADDQ .W #8,A7 > 00e052 4e5e UNLK A6 > 00e054 4e75 RTS > > Line 0e04c is the line that sets the FPCR to some random value, > as D1 is unknown going into the function. I rewrote the routine, > without line 0e4c, and everything works fine. > If anyone out there knows why this line was put in, I would > appreciate knowing. Hope this may keep someone else from spending > a couple of days tracking down this problem. I have confirmed that this is a bug in all 5.x versions of VxWorks for the 68k. (In fact, it's in 4.0.2 as well.) As Mark correctly observed, the problem is that the FPCR register is erroneously being set. This was a simple cut-and-paste error in the VxWorks source module. The line which sets the FPCR should instead be restoring the value of FP7, which was saved on the stack earlier (as you can see in the code above). So, it would appear that another side effect of this bug is to clobber FP7. The fix is pretty simple. The following patch scripts should get things back to what they should be. (You can just include the appropriate lines in your startup script, or enter them from the VxWorks shell.) For VxWorks 5.0.1 and 5.0.2: pMathPatch = mathHardIrint + 0x18; *pMathPatch = (short) 0xf21f; pMathPatch = mathHardIrint + 0x1a; *pMathPatch = (short) 0x4b80; This bug does NOT affect VxWorks 5.1. The disassembled code for Vx5.1, (HK68K/V3D) is: _mathHardIrint: 2042e58 4e56 0000 LINK .W A6,#0 2042e5c f227 6800 FMOVE .X F0,-(A7) 2042e60 f22e 5400 0008 FMOVE .D (0x8,A6),F0 2042e66 f22e 6000 0008 FMOVE .L F0,(0x8,A6) 2042e6c 202e 0008 MOVE .L (0x8,A6),D0 2042e70 f21f 4800 FMOVE .X (A7)+,F0 2042e74 4e5e UNLK A6 2042e76 4e75 RTS Kent Long further clarifies, This was indeed a real problem in the context switch code in 5.0.x which was corrected in 5.1. In both OS versions, there is an optimization that causes the FP context to be swapped only when the incoming task has been spawned with the floating point (VX_FP) flag set. In 5.0.x, the copying-in of the FP context was done via an fppSave() call. This created problems if a new FP task was created after a previous FP task had been pre-empted by a non-FP task in the middle of an instruction. The new task ended up with a mid-instruction context (which causes the protocol violation), and the old swapped-out FP task ultimately ended up with its context set to IDLE (which is equally incorrect). In 5.1, the FP context initialization was changed so that when a task is created, a pre-defined IDLE frame is copied into that tasks's context. Since there is no assumption about current FP state (as with fppSave), task creation is now decoupled from the regular switch logic. - ------------------------------ 32. What are +T, +I thingies in the "i" output? The following is an excellent description of all these symbols by many people on the net, including "Fred J. Roeber" and others: Description Status symbol ===================================== =============== and task's priority inherited + I Delayed and suspended DELAY+S Pended and suspended PEND+S Pended and Delayed PEND+T Pended, delayed and suspended PEND+S+T The DELAY state indicates that the task has done some sort of delayed call while PEND means the task has done something that caused it to block like trying to semTake a semaphore someone else was holding. PEND+T means that the task is both delaying and pending; it has done a semTake with a timeout. +I means that the task has (temporarily) inherited a higher priority through the use of a mutex semaphore. The priority inheritance protocol also accounts for the ownership of more than one mutual exclusion semaphore at a given time. A task in such a situation will execute at the priority of the highest priority task blocked on any of the owned resources. The task will return to its normal, or standard, priority only after relinquishing all of the mutual exclusion semaphores with the inversion safety option enabled. If you use nested mutex semaphores with priority inheritance turned on then when a task inherits a high priority due to some inner semaphore it owns, it doesn't lose that priority until it relinquishes all the semaphores it holds. This doesn't quite follow the rules for priority inheritance (to the extent that there really are any rules) in that normally, a task's inherited priority should decrease as it releases each nested semaphore to whatever the priority ceiling is for the semaphores it still holds. Getting this incremental priority reduction to work right in practice, though, is extremely difficult (some of the SUN papers on the Solaris real time scheduling indicate that this was one of the hardest things for SUN to get right in their OS upgrades). Given that VxWorks is a real time embedded OS, I, for one, don't care if WRS uses the current implementation even though it isn't "pure" because the result is a more reliable implementation that runs more deterministically. Anyway, my guess is that you will find that you have some nested semaphore code where you are doing something after releasing one of the nested semaphores that shouldn't be done at a high priority. - ------------------------------ 33. Gotchas w.r.t watchdogs watchdog handlers run at interrupt level. You should not use routines that can block in interrupt level code. Frequent mistakes: using printf() in watchdog routines -- use logMsg() instead. - ------------------------------ 34. Is it possible to delete a memory partition in VxWorks? No. memPartDestroy() is not really implemented. Perhaps it will be in the future. Currently it just returns ERROR. - ------------------------------ 35. rename() does not work in netDrv and nfsDrv filesystems, why? Because rename() is not implemented for netDrv (although it could be), and nfsDrv does not implement rename() completely either. Talk to WRS to get these fixed. - ------------------------------ 36. Free NFS Server for VxWorks A free, incomplete, sample implementation (i.e. hack) of NFS Server for VxWorks is available in: netcom.com:pub/hjb/nfsd There is a README file there that describes further details. The current snapshot of this implementation is a result of a couple of days of hacking, doesn't do everything right, and intended for educational and further hacking purpose. There is someone else who's porting the MS-DOS PC-based nfs server (SOSS?) to VxWorks. Not clear on its availability yet (let me know!) - ------------------------------ 37. Free SNMP for VxWorks hoff@bnlux1.bnl.gov (Lawrence T. Hoff) reports, We ported the CMU SNMPv2 code to vxWorks 5.1. This latest round of posts has prompted me to put it in anonymous ftp (ctrldev1.rhic.bnl.gov -- 130.199.96.82). SNMP Research sells VxWorks compatible port of their SNMP implementation with support. Their's cost $$$$$, though. - ------------------------------ 38. What third party products are available for VxWorks? I tried to include the third party products, list of consultants, services, goodies, etc. available for VxWorks from various sources but... there are too many to list here. Instead, the file: netcom.com:pub/hjb/vxworkers is updated in realtime to contain a list of individuals and companies that offer help, services (paid or unpaid), and goods for VxWorks. To get a copy (if you don't have ftp access) or to be listed in this file, please contact or send info in ASCII to: hjb@netcom.com. - ------------------------------ 39. What kind of products have been developed using VxWorks? - flight simulators - radio and optical telescopes - automative ABS & realtime suspension - naviation systems - deep sea instrumentation - PBXs - traffic lights - modems - sonar systems [ editorial: And, regrettably, in: ] - military stuff - --------------------------------- 40. A complete list of CPU hardware supported by VxWorks Complete list of WRS supported BSP's are available in: netcom.com:pub/hjb/vxbsp VxWorks runs on a lot of different hardware. Majority of hardware supported is based on VME bus. Porting VxWorks to a new VME board based on MC68K takes only a few days, give or take a week, depending on your karmic condition at the time. A lot of the ports are initially done by the customers and later "approved" by WRS, for which they charge, in order to keep them on "supported" list. Porting to a new "architecture" (new processor) takes longer. This varies more widely -- from a few months to a few years. - --------------------------------- 41. A complete list of peripheral devices supported by VxWorks Complete list of WRS supported BSP's are available in: netcom.com:pub/hjb/vxbsp VxWorks supports a wide variety of devices. A lot of device drivers are written both by customers and WRS staff. There are device drivers for almost popular available ethernet chips (except perhaps SEEQ and Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async COMM chip, etc.), little I/O thingies in micro-controllers (MC68302 serial I/O, etc.), SCSI, etc. Customers of VxWorks, hackers and other hardware vendors (especially VME) usually have a VxWorks driver for their board. There are drivers for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers, frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch toy games. A list of available device driver for VxWorks can be found in: netcom.com:pub/hjb/vxdrivers Some evil VxWorkers have drivers for military/weapons systems. - ---------------------------------- 42. What's with these unbundled "accessories"? Propaganda from WRS: The new product/feature doesn't need to wait for the next OS release. Only the users who want/need it pay for it lengthens price list which keeps individual items lower but still enhances WRS revenue growth. Please Note: WRS still always adds features to the core product, and has never taken items out of core product to make them unbundled. Unlike UNIX vendors and others. - ----------------------------------------- 43. How come my 5.0.2 BSP isn't available in 5.1, damn it? Propaganda from WRS: WRS tries to give customers 1 year warning when any product may be discontinued. Unfortunately, all the bugs in the notification system are still to be worked out. Complain vehemently to your sales rep. if he didn't keep you informed. WRS BSP obsoletion policy is primarily based on BSP volume and h/w avalability. The 5.1 Guide and Release Notes provide a step by step recipe to upgrade from 5.0.2 -- minimal changes, start by ANISifying. The BSP Port Kit 1.1 provides extensive info for the masochist. - ---------------------------------------- 44. How much is VxWorks? In general: Not free, in fact, quite the opposite. - Development License $23.5K (per project?) - Source $120K. - Target Licenses from $1000 for single quantity to $10 for 100,000+. - ------------------------------ 45. What is MicroWorks? VxWorks is also available as a kernel-only product (MicroWorks 1.0) for the following processors: i960, 680x0, 683xx MicroWorks is -- half the product at a half the price. It has no network, native debug, shell, or profiling. Comes with VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0 also included -- this is the debug agent which allows true system level debugging in ISR or wherever. In future, VxWorks may also be able to work with VxMon. Development License $12,500. - ------------------------------------ 46. Other Unbundled Products for VxWorks? Other unbundled "accessory" products are: VxMP ($4K) which is an extended shared memory capabilities for the kernel allowing semaphores and other objects to be manipulated over the backplane transparently (really!). VxVMI ($3K) is a library of virtual memory interface routines allowing text & kernel data protection. complementary products: BSP Port Kit 1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++ Gateway for ObjectCenter ($?K's), and Realtime Innovations StethoScope (3K). - ----------------------------- 47. How can I find out more about VxWorks? Read: comp.os.vxworks Email: inquiries@wrs.com Call: 1-800-KIK-WIND - ------------------------------ 48. What other net.resources are available on real-time systems? There is at least one other newsgroup devoted exclusively to a particular vendor's real-time operating system: comp.os.os9 Discussions about the OS/9 operating system. Here are some other related newsgroups: comp.arch Computer architecture. comp.arch.bus.vmebus Hardware and software for VMEbus Systems. comp.os.misc General OS-oriented discussion not carried elsewhere. comp.realtime Issues related to real-time computing. comp.os.os9 Issues related to OS9 and OS9000 realtime OS. There are too many other newsgroups devoted to computer operating systems to list here. The interested reader is advised to check the "newsgroups" file on a local news service machine. The automatic server for users of pSOS RTOS is now in place. PSOSUSER - A list intended for the discussion of topics relating to pSOSystem and other products of Integrated Systems Inc., Software Components Group. Send articles to psosuser@isi.com and administrative requests to listserver@isi.com. If you aren't already subscribed and would like to, please send a mail message to listserv@isi.com containing the following in the body of the message SUBSCRIBE PSOSUSER - ------------------------------ 49. How do i use FIONBIO in 5.0.2 when there is no fcntl()? Use ioctl() instead. ... { ... int on = 1; /* turn it on */ ... ioctl(fd, FIONBIO, &on); ... } - ------------------------------ 50. Free lex and yacc for use with VxWorks John Winas (winas@phebos.aps.anl.gov) writes, I just (moments ago) uploaded the two packages to thor.ncar.ucar.edu where the vxWorks archive is. When ever the maintainer moves it into the release area they will be available to everyone. I named the file lexyacc.tar.Z and it contains all of the sources and make files for you to build them. It all seems to work perfectly on my sun sparc running 4.1.3. The only thing you have to configure is the full path name to where you wish to keep flex so that it can find its skeleton file when you use it to lexify your .l files. Byacc has no skeleton files and simply needs to be in your path. I am interested in any bugs found in because we are using them here. Feel free to email me at winans@phebos.aps.anl.gov. - ------------------------------ 51. timer_gettime() bug From: kent@wrs.com (Kent Long) In article <9311230139.AA21147@focal.com> bobk@focal.com (Bob Klawuhn) writes: >I am currently trying to user the timerLib to obtain >the amount of time that a timer has left before it >expires. I am trying to use the timer_gettime function. >The value that it seems to return is always the time >that the start timer was given, not what is left on the >timer. This is indeed a bug in the 5.1 and 5.1.1 VxWorks versions. It is now being tracked as WRS SPR #2673. As a workaround, the following could be done following the timer_gettime() call, to convert the erroneous results into the desired remainder value: #include "private/timerLibP.h" struct timespec timeNow; (void) clock_gettime (CLOCK_REALTIME, &timeNow); TV_SUB (timerid->exp.it_value, timeNow); ...which leaves the remainder in it_value. - ------------------------------ 52. bogus INCLUDE_TCP_DEBUG From: hipp@wrs.com (Emily Hipp) >Bus Error >Program Counter: 0x0001c738 >Status Register: 0x3000 >Access Address : 0xbfbfbfd3 >Special Status : 0x0505 >Task: 0x3dcc54 "tExcTask" >TCP tracing not enabled (use INCLUDE_TCP_DEBUG). This is misleading information. INCLUDE_TCP_DEBUG is not supported as a configAll.h include option. [ editorial: INCLUDE_TCP_DEBUG never got integrated into VxWorks config files. To get around this bug, until WRS fixes it, either unset SO_DEBUG socket option using getsockopt()/setsockopt(), or call tcpTraceInit() (sp?) which will drag in tcp_debug.o and set the tcp_trace() routine to be called when debug option is set on TCP sockets. ] - ------------------------------ 53. free ppp for VxWorks Is available via anonymous ftp netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz - ------------------------------ 54. how to disable cache on mc68040 or mc68030 using TT regs? [ From: Steve Morris ] /**************************/ /* for 68030 (e.g. mv147) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_tt () { register int *pVal; int ttVal; pVal = &ttVal; ttVal = TT0_VALUE; asm ("pmove %0,tt0" : : "g" (*pVal)); ttVal = TT1_VALUE; asm ("pmove %0,tt1" : : "g" (*pVal)); } /**************************/ /* for 68040 (e.g. mv167) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_dtt () { asm ("movec %0,dtt0" : : "r" (DTT0_VALUE)); asm ("movec %0,dtt1" : : "r" (DTT1_VALUE)); } - ------------------------------ 55. work-arounds for ms-dos filesystem bug when lseek() past eof [From: georg@sgl.ists.ca (Georg Feil)] [editorial: This is a workaround for the bug in VxWorks ms-dos implementation which produces incorrect error return on write() after lseek() beyond eof. N.B.: VxWorks versions upto 5.1.1 have buggy IO system layer that does not support "correct" write() to normal files. When writing to a file via write() expect to check the return value even if it is not ERROR. Unlike most other systems (e.g. UNIX) VxWorks write() upto version 5.1.1 will return number of bytes actually written even when write() was not completely successful on devices that are not marked non-blocking and/or are subject to flow control. ] There's been enough heated debate on this so I'm sending out my brute force workaround. Thanks to Kent Long who managed to let slip enough information on the bug to identify the prerequisite: lseek() past the end of file. My workaround simply extends a file by writing 0's on the end whenever there is a seek past the end. (This may result in a file being extended when it shouldn't have been, i.e. no write follows the seek, but what the hell.) Use file_seek() below instead of lseek() to seek. Note that file_seek() is not meant to be plug-replaceable with lseek(), that feature is not required in our system. 'zero8k' is a character array of 8192 zero bytes. int file_seek(int fd, int offset) /* * Sets the byte offset for the next write or read from a file. * Simple interface to lseek() function. This returns ERR_NONE iff the actual * actual seek offset returned by lseek() exactly matches the desired offset. * 'fd' is the file descriptor to seek on. * 'offset' is the absolute file position to seek to in bytes, where 0 is * the beginning of file. * Return value is error code (not a VxWorks error code, another type). */ { STATUS st; struct stat filestat; /* file status info obtained from fstat() */ int aoff; /* actual seek offset returned by lseek() */ long int fillsz; /* (***) for SPR #2739 kludge */ long int fillamt; /* (***) for SPR #2739 kludge */ if (FileDebug && Verbose>=2) { wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n", offset,fd); } /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with transfer count too low but errno not set after seeking past current end of file). Note that this may extend the file prematurely, i.e. even if no write() calls follow the seek. */ /* get current file size */ st=fstat(fd, &filestat); if (st==VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n", fd, vw_errmsg(0)); } return(ERR_VXIO); } /* manually extend file using zero writes if seek offset past end of file (note: tried ioctl() with FIOTRUNC, but this only works to shorten files! */ if (offset>filestat.st_size) { /* seek to the end of the file first */ errno=0; aoff=lseek(fd, filestat.st_size, SEEK_SET); if (aoff != filestat.st_size) { /* returned value should always match 'filestat.st_size' */ if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n", fd, aoff, filestat.st_size, vw_errmsg(0)); } return(ERR_VXIO); } /* fill file with zeroes to bring length up to 'offset' */ fillsz=offset-filestat.st_size; while (fillsz>0) { if (fillsz>8192) fillamt=8192; else fillamt=fillsz; errno=0; aoff=write(fd, zero8k, fillamt); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } if (aoff != fillamt) { if (Verbose>0) { wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n", fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0)); } return(ERR_VXIO); } fillsz -= fillamt; } /* flush the output to disk immediately */ st=ioctl(fd, FIOFLUSH, 0); if (st!=VX_OK) { if (Verbose>0) { wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } } /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */ errno=0; aoff=lseek(fd, offset, SEEK_SET); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n", offset, fd, vw_errmsg(0)); } return(ERR_VXIO); } /* returned value should always match 'offset' */ if (aoff != offset) { if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n", fd, aoff, offset, vw_errmsg(0)); } return(ERR_VXIO); } return(ERR_NONE); } - ------------------------------ 56. TCL for VxWorks [From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)] Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz If you've ever been frustrated that the VxWorks shell is not re-entrant, and has no control flow (e.g. if then else, switch, case ), then you will find TCL very useful since it is a very complete language, that allows you to add your own application specific commands to the interpreter. I find it invaluable for system testing, since I register TCL commands for all major functionality of my real-time application. This allows me to test most pieces of my data acquisition system from a command line, and build nice flexible scripts to test and operate my system. As a matter of fact, I can even invoke specific methods of C++ classes via TCL. Also, you can control your real-time system from a Unix workstation by sending TCL commands from either a TCL or Tk/TCL application (via tclTCP). I find that sending TCL commands (which are just strings) is much easier and more flexible than writing a Remote Procedure Call (RPC) for each piece of functionality that I need to remotely invoke. - ------------------------------ 9999: Contributions to comp.os.vxworks FAQs. The following net.folks, among others, have contributed to this posting: Name email address ------------ ---------------------------- Mark Linimon linimon@nominil.lonestar.org Geoff Espin geoff@wrs.com Rev. Bob Crispen crispen@foxy.boeing.com Stan Schneider stan@rti.com Fred J Roeber fjr@ssd.ray.com Marc Friedman maf@verdix.com Joe Van Andel vanandel@ncar.ucar.edu Bob Marino ram@mr.picker.com Richard Kowalsky cmdorat@tc.fluke.com Kent Long kent@wrs.com James Moore james@wrs.com Chuck Meade chuckm@verdix.com Patrick T. Pinkowski ppinkow@jupiter.ksc.nasa.gov D'Anne Thompson dat@noao.edu Leonid Rosenboim leonid@rst.hellnet.org David Lim lim@robotics.jpl.nasa.gov Richard Neitzel thor@thor.atd.ucar.edu John Winas winas@phebos.aps.anl.gov Georg Feil georg@sgl.ists.ca Steve Morris morriss@smtplink.indigo.co.il I welcome flames, insults, accusations, reactions, additions, and corrections to this posting via email: hjb@netcom.com - ------------------------------ =============================================================================== --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Thu Jan 20 04:01:29 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 20 04:01:38 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 20 04:01:21 PST 1994 Subject: Re: Global Alert For All: Jesus is Coming Soon Subject: socket ioctl? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Global Alert For All: Jesus is Coming Soon Date: Tue, 18 Jan 1994 22:03:51 GMT From: zal@bnlux1.bnl.gov (gonzalo maldonado) Organization: Brookhaven National Laboratory, Upton, NY 11973 Message-ID: <1994Jan18.220351.11723@bnlux1.bnl.gov> References: <9401181424.AA23579@helios> Jesus Christ can set you free from the fear of DEADLINES because He died to pay the price for all your MISSED DATES. Taoism doesn't provide for your DELAYED DELIVERIES. Boy! You better have your RELEASE in on time before He returns. This VERSION of creation is about to get REVISED and only those who have accepted Jesus Christ as Lord will not have their CONTRACTS CANCELLED! :-{) Zal Maldonado --------------------------- Newsgroups: comp.os.vxworks Subject: socket ioctl? Date: 20 Jan 1994 10:24:51 GMT From: smagt@fwi.uva.nl (Patrick van der Smagt) Organization: FWI, University of Amsterdam Message-ID: <2hlm5j$b9v@mail.fwi.uva.nl> HI! I'm trying to port my SYSV/BSD socket code to VxWorks. I encountered a problem with raising signals on socket input, which can be done using #if SYSV if (ioctl(d_learn_socket, I_SETSIG, S_RDNORM|S_INPUT)) { perror("setup_learn ioctl()"); panic_exit(); } #elif BSD if (fcntl(d_learn_socket, F_SETOWN, getpid()) == -1) { perror("fcntl F_SETOWN"); panic_exit(); } if (fcntl(d_learn_socket, F_SETFL, FASYNC) == -1) { perror("fcntl F_SETFL"); panic_exit(); } #endif However, VxWorks doesn't know fcntl nor I_SETSIG (I'm running VxWorks 5.0.2). Is there a solution to this problem? Patrick --------------------------- End of New-News digest ********************** From erolfe@ll.mit.edu Thu Jan 20 06:45:54 1994 From: erolfe@ll.mit.edu (Ed Rolfe) Date: Thu Jan 20 06:46:09 PST 1994 Subject: Questions on TCL under VxWorks... Hi, Is anyone else using Joe Van Andel's port of tcl7.0 to vxworks? If so, I have the following questions, and being a newbie myself to tcl/tk, I apologize in advance if the answer(s) are obvious... [Q1]: from my development workstation, how can i issue the following tk command to the interpreter running on the vxworks host? "send appName arg ?arg ...?" I've briefly looked through the modified tcl code and still can not see how to do this. I doubt the vxworks tclMain task is registering the app-name against any display on our net, yet Joe eludes to this capability in his release notes. An example of how to do this, even if only with the vxTCLDemo() function, would be useful. BTW: I did also scan the tclTCP.c code, and while it looks like this may be how remoted command execution could be performed, again, i'm not clear on how the vxworks server-interpreter is established nor what commands must be registered with the client-interpreter (workstation in this case), in order to establish a link to the vxworks server. [Q2]: for those people who are using this port of tcl7.0, do you have any interesting and useful VxWorks applications you are willing to release publicly, or snipets of which you might think helpful to those of us just getting started under tcl. One such interesting case would be to use tclsh, rather than vxRsh, to execute a remoted VxWorks command. [Q3]: perhaps a question more for the WRS folks... Did WRS or FSF add the TCL interface to VxGDB? In either case, can (or should) we expect that at some point in the future, WRS will perhaps be supplying an alternative to their existing shell? Thanks - ed +-----------------------------------------------------------------------+ | Edward G. Rolfe email: erolfe@ll.mit.edu | | MIT Lincoln Laboratory voice: 617/981-4013 | | MS B-284 fax: 617/981-0785 | | 244 Wood Street Division 6 Group 64 | | Lexington, MA 02173 Satellite Communication Technology | +-----------------------------------------------------------------------+ From mpoulsen@piranha.sim.es.com Thu Jan 20 07:35:46 1994 From: mpoulsen@piranha.sim.es.com (Mike Poulsen) Date: Thu Jan 20 07:35:58 PST 1994 Mike Poulsen --- mpoulsen@piranha.sim.es.com --- Howdy: We are currently using vxWorks 5.1 and are experiencing some difficulties with the MV147 SCSI driver. When we attempt to format some SCSI devices, the vxWorks SCSI driver seems to timeout before the format command has a chance to finish. This seems to happen only on large disk drives which may take in excess of 40 minutes to complete the format. We have analyzed the SCSI information with a SCSI analyzer and have come to the conclusion that it is the driver that is timing out. We have attempted to increase this timeout period by assigning the SCSI_TIMEOUT_FULL value to the pScsiXaction->cmdTimeout field of the SCSI_PHYS_DEV structure before issuing the format command but with no success. We have tried both the scsiIoctl() and scsiFormatUnit() command (of course not both in the same image at the same time). SCSI_PHYS_DEV *pScsiPhysDev = scsiPhysDevCreate(... . . . pScsiPhysDev->pScsiXaction->cmdTimeout = SCSI_TIMEOUT_FULL; scsiIoctl(pScsiPhysDev, FIODISKFORMAT, arg); /* This command */ scsiFormatUnit(pScsiPhysDev, FALSE, 0, 0, 0, NULL, 0); /* or this command */ The formatting process begins well and continues for about 35 to 40 minutes (We know the drives require at least 40 minutes to format), at which time the SCSI driver issues a SCSI bus reset (a good indication that the driver timed out). At this point the drive cannot even be seen by the SCSI driver (even after reboot or power down) since the drive returns nothing on a scsiReadCapacity() called from scsiPhysDevCreate(). (We are pretty sure that the drives themselves are good since we can then mount them on other systems not using the vxWorks MV147 SCSI driver and be able to format them fine). An example of one of the drives we`re working with is a 2.2 Gig Seagate ST12400N removable shuttle drive. Has anyone experienced this before and if so do you know of a solution. Thanks for any ideas!!!! Michael Poulsen Evans & Sutherland Computer Corporation Salt Lake City, Utah mail to: mpoulsen@piranha.sim.es.com From mea@mclean.sparta.com Thu Jan 20 09:11:12 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Thu Jan 20 09:11:21 PST 1994 Subject: Modems and/or DES on VME Greetings! Is anyone out in netland familiar with any manufacturer that builds a VMEbus implementation of any of the popular modems (V.32, V.32bis, etc.). Alternatively, we could use a DSP if someone had code to make the DSP look like a modem. I realize that modems are cheap, but it's a packaging issue. We'd like to have at least 3-4 channels with just phone line jacks on the back of the box. On a separate, yet related, topic, does anyone have information of anyone who has implemented a VME board that supports DES (Data Encryption Standard) either in hardware? I have software versions of the algorithms, but was looking for hardware to take the load off my VxWorks systems. Any pointers would be appreciated, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From visicom!VisiCom.COM!trest@lbl.gov Thu Jan 20 10:33:05 1994 From: Mike Trest Date: Thu Jan 20 10:33:21 PST 1994 Subject: RTOS Professional Positions To All: "... If you know your stuff in RTOS generally or VxWorks in particular, please open an EMAIL-ONLY dialog with me. If you have serious experience in UNIX/C/Networking/X-Windows/Motif applications, I am interested in hearing from you. ..." It has been six months since my original posting of this message in July 1993. In that time I have received a few hundred pieces of mail. Approximately 20 organizations with about 30 current openings for experienced RTOS professionals have responded. The balance have been from individuals who wished to be on the distribution list. My motivation was, and remains, to raise the level of understanding of the career paths and opportunities available to the experienced RTOS processional. I want to encourage more people starting out in the RTOS field. I want to encourage visibility to our industry and the kinds of skills needed to function professionally. I want to encourage experienced RTOS people to be aware of the broader horizions available in our industry. I am beginning another cycle. I am asking those who have previously given me job offering EMAIL to update their data. Likewise, I am sending EMAIL to those who have previously asked me for a listing of these offerings. This cycle will be opened to include all RTOS professionals but with special interest in VxWorks, pSOS, and LYNX/OS. I have been asked why I am not restricting this to the news groups devoted to job-offerings. It is because of my narrow focus on experienced RTOS professionals only and because of the satisfaction expressed by previous participants. Therefore, I am submitting this announcement only to those EMAIL groups in which I am an active participant. ======================================================================= Here is the way I will be working this cycle: 1. If you employ RTOS professionals in your organization, please EMAIL me a simple description of your organization, your typical RTOS requirements, and how an interested individual may contact you. If you have current needs, please indicate. If you have no current openings, please state "FOR INFORMATION ONLY" somewhere in your message. I encourage organizations to send me an EMAIL even if you do not have any current openings. 2. Ever EMAIL received in response to item 1, will be forwarded on to a distribution list of individuals who express an intrest in hearing about organization who employ RTOS professionals. 3. If any individual wants to be copied on EMAIL received, please send me a message and I will put you on the distribution list. 4. Anyone on the distribution list who wants to contact any of the oragnizations who send me EMAIL must do so directly. 5. I WILL NOT GIVE A COPY OF THE DISTRIBUTION LIST TO ANYONE. Don't even ask. 6. I will provide a moderator/editor service for all messages received. I plan filter out flames and other meaningless messages to keep the distribution list clean. 7. This is not an official function of VisiCom Laboratories, Inc. I am acting as an individual. However, VisiCom may, from time to time, submit its own EMAIL which will, like other organizations will be submitted to the dristribution list. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 VisiCom Laboratories Fax: 619 457 0888 10052 Mesa Ridge Court San Diego, CA 92121 ==================================================== From rdmacko@somnet.sandia.gov Thu Jan 20 14:03:47 1994 From: RD Mackoy Date: Thu Jan 20 14:03:56 PST 1994 Subject: Boot and Reboot revisited From the responses I got, let me try to describe the situation in more detail. We have eight VXI crates with NIcpu030 cards as the slot 0 controller. We are running VxWorks 5.1.1. Our testing is weapon related (go military apps :-) ) in which we have only one chance to collect the data. We want to have the host (a SPARC 10) to be in control if and when a subsystem (the VXI crates) boot. The power up sequence is not deterministic, so a subsystem may try to boot before there is a host available. And if a subsystem controller goes down during a test we do not want it to reboot itself and possibly erase valid data on other cards. We have come up with one solution, to modify the boot PROMs and use BOOTP. The modification allows BOOTP to wait until an image is available for downloading. In the default PROMs, the BOOTP would wait until it found a host and if no image was available it would go to a serial console mode only. With the number of crates we did not want a serial network as well as ethernet. Does anyone see any gotchas or other possible solutions? If anyone is interested in our solution please let me know. Thanks, RD Mackoy rdmacko@sandia.gov Sandia National Labs 505-844-1911 PO Box 5800 505-844-4797 Albuquerque, NM 87185-0635 I speak for myself, only for myself, and noone but myself, so help me God! From hill@luke.atdiv.lanl.gov Thu Jan 20 16:28:10 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Thu Jan 20 16:28:18 PST 1994 Subject: Re: Boot and Reboot revisited Hello > > We have eight VXI crates with NIcpu030 cards as the slot 0 controller. We > are running VxWorks 5.1.1. Our testing is weapon related (go military > apps :-) ) in which we have only one chance to collect the data. > We want to have the host (a SPARC 10) to be in control if and when a > subsystem (the VXI crates) boot. The power up sequence is not > deterministic, so a subsystem may try to boot before there is a host > available. And if a subsystem controller goes down during a test we do > not want it to reboot itself and possibly erase valid data on other cards. > We have come up with one solution, to modify the boot PROMs and use > BOOTP. The modification allows BOOTP to wait until an image is available > for downloading. In the default PROMs, the BOOTP would wait until it > found a host and if no image was available it would go to a serial console > mode only. With the number of crates we did not want a serial network as > well as ethernet. > Does anyone see any gotchas or other possible solutions? If anyone is > interested in our solution please let me know. If you need stand alone operation you might try booting out of a RAM or SCSI disk. Its possible to avoid the VME sysreset when you reboot (at least on most processors- check out your BSP). By the way. We are just beginning to use NI CPU030's for some of our EPICS applications. Have used the 030 long enough to rate its reliability? Jeff From daemon@vxw.ee.lbl.gov Fri Jan 21 04:01:29 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 21 04:01:38 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 21 04:01:17 PST 1994 Subject: Re: Questions on TCL under VxWorks... Subject: Re: Questions on TCL under VxWorks... ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Questions on TCL under VxWorks... Date: 20 Jan 1994 21:47:23 GMT From: vanandel@stout.atd.ucar.edu. (Joe Van Andel) Organization: National Center for Atmospheric Research Keywords: TCL vxworks Message-ID: <2hmu5b$5ku@ncar.ucar.edu> References: <9401200943.AA15062@LL.MIT.EDU> Sender: vanandel@stout (Joe Van Andel) In article <9401200943.AA15062@LL.MIT.EDU>, erolfe@ll.mit.edu (Ed Rolfe) writes: |> Hi, |> |> Is anyone else using Joe Van Andel's port of |> tcl7.0 to vxworks? If so, I have the following |> questions, and being a newbie myself to tcl/tk, |> I apologize in advance if the answer(s) are obvious... |> |> [Q1]: from my development workstation, how can i issue |> the following tk command to the interpreter |> running on the vxworks host? |> |> "send appName arg ?arg ...?" |> You are correct, "send" only works from Tk, to other Tk/TCL processes attached to the same 'X' display. My port of tcl to vxworks supports tclTCP, which uses the "tcp" command to communicate between interpreters. You need to add tclTCP2.0 to your Unix Tk/TCL application to use this. (Get this from harbor.ecn.purdue.edu It should be available shortly as pub/tcl/extensions/tclTCP2.0.tar.Z ) Please note that tclTCP does have a known bug. If two tasks send messages to each other at the same time, they may deadlock. (Note, I didn't write tclTCP, I just ported it!) It works fine if you keep a "master-slave" task relationship, where one task always sends commands to the other. (I've investigating using a package called tcl-dp as a replacement, but it relies on Tk, so it can't easily be ported to vxworks.) Joe VanAndel Internet: vanandel@ncar.ucar.edu National Center for Web http://www.atd.ucar.edu/jva/home.html Atmospheric Research --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Questions on TCL under VxWorks... Date: 20 Jan 1994 23:02:30 GMT From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Keywords: TCL vxworks Message-ID: <2hn2i6$dn1@ncar.ucar.edu> References: <9401200943.AA15062@LL.MIT.EDU> <2hmu5b$5ku@ncar.ucar.edu> I posted: (Get this from harbor.ecn.purdue.edu |> It should be available shortly as pub/tcl/extensions/tclTCP2.0.tar.Z ) Sorry, make that tclTCP2.0.tar.gz Joe VanAndel Internet: vanandel@ncar.ucar.edu National Center for Web http://www.atd.ucar.edu/jva/home.html Atmospheric Research --------------------------- End of New-News digest ********************** From kevinr@photon.ceco.com Fri Jan 21 19:36:06 1994 From: kevinr@photon.ceco.com (Kevin R. Rumbaugh) Date: Fri Jan 21 19:36:14 PST 1994 Subject: Way to tell time since boot I have thought several times that I would like some way to be able to either query a board or at least figure out from the shell, how long a board running VxWorks has been 'up'. Has anyone else thought about this and implemented something along these lines, particularly for MVME1[46]7's? Does someone know of someway to extract this information from the 'kernel'? It does not necessarily have to be time, but simply some indication of how long it has been since the board was booted. If I could find someway to get the information it should be relatively easy to port the rstatd rpc code to send back the data to a remote requester. Any help would be appreciated. -- Kevin Rumbaugh 'The Marauder' --- Commonwealth Edison --- E-MAIL : kevinr@ceco.com OR uunet!ceco!kevinr AT&T : (312) 394-8894 FAX : (312) 394-4233 USMAIL : Information Systems; Room 1135; 125 S. Clark; Chicago IL 60603 From daemon@vxw.ee.lbl.gov Sat Jan 22 04:01:36 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 22 04:01:45 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 22 04:01:28 PST 1994 Subject: mv167 SCSI disk write CPU Hog ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: mv167 SCSI disk write CPU Hog Date: 21 Jan 1994 13:10:49 -0600 From: irwin@sugar.NeoSoft.COM (Bob Irwin) Organization: Realtime Systems / SW Houston Message-ID: <2hp9bp$bdg@sugar.NeoSoft.COM> Help! I've called for WRS support on the following, but am not getting much help. This is a plea to experienced vxWorks users. We've genned vxWorks 5.1 to support two SCSI disks (Seagate ST11200Ns) on a mv167 target using the DOS filesystem to write 'Contiguous' files while accessing data (A/D, Digital I/O, ieee488, 1553, serial, etc) in a realtime environment. The accessing of data is triggered by interrupts with periods of 1 and 10 milliseconds. A relatively low priority task 'archives' this data into one of two 1 megabyte buffers and when one of these buffers becomes full the 'archive' task writes the data to a pre-allocated contiguous local SCSI disk file. It appears that the vxworks filesystem is copying this 1 Megabyte buffer from user space and locking out ALL user tasks during the copy. As a result we cannot service the interrupts and lose data during this copy operation. I'm rather amazed that vxWorks doesn't seem to support what I'm used to calling "Asynchronous" disk IO or at least spooling of data to the filesystem. Older generation Operating Systems like DEC's RT11 and Intel's RMX handled this readily. How do we do it under vxworks? So, how do you guys work around this apparent limitation? Do we need to go to raw disk access? or direct Scsi access of the disk? Our time fuse is burning rapidly. Thank you. If we've missed an apparent way to handle this data spooling my apologies to the authors of WRS documents. Please post to this newsgroups or email me via: irwin@neosoft.com or sis@neosoft.com - -- R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 When I was a boy I was told that anybody could become president; I'm beginning to believe it. - Clarence Darrow --------------------------- End of New-News digest ********************** From leonid@rst.hellnet.org Sun Jan 23 01:43:55 1994 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Sun Jan 23 01:44:06 PST 1994 Subject: Re: Way to tell time since boot Usually the kernel ticks start at 0 when the system boots, so if you need to know the time since last reboot in seconds just do: seconds = tickGet() / sysClkRateGet() ; ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@RST.HellNet.Org From leonid@rst.hellnet.org Sun Jan 23 01:44:04 1994 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Sun Jan 23 01:44:24 PST 1994 Subject: DR-11 Board & Driver Does anyone have any pointer to a DR-11 VME board that has a VxWorks driver for it ? ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@RST.HellNet.Org From leonid@rst.hellnet.org Sun Jan 23 01:44:05 1994 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Sun Jan 23 01:44:28 PST 1994 Subject: Re: mv167 SCSI disk write CPU Hog irwin@sugar.NeoSoft.COM (Bob Irwin) writes: > It appears that the vxworks filesystem is copying this 1 Megabyte buffer > from user space and locking out ALL user tasks during the copy. As a result > we cannot service the interrupts and lose data during this copy operation. This diagnose of the problem is incorrect. We have experience with a similar application and we did not observe any interrupts locking. The mv167 ncr710 CSI chip writes the data to the disk directly from the user buffer. Besides, in VxWorks there is no concept of user space versus user space like in Unix. There is however a different problem in dosFs - the CPU overhead increases as the file size interases, which makes the use of very large cotigous files not practical. Our work around has been to use relative small files (~ 10 MBytes). This problem was filed with WRS support. Bob, I recommend you inspect your own code to see if YOU are not doing any intLock() or taskLock() within the archiver task. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@RST.HellNet.Org From morriss@smtplink.indigo.co.il Sun Jan 23 05:09:14 1994 From: Steve Morris Date: Sun Jan 23 05:09:32 PST 1994 Subject: rshd Text item: Text_1 Has anyone implemented an rsh daemon for VxWorks, or know where I can get a source that I could modify or just the correct protocol. I tried to write a server according to the protocol listed in the Sun "rshd" man page but just got the arcane message "socket: protocol failure in circuit setup" and do not know how to procede. Steve Morris ---------------------------------------------------------------------- Steve Morris voice: (972)-8-381055 Software Team Manager (972)-8-381818 Indigo Graphic Systems Fax: (972)-8-408091 P.O. Box 150, Rehovot, Israel e-mail: morriss@smtplink.indigo.hellnet.org ---------------------------------------------------------------------- From stan@rti.com Sun Jan 23 16:47:52 1994 From: stan@rti.com (Stan Schneider) Date: Sun Jan 23 16:48:03 PST 1994 Subject: Re: rshd >> Submitted-by morriss@smtplink.indigo.co.il Sun Jan 23 05:09:14 1994 >> >> Has anyone implemented an rsh daemon for VxWorks, or know where... >> RTILib has a similar functionality called "rshell"; it doesn't use the rsh protocol but accomplishes very similar results. There's also a program called vxRsh in the archives. I think it only supports one connection (?), but it may do what you want. -- 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 lerible@sass165.sandia.gov Sun Jan 23 16:52:57 1994 From: lerible@sandia.gov (Loren E. Riblett) Date: Sun Jan 23 16:53:05 PST 1994 Subject: shared backplane communications Help! We are running a sparc 2ce as a slot 0 controller running unix and an HK-MIPS V3500 in the same chassis running vxWorks. My question is, how can i signal the sparc from the V3500 that data is available for the sparc to display? I would also like to perform similar operations from the unix side to the vxWorks side. Any help with this problem would be greatly appreciated!! Thanks in advance. Loren Riblett From mea@mclean.sparta.com Sun Jan 23 17:00:24 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Sun Jan 23 17:00:35 PST 1994 Subject: Re: rshd Greetings! > > Has anyone implemented an rsh daemon for VxWorks, or know where I can > get a source that I could modify or just the correct protocol. > > I tried to write a server according to the protocol listed in the Sun > "rshd" man page but just got the arcane message "socket: protocol > failure in circuit setup" and do not know how to procede. > There is a vxrshd in the user's group archives that has clients on both sides of the link. Here at SPARTA, we took that code as a starting point and hacked it (yes, Hwa Jin, we HACKED it ;-) to support the "normal" rshd call from SunOS. Works like a champ. I'll be happy to send a copy to anyone who wants it (I thought I sent it to the archives once, but somehow it got lost in the shuffle). Rich, maybe I can try to post it to the archives again, if you can tell me what I have to do this time? BTW, I'll be out of town until next Thursday, so I can send the code as soon as I get back. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mea@mclean.sparta.com Sun Jan 23 17:00:28 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Sun Jan 23 17:00:45 PST 1994 Subject: Re: DR-11 Board & Driver Hi Leonid! VMIC has a DR11W-A board with VxWorks support. The folks at NASA Goddard are using it and we helped them integrate it into their system. It can run in either A32 or A24 space and has on-board DMA. The board makes some screwy assumptions regarding the use of BUSCLR (none of your boards can drive that signal while DMA transfers are occurring), but other than that, is works reasonably well. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From ah442@piglet.ins.cwru.edu Mon Jan 24 05:36:47 1994 From: ah442@cleveland.freenet.edu (Erik C. Orange) Date: Mon Jan 24 05:36:56 PST 1994 Subject: Spurious Interrupt: What is it? I thought I saw this subject pop up once before, so hopefully someone can re-iterate for me. Every now and then our development system pops up this message on the console shell: interrupt: Uninitialized Interrupt! Vector number 24 (0-255). Spurious Interrupt Program Counter: 0x0000177a Status Register: 0x3100 What is the significance of Vector Number 24? Thanks in advance for any insight. Erik -- Erik C. Orange FRD Industrial Automation Systems Engineer Avery-Dennison Corporation ah442@cleveland.Freenet.Edu Concord, OH From tlusco@aegis.gsfc.nasa.gov Mon Jan 24 06:44:03 1994 From: tlusco@aegis.gsfc.nasa.gov (C Tom Lusco) Date: Mon Jan 24 06:44:13 PST 1994 Subject: Re: dr11 Leonid, (See Mike Anderson's message). We've been using VMIC's dr11 board for about 1-1/2 years now. Other than the screwy BCLR thing, its been great. E-mail me personally if you have any specific questions. Tom Lusco tlusco@aegis.gsfc.nasa.gov NASA/GSFC From ma@tadpole.com Mon Jan 24 07:19:08 1994 From: ma@tadpole.com (Mark Armitage) Date: Mon Jan 24 07:19:32 PST 1994 Subject: Re: Spurious Interrupt: What is it? > Every now and then our development system pops up this message > on the console shell: > > interrupt: > Uninitialized Interrupt! > Vector number 24 (0-255). Spurious Interrupt > Program Counter: 0x0000177a > Status Register: 0x3100 > > What is the significance of Vector Number 24? Thanks in > advance for any insight. The '3' in the status register is the level that the interrupt occurred on. This should let you narrow down what it is that is causing the interrupt. A spurious interrupt is signalled when something asserts an interrupt, but when the CPU get around to fetching the vector number from the interrupting device, nothing responds (ie the CPU gets a Bus error). If you only get the error "every now and again", I assume that it must be working most of the time. My guess would be that this is a VME interrupt, and that a bus arbitration problem is stopping the CPU reading the vector from the interrupting board before it gets bus errored. My other guess is that you are using an Intel 82596 ethernet controller, which has an irritating habit of asserting an interrupt, and then removing it again before you have a chance to serve it (it's more complicated than that, but that's the general idea). Mark Armitage Tadpole Technology Tel: (512) 219 2200 Fax: (512) 219 2222 Email: ma@tadpole.com From ddavies@jaba.sim.es.com Mon Jan 24 07:49:46 1994 From: ddavies@jaba.sim.es.com (Doug Davies) Date: Mon Jan 24 07:49:57 PST 1994 Subject: Re: rshd Mike, I'd be interested in a copy of you HACKED rsh code. Thanks, -Doug -------------------------------------------------------------------------------- Douglas Davies (software engineer) | Evans & Sutherland | "Never underpay your software engineers" INTERNET: ddavies@jaba.sim.es.com | -Jurassic Park Moral From bennett@cs.unc.edu Mon Jan 24 08:30:36 1994 From: Robert Bradley Bennett Date: Mon Jan 24 08:30:45 PST 1994 Subject: Re: Spurious Interrupt: What is it? If you have a bus, in particular a VME bus, double-check the back plane jumpers. I've seen spurious interrupt messages under SUNOS when the Interrupt Ackowledge Daisy chain has been broken by lack of an interrupt jumper. From goodrich@cabernet.gong.noao.edu Mon Jan 24 08:56:55 1994 From: goodrich@cabernet.gong.noao.edu (Bret Goodrich) Date: Mon Jan 24 08:57:10 PST 1994 Subject: Re: rshd we have implemented an rsh daemon for vwWorks that receives standard rsh socket connects from a UNIX client. this software supports our needs for rsh but i won't say it's been tested *extensively*. since there is some interest in rsh daemons in this group i'll send out our implementation. caveat emptor, as always. bret -------------------- Bret Goodrich, National Optical Astronomy Observatories, Tucson, Arizona, USA Usenet: {arizona,decvax,ncar}!noao!goodrich or uunet!noao.edu!goodrich Internet: goodrich@noao.edu SPAN/HEPNET: noao::goodrich Phonenet: 602.322.8522 -----------------------rshd.shar--------------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by cabernet!goodrich on Fri Jul 9 19:00:01 MST 1993 # Contents: rshd.c rshd.h echo x - rshd.c sed 's/^@//' > "rshd.c" <<'@//E*O*F rshd.c//' /* rshd.c - remote shell daemon for WRS VxWorks */ /* * Developed 1993 by the Global Oscillation Network Group (*) * * (*) A project of the National Solar Observatory, which is a division of * the National Optical Astronomy Observatories (NOAO), operated by the * Association of Universities for Research in Astronomy, Inc. (AURA) * under cooperative agreement with the National Science Foundation. */ /* modification history ------------------- 01a,05feb93,bdg created */ /* DESCRIPTION The remote shell daemon processes commands from remote machines that execute the BSD UNIX "rsh" command. All VxWorks shell commands may be executed on a remote host, with appropriate STDOUT and STDERR return messages returned. The daemon is initialized with a call to rshdInit(), which in turn spawns the tRshd task. This task makes a connection on the standard rsh port (514) and waits for communications. A second port is opened for output once the connection has been initiated. The rsh daemon will return an error to the client host if that host is not in the hostLib. NOTES At this point there is no graceful way to quit the rsh daemon. Log messages are not redirected. SEE ALSO remLib (1) AUTHOR @.CS Bret D. Goodrich, Global Oscillation Network Group, National Solar Observatory, National Optical Astronomy Observatories Tucson, Arizona, USA goodrich@noao.edu @.CE */ /* rshd.c 1.1 2/10/93 NOAO" */ #include "vxWorks.h" #include "remLib.h" #include "types.h" #include "socket.h" #include "in.h" #include "ioLib.h" #include "iosLib.h" #include "taskLib.h" #include "ptyDrv.h" #include "logLib.h" #include "errnoLib.h" #include "string.h" #include "sysLib.h" #include "stdlib.h" #include "sockLib.h" #include "shellLib.h" #include "stdioLib.h" #include "hostLib.h" #include "rshd.h" #define RSH_PORT 514 /* shell port number */ #define RSHD_TASK_NAME "tRshd" #define RSHD_TASK_PRI 2 #define RSHD_TASK_OPT (VX_SUPERVISOR_MODE | VX_UNBREAKABLE | VX_STDIO) #define PTY_BUF_SIZE 4096 #define PTY_RSH "/pty/rsh." #define PTY_RSH_MASTER "/pty/rsh.M" #define PTY_RSH_SLAVE "/pty/rsh.S" #define ETX '\001' #define ETX_STRING "\001\0" extern printErr (char *, ...); /******************************************************************************* * rshdInit - initialize remote shell daemon * * This routine initializes the pseudo terminal connection then spawns the * rshd task. It should be executed only once. * * RETURNS * void */ VOID rshdInit (VOID) { /* check for existing rshd task */ if (taskNameToId (RSHD_TASK_NAME) != ERROR) return; /* create pseudo tty pair */ if ((ptyDrv () == ERROR || ptyDevCreate (PTY_RSH, PTY_BUF_SIZE, PTY_BUF_SIZE ) == ERROR) && errnoGet () != S_iosLib_DUPLICATE_DEVICE_NAME) { logMsg ("rshInit: ERROR--unable to create pty device (0x%x)\n", errnoGet ()); return; } if (taskSpawn (RSHD_TASK_NAME, RSHD_TASK_PRI, RSHD_TASK_OPT, 10000, (FUNCPTR) rshd) == ERROR) logMsg ("rshInit: ERROR--unable to spawn rshd (0x%x)\n", errnoGet ()); } /******************************************************************************* * rshd - remote shell daemon * * This is the remote shell daemon. It opens a pseudo terminal to connect to * the VxWorks shell when a command has been accepted on the remote shell port. * The shell is redirected, restarted, and sent a remote command. Output goes * to the remote shell port, then the shell's STDIN, STDOUT, and STDERR are * returned to their previous descriptors. This operation will momentarily * disrupt any activity in the shell, whether on the console port or via * rlogin or telnet. * * RETURNS * ERROR if rshd cannot initialize, otherwise it never returns. */ VOID rshd (VOID) { IMPORT char *shellTaskName; struct sockaddr_in sin, sin2; int sinl; int sd[3]; int slave, master; int shIn, shOut; char shellPrompt[64]; char buf[PTY_BUF_SIZE]; char c; int i, n; int lport; short port; int shellTid; char hostName[MAXHOSTNAMELEN+1]; /* open master (network-side) file */ if ((master = open (PTY_RSH_MASTER, O_RDWR, 0)) == ERROR) { logMsg ("rshd: ERROR--error opening %s (0x%x)\n", PTY_RSH_MASTER, errnoGet ()); return; } /* open slave (shell-side) file */ if ((slave = open (PTY_RSH_SLAVE, O_RDWR, 0)) == ERROR ) { logMsg ("rshd: ERROR--error opening %s (0x%x)\n", PTY_RSH_SLAVE, errnoGet ()); return; } /* Wait for shell to exist */ while ((shellTid = taskNameToId (shellTaskName)) == ERROR ) taskDelay (sysClkRateGet()); /* Open socket and wait for client */ sd[0] = socket (AF_INET, SOCK_STREAM, 0); bzero ((char *) &sin, sinl = sizeof (sin)); sin.sin_family = AF_INET; sin.sin_port = RSH_PORT; if (bind (sd[0], (struct sockaddr *) &sin, sizeof (sin)) == ERROR) { logMsg ("rshd: ERROR--bind failed (0x%x)\n", errnoGet ()); close (master); close (slave); return; } listen (sd[0], 1); /* loop forever waiting for accept */ FOREVER { errnoSet (OK); /* clear errno for pretty i() display */ /* Now accept connection */ bzero ((char *) &sin, sinl = sizeof (sin)); sin.sin_family = AF_INET; sin.sin_port = RSH_PORT; if ((sd[1] = accept (sd[0], (struct sockaddr *) &sin, &sinl)) == ERROR) { logMsg ("rshd: ALERT--accept failed (0x%x)\n", errnoGet()); continue; } /* read the stderr port */ if ((n = read (sd[1], buf, sizeof (buf))) <= 0) { logMsg ("rshd: ALERT--read failed (0x%x)\n", errnoGet()); goto RESET3; } buf[n] = 0; sscanf (buf, "%hd", &port); /* connect the stderr port */ lport = IPPORT_RESERVED - 1; if ((sd[2] = rresvport (&lport)) == ERROR) { logMsg ("rshd: ALERT--rresvport failed (0x%x)\n", errnoGet ()); goto RESET3; } bcopy ((char *) &sin, (char *) &sin2, sinl); sin2.sin_port = port; /* new port number */ if (connect (sd[2], (struct sockaddr *) &sin2, sinl) == ERROR) { logMsg ("rshd: ALERT--connect failed (0x%x)\n", errnoGet ()); goto RESET2; } /* check for valid host name */ if (hostGetByAddr (sin.sin_addr.s_addr, hostName) == ERROR) { sprintf (buf, "rshd: ALERT--Unknown host 0x%08x\n", sin.sin_addr.s_addr); logMsg ("%s", buf); write (sd[2], "\0", 1); write (sd[1], buf, strlen (buf)); goto RESET2; } /* get command from remote host */ /* ignore 2 user names */ for (n = 0; read (sd[1], &buf[n], 1) > 0 && buf[n] != NULL; n++); for (n = 0; read (sd[1], &buf[n], 1) > 0 && buf[n] != NULL; n++); for (n = 0; read (sd[1], &buf[n], 1) > 0 && buf[n] != NULL; n++); buf[n++] = '\n'; buf[n++] = NULL; write (sd[1], "\0", 1); /* protocol bytes */ write (sd[2], "\0", 1); /* save original standard in of shell */ if (!shellLock (TRUE)) { sprintf (buf, "rshd: ALERT--Shell is locked\n"); logMsg ("%s", buf); write (sd[1], buf, strlen (buf)); goto RESET2; } printErr ("\n*** Shell redirected to RSHD ***\n"); shIn = ioGlobalStdGet (STD_IN); shOut = ioGlobalStdGet (STD_OUT); /* Redirect standard in of shell */ shellOrigStdSet (STD_IN, slave); shellOrigStdSet (STD_OUT, slave); /* set options & clear pipe */ ioctl (slave, FIOOPTIONS, (VOID *) OPT_RAW); ioctl (slave, FIOFLUSH, (VOID *) 0); taskRestart (shellTid); /* restart shell */ /* get old prompt, make new one */ n = read (master, shellPrompt, sizeof (shellPrompt)); shellPrompt[n++] = '\0'; shellPromptSet (ETX_STRING); /* send command to shell */ if ((n = write (master, buf, strlen (buf))) == ERROR) { logMsg ("rshd: ALERT--error writing to master (0x%x)\n", errnoGet ()); goto RESET; } /* get response, remove prompt, etc */ for (n = 0; read (master, &buf[n], 1) > 0 && buf[n] != '\r'; n++); for (i = n = 0; read (master, &c, 1) > 0; i++) if (c == '\r') continue; else if (c == ETX) break; else buf[n++] = c; buf[n++] = '\0'; /* send response to stdout socket */ if (write (sd[1], buf, n) == ERROR) logMsg ("rshd: ALERT--error writing to socket (0x%x)\n", errnoGet ()); RESET: /* set shell back to orginal stdin */ (VOID) shellLock (FALSE); shellOrigStdSet (STD_IN, shIn); shellOrigStdSet (STD_OUT, shOut); shellPromptSet (&shellPrompt[2]); printErr ("*** Shell returned to console ***"); (VOID) taskRestart (shellTid); RESET2: close (sd[2]); RESET3: close (sd[1]); } close (sd[0]); } @//E*O*F rshd.c// chmod u=rw,g=rw,o=r rshd.c echo x - rshd.h sed 's/^@//' > "rshd.h" <<'@//E*O*F rshd.h//' /* rshd.h - remote shell daemon include file */ /* Developed 1993 by the National Optical Astronomy Observatories(*) (*) Operated by the Association of Universities for Research in Astronomy, Inc. (AURA) under cooperative agreement with the National Science Foundation. */ /* modification history -------------------- 01a,05feb93,bdg written */ /* rshd.h 1.1 2/10/93 NOAO */ #ifndef INCrshdh #define INCrshdh IMPORT VOID rshdInit (VOID); IMPORT VOID rshd (VOID); #endif /* !INCrshdh */ @//E*O*F rshd.h// chmod u=rw,g=rw,o=r rshd.h exit 0 From rodin33!wgsu13!jdeangcd@uunet.uu.net Mon Jan 24 21:07:32 1994 From: rodin33!wgsu13!jdeangcd@uunet.uu.net (Joe DeAngelo) Date: Mon Jan 24 21:07:41 PST 1994 Subject: Shared Memory Network I am using an MVME147 and a Cyclone i960 card in a VME rack. I am using the shared memory network between them, but the '147 card is a real-time controller which needs real-time access to peripheral devices which are memory mapped into VME address space. We want the 147 card to be the only bus master in order to assure bus access. This requires the shared memory for the network, etc. to be on the cyclone card. We cannot get the sm network to function in this configuration. Has anyone else tried to get this to work? (Anchor, etc. on other than CPU 0)??? This has been called into Wind River, with little response. Joe DeAngelo Kulicke and Soffa Industries deangelo@kns.com From daemon@vxw.ee.lbl.gov Tue Jan 25 04:02:01 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 25 04:02:13 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 25 04:01:44 PST 1994 Subject: SCSI Communication Subject: netDrv, Mil-Std-1553, Sockets, and VxWorks Subject: 1994 June Usenix Call for Papers -- Last Chance ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: SCSI Communication Date: Mon, 24 Jan 1994 17:27:37 GMT From: RRAILEY@relay.nswc.navy.mil (Rene H. Railey) Organization: NSWCDD, Dahlgren, VA 22448 Message-ID: Sender: news@relay.nswc.navy.mil (newserver) I am looking for some help with the initialization of some SCSI devices we are trying to install on our mv167 system with 5.0.3. Seems everyone looks for dos file systems for the norm but my situation calls for Unix type initialization. My configuration consists of two SCSI devices , one an Exabyte model 8505 5GB half high , and the other a CD-ROM device which we have not yet purchased. I am not experienced in device drivers , so any suggestions will come in handy. Thanks in advance. Rene H. Railey Naval Surface Warfare Center Dahlgren Division Code F33 Dahlgren, VA 22448-5000 (703) 663-6276 rrailey@relay.nswc.navy.mil --------------------------- Newsgroups: comp.os.vxworks Subject: netDrv, Mil-Std-1553, Sockets, and VxWorks Date: Tue, 25 Jan 94 00:36:42 GMT From: trimble@titan.rdd.lmsc.lockheed.com (Gary Trimble) Organization: Lockheed Missiles & Space Co., Palo Alto, CA Message-ID: <1994Jan25.003642.3057@enterprise.rdd.lmsc.lockheed.com> Sender: news@enterprise.rdd.lmsc.lockheed.com (News Administrator) Has anyone implemented netDrv to support socket communications using the 1553 bus. Are there any significant limitations or reasons one would not do this? Please reply via email. --------------------------- Newsgroups: news.announce.conferences,comp.os.386bsd,comp.os.linux,comp.unix.bsd,comp.unix.internals,comp.os.mach,comp.os.vxworks,comp.unix.wizards Subject: 1994 June Usenix Call for Papers -- Last Chance Date: 24 Jan 1994 22:22:49 -0500 From: margo@virtual61.harvard.edu (Margo Seltzer) Organization: Aiken Computation Lab, Harvard University Message-ID: <1994Jan25.010724.21117@das.harvard.edu> Sender: barr@pop.psu.edu ANNOUNCEMENT AND CALL FOR SUBMISSIONS USENIX SUMMER 1994 TECHNICAL CONFERENCE June 6-10, 1994 Boston Massachusetts USENIX The UNIX and Advanced Computing Professional and Technical Association IMPORTANT DATES TO REMEMBER DATES FOR REFEREED PAPER SUBMISSIONS Submissions due: January 28, 1994 Authors notified by: February 21, 1994 Camera-ready papers due: April 8, 1994 PRE-REGISTRATION SAVINGS DEADLINE Monday, May 16, 1994 HOTEL DISCOUNT RESERVATION DEADLINE Monday, May 16, 1994 REGISTRATION MATERIALS AVAILABLE mid-March, 1994 CONFERENCE SCHEDULE IN BRIEF Tutorial Program: Monday and Tuesday June 6-7, 1994 Technical Sessions: Wed. through Fri., June 8-10, 1994 Birds-of-a-Feather Sessions: Tues. through Thurs., June 7-9, 1994 USENIX Reception: Thursday evening, June 9, 1994 Vendor Display: Wednesday and Thursday, June 8-9, 1994 Product Demonstrations Wednesday and Thursday, June 8-9, 1994 Come join us in celebrating the 25th anniversary of UNIX! Our emphasis at the USENIX Summer 1994 Technical Conference in Boston is on UNIX in the real world: describe your experiences developing portable applications, running businesses on UNIX, or using UNIX as an educational platform. Share the trials and tribulations of migrating complex applications into a UNIX environment. Describe the network protocols necessary to make the networking superhighway a reality. Or, take a foray into the future of computing: * What to do when your toaster runs UNIX: Does cat still work? * What should we do now to prepare for the 21st century? * Of Mice and Pen: Human-computer interaction * UNIX for the Masses * Terabytes a Day: What's a disk to do? Our traditional focus on UNIX remains, but we also encourage submissions about systems other than UNIX, that have a significant impact on the world of open systems. We are interested in papers describing new and interesting developments in and around open systems, including networking, new languages, tools, and software engineering. As at all USENIX conferences, papers that analyze problem areas and draw important conclusions from practical experience are welcomed. Note that the USENIX conference, like most conferences and journals, requires that papers not be submitted simultaneously to more than one conference or publication and that submitted papers not be previously or subsequently published elsewhere. CONFERENCE PROGRAM COMMITTEE Program Co-Chairs: Margo Seltzer, Harvard University Keith Bostic, University of California, Berkeley Mary Baker, Stanford University John Bongiovanni, Stratus Computer, Inc. Glen Dudek, Object Design, Inc. Peter Honeyman, University of Michigan Michael Jones, Microsoft Research, Microsoft Corporation Kent Peacock, Consultant Rob Pike, AT&T Bell Laboratories Joseph Provino, Sun Select, Inc. Greg Rose, Australian Computing and Communications Institute Win Treese, Massachusetts Institute of Technology Ozan Yigit, York University DATES FOR REFEREED PAPER SUBMISSIONS Submissions due: January 28, 1994 Authors notified by: February 21, 1994 Camera-ready papers due: April 8, 1994 CASH PRIZES Cash prizes will be awarded for the best paper at the conference, the best paper by a full-time student, and the best presentation. HOW TO SUBMIT A REFEREED PAPER It is important that you contact the USENIX Association office to receive detailed guidelines for submitting a paper to the refereed track of the technical sessions; e-mail to summer94authors@usenix.org In addition, enquiries about submissions to the USENIX Summer 1994 Conference may be made by e-mail to margo@usenix.org The schedule for reviewing submissions for the conference is very short, so our preferred submission is an exteded abstract (although we will accept full papers). The object of an extended abstract is to convince the reviewers that a good paper and 25-minute presentation will result. They need to know that authors: * are attacking a significant problem * are familiar with the current literature about the problem * have devised an original or clever solution * if appropriate, have implemented the solution and characterized its performance * have drawn appropriate conclusions about what they have learned The extended abstract should be 5 manuscript pages (single-sided) or less in length. It should represent the paper in "short form." Please include the abstract as it will appear in the final paper. Include references to establish that you are familiar with related work, and, if appropriate, performance data to establish that you have a working implementation and measurement tools. If the full paper has been completed, it may be submitted instead of an extended abstract. Full papers should be limited to 12 single-spaced pages. Every submission should include one additional page containing: * the name of one of the authors, who will act as the contact for the program committee * contact's surface mail address, daytime and evening telephone numbers, e-mail address and (if available) fax number * an indication of which, if any, of the authors are full-time students Authors of accepted submissions will be notified by February 21, 1994. They will promptly receive instructions for preparing camera-ready copy of an 8-12 page final paper, which must be received by April 8, 1994. WHERE TO SEND SUBMISSION Submit one copy of an extended abstract or full paper by January 28, 1994 via AT LEAST TWO of the following methods: * E-mail to summer94papers@usenix.org * FAX to +1-510-548-5738 * Mail to: Summer 1994 USENIX USENIX Association 2560 Ninth St., Suite 215 Berkeley, CA 94710 U.S.A. TUTORIAL PROGRAM On Monday and Tuesday of the conference you can explore topics essential to anyone using or developing UNIX and UNIX-like operating systems, X windows, networks, advanced programming languages, and related technologies. The USENIX Association's well-respected program offers you introductory and advanced, intensive yet practical tutorials. Courses are presented by skilled teachers who are hands-on experts in their topic areas. At Boston, USENIX will offer two full days of tutorials covering topics such as: Introductory and advanced system administration Distributed computing: DCE, DFS, RPC, CORBA Kernel internals: SVR4, Chorus, Windows NT Systems programming tools and program development Systems and network security Portability and Interoperability Client-server application design and development Sendmail and DNS GUI technologies and builders To provide the best possible tutorial slate, USENIX is constantly soliciting proposals for new tutorials. If you are interested in presenting a tutorial, contact the Tutorial Coordinator: Daniel V. Klein +1 (412) 421-2332, E-mail: dvk@usenix.org TECHNICAL SESSIONS The conference technical sessions include one track presentations of papers selected by the Program Committee. These refereed papers are published in the Conference Proceedings, provided free to technical session attendees. A parallel track of Invited Talks complements the refereed paper track. These survey-style or tutorial-type talks by invited experts range over a variety of interesting topics, such as harnessing programming tools, resolving system administration difficulties, or employing specialized applications. Submitted Notes from the Invited Talks are published and distributed free to technical sessions attendees. This second track includes selections from the best presentations offered at recent Symposia. The Invited Talks Coordinators welcome suggestions for topics as well as request proposals for particular Talks. In your proposal, state the main focus, include a brief outline, and be sure to emphasize why your topic is of general interest to our community. Please submit to: Brent Welch, Xerox PARC (1-415-812-4405) and Bob Gray, US WEST Advanced Technologies (1-303-541-6014) or via e-mail to: ITusenix@usenix.org WORK-IN-PROGRESS REPORTS Work-in-Progress Reports, scheduled during the technical sessions, introduce interesting new or ongoing work. The USENIX audience provides valuable discussion and feedback. Do you have interesting work you would like to share, or a cool idea that is not ready to be published? Works In Progress Reports are for you! We are particularly interested in presentation of student work. To schedule your report, contact Peg Schafer via e-mail to wips@usenix.org BIRDS-OF-A-FEATHER SESSIONS The always popular Birds-of-a-Feather sessions (BOFs) are very informal gatherings of persons interested in a particular topic. BOFs often feature presentations or demonstrations followed by discussion, announcements, and the sharing of strategies. BOFs are offered Tuesday, Wednesday, and Thursday evenings of the conference. BOFs may be scheduled at the conference or in advance by telephone to the USENIX Conference Office at 1-714-588-8649 or via e-mail to conference@usenix.org SUMMER 1994 VENDOR DISPLAYS & PRODUCT DEMONSTRATIONS In Boston, vendor representatives will demonstrate the technical innovations which distinguish their products, in scheduled 30-minute product presentations in a theater-style setting. In the USENIX Vendor Display, emphasis is on serious answers from technically savvy vendor representatives. Here, in a relaxed environment, conference attendees can "kick the tires" and be sure the products and services on display really do what they're said to do. Plus, you can review the newest releases from technical publishers. Vendors: this is an exceptional opportunity for receiving feedback on new development from USENIX's technically astute conference attendees. If your company would like to demonstrate or display its products and services, please contact: Peter Mui Telephone 1-510-528-8649 FAX 1-510-548-5738 Email: pmui@usenix.org SPECIAL HOTEL RATES The Boston Marriott Copley Place Hotel is headquarters for the USENIX Summer 1994 Technical Conference and will be the location for all conference activities. The Boston Marriott Copley Place will be offering special room rates to USENIX conference attendees. FOR MORE INFORMATION Materials containing all details of the technical and tutorial program, conference registration, hotel and airline discount and reservation information will be mailed at the end of March 1994. If you wish to receive the registration materials, please contact: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 USA Telephone: 1-714-588-8649 FAX: 1-714-588-9706 E-mail: conference@usenix.org --------------------------- End of New-News digest ********************** From js@rtp.co.uk Tue Jan 25 07:24:38 1994 From: js@rtp.co.uk (Jatinder Sangha) Date: Tue Jan 25 07:24:48 PST 1994 Subject: tar for VxWorks Does anyone out there have a VxWorks version of the UNIX tar program? Or any idea how difficult it would be to port it? Thanks in advance, --Jatinder js@rtp.co.uk From bdoerr@apljax.jhuapl.edu Tue Jan 25 07:56:01 1994 From: bdoerr@apljax.jhuapl.edu (Bryan S. Doerr) Date: Tue Jan 25 07:56:14 PST 1994 Subject: TCP Sockets: Mid-level Flow Desc Req. I'm trying to obtain information on how TCP/IP sockets are implemented in vxworks. Specifically, what kind of copies, buffering, context changes etc occur during the transmission of a data buffer from micro to micro. I'm sure the answer involves knowledge of not only TCP/IP as described in an RFC but also the bp driver used by WRS. Also, didn't WRS incoporate some optimizations between 5.1 and 5.0 ( or was it 5.0 and 4.x). Does BSD "tahoe" release play a part in this question or its answer? The level of detail that I'd like is more than just "you put the data in here and it comes out here", but less than "and then this bit, in this packet is toggled, followed by a 100ms timeout ...). Kind of a Mid-level description. I checked the FAQ for a WRS App Note. Does anybody have any other references. If the BSD socket implementation is still current, I'll read the RFC and a UNIX book for that part of the question. Does anyone have the appropriate RFC number? How about documentation on the bp driver implementation. Regarding the bp driver, I know the very basics like shared memory on proc 0, carved up for each CPU, mailboxes or some other interrupt telling the CPU there is data (or polled). What happens before and after this part is the core of my question. BTW, I'm trying to learn what the user can do to optimize socket operation by making intelligent choices on buffer size, data timeout, etc. I'm hoping this infomation will give me the background that I need. Sorry for the wordy description. Thanks, Bryan From ddowning@well.sf.ca.us Tue Jan 25 09:58:12 1994 From: "Daniel D. Downing" Date: Tue Jan 25 09:58:19 PST 1994 Subject: Re: Modems and/or DES on VME If your volumn is high enough, consider contacting Kodak Berkeley Research @ 510-649-2720. They specialize in Forward Error Correction devices and can also handle crypto. dan From mitchh@hops.gvg.tek.com Tue Jan 25 18:15:57 1994 From: Mitch Hendrickson Date: Tue Jan 25 18:16:07 PST 1994 Subject: Re: RTOS Professional Positions Hi Mike: I was on the original RTOS dist list, and I deleted most of your other recent mail but saved the big second go-round one. From rereading it, it's unclear to me whether I'm automatically still on the list. If not, I would like to be added. You might have me down as mitchh@hops.gvg.tek.com or mitchh@gold.gvg.tek.com, which is the preferred address. Thanks, -Mitch -- Mitch Hendrickson mitchh@gold.gvg.tek.com Grass Valley Group, Inc. (of course I don't speak for them!!) P.O. Box 1114 (M/S N3-2B) also: mitchh@well.sf.ca.us Grass Valley, CA 95945 "Control for smilers can't be bought..." From daemon@vxw.ee.lbl.gov Wed Jan 26 04:01:56 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 26 04:02:06 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 26 04:01:45 PST 1994 Subject: Configuring Gcc to produce VxWorks compatible objects ? Subject: Of interest of VxWorks/MIPS users Subject: Re: SCSI Communication Subject: Re: port of vxWorks to multiple custom boards Subject: Re: Spurious Interrupt: What is it? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Configuring Gcc to produce VxWorks compatible objects ? Date: Tue, 25 Jan 1994 13:21:14 GMT From: heyes@dahp1.cebaf.gov (Graham Heyes) Organization: Continuous Electron Beam Accelerator Facility Message-ID: Sender: usenet@murdoch.acc.Virginia.EDU Someone has asked me how to configure the GNU C compiler to generate VxWorks compatible object code. Sadly I can't remember the answer, something to do with using the configure option for SUN OS or maybe I am totally wrong. Can someone jog my memory? I seem to remember seeing this somewhere here in the past few months. - -- Graham - -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>- Graham Heyes,CEBAF,12000 Jefferson Ave,Newport News,VA 23606,Tel:(804) 249-7030 --------------------------- Newsgroups: comp.os.vxworks Subject: Of interest of VxWorks/MIPS users Date: 25 Jan 1994 23:36:48 GMT From: edmunds@s1.gov (Dave Edmunds) Organization: Lawrence Livermore National Laboratory Message-ID: Followup-To: comp.os.vxworks This is a long post that I think would only be of interest to people running VxWorks on MIPS targets, and in particular ones running it on the MIPS Magnum development platform. After telling us last fall (when we were debating whether to get another year of maintenance on VxWorks) that the release of version 5.1 was going to be "very soon", I came to find out (several months later) that not only was it not going to be very soon, it wasn't going to be at all. Wind River said that MIPS didn't have an ANSI C compiler, and 5.1 couldn't be compiled without one. I called up Silicon Graphics, got put in touch with their MIPS folks, and was told that the current release of their compiler was ANSI, and had been so for quite a while. The compiler that ships with the workstations isn't ANSI, but one can buy one that is. I called Wind River back, and they verified this with MIPS and said they would put it on their work list, but they couldn't say quite when it would be complete yet, and that I should call back in the middle to end of February and that they could give me a date then. In the meantime, WRS has released 5.1.1 in beta for the Sun/MIPS and SGI/MIPS combinations. They suggested I try one of those. Well, I don't have ready access to an SGI machine, and the cross-compiler for the Sun is $5000 for one machine or $15000 for eight. This seems hefty to me for a C compiler in this day and age, but WRS said they just buy it from MIPS. These are my only alternatives at the moment. WRS says they didn't know about the ANSI C compiler because it didn't ship standard with the MIPS systems, and nobody asked if there was another one. They added that they don't like to rely on compilers that cost extra over and above the workstations because the end-users don't like to have to pay more. I can understand that, and suggested to them that they do a port for the GNU C compiler, which will generate R3000 code, as they have done for most of their other targets. Their response, and I would very much like to hear responses from anyone on the Net about this, is that the MIPS community overall felt that the performance of their target machines was very much tied to the excellent performance of the MIPS C compiler, and that they wouldn't consider using the GNU compiler. I said that I would consider it, and that in fact version 2.x of the MIPS compiler was pretty buggy, to the point of generating erroneous code on at least two occasions that I came across in only a few months of using it. WRS said they didn't doubt this, but that the MIPS community's perception is what mattered. I don't know about the quality of the code generated by the GNU compiler (is it really bad?), but does everyone really feel that strongly about the MIPS compiler? I could go on (believe it or not), but I think that's enough for now. I thought this might be of interest to some of the MIPS users out there. - -- Dave Edmunds --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SCSI Communication Date: 26 Jan 94 00:35:33 GMT From: mike@imatron.COM (Mike Morrison[Software Eng]) Organization: Imatron Inc., South San Francisco Message-ID: <360@imatron.COM> References: In article RRAILEY@relay.nswc.navy.mil (Rene H. Railey) writes: >I am looking for some help with the initialization of some SCSI devices we are >trying to install on our mv167 system with 5.0.3. Seems everyone looks for dos >file systems for the norm but my situation calls for Unix type initialization. >My configuration consists of two SCSI devices , one an Exabyte model 8505 5GB >half high , and the other a CD-ROM device which we have not yet purchased. >I am not experienced in device drivers , so any suggestions will come in handy. >Thanks in advance. >Rene H. Railey >Naval Surface Warfare Center >Dahlgren Division Code F33 >Dahlgren, VA 22448-5000 >(703) 663-6276 >rrailey@relay.nswc.navy.mil - - VxWorks doesn't support a unix filesystem, only DOS, RT-11 and RAW. You can use long unix type filenames however. - - What exactly do you mean by initialization of SCSI devices? low level format? writting a file system? - - VxWorks scsi devices get set up in $(VX_VW_BASE)/src/config/usrScsi.c You will probably have to change the arguments to scsiPhysDevCreate to reflect your SCSI ids. - - Feel free to e-mail me any specific questions. I just did this type of stuff on a 167. - -- ******************************************************************** * Michael Morrison mike_morrison@imatron.com * ******************************************************************** --------------------------- Newsgroups: comp.os.vxworks Subject: Re: port of vxWorks to multiple custom boards Date: Wed, 26 Jan 1994 04:44:18 GMT From: tna@ornl.gov (NOELL T E) Organization: Oak Ridge National Laboratory Message-ID: <1994Jan26.044418.22090@ornl.gov> References: <9401111613.AA00377@maureen.VisiCom.COM> FrankVaughn asks: > Question 1: In this case, is it reasonable to maintain the WRS > philosophy of creating one target directory for each board under a > common /config directory? I don't believe that > config/all/usrConfig.c(or the other files in /config/all) will be > similiar at all for the different targets. > > (remainder deleted) > In general, I think the philosophy of a common tree for all BSPs is good, but in practice (at least in the example of 5.1, I haven't switched to 5.1.1 yet), there are some problems. A minor problem: how can a single vw/h/bspVersion.h file keep track of bspVersions for multiple BSPs? Every time you load a BSP, this file gets overwritten. A 3rd party problem: Synergy apparently supplies their own BSP (target = sv4X). When you run their install script, they replace files in config/all, which (I believe) are supposed to remain the same for "all" targets (thus the name?). As a result, after you run their install, the sv4X is the only kernel you can rebuild. Gee, I wonder why :-) If I've missed something (regarding the scope of config/all/* across BSPs, please let me know! BTW, did they fix the bspVersion.h ambiguity in 5.1.1? Regards, Tim noellte@ornl.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Spurious Interrupt: What is it? Date: Wed, 26 Jan 1994 05:50:40 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <9401241519.AA04066@tadpole.tadpole.com> In article <9401241519.AA04066@tadpole.tadpole.com> ma@tadpole.com (Mark Armitage) writes: >> Vector number 24 (0-255). Spurious Interrupt >> Program Counter: 0x0000177a >> Status Register: 0x3100 >> >> What is the significance of Vector Number 24? Thanks in >> advance for any insight. spurious interrupt -- caused when a device does not respond to IACK cycle, typically due to faulty hardware or incorrect PAL's or incorrect software configuration of hardware interrupts. the device should be asserting /avec (if autovector'ed), /sterm, or /dsack (/dtack on 68000) if using external vector'ed devices. in the latter case, your device is prolly not putting out correct vector address. >The '3' in the status register is the level that the interrupt occurred on. the '3' in the above message is S and M bit in SR, not interrupt level mask. it means exception occurred during supervisor mode (vxworks always runs in this mode), and while using SSP (as opposed to ISP). the correct interrupt level encoded is the following nybble -- '1' in 0x3100. hwajin PEACEFUL STAR --------------------------- End of New-News digest ********************** From rayssd!ssd.ray.com!fjr@uunet.uu.net Wed Jan 26 05:30:21 1994 From: "Fred J. Roeber" Date: Wed Jan 26 05:30:31 PST 1994 Subject: Re: Shared Memory Network Joe DeAngelo says: > I am using an MVME147 and a Cyclone i960 card in a VME rack. > I am using the shared memory network between them, but the > '147 card is a real-time controller which needs real-time > access to peripheral devices which are memory mapped into > VME address space. We want the 147 card to be the only bus > master in order to assure bus access. > This requires the shared memory for the network, etc. > to be on the cyclone card. We cannot get the sm network to > function in this configuration. Has anyone else tried to get > this to work? (Anchor, etc. on other than CPU 0)??? > This has been called into Wind River, with little > response. I think you may be approaching the problem wrong Joe. You say your 147 is doing "real time" processing. I assume it is in slot 0 and is acting as the VME bus arbiter. The fact that it's memory is dual ported for backplane communication shouldn't cause problems. I assume that the backplane communications you are worried about are between the 147 and i960. Since there will be backplane traffic for inter CPU messages, you will get better response in the 147 if it is accessing it's own memory rather than trying to get to the i960. The backplane driver uses spin locks for synchronization. Thus, there are loops where the code tries to test and set flags atomically. This will be faster for the 147 if it is going to it's own memory. Rather than relocating the backplane buffers, I would suggest you look into using priority based VME bus arbitration. Put the 147 at the highest level (level 3) and put the i960 at a lower level (e.g. 2). Setting this mode of operation is possible in the config files. You don't mention if there is an ethernet connection too. If there is one being used on the 147 that routes info to the i960 over the backplane then you could have other loading concerns. Other than that, there shouldn't be any real problems with the 147 getting locked out from VME access unless your basic design is overloading the VME bus, throughput wise. Fred | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 177 | | Portsmouth, RI 02871-1087 (401) 842-4205 | | fjr@ssd.ray.com | From tweadon@sadira.gb.nrao.edu Wed Jan 26 07:24:36 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Wed Jan 26 07:24:44 PST 1994 Subject: MV167 and the CD2400 Serial Chip I'm having a problem with the Cirrus CD2400 in an application which is "different" than normal. I'm setting up the chip to run at 57.6k baud async. This chip is the controller on an in-house bus which requires all command bytes to be sent out in even parity and all data bytes to be send out in odd parity. Well, I "hacked" the CD2400Serial.c file to setup the port of interest up to 57.6k baud and I added routines which will allow me to dynamically enable / disable the receiver and change parity (two independent functions). I have been working with Cirrus and they have assured me that my software looks fine. But it doesn't work all the time. The protocol is: I send out 1 sync byte at even parity then 4 data bytes at odd parity. Right after the 2nd data byte is received I get a response from a device acknowledging it is responding to this message. What happens (1 out of probably every 5 to 40 transmissions) is the parity on the CD2400 doesn't seem to change and instead of transmitting 4 data words at odd parity I see (on a logic analyzer) 3 + bytes to 4 + bytes being sent out! In other words, the parity is not only not changed but a byte (11 bits [start, 8 data, parity, 1 stop]) now has 2 or three extra bits! Yes, I have tried putting in delays between setting the parity and transmitting. In addition I do wait till the chip says that the transmitter is empty before I change parity (not just fifo). The MV167 is running at 33MHZ. Has anybody else tried to change parity dynamically with this chip? At what baud rate? What is your experience? I have done the same thing on an MV147 running at 25MHZ (using an external baud rate generator) and it works very well. In fact the exact code runs on the MV147 except the actual "hacked up" chip specific code. (The MV147 uses a 8530.) Thanks for any thoughts. Tim Weadon National Radio Astronomy Observatory (NRAO) (304) 456-2120 tweadon@nrao.edu From lam@csd.nad.northrop.com Wed Jan 26 10:59:27 1994 From: Christine Lam Date: Wed Jan 26 10:59:35 PST 1994 Subject: Re: DR-11 Board & Driver AP Labs has a Asynchronous I/O(AIO) DEvice Driver and it supports the IKON DR11 board. But you have to write your own interface for it. Here is the AP Labs San Diego and Colorado Spring phone numbers (619) 546-8626 and (719) 598-2801. Christine Lam From daemon@vxw.ee.lbl.gov Thu Jan 27 04:02:10 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 27 04:02:23 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 27 04:01:58 PST 1994 Subject: Re: Of interest of VxWorks/MIPS users Subject: Re: port of vxWorks to multiple custom boards Subject: Need Feedback/Opinions on Upgrade? Subject: VxWorks in Space Subject: Re: port of vxWorks to multiple custom boards Subject: Re: port of vxWorks to multiple custom boards Subject: Re: Of interest of VxWorks/MIPS users ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Of interest of VxWorks/MIPS users Date: 26 Jan 94 18:35:09 GMT From: wesw@fog.WV.TEK.COM (Wes Whitnah) Organization: Network Displays Division Message-ID: <4534@shaman.wv.tek.com> References: Reply-To: wesw@orca.WV.TEK.COM Sender: news@shaman.wv.tek.com In article , edmunds@s1.gov (Dave Edmunds) writes: < Many frustrating dealings with MIPS and WRS deleted... > I've been very disappointed in the attitudes of MIPS and WRS regarding compiler and development environments in general, and WRS's approach to supporting MIPS in particular. I've experienced the same things Dave listed in his email. Neither MIPS nor WRS are prompt or forthright in providing (correct) information or support, unless you are willing to pay big bucks up front! This is why we've pretty well gone on our own in our development environment. We've been successfully using GNU C running on Sun workstations and cross-compiling for MIPS for quite some time (going on two years now). While it is true the first versions of GNU C were not as good at optimizing as the MIPS compilers and were a bit buggy, the later versions produced comperable if not better code than MIPS for our code base. The current GNU C version we are using is 2.5.7 . GNU is a strong alternative to MIPS, and much easier to work with. Wes Whitnah Principal Software Engineer Network Displays Division Tektronix, Inc. wesw@orca.wv.tek.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: port of vxWorks to multiple custom boards Date: Wed, 26 Jan 1994 19:59:48 GMT From: geoff@wrs.com (Geoff Espin) Organization: Wind River Systems, Inc. Message-ID: References: <9401111613.AA00377@maureen.VisiCom.COM> <1994Jan26.044418.22090@ornl.gov> Sender: news@wrs.com (News Manager) tna@ornl.gov (NOELL T E) writes: >In general, I think the philosophy of a common tree for all BSPs is >good, but in practice (at least in the example of 5.1, I haven't >switched to 5.1.1 yet), there are some problems. >A minor problem: how can a single vw/h/bspVersion.h file keep track of >bspVersions for multiple BSPs? Every time you load a BSP, this file >gets overwritten. The bspVersion.h (1.0) for 5.1 is, unfortunately, of little practical use. It can't be tweaked on a board by board basis, it more or less stands for the "interface level" which has changed little since 4.0.2 (+mmu support, +generic serial/timer drivers). We have recently started adding to sysLib.c, sysBspRev(), which concatenates the BSP_VERSION (1.0) with a release number (starting now at "/1"). However, usrConfig.c does not know about this routine yet, so it is not called. When the next major release is made, both BSPs and device drivers will have unique version numbers associated with them. >A 3rd party problem: Synergy apparently supplies their own BSP (target = >sv4X). When you run their install script, they replace files in >config/all, which (I believe) are supposed to remain the same for "all" >targets (thus the name?). As a result, after you run their install, >the sv4X is the only kernel you can rebuild. Gee, I wonder why :-) You are correct, this is not the right way, but if you're only using Synergy products then it doesn't matter. The correct way is to fix the MakeSkel/Makefile to redefine: ## alternate file directory CONFIG_ALL = $(VX_BSP_BASE)/config/all/ to be "//" instead of "/all/". I spoke with Synergy and they explained that due to the various changes to WRS sources, that they instruct the developer to clone a new vw tree before installing patches. They weren't aware of this "trick", but there were several other patches they had due to some of the fancy h/w they support. The BSP Port Kit that most 3rd party vendors use does make a lot of suggestions in this area, but often vendors find there still aren't enough "hooks" so such compromises are made. >BTW, did they fix the bspVersion.h ambiguity in 5.1.1? Version 5.1.1 was an OS maintenance release only. No BSP or drivers were included. Geoff (Hardware Interface Technology Group Leader nee BSP&Drivers) - -- Geoff Espin geoff@wrs.com (510)748-4100 Wind River Systems 1010 Atlantic Avenue Alameda CA 94501 - -- Geoff Espin geoff@wrs.com (510)748-4100 Wind River Systems 1010 Atlantic Avenue Alameda CA 94501 --------------------------- Newsgroups: comp.os.vxworks Subject: Need Feedback/Opinions on Upgrade? Date: 26 Jan 1994 14:46:05 -0700 From: rdhunt@unm.edu Organization: University of New Mexico, Albuquerque Message-ID: <2i6oat$gaf@triton.unm.edu> Hi Folks: Well, I'm thinking of upgrading my development environment in a MAJOR way. I realize that I am flying in the face of the "just change one thing at a time" rule but there doesn't seem to be any alternative. I could use a little guidance on what versions of what to use. Does anyone have any opinions on this set of hardware/software ? Host: SUN SPARC10 Host OS: Solaris 2.3 Target: FORCE CPU-30 68030 VME board Target OS: vxWorks version 5.1 Software Tools: GNU Binutils version 1.97.1 ?? ( per the warning from wjasper@tx.ncsu.edu in archive9312) GCC 2.5.7 ???? GAS version ???? BISON version ???? libg++ version ???? gdb version ???? xxgdb version ???? If you have a working development environment with similar hardware and fairly current versions of these tools please let me know what you are using. Also, I'm aware of the stink over RPCGEN and have already built it from the source, so don't bother warning me about that. Thanks in advance. ============================================================================== Jeff Hollowell e-mail: jahollo@sandia.gov Sandia Labs (Sandia is Spanish for watermelon) voice: (505) 844 - 6981 (We're working on the big seedless ones) - ------------------------------------------------------------------------------ "In theory, theory and practice are the same thing" ============================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks in Space Date: 26 Jan 94 12:13:50 -0400 From: cacciaglia@nrlvx1.nrl.navy.mil Organization: NRL SPACE SYSTEMS DIVISION Message-ID: <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil> 1. I am interested in hearing from other users of VxWorks which have or our planning to use in space based applications. In particular error recovery and fault tolerance. 2. With the successful launch of the Deep Space Program Science Experiment (DSPSE) also known as Clementine 1 on Jan. 25, we are using VxWorks on a r3081 IDT processor. 3. The use of VxWorks and the flexibility in development configurations really boost the productivity compared to the normal environments available for spacecraft software development. We were able to use the networking capabilities using SLIP and the Shell vs. using In Circuit Emulators or break/halt/snapshot diagnostic ports. 4. With the flexibility of I/O devices we are able to upload new ecoff object files into a Memory device and then use the standard loadLib routines to use it, instead of the tedious and awkward methods of patch areas. If you wish not to post my email address is: cacciaglia@nrlvax.nrl.navy.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Re: port of vxWorks to multiple custom boards Date: 27 Jan 94 02:18:44 GMT From: wa137@sdcc12.ucsd.edu (john e. clark) Organization: University of California, San Diego Message-ID: <60224@sdcc12.ucsd.edu> References: <9401111613.AA00377@maureen.VisiCom.COM> <1994Jan26.044418.22090@ornl.gov> Sender: news@sdcc12.ucsd.edu In article <1994Jan26.044418.22090@ornl.gov> tna@ornl.gov (NOELL T E) writes: +FrankVaughn asks: + + > Question 1: In this case, is it reasonable to maintain the WRS + > philosophy of creating one target directory for each board under a + > common /config directory? I don't believe that + +In general, I think the philosophy of a common tree for all BSPs is +good, but in practice (at least in the example of 5.1, I haven't +switched to 5.1.1 yet), there are some problems. + +A 3rd party problem: Synergy apparently supplies their own BSP (target = +sv4X). When you run their install script, they replace files in +config/all, which (I believe) are supposed to remain the same for "all" +targets (thus the name?). As a result, after you run their install, +the sv4X is the only kernel you can rebuild. Gee, I wonder why :-) The following remarks refer to WRS BSP 1.0 for vx5.1. It will remain to be seen how these items are delt with in later versions of the BSP kit. Because bootConfig.c only containes WRS BSP provided boot devices, or libXXXXdrv.a only contains drivers found in WRS's BSP's. 3rd parties on the left hind txxxt in regards to inclusion or even pre-sight to inclusion in these important details. Of course, if a board is from Motorola then WRS may dein to do the port "themselves", well, unless you happen to be talking to someone trying to sell you WRS programming support, and then you get the 'Well, WRS does say that, but really...'. But back to the BSP. If one wished to modify some 'driver' and place it in the 'src/drv' level, which seesm according to the hierarchy to be the place, and use the 'driver' makefile skeleton, one is confronted with two problems. One problem is that the libxxxxdrv.a which will eventually be made includes all 'drivers' which happen to 'work correctly' one WRS supported boards, but may not work correctly on other boards. There is no provision to have libxxxxdrv_special.a processed before the libxxxxdrv.a supplied by WRS. So, to the next problem. If a special driver needs to be included in libxxxxxdrv.a then it must have a different name than the so called generic one. And that is the crux of the problem. A Boards Support Package is that set of software modules which CHANGES on a per board basis. In other words WRS libxxxxdrv.a is excluded from the BSP, but in fact is part of those modules which CHANGES from board to board. Other BSP details are there is no provision to version stamp the vendor's BSP modules and the WRS level in 'h/bspVersion.h'. Additionally, the bootConfig.c file contains only ethernet or booting devices which are supported directly by WRS. All other 3rd parties must use a singel defined macro to include their 'one' interface. This means that either the 3rd party make a zillion configurations for each possible interface, or CHANGE the module which CHANGES with the board, namely bootConfig.c In another area WRS fumbled the MakeSkel was that of memory sizes and bases. Again, since WRS does not directly support a dual processor version of vxWorks for the MC68040 processor, the memory base and size parameters are not very will suited for vendor modification. The vxWorks kernel must be compiled individually for each option, since the RAM_... definitions are not only used in the code but used in the link commands to set the base addresses where the final kernel will execute. For single CPU version this is OK. But for the dual processors this means that for what ever partition of the various memory sizes the MakeSkel file needs to be changed for each configured kernel. A simple 'RAM_BASE_ADRS=memBaseAddress', memBaseAddress being a variable which on initialization would contain the base of memory would work except for later on in the resulting 'Makefile.MC...gnu' there is a line '-Ttext $(RAM_LOW_ADRS)', which would fail if the value is not the explicit numerical address. WRS could better define a Board Support Package to be all those files which change on a per vendor basis. The 'config/vendor/boardxxx' hierarchy could be such that all vendors use a 'config/h/xxxx.h' if those files are generic enough or have a 'config/vendor/h/xxxx.h' file which a '-I../h' CFLAGS definition would cause the compiler to search the vendor's 'h' directory first and the subsequent 'h' directories on up the hierarchy. The current one is this: CC_INCLUDE = -I$(UP)/h $(INCLUDE_CC) $(EXTRA_INCLUDE) \ Notice the subtle placement of the EXTRA_INCLUDE after anything else. The $(UP) macro may be useful, but where's any documentation describing that item? For those files which 99% remain the same, '#include "vendor-option.h", for the 1% that varies, or could vary would allow the 'config/all' directory to be truely 'all boards' independent of vendor. Other issues of the vendor support such as SCSI configurations, types of disk drives etc. are also a problem. The vendor is 'stuck' with handling the first call from a customer with a line like 'your vxWorks doesn't work with a MAXTOR xxxYYYzzz'. It is very unsatisfying to either the customer or the vendor to say 'Please refer all vxWorks calls to your vxWorks customer support person'. It gives the customer the impression that he's getting a run-around. Especially when WRS support says, 'that sound like a BSP problem'. The solution for the vendor has been to 'solve' the integration issue on a particular set of hard drives, modify 'usrScsi.c' to match that set or some reasonable subset, and when a customer calls, give explicit instructions on how to integrate a new drive based on experience with some known set of drives. Alternatively, a vendor can pay WRS for inclusion in to the 'big picture', or become so big that WRS offers to do the BSP 'themselves'. - -------------- My personal opinion is that when WRS grew to a point where 'public' was in the near future it's technical support to vendors declined exponentially with the 'size' of the vendor. But in the VME board biz size often changes, so other than Motorola, which can float an operating unit for a while, this year's big VME vendor may be next year's has been. Also, there has been a lemming race for RISC. Of course these chips will be big biz in the future and there will be need to support them. But again, what ever happend to MIPS anyway? And were's an I860 when you need one. So while supporting the new WRS should not disconnect from the past. One way to do this is to be more atuned to the vendors suppling the current set of boards, and not just atuned to the 'mighty mote' or 'the force'. - ---- As a last word, let VRTX be an object lesson in kernel technology vs vendor support, 'uh, yah I'm using VRTX 'cause it's 'fast' and we got all this code, but I'd junk it in a second if there was an alternative'. Some of the features of VRTX support were 'no call backs' to OEM's who didn't seem to have 'the immediate sales numbers'; no-support on the sales pitch, 'we're great and everyone should know that, and if they don't then they're not worth the time' or 'Uh, why should we break our necks installing some XYZ BSP, when we got Mot..' (well the sale was lost 'cause the customer liked XYZ's performance over Mot.. and XYZ had an alternative Real Time Kernel'). - -- John Clark wa137@sdcc12.ucsd.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: port of vxWorks to multiple custom boards Date: Thu, 27 Jan 1994 03:45:20 GMT From: chris@wrs.com (Chris Ford) Organization: Wind River Systems, Inc. Message-ID: References: Sender: news@wrs.com (News Manager) Hello, regarding problems encountered when installing 3rd party BSPs... geoff@wrs.com (Geoff Espin) writes: > tna@ornl.gov (NOELL T E) writes: > > ... When you run their install script, they replace files in > >config/all, which (I believe) are supposed to remain the same for "all" > >targets (thus the name?). As a result, after you run their install, > >the sv4X is the only kernel you can rebuild. Gee, I wonder why :-) > > You are correct, this is not the right way, but if you're only > using [name withheld] products then it doesn't matter. Until recently the configuration policies for 3rd party BSP vendors were ill-defined. At the beginning of 1994, however, Wind River released BSP Porting Kit 1.1 FCS. The documentation element of this product answers questions such as: "Should I modify bspVersion.h?" (Answer: "No"); and "What if the config/all/* files supplied on the VxWorks object tape are not appropriate for my hardware?" (Answered earlier by Geoff Espin). Using BSP Porting Kit 1.1 FCS, developers can create BSPs for VxWorks 5.1.x that will not clobber other BSPs when installed. To be assured that 3rd party VxWorks BSPs meet Wind River standards, insist that their BSPs are validated by Wind River. (BSP validation is a service offered to VxWorks BSP Porting Kit customers). Have fun, - -Chris Ford Wind River Systems Engineering --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Of interest of VxWorks/MIPS users Date: Thu, 27 Jan 1994 05:10:45 GMT From: chris@wrs.com (Chris Ford) Organization: Wind River Systems, Inc. Message-ID: References: <4534@shaman.wv.tek.com> Sender: news@wrs.com (News Manager) Hello again, regarding tools for VxWorks MIPS targets... edmunds@s1.gov (Dave Edmunds) writes: > ... [Wind River] wouldn't consider using the GNU compiler. I said that I > would consider it, and that in fact version 2.x of the MIPS compiler was > pretty buggy ... wesw@orca.wv.tek.com (Wes Whitnah) writes: > I've been very disappointed in the attitudes of MIPS and WRS regarding > compiler and development environments in general, and WRS's approach to > supporting MIPS in particular ... > We've been successfully using GNU C running on Sun workstations and > cross-compiling for MIPS for quite some time (going on two years now) > ... later versions produced comperable if not better code than MIPS for > our code base. The current GNU C version we are using is 2.5.7 . > GNU is a strong alternative to MIPS, and much easier to work with. The customer is always right. Any more calls for a GNU-based MIPS toolchain, or (gulp) my resignation? We're listening, - -Chris Ford Wind River Systems Engineering --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Thu Jan 27 09:27:50 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Thu Jan 27 09:28:04 PST 1994 Subject: Re: GCC MIPS Tool Chain Greetings! Toss my name in in favor of a GCC Sun X MIPS flavor. If the fellow from Tektronix could tell us how he generated the compiler, I think that many of us who are interested in GCC MIPS would applaud. WRS, I, for one, am willing to give up a MIP or two to get a toolchain that is consistent with my i960 and 68k flavors without costing me (and my customers) an arm and a couple of legs. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From visicom!VisiCom.COM!trest@lbl.gov Thu Jan 27 11:36:06 1994 From: Mike Trest Date: Thu Jan 27 11:36:15 PST 1994 Subject: WRS is listening > The customer is always right. ... We're listening, > -Chris Ford ... Wind River Systems Engineering A few voices have expressed grief and frustration at WRS. On some issues there are more than a few voices. Working at VisiCom Laboratories, I hear these voices from our customers. Quite often, I add my own comments and send them to WRS. Most of the time, WRS' time schedules do not match mine, but eventually we find mutual solutions. As both a major consumer of VxWorks and as a Value Added Reseller of WRS products, we are aware of the increasing price sensitivity in the RTOS marketplace. We are also aware of the growing technical awareness of the RTOS customer and their demands for *MORE* in every aspect of hardware and software products. I wish to thank Chris for his personal attention to issues such as this WRS/MIPS/GNU issue. My experiences with Dave, Chris, Goeff, Kent, Mike, Mani, ... (and quite a few others over the years) tell me that there are some real people at WRS who really do care about the future of their product and the customers who use it. I encourage WRS and all of us to keep the messages flowing both privately and publically. It is through this kind of constructive, factual exchange that we all gain a better product and happier customers. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 VisiCom Laboratories Fax: 619 457 0888 10052 Mesa Ridge Court San Diego, CA 92121 ==================================================== From daemon@vxw.ee.lbl.gov Fri Jan 28 04:02:00 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 28 04:02:16 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 28 04:01:49 PST 1994 Subject: Re: FDDI VME Subject: Re: HDLC for VxWorks Subject: Re: VxWorks in Space Subject: Re: GCC MIPS Tool Chain Subject: Re: TCP Sockets: Mid-level Flow Desc Req. ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: FDDI VME Date: Thu, 27 Jan 1994 17:27:02 GMT From: johnb@fc.hp.com (John Barclay) Organization: Hewlett-Packard Fort Collins Site Message-ID: References: <9401052014.AA23613@rad.orincon.com> Sender: news@fc.hp.com (news daemon) Suppliers of FDDI within the HP Complementary Hardware Vendor Program are: Rockwell Networking SBE, Inc. Performance Technologies Inc. Checkout the VITA Directory for VMEbus solutions which the above are. - -- John Barclay Hewlett-Packard Company TN 229-4325 johnb@hpfcjb.fc.hp.com AT&T (303) 229-4325 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: HDLC for VxWorks Date: Thu, 27 Jan 1994 17:31:09 GMT From: johnb@fc.hp.com (John Barclay) Organization: Hewlett-Packard Fort Collins Site Message-ID: References: Sender: news@fc.hp.com (news daemon) You might want to check in with HDLC solution providers to findout what drivers are available. I think VMIC and SBE have HDLC solutions. - -- John Barclay Hewlett-Packard Company TN 229-4325 johnb@hpfcjb.fc.hp.com AT&T (303) 229-4325 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks in Space Date: 27 Jan 1994 18:06 UT From: baalke@kelvin.jpl.nasa.gov (Ron Baalke) Organization: Jet Propulsion Laboratory Message-ID: <27JAN199418065999@kelvin.jpl.nasa.gov> References: <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil> In article <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil>, cacciaglia@nrlvx1.nrl.navy.mil writes... >1. I am interested in hearing from other users of VxWorks which >have or our planning to use in space based applications. In >particular error recovery and fault tolerance. > We are using VxWorks on the Galileo S-Band project. The goal of the project is to maximize the data output from the Galileo spacecraft using its low gain antenna. We use VxWorks to process the signal from Galileo in real-time. This week we had our first real test when we took our system out to Goldstone. We were able to acquire and record the signal from the Voyager 1 and Voyager 2 spacecraft using DSS-13 (a 34 meter antenna). Next week we go back out to Goldstone for our first opportunity with Galileo. ___ _____ ___ /_ /| /____/ \ /_ /| Ron Baalke | baalke@kelvin.jpl.nasa.gov | | | | __ \ /| | | | Jet Propulsion Lab | ___| | | | |__) |/ | | |__ Galileo S-Band | Failure is success if we /___| | | | ___/ | |/__ /| Pasadena, CA 91109 | learn from it. |_____|/ |_|/ |_____|/ | Malcom Forbes --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GCC MIPS Tool Chain Date: Thu, 27 Jan 1994 19:28:27 GMT From: bradley@gaia.den.mmc.com (Jami Bradley) Organization: Martin Marietta Astronautics, Denver Message-ID: References: <9401271728.AA04022@helios> Sender: news@news2.den.mmc.com (News Admin) What, the R3000 is using the MIPS compilers? I am about to get the R3000 development system, and a very important feature of it is my software compatibility with the MV167's, so we can use either board as needed. This will put a big damper on my development effort. I far prefer the GCC toolset for all C/C++ code I write. I would be very interested in any GCC ports to the R3000 as well! Jami Bradley jbradley@den.mmc.com Embedded Flight Systems Software Martin Marietta Corporation --------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP Sockets: Mid-level Flow Desc Req. Date: 27 Jan 1994 23:14:25 GMT From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae) Organization: Silicon Graphics, Inc. Mountain View, CA Message-ID: References: <9401251555.AA14369@apljax.jhuapl.edu> In article <9401251555.AA14369@apljax.jhuapl.edu> bdoerr@apljax.jhuapl.edu (Bryan S. Doerr) writes: > I'm trying to obtain information on how TCP/IP sockets are > implemented in vxworks. Specifically, what kind of copies, buffering, > context changes etc occur during the transmission of a data buffer > from micro to micro. I'm sure the answer involves knowledge of > not only TCP/IP as described in an RFC but also the bp driver used > by WRS. Also, didn't WRS incoporate some optimizations between 5.1 > and 5.0 ( or was it 5.0 and 4.x). Does BSD "tahoe" release play a > part in this question or its answer? vxworks tcp/ip in 5.x is a direct port of bsd tahoe release. the optimizations occurred between 4.x and 5.0 are significant: they include things like addtion of cluster mbuf, optimization of various network drivers to perform buffer-loaning (avoids expensive copying of data), socket level recoding for more efficient user interface, recoding of checksum routines, etc. the buffer-loaning stuff was taken out by wind river since i left due to misunderstanding by other engineers, and i believe they'll be put back in soon, since they provide maximum bang for the buck in the whole optimization scheme. vxworks tcp/ip stuff could use some serious updates and tuning again... but i'm not sure of wrs's plans. > The level of detail that I'd like is more than just "you put the > data in here and it comes out here", but less than "and then this > bit, in this packet is toggled, followed by a 100ms timeout ...). > Kind of a Mid-level description. this kind of information is not readily available. it's prolly only available in source code format. when in doubt read the bsd tahoe code. bulk of the protocol code is essentially the same inside vxworks. alternative is to pay big bucks to get wrs's modified version of network code. if you ask some specific questions on the net, you have a good chance of getting them answered. unfortunately, there is no "cookbook" on this stuff as you might need. > I checked the FAQ for a WRS App Note. Does anybody have any > other references. If the BSD socket implementation is still current, > I'll read the RFC and a UNIX book for that part of the question. Does > anyone have the appropriate RFC number? How about documentation on the > bp driver implementation. Regarding the bp driver, I know the very basics > like shared memory on proc 0, carved up for each CPU, mailboxes or some > other interrupt telling the CPU there is data (or polled). What happens > before and after this part is the core of my question. the socket interface is compatible with almost all other bsd based implementations. some companies ship net2 based tcp/ip sockets, with the new socket address scheme, but all that stuff is essentially done transparently, so it's no problem as long as you recompile for those machines. > BTW, I'm trying to learn what the user can do to optimize socket > operation by making intelligent choices on buffer size, data timeout, > etc. I'm hoping this infomation will give me the background that I > need. Sorry for the wordy description. a reasonable thing to do is to experiment. i have found that experimenting with different buffer sizes can result in widely varied througput measurements. try different ones and find the one that fits your requirement. unless you're willing to modify/enhance vxworks network code, that's probably all you can do to improve your performance. hwajin PEACEFUL STAR --------------------------- End of New-News digest ********************** From WELCH@asd1.jsc.nasa.gov Fri Jan 28 10:47:36 1994 From: WELCH@asd1.jsc.nasa.gov Date: Fri Jan 28 10:47:44 PST 1994 Subject: Re: VxWorks in Space In article <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil>, cacciaglia@nrlvx1.nrl.navy.mil writes... >1. I am interested in hearing from other users of VxWorks which >have or are planning to use in space based applications. In >particular error recovery and fault tolerance. > We will be using VxWorks on the Space Shuttle Mass Memory Unit (MMU) project here at JSC. The redesigned MMU is based on a standard VME architecture using a custom rad-tolerant 68020 based CPU board. We are ready to fabricate the prototype of the CPU board and will be porting VxWorks in the not to distant future. We have taken some pretty intresting approaches to memory scrubing and health monitoring. We have also implemented a "sleep" mode which provides for low power consumption during periods of inactivity. I would be happy to exchange information and experiences. Tim Welch welch@asd1.jsc.nasa.gov Lockheed Engineering & Sciences Co. Houston, Tx.77058 713-333-7769 From lou@nova.arc.nasa.gov Fri Jan 28 12:15:43 1994 From: lou@nova.arc.nasa.gov (Lou's Work) Date: Fri Jan 28 12:15:51 PST 1994 Subject: Error Recovery and Fault Tolerance I am presently working on a large wind-tunnel project and am interested in hearing from other VxWorks users on available algorithms or code concerning error recovery and fault tolerance. I too would be happy to exchange experiences in both VxWorks, SunOS, SGI IRIX, or Unix in general. Did I say both? Oops. Lou Bangert lou@nova.arc.nasa.gov (415) 604-1309 (415) 604-0563 From ioinc.tucson.az.us!sarge%ioinc.UUCP@noao.edu Fri Jan 28 15:38:24 1994 From: sarge@ioinc.tucson.az.us (Tom Sargent) Date: Fri Jan 28 15:38:38 PST 1994 Subject: programming position My company is looking for a programmer with experience in some subset of the following: Unix, VxWorks, pSOS, VRTX, writing hardware diagnostics, networks and telecommunications. We are a small VMEbus board level design and manufacturing company with a site in Tucson, AZ and a site in San Diego, CA. Our products include CPU cards (Motorola family microprocessors and soon PowerPC) with a wide variety daughter card modules which add SCSI, Ethernet, serial, parallel and various custom I/O capabilities to the CPUs. _____________________________________ --- Tom Sargent, Synergy Microsystems/Io, Tucson, AZ From daemon@vxw.ee.lbl.gov Sat Jan 29 04:01:13 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 29 04:01:27 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 29 04:01:03 PST 1994 Subject: Re: WRS is listening Subject: Re: Way to tell time since boot Subject: Re: GCC MIPS Tool Chain Subject: Re: port of vxWorks to multiple custom boards Subject: Re: Spurious Interrupt: What is it? Subject: TCP/IP recovery Subject: vxWorks Shell Metqlanguage availability Subject: Multicast under vxWorks? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: WRS is listening Date: Fri, 28 Jan 1994 16:13:15 GMT From: geger@phantom.den.mmc.com (George Eger (303) 971-6974) Organization: Martin Marietta Astronautics Group Message-ID: <1994Jan28.161315.21494@den.mmc.com> References: <9401271633.AA05298@maureen.VisiCom.COM> Sender: news@den.mmc.com (News Admin) In article <9401271633.AA05298@maureen.VisiCom.COM>, Mike Trest writes: |> |> As both a major consumer of VxWorks and as a Value Added Reseller |> of WRS products, we are aware of the increasing price sensitivity |> in the RTOS marketplace. We are also aware of the growing technical |> awareness of the RTOS customer and their demands for *MORE* in every |> aspect of hardware and software products. |> I recently got some info from DDC-I about a new C++ RTOS that they are introducing. What struck me as very interesting was the pricing. The cost of the development system (sans compiler, they resell the Microtek and don't currently have a GNU option) starts at $5K. For $10K, you get 10 seats. This is reasonable; the run time target licenses are cheap - starting at $50 for onesies going to $15 in volume. Source code for the run time kernel is $15K. If WRS is listening, I think they should consider they might be missing out by charging 10x more for the RTL's. IMHO, I think they'd get a lot more volume with relatively little support cost by expanding the number of targets their kernel is running on with cheaper pricing. GWE ||========================================================================== ||George Eger / geger@den.mmc.com || Voice - (303) - 971 - 6974 || ||Integ. Fault Tolerant Avionics || Fax - (303) - 977 - 1145 || ||Space Launch Systems || MS T320 || ||Martin Marietta Astronautics || 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. || ||========================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Way to tell time since boot Date: 28 Jan 1994 13:32:00 -0500 From: realtime@access2.digex.net (REAL TIME Corporation) Organization: Express Access Online Communications, Greenbelt, MD USA Message-ID: <2ibln0$ja9@access2.digex.net> References: <9401220335.AA04445@marauder.is.ceco.com> In article <9401220335.AA04445@marauder.is.ceco.com>, Kevin R. Rumbaugh wrote: > >I have thought several times that I would like some way to be able >to either query a board or at least figure out from the shell, how >long a board running VxWorks has been 'up'. Has anyone else >thought about this and implemented something along these lines, >particularly for MVME1[46]7's? Does someone know of someway >to extract this information from the 'kernel'? It does not >necessarily have to be time, but simply some indication of >how long it has been since the board was booted. If I could >find someway to get the information it should be relatively >easy to port the rstatd rpc code to send back the data to >a remote requester. Any help would be appreciated. On a 68xxx cpu card you can do the following: 1. Assign one of the interrupt vector spaces to TicksSinceBoot (you may use any other global address which you find appropriate). 2. At boot time, clear that address to zero. 3. Each time the clock interrupts, increment that vector space by 1. hopefully the 32 bit value is long enough to cover more than the time between consecutive boots. If not, then use 2 vectors (64 bits). this will cost you more time on every clock interrupt. 4. Since the vector space is a well known address, any routine can get access to it, and read the value of TicksSinceBoot. I am assuming that you have source for the clock interrupt routine. If you do not have the source for the clock interrupt routine, then replace the clock vector with the address of your own routine and save the original routine address. do step #3 above and then call the original clock interrupt routine (the one that you do not have source for). At the end of that original routine you will have to replace a "return from interrupt" instruction with the "return from subroutine" instruction, since you want to return to *your* modified clock interrupt routine. Naomi Avigdor realtime@access.digex.net --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GCC MIPS Tool Chain Date: 28 Jan 94 19:29:11 GMT From: wesw@fog.WV.TEK.COM (Wes Whitnah) Organization: Network Displays Division Message-ID: <4544@shaman.wv.tek.com> References: <9401271728.AA04022@helios> Reply-To: wesw@orca.WV.TEK.COM Sender: news@shaman.wv.tek.com For those who asked, and those with an interest: GNU fully supported MIPS processors since their 2.0 release, and it is integrated into their current environment. We've found the binaries generated to be comperable to (and sometimes better than) the MIPS compilers for our code. The last time we compared the two was last year, just before we got rid of our last MIPS host. It would be best to compile your code with both compilers and compare the two in size and performance for yourself. Using GNU is not necessarily a piece of cake. You have to build and maintain the whole works on your own. However, I've found it preferable to dealing with MIPS on compiler issues. You will need the following sources, which can be found at most archive sites (we usually get them from prep.ai.mit.edu in the pub/gnu directory): gcc-2.5.8.tar.gz (We are using 2.5.7 with a patch. This version should include the patch, but we haven't tried it.) gas-2.2.tar.gz binutils-2.3.tar.gz gdb-4.11.tar.gz Unpack the whole works and follow the instructions given on configuring for your host and target processors. A few caveats: 1) We first used VxWorks with the TI34020, whose tools only supported COFF output, so we made our own COFF downloader as WRS did not have one at the time (TI tools required preservation of sections that the a.out converter would strip out). When we added MIPS processors we used the native COFF output of their tools as well, and continued this with GNU. I'm unsure of whether WRS now provides a COFF loader or whether they still use an a.out converter. If you don't need the extra sections, then the WRS converter should work fine. I've heard the GNU linker can take MIPS objects and produce a.out directly, but we've not tried it. 2) GNU does not supply (to my knowledge) a soft-float library for MIPS, so if you need one, you'll need to find one elsewhere. 3) We've put a lot of effort into the GNU environment over the years, so I've probably forgotten something else that you need to do which is different from a vanilla WRS VxWorks release. Perhaps now that WRS seems interested, they can help fill in the gaps in a future release ;-). Wes Whitnah wesw@orca.wv.tek.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: port of vxWorks to multiple custom boards Date: 28 Jan 94 21:09:59 GMT From: wa137@sdcc12.ucsd.edu (john e. clark) Organization: University of California, San Diego Message-ID: <60337@sdcc12.ucsd.edu> References: Sender: news@sdcc12.ucsd.edu In article chris@wrs.com (Chris Ford) writes: + +Hello, regarding problems encountered when installing 3rd party BSPs... + +Using BSP Porting Kit 1.1 FCS, developers can create BSPs for VxWorks +5.1.x that will not clobber other BSPs when installed. To be assured +that 3rd party VxWorks BSPs meet Wind River standards, insist that their +BSPs are validated by Wind River. (BSP validation is a service offered +to VxWorks BSP Porting Kit customers). And how much does this 'service' cost? FreeBSD has better 'machine' separation than WRS's Porting Kits. What's more FreeBSD is more likely to have posix compliance if someone bothered to take the time to do so than WRS's kernel may ever have. What's more FreeBSD has identical libc.a compatability than WRS may have at any time. Unix file system? Well, which varient, but again FreeBSD has it now, just a matter of porting it to the WRS environment. What is the point? The point is that as WRS has tightned up on 'free support' for BSP providers, other packages become more attractive in terms of porting. If it is just as much hassle to port a BSD derivative, and get just as much support, ie. none, then other than customers demanding the WRS products, there's no basic reason for choosing WRS product over some other alternative. Customer's of RTOS products can be 'educated' in directions not sympathetic to WRS products just as easily as towards WRS products. At current WRS prices, there are several competitors which can give the same performance, give 'unix file system' support, and have POSIX compliance. Where can WRS make the difference? 1) Has longevity in the market place gives lots of real world experience. 2) Needs current competative pricing on development packages. Everyone knowns that Cygnus is the porting house for the development tools. 3) Needs stand on you head customer support, including BSP providors if they are considered 'customers' (see above quote). 4) Needs to realize that as there are more RTOS customers there are more RTOS providers and the attitude that 'we're the only ones in town' must change. A few years ago the sales pitch of 'we've got libc.a compatibility' may have sold a few, but now that's done by everone. DOS file system??? RT-11??? I've written 2 file system packages for both of these as well. This of course was back in the stone age and the machines were advanced abaci. WRS could possible make use of 'the thundering HURD' file system. But they seem more inclined to tighten up on products than go for the gusto. (Shared memory?? Again present in other RTOS's for several years in one form or another, MMU support, Virtual Memory?? Again these have been found elsewhere). The main reason that many companies do not use the 'free' packages, if they know of them at all, is the cost to port and support. However, WRS has in some cases given less support, in my opinion, than these packages which only have USENET as their support agency. - -- John Clark wa137@sdcc12.ucsd.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Spurious Interrupt: What is it? Date: Thu, 27 Jan 1994 14:12:41 GMT From: edski@phx.mcd.mot.com (Ed Skinner) Organization: Motorola Computer Group, Tempe, Az. Message-ID: <1994Jan27.141241.27336@phx.mcd.mot.com> References: <9401241519.AA04066@tadpole.tadpole.com> Sender: news@phx.mcd.mot.com Spurious Interrupts may also be seen when the hardware is pushed outside the normal bounds of operation, such as when the VMEbus is mega-stressed with work and the MPU is unable to initiate the IACK cycle for an extended period. In such situations, the MPU's request to acquire the bus in order to do the IACK may take too long and an on-board "bus acquisition" timer may pop. Also, in some cases the interrupting device may suffer strange aberrations when its request is not acknowledged for an extended period and, among other things, simply forget that it was requesting an interrupt. A "Spurious Interrupt" is seen in either case by the responding MPU. These situations are outside the bounds of what we would consider normal operation. Unfortunately, contemporary designs with lots of processors and shared RAM makes for very busy busses, and long delays in acquiring the bus are more and more common. In the extreme these cause Bus Errors (68K), Data Access Exceptions (88K), and spurious interrupts, all of which may be due to bus acquisition time-outs, may occur. The telling clue in all cases is that the failing operation "SHOULD" have been successful. That is, the Bus Error or Data Access Exception is to an address that "SHOULD" have be legitimate. The time-out on the IACK is more difficult to detect. Many board designs will "latch" some status about the origin of the exception. In particular a bus-acquisition time- out should be high on the list of "things to check." - -- #include Ed Skinner, Customer Education Services, Motorola Inc., USA(602)438-3956 Internet: edski@phx.mcd.mot.com --------------------------- Newsgroups: comp.os.vxworks Subject: TCP/IP recovery Date: Fri, 28 Jan 1994 22:46:44 GMT From: sterrett@manta.nosc.mil (Anthony E. Sterrett) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Jan28.224644.4292@nosc.mil> Sender: news@nosc.mil Hi y'all I'm work on some client/server routine and my client needs the ability to recover the connection. My approach is first I setsockopt with SO_REUSEADDR so I can reuse the port. Next I close the ofending socket po 1. I setsockopt with SO_REUSEADDR so I can reuse the port. 2. close the socket number . 3. Reopen, rebind. successfully. 4. attempt to reconnect using connect The attempt to connect fails. Does anybody know how to recover the connect. Tony NRaD --------------------------- Newsgroups: comp.os.vxworks Subject: vxWorks Shell Metqlanguage availability Date: Fri, 28 Jan 1994 22:51:33 GMT From: doug@neopath.wa.com (Doug Carlton) Organization: NeoPath Inc. Message-ID: <1994Jan28.225133.4354@neopath.wa.com> Reply-To: doug@neopath.wa.com Sender: news@neopath.wa.com I am interested in finding some third-party tools to help us in testing (V&V) our vxWorks 5.0.2 application. Is there a commercially produced (and tested) version of the public domain vxRsh remote shell execution program? Is there a vxWorks shell metalanguage available? Something like tcl?? Your time and consideration are appreciated. - --- +-------------------------------+--------------------------------------+ | Doug Carlton | If everyone is a victim who are + | doug@neopath.wa.com | the perpetrators????? + | +--------------------------------------+ | (206) 455-5932 |Opinions expressed here are mine alone| +-------------------------------+--------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: Multicast under vxWorks? Date: Thu, 27 Jan 94 22:54:19 GMT From: mcdowell@exlogcorp.exlog.com (Steve McDowell) Organization: Baker Hughes INTEQ, Inc. Message-ID: <1994Jan27.225419.21221@exlog.com> Sender: mcdowell@exlog.com (Steve McDowell) Is anyone aware of any available software to support IP multicast (as described in RFC-1054) under vxWorks? I'm interested in a port for either 5.1 or 5.1.1 on either Force sun[2,3]ce or cpu-30 boards.. Thanks in advance. - -- Steve McDowell Baker Hughes INTEQ, Inc. bzero(brain_buffer, sizeof(brain)); Houston, Texas USA --------------------------- End of New-News digest ********************** From rayssd!ssd.ray.com!fjr@uunet.uu.net Sat Jan 29 22:22:20 1994 From: "Fred J. Roeber" Date: Sat Jan 29 22:22:29 PST 1994 Subject: Re: VxWorks networking Bryn Doehr asked about details on the VxWorks networking and how to improve performance. As Hwa-Jin Bae mentioned, the WRS code is very similar to the standard BSD Tahoe networking code. For insight into how the code works, a good reference is "The Design and Implementation of 4.3BSD UNIX" by Leffler and others. This book is one of the leading references on UNIX design issues. Chapter 11 in particular has a lot of information on the networking implementation. Of course, to get much better throughput out of the networking code, one of the best solutions is to bypass a lot of it by using the raw ethernet input protocol input hook to look at the raw input data. Doing this has been discussed in this forum before in the not to distant past so I won't go into more depth. Fred | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 177 | | Portsmouth, RI 02871-1087 (401) 842-4205 | | fjr@ssd.ray.com | From daemon@vxw.ee.lbl.gov Sun Jan 30 04:01:37 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Jan 30 04:01:45 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jan 30 04:01:28 PST 1994 Subject: Is select () interruptible? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Is select () interruptible? Date: 29 Jan 94 21:07:45 MST From: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) Message-ID: <1994Jan29.210748.27028@hellgate.utah.edu> Reply-To: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) I've set up a loop around a call to select. The last argument to select () is 0 i.e., wait forever. I've also set up an interval timer that is delivering a SIGALRM every 15th of a second. The call to select () never returns. Is this the expected behavior under VxWorks? Under Unix, select () would return EINTR after the SIGALRM was handled. - -- Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge" - Rush --------------------------- End of New-News digest ********************** From leonid@rst.hellnet.org Sun Jan 30 06:40:09 1994 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Sun Jan 30 06:40:20 PST 1994 Subject: Re: Is select () interruptible? Dear fellow networkers, please try to specify your VxWorks version and relevant hardware configuration to avoid ambiguities. >I've also set up an interval timer that is delivering a SIGALRM every >15th of a second. The call to select () never returns. > >Is this the expected behavior under VxWorks? Under Unix, select () >would return EINTR after the SIGALRM was handled. Under VxWorks 5.0.x, signals do not interrupt system calls, including select(). In VxWorks 5.1.x however, this has changed, a signal can happen anytime and will interrupt a system call, be it read() or select(), but the signal handler has to decide how to continue, if the signal handler returns, the task will resume into the system call, i.e. will go on waiting. If that is not desired, the signal handler has to perform a longjmp() to a know point where it will contiue execution abandoning that system call. Please note that select() is implemented with a semaphore, this means that a signal will interrupt a task waiting for a semaphore, or message queue too. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@RST.HellNet.Org From moore@defmacro.cs.utah.edu Sun Jan 30 10:06:24 1994 From: moore@defmacro.cs.utah.edu (Timothy B. Moore) Date: Sun Jan 30 10:06:33 PST 1994 Subject: Re: Is select () interruptible? Thanks. I am using VxWorks 5.1. Your longjmp () solution is what I had determined I needed to do. Tim From daemon@vxw.ee.lbl.gov Mon Jan 31 04:01:47 1994 From: daemon@vxw.ee.lbl.gov Date: Mon Jan 31 04:01:59 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Jan 31 04:01:37 PST 1994 Subject: Re: Is select () interruptible? Subject: Re: WRS is listening Subject: Re: GCC MIPS Tool Chain Subject: Re: Multicast under vxWorks? Subject: Re: TCP/IP recovery Subject: Re: socket ioctl? Subject: Re: Modems and/or DES on VME Subject: Re: port of vxWorks to multiple custom boards ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Is select () interruptible? Date: Mon, 31 Jan 1994 01:37:42 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <1994Jan29.210748.27028@hellgate.utah.edu> In article <1994Jan29.210748.27028@hellgate.utah.edu> moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) writes: > >I've set up a loop around a call to select. The last argument to >select () is 0 i.e., wait forever. > >I've also set up an interval timer that is delivering a SIGALRM every >15th of a second. The call to select () never returns. > >Is this the expected behavior under VxWorks? Under Unix, select () >would return EINTR after the SIGALRM was handled. this is the expected behavior under vxworks and this behavior is not compatible with unix. in general, vxworks signal and system call facilities do not support call restart as in SA_INTERRUPT, SV_INTERRUPT in unix/posix. vxworks does not really use the concept of system calls as in the other operating systems which use trap based system call interface. and although some facilities in vxworks are hacke up to support some support for "restart", almost all system functions are not aware of such facilities. vxworks system calls (functions) are just normal C functions -- think of vxworks as just a glorified C program, where system calls (like select()) are subroutines inside the program (rather than a unix-or-other-realtime-os-like trap-based system calls). hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Re: WRS is listening Date: Mon, 31 Jan 1994 01:45:24 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <9401271633.AA05298@maureen.VisiCom.COM> <1994Jan28.161315.21494@den.mmc.com> In article <1994Jan28.161315.21494@den.mmc.com> geger@phantom.den.mmc.com (George Eger (303) 971-6974) writes: > >If WRS is listening, I think they should consider they might be missing >out by charging 10x more for the RTL's. IMHO, I think they'd get a >lot more volume with relatively little support cost by expanding the number >of targets their kernel is running on with cheaper pricing. > wrs is only able to charge as much as what they charge because there seem to be enough military contractors, large corporations, government subsidized laboratories and eductional institutions with big bucks to spend. it's all economics and matter of momentum. if you can get away with current pricing scheme why bother changing it? in the mean time, there are many other operating systems with similar feature-sets as vxworks selling for much less bucks. i doubt wind river will change their pricing and marketing strategy unless they're forced to do so by competition. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GCC MIPS Tool Chain Date: Mon, 31 Jan 1994 01:47:11 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <9401271728.AA04022@helios> <4544@shaman.wv.tek.com> In article <4544@shaman.wv.tek.com> wesw@orca.WV.TEK.COM writes: > > GNU fully supported MIPS processors since their 2.0 release, and it > is integrated into their current environment. We've found the binaries > generated to be comperable to (and sometimes better than) the MIPS > compilers for our code. The last time we compared the two was last year, > just before we got rid of our last MIPS host. It would be best to compile > your code with both compilers and compare the two in size and performance > for yourself. we all believe this. anything else is just marketing b.s. as they say, wind river "is listening". bravo! --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Multicast under vxWorks? Date: Mon, 31 Jan 1994 01:48:30 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <1994Jan27.225419.21221@exlog.com> In article <1994Jan27.225419.21221@exlog.com> mcdowell@exlogcorp.exlog.com (Steve McDowell) writes: > >Is anyone aware of any available software to support IP multicast >(as described in RFC-1054) under vxWorks? the work involved in supporting this in vxworks is so trivial that it boggles minds to realize that wrs has not done so for the past several years... hopefully they're listening... or better yet doing something about it. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP/IP recovery Date: Mon, 31 Jan 1994 01:49:52 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <1994Jan28.224644.4292@nosc.mil> In article <1994Jan28.224644.4292@nosc.mil> sterrett@manta.nosc.mil (Anthony E. Sterrett) writes: > >My approach is first I setsockopt with SO_REUSEADDR >so I can reuse the port. Next I close the ofending socket po >1. I setsockopt with SO_REUSEADDR so I can reuse the port. >2. close the socket number . >3. Reopen, rebind. successfully. >4. attempt to reconnect using connect > The attempt to connect fails. > make sure the other end is accepting for new connections at this point. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: socket ioctl? Date: Mon, 31 Jan 1994 01:54:23 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <2hlm5j$b9v@mail.fwi.uva.nl> In article <2hlm5j$b9v@mail.fwi.uva.nl> smagt@fwi.uva.nl (Patrick van der Smagt) writes: >HI! > >I'm trying to port my SYSV/BSD socket code to VxWorks. I encountered >a problem with raising signals on socket input, which can be done >using > >#if SYSV > if (ioctl(d_learn_socket, I_SETSIG, S_RDNORM|S_INPUT)) > { > perror("setup_learn ioctl()"); > panic_exit(); > } >#elif BSD > if (fcntl(d_learn_socket, F_SETOWN, getpid()) == -1) > { > perror("fcntl F_SETOWN"); > panic_exit(); > } > if (fcntl(d_learn_socket, F_SETFL, FASYNC) == -1) > { > perror("fcntl F_SETFL"); > panic_exit(); > } >#endif > > >However, VxWorks doesn't know fcntl nor I_SETSIG (I'm running >VxWorks 5.0.2). Is there a solution to this problem? > you can't do this in vxworks 5.0.2, or later releases for that matter.. wind river is hopefully listening and fixing this problem in their future posix-smart releases. in general, in currently released versions of vxworks, doing simple unix compatible things may work for you, but if you start doing tricky things assuming that vxworks is somehow compatible with posix or unix, you're wasting your time. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Modems and/or DES on VME Date: Mon, 31 Jan 1994 01:57:07 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <9401201711.AA01036@helios> In article <9401201711.AA01036@helios> mea@mclean.sparta.com (Mike Anderson) writes: > > On a separate, yet related, topic, does anyone have information of >anyone who has implemented a VME board that supports DES (Data Encryption >Standard) either in hardware? I have software versions of the algorithms, >but was looking for hardware to take the load off my VxWorks systems. if you're not married to VME, you might be able to talk to hybrid networks, inc. in cupertino, california. we implemented a wireless 10mbit/sec RF ethernet emulation in Sbus/SS1, part of which included a DES (and other downloaded encryption) in hardware. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: port of vxWorks to multiple custom boards Date: Mon, 31 Jan 1994 02:29:34 GMT From: hjb@netcom.com (squeedy) Organization: PEACEFUL STAR, Oakland, CA Message-ID: References: <60337@sdcc12.ucsd.edu> In article <60337@sdcc12.ucsd.edu> wa137@sdcc12.ucsd.edu (john e. clark) writes: >In article chris@wrs.com (Chris Ford) writes: >+ >+Hello, regarding problems encountered when installing 3rd party BSPs... >+ >+Using BSP Porting Kit 1.1 FCS, developers can create BSPs for VxWorks >+5.1.x that will not clobber other BSPs when installed. To be assured >+that 3rd party VxWorks BSPs meet Wind River standards, insist that their >+BSPs are validated by Wind River. (BSP validation is a service offered >+to VxWorks BSP Porting Kit customers). > >And how much does this 'service' cost? FreeBSD has better 'machine' >separation than WRS's Porting Kits. What's more FreeBSD is more likely >to have posix compliance if someone bothered to take the time to do >so than WRS's kernel may ever have. What's more FreeBSD has >identical libc.a compatability than WRS may have at any time. > w.r.t cost -- wrs is free to charge as much as they want. market needs to decide if their product is worth it. i personally don't. vxworks is a fun, useful tool, but the price structure is ridiculous. unless you're a big-time government military contractor or rolling in dollar bills, i don't know how you'd justify the cost. the vast majority of the market seems to disagree with me -- they absolutely love it and are willing to pay! w.r.t freebsd -- it's too big for a lot of work vxworks is being used for. it is also not as scalable, has too much unix junk in it, hacked to death by too many ... code quality varies a lot. the h.w. independence layer is no better than vxworks. in some ways vxworks is better. in some ways freebsd wins. but in terms of overall portability vxworks wins hands down. just look at the list of boards and architectures vxworks runs on. it takes a couple of days (max! by a competent programmer) to bring up vxworks on a new board. >Unix file system? Well, which varient, but again FreeBSD has it now, >just a matter of porting it to the WRS environment. > so, go ahead and do it. we'd all be very grateful. >What is the point? The point is that as WRS has tightned up on 'free >support' for BSP providers, other packages become more attractive >in terms of porting. If it is just as much hassle to port a BSD >derivative, and get just as much support, ie. none, then other than >customers demanding the WRS products, there's no basic reason for >choosing WRS product over some other alternative. freebsd and vxworks are very very different beasts. > >Customer's of RTOS products can be 'educated' in directions not >sympathetic to WRS products just as easily as towards WRS products. >At current WRS prices, there are several competitors which can give >the same performance, give 'unix file system' support, and have >POSIX compliance. Where can WRS make the difference? > >1) Has longevity in the market place gives lots of real world >experience. ??? >2) Needs current competative pricing on development packages. Everyone >knowns that Cygnus is the porting house for the development tools. cygnus is kissing up to free software foundation's ass to make profit out of free software phenomena. i have nothing against them, except that they don't seem to be too honest in their business practice -- they distribute their modified versions of gnuware to their customers way in advance than others -- which in my opinion is just a little greedy trick to make money -- instead of putting up the modified code on the ftp sites as soon as they're qualified enough to be released to their customers. if it's all free, why play games? gnu compiler stuff is great -- and by all means use them. but do not pay stupid amount of money. you can always get it running for nothing. if you want to support gnu, give money direct to f.s.f. if you don't support gnu, use their compilers anyway, they're great. > >3) Needs stand on you head customer support, including BSP providors if >they are considered 'customers' (see above quote). > >4) Needs to realize that as there are more RTOS customers there are more RTOS >providers and the attitude that 'we're the only ones in town' must >change. > >A few years ago the sales pitch of 'we've got libc.a compatibility' >may have sold a few, but now that's done by everone. DOS file system??? >RT-11??? I've written 2 file system packages for both of these as well. >This of course was back in the stone age and the machines were advanced >abaci. WRS could possible make use of 'the thundering HURD' file system. >But they seem more inclined to tighten up on products than go for >the gusto. (Shared memory?? Again present in other RTOS's for >several years in one form or another, MMU support, Virtual Memory?? >Again these have been found elsewhere). > if you have these reasons, why use vxworks at all? it puzzles me that people buy vxworks, spend all that money and later complain that it's not like unix... it's just a glorified realtime monitor. it's not unix. do you really want all those features in your embedded system that handled 500 mega bytes of input load per second and has to be "on-time"? it's insane to duplicate unix inside vxworks... why not just use unix for unix's features and use vxworks for what it provides? or better yet, if you like intel architecture use QNX. >The main reason that many companies do not use the 'free' packages, >if they know of them at all, is the cost to port and support. However, >WRS has in some cases given less support, in my opinion, than these >packages which only have USENET as their support agency. > wind river support has gone thru its ups and downs ... more downs recently. they simply do not have enough knowledgable people answering tech support questions... they should go back to rotating development engineers on techsupport duty (as in the good old days). if there was a single most important feature in vxworks in its early days, it was this quality of support. not there any more folks! but your mileage may vary. --------------------------- End of New-News digest ********************** From visicom!VisiCom.COM!trest@lbl.gov Mon Jan 31 07:14:01 1994 From: Mike Trest Date: Mon Jan 31 07:14:10 PST 1994 Subject: RTOS Professional Survey UPDATE "My motivation was, and remains, to raise the level of understanding of the career paths and opportunities available to the experienced RTOS processional." ..mike.. In the first 15 days of the survey, I have received messages from 10 new organizations and 107 individuals. The response from organizations on the previous mailings has been mostly like: "Keep my company's name in your distribution, we are looking for experieced RTOS professionals." >From these comments, I think we are seeing a slight upward trend in positions available (compared with 6 months ago). The need for RTOS Professionals is not shrinking, it is growing! =======================================+++=============================== RECENT COMMENTS RECEIVED: =======================================+++=============================== "There are no changes in the job description I just sent you. I do appreciate what you are doing. . . . "Mike, this is quite a large job that you have carved out here. good luck. I think it will really help in several areas. . . . "Just out of curiosity, why the special interest in these three? Is it personal? Why not, for instance, VRTX, which is more popular than any of these? . . . [Ed. The announcement was sent to: vxwexplo@lbl.gov (VxWorks users) psosuser@isi.com (pSOS users) embed@synchro.com (Embedded Systems users) No particular priority or business interests motivated my exclusion of VRTX only my lack of knowledge about an appropriate EMAIL service method.] . . . "Thanks for the service you provide! I saw your notice via the pSOS mail list. . . . "Please STOP sending the distribution. Thank you. . . . "This support for the profession is very commendable. . . . "Thank you for providing this service at no cost and with no strings attached. I can't imagine how much extra work this must cost you. . . . "We received 3 reponses, of which we interviewed 2 and hired one candidate that you referred to us. [Ed. I only pass along your EMAIL to those who have asked to be put on the distribution list.] =======================================+++=============================== If you want to participate, this is the way I will be working this cycle: =======================================+++=============================== 1. If you employ RTOS professionals in your organization, please EMAIL me a simple description of your organization, your typical RTOS requirements, and how an interested individual may contact you. If you have current needs, please indicate. If you have no current openings, please state "FOR INFORMATION ONLY" somewhere in your message. I encourage organizations to send me an EMAIL even if you do not have any current openings. 2. Ever EMAIL received in response to item 1, will be forwarded on to a distribution list of individuals who express an intrest in hearing about organization who employ RTOS professionals. 3. If any individual wants to be copied on EMAIL received, please send me a message and I will put you on the distribution list. 4. Anyone on the distribution list who wants to contact any of the oragnizations who send me EMAIL must do so directly. 5. I WILL NOT GIVE A COPY OF THE DISTRIBUTION LIST TO ANYONE. Don't even ask. 6. I will provide a moderator/editor service for all messages received. I plan filter out flames and other meaningless messages to keep the distribution list clean. 7. This is not an official function of VisiCom Laboratories, Inc. I am acting as an individual. However, VisiCom may, from time to time, submit its own EMAIL which will, like other organizations will be submitted to the dristribution list. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 VisiCom Laboratories Fax: 619 457 0888 10052 Mesa Ridge Court San Diego, CA 92121 ==================================================== From mea@mclean.sparta.com Mon Jan 31 11:17:14 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Mon Jan 31 11:17:27 PST 1994 Subject: Re: Shared Memory Network Hi Rajesh, Yes, my target is the hkv960. Thanks, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mea@mclean.sparta.com Mon Jan 31 11:52:28 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Mon Jan 31 11:52:45 PST 1994 Subject: Re: Shared Memory Network Hi Folks! Sorry for the mis-posting. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mea@mclean.sparta.com Mon Jan 31 14:02:34 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Mon Jan 31 14:02:43 PST 1994 Subject: Re: shared backplane communications Greetings! > > Help! We are running a sparc 2ce as a slot 0 controller running unix > and an HK-MIPS V3500 in the same chassis running vxWorks. My question is, > how can i signal the sparc from the V3500 that data is available for the > sparc to display? I would also like to perform similar operations from the > unix side to the vxWorks side. Any help with this problem would be greatly > appreciated!! > Well, first you can get the VMEbus support patches from Force for the 2CE. These patches will enable you to receive and generate interrupts via the SPARC over VME. Then you'll have to map some VMEbus physical memory into the SPARC's virtual memory (unless you want to move the data via Ethernet). Once this is done, you'll have to write ISRs for both VxWorks and UNIX to deal with the communications. Pick a couple of interrupt levels (one for the SPARC->HKV3500 and one for the return) and fire away. Be forewarned, however, the bus interface speed of the 2CE is not a stellar performer. I've seen numbers that barely push 3 MBytes per second with more realistic applications in the 1.5 MBytes/sec range. The 3E (?) or the newer SPARC 10 flavor may be a better choice (Force assures me that these boards have a better bus interface). Alternatively, use an SBus-VMEbus adapter with DMA from either Perfomance Tech or Bit-3. Even that route is faster than what I've seen on the 2CE straight to the VME. Hope this helps, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mea@mclean.sparta.com Mon Jan 31 14:34:31 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Mon Jan 31 14:34:40 PST 1994 Subject: Re: Shared Memory Network Greetings! > Submitted-by: rodin33!wgsu13!jdeangcd@uunet.uu.net (Joe DeAngelo) > > > I am using an MVME147 and a Cyclone i960 card in a VME rack. > I am using the shared memory network between them, but the > '147 card is a real-time controller which needs real-time > access to peripheral devices which are memory mapped into > VME address space. We want the 147 card to be the only bus > master in order to assure bus access. > This requires the shared memory for the network, etc. > to be on the cyclone card. We cannot get the sm network to > function in this configuration. Has anyone else tried to get > this to work? (Anchor, etc. on other than CPU 0)??? > This has been called into Wind River, with little > response. > Part of the problem you're seeing is related to the fact that the Cyclone card is based on a "little-endian" i960 whereas the 147 is "big-endian". This means that the byte ordering is completely backwards between the two boards. 0x12345678 from the 147 looks like 0x78563412 from the i960. Now, I thought the Cyclone had a "bp" driver that dealt with the endianness issues so 68ks and i960s could coexist. But, I'm not sure if they have an "sm" driver for 5.1.x flavors though. If Cyclone does have a big-endian "sm" driver, then you might have to either locate the sm backplane on the 147 or on a "neutral" board such as a regular VME memory board. I can't lay my hands on my Cyclone 960 manual presently, but you might want to check yours to see if the VME slave interface is big or little endian. So much for my $.02, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From bwb@one.one.com Mon Jan 31 15:19:12 1994 From: bwb@one.com (Bruce Baker) Date: Mon Jan 31 15:19:24 PST 1994 Subject: X.25 Are there implementations of X.25 in VxWorks? If so, I would appreciate some technical product literature. We are an OSI supplier and run our stack over X.25 in other environments. We received an inquiry about this configuration for our VxWorks OSI product, but aren't familiar with the available X.25 implementations. Thanks. --Bruce ====================================================================== Bruce W. Baker Open Networks Engineering, Inc. (ONE) Voice: (313) 996-9900 777 E. Eisenhower Parkway, Suite 650 FAX: (313) 996-9908 Ann Arbor, MI 48108 Internet: bwb@one.com ====================================================================== From sblachma@aoc.nrao.edu Mon Jan 31 18:24:53 1994 From: Steve Blachman Date: Mon Jan 31 18:25:02 PST 1994 Subject: MVME-147 SCSI problem We are using an MVME-147 computer with a Seagate WREN VII 1Gb disk on the local SCSI bus. Since we added two DAT tape drives, the SCSI drivers occasionally hang forever in sbicProgBytesIn(), polling for a bit to be set in the Western Digital SCSI controller (a bad real-time coding practice IMHP). This hang does not (necessarily) occur on the first write, but may take quite a while to happen. It does not happen (is rare?) when the disk is alone on the SCSI bus. It happens when ANY other device is added to the SCSI, even if it is powered down. We are runing vxWorks 5.1.1, but we do experience this under 5.0.2. We can make it happen more (or less) frequently by swapping 147s. It is also more frequent if our output rate to disk is higher We can write to a DAT tape drive with no problems, but the data rates to DAT are lower, so maybe we just haven't seen it. The problem seems unimpressed by changes in overall SCSI cable length. We think the bus is properly terminated. A quick peek with a scope on the SCSI shows no obvious problems with voltage levels or ringing. Does anyone know if there is a problem with the SCSI port on the 147 or with the WREN VII? I have little experience with SCSI, is SCSI often flakey? Thanks, Steven Blachman From bob@zeus.jupiter.com Mon Jan 31 18:36:52 1994 From: Bob Schulman Date: Mon Jan 31 18:37:08 PST 1994 Subject: Re: GCC MIPS Tool Chain Algorithmics of England sells a GCC-based set of tools which work well for vxWorks cross-development. This set of tools includes a floating point library. They can be reached at dom@algor.co.uk (That's mail to Dominic Sweetman, their President). bob From thor@thor.atd.ucar.edu Mon Jan 31 23:00:20 1994 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Mon Jan 31 23:00:28 PST 1994 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 4020 -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 19170 Apr 1 1993 dirlib01 -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 2453 Mar 10 1993 gcc+68040 -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 12086 Jan 7 14:42 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 -rw-r--r-- 1 thor 10747 Nov 3 11:54 libg++-2.5-src.patch lrwxrwxrwx 1 root 20 Jan 20 07:28 libg++-2.5.1-src.patch -> libg++-2.5-src.patch lrwxrwxrwx 1 root 20 Jan 20 07:28 libg++-2.5.2-src.patch -> libg++-2.5-src.patch -rw-r--r-- 1 thor 1568 Nov 3 11:54 libgcc2-2.5.0.patch -rw-r--r-- 3 thor 1545 Nov 3 11:55 libgcc2-2.5.2.patch lrwxrwxrwx 1 root 19 Jan 20 07:28 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch -rw-r--r-- 3 thor 1545 Nov 3 11:55 libgcc2-2.5.5.patch -rw-r--r-- 3 thor 1545 Nov 3 11:55 libgcc2-2.5.6.patch lrwxrwxrwx 1 root 15 Jan 20 07:28 libio-2.5.1.patch -> libio-2.5.patch lrwxrwxrwx 1 root 15 Jan 20 07:28 libio-2.5.2.patch -> libio-2.5.patch -rw-r--r-- 1 thor 1228 Dec 29 09:51 libio-2.5.patch lrwxrwxrwx 1 root 6 Jan 20 07:28 libx11 -> libX11 -rw-r--r-- 1 thor 3515 Mar 16 1993 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 829713 Dec 17 08:10 ntpv3.1.tar.gz -rw-r----- 1 thor 1010176 Nov 8 13:42 ntpv3.tar.gz -rw-r--r-- 1 thor 1082 Dec 14 09:09 objc.patch -rw-r--r-- 1 thor 19593 Dec 8 10:43 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 Jan 20 07:28 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 Jan 20 07:28 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 41196 Oct 16 1992 stevie01 -rw-r--r-- 1 thor 35279 Oct 16 1992 stevie02 -rw-r--r-- 1 thor 35278 Oct 16 1992 stevie03 -rw-r--r-- 1 thor 35012 Oct 16 1992 stevie04 -rw-r--r-- 1 thor 34502 Oct 16 1992 stevie05 -rw-r--r-- 1 thor 37476 Oct 16 1992 stevie06 -rw-r--r-- 1 thor 30073 Oct 16 1992 stevie07 -rw-r--r-- 1 thor 31562 Oct 16 1992 stevie08 -rw-r--r-- 1 thor 37360 Oct 16 1992 stevie09 -rw-r--r-- 1 thor 20662 Oct 16 1992 stevie10 -rw-r--r-- 1 thor 25717 Oct 16 1992 stevie11 -rw-r--r-- 1 thor 28075 Oct 16 1992 stevie12 -rw-r--r-- 1 thor 31852 Oct 16 1992 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-rw-r-- 1 root 416642 Jan 7 14:41 tclvx7.0v4.tar.gz -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 1992 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 5491 Dec 8 10:40 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