From ntmtv.com!kapoorsx@ntmtv.portal.com Fri Jul 1 01:31:38 1994 From: kapoorsx@ntmtv.com (Sanjay Kapoor) Date: Fri Jul 1 01:31:50 PDT 1994 Subject: a.out to ieee/srec/hp formats I am trying to port VxWorks to a new 68k based hardware board. I'm trying to use an HP emulator to initially debug the VxWorks port. The emulator, however, only understands IEEE and HP executable formats. As far as I can tell though, the 68k cross linker (ld68K) doesn't allow for formats other than a.out to be specified for output. Does anyone know of how to generate executable formats other than a.out either with ld68k or with a conversion utility? Thanks, Sanjay Kapoor kapoorsx@ntmtv.com Norther Telecom Mountain View, CA From daemon@vxw.ee.lbl.gov Fri Jul 1 04:00:31 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jul 1 04:00:43 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jul 1 04:00:18 PDT 1994 Subject: Tool info sought Subject: Re: poking a blocked process Subject: Recommd. for serial mux Subject: Re: HDLC (LAPB) for 68302 Subject: Re: HDLC (LAPB) for 68302 Subject: Job Posting Subject: ifunit 0 Subject: Re: poking a blocked process Subject: PCMCIA driver ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Tool info sought Date: 30 Jun 1994 13:20:18 GMT From: mpd@adc.com (Matthew P. Downs) Organization: ADC Telecommunications Keywords: info Message-ID: <2uugqi$ld4@ingate.adc.com> I was interested in getting some information on development tools such as SES Workbench and other behavioral simulation packages. The environment is HP workstation and 68360 target using possibly VxWorks or pSOS+ (I doubt the pSOS since they are being really hard headed in the licensing area!) Any information (800 numbers, internet addresses, experiences, etc) would be greatly appreciated. Also, comparisons of VxWorks to pSOS+ from those of you that USED them would also be appredciated. Matt - -- =================================================================== Matthew Downs | e-mail: mpd@adc.com ADC Telecommunications | Phone :(612) 946-3707 M.S. 256 | Fax :(612) 946-3499 5950 Clearwater Dr. | Minnetonka, MN 55343 | =================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: Re: poking a blocked process Date: 30 Jun 94 09:31:37 -0400 From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer) Organization: NRL SPACE SYSTEMS DIVISION Message-ID: <1994Jun30.093137.1376@nrlvx1.nrl.navy.mil> References: <1994Jun29.213035.27188@sal.wisc.edu> In article <1994Jun29.213035.27188@sal.wisc.edu>, jwp@bernie.sal.wisc.edu (Jeffrey W Percival) writes: > I have a task that uses select() to block on a bunch of file descriptors, > waiting for data to appear on sockets. How can I unblock this task > when I want to? That is, at some point I'd like the select() to return 0, > at a time of my choosing. Timeouts aren't the way, because I want the > block to remain in effect until a special event happens. > > Are signals the answer? > -- > Jeffrey W Percival (jwp@larry.sal.wisc.edu) (608)262-8686 I was going to propose two things (the other involving selWakeup) but I think this one is better (and it uses your signals idea): install your signal handler, enabled for the SIGALARM or pick one.. create an empty pipe flush and use the pipe as one of the descriptors to read, then to unblock the task, write to the pipe. This requires that the task should know not to do anything with that file descriptor. (or something to this effect). If needed, raise the signal from somewhere. The handler will then write to the pipe. In this way, the pipe could be created and maintained locally on a task-by-task basis. I bet there is a better way as well. Anyone else? - -- Doug Dyer - dyer@alx.sticomet.com | Real-time systems . * //[]// Software Technology, Inc. (STI) | Space flight/ground software ^^ . DC office: (703) 329-9707 | vxWorks BSPs, etc. . --------------------------- Newsgroups: comp.os.vxworks Subject: Recommd. for serial mux Date: Thu, 30 Jun 1994 18:16:47 GMT From: lacy@draper.com (Carl Lacy) Organization: Draper Laboratory Message-ID: <1994Jun30.181647.4365@draper.com> Sender: nntp@draper.com (NNTP Master) We need a recommendation for a serial mux board with a VxWorks driver. but one that can run 76.8 Kbaud (?). (We hadn't heard of this baud rate, but this is military equipment, so who knows ...) Any advice? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: HDLC (LAPB) for 68302 Date: 30 Jun 1994 19:31:18 GMT From: synergy@nic.cerf.net (John E. Clark) Organization: CERFnet Dial n' CERF Customer Message-ID: <2uv6i6$h0b@news.cerf.net> References: <9406270812.AA18031@lepy07> In article <9406270812.AA18031@lepy07> Matthew Pardoe writes: + + +I am currently implementing X.25 LAPB protocol on top of the hdlc controller +of a MC68302 processor. Does anyone out there have source code for LAPB +protocol (VXworks or not) that I can use as a starting point. I don't know how full feature you want LAPB to be, but there are to publicly available LAPB's in conjunction with X.25. At 'ftp.ucsd.edu' in hamradio/packet/tcpip there is the AX.25 implementation. This is 'amatur packet radio''s implimentation of an TCP/IP protocol on top of X.25, the A of AX is in regard to a 'arp' sequence to find a station call sign relative to an IP address. In real X.25 one would have to know the near neighbor station's call sign to connect up a virtual circuit for the X.25/LAPB link. The other LAPB implementation is in the BSD-4.4 distribution. It is limited but may be a start. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: HDLC (LAPB) for 68302 Date: 30 Jun 1994 19:36:32 GMT From: synergy@nic.cerf.net (John E. Clark) Organization: CERFnet Dial n' CERF Customer Message-ID: <2uv6s0$h6o@news.cerf.net> References: <9406270812.AA18031@lepy07> <2uv6i6$h0b@news.cerf.net> In article <2uv6i6$h0b@news.cerf.net> synergy@nic.cerf.net (John E. Clark) writes: +In article <9406270812.AA18031@lepy07> Matthew Pardoe writes: ++ ++ ++I am currently implementing X.25 LAPB protocol on top of the hdlc controller ++of a MC68302 processor. Does anyone out there have source code for LAPB ++protocol (VXworks or not) that I can use as a starting point. + +I don't know how full feature you want LAPB to be, but there are +to publicly available LAPB's in conjunction with X.25. In defiance of usual net protocol, I'll post an adendum. The Motorola builten board does have the rudamentary 68302 sources to set up the chip in an SDLC/HDLC mode available for free. It does not have the full "LAPB" sources, but at least the registers, and dma data structure code will give an example of that level of the problem. Unfortunately, the BBS is not ftp'able, or at least I'm not aware of such. --------------------------- Newsgroups: comp.os.vxworks Subject: Job Posting Date: Thu, 30 Jun 1994 19:14:57 GMT From: maillet@wrs.com (Al Maillet) Organization: Wind River Systems, Inc. Message-ID: Hi All, As a favor to one of our resellers I am posting a job listing for Alliant Techsystems. If you are interested please contact them directly. --------------------------------------------------------------------- Advanced Technology Center (ATC), a division of Alliant Techsystems, Inc. in San Diego is looking for a Software Engineer to join their team of professionals specializing in Research and Development, Field Operations and Underwater Acoustics. SOFTWARE ENGINEER BS/MS Computer Science or Engineering. 5+ years UNIX and C real-time programming and 1+ years with vxWorks is required. Real-time data acquisition, interfaces to external devices and networking are also required. Experience writing vxWorks device drivers is a plus. If you meet the requirements listed above and are interested in joining the Alliant Techsystems' team, please email your resume to: human_res@atcwest.com or mail your resume to: Alliant Techsystems, ATC/West - Human Resources, 8080 Dagget Street, San Diego, CA 92111. U.S. Citizenship is required. An Equal Opportunity Employer M/F/D - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Al Maillet Wind River Systems Inc. 8910 University Center Lane Phone: (619)597-2477 --------------------------- Newsgroups: comp.os.vxworks Subject: ifunit 0 Date: Thu, 30 Jun 1994 20:28:17 GMT From: geger@starfire.den.mmc.com (George Eger (303) 971-6974) Organization: Martin Marietta Astronautics Group Message-ID: <1994Jun30.202817.3719@den.mmc.com> Sender: news@den.mmc.com (News Admin) I'm trying to make use of the onboard ethernet interface on various single board computers. Is it safe to assume the first struct ifnet is the onboard interface (if the board has one). Anybody have any better suggestions as to how to detect whether there is an onboard I/F and get the pointer to its ifnet structure? TIA, 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: poking a blocked process Date: Thu, 30 Jun 1994 21:18:09 GMT From: davem@micom.com (David Monachello) Organization: Micom Communications Corp. Message-ID: <1994Jun30.211809.25381@micom.com> References: <1994Jun29.213035.27188@sal.wisc.edu> Jeffrey W Percival (jwp@bernie.sal.wisc.edu) wrote: : I have a task that uses select() to block on a bunch of file descriptors, : waiting for data to appear on sockets. How can I unblock this task : when I want to? That is, at some point I'd like the select() to return 0, : at a time of my choosing. Timeouts aren't the way, because I want the : block to remain in effect until a special event happens. : Are signals the answer? : -- : Jeffrey W Percival (jwp@larry.sal.wisc.edu) (608)262-8686 hi, I've written a little pseudo device driver which sole purpose is to allow some non vxworks device event to trigger the vxworks select call. The fd returned from opening this device is one of the fd's passed to select. When the trigger event occurs selWakeupAll is called to tell select its ready. This will cause select to not return zero but through the normal mask testing you can determine if this was a trigger caused by the pseudo-device. Hope this helps. I can provide more details if you want them. later, dave - -- ************************************************** * Dave Monachello @ Micom Communications Corp. * * email: davem@micom.com * --------------------------- Newsgroups: comp.os.vxworks Subject: PCMCIA driver Date: Thu, 30 Jun 1994 19:50:37 GMT From: kit@abbott.sandiegoca.ncr.com (Kit Chow) Organization: NCR LCPD San Diego Keywords: VxWorks, PCMCIA Message-ID: Sender: news@lcpd2.SanDiegoCA.NCR.COM (News Administrator) Does anyone out there have or know of a PCMCIA driver for VxWorks on the 80x86? Thanks Kit Chow 619-485-2292 --------------------------- End of New-News digest ********************** From btansill@netcom.com Fri Jul 1 15:17:15 1994 From: btansill@netcom.com (Sequent Associates) Date: Fri Jul 1 15:17:24 PDT 1994 Subject: Contract opening A fantastic opportunity exists at a unique south bay (Silicon Valley) company. They are looking for a software engineer with VxWorks experience to add application features and make changes to the existing software on a medical system prior to it's U.S. release. Candidates must have: 1) Strong realtime application development w/VxWorks 2) C 3) Sun This is a 2-4 month contract Pay rate: to $45/hr W-2 Immediate start. For more information either email me btansill@netcom.com or call/fax me at Sequent Associates (408) 436-0111 (408) 436-1842 fax From 100067.355@compuserve.com Fri Jul 1 23:16:35 1994 From: Phil Weber <100067.355@compuserve.com> Date: Fri Jul 1 23:16:43 PDT 1994 Subject: Re: CPUs comparison question Michael, My company, Themis Computer, is one of the major suppliers of SPARC-based VMEbus solutions. Listed here are results of some comparative benchmarks conducted under VxWorks by independant companies who involved our SPARC products like the SPARC 2SE (SPARC 2), the SPARC LXE (microSPARC) and the SPARC 10HS (HyperSPARC), together with a well-known 68040 based board from another vendor. This will help you to evaluate the realistic performance ratio between these processors. About development tools, they will be similar for all supported processors, because VxWorks philosophy is to use a standard workstation for cross-development, whatever the target. SPARC has the advantage of offering the same hardware platform for development and target systems : all SPARC boards listed below can be used for development under SunOS/Solaris as well. Moreover, the same chassis can contain both development and target boards, with possibly, TCP/IP communication via VMEbus backplane. Don't hesitate to contact me directly for further information. BENCHMARKS ========== 1) Bench 1 is a large program integrating various integer and floating point calculation. Given figures are execution times. 68040 at 25 MHz : 430 SPARC 2SE at 40 MHz : 243 SPARC 10HS at 66 MHz : 90 2) Multiply (unsigned integer) : 68040 at 25 MHz : 7826 SPARC LXE at 40 Mhz : 4759 SPARC 2SE at 40 MHz : 4663 SPARC 10HS at 66 MHz : 2847 3) Multiply (Double precision): 68040 at 25 MHz : 4659 SPARC LXE at 40 Mhz : 2763 SPARC 2SE at 40 MHz : 2377 SPARC 10HS at 66 MHz : 625 4) CPU-intensive integer test (manipulation of large bit arrays) 68040 at 25 MHz : 323 SPARC LXE at 40 Mhz : 149 SPARC 2SE at 40 MHz : 120 ************************************* * Philippe WEBER * * Product Marketing Manager * * THEMIS COMPUTER * * 1, rue des Essarts * * 38610 GIERES, FRANCE * * Voice : +33 76596046 * * Fax : +33 76630030 * * E-mail: 100067.355@CompuServe.com * ************************************* From daemon@vxw.ee.lbl.gov Sat Jul 2 04:00:27 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jul 2 04:00:35 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jul 2 04:00:14 PDT 1994 Subject: NEED Intephase 5211 FDDI driver! ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: NEED Intephase 5211 FDDI driver! Date: Fri, 1 Jul 1994 16:05:02 GMT From: vr2a@fulton.seas.Virginia.EDU (Vikram Rana) Organization: uva Message-ID: Sender: usenet@murdoch.acc.Virginia.EDU I am looking for stand alone source code that can be compiled and downloaded to a 68040 board that is host to a 5211 Interphase FDDI card. We are NOT running VXworks or any other commercial OS, but rather an embedded control system with a custom executive(OS). The code should be able to boot the 5211 and establish a communication session between two FDDI nodes. Thanks! Vikram Rana Dept of EE UVa email:vr2a@virginia.edu --------------------------- End of New-News digest ********************** From vdbent@rulrol.leidenuniv.nl Mon Jul 4 03:23:49 1994 From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent) Date: Mon Jul 4 03:23:59 PDT 1994 Subject: I'm looking for a new job (in The Netherlands) Hi there, Currently I'm working for an institute whose main business is *not* building real-time systems. It is my wish to use/extend my experience in the field, in a professional (non-military) company. Below you find what I've done the past 4 years (brief descriptions): - Build and maintained several versions of a scientific instrument control system consisting of 3 SBCs in a VMEbus rack running VxWorks. - Maintained the VMEbus/VxWorks system. Porting BSPs and installing new versions of VxWorks. - Designed a digital data generators and written compilers for it running on a Sun SPARCstation. - Written technical and user documentation. And here's a brief list of used tools/techniques: - VxWorks (4.0.2 - 5.1): C, TCP/IP sockets, lex & yacc, SCSI, RPC, ... - SunOS (4.1.3: C, lex & yacc, make, TCP/IP sockets, RPC, ... - Workview: Actel FPGA design - FrameMaker (3.1 and 4.0) Finally I gained some knowledge/experience on: - VxMP - SW Design methodologies: Ward/Mellor (SADT), Hatley/Pirbhai (SA/RT), and Coad/Yourdon (OOA) - Xlib - C++ If you're interested, you can reach me at the following addresses: - Home: Kees van der Bent, B.Sc. Oude Vest 157 2312 XW Leiden The Netherlands +31-71-121555 - E-mail: vdbent@rulrol.LeidenUniv.nl Sincerely, Kees van der Bent Please forward this message to persons that ... Thanks! ================================================================================ From rhin!joergb@lbl.gov Tue Jul 5 02:17:56 1994 From: rhin!joergb@lbl.gov Date: Tue Jul 5 02:18:05 PDT 1994 Subject: Drivers for IP Greetings, I`m looking for drivers for the following IP-modules. IP-PC-Card from Greenspring or TIP-870 from TEWS IP-ADIO from Greenspring IP-68322 from Greenspring. Has anybody drivers for these modules and what are the costs ? Any information would be appreciated. Thanks Joerg Bertholdt, FAE Wind River Systems GmbH Freisinger Strasse 34 85737 ISMANING GERMANY +49 89 96 09 49 49 phone +49 89 96 09 49 40 fax Email: joergb@wrsec.fr From rhin!chrism@lbl.gov Tue Jul 5 04:47:54 1994 From: rhin!chrism@lbl.gov Date: Tue Jul 5 04:48:02 PDT 1994 Subject: Re: a.out to ieee/srec/hp formats Hi World, there is a new product of WRS, that deals with that. That means it is an integrated HP Emulator Software Package of Wind River, which includes also an a.out to IEEE converter. The VxGDB is extended to deal with emulator commands etc. For a data sheet or additional information, please contact your local sales office or in USA 800-447-3282. Best regards Christoph Marscholik, FAE Wind River Systems GmbH Freisinger Strasse 34 85737 ISMANING GERMANY +49 89 96 09 49 43 phone +49 89 96 09 49 40 fax +49 161 28 32 114 car phone Email: chrism@wrsec.fr ______________________ end of message __________________________________________ From atl@adaclabs.com Tue Jul 5 08:28:28 1994 From: atl@adaclabs.com (Anthony Le) Date: Tue Jul 5 08:34:51 PDT 1994 Subject: Why MVME-147 does not access A24/D16 address space? Doen anyone know why MVME-147 (68030CPU) does not access A24/D16 external VME address space? Am I missing something? Does VxWorks miss something? According to the VME memory map, address A24/D16 is in range 0xF0000000-0xF0FFFFFFF. When I use command "-> m 0xF0000000", there is no external bus activity. However, if I use the "m" command to access A32/D32 space (->m 0xE00000000), I am able to capture the bus activity by the logic analyzer (VMETRO). I am currently use VxWorks 5.1. Note that I also use VME147_BUG to access A24/D16 and the result is fine (VME bus cycle is normal). Thank you. Anthony Le -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- Anthony T. Le _/_/ _/_/_/_/_/ _/ Sr. Software Engineer _/ _/ _/ _/ ADAC LABS Inc. _/_/_/ _/ _/ 540 Alder Dr. _/ _/ _/ _/ Milpitas, CA 95035 _/ _/ _/ _/_/_/_/ e-mail: atl@adaclabs.com phone: (408)321-9100 x1667 -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- From jmarc@wrsec.fr Tue Jul 5 10:07:42 1994 From: jmarc@wrsec.fr (Jmarc Jean-marc DeMaraumont) Date: Tue Jul 5 10:07:50 PDT 1994 Subject: mv147 and A24/D16 > > Submitted-by atl@adaclabs.com Tue Jul 5 08:28:28 1994 > Submitted-by: atl@adaclabs.com (Anthony Le) > > Subject: Why MVME-147 does not access A24/D16 address space? > > Doen anyone know why MVME-147 (68030CPU) does not access A24/D16 > external VME address space? Am I missing something? Does VxWorks > miss something? > > According to the VME memory map, address A24/D16 is in range > 0xF0000000-0xF0FFFFFFF. When I use command "-> m 0xF0000000", > there is no external bus activity. However, if I use the "m" command > to access A32/D32 space (->m 0xE00000000), I am able to capture the > bus activity by the logic analyzer (VMETRO). > > I am currently use VxWorks 5.1. Note that I also use VME147_BUG to > access A24/D16 and the result is fine (VME bus cycle is normal). > > The window for A24 VME accesses is not defined by default in the sysPhysMemDesc structure (in sysLib.c). Try to add the following in that structure: { (void *) 0xf0000000, (void *) 0xf0000000, 0x1000000, /* 16 Mbytes */ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, This should do it (don't forget to remake the vxWorks image). Regards, Jean-Marc ***************************************************************** * Jean-Marc de Maraumont email : jmarc@wrsec.fr * * WIND RIVER SYSTEM EUROPE tel : 33 1 69 07 78 78 * * 27 Avenue de la baltique-lp739 fax : 33 1 69 07 08 26 * * ZAC de Courtaboeuf * * 91962 LES ULIS cedex * ***************************************************************** From mickel@wrsec.fr Tue Jul 5 10:19:20 1994 From: mickel@wrsec.fr Date: Tue Jul 5 10:19:28 PDT 1994 Subject: Re: Why MVME-147 does not access A24/D16 address space? Anthony Le writes: >Doen anyone know why MVME-147 (68030CPU) does not access A24/D16 >external VME address space? Am I missing something? Does VxWorks >miss something? > >According to the VME memory map, address A24/D16 is in range >0xF0000000-0xF0FFFFFFF. When I use command "-> m 0xF0000000", >there is no external bus activity. However, if I use the "m" command >to access A32/D32 space (->m 0xE00000000), I am able to capture the >bus activity by the logic analyzer (VMETRO). > Do you mean that there is literally NO bus activitiy, or that there is no A24 activity? I recently run into a similar problem with an older revision mv147, which generated A32 instead of A24 in the range 0xf0000000... There is a VME control register on the mv147 - don't recall its name but it is at address 0xfffe2005 - that can be used to force A24 VME accesses. By setting this register to 0xc2 instead of the default 0xc0 I was able to force A24 accesses. Best regards, Mikael Liden WRS Scandinavia tel: +46 - 8 707 32 20 fax: +46 - 8 777 30 49 From greg@eng.nmr.varian.com Tue Jul 5 10:42:16 1994 From: greg@eng.nmr.varian.com (Greg Brissey x6951) Date: Tue Jul 5 10:42:26 PDT 1994 Anthony T. Le (atl@adaclabs.com) writes: : Does anyone know why MVME-147 (68030CPU) does not access A24/D16 : external VME address space? Am I missing something? Does VxWorks : miss something?: ..... You need to program the MMU on the MVME-147 IN sysLib.c look for PHYS_MEM_DESC sysPhysMemDesc [] = just follow the style and add your address space you wich to access E.G. /* My Board Address */ { (void *) (0x90000000), (void *) (0x90000000), 0x1000000, /* 16 Mbytes */ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, /* My Memory vme */ { (void *) (0xA0000000), (void *) (0xA0000000), 0x1000000, /* 16 Mbytes */ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, /* rom */ { (void *) ROM_BASE_ADRS, (void *) ROM_BASE_ADRS, ROM_SIZE, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE_NOT | VM_STATE_CACHEABLE_NOT }, I hope this helps. Greg Brissey Varian Palo Alto, CA 94304 E-mail: greg.brissey@nmr.varian.com From pardo@sun-valley.stanford.edu Tue Jul 5 12:37:43 1994 From: pardo@sun-valley.stanford.edu (Gerardo Pardo-Castellote) Date: Tue Jul 5 12:37:50 PDT 1994 Subject: Re: Why MVME-147 does not access A24/D16 address space? > According to the VME memory map, address A24/D16 is in range > 0xF0000000-0xF0FFFFFFF. When I use command "-> m 0xF0000000", > there is no external bus activity. However, if I use the "m" command > to access A32/D32 space (->m 0xE00000000), I am able to capture the > bus activity by the logic analyzer (VMETRO). This isn't correct. In the mv147, the VME master only drives a A24/D16 cycle if either the address is below 0x1000000 (16MB) or else if the Master Configuration Register is programmed to "always" use A24/D16. By default, the Master Configuration Register isn't programmed to do this so that anything between 0x1000000 and 0xffff0000 will be accesed in A32/D32 mode. To program the Master Configuration Register to use A24/D16 (this is what we do for our systems without a P2 backplane), replace the appropriate lines in sysHwInit() in the sysLib.c file with the following and rebuild your kernel. #ifdef P2_BACKPLANE *LCSR_MASTER_CONF = MASTER_CONF_MASD32 | MASTER_CONF_MASA32; /* simple A32 D32 master */ #else *LCSR_MASTER_CONF = MASTER_CONF_MASD16 | MASTER_CONF_MASA24; /* simple A24 D16 master */ #endif BTW. I have never needed to modify sysPhysMemDesc[] to get A24/D16 to work. Gerardo. ------------------------------------------------------------------- Gerardo Pardo-Castellote [ pardo@sun-valley.stanford.edu ] Aerospace Robotics Laboratory [ (415) 723-3677 ] ---- From atl@adaclabs.com Tue Jul 5 13:22:23 1994 From: atl@adaclabs.com (Anthony Le) Date: Tue Jul 5 13:22:31 PDT 1994 Subject: THANK YOU. MVME-147 is able to access A24/D16 address. I just want to thank all people who reponsed to A24/D16 address problem. Specially many thanks to these people: ----------------------------------- ----------------------------------- -> Paul Pearson, -> Mike Morrison, -> Mikael Liden, -> Greg Brissey, -> and vxWorks support's Joel Lutzker. ----------------------------------- ----------------------------------- ***ALL ANSWERS ARE CORRECTED!!!! This is the code I have added to sysLib.c .. PHYS_MEM_DESC sysPhysMemDesc [] { ....... /* VMEbus A24/D16 memory space */ { (void *) (0xF0000000), (void *) (0xF0000000), 0x1000000, /* 16 Mbytes */ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, ....... }; -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- Anthony T. Le _/_/ _/_/_/_/_/ _/ Sr. Software Engineer _/ _/ _/ _/ ADAC LABS Inc. _/_/_/ _/ _/ 540 Alder Dr. _/ _/ _/ _/ Milpitas, CA 95035 _/ _/ _/ _/_/_/_/ e-mail: atl@adaclabs.com phone: (408)321-9100 x1667 -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- From mad@strata.com Tue Jul 5 15:48:19 1994 From: mad@strata.com (Madhu R. Grandhi) Date: Tue Jul 5 15:48:26 PDT 1994 Subject: Intermitent racer-x boot hangups We are trying to load a kernel with IP stack on racer-x from LSI 33020 processor The booting is normal 30% of the time, totally hangs up 25% of the time 45% of the time, the boot is slow (takes 1 -2 minutes). When loading a file of size 80 kbytes the VxWorks totally hangsup. Hangup implies, absolutely no response, only a hard reset works at this point. Has any of you experienced this problem? I would appreciate your input very much. Thanks, Madhu & shinn From micf@lannet.com Wed Jul 6 05:17:18 1994 From: micf@lannet.com (Michael Feldman) Date: Wed Jul 6 05:17:26 PDT 1994 Subject: CPUs comparison thanks I'd like to thank all who responded to my mail about "CPUs comparison", especially Doug Dyer, Gary M. Trimble, R. Clegg PE, Phil Ekins, George Eger, Paul Harvey, Phil Weber and Cheryl Schiltz. The information I've received is very useful. ------------------------------------------------------------------------------ Feldman Michael email: micf@lannet.com Lannet Data Communications Ltd. Fax: 972-3-6487146 Atidim Technology Park, Bldg. 3 Tel: 972-3-6458469 Tel Aviv 61131, Israel ------------------------------------------------------------------------------ From steele@telerobotics.jpl.nasa.gov Wed Jul 6 07:07:42 1994 From: steele@telerobotics.jpl.nasa.gov (Rob Steele) Date: Wed Jul 6 07:07:50 PDT 1994 Subject: 5211 FDDI Driver Request I had trouble sending e-mail to Vikram Rana concerning his request for a 5211 driver. Could Vikram send his e-mail address to me. Rob Steele e-mail: steele@telerobotics.jpl.nasa.gov From atl@adaclabs.com Wed Jul 6 08:13:57 1994 From: atl@adaclabs.com (Anthony Le) Date: Wed Jul 6 08:14:06 PDT 1994 Subject: R Intermitent racer-x boot hangups FROM MESSAGE: >>We are trying to load a kernel with IP stack on racer-x from LSI 33020 processor >>The booting is normal 30% of the time, totally hangs up 25% of the time >>45% of the time, the boot is slow (takes 1 -2 minutes). >> >>When loading a file of size 80 kbytes the VxWorks totally hangsup. >>Hangup implies, absolutely no response, only a hard reset works at this point. >>Has any of you experienced this problem? I would appreciate your input very >>much. >>Thanks, Madhu & shinn I had experienced this problem before. What I found is sometime if the SBC was located far from the HOST. What I means "far" is there are many nodes between my CPU (SBC) and the HOST. If the network is so heavy traffic this also causes the boot fail and slow. I make an experience by config the system stand alone just only the HOST(SUN) and SBC and disconnect from the company central network. Then the problem disappears. -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- Anthony T. Le _/_/ _/_/_/_/_/ _/ Sr. Software Engineer _/ _/ _/ _/ ADAC LABS Inc. _/_/_/ _/ _/ 540 Alder Dr. _/ _/ _/ _/ Milpitas, CA 95035 _/ _/ _/ _/_/_/_/ e-mail: atl@adaclabs.com phone: (408)321-9100 x1667 -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- From plucknet@tesla.elen.ssd.fsi.com Wed Jul 6 11:52:56 1994 From: dev1!plucknet@tesla.elen.ssd.fsi.com (Jim Plucknett) Date: Wed Jul 6 11:53:04 PDT 1994 Subject: [-r] gnu behavior I realize this may be a gnu working group topic, but after talking with WRS I thought I'd start here and see what happens. We recently aquired a msdos port of gnu (gcc,as,ld,etc.) to use on a field support laptop, in leau of a Spark-book :-( gcc is at version 2.5H, as & ld are at 2.2 (BFD 2.2) This new linker/bfd [-r] output is generating the following vxWorks error when loaded : adLib error: attempt to relocate non-long address at 0xf5a31f, code = 0. The source responsible is any switch statement with more than 3 cases (which results in a jump table from the assembler). Eliminate the switch() and it loads fine. I expect the problem is in the bfd port or some ld option is missing. Apparently the supplier of the port doesn't have a vxWorks target to test this on. Does anyone have any suggestions how to troubleshoot this? Any help would be appreciated. ==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- * Jim Plucknett | FlightSafety International * plucknet@tesla.elen.ssd.fsi.com | Simulation Systems Division * || sim_eng@netcom.com | 2700 N. Hemlock Cr. * Phone: (918) 251-0500 x529 | Broken Arrow, OK 74012 ==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- From del@rst.com Wed Jul 6 15:17:11 1994 From: del@rst.com (Mark Del Giorno) Date: Wed Jul 6 15:17:20 PDT 1994 Subject: MVME162 IP Module Access Heyyyyyyyyyyyyyyy, I'd like to get some pointers on how anyone out there has (successfully) set up the IPIC chip on the Motorola MVME 162 board. I've got an IP-a module mapped to 0x01000000 by initializing the IPIC registers as follows: 0xfffbc004 = 0x01 0xfffbc005 = 0x00 0xfffbc018 = 0x55 I get inconsistent results - sometimes I can correctly access the IP module at 0x01000000, and sometimes I get a bus error. I've tried mapping the IPIC to different addresses (like the non-decoded space at 0xffe80000), but I get a bus error *every* time when I try to access that - this probably has something to do with how the MMU is being initialized by my BSP (which I will have to try and tackle at a later time). I'd appreciate any help anyone can pass along - Thanks in advance. (P.S. I know there are people out there looking for drivers for IP modules - I've written one for the Greenspring IP Octal that has been working well for the last couple years. Just ask and you shall receive....) _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com) _/ _/ _/ _/ (410) 876-9200 Fax: 876-9470 _/_/_/_/ _/_/_/_/ _/ Robotic Systems Technology _/ _/ _/ _/ 1110 Business Parkway South _/ _/ _/_/_/_/ _/ Westminster, MD 21157 From kfir@sparc1a.indigo.co.il Thu Jul 7 01:45:24 1994 From: kfir@sparc1a.indigo.co.il (Yuval Kfir) Date: Thu Jul 7 01:45:39 PDT 1994 Subject: Avoiding __main in cross-compile to VxWorks (on m68k) [This was also posted to gnu.gcc.help, but a colleague suggested I also mail it here. Please mail responses directly to me, as I am not subscribed to this list. Thank you.] I am using gcc-2.5.7, configured with: --host=sparc-sun-solaris2.3 --target=m68k-sun-sunos4.1 I use this to build an object file for VxWorks 5.0.2b. After I assemble the object file, I perform a trial link with vxWorks.st to verify that all external functions are present. I get the following: /sw/m68k-sun-sunos4.1/bin/ld -o dummy.e68 machine.e68 vxWorks.st machine.e68(.text+0xb0): undefined reference to `__main' I've tried looking at the info. It says something about INIT_SECTION_ASM_OP which is related to __main, but I haven't been able to figure it out -- looks to me like it's talking about C++ rather than C. We're using plain C. What can I do to avoid `__main'? Or can I perhaps define a dummy __main() routine (or is that _main()?) to silence the linker? TIA! -- Yuval Kfir, Indigo Ltd., Israel (NOT an official spokesperson) kfiry@Indigo.co.il "My opinions may change but not the fact that I am right." PLEASE mail me if you know the source of my .sig quote... I don't! From AMMGR@msgate.emis.hac.com Thu Jul 7 02:40:56 1994 From: "Message Router Submi" Date: Thu Jul 7 02:41:08 PDT 1994 Subject: Status of : [-r] gnu behavior ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : [-r] gnu behavior To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 02:36:51.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 03:15:58 1994 From: "Message Router Submi" Date: Thu Jul 7 03:16:10 PDT 1994 Subject: Status of : NOTE 07/07/94 01:12:00 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : NOTE 07/07/94 01:12:00 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 03:11:23.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 03:28:56 1994 From: "Message Router Submi" Date: Thu Jul 7 03:29:11 PDT 1994 Subject: Status of : MVME162 IP Module Access ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : MVME162 IP Module Access To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 03:24:28.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From daemon@vxw.ee.lbl.gov Thu Jul 7 04:00:26 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jul 7 04:00:41 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jul 7 04:00:15 PDT 1994 Subject: National Inst 1014D/VME support code? Subject: Re: Non-tty checkStack()? Subject: Re: What's the minimum set of files needed from GNU Toolkit? Subject: Re: Non-tty checkStack()? Subject: Re: CPUs comparison thanks Subject: tclTCP Subject: Non-tty checkStack()? Subject: vxWorks Contract Position Subject: Memory leak in TCL Subject: Re: MVME162 IP Module Access Subject: Re: a.out to ieee/srec/hp formats ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: National Inst 1014D/VME support code? Date: 6 Jul 1994 10:11:17 -0500 From: irwin@sugar.NeoSoft.COM (Bob Irwin) Organization: Realtime Systems / SW Houston Message-ID: <2vehil$970@sugar.NeoSoft.COM> Help. Am using the National 1014D (VME) boards (2) in a vxWorks environment as gpib DEVICES [The system controller is external to the VME box]. Have modified the ESP488 software 'package' from National to support interrupts and DMA on the mv167 under vxWorks 5.1. A sample 'ibic' script running on the mv167 'timesout' on the last ibwrt.: ibonl 1 ibpad 1 ibwrt "fubar" ibrd 50 ibwrt "bufar,again" A c task doing the same sequence fails in the same fashion. BTW, a PC also running ibic is the system controller for this test and does the corresponding writes and reads to support the above sequence. A note at the front of the esp488_master.c file says that the 1014 board can only be used as a system controller, but We need it to be a device on the gpib bus. Anyone have success using the 1014 as a device? Suggestions? Condolences? Thank you. R L Bob Irwin / Realtime Systems / Houston irwin@neosoft.com - -- R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 80% of life is just showing up. - Woody Allen --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Non-tty checkStack()? Date: Wed, 6 Jul 1994 16:16:23 GMT From: ericr@vcd.hp.com (Eric Ross) Organization: Hewlett-Packard VCD Message-ID: References: Sender: news@vcd.hp.com (News user) I have had two responses already from Georg Feil and Matt Singer. Georg suggested redirecting stdout. Good idea, except in my case there is no file system. (He did mention that it was a kludge) Matt mentioned that the sources are in usrLib.c. I will create a new function based on checkStack that will do what I want to do. Thank you both. - -- Eric Ross, WB7SDE | Hewlett-Packard Company, VPR ericr@vcd.hp.com | Vancouver, WA, USA In government circles when it's all said and done, more gets said than done. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: What's the minimum set of files needed from GNU Toolkit? Date: Tue, 5 Jul 1994 17:36:40 GMT From: markf@wrs.com (Mark Fox) Organization: Wind River Systems, Inc. Message-ID: References: Sender: news@wrs.com (News Manager) Mat Ramey writes: >I'm installing the VxWorks GNU Toolkit on a Sun4 and in the interest of saving >disk space, would like to install only the minimum set of files. For instance, >can I get by with only installing the sun4.68k directory and not worry about >the src directory and other host-specific directories? What are the >ramifications if I don't install the src directory? Everything you need to do Sun-4 (SunOS 4) x 68k cross-development is in the sun4.68k directory. If you're not using the other hosts included on the Sun tape (Sun-3, Sun-4 Solaris 2), you don't need the corresponding directories (sun3.68k, solaris.68k). Also, you don't need the src directory if you're not planning to work with the source to the GNU tools. Mark Fox Wind River Systems --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Non-tty checkStack()? Date: 6 Jul 94 11:41:33 -0400 From: cacciaglia@nrlvx1.nrl.navy.mil Organization: NRL SPACE SYSTEMS DIVISION Message-ID: <1994Jul6.114133.1383@nrlvx1.nrl.navy.mil> References: In article , ericr@vcd.hp.com (Eric Ross) writes: > Is there a way to do the same thing as checkStack() without having > a console attached to your target. Ideally, I would like the function > to return a data structure that would contain the same information as > is printed to the console. My only other plan of attack is to have > each task probe its own stack and stuff the result into some global > memory. > The routine checkStack is in the source code usrLib.c in the 'all' folder. You should be able to make your own function that meets your requirements from this. David J. Cacciaglia aka Chico Software Technology Inc --------------------------- Newsgroups: comp.os.vxworks Subject: Re: CPUs comparison thanks Date: 6 Jul 1994 15:45:42 GMT From: mann@austin.wireline.slb.com (Dave Mann) Organization: Schlumberger Austin Systems Center Message-ID: <2vejj6$l3i@maggie.austin.wireline.slb.com> References: <9407061222.AA05389@zoo.lannet.com> Sender: mann@cedrick (Dave Mann) Could anyone comment on how the Interdc intel processors compare? Thanks, David p.s. ignore the Interdc (it was a typo) --------------------------- Newsgroups: comp.os.vxworks Subject: tclTCP Date: 6 Jul 1994 22:15:39 GMT From: cgonter@inept.stanford.edu Organization: Elvis+, Ltd. Message-ID: <2vfaeb$j05@nntp2.Stanford.EDU> Has anyone gotten tclTCP to compile. I have seen bugs (features) that declare socket structures two different way. So far I have nearly compiled it under Solaris 2.3. It was that compiler that found the type discrepancies. The only thing left is to fix the library stuff. On the vxworks side there are different type bugs in simple and simpleEvent.c. I did a major hack on the makefile for the vxworks system. Any ideas out there? craig cgonter@inept.stanford.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Non-tty checkStack()? Date: Tue, 5 Jul 1994 23:37:16 GMT From: ericr@vcd.hp.com (Eric Ross) Organization: Hewlett-Packard VCD Message-ID: Sender: news@vcd.hp.com (News user) Is there a way to do the same thing as checkStack() without having a console attached to your target. Ideally, I would like the function to return a data structure that would contain the same information as is printed to the console. My only other plan of attack is to have each task probe its own stack and stuff the result into some global memory. Thanks in advance. - -- Eric Ross, WB7SDE | Hewlett-Packard Company, VPR ericr@vcd.hp.com | Vancouver, WA, USA --------------------------- Newsgroups: ba.jobs.offered,comp.os.vxworks Subject: vxWorks Contract Position Date: 25 Jun 1994 01:48:36 GMT From: nam@peregrine.esl.com (Nam N. Nguyen) Organization: Cornell Theory Center Message-ID: <2ug2dk$c4l@gatekeeper.esl.com> I am looking for a contract/permanent software engineer (see below) who is strong with vxWorks, have been and is now capable of writing drivers with minimal supervision and training. The work must be done at our site. Initial contract for 3 months. Possible conversion to full time, permanent position after that (based mostly on performance). Rate: DOE ($40 - $60++ per hour) Length: 3 months (contract) When: ASAP Location: Sunnyvale, CA Qualifications: vxWorks, SunOS (must) vxWorks drivers (must) audio, video (big plus) self-starter Contact Nam Nguyen at: (tel) (408) 743-4299 extension 4485 (fax) (408) 743-6425 (email) nam@esl.com (ascii format preferred) Nam Nguyen ESL Inc. nam@esl.com --------------------------- Newsgroups: comp.os.vxworks Subject: Memory leak in TCL Date: 6 Jul 1994 14:11:19 -0700 From: rls@ltis.loral.com (Randy Silagi) Organization: Loral Test And Information Systems Message-ID: I have been using Joe VanAndel's port of TCL 7.0. I have found a memory leak when a procedure is called. I have created some procedures and a script that calls the procedures. Whenever a procedure, that I created, is run I lose 160 bytes of memory. I am running this on a Force '040, with 4 megs. memory, and VxWorks 5.1.1. The number of bytes lost is always 160, it does not depend on the size of the procedure called. I found this problem using memShow. Does anyone have any ideas what is causing this? Has anyone else had this problem? Where can I look to fix this? I do have the source code, but do not have the time to investigate the TCL source code. If someone has already fixed this problem please let me know. +------------------------------------------------------------------+ | Randy Silagi E-Mail: rls@ltis.loral.com | Loral Test & Information Systems | 15378 Avenue of Science Phone: 619-674-5100, X4798 | San Diego, CA 92128-3407 Fax: 619-674-5145 +-------------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MVME162 IP Module Access Date: 7 Jul 1994 03:54:00 GMT From: minyard@crchh7b9 (Corey Minyard) Organization: Bell-Northern Research, Richardson, TX Message-ID: <2vfu8o$nld@crchh327.bnr.ca> References: <9407062151.AA26608@rst.com> Mark Del Giorno (del@rst.com) wrote: : Heyyyyyyyyyyyyyyy, : I'd like to get some pointers on how anyone out there has (successfully) : set up the IPIC chip on the Motorola MVME 162 board. I've got an IP-a : module mapped to 0x01000000 by initializing the IPIC registers : as follows: : 0xfffbc004 = 0x01 : 0xfffbc005 = 0x00 : 0xfffbc018 = 0x55 : I get inconsistent results - sometimes I can correctly access the IP module : at 0x01000000, and sometimes I get a bus error. I don't believe you can map IPAC memory into that location. You have to map it to a non-decoded address. : I've tried mapping the IPIC to different addresses (like the non-decoded : space at 0xffe80000), but I get a bus error *every* time when I try to : access that - this probably has something to do with how the MMU is being : initialized by my BSP (which I will have to try and tackle at a later time). You probably have to add the memory config to you sysLib.c file for the 162. You can't access any memory not in the memory configuration. : I'd appreciate any help anyone can pass along - Thanks in advance. : (P.S. I know there are people out there looking for drivers for IP modules - : I've written one for the Greenspring IP Octal that has been working well : for the last couple years. Just ask and you shall receive....) Put it out on the archive! Corey minyard@bnr.ca : _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com) : _/ _/ _/ _/ (410) 876-9200 Fax: 876-9470 : _/_/_/_/ _/_/_/_/ _/ Robotic Systems Technology : _/ _/ _/ _/ 1110 Business Parkway South : _/ _/ _/_/_/_/ _/ Westminster, MD 21157 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: a.out to ieee/srec/hp formats Date: Wed, 6 Jul 1994 20:58:31 GMT From: markf@wrs.com (Mark Fox) Organization: Wind River Systems, Inc. Message-ID: References: <9407010010.AA14704@jupiter.mtvyp> Sender: news@wrs.com (News Manager) Sanjay Kapoor writes: > I am trying to port VxWorks to a new 68k based hardware board. I'm trying > to use an HP emulator to initially debug the VxWorks port. The emulator, > however, only understands IEEE and HP executable formats. As far as I can > tell though, the 68k cross linker (ld68K) doesn't allow for formats other > than a.out to be specified for output. Does anyone know of how to generate > executable formats other than a.out either with ld68k or with a > conversion utility? Hope this isn't too much of an advertisement, but... We're just now releasing into Beta a package that allows users to integrate the WRS and HP 64700 development environments. This includes an a.out-to-IEEE file format converter, as well as a version of VxGDB capable of connecting to the HP 64700 debug environment. VxGDB shares the emulation session with the HP emulation tools (e.g, the emulator/analyzer interface), so you can use VxGDB concurrently with the HP tools while connected to a single emulator. When connected to the emulator, VxGDB is able to display the status of VxWorks system objects--tasks, semaphores, etc.--so you can, for example, do the equivalent of the VxWorks shell i() command from within VxGDB. This product is the result of a collaborative effort between WRS and HP. Mark Fox Wind River Systems --------------------------- End of New-News digest ********************** From amf@teleop.co.il Thu Jul 7 04:25:09 1994 From: amf@teleop.co.il (Amir Fuhrmann) Date: Thu Jul 7 04:25:28 PDT 1994 Subject: Synchronuous Driver for Z8530 Does anyone know of a public domain driver for using the z8530 chip in shycnhruous mode (SDLC/HDLC). Any help would be appreciated. Amir Fuhrmann HyNET Ltd. Jabotinski 102, P.O.B. 3638, Petah-Tikva 49130, Israel Phone : 972-3-9211423 FAX : 972-3-9211424 Res. : 972-3-6416206 E-mail : amf@teleop.co.il From AMMGR@msgate.emis.hac.com Thu Jul 7 05:43:02 1994 From: "Message Router Submi" Date: Thu Jul 7 05:43:14 PDT 1994 Subject: Status of : comp.os.vxworks newsdigest ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : comp.os.vxworks newsdigest To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 05:38:43.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 05:44:57 1994 From: "Message Router Submi" Date: Thu Jul 7 05:45:07 PDT 1994 Subject: Status of : Status of : MVME162 IP Module Access ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : MVME162 IP Module Access To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 05:40:47.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 05:46:10 1994 From: "Message Router Submi" Date: Thu Jul 7 05:46:25 PDT 1994 Subject: Status of : Synchronuous Driver for Z8530 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Synchronuous Driver for Z8530 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 05:42:07.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 05:46:56 1994 From: "Message Router Submi" Date: Thu Jul 7 05:47:08 PDT 1994 Subject: Status of : Avoiding __main in cross-compile to VxWorks (on ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Avoiding __main in cross-compile to VxWorks (on To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 05:42:45.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 05:47:56 1994 From: "Message Router Submi" Date: Thu Jul 7 05:48:09 PDT 1994 Subject: Status of : Status of : [-r] gnu behavior ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : [-r] gnu behavior To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 05:43:28.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 05:49:02 1994 From: "Message Router Submi" Date: Thu Jul 7 05:49:14 PDT 1994 Subject: Status of : Status of : NOTE 07/07/94 01:12:00 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : NOTE 07/07/94 01:12:00 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 05:44:06.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From phil@naic.edu Thu Jul 7 06:15:56 1994 From: phil@naic.edu (Phil Perillat) Date: Thu Jul 7 06:16:10 PDT 1994 Subject: Re: MVME162 IP Module Access > Submitted-by: del@rst.com (Mark Del Giorno) > > Heyyyyyyyyyyyyyyy, > > I'd like to get some pointers on how anyone out there has (successfully) > set up the IPIC chip on the Motorola MVME 162 board. I've got an IP-a > module mapped to 0x01000000 by initializing the IPIC registers > as follows: > 0xfffbc004 = 0x01 > 0xfffbc005 = 0x00 > 0xfffbc018 = 0x55 > > I get inconsistent results - sometimes I can correctly access the IP module > at 0x01000000, and sometimes I get a bus error. > > I've tried mapping the IPIC to different addresses (like the non-decoded > space at 0xffe80000), but I get a bus error *every* time when I try to > access that - this probably has something to do with how the MMU is being > initialized by my BSP (which I will have to try and tackle at a later time). > > I'd appreciate any help anyone can pass along - Thanks in advance. > > (P.S. I know there are people out there looking for drivers for IP modules - > I've written one for the Greenspring IP Octal that has been working well > for the last couple years. Just ask and you shall receive....) I'm too lazy to walk downstairs and get my mv162 programmers manual to check what i'm about to say but..... I think your problem may be that the vmechip2 has enabled sysMemTop to about 0xefffffff. So you may have two decoders fighting for the local bus address 0x01000000 when you place it on the bus ( from sysLib.c sysHwInit: ------------ #ifdef INCLUDE_VMECHIP2 /* disable VME access to on-board ram and VMEchip slave write posting. * (VME access is later enabled for processor 0 in sysProcNumSet.) * * Set-up VMEbus access as follows: * * SHORT_IO 0xffff0000 - 0xffffffff * STD (A24/D16) 0xf0000000 - 0xf0ffffff * EXT (A32/D32) sysMemTop - 0xefffffff ------------ I've been using 64k for each ip modules memory space and i've been locating it at : ipa 0xffc00000 ipb 0xffc10000 ipc 0xffc20000 ipc 0xffc30000 I added the following to the mmu table /* ip boards for 162 a,b,c,d set to 64k each */ /* ip a*/ { (void *) 0xffc00000, (void *) 0xffc00000, 0x00010000, /* 64kb*/ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, /* ip b*/ { (void *) 0xffc10000, (void *) 0xffc10000, 0x00010000, /* 64kb*/ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, /* ip c*/ { (void *) 0xffc20000, (void *) 0xffc20000, 0x00010000, /* 64kb*/ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, /* ip d*/ { (void *) 0xffc30000, (void *) 0xffc30000, 0x00010000, /* 64kb*/ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, If you want more memory you'll have to adjust the number accordingly (and be sure you don't end up using some already in use locations). You would then have something like: 0xfffbc004 = 0xff 0xfffbc005 = 0xc0 for the memory address control registers for ip-a.... Good luck (and remember i didn't check this in the book....) phil perillat arecibo observatory phil@naic.edu From AMMGR@msgate.emis.hac.com Thu Jul 7 07:10:57 1994 From: "Message Router Submi" Date: Thu Jul 7 07:11:07 PDT 1994 Subject: Status of : Status of : Status of : NOTE 07/07/94 01:12:00 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : NOTE 07/07/94 01:12:00 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 06:57:25.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 07:11:58 1994 From: "Message Router Submi" Date: Thu Jul 7 07:12:15 PDT 1994 Subject: Status of : Status of : Synchronuous Driver for Z8530 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Synchronuous Driver for Z8530 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 06:58:03.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 07:11:58 1994 From: "Message Router Submi" Date: Thu Jul 7 07:12:27 PDT 1994 Subject: Status of : Status of : Avoiding __main in cross-compile to ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Avoiding __main in cross-compile to To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 06:58:58.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 07:13:56 1994 From: "Message Router Submi" Date: Thu Jul 7 07:14:07 PDT 1994 Subject: Status of : Status of : comp.os.vxworks newsdigest ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : comp.os.vxworks newsdigest To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 07:04:35.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 07:15:56 1994 From: "Message Router Submi" Date: Thu Jul 7 07:16:09 PDT 1994 Subject: Status of : Status of : Status of : MVME162 IP Module Access ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : MVME162 IP Module Access To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 07:05:14.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From wfogleso@astro.ge.com Thu Jul 7 07:31:53 1994 From: William G Foglesong Date: Thu Jul 7 07:32:05 PDT 1994 Subject: VX-Windows We are interested in finding users of Visicom's VX-Windows product that would be interested in answering several questions about the ins and outs of using VX-Windows. We are just beginning to set up our system and have some questions about Frame Buffer Drivers, general setup, and compatibility with Solaris built user interfaces. Any lessons learned would also be helpful... Our basic system: VXWorks 5.1.1 Force 3CE Sparc CPU Card Vigra VS12 Frame Buffer VX-Windows 2.0 If you would be willing to help, please reply to wfogleso@astro.ge.com Thanks! From AMMGR@msgate.emis.hac.com Thu Jul 7 07:31:56 1994 From: "Message Router Submi" Date: Thu Jul 7 07:32:17 PDT 1994 Subject: Status of : Status of : Status of : [-r] gnu behavior ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : [-r] gnu behavior To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 07:21:24.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 08:18:01 1994 From: "Message Router Submi" Date: Thu Jul 7 08:18:12 PDT 1994 Subject: Status of : Re: MVME162 IP Module Access ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Re: MVME162 IP Module Access To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 07:55:51.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From interactive.com!scott@indev.portal.com Thu Jul 7 08:46:05 1994 From: "Scott Yen" Date: Thu Jul 7 08:46:22 PDT 1994 Subject: Re: a.out to ieee/srec/hp formats > Submitted-by: kapoorsx@ntmtv.com (Sanjay Kapoor) > > I am trying to port VxWorks to a new 68k based hardware board. I'm trying > to use an HP emulator to initially debug the VxWorks port. The emulator, > however, only understands IEEE and HP executable formats. As far as I can > tell though, the 68k cross linker (ld68K) doesn't allow for formats other > than a.out to be specified for output. Does anyone know of how to generate > executable formats other than a.out either with ld68k or with a > conversion utility? > > Thanks, > > Sanjay Kapoor > kapoorsx@ntmtv.com > Norther Telecom > Mountain View, CA In my previous job at WRS, I had worked to get VxGDB to co-work with HP emulator tools, where an a2i68k converter was used to convert VxWorks and application image from aout to ieee. Please check with Wind River (tools group) to see if you can obtain the converter. I remember the utility was from HP Colorado Spring Emulator division and it's GNU copylefted. --Scott -- -------------------------------------------------------------------------------- scott@interactive.com | "God, grant me patience... Scott Yen | (415) 940-6818 | ...but please hurry up!" -------------------------------------------------------------------------------- From AMMGR@msgate.emis.hac.com Thu Jul 7 08:51:58 1994 From: "Message Router Submi" Date: Thu Jul 7 08:52:07 PDT 1994 Subject: Status of : Status of : Status of : Status of : MVME162 IP M ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : MVME162 IP M To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 08:36:48.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 08:53:57 1994 From: "Message Router Submi" Date: Thu Jul 7 08:54:10 PDT 1994 Subject: Status of : Status of : Status of : Synchronuous Driver for ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Synchronuous Driver for To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 08:37:35.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 08:57:58 1994 From: "Message Router Submi" Date: Thu Jul 7 08:58:07 PDT 1994 Subject: Status of : Status of : Status of : Status of : NOTE 07/07/9 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : NOTE 07/07/9 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 08:43:51.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 09:22:58 1994 From: "Message Router Submi" Date: Thu Jul 7 09:23:09 PDT 1994 Subject: Status of : Status of : Status of : Avoiding __main in cross ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Avoiding __main in cross To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 08:59:44.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From mad@strata.com Thu Jul 7 09:41:30 1994 From: mad@strata.com (Madhu R. Grandhi) Date: Thu Jul 7 09:41:41 PDT 1994 Subject: RCS I am using vxWorks on SUN, does anyone use source code control other than UNIX SCCS? I am interested in RCS, I would appreciate if anyone can let me know where I could find the RCS in obj form for SUN or source code. madhu From pean@mbari.org Thu Jul 7 11:08:19 1994 From: Andrew Pearce Date: Thu Jul 7 11:08:29 PDT 1994 Subject: Software Engineer/Embedded Systems The Monterey Bay Aquarium Research Institute SOFTWARE ENGINEER I The Monterey Bay Aquarium Research Institute seeks an energetic, junior Software Engineer to provide software maintenance and support to a team of engineers currently building a technologically advanced remotely operated underwater vehicle (ROV). Responsibilities include configuration, operation, and problem solving for vehicle real-time control, data acquisition, and communications systems. Some software design and implementation will also be required. The successful candidate will assist other project team members during prototype vehicle testing and provide long-term software support for the final operational system. BS in CS, EE, or equivalent, and 1-3 years experience in developing software using C/C++ in UNIX or PC environments is required. Proficiency in vxWorks or embedded microcontroller applications is a plus. An ability and willingness to go to sea for short durations of time is required. Please send resume by 07/15/94 to SWE, MBARI, 160 Central Ave, Pacific Grove, CA 93950, or email to pean@mbari.org EOE From hill@luke.atdiv.lanl.gov Thu Jul 7 11:22:21 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Thu Jul 7 11:22:30 PDT 1994 Subject: corba on vxWorks Hello, Does anyone know of a company that provides corba support which run under vxWorks? Jeff ______________________________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos, NM USA 87545 FAX 505 665 5107 From mike@imatron.com Thu Jul 7 11:33:03 1994 From: "Mike Morrison[Software Eng]" Date: Thu Jul 7 11:33:13 PDT 1994 Subject: Floating point on 040 We would like to improve the speed of floating point operations on a mvme167 running vxworks 5.1.1. Does anyone know of a nice fast single precision floating point library for the '040 that implements transcendental functions? Vxworks only does double precisios. From AMMGR@msgate.emis.hac.com Thu Jul 7 14:16:02 1994 From: "Message Router Submi" Date: Thu Jul 7 14:16:23 PDT 1994 Subject: Status of : Status of : Status of : comp.os.vxworks newsdige ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : comp.os.vxworks newsdige To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 09:22:07.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 14:16:02 1994 From: "Message Router Submi" Date: Thu Jul 7 14:16:26 PDT 1994 Subject: Status of : VX-Windows ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : VX-Windows To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 09:32:01.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 14:16:04 1994 From: "Message Router Submi" Date: Thu Jul 7 14:16:32 PDT 1994 Subject: Status of : Status of : Status of : Status of : [-r] gnu beh ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : [-r] gnu beh To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 09:22:50.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 14:37:00 1994 From: "Message Router Submi" Date: Thu Jul 7 14:37:09 PDT 1994 Subject: Status of : Status of : Re: MVME162 IP Module Access ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Re: MVME162 IP Module Access To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 14:27:58.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 14:43:02 1994 From: "Message Router Submi" Date: Thu Jul 7 14:43:20 PDT 1994 Subject: Status of : Status of : Status of : Status of : Synchronuous ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Synchronuous To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 14:38:05.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 14:43:02 1994 From: "Message Router Submi" Date: Thu Jul 7 14:43:21 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 14:37:24.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 14:44:00 1994 From: "Message Router Submi" Date: Thu Jul 7 14:44:10 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 14:38:48.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 15:25:02 1994 From: "Message Router Submi" Date: Thu Jul 7 15:25:18 PDT 1994 Subject: Status of : RCS ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : RCS To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 15:13:19.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 15:25:02 1994 From: "Message Router Submi" Date: Thu Jul 7 15:25:20 PDT 1994 Subject: Status of : Status of : Status of : Status of : Avoiding __m ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Avoiding __m To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 15:12:38.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 15:33:59 1994 From: "Message Router Submi" Date: Thu Jul 7 15:34:09 PDT 1994 Subject: Status of : corba on vxWorks ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : corba on vxWorks To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 15:24:44.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 15:36:06 1994 From: "Message Router Submi" Date: Thu Jul 7 15:36:23 PDT 1994 Subject: Status of : Floating point on 040 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Floating point on 040 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 15:26:23.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 17:14:58 1994 From: "Message Router Submi" Date: Thu Jul 7 17:15:10 PDT 1994 Subject: Status of : Software Engineer/Embedded Systems ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Software Engineer/Embedded Systems To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 17:10:54.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 17:25:59 1994 From: "Message Router Submi" Date: Thu Jul 7 17:26:08 PDT 1994 Subject: Status of : Re: a.out to ieee/srec/hp formats ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Re: a.out to ieee/srec/hp formats To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 17:20:52.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 19:29:00 1994 From: "Message Router Submi" Date: Thu Jul 7 19:29:16 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 19:24:18.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 19:29:00 1994 From: "Message Router Submi" Date: Thu Jul 7 19:29:18 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 19:25:05.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 19:29:59 1994 From: "Message Router Submi" Date: Thu Jul 7 19:30:10 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 19:26:03.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From goodrich@cabernet.tuc.noao.edu Thu Jul 7 19:30:44 1994 From: goodrich@cabernet.tuc.noao.edu (Bret Goodrich) Date: Thu Jul 7 19:30:56 PDT 1994 Subject: Booting VxWorks from NVRAM Although VxWorks has given us numerous ways to boot processors under version 5.1.1, WRS has never implemented a non-volatile RAM boot mechanism. By tweeking the 5.1.1 distribution, I've added the capability to boot from this "ram" disk. The changes parallel the SCSI boot process to such a degree that I share some code from this boot mechanism. I now boot with the following configuration: boot device : ram=800000,800 processor number : 0 host name : sonora file name : /ram/vxWorks inet on ethernet (e) : 140.252.1.53:ffffff00 host inet (h) : 140.252.1.52 user (u) : prog flags (f) : 0x8 target name (tn) : sonora-i startup script (s) : /ram/startup.cmd other (o) : ln The boot device contains the device "ram", the starting VME address, and the number of 512 byte blocks in the DOS file system. The latter two are hexidecimal numbers. An optional network device can be attached with the "other" field, a la SCSI_BOOT. I have a 1 MB battery-backed RAM card (Micro Memories MM6704c) with a DOS file system ("/ram/") installed on it. Loaded on this are the files "vxWorks", "vxWorks.sym", and "startup.cmd" configured for normal operation. There are five files which need to be modified to implement RAM booting. First is "./config/all/bootConfig.c" which needs to detect the "ram" device and address from the boot line and a routine to load the vxWorks image from a local RAM disk. Second is "./config/usrConfig.c" which installs the RAM disk for the full operating system. The files "./src/config/usrLoadSym.c" and "./src/config/usrNetwork.c" modify the symbol table load and network configure operations for RAM boots. Finally the line "#define INCLUDE_RAM_BOOT" needs to be added to the BSP "config.h" file. I've implemented this on a Motorola MV147, but none of the mods are board-specific. The diffs for these modifications are available. If there is enough interest I'll post them. 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 From AMMGR@msgate.emis.hac.com Thu Jul 7 19:32:59 1994 From: "Message Router Submi" Date: Thu Jul 7 19:33:13 PDT 1994 Subject: Status of : Status of : Status of : Re: MVME162 IP Module Ac ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Re: MVME162 IP Module Ac To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 19:28:56.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 20:15:00 1994 From: "Message Router Submi" Date: Thu Jul 7 20:15:16 PDT 1994 Subject: Status of : Status of : VX-Windows ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : VX-Windows To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 20:10:04.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 20:35:59 1994 From: "Message Router Submi" Date: Thu Jul 7 20:36:09 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 20:32:07.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 20:37:59 1994 From: "Message Router Submi" Date: Thu Jul 7 20:38:16 PDT 1994 Subject: Status of : Status of : Status of : Status of : comp.os.vxwo ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : comp.os.vxwo To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 20:33:02.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 22:54:01 1994 From: "Message Router Submi" Date: Thu Jul 7 22:54:09 PDT 1994 Subject: Status of : Status of : Floating point on 040 ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Floating point on 040 To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 22:50:50.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 22:55:04 1994 From: "Message Router Submi" Date: Thu Jul 7 22:55:13 PDT 1994 Subject: Status of : Status of : corba on vxWorks ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : corba on vxWorks To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 22:51:52.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 23:02:02 1994 From: "Message Router Submi" Date: Thu Jul 7 23:02:17 PDT 1994 Subject: Status of : Status of : Status of : Status of : Status of : ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Status of : Status of : Status of : To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 22:57:26.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Thu Jul 7 23:02:01 1994 From: "Message Router Submi" Date: Thu Jul 7 23:02:19 PDT 1994 Subject: Status of : Status of : RCS ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : RCS To : SSW::SMTPGATE::VXWEXPLO Date: 7-JUL-1994 22:58:22.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Fri Jul 8 00:21:20 1994 From: "Message Router Submi" Date: Fri Jul 8 00:21:31 PDT 1994 Subject: Status of : Status of : Re: a.out to ieee/srec/hp formats ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Re: a.out to ieee/srec/hp formats To : SSW::SMTPGATE::VXWEXPLO Date: 8-JUL-1994 00:16:58.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From AMMGR@msgate.emis.hac.com Fri Jul 8 00:45:02 1994 From: "Message Router Submi" Date: Fri Jul 8 00:45:18 PDT 1994 Subject: Status of : Status of : Software Engineer/Embedded Systems ----- ITEM 1 ----- From: AMMGR@MRAM_EDEN@EDEN Author: Message Router Submission Agen To: SMTPGATE Created: // Time: :: Subject: Status of : Status of : Software Engineer/Embedded Systems To : SSW::SMTPGATE::VXWEXPLO Date: 8-JUL-1994 00:28:37.00 Invalid address - SB07981 %DIR-E-NODIRMTCH, No matching Directory Entry found Error processing envelope From daemon@vxw.ee.lbl.gov Fri Jul 8 04:00:38 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jul 8 04:00:50 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jul 8 04:00:14 PDT 1994 Subject: Re: Memory leak in TCL Subject: MV167 MMU Transparent Translation register format ? Subject: Need info on latest NTPport to VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Memory leak in TCL Date: Thu, 7 Jul 94 12:09:28 GMT From: erolfe@ll.mit.edu (Ed Rolfe) Organization: MIT Lincoln Lab Message-ID: <1994Jul7.120928.18785@ll.mit.edu> Reply-To: erolfe@ll.mit.edu (Ed Rolfe) Sender: news@ll.mit.edu > I have been using Joe VanAndel's port of TCL 7.0. I have found a memory > leak when a procedure is called. I have created some procedures and a > script that calls the procedures. Whenever a procedure, that I > created, is run I lose 160 bytes of memory. I am running this on a > Force '040, with 4 megs. memory, and VxWorks 5.1.1. The number of bytes > lost is always 160, it does not depend on the size of the procedure > called. I found this problem using memShow. If you have the source code, look at the tcpLoginCommand function in the tclTCP.c module. On my release, it appears that storage is allocated (ckalloc) during the evaluation of "hostname" and if the host is trusted, the procedure returns a greeting mesage -- without ckfree(ing) the storage. This may (or may not) fix your memory (160 bytes) leak. On our system - which runs 24x7 with multiple workstation -> tclvx accesses, we haven't yet "crashed" because of a memory error related to tclvx (after fixing the above problem). We may just may not have run long enough, however. I've not had time to fully look at the inner workings of the tcl interpreter, but perhaps someone could comment on memory utilization within the interpreter - does the interpreter release memory when no longer needed or does it simply shift previously allocated memory into some form of pool, such that if needed later and of the right size, it does not have to reallocate the block. Best regards, - -- +-------------------------------------------------------------+ | 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 | +-------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: MV167 MMU Transparent Translation register format ? Date: Thu, 7 Jul 1994 14:46:25 GMT From: vxworks@jet.uk (VxWorks Home) Organization: Joint European Torus Keywords: DTT MV167 68040 Message-ID: <1994Jul7.144625.16859@jet.uk> From vxWorks FAQ question 54. > /**************************/ > /* for 68040 (e.g. mv167) */ > /**************************/ > /* 2 large areas, R/W, cache disabled */ > #define DTT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ > #define DTT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ > > test_dtt () > { > asm ("movec %0,dtt0" : : "r" (DTT0_VALUE)); > asm ("movec %0,dtt1" : : "r" (DTT1_VALUE)); > } The lower 16 bits of the DTTx_VALUE words seem at odds with the description in the MC68040 USER MANUAL, which defines the format:- bit No. - ------- 0 = 0. 1 = 0. 2 = Write protect bit. 1=Write accesses not permitted. 3 = 0. 4 = 0. 5 & 6 = Cache mode bits. 00 = Cachable Writethrough. 01 = Cache, Copyback. 10 = Cache Inhibited, Serialized. 11 = Cache Inhibited, Not Serialized. 7 = 0 8 = U0 User page Attributes 9 = U1 10 = 0 11 = 0 12 = 0 13 & 14 = Supervisor/User mode. 00 = Match only if FC2 is 0 (User mode). 01 = Match only if FC2 is 1 (Supervisor mode). 1x = Ignore FC2 when matching. 15 = Enable. 1 = Transparent translation enable. 0 = Disavled. For access to a big slice of VME extented address space (A32/D32), a value of 0x403fc040 would seem more correct for DTT0_VALUE. To disable cache, not write protected, enable translation and ignore user/super mode. Before I waste time testing this. Can anyone confirm this or correct me ? Thanks in advance. Ivan.... - - Disclaimer: Please note that the above is a personal view and should not be construed as an official comment from the JET project. --------------------------- Newsgroups: comp.protocols.time.ntp,comp.os.vxworks Subject: Need info on latest NTPport to VxWorks Date: Thu, 7 Jul 1994 19:35:58 GMT From: pnarayan@hns.com (Padmini Narayan) Organization: Hughes Network Systems Inc. Keywords: NTP, SNTP, usrTime Message-ID: <1994Jul7.193558.110@hns.com> Sender: news@hns.com (USENET news system) HI I would like to know if NTP or SNTP have been ported to VxWorks 5.1.1. Where can I find these implementations? I would appreciate it if you can provide me with any pointers (ftp sites, author names, etc.). Thanks in advance - -- Padmini ^^^^^^^^^^^^^^^^^^^^^^^ Padmini Narayan pnarayan@hns.com Embedded Software Group Hughes Network Systems --------------------------- End of New-News digest ********************** From tsb@mclean.sparta.com Fri Jul 8 05:21:24 1994 From: tsb@mclean.sparta.com (Todd S. Brackett) Date: Fri Jul 8 05:21:35 PDT 1994 Subject: Re: RCS > From root@vxw.ee.lbl.gov Thu Jul 7 13:06:05 1994 > Date: Thu, 7 Jul 94 09:41:52 PDT > To: vxworks_users@vxw.ee.lbl.gov > From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) > Subject: RCS Madhu R. Grandhi writes; > > > I am using vxWorks on SUN, does anyone use source code control other than UNIX > SCCS? I am interested in RCS, I would appreciate if anyone can let me know > where I could find the RCS in obj form for SUN or source code. We use RCS here at SPARTA. The source is available via anonymous ftp from prep.ai.mit.edu This site tends to be saturated so most GNU sources can also be found at the following mirror sites. gatekeeper.dec.com:/pub/GNU ftp.uu.net:/systems/gnu wuarchive.wustl.edu:/mirrors/gnu nic.funet.fi:/pub/gnu The file of interest is (always check for patches and updates) rcs-5.6.0.1.tar.gz this is GNU-ZIPPED (compressed) if you need GNU-ZIP it can be found in the same locations. gzip-1.2.4.tar Regards, ----------------------------------------------------------- |Todd S. Brackett | Voice -> 703 448 1683 x249 | |tsb@mclean.sparta.com | FAX -> 703 734 3323 | |_________________________________________________________| | | | /\\ SPARTA, Inc. | | ///\\ 7926 Jones Branch Drive | | /////\\ Suite 900 | | ///// \\ McLean, VA 22102 | | / \\\\\ \\ "Life is like baseball, | | \ \\\\\ // some days you win, | | \ ////// some days you loose, | | \////// SPARTA some days it rains..." | | \//// Pride In Performance | | \// | ___________________________________________________________ From rec@yin.ucsd.edu Fri Jul 8 09:01:59 1994 From: rec@yin.ucsd.edu (Richard E. Currier) Date: Fri Jul 8 09:02:10 PDT 1994 Subject: Re: Status of : Status of : Status of : Status of : Status of : Ok folks, time to dump this poster NOW...... From ddavies@sim.es.com Fri Jul 8 09:49:51 1994 From: ddavies@sim.es.com (Doug Davies) Date: Fri Jul 8 09:49:59 PDT 1994 Subject: Re: Status of : Status of : Status of : Status of : Status of : > Ok folks, time to dump this poster NOW...... I've been over run by these messages also... I sent a message to the 'vxwexplo-request' address of this mailer, I hope they get it resolved soon, this is really getting annoying! -Doug -------------------------------------------------------------------------------- Douglas Davies (software engineer) | Evans & Sutherland | "Never underpay your software engineers" INTERNET: ddavies@jaba.sim.es.com | -Jurassic Park Moral From micf@lannet.com Fri Jul 8 12:26:45 1994 From: micf@lannet.com (Michael Feldman) Date: Fri Jul 8 12:26:56 PDT 1994 Subject: CPUs comparison responses Dear vxWorkers! I've received a few messages with requests to "explode" responses to my "CPUs comparison question". The question was as following: >> Has anyone out there tried to compare >> a).relative performance; >> b).availability and response time of technical support; >> c).availability and quality of development tools >> and maybe other parameters for following list of CPUs: >> i960CA/CF, i960KA, i960SX, M68360, M68030, M68040, SPARC-LITE, SPARC2? >> As it's seen, the question hasn't been formulated precisely, and I haven't expected to receive the precise responses, and it's very difficalt to formulate a conclusion. However, the responses that I've received contain very interesting information for further work. Here I attach responses that I've received in "private" manner (not through the "exploder"). Best regards, ------------------------------------------------------------------------------ Feldman Michael email: micf@lannet.com Lannet Data Communications Ltd. Fax: 972-3-6487146 Atidim Technology Park, Bldg. 3 Tel: 972-3-6458469 Tel Aviv 61131, Israel ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Paul Harvey (pmh@zoe.as.utexas.edu) writes: >We are probably in the process of giving up on trying to use a Sparc 1E >board for a project and will be switching to something else. So I >am interested in the same kind of information you are looking for. If >you happen to get any private emails (rather than exploder answers), >I'd appreciate it if you could cc them to me if that is not asking too >much. Thanks. > >Paul Harvey ------------------------------------------------------------------------------ Gary M. Trimble (trimble@lams.msd.lmsc.lockheed.com) writes: >We are currently planning to go to Power PC (603) by the end of the year. WRS has >announced support for the chip, and there are a number of manufacturers working >on board level products. A major advantage of PPC is signal processing level >performance in a general purpose CPU. > >Gary M. Trimble - Lockheed Marine Automation and Robotics Engineering ------------------------------------------------------------------------------- Doug Dyer (dyer@alx.sticomet.com) writes: >Hey, what about MIPS? Heurikon has some great systems bundled with SGIs for >development. We also have great experience with MIPS BSPs, etc. You might >want to look at that chip's performance. > >best of luck, >-- >Doug Dyer - dyer@alx.sticomet.com | Real-time systems . * //[]// >Software Technology, Inc. (STI) | Space flight/ground software ^^ . >DC office: (703) 329-9707 | vxWorks BSPs, etc. . ------------------------------------------------------------------------------- R. Clegg PE (clegg@tesla.elen.ssd.fsi.com) writes: >Michael: >The CPU's you chose each have their unique niches at the moment and therefore >may not be able to be compared easily. However, I believe that, of the ones >you listed, the SPARC2 is currently the hungriest number cruncher. On the other hand it cannot even come close to the RISC-engine/68K performance in >communications that the M68360 can. Furthermore, if you are developing a >board yourself, the easiest to develope with is the MC68360 as it incorporates >reset logic, timers, etc. and has MANY software examples available. Motorola >did an excellent job with that one. If you are considering the M68040 for a >new design, you should probably toss it and go with the next generation M68060 >since it doubles or trebles the performance of the M68040 (supposedly). > >My personal favorite from a pure CPU point is the M68060. It has a large >installed base (due to 68K compatibility), an incredibly easy assembly language, >for those who dabble in hand optimization and GNU has a reasonably decent >compiler/development system for "free". > >If you are doing any sort of signal processing, you may wish to consider a >DSP style cpu. For instance, in a recent audio multiplexing/processing system, >we ended up using a QUAD TI DSP board ('50) with direct connections to a >A/D D/A board using their built in comm ports in order to achieve the >performance desired and 44K samples/sec. > >Hope this hasn't been too confusing. > >Good Luck, >R. Clegg PE >Flight Safety-SSD >"The best safety device in any plane is a well trained pilot" ------------------------------------------------------------------------------- Phil Ekins (Ekins@sif.Sinet.SLB.Com) writes: >Michael, > >When I was evaluating CPU's (2-3 years ago) we just looked at the 68000 range, >e.g. Motorola, Force, Tadpole,... We went for the MVME147 (motorola 68030), we >required performance, ethernet, serial port + well supported + reliable + PRICE. > The mv147 proved adequate but by the end of the project was running short of >puff, so we got in a MVME167 (motorola 68040) which as we required lots of >floating point maths, the 167 had an obvious big advantage. So, all we had to >do was re-compile and run-up the same software and away we go (that's what >everyone said, and what I said to my boss), and that's what happened, it was >amazingly easy and straight forward. The performance improvement of the mv167 >is far more than just the 68040 to a 68030, i.e. floating point speed, the mv167 >has a very good system performance, far superior to the mv147. >We now support both boards: mv147 and mv167, the only difference is at compile >time and the VxWorks image that gets booted (I'm still amazed by this). We have >had no bugs which have only affected one of the CPU's. >Also we have had NO hardware problems with either of these CPU's. > >Hope this helps, > Phil > >******************************************************************************* > Phil Ekins, Internet: Ekins@sif.Sinet.SLB.Com > Solartron Instruments, Tel: (44) 252 376666 Ext.2287 > Victoria Road, Fax: (44) 252 543854 > Farnborough, GU14 7PW, > England. >******************************************************************************* > > >VMSmail To information: m_internet::"micf@lannet.com" >Sender's personal name: Phil Ekins - Solartron Instruments R&D - Farnborough UK ------------------------------------------------------------------------------- George Eger (geger@den.mmc.com) writes: >In article <9406301624.AA03588@zoo.lannet.com>, you write: |> Hi folks! ...... ...... |> >Boy is this a loaded question. First, you need to determine your requirements >for the various products that you're going to produce. Obviously performance >is a factor and that in itself is a minefield. You'll have to determine what >is going to limit your performance - interrupt handling, buffer handling, >data copying, other algorithmic processing, context switching, etc. Once you >do that, then you can start talking about processor selection from a >performance point of view. > >I strongly suggest you create a set of your own benchmarks for testing >the various candidates and get the vendors to help you run them. I don't >know how big your company is, but if you have the resources to use something >like Verilog or VHDL, you can get models of most of these processors and >do a full simulation before getting any HW. That way you can see if >the performance is adequate before you do a complete design. > >There is also a tremendous overall system trade with memory type, size, and >cost that'll need to be addressed. With most of the faster comm systems I've >worked with, the bottlneck becomes how you design the flow through the >protocol stack to eliminate processor copying and buffer processing. The >more you can do to offload the processor from data and buffer movement, >the better off you are. If you can get a well implemented DMA controller >to do the movement, then the processor can be making the decisions while the >DMA is handling the dirty work. Page boundary/DMA burst limitations, memory >access speed and wait states, alignment/misaligned transfer processing, >and other factors will influence how much performance you need from your >CPU to get the optimal performance for the optimal price. You may need >to spend more on the memory if there's little or no cache (or the processor >has to share the same address space for both data and instructions). > >Overall development cost should also be a factor. I would strongly recommend >that you pay attention to the cost of both HW needed to support the processor >(glue logic, cache, DMA controllers, peripheral interrupt/io/timer chips, etc) >and the SW tools. My rule of thumb for SW is that if it isn't supported by GNU, >don't muck with it. At least you have a good quality, inexpensive tool >to get started with if the processor is supported by GNU. > >Why are you excluding the AMD 29K family, the 80X86 variants, and the MIPS >R[34]000 chips. These are supported by WindRiver and have pretty good >characteristics for comm applications. For some applications, the AMD (with >192 registers, better interrupt and memory architecture, and the branch >target cache) can be a winner. The MIPS is a very well balanced architecture >with the 32 registers. It is limited in the number of external interrupts, >but with some variants (like the IDT 3051), there are some interesting >"microcontroller-like" features built in. Both AMD and MIPS chips have >bend successfully used for FDDI boards and for PostScript printer controllers. >The AMD's have also been used for multiport serial muxes and for graphics >controllers (Apple selected them for a Mac Toolbox-compatible advanced graphics >Nubus card). > >I would also recommend that you check out some of the other kernel vendors >before going whole-hog into VxWorks. If you need a family of processors, >VxWorks limits you to the 32-bit top of the line type stuff. OS-9, C-Exec, >RTXC, and some of the others let you run the smae kernel on less powerful >processors, thereby improving your code protability/reusability. And >there is a vast difference in RT licensing philosophy. You need to >do some cost vs quantity vs market penetration type studies. > >I know this isn't much help, but your question just begged for a response. > >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. || >||========================================================================== > From goodrich@cabernet.tuc.noao.edu Fri Jul 8 13:38:57 1994 From: goodrich@cabernet.tuc.noao.edu (Bret Goodrich) Date: Fri Jul 8 13:39:11 PDT 1994 Subject: Re: Booting VxWorks from NVRAM Here are the four diff files for adding RAM booting to VxWorks 5.1.1. These files were created from "diff -e", so you can run them through "ed" to convert the originals. I haven't bothered to package them into a nice "patch" script but the changes are minor. As always, back up the originals. The four files can be modified with the following: # in $VXWORKS/config/all mv bootConfig.c bootConfig.c.BAK (cat bootConfig.c.diff; echo '1,$p') | ed - bootConfig.c.BAK > bootConfig.c mv usrConfig.c usrConfig.c.BAK (cat usrConfig.c.diff; echo '1,$p') | ed - usrConfig.c.BAK > usrConfig.c # in $VXWORKS/src/config mv usrLoadSym.c usrLoadSym.c.BAK (cat usrLoadSym.c.diff; echo '1,$p') | ed - usrLoadSym.c.BAK > usrLoadSym.c mv usrNetwork.c usrNetwork.c.BAK (cat usrNetwork.c.diff; echo '1,$p') | ed - usrNetwork.c.BAK > usrNetwork.c Edit your BSP config.h file for the *minimum* system you need for the boot ROM (remember to include "#define INCLUDE_RAM_BOOT"), then compile with "make bootrom.hex". Burn your boot EPROMs and install them. Edit your BSP config.h file for your *standard* VxWorks system (include "#define INCLUDE_RAM_BOOT" if you wish to continue to have access to the RAM disk), then compile with "make vxWorks". Boot up your VxWorks target using the original boot device (non-RAM). Install a DOS file system on the RAM disk. Copy files $VXWORKS/config//vxWorks and $VXWORKS/config//vxWorks.sym to the RAM disk. You may also want to add a "startup.cmd" file to the RAM disk. Change the boot parameters for boot device ("ram=800000,800" or similiar), file name ("/ram/vxWorks"), and startup script ("/ram/startup.cmd" or equivalent). Reboot. If you have any problems with the patch or the final results, please email me. If you need the full source files i can arrange to send them to you or set up an ftp site. 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 ---cut here-------------------bootConfig.c.diff---------------------cut here--- 1664a #ifdef INCLUDE_RAM_BOOT #include "vxLib.h" /******************************************************************************* * * ramLoad - load a vxWorks image from a local RAM disk */ LOCAL STATUS ramLoad ( char *ramAdrs, int nBlocks, char *fileName, FUNCPTR *pEntry ) { int fd; BLK_DEV * pRamBlkBootDev; char bootDir[BOOT_FILE_LEN]; char * i; /* create a block device spanning entire disk (non-destructive!) */ for (i = ramAdrs; i < ramAdrs + nBlocks*512; i += 512) if (vxMemProbe (ramAdrs, VX_READ, sizeof (int), (char *) &fd) == ERROR) { printErr ("Invalid RAM address 0x%x.\n", (int) i); return (ERROR); } if ((pRamBlkBootDev = ramDevCreate (ramAdrs, 512, 0, nBlocks, 0)) == NULL) { printErr ("pRamBlkBootDev failed.\n"); return (ERROR); } dosFsInit (NUM_DOSFS_FILES); /* initialize DOS-FS */ /* split off boot device from boot file */ devSplit (fileName, bootDir); /* initialize the boot block device as a dosFs device named */ if (dosFsDevInit (bootDir, pRamBlkBootDev, NULL) == NULL) { printErr ("dosFsDevInit failed.\n"); return (ERROR); } printErr ("done.\n"); /* load the boot file */ printErr ("Loading %s...", fileName); fd = open (fileName, O_RDONLY, 0); if (fd == ERROR) { printErr ("\nCannot open \"%s\".\n", fileName); return (ERROR); } if (bootLoadModule (fd, pEntry) != OK) goto readErr; close (fd); return (OK); readErr: printErr ("\nerror loading file: status = 0x%x.\n", errnoGet ()); close (fd); return (ERROR); } #endif /* INCLUDE_RAM_BOOT */ . 1446a #endif /* INCLUDE_SCSI_BOOT || INCLUDE_RAM_BOOT */ #ifdef INCLUDE_SCSI_BOOT #define SPIN_UP_TIMEOUT 45 /* max # of seconds to wait for spinup */ . 1404,1405d 1402c #if defined(INCLUDE_SCSI_BOOT) || defined (INCLUDE_RAM_BOOT) . 1115a #ifdef INCLUDE_RAM_BOOT if (strncmp (params.bootDev, "ram", 3) == 0) { int ramAdrs; int nBlocks; if (strlen (params.bootDev) == 3) { printErr ("No RAM boot address,#blocks given\n"); return (ERROR); } sscanf (params.bootDev, "%*3s%*c%x%*c%x", &ramAdrs, &nBlocks); if (ramLoad ((char *) ramAdrs, nBlocks, params.bootFile, pEntry) != OK) { printErr ("\nError loading file: errno = 0x%x.\n", errno); return (ERROR); } return (OK); } #endif /* INCLUDE_RAM_BOOT */ . 962c printf ("Version: %s-RAM\n", vxWorksVersion); . 451a #ifdef INCLUDE_RAM_BOOT LOCAL STATUS ramLoad(); #endif /* INCLUDE_RAM_BOOT */ . 419a #ifdef INCLUDE_RAM_BOOT LOCAL STATUS ramLoad (char *ramAdrs, int nBlocks, char *fileName, FUNCPTR *pEntry ); #endif /* INCLUDE_RAM_BOOT */ . 176a #include "ramDrv.h" . 8a 05jul94,bdg added RAM boot option . ---cut here-------------------bootConfig.c.diff---------------------cut here--- ---cut here--------------------usrConfig.c.diff---------------------cut here--- 633a /******************************************************************************* * * usrRamConfig - initialize boot RAM disk */ LOCAL STATUS usrRamConfig () { BLK_DEV *pRamDev; int ramAdrs; int nBlocks; if (strncmp (sysBootParams.bootDev, "ram", 3) == 0) { sscanf (sysBootParams.bootDev, "%*3s%*c%x%*c%x", &ramAdrs, &nBlocks); if ((pRamDev = ramDevCreate ((char *) ramAdrs, 512, 0, nBlocks, 0)) == NULL) { printErr ("pRamDev failed\n"); return (ERROR); } if ((dosFsDevInit ("/ram/", pRamDev, NULL)) == NULL) { printErr ("dosFsDevInit failed.\n"); return (ERROR); } } return (OK); } . 468a /* initialize RAM disk */ #ifdef INCLUDE_RAMDRV usrRamConfig (); #endif /* INCLUDE_RAMDRV */ . 187a LOCAL STATUS usrRamConfig (); . 8a 06jul94,bdg added usrRamConfig() and call to it in usrRoot(). . ---cut here--------------------usrConfig.c.diff---------------------cut here--- ---cut here-------------------usrLoadSym.c.diff---------------------cut here--- 46,47d 43c if (strncmp (sysBootParams.bootDev, "scsi", 4) == 0) sprintf (symTblFile, "%s.sym", sysBootParams.bootFile); else if (strncmp (sysBootParams.bootDev, "ram", 3) == 0) sprintf (symTblFile, "%s.sym", sysBootParams.bootFile); else . 7a 06jul94,bdg modified symtab filename for ram boot. . ---cut here-------------------usrLoadSym.c.diff---------------------cut here--- ---cut here-------------------usrNetwork.c.diff---------------------cut here--- 318a } else { /* booting via ethernet */ if ((usrNetIfAttach (params.bootDev, params.ead) !=OK) || (usrNetIfConfig (params.bootDev, params.ead, params.targetName, netmask) !=OK)) return (ERROR); . 304,312d 302c /* booting via scsi or ram, configure network if included */ . 300c if (strncmp (params.bootDev, "scsi", 4) == 0 || strncmp (params.bootDev, "ram", 3) == 0) . 7a 06jul94,bdg modified network creation for ram boot . ---cut here-------------------usrNetwork.c.diff---------------------cut here--- From EMAILSUPPORT@email.hub.tek.com Fri Jul 8 14:47:26 1994 From: EMAILSUPPORT@email.hub.tek.com Date: Fri Jul 8 14:47:39 PDT 1994 Subject: Message Router non-delivery notification message. This message is being returned to you by the Tektronix MailBridge system because of an error. If you have questions contact: Tektronix Email and Groupware Support Phone: +1 (503) 627-7777 Internet: emailsupport@tek.com or by replying to this message or contact your local system administrator. EMAIL attempted delivery to: CHRISTOPHER.E.TILT Unable to deliver because the recipient name as typed is not in the directory. Please verify spelling & syntax. -=-=-=-=-=-=-=-=-=-=-=-=-=- Original Message Follows -=-=-=-=-=-=-=-=-=-=-=-=-=- Original Message ID: 72524180704991/307402@EMAIL Original message sender: vxwexplo @ lbl @ gov @ HUB @ EMAIL Original message sent to: vxworks_users @ vxw @ ee @ lbl @ gov @ HUB @ EMAIL Original message subject: Re: Booting VxWorks from NVRAM Original message contents: Submitted-by goodrich@cabernet.tuc.noao.edu Fri Jul 8 13:38:57 1994 Submitted-by: goodrich@cabernet.tuc.noao.edu (Bret Goodrich) Here are the four diff files for adding RAM booting to VxWorks 5.1.1. These files were created from "diff -e", so you can run them through "ed" to convert the originals. I haven't bothered to package them into a nice "patch" script but the changes are minor. As always, back up the originals. The four files can be modified with the following: # in $VXWORKS/config/all mv bootConfig.c bootConfig.c.BAK (cat bootConfig.c.diff; echo '1,$p') | ed - bootConfig.c.BAK > bootConfig.c mv usrConfig.c usrConfig.c.BAK (cat usrConfig.c.diff; echo '1,$p') | ed - usrConfig.c.BAK > usrConfig.c # in $VXWORKS/src/config mv usrLoadSym.c usrLoadSym.c.BAK (cat usrLoadSym.c.diff; echo '1,$p') | ed - usrLoadSym.c.BAK > usrLoadSym.c mv usrNetwork.c usrNetwork.c.BAK (cat usrNetwork.c.diff; echo '1,$p') | ed - usrNetwork.c.BAK > usrNetwork.c Edit your BSP config.h file for the *minimum* system you need for the boot ROM (remember to include "#define INCLUDE_RAM_BOOT"), then compile with "make bootrom.hex". Burn your boot EPROMs and install them. Edit your BSP config.h file for your *standard* VxWorks system (include "#define INCLUDE_RAM_BOOT" if you wish to continue to have access to the RAM disk), then compile with "make vxWorks". Boot up your VxWorks target using the original boot device (non-RAM). Install a DOS file system on the RAM disk. Copy files $VXWORKS/config//vxWorks and $VXWORKS/config//vxWorks.sym to the RAM disk. You may also want to add a "startup.cmd" file to the RAM disk. Change the boot parameters for boot device ("ram=800000,800" or similiar), file name ("/ram/vxWorks"), and startup script ("/ram/startup.cmd" or equivalent). Reboot. If you have any problems with the patch or the final results, please email me. If you need the full source files i can arrange to send them to you or set up an ftp site. 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 ---cut here-------------------bootConfig.c.diff---------------------cut here--- 1664a #ifdef INCLUDE_RAM_BOOT #include "vxLib.h" /******************************************************************************* * * ramLoad - load a vxWorks image from a local RAM disk */ LOCAL STATUS ramLoad ( char *ramAdrs, int nBlocks, char *fileName, FUNCPTR *pEntry ) { int fd; BLK_DEV * pRamBlkBootDev; char bootDir[BOOT_FILE_LEN]; char * i; /* create a block device spanning entire disk (non-destructive!) */ for (i = ramAdrs; i < ramAdrs + nBlocks*512; i += 512) if (vxMemProbe (ramAdrs, VX_READ, sizeof (int), (char *) &fd) == ERROR) { printErr ("Invalid RAM address 0x%x.\n", (int) i); return (ERROR); } if ((pRamBlkBootDev = ramDevCreate (ramAdrs, 512, 0, nBlocks, 0)) == NULL) { printErr ("pRamBlkBootDev failed.\n"); return (ERROR); } dosFsInit (NUM_DOSFS_FILES); /* initialize DOS-FS */ /* split off boot device from boot file */ devSplit (fileName, bootDir); /* initialize the boot block device as a dosFs device named */ if (dosFsDevInit (bootDir, pRamBlkBootDev, NULL) == NULL) { printErr ("dosFsDevInit failed.\n"); return (ERROR); } printErr ("done.\n"); /* load the boot file */ printErr ("Loading %s...", fileName); fd = open (fileName, O_RDONLY, 0); if (fd == ERROR) { printErr ("\nCannot open \"%s\".\n", fileName); return (ERROR); } if (bootLoadModule (fd, pEntry) != OK) goto readErr; close (fd); return (OK); readErr: printErr ("\nerror loading file: status = 0x%x.\n", errnoGet ()); close (fd); return (ERROR); } #endif /* INCLUDE_RAM_BOOT */ From goodrich@cabernet.tuc.noao.edu Fri Jul 8 14:56:48 1994 From: goodrich@cabernet.tuc.noao.edu (Bret Goodrich) Date: Fri Jul 8 14:57:02 PDT 1994 Subject: REPOST Re: Booting VxWorks from NVRAM # REPOST REPOST # # My copy of the exploder version of this message was truncated. I am # re-issuing the message, and hope it makes it out unscathed. # # bret Here are the four diff files for adding RAM booting to VxWorks 5.1.1. These files were created from "diff -e", so you can run them through "ed" to convert the originals. I haven't bothered to package them into a nice "patch" script but the changes are minor. As always, back up the originals. The four files can be modified with the following: # in $VXWORKS/config/all mv bootConfig.c bootConfig.c.BAK (cat bootConfig.c.diff; echo '1,$p') | ed - bootConfig.c.BAK > bootConfig.c mv usrConfig.c usrConfig.c.BAK (cat usrConfig.c.diff; echo '1,$p') | ed - usrConfig.c.BAK > usrConfig.c # in $VXWORKS/src/config mv usrLoadSym.c usrLoadSym.c.BAK (cat usrLoadSym.c.diff; echo '1,$p') | ed - usrLoadSym.c.BAK > usrLoadSym.c mv usrNetwork.c usrNetwork.c.BAK (cat usrNetwork.c.diff; echo '1,$p') | ed - usrNetwork.c.BAK > usrNetwork.c Edit your BSP config.h file for the *minimum* system you need for the boot ROM (remember to include "#define INCLUDE_RAM_BOOT"), then compile with "make bootrom.hex". Burn your boot EPROMs and install them. Edit your BSP config.h file for your *standard* VxWorks system (include "#define INCLUDE_RAM_BOOT" if you wish to continue to have access to the RAM disk), then compile with "make vxWorks". Boot up your VxWorks target using the original boot device (non-RAM). Install a DOS file system on the RAM disk. Copy files $VXWORKS/config//vxWorks and $VXWORKS/config//vxWorks.sym to the RAM disk. You may also want to add a "startup.cmd" file to the RAM disk. Change the boot parameters for boot device ("ram=800000,800" or similiar), file name ("/ram/vxWorks"), and startup script ("/ram/startup.cmd" or equivalent). Reboot. If you have any problems with the patch or the final results, please email me. If you need the full source files i can arrange to send them to you or set up an ftp site. 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 ---cut here-------------------bootConfig.c.diff---------------------cut here--- 1664a #ifdef INCLUDE_RAM_BOOT #include "vxLib.h" /******************************************************************************* * * ramLoad - load a vxWorks image from a local RAM disk */ LOCAL STATUS ramLoad ( char *ramAdrs, int nBlocks, char *fileName, FUNCPTR *pEntry ) { int fd; BLK_DEV * pRamBlkBootDev; char bootDir[BOOT_FILE_LEN]; char * i; /* create a block device spanning entire disk (non-destructive!) */ for (i = ramAdrs; i < ramAdrs + nBlocks*512; i += 512) if (vxMemProbe (ramAdrs, VX_READ, sizeof (int), (char *) &fd) == ERROR) { printErr ("Invalid RAM address 0x%x.\n", (int) i); return (ERROR); } if ((pRamBlkBootDev = ramDevCreate (ramAdrs, 512, 0, nBlocks, 0)) == NULL) { printErr ("pRamBlkBootDev failed.\n"); return (ERROR); } dosFsInit (NUM_DOSFS_FILES); /* initialize DOS-FS */ /* split off boot device from boot file */ devSplit (fileName, bootDir); /* initialize the boot block device as a dosFs device named */ if (dosFsDevInit (bootDir, pRamBlkBootDev, NULL) == NULL) { printErr ("dosFsDevInit failed.\n"); return (ERROR); } printErr ("done.\n"); /* load the boot file */ printErr ("Loading %s...", fileName); fd = open (fileName, O_RDONLY, 0); if (fd == ERROR) { printErr ("\nCannot open \"%s\".\n", fileName); return (ERROR); } if (bootLoadModule (fd, pEntry) != OK) goto readErr; close (fd); return (OK); readErr: printErr ("\nerror loading file: status = 0x%x.\n", errnoGet ()); close (fd); return (ERROR); } #endif /* INCLUDE_RAM_BOOT */ . 1446a #endif /* INCLUDE_SCSI_BOOT || INCLUDE_RAM_BOOT */ #ifdef INCLUDE_SCSI_BOOT #define SPIN_UP_TIMEOUT 45 /* max # of seconds to wait for spinup */ . 1404,1405d 1402c #if defined(INCLUDE_SCSI_BOOT) || defined (INCLUDE_RAM_BOOT) . 1115a #ifdef INCLUDE_RAM_BOOT if (strncmp (params.bootDev, "ram", 3) == 0) { int ramAdrs; int nBlocks; if (strlen (params.bootDev) == 3) { printErr ("No RAM boot address,#blocks given\n"); return (ERROR); } sscanf (params.bootDev, "%*3s%*c%x%*c%x", &ramAdrs, &nBlocks); if (ramLoad ((char *) ramAdrs, nBlocks, params.bootFile, pEntry) != OK) { printErr ("\nError loading file: errno = 0x%x.\n", errno); return (ERROR); } return (OK); } #endif /* INCLUDE_RAM_BOOT */ . 962c printf ("Version: %s-RAM\n", vxWorksVersion); . 451a #ifdef INCLUDE_RAM_BOOT LOCAL STATUS ramLoad(); #endif /* INCLUDE_RAM_BOOT */ . 419a #ifdef INCLUDE_RAM_BOOT LOCAL STATUS ramLoad (char *ramAdrs, int nBlocks, char *fileName, FUNCPTR *pEntry ); #endif /* INCLUDE_RAM_BOOT */ . 176a #include "ramDrv.h" . 8a 05jul94,bdg added RAM boot option . ---cut here-------------------bootConfig.c.diff---------------------cut here--- ---cut here--------------------usrConfig.c.diff---------------------cut here--- 633a /******************************************************************************* * * usrRamConfig - initialize boot RAM disk */ LOCAL STATUS usrRamConfig () { BLK_DEV *pRamDev; int ramAdrs; int nBlocks; if (strncmp (sysBootParams.bootDev, "ram", 3) == 0) { sscanf (sysBootParams.bootDev, "%*3s%*c%x%*c%x", &ramAdrs, &nBlocks); if ((pRamDev = ramDevCreate ((char *) ramAdrs, 512, 0, nBlocks, 0)) == NULL) { printErr ("pRamDev failed\n"); return (ERROR); } if ((dosFsDevInit ("/ram/", pRamDev, NULL)) == NULL) { printErr ("dosFsDevInit failed.\n"); return (ERROR); } } return (OK); } . 468a /* initialize RAM disk */ #ifdef INCLUDE_RAMDRV usrRamConfig (); #endif /* INCLUDE_RAMDRV */ . 187a LOCAL STATUS usrRamConfig (); . 8a 06jul94,bdg added usrRamConfig() and call to it in usrRoot(). . ---cut here--------------------usrConfig.c.diff---------------------cut here--- ---cut here-------------------usrLoadSym.c.diff---------------------cut here--- 46,47d 43c if (strncmp (sysBootParams.bootDev, "scsi", 4) == 0) sprintf (symTblFile, "%s.sym", sysBootParams.bootFile); else if (strncmp (sysBootParams.bootDev, "ram", 3) == 0) sprintf (symTblFile, "%s.sym", sysBootParams.bootFile); else . 7a 06jul94,bdg modified symtab filename for ram boot. . ---cut here-------------------usrLoadSym.c.diff---------------------cut here--- ---cut here-------------------usrNetwork.c.diff---------------------cut here--- 318a } else { /* booting via ethernet */ if ((usrNetIfAttach (params.bootDev, params.ead) !=OK) || (usrNetIfConfig (params.bootDev, params.ead, params.targetName, netmask) !=OK)) return (ERROR); . 304,312d 302c /* booting via scsi or ram, configure network if included */ . 300c if (strncmp (params.bootDev, "scsi", 4) == 0 || strncmp (params.bootDev, "ram", 3) == 0) . 7a 06jul94,bdg modified network creation for ram boot . ---cut here-------------------usrNetwork.c.diff---------------------cut here--- From EMAILSUPPORT@email.hub.tek.com Fri Jul 8 15:37:56 1994 From: EMAILSUPPORT@email.hub.tek.com Date: Fri Jul 8 15:38:12 PDT 1994 Subject: Message Router non-delivery notification message. This message is being returned to you by the Tektronix MailBridge system because of an error. If you have questions contact: Tektronix Email and Groupware Support Phone: +1 (503) 627-7777 Internet: emailsupport@tek.com or by replying to this message or contact your local system administrator. EMAIL attempted delivery to: CHRISTOPHER.E.TILT Unable to deliver because the recipient name as typed is not in the directory. Please verify spelling & syntax. -=-=-=-=-=-=-=-=-=-=-=-=-=- Original Message Follows -=-=-=-=-=-=-=-=-=-=-=-=-=- Original Message ID: 93335180704991/307687@EMAIL Original message sender: vxwexplo @ lbl @ gov @ HUB @ EMAIL Original message sent to: vxworks_users @ vxw @ ee @ lbl @ gov @ HUB @ EMAIL Original message subject: REPOST Re: Booting VxWorks from NVRAM Original message contents: Submitted-by goodrich@cabernet.tuc.noao.edu Fri Jul 8 14:56:48 1994 Submitted-by: goodrich@cabernet.tuc.noao.edu (Bret Goodrich) # REPOST REPOST # # My copy of the exploder version of this message was truncated. I am # re-issuing the message, and hope it makes it out unscathed. # # bret Here are the four diff files for adding RAM booting to VxWorks 5.1.1. These files were created from "diff -e", so you can run them through "ed" to convert the originals. I haven't bothered to package them into a nice "patch" script but the changes are minor. As always, back up the originals. The four files can be modified with the following: # in $VXWORKS/config/all mv bootConfig.c bootConfig.c.BAK (cat bootConfig.c.diff; echo '1,$p') | ed - bootConfig.c.BAK > bootConfig.c mv usrConfig.c usrConfig.c.BAK (cat usrConfig.c.diff; echo '1,$p') | ed - usrConfig.c.BAK > usrConfig.c # in $VXWORKS/src/config mv usrLoadSym.c usrLoadSym.c.BAK (cat usrLoadSym.c.diff; echo '1,$p') | ed - usrLoadSym.c.BAK > usrLoadSym.c mv usrNetwork.c usrNetwork.c.BAK (cat usrNetwork.c.diff; echo '1,$p') | ed - usrNetwork.c.BAK > usrNetwork.c Edit your BSP config.h file for the *minimum* system you need for the boot ROM (remember to include "#define INCLUDE_RAM_BOOT"), then compile with "make bootrom.hex". Burn your boot EPROMs and install them. Edit your BSP config.h file for your *standard* VxWorks system (include "#define INCLUDE_RAM_BOOT" if you wish to continue to have access to the RAM disk), then compile with "make vxWorks". Boot up your VxWorks target using the original boot device (non-RAM). Install a DOS file system on the RAM disk. Copy files $VXWORKS/config//vxWorks and $VXWORKS/config//vxWorks.sym to the RAM disk. You may also want to add a "startup.cmd" file to the RAM disk. Change the boot parameters for boot device ("ram=800000,800" or similiar), file name ("/ram/vxWorks"), and startup script ("/ram/startup.cmd" or equivalent). Reboot. If you have any problems with the patch or the final results, please email me. If you need the full source files i can arrange to send them to you or set up an ftp site. 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 ---cut here-------------------bootConfig.c.diff---------------------cut here--- 1664a #ifdef INCLUDE_RAM_BOOT #include "vxLib.h" /******************************************************************************* * * ramLoad - load a vxWorks image from a local RAM disk */ LOCAL STATUS ramLoad ( char *ramAdrs, int nBlocks, char *fileName, FUNCPTR *pEntry ) { int fd; BLK_DEV * pRamBlkBootDev; char bootDir[BOOT_FILE_LEN]; char * i; /* create a block device spanning entire disk (non-destructive!) */ for (i = ramAdrs; i < ramAdrs + nBlocks*512; i += 512) if (vxMemProbe (ramAdrs, VX_READ, sizeof (int), (char *) &fd) == ERROR) { printErr ("Invalid RAM address 0x%x.\n", (int) i); return (ERROR); } if ((pRamBlkBootDev = ramDevCreate (ramAdrs, 512, 0, nBlocks, 0)) == NULL) { printErr ("pRamBlkBootDev failed.\n"); return (ERROR); } dosFsInit (NUM_DOSFS_FILES); /* initialize DOS-FS */ /* split off boot device from boot file */ devSplit (fileName, bootDir); /* initialize the boot block device as a dosFs device named */ if (dosFsDevInit (bootDir, pRamBlkBootDev, NULL) == NULL) { printErr ("dosFsDevInit failed.\n"); return (ERROR); } printErr ("done.\n"); /* load the boot file */ printErr ("Loading %s...", fileName); fd = open (fileName, O_RDONLY, 0); if (fd == ERROR) { printErr ("\nCannot open \"%s\".\n", fileName); return (ERROR); } if (bootLoadModule (fd, pEntry) != OK) goto readErr; close (fd); return (OK); readErr: printErr ("\nerror loading file: status = 0x%x.\n", errnoGet ()); close (fd); return (ERROR); } #endif /* INCLUDE_RAM_BOOT */ From goodrich@cabernet.tuc.noao.edu Fri Jul 8 15:58:20 1994 From: goodrich@cabernet.tuc.noao.edu (Bret Goodrich) Date: Fri Jul 8 15:58:37 PDT 1994 Subject: REPOST try #2 Re: Booting VxWorks from NVRAM # REPOST again # # Aha! My original mail message has a dot in one of the line's first column. # It's an artifact of "diff". Strip the leading ">" from the rest of this # post. Sorry for the wasted bandwidth. At least it's better than # "Status of: Status of: Status of: ..." :-). # # bret >Here are the four diff files for adding RAM booting to VxWorks 5.1.1. These >files were created from "diff -e", so you can run them through "ed" to convert >the originals. I haven't bothered to package them into a nice "patch" script >but the changes are minor. As always, back up the originals. The four files >can be modified with the following: > ># in $VXWORKS/config/all >mv bootConfig.c bootConfig.c.BAK >(cat bootConfig.c.diff; echo '1,$p') | ed - bootConfig.c.BAK > bootConfig.c >mv usrConfig.c usrConfig.c.BAK >(cat usrConfig.c.diff; echo '1,$p') | ed - usrConfig.c.BAK > usrConfig.c > ># in $VXWORKS/src/config >mv usrLoadSym.c usrLoadSym.c.BAK >(cat usrLoadSym.c.diff; echo '1,$p') | ed - usrLoadSym.c.BAK > usrLoadSym.c >mv usrNetwork.c usrNetwork.c.BAK >(cat usrNetwork.c.diff; echo '1,$p') | ed - usrNetwork.c.BAK > usrNetwork.c > >Edit your BSP config.h file for the *minimum* system you need for the boot ROM >(remember to include "#define INCLUDE_RAM_BOOT"), then compile with >"make bootrom.hex". Burn your boot EPROMs and install them. > >Edit your BSP config.h file for your *standard* VxWorks system (include >"#define INCLUDE_RAM_BOOT" if you wish to continue to have access to the RAM >disk), then compile with "make vxWorks". > >Boot up your VxWorks target using the original boot device (non-RAM). Install >a DOS file system on the RAM disk. Copy files $VXWORKS/config//vxWorks >and $VXWORKS/config//vxWorks.sym to the RAM disk. You may also want >to add a "startup.cmd" file to the RAM disk. Change the boot parameters >for boot device ("ram=800000,800" or similiar), file name ("/ram/vxWorks"), >and startup script ("/ram/startup.cmd" or equivalent). Reboot. > >If you have any problems with the patch or the final results, please email me. >If you need the full source files i can arrange to send them to you or set >up an ftp site. > >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 > > >---cut here-------------------bootConfig.c.diff---------------------cut here--- >1664a > >#ifdef INCLUDE_RAM_BOOT > >#include "vxLib.h" > >/******************************************************************************* >* >* ramLoad - load a vxWorks image from a local RAM disk >*/ > >LOCAL STATUS ramLoad > ( > char *ramAdrs, > int nBlocks, > char *fileName, > FUNCPTR *pEntry > ) > { > int fd; > BLK_DEV * pRamBlkBootDev; > char bootDir[BOOT_FILE_LEN]; > char * i; > > /* create a block device spanning entire disk (non-destructive!) */ > > for (i = ramAdrs; i < ramAdrs + nBlocks*512; i += 512) > if (vxMemProbe (ramAdrs, VX_READ, sizeof (int), (char *) &fd) == ERROR) > { > printErr ("Invalid RAM address 0x%x.\n", (int) i); > return (ERROR); > } > > if ((pRamBlkBootDev = ramDevCreate (ramAdrs, 512, 0, nBlocks, 0)) == NULL) > { > printErr ("pRamBlkBootDev failed.\n"); > return (ERROR); > } > > dosFsInit (NUM_DOSFS_FILES); /* initialize DOS-FS */ > > /* split off boot device from boot file */ > > devSplit (fileName, bootDir); > > /* initialize the boot block device as a dosFs device named */ > > if (dosFsDevInit (bootDir, pRamBlkBootDev, NULL) == NULL) > { > printErr ("dosFsDevInit failed.\n"); > return (ERROR); > } > > printErr ("done.\n"); > > /* load the boot file */ > > printErr ("Loading %s...", fileName); > > fd = open (fileName, O_RDONLY, 0); > > if (fd == ERROR) > { > printErr ("\nCannot open \"%s\".\n", fileName); > return (ERROR); > } > > if (bootLoadModule (fd, pEntry) != OK) > goto readErr; > > close (fd); > return (OK); > >readErr: > > printErr ("\nerror loading file: status = 0x%x.\n", errnoGet ()); > close (fd); > return (ERROR); > } > >#endif /* INCLUDE_RAM_BOOT */ >. >1446a >#endif /* INCLUDE_SCSI_BOOT || INCLUDE_RAM_BOOT */ > >#ifdef INCLUDE_SCSI_BOOT > >#define SPIN_UP_TIMEOUT 45 /* max # of seconds to wait for spinup */ > >. >1404,1405d >1402c >#if defined(INCLUDE_SCSI_BOOT) || defined (INCLUDE_RAM_BOOT) >. >1115a >#ifdef INCLUDE_RAM_BOOT > > if (strncmp (params.bootDev, "ram", 3) == 0) > { > int ramAdrs; > int nBlocks; > > if (strlen (params.bootDev) == 3) > { > printErr ("No RAM boot address,#blocks given\n"); > return (ERROR); > } > > sscanf (params.bootDev, "%*3s%*c%x%*c%x", &ramAdrs, &nBlocks); > > if (ramLoad ((char *) ramAdrs, nBlocks, params.bootFile, pEntry) != OK) > { > printErr ("\nError loading file: errno = 0x%x.\n", errno); > return (ERROR); > } > > return (OK); > } > >#endif /* INCLUDE_RAM_BOOT */ > >. >962c > printf ("Version: %s-RAM\n", vxWorksVersion); >. >451a >#ifdef INCLUDE_RAM_BOOT >LOCAL STATUS ramLoad(); >#endif /* INCLUDE_RAM_BOOT */ >. >419a >#ifdef INCLUDE_RAM_BOOT >LOCAL STATUS ramLoad (char *ramAdrs, int nBlocks, char *fileName, > FUNCPTR *pEntry ); >#endif /* INCLUDE_RAM_BOOT */ >. >176a >#include "ramDrv.h" >. >8a > 05jul94,bdg added RAM boot option > >. >---cut here-------------------bootConfig.c.diff---------------------cut here--- > >---cut here--------------------usrConfig.c.diff---------------------cut here--- >633a > > >/******************************************************************************* >* >* usrRamConfig - initialize boot RAM disk >*/ > >LOCAL STATUS usrRamConfig () > { > BLK_DEV *pRamDev; > int ramAdrs; > int nBlocks; > > if (strncmp (sysBootParams.bootDev, "ram", 3) == 0) > { > sscanf (sysBootParams.bootDev, "%*3s%*c%x%*c%x", &ramAdrs, &nBlocks); > if ((pRamDev = ramDevCreate ((char *) ramAdrs, 512, 0, nBlocks, 0)) > == NULL) > { > printErr ("pRamDev failed\n"); > return (ERROR); > } > > if ((dosFsDevInit ("/ram/", pRamDev, NULL)) == NULL) > { > printErr ("dosFsDevInit failed.\n"); > return (ERROR); > } > } > > return (OK); > } >. >468a > /* initialize RAM disk */ >#ifdef INCLUDE_RAMDRV > usrRamConfig (); >#endif /* INCLUDE_RAMDRV */ > >. >187a >LOCAL STATUS usrRamConfig (); >. >8a > 06jul94,bdg added usrRamConfig() and call to it in usrRoot(). > >. >---cut here--------------------usrConfig.c.diff---------------------cut here--- > >---cut here-------------------usrLoadSym.c.diff---------------------cut here--- >46,47d >43c > if (strncmp (sysBootParams.bootDev, "scsi", 4) == 0) > sprintf (symTblFile, "%s.sym", sysBootParams.bootFile); > > else if (strncmp (sysBootParams.bootDev, "ram", 3) == 0) > sprintf (symTblFile, "%s.sym", sysBootParams.bootFile); > > else >. >7a > 06jul94,bdg modified symtab filename for ram boot. > >. >---cut here-------------------usrLoadSym.c.diff---------------------cut here--- > >---cut here-------------------usrNetwork.c.diff---------------------cut here--- >318a > } > else > { > /* booting via ethernet */ > > if ((usrNetIfAttach (params.bootDev, params.ead) !=OK) || > (usrNetIfConfig (params.bootDev, params.ead, params.targetName, > netmask) !=OK)) > return (ERROR); >. >304,312d >302c > /* booting via scsi or ram, configure network if included */ >. >300c > if (strncmp (params.bootDev, "scsi", 4) == 0 || > strncmp (params.bootDev, "ram", 3) == 0) >. >7a > 06jul94,bdg modified network creation for ram boot > >. >---cut here-------------------usrNetwork.c.diff---------------------cut here--- From daemon@vxw.ee.lbl.gov Sat Jul 9 04:00:24 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jul 9 04:00:35 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jul 9 04:00:14 PDT 1994 Subject: HELP NEEDED: from socket/RPC experts Subject: Re: Floating point on 040 Subject: SCSI 5394 driver ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.windows.interviews Subject: HELP NEEDED: from socket/RPC experts Date: 8 Jul 1994 15:29:21 GMT From: chandy@hellix.inria.fr (Chandra Shekhar) Organization: INRIA, Sophia-Antipolis (Fr) Message-ID: <2vjrch$4g8@sophia.inria.fr> Hi Folks, I am trying to establish two-way communication between a M68040/VxWorks real-time application (the client) and an InterViews graphical interface on Sun4/Unix (the server). Basically, I'd like to be able to display the status of the various VxWorks tasks on the GUI. The obvious way to do this is to use sockets or better, RPCs. I have looked at the following (1) the VxWorks client-server demo (2) the VxWorks sprites demo (3) the InterViews plot/sendplot demo. I am still at a loss as to how to make the two applications communicate. The InterViews application seems to be heavily dependent on a special protocol (RpcHdr, etc.), which are not available under VxWorks. So how do I go about it? I'd greatly appreciate any advice on this subject. I'd prefer using RPC's to sockets, but advice on the use of either is welcome. Thank you. Chandy --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Floating point on 040 Date: 8 Jul 1994 17:13:54 -0400 From: Jcreem@deathstar.cris.com (Jeff Creem) Organization: Concentric Research Corporation Message-ID: <2vkfii$a37@deathstar.cris.com> References: <9407071836.AA19343@imatron.com> iIf you are using Ada we have used the mathg packages from the wuarchive (PAL Public Ada Library) with some modification and gotten both single and double precision to run faster (about 2-1 increase for single vs vxworks double and about 10% increase for double vs double) Let me know if you are interested Jeff Creem jcreem@cris.com --------------------------- Newsgroups: comp.os.vxworks Subject: SCSI 5394 driver Date: Sat, 9 Jul 1994 06:21:43 GMT From: robnett@netcom.com (Glenn Robnett) Organization: NETCOM On-line Communication Services Message-ID: Sender: robnett@netcom.com Is anyone aware of an existing 5394 SCSI driver running under VxWorks? TIA, Glenn --------------------------- End of New-News digest ********************** From pdw@sunbar.mc.duke.edu Mon Jul 11 08:49:14 1994 From: "Patrick D. Wolf" Date: Mon Jul 11 08:49:23 PDT 1994 Subject: 3u ethernet cards Does anybody know of any 3U VME ethernet cards that have VxWorks support? Thanks in advance, Patrick Wolf Duke University 919-660-5114 pdw@sunbar.mc.duke.edu From gordon@tpocc.gsfc.nasa.gov Mon Jul 11 12:31:32 1994 From: gordon@tpocc.gsfc.nasa.gov (Gordon Miller) Date: Mon Jul 11 12:31:41 PDT 1994 Subject: Re: 3u ethernet cards Patrick Wolf wrote: > Does anybody know of any 3U VME ethernet cards that have VxWorks support? You should check with Mizar. They have a line of 3u 680x0 based cards. 68010 Mizar 8115 68020 Mizar 8120 68030 Mizar 8130 68040 Mizar 8140 I have used these boards in custom applications requiring a cpu. They have a an optional "MX bus" interface for custom work. I seem to remember that direct WRS support for these boards was disappearing. I don't know what the deal is these days. Give Mizar or Wind River a call. Mizar can be reached at (800) 635-0200. You know how to reach WRS. Gordon Miller Integral Systems, Inc. gordon@tpocc.gsfc.nasa.gov 1100 West Street, CSC/LR (301) 497-2416 Laurel, MD 20707 From andy@oe.fau.edu Mon Jul 11 14:09:11 1994 From: "Mr.Andrew Shein" Date: Mon Jul 11 14:09:19 PDT 1994 Subject: Re: 3u ethernet cards Does anybody know of any 3U VME ethernet cards that have VxWorks support? Thanks in advance, Patrick Wolf Duke University 919-660-5114 pdw@sunbar.mc.duke.edu Hi We use a set of 3U cards from O+R. They are very low power and we have drivers for meny of the cards (AD, DA, Seral, DIG I/O) We have been using them for about 2 years and have most of the bugs worked out. You can contact Mike Horan at Dynatem for more info at 714 - 855 - 3235 Andy Shein Florida Atlantic University Dept. Ocean Engineering 407 367 2854 "Home of the worlds fastest Human Powered Sub" From vessels@ahi.geg.mot.com Mon Jul 11 15:15:37 1994 From: vessels@ahi.geg.mot.com (Pat Vessels x2465) Date: Mon Jul 11 15:15:47 PDT 1994 Subject: vxWorks & 1553 boards Hi, I am trying to find information on vxWorks 1553 boards (vme preferably). There was an entry in a vxWorks newsgroup that had your address associated with it. Do you have any information you can send me, or know who I can contact that does? Thanks, Pat Vessels From C43TLM_at_US-SBDSO-CC07@ccintgw.dso.delcoelect.com Mon Jul 11 16:30:59 1994 From: "C43TLM" Date: Mon Jul 11 16:31:08 PDT 1994 Subject: Serial Keyboard Driver I have a MVME167 board running VADSworks. I am looking for an example of a Serial Keyboard Driver preferably written in Ada, but C works too. I thank you in advance if anyone has one I can use. Tim Miller c43tlm@ccintgw.dso.delcoelect.com From stan@lassen.rti.com Mon Jul 11 18:03:17 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Mon Jul 11 18:03:25 PDT 1994 Subject: Re: Memory leak in TCL >> Subject: Memory leak in TCL >> Date: 6 Jul 1994 14:11:19 -0700 >> From: rls@ltis.loral.com (Randy Silagi) >> >> I have been using Joe VanAndel's port of TCL 7.0. I have found a memory >> leak when a procedure is called. I have created some procedures and a >> script that calls the procedures. Whenever a procedure, that I >> created, is run I lose 160 bytes of memory. I am running this on a >> Force '040, with 4 megs. memory, and VxWorks 5.1.1. The number of bytes >> lost is always 160, it does not depend on the size of the procedure >> called. I found this problem using memShow. >> >> Does anyone have any ideas what is causing this? Has anyone else had >> this problem? Where can I look to fix this? I do have the source code, >> but do not have the time to investigate the TCL source code. If >> someone has already fixed this problem please let me know. >> >> >> I couldn't recreate this. Creating a procedure allocated some memory. For instance, after running "proc plus {a b} {expr $a+$b}", as in the example, I got this (view this with a wide window): rshell1-> HeapTraceShow 5 Blocks Total Call stack (to depth 5) 1 58 _tclMain _Tcl_RecordAndEval _Tcl_Eval _Tcl_ProcCmd _Tcl_DbCkalloc 1 53 _tclMain _Tcl_RecordAndEval _Tcl_Eval _Tcl_ProcCmd _Tcl_DbCkalloc 2 104 _tclMain _Tcl_RecordAndEval _Tcl_Eval _Tcl_ProcCmd _Tcl_DbCkalloc 1 63 _Tcl_Eval _Tcl_ProcCmd _Tcl_CreateCommand _StringCreate _Tcl_DbCkalloc 1 58 _Tcl_RecordAndEval _Tcl_Eval _Tcl_ProcCmd _Tcl_CreateCommand _Tcl_DbCkalloc However, running the new proc (e.g. "plus 4 5") didn't allocate anything new. What were you running? -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From daemon@vxw.ee.lbl.gov Tue Jul 12 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jul 12 04:00:33 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jul 12 04:00:12 PDT 1994 Subject: Subject: flash file system code available ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Date: 11 Jul 94 13:16:42 EST From: w604328s@edinboro.edu Organization: Edinboro University of PA Message-ID: <1994Jul11.131642.12784@edinboro.edu> Need a source for code examples for VxWorks Interrupts and A/D ; D/A drivers. You can reply here or to alp@mpd.lord.com. Thanks... --------------------------- Newsgroups: comp.os.vxworks Subject: flash file system code available Date: 11 Jul 1994 11:37:18 -0700 From: billr@saab.cna.tek.com (Bill Randle) Organization: Tektronix, Inc., Redmond, OR Message-ID: <2vs3gu$667@saab.cna.tek.com> After posting a note about our Flash filesystem code, I was inundated with requests for a copy of the source. Rather than email it to all the individuals that requested it, I put a copy on the archive server. It is currently in the "/pub/incoming" directory on thor.ucar.edu as "flash.zip". The main parts are the filesystem code, which is derived from dosFsLib.c and the actual driver file flashDrv.c (which uses flash.c to read/write/erase the flash parts). I was unwilling to distribute flashFsLib.c unless the receiver indicated they actually had a source license. Thus, this file is distributed as a context diff relative to the 5.1 version of dosFsLib. Even though the diff is larger than the original, the core changes are fairly minor - most of the diffs are due to name changes from "dosFsXXXX" to "flashFsXXXX". Finally, while the driver and filesystem are fairly generic, some other parts are specific to our actually system and may need to be changed for your use. -Bill Randle Tektronix, Inc. billr@saab.CNA.TEK.COM --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Wed Jul 13 04:00:30 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jul 13 04:00:41 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jul 13 04:00:16 PDT 1994 Subject: 1553 Boards Subject: Re: Status of : Status of : Status of : Status o ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: 1553 Boards Date: Mon, 11 Jul 1994 22:24:05 GMT From: vessels@ahi (Pat Vessels x2465) Organization: MOTOROLA Message-ID: <1994Jul11.222405.19377@schbbs.mot.com> Sender: news@schbbs.mot.com (Net News) Awhile back someone posted a list of 1553 boards they had researched or tested. We are in the marked for a VME 1553 board running vxWorks. Ideally using a 68020 processor and having at least 4 MB RAM. I am interested anything anyone has. Please enclose dealer contact if possible. Thanks, Pat Vessels --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Status of : Status of : Status of : Status o Date: 13 Jul 1994 06:28:35 GMT From: bindi@mrad.com.au (Bindi Hawkey) Organization: MRad Pty Ltd, Australia Message-ID: <3001ij$p9j@zeppo.mrad.com.au> References: Reply-To: bindi@mrad.com.au Can anyone do anything about this person who keeps mailing complete rubbish to comp.os.vxworks? - --- Bindi Hawkey Email : bindi@mrad.com.au Systems Engineer Phone : (08) 260 8965 (work) MRad Pty Ltd Adelaide, AUSTRALIA --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Thu Jul 14 04:00:35 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jul 14 04:00:45 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jul 14 04:00:23 PDT 1994 Subject: Archive Notes Subject: Recommd. for 488 board Subject: looking for SCSI recommendation Subject: routing between multiple ethernets ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Archive Notes Date: 13 Jul 1994 15:50:26 GMT From: thor@ymir.atd.ucar.edu (Rich Neitzel) Organization: National Center for Atmospheric Research Message-ID: <3012g2$bpp@ncar.ucar.edu> Sender: thor@ymir (Rich Neitzel) First, I shall be on vacation until August, so any problems, submissions, etc. should be held until then. Second, please remember to tell me if you put something into /pub/incoming. This directory cannot be read by outside users, so your submission will not be available unless I move it into the vx directory. - -- Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjx'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------- Newsgroups: comp.os.vxworks Subject: Recommd. for 488 board Date: Wed, 13 Jul 1994 18:11:31 GMT From: lacy@draper.com (Carl Lacy) Organization: Draper Laboratory Message-ID: <1994Jul13.181131.11146@draper.com> Sender: nntp@draper.com (NNTP Master) Would anyone have a recommendation for a 488 board for which a a VxWorks driver is available/supported? Many thanks --------------------------- Newsgroups: comp.os.vxworks Subject: looking for SCSI recommendation Date: 13 Jul 1994 19:27:50 GMT From: gagnon@rsf.atd.ucar.edu (Rich Gagnon) Organization: National Center for Atmospheric Research Message-ID: <301f7m$qo2@ncar.ucar.edu> I am looking for recomendations on 6U VME SCSI controller boards which have a good record for ease of use under VX5.1. The board will reside in a VME basket running VX5.1 an a 68030 and will have to deliver data to an Exabyte 8505 and a Seagate Barracuda disk drive (fast SCSI-2). It should have dma capability, but it need not be all that fast; on the order of 5 mBytes/sec would be sufficient for now. I do not want to have to write driver code for it as I need to get this up and running quickly, so a fully supported software package is a must. Please E-mail responses and I will summerize if anyone is interested. Thanks in advance, - -- Rich Gagnon Internet:gagnon@ncar.ucar.edu NCAR - ATD/RSF P.O Box 3000 Fax: 303-497-2044 Boulder, CO 80307-3000 Voice: 303-497-2076 --------------------------- Newsgroups: comp.os.vxworks Subject: routing between multiple ethernets Date: 13 Jul 1994 19:17:57 GMT From: singer@osfrt.mro1.dec.com (Matt Singer) Organization: Digital Equipment Corporation Message-ID: <301el5$a7v@mrnews.mro.dec.com> Reply-To: singer@osfrt.mro1.dec.com (Matt Singer) Sender: singer@osfrt (Matt Singer) Has anyone ever attempted to run an on SBC ethernet and an off card net at the same time an route between them? Either it just doesnt work, or I'm just not getting the routing table right. I'm running a CMC ENP 10 in addition to the SBC. I can ping either one from a host on its net, but cant get it to forward from one interface to the other... Contact from anyone who has tried this is welcome... - -- - ------------------------------------------------------------------------------- Matthew R. Singer LM Technology Systems Engineer Systems & Software Consulting singer@osfrt.mro1.dec.com VxWorks/Unix/MS-DOS/X Window/Motif 508-467-9108 508-877-8736 - ------------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From vdbent@rulrol.leidenuniv.nl Thu Jul 14 06:36:18 1994 From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent) Date: Thu Jul 14 06:36:27 PDT 1994 Subject: Looking for Mizar MZ7850 & MZ7130 BSP Hi, I've tried to port the BSPs of a Mizar MZ7130 having the MZ7850 Ethernet Daughterboard attached to it, to VxWorks 5.1 (coming from 5.0.2b). The recompiled MZ7850 driver does not seem to work. Since I'm not familiar with this kind of drivers, it is hard for me to find out what's wrong. Before I waiste a lot of time learning to understand how this driver works, could someone please help me with getting the updated BSPs (object code only would do, but if I could get the source ...). Thanks a lot, Kees van der Bent vdbent@rulrol.LeidenUniv.nl Space Research Organisation Netherlands -------------------------------------------------------- From rhin!joergb@lbl.gov Thu Jul 14 07:18:25 1994 From: rhin!joergb@lbl.gov Date: Thu Jul 14 07:18:34 PDT 1994 Subject: IP Modules for VxWorks Greetings, I try to put together a list of available VxWorks drivers for IP modules. If anybody has a driver or know where to get a driver for an IP-module please let me know. All information would be appreciated (price is always of great interest too). Thanks in advance Joerg Bertholdt, FAE Wind River Systems GmbH, Germany email: joergb@wrsec.fr From has@snmy.info.kobelco.co.jp Fri Jul 15 00:39:24 1994 From: Sigeo Hasegawa Date: Fri Jul 15 00:39:35 PDT 1994 Subject: MS-C graphic library for x86(PC-AT) I wish to get MS-C graphic library for vxWorks-x86. Anyone who had developed it or used it, please recommend it for me. Regards, --------------------------------------------------- Electronics & Information Division KOBE STEEL, LTD. Shigeo Hasegawa TEL: 81-78-261-6460 FAX: 81-78-261-6499 E-mail: has@info.kobelco.co.jp --------------------------------------------------- From daemon@vxw.ee.lbl.gov Fri Jul 15 04:00:32 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jul 15 04:00:43 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jul 15 04:00:21 PDT 1994 Subject: Re: 3u ethernet cards Subject: backplane sockets Subject: Streams? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: 3u ethernet cards Date: Thu, 14 Jul 1994 16:38:20 GMT From: charpentier@mickey.mc.ti.com Organization: Texas Instruments M&C Group Message-ID: <1994Jul14.113820.1@mickey.mc.ti.com> References: <199407111549.LAA00942@pat.mc.duke.edu> Sender: usenet@pan.mc.ti.com (USENET News System) In article <199407111549.LAA00942@pat.mc.duke.edu>, "Patrick D. Wolf" writes: > > Does anybody know of any 3U VME ethernet cards that have VxWorks support? > > Thanks in advance, > > Patrick Wolf > Duke University > 919-660-5114 > pdw@sunbar.mc.duke.edu > Try: PEP Modular Computers phone: 1-800-228-1737 Andre Charpentier --------------------------- Newsgroups: comp.os.vxworks Subject: backplane sockets Date: Thu, 14 Jul 1994 23:45:11 GMT From: healy@cod.nosc.mil (Mike Healy) Organization: NCCOSC RDT&E Division, San Diego, CA Keywords: CPU-40 Message-ID: <1994Jul14.234511.7147@nosc.mil> Sender: news@nosc.mil I have sized up a data structure that is being passed accross the backplane using tcp/ip sockets. The board now crashes and burns when it tries to write the data to the socket. Is there a max buffer length that can be written to a backplane socket? Where is this max length configured? We are using Force CPU-40s and vxWorks 5.1. Thanks Mike Healy healy@nosc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Streams? Date: Thu, 14 Jul 1994 16:42:30 GMT From: Kevin Bonifield Organization: SpaceCom Systems, Inc. Message-ID: Sender: news@spacecom.com Does anyone have info on the new Streams package from WRS? //Kevin --------------------------- End of New-News digest ********************** From del@rst.com Fri Jul 15 09:04:00 1994 From: del@rst.com (Mark Del Giorno) Date: Fri Jul 15 09:04:09 PDT 1994 Subject: MV162 IP Interrupts Heyyyyyyyyyyyyyyyyyyyyy, I have an MV162 board and am finishing up a driver for an IP module that we designed (CANbus). I've successfully programmed the IPIC for memory accesses as well as the MMU (by changing sysLib.c). The question now is: How do I know which interrupt vectors are available for use by each of the IP's? Is there a set of vectors that are recommended? (WRS doesn't really support the IP-portion of the 162 board and recommended I post this question here). Also, the IPIC can be programmed to interrupt on any of the 7 hardware levels. Am I restricted in choosing my level in any way? (It would be nice if there was a list of all the devices and the levels they interrupt the processor on...) Thanks in advance for the help.... _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com) _/ _/ _/ _/ (410) 876-9200 Fax: 876-9470 _/_/_/_/ _/_/_/_/ _/ Robotic Systems Technology _/ _/ _/ _/ 1110 Business Parkway South _/ _/ _/_/_/_/ _/ Westminster, MD 21157 From daemon@vxw.ee.lbl.gov Sun Jul 17 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Jul 17 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jul 17 04:00:13 PDT 1994 Subject: qsort bug Subject: WDOG_ID structure? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: qsort bug Date: Fri, 15 Jul 1994 19:33:08 GMT From: dombrows@lds.loral.com (Brian Dombrowski, 5424) Organization: Loral Data Systems Message-ID: <1994Jul15.193308.16849@lds.loral.com> Reply-To: dombrows@lds.loral.com Sender: news@lds.loral.com Hi: We are running VxWorks 5.1 on a Fujitsu SPARClite based board. I attempted to use qsort() ( the standard C quick sort routine ) and to my surprise it dies! I get a address not aligned trap. The code that calls it is fine. Has anyone else experience problems with the VxWorks qsort()? I don't want to wait a year for WRS tech support. Here is some post mortem output: - -> ti t2 NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY - ---------- ------------ -------- --- ---------- -------- -------- ------- ----- t2 _dumpDiagLis 4df8cf8 100 SUSPEND 4dfa734 4df8998 0 0 stack: base 0x4df8cf8 end 0x4df3ed8 size 19992 high 3464 margin 16528 options: 0x1d VX_SUPERVISOR_MODE VX_DEALLOC_STACK VX_FP_TASK VX_STDIO %pc = 4dfa734 %npc = 4dfa738 %psr = 29010c0 %wim = 20 %tbr = 4101070 %y = 0 %g0 = 0 %g1 = ac %g2 = 8000000 %g3 = 0 %g4 = 0 %g5 = 4190148 %g6 = 419ff60 %g7 = 8 %i0 = 4dfb19e %i1 = 4dfb1c8 %i2 = 0 %i3 = ffffff98 %i4 = ffffffff %i5 = 54 %fp = 4df8a08 %i7 = 4124e68 %l0 = 4fb2810 %l1 = 411bd30 %l2 = 411bd34 %l3 = 1 %l4 = 4197b38 %l5 = 0 %l6 = 4 %l7 = 400 %o0 = 4dfb19e %o1 = 4dfb1c8 %o2 = 80000000 %o3 = 0 %o4 = 0 %o5 = ffff0001 %sp = 4df8998 %o7 = 410ff84 Exception: Memory Address Not Aligned program counter: 0x04dfa734 next program counter: 0x04dfa738 processor status register: 0x029010c0 access address: 0x04dfb19e value = 81759480 = 0x4df8cf8 - -> tt t2 417e0a8 _vxTaskEntry +c : 10c6 (0, 0, 0, 0, 0, 0) 4dfa66c _dumpDiagList +ac : _qsort (&diagxref.o_bss, ac, c, &_cmpDiagRec, 4dfa400, ffff0001) 4124d70 _qsort +30 : 412516c (4dfb174, ac, 9, &_cmpDiagRec, 0, 0) 412506c _qsort +32c: 4124d80 (4dfb174, 4, 57, &_cmpDiagRec, ffffffff, ac) 412506c _qsort +32c: 4124d80 (4dfb19e, 2a, 4, &_cmpDiagRec, ffffffff, 4) 4124e68 _qsort +128: ffffff98 (4dfb19e, 4dfb1c8, 0, ffffff98, ffffffff, 54) value = 0 = 0x0 --------------------------- Newsgroups: comp.os.vxworks Subject: WDOG_ID structure? Date: 15 Jul 1994 03:21:23 GMT From: bindi@mrad.com.au (Bindi Hawkey) Organization: MRad Pty Ltd, Australia Message-ID: <304vbj$bc9@zeppo.mrad.com.au> Reply-To: bindi@mrad.com.au In an application I am developing, I would like my code to determine how many ticks are remaining before a watchdog timer times out. I have seen wdShow(), but that displays information on the screen. Where can I find out the fields that are in WDOG_ID structures? I've looked in all the .h files etc. It must be defined _somewhere_! Thanks in advance, Bindi - --- Bindi Hawkey Email : bindi@mrad.com.au Systems Engineer Phone : (08) 260 8965 (work) MRad Pty Ltd Adelaide, AUSTRALIA --------------------------- End of New-News digest ********************** From atl@adaclabs.com Mon Jul 18 08:06:18 1994 From: atl@adaclabs.com (Anthony Le) Date: Mon Jul 18 08:06:26 PDT 1994 Subject: Re: Booting VxWorks from NVRAM Please send me the diffs of this implementation. I am very interest. My e-mail is: atl@adaclabs.com Thanks you. Anthony Le From atl@adaclabs.com Mon Jul 18 09:26:10 1994 From: atl@adaclabs.com (Anthony Le) Date: Mon Jul 18 09:26:18 PDT 1994 Hello "Vxperts". This is a question about Address Modifier(AM) Code on VME bus. Can anyone explain to me the AM code on VME bus? I am currently writing code for MVME-147 CPU to control the hardware which responding to the AM code 0x39. The hardware is resided in A24/D16 address space. The "DEFAULT" AM code which I can capture is 0x3D on the VME bus (by using my VMETRO logic analyzer to capture). VxWorks does not set this value (or at least set to dynamic AM code). I know I have to specifically set one register to output AM code 0x39 on the VMEbus for my MVME-147 CPU. Is there anyway I can set VxWorks to control the CPU to output AM code 0x39 at kernel level (default value)? - Why AM code? - What it use for? - What do they mean for different values? - What different between dynamic and static AM code? - Does It effect other hardware when I set AM code equals 0x39 all time? - When can I use other codes and for what purpose? - Why is It complicate like this? It seems to me nobody care about AM code on VME bus when designing the hardware. Thanks. Anthony Le. -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- Anthony T. Le _/_/ _/_/_/_/_/ _/ Sr. Software Engineer _/ _/ _/ _/ ADAC LABS Inc. _/_/_/ _/ _/ 540 Alder Dr. _/ _/ _/ _/ Milpitas, CA 95035 _/ _/ _/ _/_/_/_/ e-mail: atl@adaclabs.com phone: (408)321-9100 x1667 -*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-*- From tsb@mclean.sparta.com Mon Jul 18 11:36:51 1994 From: tsb@mclean.sparta.com (Todd S. Brackett) Date: Mon Jul 18 11:37:00 PDT 1994 Subject: RE: AM Codes Anthony Le writes ... > > Can anyone explain to me the AM code on VME bus? > > - Why AM code? > - What it use for? > - What do they mean for different values? > - What different between dynamic and static AM code? > - Does It effect other hardware when I set AM code equals 0x39 all time? > - When can I use other codes and for what purpose? > > - Why is It complicate like this? > > It seems to me nobody care about AM code on VME bus when designing > the hardware. > Wrongo!!!!!!! Address modifiers are extremely important. -------------------------------------------------- > - Why AM code? > - What it use for? Address modifiers are a way of describing the address space available to you on the VMEbus. These codes exist so that a wide variety of options are available to the designer. The functions can be broken into three basic groups. 1) Address size The first function described by AM codes is the physical size of a VMEbus address. In fact, the codes are "grouped" by this portion of the AM. The choices are: Short I/0 A16 0x29 and 0x2D Standard A24 0x38-0x3F Extended A32 0x08-0x0f Long A64 0x00-0x07 2) Data Space The next function defines the type of data space. There are 2 types of access to data. Supervisor Non-Privileged 3) Transfer Type The third function describes the transfer type, there are 4 types of transfer (only two in Short I/O, program and data) Block Transfer Program Data 64-Bit Block Transfer ------------------------------------------------ > - What do they mean for different values? > - When can I use other codes and for what purpose? Here is a useful table (all values are hex) All other codes are reserved 3F STD SUP BLK 3E STD SUP PRO 3D STD SUP DAT 3C STD SUP B64 3B STD NON BLK 3A STD NON PRO 39 STD NON DAT 38 STD NON B64 2D SHT SUP 29 SHT NON 10-1F USR 0F EXT SUP BLK 0E EXT SUP PRO 0D EXT SUP DAT 0C EXT SUP B64 0B EXT NON BLK 0A EXT NON PRO 09 EXT NON DAT 08 EXT NON B64 07 LNG SUP BLK 06 LNG SUP PRO 05 LNG SUP DAT 04 LNG SUP B64 03 LNG NON BLK 02 LNG NON PRO 01 LNG NON DAT 00 LNG NON B64 ----------------------------------------------------- > - What different between dynamic and static AM code? (At least to me, TSB) 1) FIXED Your local CPU's memory map is sliced into chunks which describe the way in which the CPU "gets" to the VMEbus. This is usually done in hardware (PALs hopefully) and is completely tranparent to the CPU and thus the OS. In this case there is no way to change the values on the fly. 2) STATIC Your local CPU has access to a register which can configure the AM code. This means that routines can be written which change the AM for various access to the VMEbus. Routines may have been written to support this in your BSP (look in sysLib.c or ../src/drv/vme for these things). If not, then you would have to write them yourself. 3) DYNAMIC The 68K has Function code lines which describe the nature of the access (FC0-2) These lines can be directly routed out as part (low bits) of the AM code. This along with the Address (FIXED Model) sets the AM code. Your '147 can be DYNAMIC or STATIC. (I have a manual, but no BSP sorry.) There is a register in the VMEchip that sets AM Code value. ---------------------------------------------------- > Is there anyway I can set VxWorks to control the CPU to output AM code > 0x39 at kernel level (default value)? I don't think you can do that since it is hardware specific. Secondly, VxWorks is always in Supervisior state (This explains your 3D vs 39 access). The only way I know to change that would be at the assembly language level. Plan B That same register has an AMSEL bit (7) which will always force the register values out on the bus. Set the bit to one (1) to do this. SYSRESET will make it 0. ----------------------------------------------------- > - Does It effect other hardware when I set AM code equals 0x39 all time? Maybe, maybe not. I depends on the capability of the other hardware. Perhaps the slave hardware only responds in the Short I/O space. A 0x39 might issue you a Bus Error. ----------------------------------------------------- > - Why is It complicate like this? > > It seems to me nobody care about AM code on VME bus when designing > the hardware. The reason this exists is partly history and partly flexibility. Originally VMEbus only had A24/D16 support (P1). 3U CPU boards are still quite common and are used regularly. If you are designing a simple system then you probably don't care much about AM codes but you still must use them correctly. By having AM codes I can integrate a wide variety of components which do not have to reside in the same address space or be accessed in the same fashion. This gives me the freedom to pick and choose my components as required. In many cases it directly affects the price of the VMEbus board (Price any VME64 hardware lately?). This way you can tailor the performace and capabilities of your system. Every hardware designer MUST account for proper AM code decoding on their boards. Sometimes this is configured in a PLD, jumpers or switches. It is a common practice to allow the board to decode several address modifier types at once. (eg A24/A32 Memory boards) You must RTFM ;) to find out the details of your particular hardware. I hope this has been useful........ Regards, ----------------------------------------------------------- |Todd S. Brackett | Voice -> 703 448 1683 x249 | |tsb@mclean.sparta.com | FAX -> 703 734 3323 | |_________________________________________________________| | | | /\\ SPARTA, Inc. | | ///\\ 7926 Jones Branch Drive | | /////\\ Suite 900 | | ///// \\ McLean, VA 22102 | | / \\\\\ \\ "Life is like baseball, | | \ \\\\\ // some days you win, | | \ ////// some days you loose, | | \////// SPARTA some days it rains..." | | \//// Pride In Performance | | \// | ___________________________________________________________ From daemon@vxw.ee.lbl.gov Tue Jul 19 04:00:28 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jul 19 04:00:42 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jul 19 04:00:16 PDT 1994 Subject: VxWorks and Imaging Technology 150/40 compatibility Subject: 5.1.1 Memory leak Subject: Re: AM Codes Subject: How to display console output of a MVME167 to a window on a Sun SPARC10 w/s? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks and Imaging Technology 150/40 compatibility Date: 18 Jul 1994 20:04:40 GMT From: hpotlap@sparc11.tx.ncsu.edu (HARSHAVARDHAN POTLAPALLI) Organization: College of Textiles, North Carolina State University Message-ID: <30en8o$bdq@taco.cc.ncsu.edu> Followup-To: comp.os.vxworks Reply-To: hpotlap@sparc11.tx.ncsu.edu (HARSHAVARDHAN POTLAPALLI) Hi Y'all: I am in the process of purchasing an Imaging Technology series 150/40 image acquisition system. I will be installing this board on our VME system running VxWorks 5.1.1. The host processor is a Motorola MV167 68040. We will be running native VxWorks code for the imaging board. I am looking to the net for installation tips, shortcuts and caveats. If you are familiar with this configuration or have used this set-up, let us chat. I would love to hear from you. Many thanks in advance, - -harsh - -- Harsh Potlapalli, Research Associate, Dept. of Textile Engineering College of Textiles, North Carolina State University,Raleigh, NC Phone: 919-515-6565, Fax: 919-515-6532, e-mail: hpotlap@tx.ncsu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: 5.1.1 Memory leak Date: 18 Jul 1994 14:02:46 -0700 From: rls@ltis.loral.com (Randy Silagi) Organization: Loral Test And Information Systems Keywords: memory leak Message-ID: This is an update to a posting of a few of weeks back. The original had to do with a memory leak that I suspected was in TCL. I suspected TCL because that was what was running when I discovered the leak. Stan Schneider, of Real-Time Innovations, decided to investigated this and found the leak in "stderr", which is a macro that expands to __stderr(). This leak is only present on the first activation from a task. But, since TCL spawns a new task for each call to a VxWorks function, my system ran out of memory. The __stdout() has the same problem. This is a VxWorks call and therefore this memory leak should be in every version of 5.1.1. So, everybody needs to look-out for this leak. I have forward this problem to support@wrs.com. The following is the mail I got from Stan about how he found the leak. +------------------------------------------------------------------+ | Randy Silagi E-Mail: rls@ltis.loral.com | Loral Test & Information Systems | 15378 Avenue of Science Phone: 619-674-5100, X4798 | San Diego, CA 92128-3407 Fax: 619-674-5145 +-------------------------------------------------------------------+ Hi Randy, I've traced this down to the initialization of the standard IO for the "exec" task spawned by TCL's vxexec command. Unfortunately, this appears to be a leak in WRS code, so I don't see any easy fix. It also goes underneath the "malloc" layer (it's OS code), and so doesn't show up in HeapTrace easily; I found it with the execution tracing facility (also in RTILib) called "Trace". In particular, the line "fflush(stderr)" in executeAndClose() in vxUtil.c yields this trace: 0x289294 (): task dead245: ___stderr() 0x289294 (): task dead246: _stdioInitStd() 0x289294 (): task dead247: _stdioFpCreate() 0x289294 (): task dead248: _stdioInit() 0x289294 (): task dead248: _stdioInit returned 0x0 0x289294 (): task dead249: _objAllocExtra() 0x289294 (): task dead250: _memPartAlloc(75538, 72) <-- lost memory 0x289294 (): task dead250: _memPartAlloc returned 0x291124 0x289294 (): task dead249: _objAllocExtra returned 0x291124 0x289294 (): task dead247: _stdioFpCreate returned 0x291124 0x289294 (): task dead246: _stdioInitStd returned 0x0 0x289294 (): task dead245: ___stderr returned 0x289360 A similar thing happens with stdout. Each time, it costs 72 bytes, plus an 8 byte header, so 72+8 (stderr) + 72+8 (stdout) = 160, as you saw. ... [snip] ... =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: Re: AM Codes Date: 18 Jul 1994 14:14:38 -0700 From: rls@ltis.loral.com (Randy Silagi) Organization: Loral Test And Information Systems Message-ID: References: <9407181835.AA24401@mclean.sparta.com> tsb@mclean.sparta.com (Todd S. Brackett) writes: >Anthony Le writes ... >> >> Can anyone explain to me the AM code on VME bus? >> >> - Why AM code? >> - What it use for? >> - What do they mean for different values? >> - What different between dynamic and static AM code? >> - Does It effect other hardware when I set AM code equals 0x39 all time? >> - When can I use other codes and for what purpose? >> >> - Why is It complicate like this? >> >> It seems to me nobody care about AM code on VME bus when designing >> the hardware. >> >Wrongo!!!!!!! Address modifiers are extremely important. I agree with Todd B. Address modifiers are important. I spent 2 days tring to DMA data from my Force 040. I found that the '040 will not respond to 0x0E, which is Extended, Supervisory, Program, but it will respond to 0x0D, Extended, Supervisory, Data. Which makes sense from the System Controler's point of view. If I was the System Controller I would not want anybody coming in, out of no where, and messing with my program, but they could come and take any data that they wanted. +------------------------------------------------------------------+ | Randy Silagi E-Mail: rls@ltis.loral.com | Loral Test & Information Systems | 15378 Avenue of Science Phone: 619-674-5100, X4798 | San Diego, CA 92128-3407 Fax: 619-674-5145 +-------------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks,comp.sys.sun.admin,comp.arch.bus.vmebus Subject: How to display console output of a MVME167 to a window on a Sun SPARC10 w/s? Date: 18 Jul 94 20:40:13 GMT From: clh@mdavcr.mda.ca (Christian Lam) Organization: MacDonald Dettwiler, 13800 Commerce Parkway, Richmond, BC, Canada V6V 2J3 Keywords: serial devices, tty display, vxWorks, SunOS Message-ID: <5979@sparky.mdavcr.mda.ca> Followup-To: poster Hi there, Due to limited space, we cannot use a dumb terminal to display output coming from the serial console of a MVME167 board running vxWorks. So that, we'd like to use the develepment workstation, which is a Sun SPARC10 to display the said output in a window shell. Then, the question is how do we connect the serial port of the MVME167 to the serial port of the SPARC10 w/s (should we use a null-modem cable?) and how do we configure the w/s runnning SunOS to use the serial port as incoming and redirect data to the dumb terminal emulator in a window shell? +---------+ +------------------+ | MVME167 | | SS10/SunOS 4.1.3 | | | | | | port 0 |------>-------| ttya --> +-----+ | | console | serial cable | port A |-> i | | | | | | | | +---------+ | +-----+ | | window | | shell | | | +------------------+ Please email responses to "clh@mda.ca". Cheers, Chris. - -- | MacDonald Dettwiler & Associates Ltd. Christian Lam | | 13800 Commerce Parkway, Tel: (604)-278-3411 | | Richmond, BC, Fax: (604)-278-4716 | | Canada, V6V 2J3 email: clh@mda.ca OR ..!uunet!van-bc!mdavcr!clh | --------------------------- End of New-News digest ********************** From tweadon@sadira.gb.nrao.edu Tue Jul 19 05:27:14 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Tue Jul 19 05:27:23 PDT 1994 Subject: How to display console output of a MVME167 to a window on a SunSPARC10 w/s Add the following line to /etc/uucp/Devices Direct ttya - Any direct Then Change the file permission on /dev/ttya to 666 Now you are ready to "hook" ttya to a window. Type: cu -lttya -s9600 And the Sparc should say "Connected" Hardware wise: Your Sparc should have come with a cable which plugs into the A/B ports and convertss it to a DB-25 connector. Plug the DB-25 connector into the Transition Module "Console" port. Pins 2&3 need to either be swapped or you need to change the jumpers on the Transition module to be on the "To Terminal" jumpers instead of the "To Modem" jumper posts. Everything should work at this point. Tim Weadon National Radio Astronomy Observatory Green Bank, WV. 24944 P.S. If you get "cu" to hang then the procedure to fix it is: a: Become superuser b: Kill the two processes associated with this cu (input & output processes) c: delete the lock /var/spool/locks/LCK.ttya From csuka@heracc.desy.de Tue Jul 19 06:27:07 1994 From: "Gabor Csuka, DESY - Germany" Date: Tue Jul 19 06:27:15 PDT 1994 Subject: RE: MV162 IP Interrupts Hi, my experience with mv162 and IP. NOT use interrupt level 7. :-( With any other interrupt I have had no problem, but th 7 was sometime lost. (Maybe my setup was wrong. :-) ) I have found the same with the VME interrups too. The 'error rate' was around 1/0x20000 ~ 0.0000075 = 0.75 * 10^(-5). Gabor CSUKA DESY csuka@heracc.desy.de From hill@luke.atdiv.lanl.gov Tue Jul 19 08:00:10 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Tue Jul 19 08:00:18 PDT 1994 Subject: Re: How to display console output of a MVME167 to a window on a SunSPARC10 w/s > > P.S. If you get "cu" to hang then the procedure to fix it is: > a: Become superuser > b: Kill the two processes associated with this cu (input & output processes) > c: delete the lock /var/spool/locks/LCK.ttya > We have observed that problems with tip "hanging" occur only when using sun's cmdtool and do not occur when using xterms. Jeff ______________________________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos, NM USA 87545 FAX 505 665 5107 From guthrie@power.amasd.anatcp.rockwell.com Tue Jul 19 09:09:04 1994 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Tue Jul 19 09:09:14 PDT 1994 Subject: How to display console output of a MVME167 to a window on a Sun SPARC10 w/s? Christian Lam: > Hi there, > Due to limited space, we cannot use a dumb terminal to display > output coming from the serial console of a MVME167 board running > vxWorks. So that, we'd like to use the develepment workstation, > which is a Sun SPARC10 to display the said output in a window shell. > Then, the question is how do we connect the serial port of the MVME167 > to the serial port of the SPARC10 w/s (should we use a null-modem cable?) > and how do we configure the w/s runnning SunOS to use the serial port > as incoming and redirect data to the dumb terminal emulator in a window shell? I am pretty sure you will need a null modem. You can use a volt meter on pins 2 and 3 relative to pin 7 to tell for sure. One side needs to make 3 hot and the other needs to make 2 hot. To do the terminal emulation, you need to setup the SUN's serial port in the "/etc/remote" file and use the "tip" program. See the man pages for tip and remote for more info. Perhaps an easier way to do this is to "rlogin" to the vxWorks board over the ethernet. Robert Guthrie Rockwell International From pedersen@tigger.geg.mot.com Tue Jul 19 23:41:33 1994 From: pedersen@tigger.geg.mot.com (Ryan Pedersen x2895) Date: Tue Jul 19 23:41:41 PDT 1994 Subject: MV167 Serial Port DMA TRANSFER - BUS ERRORS Has anyone seen this problem before? I have a MV167 card that is receiveing data from three async ports at the same time. Usualy everything runs fine; but sometimes (1%) I get a BUS ERROR and when transfering the data to memory via the DMA transfer. Data that is received is sent out over the VME bus at the same time. Could this be a collision with the VME transfers. If any ideas, how do I debug this to get the BUS ERROR to occure more often. ------------------------- _____ _____/__/__\_____ Ryan Pedersen (oo_oo(_(@)___(@)_) MOTOROLA, GSTG ------------------------- From daemon@vxw.ee.lbl.gov Wed Jul 20 04:00:27 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jul 20 04:00:43 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jul 20 04:00:16 PDT 1994 Subject: SPARC CPU interrupts (converting from 68K) ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: SPARC CPU interrupts (converting from 68K) Date: Tue, 19 Jul 1994 21:35:41 GMT From: curry@tc.fluke.COM (John Curry) Organization: Fluke Corporation, Everett, WA Message-ID: We are in the process of attempting to port our MVME167 software to a FORCE SPARC CPU-3ce board. Converting our basic application software went fairly smoothly, but we are having problems converting our interrupt based IEEE I/O driver software. Bascially, we can't seem to get the intConnect() routine to work correctly. Does anyone have any examples or insights on converting from 68K interrupts to SPARC interrupts? I've read through appendix D of the VxWorks Programmers Guide, but it doesn't address the problem we are having. We are currently using VxWorks 5.1.1. Thanks for any information. John Curry - -- - ---------------------------------------------------------------------------- John Curry Fluke Corporation curry@tc.fluke.com 6920 Seaway Blvd m/s 178D 206-356-5708 Everett, Wa. 98206 - ---------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From hill@luke.atdiv.lanl.gov Wed Jul 20 08:17:32 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Wed Jul 20 08:17:41 PDT 1994 Subject: Re: 68k int => sparc int > Does anyone have any examples or insights on > converting from 68K interrupts to SPARC interrupts? I've read through > appendix D of the VxWorks Programmers Guide, but it doesn't address the > problem we are having. We are currently using VxWorks 5.1.1. > Perhaps you are not using "INUM_TO_IVEC()" as the first argument to intConnect(). See iv.h and its architecture dependent includes. Hope this helps. Jeff ______________________________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos, NM USA 87545 FAX 505 665 5107 From mike@imatron.com Wed Jul 20 09:36:53 1994 From: "Mike Morrison[Software Eng]" Date: Wed Jul 20 09:37:01 PDT 1994 Subject: Re: MV167 Serial Port DMA TRANSFER - BUS ERRORS >>Has anyone seen this problem before? >> >>I have a MV167 card that is receiveing data from three async ports >>at the same time. Usualy everything runs fine; but sometimes (1%) >>I get a BUS ERROR and when transfering the data to memory via >>the DMA transfer. >> >>Data that is received is sent out over the VME bus at the same time. >>Could this be a collision with the VME transfers. >> >>If any ideas, how do I debug this to get the BUS ERROR to occure more >>often. You could play with the VME Access and Local Bus timeouts These are found at 0xfff4004c. Try decreasing/increasing the local bus timeout it goes from 8us up to 256us. You may be able to increase the occurence of the problem by setting the timeout to 8us. If you have another bus master that may be hogging the VME bus, try increasing the VMEbus access timeout. The timeout register is described on page 2-62 of the mvme167 Programmer's Reference Guide. If you don't have the guide, e-mail me and I'll send a description of the register. From sbads@amd-1s.hac.com Wed Jul 20 11:59:06 1994 From: sbads@amd-1s.hac.com (Stefan Badstuebner) Date: Wed Jul 20 11:59:15 PDT 1994 Subject: Re: qsort bug Here is a fix for VxWorks 5.1 that I used (5.1.1 should bo OK) /* ----------------------------------------------------------------- ** qsortErsatz ** ** ``Portions of this work are derived from The Standard C Library, ** copyright (c) 1991 by P.J. Plauger, published by Prentice-Hall, ** and are used with permission.'' ** ** sort (char base[size])[nelem] using quicksort ** ** 14Sep93 Sb, function declaration updated. ** ** make private, WRS's version does not work */ /* macros */ #define MAX_BUF 256 /* chunk to copy on swap */ static void qsortErsatz (void *base, size_t n, size_t size, int(*cmp)(const void *a, const void *b)) { while (1 < n) { /* worth sorting */ size_t i = 0; size_t j = n - 1; char *qi = base; char *qj = qi + size * j; char *qp = qj; while (i < j) {/* partition about pivot */ while (i < j && (*cmp)(qi, qp) <= 0) ++i, qi += size; while (i < j && (*cmp)(qp, qj) <= 0) --j, qj -= size; if (i < j) {/* swap elements i and j */ char buf[MAX_BUF]; char *q1 = qi; char *q2 = qj; size_t m, ms; for (ms = size; 0 < ms; ms -= m, q1 += m, q2 -= m) {/* swap as many as possible */ m = ms < sizeof (buf) ? ms : sizeof (buf); memcpy(buf, q1, m); memcpy(q1, q2, m); memcpy(q2, buf, m); } ++i, qi += size; --j, qj -= size; } } if (qi != qp) {/* swap elements i and pivot */ char buf[MAX_BUF]; char *q1 = qi; char *q2 = qp; size_t m, ms; for (ms = size; 0 < ms; ms -= m, q1 += m, q2 -= m) {/* swap as many as possible */ m = ms < sizeof (buf) ? ms : sizeof (buf); memcpy(buf, q1, m); memcpy(q1, q2, m); memcpy(q2, buf, m); } } j = n - i; if (j < i) {/* recurse on smaller partition */ if (1 < j) qsortErsatz(qi, j, size, cmp); n = i; } else {/* lower partition is smaller */ if (1 < i) qsortErsatz(base, i, size, cmp); base = qi; n = j; } } } Sorry for the sloppy cut&paste ------------------ Stefan Badstuebner [sbads@amd-1s.hac.com] Hughes Aircraft Co Fullerton, CA From shian@dcsd.sj.nec.com Wed Jul 20 14:33:10 1994 From: shian@dcsd.sj.nec.com Date: Wed Jul 20 14:40:44 PDT 1994 Subject: Telnet Client Source for VxWorks I'm looking for "Telnet Client Source code for VxWorks". It can be from freeware, shareware, or a commercial package. Please let me know if you know there is one. Thanks in advance, Shian-Tung Wong _____________________________ NEC America, Inc. Phone:(408)433-2943 Fax: (408)433-2950 E-mail: shian@dcsd.sj.nec.com From stan@lassen.rti.com Wed Jul 20 16:21:09 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Wed Jul 20 16:21:17 PDT 1994 Subject: Re: comp.os.vxworks newsdigest >> Date: Tue, 19 Jul 1994 21:35:41 GMT >> From: curry@tc.fluke.COM (John Curry) >> >> We are in the process of attempting to port our MVME167 software to >> a FORCE SPARC CPU-3ce board. Converting our basic application software went >> fairly smoothly, but we are having problems converting our interrupt based >> IEEE I/O driver software. Bascially, we can't seem to get the intConnect() >> routine to work correctly. Does anyone have any examples or insights on >> converting from 68K interrupts to SPARC interrupts? I've read through >> appendix D of the VxWorks Programmers Guide, but it doesn't address the >> problem we are having. We are currently using VxWorks 5.1.1. >> Without any indication of the nature of the problem... If you're using VxVM and getting bus errors, then check out SPR 2653 at Wind River, or drop me a line. There are some cases where intConnect() can fail on a SPARC, but there's an easy workaround. -- 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 greg@eng.nmr.varian.com Wed Jul 20 17:38:38 1994 From: greg@eng.nmr.varian.com (Greg Brissey x6951) Date: Wed Jul 20 17:38:48 PDT 1994 Subject: 68332 support Greetings: I am presently using VxWorks 5.1.1 on our main CPU card. We also using a 68332 on another board. I am contemplating whether I should go ahead and use VxWorks on this processor or roll our own. The BSP for this processor doesn't include very much considering the tremendous amounts of controllable features of this processor and the asking $$. I am looking for comments and/or suggestions from anyone with previous experience with this processor. Are there any VxWorks supported freeware, shareware, or commercial drivers for any of the many aspects of 68332 features? You can mail to me directly at greg.brissey@nmr.varian.com Thanks in Advance Greg Brissey +-------------------------------------------------------------+ | Greg Brissey email: greg.brissey@nmr.varian.com | | Varian voice: (415) 424-6951 | | MS D-316 | | 3120 Hansen Way | | Palo Alto CA. 94587 | +-------------------------------------------------------------+ From leonid@rst.co.il Thu Jul 21 02:08:02 1994 From: leonid@rst.co.il (Leonid Rosenboim) Date: Thu Jul 21 02:08:31 PDT 1994 Subject: Re: SPARC CPU interrupts (converting from 68K) > From: curry@tc.fluke.COM (John Curry) > ... > but we are having problems converting our interrupt based > IEEE I/O driver software. Bascially, we can't seem to get the intConnect() > routine to work correctly. > ... Maybe you should add a call to sysBusIntAck() function to your ISR. Thos BSP function has no effect on 68k boards cause they all do it in hardware, but on SPARC the CPU does not acknowledge interrupts, and it must be done either by external hardware, or by software, and that is why this function is there in the first place. Maybe this is the cause of your trouble, try 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.co.il [ Wind River Systems Distributor and Systems Integrator ] From daemon@vxw.ee.lbl.gov Thu Jul 21 04:00:28 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jul 21 04:00:46 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jul 21 04:00:18 PDT 1994 Subject: Re: How to display console output of a MVME167 to a window on a Sun SPARC10 w/s? ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus,comp.sys.sun.admin Subject: Re: How to display console output of a MVME167 to a window on a Sun SPARC10 w/s? Date: 20 Jul 94 16:32:59 GMT From: clh@mdavcr.mda.ca (Christian Lam) Organization: MacDonald Dettwiler, 13800 Commerce Parkway, Richmond, BC, Canada V6V 2J3 Keywords: serial devices, tty display, vxWorks, SunOS Message-ID: <6003@sparky.mdavcr.mda.ca> Followup-To: comp.os.vxworks Hi there, We would like to thank to all those of you out there who responded to our question, which was indeed a simple one as some of you pointed out, (you just had to know where to search ...). For those of you who might be interested: From what I've glanced thru the responses, the majority of you suggested using "tip" as the simplest solution. For those of you who were planning to respond, please don't bother since we've already got enough to get going. Again thank you all, and please stop sending the responses. Cheers, Chris. - -- | MacDonald Dettwiler & Associates Ltd. Christian Lam | | 13800 Commerce Parkway, Tel: (604)-278-3411 | | Richmond, BC, Fax: (604)-278-4716 | | Canada, V6V 2J3 email: clh@mda.ca OR ..!uunet!van-bc!mdavcr!clh | --------------------------- End of New-News digest ********************** From lerible@raptor.sandia.gov Thu Jul 21 06:30:38 1994 From: lerible@raptor.sandia.gov (Loren E. Riblett) Date: Thu Jul 21 06:30:46 PDT 1994 Subject: wildcard copy Does anyone know of a vxWorks 'copy' implementation that allows for wildcarding for the file names, i.e. 'copy "*.*", "/pcfsA"' ? Thanks in advance. _/_/_/_/ _/ _/ _/ Loren E. Riblett _/ _/_/ _/ _/ Email: lerible@sandia.gov _/_/_/_/ _/ _/ _/ _/ (505) 845-8841 FAX 844-4157 _/ _/ _/_/ _/ Senior Member of the Technical Staff _/_/_/_/ _/ _/ _/_/_/_/ Image & Signal Processing Department 9137 Sandia National Laboratories Albuquerque, NM 87185 From guthrie@power.amasd.anatcp.rockwell.com Thu Jul 21 12:11:25 1994 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Thu Jul 21 12:11:34 PDT 1994 Subject: CACHE_SNOOP_ENABLE Can anybody tell me what the CACHE_SNOOP_ENABLE bit does when it is OR'ed into the USER_D_CACHE_MODE constant as follows: #define USER_D_CACHE_MODE (CACHE_COPYBACK|CACHE_SNOOP_ENABLE) I don't see my BSP doing anything with it other than passing USER_D_CACHE_MODE to the cacheLibInit() function. My board has a register to control snooping, and my BSP enables this register. I don't see any thing in the 68040 that allows the software to control snooping. I am using vxWorks 5.1.1, have a 68040, and set the CPU environment variable to 68040. The only thing I can guess is that this effects the determination of cache safe routines like invalidate. Robert Guthrie Rockwell International From daemon@vxw.ee.lbl.gov Fri Jul 22 04:00:32 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jul 22 04:00:42 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jul 22 04:00:22 PDT 1994 Subject: CPU boot from vembus ?? Subject: X-window Server under VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: CPU boot from vembus ?? Date: 21 Jul 94 21:23:46 +0100 From: junkes@FHI-Berlin.MPG.DE Organization: Fritz-Haber-Institut der MPG,Berlin Message-ID: <1994Jul21.212346.8191@rz-berlin.mpg.de> I am using a Force 2ce running Solaris 2.3 a FORCE CPU 39 and a FORCE CPU32 in a VMEbus. A backplane-driver for Solaris 2.3 is still not available from wind river system. I want to boot the CPU39 over the Vme-bus. My idea is to copy vxworks into the dual portet memory of the CPU39 (over vmebus from 2ce) and then assert a FGA reset to reset the CPU39. Who can i copy the vxworks into the memory of the cpu 39 ??? Or can i boot from a memory ? (i have an other memory in the vmebus) Any help would be nice !!! --------------------------- Newsgroups: comp.os.vxworks Subject: X-window Server under VxWorks Date: 21 Jul 1994 20:27:36 GMT From: synergy@nic.cerf.net (John E. Clark) Organization: CERFnet Dial n' CERF Customer Message-ID: <30mlno$sk4@news.cerf.net> We are in need of a port of an X-window server to our graphics hardware, which runs under VxWorks. The graphics hardware is a 'dumb' fram buffer and the VxWorks runs on our 68040 based VME CPU cards. I would like responses from firms or individuals who could possibly perform the port in the next two weeks (plenty of time, right..). Also, I would like some general reponses from someone who has done such a port. Contact: John Clark Synergy Microsystems, Inc (619) 452-0020 Thank You. --------------------------- End of New-News digest ********************** From visicom!VisiCom.COM!trest@lbl.gov Fri Jul 22 09:11:58 1994 From: Mike Trest Date: Fri Jul 22 09:12:07 PDT 1994 Subject: Re: CACHE_SNOOP_ENABLE > Can anybody tell me what the CACHE_SNOOP_ENABLE bit does when it is > The only thing I can guess is that this effects the determination of > cache safe routines like invalidate. Bob, It does nothing inside VxWorks kernel or libraries (to my knowledge). Since it is a hardware feature, look in you BSP sources for any specific references. Snooping is supposed to cause logic on the CPU board to interact more closely with the MMU. For example, suppose your MMU reads a cache line because of a local DRAM reference, and that DRAM is also visible on the VME bus. Then, while that line is still in cache, a outside master updates the DRAM location. If SNOOP_ENABLE is working, the cache will be told to invalidate that line so that the next read by the CPU of that DRAM reference will refill the cache line with the correct value. If SNOOP_ENABLE is not working, and the CPU modifies the value, a subsequent flush of the cache will overwrite the value in the DRAM, thus destroying the value written by the outside master. Bus snooping is generally done best in MBUS, RISC, or boards with multiple processor environments. VME boards which properly snoop external VMEbus references to onboard DRAM are a rare item. I am working on an SMP implementation with clusters of processors. I am very interested in hearing from users and vendors who have actually used or can recommend boards with good DRAM-VME-CACHE snooping. ..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 mjeronis@astro.ge.com Fri Jul 22 10:04:38 1994 From: Mike Jeronis Date: Fri Jul 22 10:04:48 PDT 1994 Subject: Force CPU-3CE Users Hello, Here is a heads up to anybody using the CPU-3CE. Currently we're developing product using the 3CE running vxWorks. We have 8 3CEs in house. We noticed that several of the cards were not responding the VMEbus interrupts. It turns out we have three rev. 0.3 cards and 5 rev. 0.4 cards. The rev. 0.3 respond to VMEbus interrupts, while the rev. 0.4 cards don't. The problem turns out to be due to a VME IRQ buffer added to the rev. 0.4 card. Wind Rivers acknowledges the problem and plans to do something about in the future. Our Force rep. provided us with the information to enable the buffer. From Force: The following is text from our Tech Support department. The VME IRQ buffer on Rev 0.4 PCBs is enabled by setting Bit 4 of the gen_purpose2 register and disabled by clearing Bit 4 to "0". The function is Write-Only. Bit 4 of the gen_purpose2 register reads back the status of the AS Fail NMI, per the Tech Ref Manual, pages 119 & 120. The physical address of the gen_purpose2 register is 71380007. It turns out that in the function sysHwInitOem in sysLib.c, Wind Rivers does attempt to enable this buffer, but they must clobber it somewhere else. All we did was copy the lines of code in sysHwInitOem that pertain to setting bit 4 in the general_purpose2 register into a function we call at the end of the usrRoot task. We put the function in sysLib.c. /******************************************************************* 7/21/94 - MEJ. Needed to correct interrupt enable problem with rev. 0.4 cards. This function is called from usrRoot in file usrConfig.c. Temporary patch. **********************************************************************/ void ourSysHwInit(void) { UINT8 dummy; /* dummy parameter */ dummy = *FRC3CE_GEN_PURPOSE2_REG; *FRC3CE_GEN_PURPOSE2_REG = (dummy & ~(FRC3CE_RESET_WATCHDOG_NMI | FRC3CE_RESET_ACFAIL)) | FRC3CE_IT_ENABLE; } We have not seen any ill effects with either the 0.3 or 0.4 cards as of yet due to this patch. Hope this is helpful to somebody ________________________________________________________________________ Mike Jeronis (mjeronis@astro.ge.com) Martin Marietta Asto (609) 490-7120 From mea@mclean.sparta.com Fri Jul 22 11:57:07 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Jul 22 11:57:15 PDT 1994 Subject: IP Serial Drivers Greetings! Does anyone have device drivers for either the IP-Serial or the IP Dual-PI/T IP modules that they're willing to share? I'm using the GreenSprings 610 IP carrier board, but even a version running on the MVME-162 would be greatly appreciated. BTW, I'm currently working the issues to get an anonymous FTP site set up here at SPARTA to make available the FAQ and it's associated appendixes (which I'll be sending out an update for shortly) as well as be a potential mirror site for the VxWorks User's Group archives. Please bear with me as I'm having a difficult time convincing my security folks that anonymous FTP isn't evil incarnate ;-). Regards and 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 ddavies@sim.es.com Fri Jul 22 14:15:30 1994 From: ddavies@sim.es.com (Doug Davies) Date: Fri Jul 22 14:15:41 PDT 1994 Subject: Email address change Folks, I debated on whether I should bother everybody with this, but I have corresponded with SO many people on the exploder for many years, and thought an alert was in order. I am moving to another company and will no longer be with Evans & Sutherland. My new email address will be: ddavies@xmission.com See you there. -Douglas Davies From ddavies@sim.es.com Fri Jul 22 14:15:28 1994 From: ddavies@sim.es.com (Doug Davies) Date: Fri Jul 22 14:15:50 PDT 1994 Subject: Re: CACHE_SNOOP_ENABLE > Can anybody tell me what the CACHE_SNOOP_ENABLE bit does when it is > OR'ed into the USER_D_CACHE_MODE constant as follows: > #define USER_D_CACHE_MODE (CACHE_COPYBACK|CACHE_SNOOP_ENABLE) > I don't see my BSP doing anything with it other than passing > USER_D_CACHE_MODE to the cacheLibInit() function. There are several sections in the Motorola 68040 manual that talk about bus snooping. It is used in conjunction with caching to insure that caching is kept coherent. It is valuable when another device, such as a I/O device with DMA - or a bus controller to another bus such as the VMEbus, accesses the local bus to read/write RAM. The problem arises when the 68040 CPU has a line cached and someone steals the bus and reads or writes that location in RAM. You can see how the cached line is not in agreement (coherent) with RAM. From page 5-10: If the MC68040 is allowed to snoop an alternate master read transfer, it can intervene in the access to supply data from its data cache when the memory copy is stale, ensuring the alternate master receives valid data. Writes by an alternate master can also be snooped to either update the MC68040's internal data cache with the new data or invalidate the matching cache lines, ensuring subsequent reads by the MC68040 access valid data. Now this is a pretty simplistic explaination, because what actually happens depends on a lot of things such as whether caching (data) is enabled, and what the mode of caching is (ie. write through or copy back). It also depends on the type of device that is doing the access and whether it is able to access RAM without involving the CPU (DMA, etc). > My board has a register to control snooping, and my BSP enables this register. > I don't see any thing in the 68040 that allows the software to control > snooping. It is a hardware pin on the 68040 (SC0/SC1). Most CPU boards have a control register that is latched to those pins. You write the register and it asserts the correct bus snooping mode. Beware of a nasty little condition that is not guarded... that is the test and set operation. The bus snoop on the 68040 will not guard a test and set operation. If you look in the BSP code you will notice that if you enable the BP (back panel) network that the BSP undef's bus snooping. This is due to the fact that the BP network uses test and set operations. There is a patch that you can get from Wind River that modifies the usrNetwork.c file such that the BP anchor area is allocated and then marked uncachable. This gets around this problem, but has a nasty side effect in that it puts the BP anchor address at some wild/unintuative address. You will also need to play around with the BSP to keep it from messing with the BUS_SNOOP definition (if using the BP). -Doug -------------------------------------------------------------------------------- Douglas Davies (software engineer) |"Never underpay your software engineers" INTERNET: ddavies@xmission.es.com | -Jurassic Park Moral From visicom!VisiCom.COM!trest@lbl.gov Fri Jul 22 14:58:24 1994 From: Mike Trest Date: Fri Jul 22 14:58:33 PDT 1994 Subject: Re: CPU boot from vembus >>A backplane-driver for Solaris 2.3 is still not available from >>wind river system. >>I want to boot the CPU39 over the Vme-bus. >>My idea is to copy vxworks into the dual portet memory of the CPU39 >>(over vmebus from 2ce) and then assert a FGA reset to reset the CPU39. I regurarly use this method to bring up new boards which do not yet have a VxWorks BSP. You just have to be careful about what is in your bootrom. You will have to do something to put a structure in a known location in the DRAM with address,size,and checksum of the VxWorks image. Your boot rom would then look for this structure and confirm the checksum. If valid, then set SP and branch to the initial entry point of your downloaded VxWorks image. >>Who can i copy the vxworks into the memory of the cpu 39 ??? >>Or can i boot from a memory ? (i have an other memory in the vmebus) >>Any help would be nice !!! I did the above as well. I had a Force IBC20 with no BSP. I built the VxWorks image and positioned it on a 2MB VME DRAM board. I put a very small rom program on the IBC20 which responded to RESET. The rom program enabeled VME master capabilities and executed the VxWorks out of the VME DRAM board as if it were a VxWorks boot rom. It "expanded" the bootrom image into the local IBC20 DRAM and were up! Hope some of this helps. ..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 ==================================================== ===Warning: Following may be a crass commercial! === === Read it at your own risk!! === I will write and test a Solaris backplane driver for Force 2ce if there is adequate customer interest. If the number of requests is large enough we would probably do it sooner rather than later. We have Force 2ce + Solaris and Force CPU30/40/42/etc available for testing. VisiCom Laboratories is a WRS Value Added Reseller. From daemon@vxw.ee.lbl.gov Sat Jul 23 04:00:29 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jul 23 04:00:37 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jul 23 04:00:19 PDT 1994 Subject: OSI on vxworks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: OSI on vxworks Date: Fri, 22 Jul 1994 16:08:58 GMT From: akr@acsu.buffalo.edu (Ajit K Ranganathan) Organization: UB Message-ID: Sender: nntp@acsu.buffalo.edu --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Jul 24 04:00:26 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Jul 24 04:00:36 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jul 24 04:00:14 PDT 1994 Subject: Ethernet Hooks Subject: Mobile94 Workshop --- deadline 8/20 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Ethernet Hooks Date: 22 Jul 1994 06:17:53 GMT From: bindi@mrad.com.au (Bindi Hawkey) Organization: MRad Pty Ltd, Australia Message-ID: <30noah$rt2@zeppo.mrad.com.au> Reply-To: bindi@mrad.com.au Hi, I'm looking at using ethernet input and output hook routines to handle each incoming and outgoing packet to and from my application. On first reading of the man pages, I got the impression that the input hook routine was called _automatically_ each time a packet arrives. But, having checked up on it 5 minutes ago, it seems that I need to actually make a call to the input hook routine manually. How would I know if a packet had actually arrived to be handled? I'd appreciate people's comments on this - and in particular any example code which demonstrates typical use of the etherLib routines. Perhaps somebody might know where I might find more doco on this besides the man pages and the manual? It's driving me crazy! Thanks 8-) Bindi - --- Bindi Hawkey Email : bindi@mrad.com.au Systems Engineer Phone : (08) 260 8965 (work) MRad Pty Ltd Adelaide, AUSTRALIA --------------------------- Newsgroups: comp.os.vxworks Subject: Mobile94 Workshop --- deadline 8/20 Date: 23 Jul 1994 20:39:11 GMT From: darrell@cse.ucsc.edu (Darrell Long) Organization: University of California, Santa Cruz Message-ID: <30rv5f$85@darkstar.UCSC.EDU> CALL FOR PARTICIPATION WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS DECEMBER 8-9 1994 DREAM INN, SANTA CRUZ, CA Sponsored by the IEEE Computer Society TCOS (in cooperation with ACM SIGOPS and USENIX Association) General Chair Darrell Long, University of California, Santa Cruz Program Chair M. Satyanarayanan, Carnegie Mellon University Exhibits Peter Honeyman, University of Michigan Finance & Registration Richard Golding, Hewlett-Packard Publication Luis-Felipe Cabrera, IBM Almaden Program Committee Dan Duchamp, Columbia University Peter Honeyman, University of Michigan Randy Katz, UC Berkeley & ARPA Jay Kistler, DEC SRC Krishan Sabnani, AT&T Holmdel M. Satyanarayanan, Carnegie Mellon University Amal Shaheen, IBM Austin Marvin Theimer, Xerox PARC Rich Wolff, Bellcore A major challenge of this decade is the effective exploitation of two symbiotic technologies: portable computers and wireless networks. Harnessing these technologies will dramatically change the computing landscape. But realizing the full potential of the resulting mobile computing systems will require advances in many areas such as: hardware communications scalability power management security data access user interfaces location sensitivity The goal of this workshop is to foster exchange of ideas in mobile computing among workers in the field. Attendance will be limited to about 60 participants, based on the position papers submitted. Submissions should be fewer than 5 pages in length and may expose a new problem, advocate a specific solution, or report on actual experience. In addition, we will be hosting a small number of novel hardware and software exhibits relevant to mobile computing. The exhibits may be research prototypes or commercial products. Interested parties should submit technical descriptions of their exhibits. Online copies of the position papers will be made available via anonymous FTP prior to the workshop. A printed proceedings will be published after the workshop, and mailed to participants. A small number of graduate students will be granted a waiver of the registration fee. In return, these students will be required to take notes at the workshop and help put together the proceedings. Students who wish to be considered for the waiver must send in a brief description of their current research, and an explanation of how participation in the workshop is likely to help them. Send 10 copies of position papers to: M. Satyanarayanan Email: satya@cs.cmu.edu School of Computer Science Phone: (412)-268-3743 Carnegie Mellon University Fax: (412)-681-5739 Pittsburgh, PA 15213 Send exhibit descriptions to: Peter Honeyman Email: honey@citi.umich.edu CITI Phone: (313)-763-4413 University of Michigan Fax: (313)-763-4434 Ann Arbor, MI 48103-4943 IMPORTANT DATES Submissions due August 20 1994 Acceptance Notification October 1 1994 Camera-ready copy due November 15 1994 --------------------------- End of New-News digest ********************** From leonid@rst.co.il Sun Jul 24 08:13:35 1994 From: leonid@rst.co.il (Leonid Rosenboim) Date: Sun Jul 24 08:13:42 PDT 1994 Subject: i960CF I ma looking for people who have experience operating the Dta Cache on the I960CF processor. Apparently, VxWorks 5.1.1, support up to the CA version which has only instruction cache. Any information will be gratly welcome. I will post a summary, possible with a patch, for people to use. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel E-Mail: leonid@rst.co.il [ Wind River Systems Distributor and Systems Integrator ] From ddowning@well.sf.ca.us Mon Jul 25 07:56:32 1994 From: "Daniel D. Downing" Date: Mon Jul 25 07:56:40 PDT 1994 Subject: Job-Wanted Is anyone aware of any job openings for an engineer with both hw & sw experience. About 4 years ago I designed a 68020 based VME board and also did the vxworks port to it. I live 20 miles south of San Francisco in Montara and am interested in a job location with a reasonable commute. Dan Downing 415-728-2532 From guthrie@power.amasd.anatcp.rockwell.com Mon Jul 25 09:05:37 1994 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Mon Jul 25 09:05:46 PDT 1994 Subject: Re: CACHE_SNOOP_ENABLE Douglas Davies: Thanks for the reply. What I was really after was what the vxWorks "core" not "BSP" does when the SNOOP bit is set in the USER_D_CACHE_MODE #define. I got one reply back that stated this bit would effect the CACHE_DMA_FLUSH macro associated with the cacheDmaMalloc function. Basically, the reply suggested that the cache library would not worry about coherency if the SNOOP bit is set, just like it would not worry about it if the memory was uncached. Looking at the source code I have for my BSP, I don't see them doing anything with this bit, but I do see different behavior depending on whether the bit is set or not. There is code somewhere that looks at this bit. Robert Guthrie Rockwell International From enorgren@ehsl.mitre.org Mon Jul 25 12:13:21 1994 From: enorgren@ehsl.mitre.org (Eric J Norgren) Date: Mon Jul 25 12:13:30 PDT 1994 Subject: 68302 IP module serial driver code Hello, Does anyone have any C +/or Assembly driver code for operating a 68302 IP module in any of the SCC channel modes ( preferably promiscuos transparent +/or asynchronous UART ) that they would be interested in sharing? Thank you in advance for any assistance. Eric Norgren MITRE Corporation Embedded Hardware Standards Specialty Group email: enorgren@ehsl.mitre.org voice: 703-883-5632 fax: 703-883-3337 From mea@mclean.sparta.com Mon Jul 25 13:56:06 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Mon Jul 25 13:56:16 PDT 1994 Subject: Re: Ethernet Hooks Greetings! > From: bindi@mrad.com.au (Bindi Hawkey) > > Hi, > > I'm looking at using ethernet input and output hook routines to handle each > incoming and outgoing packet to and from my application. > > On first reading of the man pages, I got the impression that the input hook > routine was called _automatically_ each time a packet arrives. But, having > checked up on it 5 minutes ago, it seems that I need to actually make a call > to the input hook routine manually. How would I know if a packet had actually > arrived to be handled? > > I'd appreciate people's comments on this - and in particular any example code > which demonstrates typical use of the etherLib routines. > > Perhaps somebody might know where I might find more doco on this besides the > man pages and the manual? It's driving me crazy! > > Thanks 8-) > > Bindi > The routine that is "hooked" using etherInputHookAdd *is* called automatically by the processing stack provided the interface you are using plays by the rules. Ones like Ethernet and FDDI do work, but ones like SLIP do not. If you've hooked the input routine, for example, you will get passed a pointer to the interface structure, a pointer to an input buffer, and the length of the buffer. This buffer will contain the entire packet *including* the Ethernet wrapper. So, you end up with all of the layers of the protcol stack from the Ethernet link layer up. What you then do is perform what ever it was that you wanted to do, and then return a TRUE if there is no more processing required (i.e., you handled the packet yourself) or a FALSE if you want the protocol stack to handle it normally. The output hook routine will then be called each time the packet gets ready to go out the interface. I haven't done much with outbound packets myself, but I'm told that they work the same way. My students work with these in my Advanced Real-time courses to build a simple protocol analyzer. I've attached a piece of code for your review and enlightenment that was developed in a recent class by one of my students. I'm pretty sure that it works ;-). 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." =============================================================================== #include "vxWorks.h" #include "net/if.h" #include "net/if_ether.h" #include "net/in_systm.h" #include "in.h" #include "net/ip.h" #include "net/tcp.h" #include "net/udp.h" #include "net/ip_icmp.h" /* initialize boolean sw var */ int etherdump = 0; /* function to capture packets */ int etherLook(pIf, buffer, length) struct ifnet *pIf; /* defined in if.h */ char *buffer; /* buffer to catch packets */ int length; /* these variables are declared on page 1 - * 73 of vxWorks manual */ { char *bufPtr; /* pointer to buffer location */ struct ether_header *eth; /* declared in if_ether.h */ struct ether_arp *arpH; /* declared in if_ether.h */ struct ip *iph; /* declared in ip.h */ struct tcphdr *tcph; /* declared in tcp.h */ struct udphdr *udph; /* declared in udp.h */ eth = (struct ether_header *) buffer; bufPtr = buffer; if (etherdump) { /* * split out source & destination ethernet addr */ printf("source:%s\n", ether_sprintf(eth->ether_shost)); printf("destin: %s\n", ether_sprintf(eth->ether_dhost)); /* print out type field */ printf("type : % 2x\n ",eth->ether_type); } else { } /* skip ethernet header */ bufPtr += sizeof(struct ether_header); switch (eth->ether_type) { case ETHERTYPE_ARP: printf("arp protocol\n"); arpH = (struct ether_arp *)bufPtr; printf("sender HWA = %s\n ", ether_sprintf(arpH->arp_sha)); printf("sender PA = %s \n", inet_ntoa(*((unsigned long *)arpH->arp_spa))); printf("target HWA = %s \n", ether_sprintf(arpH->arp_tha)); printf("target PA = %s \n", inet_ntoa(*((unsigned long *) arpH->arp_tpa))); break; case ETHERTYPE_IP:{ printf("ip protocol\n"); iph = (struct ip *) bufPtr; printf("version = %d headerlen = %d total len = %d tim to live = %d\n ", iph->ip_v, iph->ip_hl,iph->ip_len, iph->ip_ttl); printf("src addr = %s, dst addr = %s\n ", inet_ntoa(iph->ip_src.s_addr), inet_ntoa(iph->ip_dst.s_addr)); bufPtr += iph->ip_hl << 2; switch (iph->ip_p) { case IPPROTO_TCP: tcph = (struct tcphdr *) bufPtr; /* print src & des port # */ printf("tcp in src = %d des = %d \n", tcph->th_sport, tcph->th_dport); bufPtr += tcph->th_off << 2; break; case IPPROTO_UDP: udph = (struct udphdr *) bufPtr; /* print src & des port # */ printf("ucp in src = %d des %d \n", udph->uh_sport, udph->uh_dport); bufPtr += sizeof(struct udphdr); break; case IPPROTO_ICMP: printf("icmp in\n"); bufPtr += sizeof(struct icmp); break; default: printf("protcol not found =%d \n", iph->ip_p); } break; default: printf("packet not defined %2x\n", eth->ether_type); break; } } /* printout rest of packet */ d(bufPtr, ((length - (bufPtr - buffer)) / 2) + 1); return (FALSE); } From interactive.com!hali@indev.portal.com Mon Jul 25 18:05:50 1994 From: hali@interactive.com (Hali Lindbloom) Date: Mon Jul 25 18:05:58 PDT 1994 Subject: Number of open file descriptors We are having a problem with the number of open file descriptors (i.e. sockets) allowed in VxWorks. Has anyone else experienced this problem or have a work-around for it? The user-configurable NUM_FILES in $VW/config/all/configAll.h defaults to 50 and can be increased up to 256. However, it is not possible to increase it beyond 256 and still use select(). This is because of the non-user-configurable value of FD_SETSIZE in $VW/h/types/vxTypesOld.h Attempting to increase FD_SETSIZE beyond 256 results in INVALID_FILE_DESCRIPTOR errors from any select() call. I believe this restriction is inherited from UNIX, where a limit of 256 file descriptors PER PROCESS seems somewhat reasonable. However, in VxWorks this is a global limit, and it is too small for our application. Thanks for any help, advice, or comments. -Hali Lindbloom hali@interactive.com Interactive Network (415) 903-4052 From daemon@vxw.ee.lbl.gov Tue Jul 26 04:00:29 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Jul 26 04:00:37 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jul 26 04:00:15 PDT 1994 Subject: 68060, MVME177 plans Subject: Terminal I/O ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: 68060, MVME177 plans Date: Mon, 25 Jul 1994 12:27:11 GMT From: clare@bisco.kodak.com (clare) Organization: Eastman Kodak Message-ID: Sender: usenet@bisco.kodak.com Does anyone have any information regarding VxWorks development packages targetted towards the 68060/MVME177 platforms? Are there any immediate plans to support this new platform? Thanks in advance billc - -- Bill Clare, Eastman Kodak Company Internet: clare@pixel.kodak.com m/c 35424 -- 901 Elmgrove Road Phone: (716) 726-9419 Rochester, New York 14653-5424 Section 34, row G, seats 3 and 4. Any opinions expressed herein belong to me and not to my employer. --------------------------- Newsgroups: comp.os.vxworks Subject: Terminal I/O Date: Mon, 25 Jul 1994 21:56:16 GMT From: brent2@metronet.com (Brent Bailey) Organization: Texas Metronet, Internet for the Individual 214-705-2901 (info) Message-ID: Does anybody have a UNIX-like terminal I/O library for VxWorks on an MC68360 or MC68302? I'm trying to port some software that expects the termios and supporting structures. Thanks. --------------------------- End of New-News digest ********************** From pdw@sunbar.mc.duke.edu Tue Jul 26 05:46:14 1994 From: "Patrick D. Wolf" Date: Tue Jul 26 05:46:22 PDT 1994 Subject: booting from PEP VLAN board Is anybody booting VxWorks using a PEP VLAN board (3U) and a third party CPU board? Is this trivial? Is the source code for the bootrom necessary to do this? Thanks for any info, Patrick Wolf Department of Biomedical Engineering Duke University 919-660-5114 pdw@sunbar.mc.duke.edu From mickey!@denali.uucp.cleaves Tue Jul 26 06:07:45 1994 From: Date: Tue Jul 26 06:08:31 PDT 1994 Subject: Re: Job-Wanted >Is anyone aware of any job openings for an engineer with both hw & sw >experience. About 4 years ago I designed a 68020 based VME board and >also did the vxworks port to it. I live 20 miles south of San Francisco >in Montara and am interested in a job location with a reasonable commute. Hope this is close: I am looking for a contract/permanent software engineer (see below) who is strong with vxWorks, have been and is now capable of writing drivers with minimal supervision and training. The work must be done at our site. Initial contract for 3 months. Possible conversion to full time, permanent position after that (based mostly on performance). Rate: DOE ($40 - $60++ per hour) Length: 3 months (contract) When: ASAP Location: Sunnyvale, CA Qualifications: vxWorks, SunOS (must) vxWorks drivers (must) audio, video (big plus) self-starter Contact Nam Nguyen at: (tel) (408) 743-4299 extension 4485 (fax) (408) 743-6425 (email) nam@esl.com (ascii format preferred) Nam Nguyen ESL Inc. nam@esl.com --------------------------- from: Newsgroups: ba.jobs.offered,comp.os.vxworks Subject: vxWorks Contract Position Date: 25 Jun 1994 01:48:36 GMT From: nam@peregrine.esl.com (Nam N. Nguyen) Organization: Cornell Theory Center Message-ID: <2ug2dk$c4l@gatekeeper.esl.com> ---------------------------------------------------------- Bob ____________________________________________________________ Bob Cleaves KineticsSystems 7308 S. Alton Way 303/220_7455x14 Englewood, CO. 80112 cleaves@kscorp.com ____________________________________________________________ From atl@adaclabs.com Tue Jul 26 10:20:03 1994 From: atl@adaclabs.com (Anthony Le) Date: Tue Jul 26 10:20:12 PDT 1994 Subject: open a large file in VxWorks. Can anyone explain to me, when VxWorks open a NFS file, It will keep this entire file locally or only only a portion of the file? How does VxWorks handle a large file (10MBytes) when my SBC memory has only 4MBytes? ------------------------ Anthony Le ADAC LABORATORY INC. Nuclear Enginering Dept. e-mail: atl@adaclabs.com ------------------------ From atl@adaclabs.com Tue Jul 26 10:40:15 1994 From: atl@adaclabs.com (Anthony Le) Date: Tue Jul 26 10:40:24 PDT 1994 Subject: loading object file containing a huge array This is a problem related to loading in VxWorks when declare a huge array in a program. When I declare a huge array of 2 MBytes (not use malloc() in my program) I can not load the object file to SBC. It complains about the memory patition error. But if I use malloc to allocate 2Mbytes, the loading is OK! and program run fine. Can any "vxPert" answer this problem? thank you. ------------------------ Anthony Le ADAC LABORATORY INC. Nuclear Enginering Dept. e-mail: atl@adaclabs.com ------------------------ From robert@orincon.com Tue Jul 26 12:57:00 1994 From: robert@orincon.com (Robert Redfield) Date: Tue Jul 26 12:57:38 PDT 1994 Subject: Ada to C Anybody got vendor names for products that convert Ada to C? Thanks. From daemon@vxw.ee.lbl.gov Wed Jul 27 04:00:30 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Jul 27 04:00:39 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jul 27 04:00:19 PDT 1994 Subject: Serial driver for NEC PD71051 Subject: Re: loading object file containing a huge array ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Serial driver for NEC PD71051 Date: Tue, 26 Jul 1994 11:04:22 GMT From: rsgawera@wg.icl.co.uk (Raj Gawera) Organization: International Computers Limited Message-ID: Reply-To: rsgawera@wg.icl.co.uk Sender: news@oasis.icl.co.uk Dear vxWorkers, Does anyone have a serial device driver (tyCoDrv.c) for the NEC PD71051 or similar device. I've had a look at a few drivers and they don't appear too difficult to write but if someones already done it ...? We will be using this device on the other end of VMEbus. Will this cause any particular problems ? cheers in advance, Raj Gawera Raj Gawera Designer ICL Corporate Systems email: rsgawera@wg.icl.co.uk --------------------------- Newsgroups: comp.os.vxworks Subject: Re: loading object file containing a huge array Date: Wed, 27 Jul 1994 08:43:36 GMT From: rsgawera@ss11.wg.icl.co.uk (Raj Gawera) Organization: International Computers Limited Message-ID: References: <9407261727.AA00582@adac.com> Reply-To: rsgawera@ss11.wg.icl.co.uk Sender: news@oasis.icl.co.uk In article AA00582@adac.com, atl@adaclabs.com (Anthony Le) writes: > > >This is a problem related to loading in VxWorks when declare >a huge array in a program. > >When I declare a huge array of 2 MBytes (not use malloc() in >my program) I can not load the object file to SBC. It complains >about the memory patition error. > >But if I use malloc to allocate 2Mbytes, the loading is OK! and >program run fine. > >Can any "vxPert" answer this problem? > >thank you. > >------------------------ >Anthony Le >ADAC LABORATORY INC. >Nuclear Enginering Dept. >e-mail: atl@adaclabs.com >------------------------ I am also interested to the answer to this one. Is there any easy commands that let you see where and how your memory has been allocated ? Or how much of it is free ? cheers, Raj Raj Gawera Designer ICL CSD email : rsgawera@wg.icl.co.uk --------------------------- End of New-News digest ********************** From vdbent@rulrol.leidenuniv.nl Wed Jul 27 07:17:03 1994 From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent) Date: Wed Jul 27 07:17:10 PDT 1994 Subject: How many bytes can be written to socket? Hi there, Is there a way to get the number of bytes that can be written to a socket file descriptor on the SunOS side of our application at a given time? Something similar to FIONWRITE under VxWorks maybe? (We only want to write complete messages to a socket, so we must decide if the a message will fit at the given time before attempting to write it.) Any help is appreciated! Sorry it's not a VxWorks related question :-) | ### ## | #### ### ## # | Kees van der Bent | #### ### | ## ## # ### ##### | Space Research Organisation Netherlands | #### ## | #### ## ## ## ## | P.O. Box 9504 2300 RA Leiden | #### | ## ## ### ## ## | The Netherlands | ## #### | | | ### #### | | +31-71-275805 | ## ### | | vdbent@rulrol.LeidenUniv.nl From chacon@tcville.es.hac.com Wed Jul 27 08:16:24 1994 From: chacon@tcville.es.hac.com (Kim Chacon) Date: Wed Jul 27 08:16:37 PDT 1994 Subject: Re: comp.os.vxworks newsdigest Raj Gawera writes: > I am also interested to the answer to this one. Is there any easy commands that let you see where and how your memory has been allocated ? Or how much of it is free ? You can use the VxWorks memLib commands, specifically memShow to show the system partition blocks and statistics, including currently allocated and free space. Use "memShow 1" to get a list of all the blocks in the free list of the memory pool. Note that there is also a way to add more memory to the memory pool with memAddToPool. I have found the memLib commands to be very useful. I hope this helps. Kim M. Chacon Hughes Aircraft Company email : chacon@tcville.es.hac.com From mwbrown@somnet.sandia.gov Wed Jul 27 12:55:36 1994 From: "Matthew W. Brown" Date: Wed Jul 27 12:55:45 PDT 1994 Subject: some useful networking info Well, here's some useful information to file away ... I've been working with multiple target boards and reconfiguring them frequently. Occasionally, after I had changed the parameters, the target wouldn't boot and I got the following error message: Error loading file: errno = 0x3c. (This is the ethernet timeout error) Anyway, I called WRS for support and they were of little help. I don't know about other people's experiences, but every time I ask them for help, I seem to have to spend a couple of days educating the "experts" so that I can ask them the question (and in the mean time they send me copies of their basic booting technotes). Here's the situation. The Sun (SunOs 4.1.3 at least--maybe UNIX in general) keeps Internet-to-Ethernet address translation tables in some sort of cache. You can display it by typing "arp -a" as illustrated below: w88{mwbrown}172: arp -a bilevel (1.0.0.21) at 0:80:2f:1:1:2 LSDAS3 (1.0.0.9) at 0:80:2f:1:1:1 Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 Now, I reconfigured one of my boards (LSDAS3) to a new address (1.0.0.7) and new target name (LSDAS1) and rebooted it. Note that the info for LSDAS3 still lingers on. w88{mwbrown}173: arp -a bilevel (1.0.0.21) at 0:80:2f:1:1:2 LSDAS1 (1.0.0.7) at 0:80:2f:1:1:1 LSDAS3 (1.0.0.9) at 0:80:2f:1:1:1 Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 So it's OK for a given board (ethernet hardware address 0:80:2f:1:1:1) to be assigned two inet addresses (in this case 1.0.0.7 and 1.0.0.9). Now when I tried to reconfigure bilevel [0:80:2f:1:1:2] to the no longer used LSDAS3 & (1.0.0.7) parameters I get the ethernet timeout error. It turns out that if I wait a few hours, it will boot OK--so I assume that this "cache" gets flushed after a while (does anyone know about this?). However, there is a better way then just waiting, and that is by using arp with the delete option (BTW, you need root privileges to use this option). w88# arp -d LSDAS3 LSDAS3 (1.0.0.9) deleted The board with ethernet hardware address 0:80:2f:1:1:2 will now boot up immediately. w88{mwbrown}174: arp -a bilevel (1.0.0.21) at 0:80:2f:1:1:2 LSDAS1 (1.0.0.7) at 0:80:2f:1:1:1 LSDAS3 (1.0.0.9) at 0:80:2f:1:1:2 Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 I hope that this information helps others avoid some aggravation (and research). BTW, if anyone from WRS is reading this, please forward it to your tech support guys so that they'll at least be familiar with the concepts! Matthew Brown mwbrown@sandia.gov From harjit@huey.jpl.nasa.gov Wed Jul 27 13:53:50 1994 From: harjit@huey.jpl.nasa.gov (Harjit Singh) Date: Wed Jul 27 13:54:00 PDT 1994 Subject: IEEE 488 help We are having some problems with the driver for our National Instruments GPIB 1014 board. When we use interrupts with the board, everything works fine. When we use programmed I/O, things start to fall apart. The system works most of the time. Occasionaly, the software hangs up while it is doing a serial poll. It seems that the board misses the End of Identify signal and then times out. Is anyone out there using the GPIB 1014 board in programmed mode ? If we cant solve the problem soon, we might switch to a Green Spring IP-488 board. Does anyone have any experience with this board ? Drivers ? Thanks for the help. Harjit Singh harjit@huey.jpl.nasa.gov From marge.pentek.com!tkl@pentek.com Wed Jul 27 14:59:03 1994 From: tkl@marge.pentek.com (Terry K. Lim) Date: Wed Jul 27 14:59:12 PDT 1994 Subject: Re: some useful networking info > w88# arp -d LSDAS3 > LSDAS3 (1.0.0.9) deleted > > The board with ethernet hardware address 0:80:2f:1:1:2 will now boot up > immediately. > > w88{mwbrown}174: arp -a > bilevel (1.0.0.21) at 0:80:2f:1:1:2 > LSDAS1 (1.0.0.7) at 0:80:2f:1:1:1 > LSDAS3 (1.0.0.9) at 0:80:2f:1:1:2 > Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 > > I hope that this information helps others avoid some aggravation (and > research). BTW, if anyone from WRS is reading this, please forward it to > your tech support guys so that they'll at least be familiar with the concepts! > > Matthew Brown > mwbrown@sandia.gov Matthew, I am glad you posted your findings! I was having a similar problem when swapping a target but keeping the same inet address. In this case the second target was not getting an ethernet timeout (it has a custom ROM so it doesn't boot over ethernet, but it does initialize the ethernet interface) The target would come up normally, but would not respond to network requests from my Sun, i.e. ping. Using arp -d solved my problem! Thanks. -- Terry Lim | Voice: (201) 767-7100 Senior Software Engineer | FAX: (201) 767-3994 Pentek, Inc. | BBS: (201) 767-8733 From stan@lassen.rti.com Wed Jul 27 23:11:05 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Wed Jul 27 23:11:18 PDT 1994 Subject: Re: loading object file containing a huge array >> Date: Wed, 27 Jul 1994 08:43:36 GMT >> From: rsgawera@ss11.wg.icl.co.uk (Raj Gawera) >> >> I am also interested to the answer to this one. Is there any easy >> commands that let you see where and how your memory has been allocated ? >> Or how much of it is free ? >> Hard to resist this one... memShow will get you the basics: how much is allocated & free, and a dump of the free list. RTILib has some much more extensive memory diagnostics, including a routine to check memory for consistency (HeapCheck), and a routine to trace all allocations & display which routines allocated which blocks (HeapTrace). HeapCheck is very useful for discovering memory errors; HeapTrace for finding leaks and figuring our how your program and VxWorks are using memory. It will tell you exactly how every block in your system was allocated. RTILib is included *free* with StethoScope. It's now also available separately. Besides the memory utilities, it includes a reentrant remote shell and terminal emulator, an execution tracing facility, a code patching tool, and more. -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From daemon@vxw.ee.lbl.gov Thu Jul 28 04:00:41 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Jul 28 04:00:54 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jul 28 04:00:19 PDT 1994 Subject: Re: open a large file in VxWorks. Subject: 68040 Bus Snooping/TAS and the smNet fixed. Subject: Prob. Loading VxWorks Subject: Re: some useful networking info Subject: Re: AM codes on VME bus ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: open a large file in VxWorks. Date: Wed, 27 Jul 1994 19:12:32 GMT From: jfinley@netcom.com (John Finley) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: References: <9407261720.AA00509@adac.com> Anthony Le (atl@adaclabs.com) wrote: : : Can anyone explain to me, when VxWorks open a NFS file, It will : keep this entire file locally or only only a portion of the file? : : How does VxWorks handle a large file (10MBytes) when my SBC memory : has only 4MBytes? : : ------------------------ : Anthony Le : ADAC LABORATORY INC. : Nuclear Enginering Dept. : e-mail: atl@adaclabs.com : ------------------------ If NFS is turned on (INCLUDE_NFS in configAll.h), then the file is read in as needed, i.e. it is not all kept in memory. If NFS is not turned on, and netDrv is used to access files, then when a file is opened for reading, the whole file is read into memory, and reads access it there. Don't know what it does if you open a file for writing... probably allocates memory as the file expands, then writes it all out when you close it. You can't open files bigger than available memory when using netDrv. - -John john@sd.aplabs.com --------------------------- Newsgroups: comp.os.vxworks Subject: 68040 Bus Snooping/TAS and the smNet fixed. Date: Wed, 27 Jul 1994 20:55:20 GMT From: johnx@wrs.com (John Fabiani) Organization: Wind River Systems, Inc. Keywords: mv167 mv162 68040 heatbeat Message-ID: Sender: news@wrs.com (News Manager) Greetings, > >From: ddavies@sim.es.com (Doug Davies) > >Newsgroups: comp.os.vxworks > >Subject: re: CACHE_SNOOP_ENABLE > >Date: Thu, 21 Jul 94 15:31:26 MDT > > > Can anybody tell me what the CACHE_SNOOP_ENABLE bit does when it is > > OR'ed into the USER_D_CACHE_MODE constant as follows: > > #define USER_D_CACHE_MODE (CACHE_COPYBACK|CACHE_SNOOP_ENABLE) > > I don't see my BSP doing anything with it other than passing > > USER_D_CACHE_MODE to the cacheLibInit() function. > > Beware of a nasty little condition that is not guarded... that is > the test and set operation. The bus snoop on the 68040 will not > guard a test and set operation. If you look in the BSP code you > will notice that if you enable the BP (back panel) network that the > BSP undef's bus snooping. This is due to the fact that the BP network > uses test and set operations. There is a patch that you can get from > Wind River that modifies the usrNetwork.c file such that the BP anchor > area is allocated and then marked uncachable. This gets around this > problem, but has a nasty side effect in that it puts the BP anchor > address at some wild/unintuative address. You will also need to play > around with the BSP to keep it from messing with the BUS_SNOOP > definition (if using the BP). > > -Doug This issue (SPR#2188) has been addressed in the most recent releases of the MVME-162/MVME-162-LX and the MVME-167 BSP's. These are the new part numbers: BSP-100599-0003 VxWorks BSP: MVME167/166 BSP-100623-0000 VxWorks BSP: Motorola MVME-162/162LX If you are using these versions then no modification is necesary to use the shared memory network. Sincerely, John Kevin Fabiani Technical Support Engineer Wind River Systems (510) 814-2167 (510) 814-2164 Fax (800) 872-4977 johnx@wrs.com support@wrs.com - -- /\_/\ ____________________ _ __/| ( o o ) | johnx@wrs.com | \`O.o' ==_Y_== | John Kevin Fabiani| =(_ _)= `-' \--------------------/ U --------------------------- Newsgroups: comp.os.vxworks Subject: Prob. Loading VxWorks Date: Wed, 27 Jul 1994 18:37:50 GMT From: depeltea@bcarh52d.bnr.ca (Gary Depelteau) Organization: Bell-Northern Research, Ottawa, Canada Message-ID: <1994Jul27.183750.1211@bcarh54a.bnr.ca> Sender: depeltea@bcarh52d (Gary Depelteau) Hi, I have been encountering a few intermittent problems while booting my target that occur around the time when VxWorks is being downloaded via ethernet or when the ethernet controller is being initialized. I would like to hear from anyone who has had similar problems, regarding solutions and/or experiences. First, let me describe my environment: Board: GPU960 (built by BNR/NT) BSP: Ported by myself Proc: I960CA Ethernet Controller: i82596CA Host WS: Sun4 running sunOS 4.1.3 Problem 1: Ethernet Timeout - --------------------------- The following will be printed out via the serial port: > >VxWorks System Boot > > >Copyright 1984-1993 Wind River Systems, Inc. > > > > > >CPU: GPU960 >Version: 5.1.1 >BSP version: 1.0 Beta-4 >Creation date: Fri Jul 8 09:57:13 EDT 1994 > > > > >Press any key to stop auto-boot... > 0 >auto-booting... > > >boot device : ei >processor number : 0 >host name : bcars782b >file name : >/bnr/3rdparty/glan_sw/WindRiver/vw/config/gpu2960/vxWorks >inet on ethernet (e) : 47.53.32.8:ffff0000 >host inet (h) : 47.53.32.1 >user (u) : nobody >ftp password (pw) : nobody >flags (f) : 0x8 >target name (tn) : gpu5 >startup script (s) : >/bnr/3rdparty/glan_sw/WindRiver/vw/config/gpu2960/debug.scr > >Attaching network interface ei0... done. >Attaching network interface lo0... done. >Loading... >Error loading file: errno = 0x3c. >Can't load boot file!! Errno 0x3c translates to S_enet_TIMEDOUT. I have run etherfind while the display has been sitting at "Loading..." and did not see any arp requests coming from the target. This leads me to believe it might be a HW problem but I am not sure. Also, I am not able to successfully ping my target at this point. Has anybody had any experience with this? Problem 2: Errno 0x1a9 - ---------------------- The same stuff is printed as above but the errno is 0x1a9. I am not sure what this errno refers to but WRS tech. support said that this is a known problem which is due to a bug in inetd in sunOS 4.1.x. I installed a patch that they recommended but this did not get rid of the problem. Has anybody got another solution to this problem, one that works? Problem 3: ei device did not initialize. This is what I se this time: >. >. >. >Attaching network interface ei0... >ei:device did not initialize This occurs when the ei driver SW has instructed the i82596CA to read a control data structure from shared RAM and the driver expects to see the i82596CA toggle a bit to indicate its done. Unfortunately, the device is not toggling the bit, so the driver times out after a while and prints the above. The RAM which is being shared by the i960CA and i82596CA has been fully tested at this point. Usually the board manages to boot on its own after rebooting several times when this problem occurs. I first thought that perhaps I did not put in the appropriate timing delays in the BSP functions that interface to the i82596 but I checked these and they seem to be OK. Anyone got any suggestions about this one? The boards we are working with are prototypes and I am very suspicious of the Ethernet HW on them but I would still appreciate anything anyone could share regarding these problems. Thanks a lot, Gary Depelteau Bell Northern Research depeltea@bnr.ca (613) 765-3340 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: some useful networking info Date: Thu, 28 Jul 1994 03:54:22 GMT From: jfinley@netcom.com (John Finley) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: References: <199407271956.NAA20912@somnet.sandia.gov> Matthew W. Brown (mwbrown@somnet.sandia.gov) wrote: [edited] : So it's OK for a given board (ethernet hardware address 0:80:2f:1:1:1) to : be assigned two inet addresses (in this case 1.0.0.7 and 1.0.0.9). Now : when I tried to reconfigure bilevel [0:80:2f:1:1:2] to the no longer used : LSDAS3 & (1.0.0.7) parameters I get the ethernet timeout error. It turns : out that if I wait a few hours, it will boot OK--so I assume that this : "cache" gets flushed after a while (does anyone know about this?). [edited some more] : Matthew Brown : mwbrown@sandia.gov An ARP entry is created when a host wants to send to an IP address but doesn't know the hardware address. It gets the hardware address by broadcasting an ARP request packet containing the IP address, and receiving (hopefully) an ARP reply packet with the hardware address. The host can then send the packet to the correct hardware address. The entry in the ARP cache (mapping from IP address to hardware address) is supposed to time out after 20 minutes, regardless of whether it is used or not, causing another ARP request to go out again if another packet needs to be sent to the same IP address. BSD TCP/IP implementations (which includes VxWorks) restart this timeout each time the entry is used, however. All I know about this comes from the excellent book "TCP/IP Illustrated, Volume 1 - The Protocols" by W. Richard Stevens. - -John Finley john@sd.aplabs.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: AM codes on VME bus Date: 27 Jul 1994 17:54:36 GMT From: steinley@fstop.csc.ti.com (Jeff Steinley 995-6414 msgid J2S) Organization: Texas Instruments Inc., DIVP Message-ID: <31670s$sdq@osage.csc.ti.com> References: <9407181626.AA17080@adac.com> Reply-To: steinley@fstop.csc.ti.com Anthony, With all the VME boards I have purchased & worked with, the AM code was modifiable on the h/w board itself. So the easiest fix would be to update the h/w to accept >3D (supervisory) rather than >39 (non-priviledged). If that won't work in your situation, then I believe you need to look at the following VxWorks routines to help solve your problem: - -) sysLib.c ; routine sysHwInit() In this routine (at least with my MVME167 BSP), the VMEchip2 is setup with what looks like the default AM's for specific CPU memory addresses. You might be able to modify this code and support the AM (>39) rather than having it send >3D. The following book, The VME Handbook, by Wade Peterson - should help you understand more about Address modifiers & the VME bus itself. This book is published by VITA - VFEA International Trade Association. Good Luck, Jeff Steinley Wk: 214-995-6414 Texas Instruments, Inc. --------------------------- End of New-News digest ********************** From stephenw@newbridge.com Thu Jul 28 09:29:10 1994 From: stephenw@newbridge.com (Stephen Williams) Date: Thu Jul 28 09:29:18 PDT 1994 Subject: Device Drivers Hi, I am looking for FREE (but I will entertain suggestions on purchased S/W) for VxWorks device drivers to support the MC68360 QUICC. I need such network protocols as V.36, V.24, X.25, HDLC, T1/E1, FrameRelay, sync UART, async UART, etc. You get the idea. I have seen the code that Motorola has on it's BBS, but this code is geared towards UNIX, not VxWorks. The only driver I have found from WRS so far is m68360Serial.c included with the BSP for the 360 QUADS board, but this driver only supports async UART to a terminal. If anyone has any information on ANY device drivers for the 360, please e-mail to stephenw@newbridge.com. I want to know what's out there before I redesign the wheel yet again! Thanks in advance, Steve. -- Stephen Williams Telephone: (613) 591-3600 Ext. 3485 Newbridge Networks Corporation G3 Fax: (613) 591-3680 Internet: stephenw@Newbridge.Com From csibtfr!eugenel@apple.com Thu Jul 28 09:52:20 1994 From: csibtfr!eugenel@apple.com (Eugene Leung) Date: Thu Jul 28 09:52:30 PDT 1994 Subject: graphics hardware/software We are looking to upgrade our realtime graphics. Anyone got any suggestions or recommendations on hardware and/or software. We would prefer an open architecture and X pops into our head. However, speed is a requirement! Thanks in advance. Eugene ================================================================================ - - - Eugene Leung + email: apple.com!csibtfr!eugenel - - Sr. S/W Engineer + phone: (408)371-9580 ext 714 - - Condor Systems Inc. + fax: (408)371-9589 - - - ================================================================================ From u4936@ironwood.cray.com Thu Jul 28 10:20:50 1994 From: u4936@ironwood.cray.com (Susan Cupp) Date: Thu Jul 28 10:20:59 PDT 1994 Subject: core file formatter for DRAM binary image? I was wondering whether anyone has a core file formatter for a DRAM binary image containing vxWorks? We would like to be able to format the binary image so that a debugger (gdb) could access the resulting core file. From visicom!VisiCom.COM!trest@lbl.gov Thu Jul 28 11:12:44 1994 From: Mike Trest Date: Thu Jul 28 11:12:56 PDT 1994 Subject: Re: some useful networking info > Matthew Brown > mwbrown@sandia.gov Writes about the long known problem of stale arp table. His observations are also true of other arp services (not just Sun). I have seen very experienced VxWorks gurus and consultants stumble over this same issue. [Names are available only after an appropriate level of entertainment at the next User's Confrence or trade show.] Therefore, it is unfortunate that Matthew was not "in the know" on this problem. Clearly, the problem could have been solved without access to the human experts. Matthew also touched on a very important issue. How much of this problem can be attributed to WRS? IMHO, none of the host's arp cache problem can be charged against WRS! However, it is reasonable for Matthew to expect WRS to relay this kind of "related information" even if it is not part of the WRS product software. Not being familiar with the related information and not passing it on to Matthew can be charged against WRS. True, WRS must be careful about bad-mouthing other vendor's products. But disclosure of a list of other things to be checked is not negative information. It is just information. How shall we, as an industry, resolve this problem of information gap? I praise Matthew for his contribution to the net, because this is one way to solve the information gap problem. In a larger view of things the FAQ file should have something about this and its existence should be disclosed to all VxWorks users and support people. Perhaps what we really need is different approach. Better access to the descriptions of problems and their typical solutions. My discussions with WRS folks at the recent User's Conference indicate that they are moving in the direction of a more "network smart" approach to closing this information gap. At VisiCom, we are planning to put this kind of FAQ into our WWW/Mosaic home page. Additionally, we are putting up an EMAIL "infoserv" service. This service will allow users to include key words of a problem description. The infoserv will then reasearch WRS on-line man-pages, WRS documentation, network FAQ, and VisiCom's internal reports. The first EMAIL response will a summary of the various resources available and how to get them. We also have anonymous FTP available for larger transfers. [Now 56kb, soon T1. We will not be publishing our own Mosaic home page until the T1 is on line.] At VisiCom, we already have the infrastructure in place to support this network smart approach to resolving the information gap. However, we do not have all the information available to WRS. Perhaps, WRS will pursue this technique prior to involving the human experts. Perhaps we can all begin using the new paradigm for a network smart solution to the information gap. As many of you have heard me say, I believe the future of the RTOS industry is OPEN not CLOSED. Perhaps, this is an opportunity to open the bandwidth to better information for all of us. ..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 tweadon@sadira.gb.nrao.edu Thu Jul 28 12:02:10 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Thu Jul 28 12:02:18 PDT 1994 Subject: Re: some useful networking info I learned the answer to Matthew Brown's problem (using arp -d) probably 9 months ago, and it has worked fine for me until recently. Sometimes when I try to delete my entry out of the stale arp table the system (Sparc) says that it couldn't find this entry. But my VxWorks system still fails to boot properly. If I look at the ethernet number on the card I'm booting and manually add it to the arp list like: arp -s myComputerName 8:0:3e:21:fb:b2 Then reboot my vxWorks sbc, everything works fine. Does any "expert" out there have any suggestions for this behavior. The system which this fails has two ethernet networks which it is on, this is probably the cause of the problem but how do I go about fixing it? Thanks Tim Weadon National Radio Astronomy Observatory Green Bank, WV. 24944 From singer@osfrt.mro1.dec.com Thu Jul 28 12:02:55 1994 From: singer@osfrt.mro1.dec.com Date: Thu Jul 28 12:03:04 PDT 1994 Subject: Re: graphics hardware/software >We are looking to upgrade our realtime graphics. >Anyone got any suggestions or recommendations on hardware and/or software. >We would prefer an open architecture and X pops into our head. However, >speed is a requirement! > >Thanks in advance. > >Eugene I've had preey good luck (and performance) with the Vigra 882 and X/Motif libraries from Visicom. Both companies seem reasonable to deal with and understand how their delays can effect a project schedule... ------------------------------------------------------------------------------- Matthew R. Singer LM Technology Systems Engineer Systems & Software Consulting singer@osfrt.mro1.dec.com VxWorks/Unix/MS-DOS/X Window/Motif 508-467-9108 508-877-8736 ------------------------------------------------------------------------------- From daemon@vxw.ee.lbl.gov Fri Jul 29 04:00:40 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Jul 29 04:00:55 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jul 29 04:00:26 PDT 1994 Subject: Network Interfaces Subject: Serial driver for board with MC68681 DUART Subject: Serial driver for MC68681 UART ? Subject: Re: some useful networking info Subject: MVME162 Flash Memory. Subject: Re: Serial driver for board with MC68681 DUART Subject: Re: some useful networking info Subject: Device Drivers Subject: Tcl for Vxworks Subject: OSI on VxWorks Subject: By-passing lengthy self-test Subject: ld68k core dumps ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Network Interfaces Date: 28 Jul 1994 08:40:16 GMT From: penny@paramount.sna.dec.com (Simon Penny) Organization: Digital Equipment Corporation Message-ID: <317qtg$fok@funlwb.stl.dec.com> Reply-To: penny@paramount.sna.dec.com (Simon Penny) In our VME crate we have an MV167 CPU card and a Radstone FDDI card. The CPU card is running VxWorks and we have a VxWorks driver for the FDDI card. We use that Ethernet interface of the CPU card to communicate with it, in that we rlogin to the crate and also send RPCs to the application software which we have running on the CPU card. This all works fine until I try to set up the FDDI interface. I can attach to the FDDI card (hooks in interrupts and a whole swag of other stuff) without any deterimental effect using the (Radstone supplied) rpfattach() routine in the VxWorks driver software. The FDDI card documentation then tells me to set up the internet address of the FDDI interface using the routine ifAddrSet("rpf0", "90.0.0.1"); (although we use the proper address of course). When I do this, the CPU card no longer responds to RPC messages received over the Ethernet (they time out) plus I may or may not be getting a heap of FDDI traffic. Basically, my application becomes useless whenever I execute the above routine. Does this sound familiar to anyone? Is there a problem with trying to bring a second net interface online? Is there a switch in the Kernel I need to make? What's happening? Thanks in advance, Simon --------------------------- Newsgroups: comp.os.vxworks Subject: Serial driver for board with MC68681 DUART Date: 28 Jul 1994 08:44:04 GMT From: vb@iriiw1.tudelft.nl (Victor R. Bom) Organization: Delft University of Technology Message-ID: <317r4k$nvb@liberator.et.tudelft.nl> Reply-To: vb@iriiw1.tudelft.nl (Victor R. Bom) Does anyone has a serial driver (tyCoDrv.c) for a board containing a Motorola MC68681, that they are willing to share ? This DUART is the communication chip used on the Struck STR612/CVC CAMAC crate controller. Thanks in advance, vb@iri.tudelft.nl or vb@iriiw1.tudelft.nl --------------------------- Newsgroups: comp.os.vxworks Subject: Serial driver for MC68681 UART ? Date: 28 Jul 1994 11:33:07 GMT From: vb@iriiw1.tudelft.nl (Victor R. Bom) Organization: Delft University of Technology Message-ID: <31851k$qkp@liberator.et.tudelft.nl> Reply-To: vb@iriiw1.tudelft.nl (Victor R. Bom) Article 1897 of comp.os.vxworks: Does anyone has a serial driver (tyCoDrv.c) for a board containing a Motorola MC68681, that they are willing to share ? This DUART is the communication chip used on the Struck STR612/CVC CAMAC crate controller. Thanks in advance, vb@iri.tudelft.nl or vb@iriiw1.tudelft.nl --------------------------- Newsgroups: comp.os.vxworks Subject: Re: some useful networking info Date: 28 Jul 1994 12:32:55 GMT From: singer@osfrt.mro1.dec.com (Matt Singer) Organization: Digital Equipment Corporation Message-ID: <3188hn$lsp@mrnews.mro.dec.com> References: <199407271956.NAA20912@somnet.sandia.gov> Reply-To: singer@osfrt.mro1.dec.com (Matt Singer) Sender: singer@osfrt (Matt Singer) In article <199407271956.NAA20912@somnet.sandia.gov>, "Matthew W. Brown" writes: |> |>Well, here's some useful information to file away ... |> |>I've been working with multiple target boards and reconfiguring them |>frequently. Occasionally, after I had changed the parameters, the target |>wouldn't boot and I got the following error message: |> |> Error loading file: errno = 0x3c. |> |>(This is the ethernet timeout error) |> |>Anyway, I called WRS for support and they were of little help. I don't |>know about other people's experiences, but every time I ask them for help, |>I seem to have to spend a couple of days educating the "experts" so that I |>can ask them the question (and in the mean time they send me copies of |>their basic booting technotes). |> |>Here's the situation. The Sun (SunOs 4.1.3 at least--maybe UNIX in general) |>keeps Internet-to-Ethernet address translation tables in some sort of |>cache. You can display it by typing "arp -a" as illustrated below: |> |>w88{mwbrown}172: arp -a |>bilevel (1.0.0.21) at 0:80:2f:1:1:2 |>LSDAS3 (1.0.0.9) at 0:80:2f:1:1:1 |>Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 |> |>Now, I reconfigured one of my boards (LSDAS3) to a new address |>(1.0.0.7) and new target name (LSDAS1) and rebooted it. Note that the info |>for LSDAS3 still lingers on. |> |>w88{mwbrown}173: arp -a |>bilevel (1.0.0.21) at 0:80:2f:1:1:2 |>LSDAS1 (1.0.0.7) at 0:80:2f:1:1:1 |>LSDAS3 (1.0.0.9) at 0:80:2f:1:1:1 |>Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 |> |>So it's OK for a given board (ethernet hardware address 0:80:2f:1:1:1) to |>be assigned two inet addresses (in this case 1.0.0.7 and 1.0.0.9). Now |>when I tried to reconfigure bilevel [0:80:2f:1:1:2] to the no longer used |>LSDAS3 & (1.0.0.7) parameters I get the ethernet timeout error. It turns |>out that if I wait a few hours, it will boot OK--so I assume that this |>"cache" gets flushed after a while (does anyone know about this?). |>However, there is a better way then just waiting, and that is by using arp |>with the delete option (BTW, you need root privileges to use this option). |> |>w88# arp -d LSDAS3 |>LSDAS3 (1.0.0.9) deleted |> |>The board with ethernet hardware address 0:80:2f:1:1:2 will now boot up |>immediately. |> |>w88{mwbrown}174: arp -a |>bilevel (1.0.0.21) at 0:80:2f:1:1:2 |>LSDAS1 (1.0.0.7) at 0:80:2f:1:1:1 |>LSDAS3 (1.0.0.9) at 0:80:2f:1:1:2 |>Xterm2 (1.0.0.13) at 8:0:2b:2b:88:e9 |> |>I hope that this information helps others avoid some aggravation (and |>research). BTW, if anyone from WRS is reading this, please forward it to |>your tech support guys so that they'll at least be familiar with the concepts! |> |>Matthew Brown |>mwbrown@sandia.gov |> You could also have done this: edit /etc/ethers. The format is: ethernet_address hostname If you do a man on rarpd, you will find that the file is read every 10 minutes for any changes. Of course doing arp -d is immediate... As a quick note, if you are booting from VxWorks proms and not bootp, then once you get to the boot prompt, you should be able to "ping" the SBC. In this case, since the arp table didn't match, you would have not received a reply which might have pointed the problem to network configuration and not something within VxWorks. When moving ID's around like this, booting with bootp is easier since the host is matching the ethernet hardware address and giving the target its ip address. I had a similar problem last week trying to use two inet interfaces and use VxWorks to gateway between them. If you had hooked up a network analyzer you might (or might not) have seen the packets going by with mis-matched src/dest addresses... - ------------------------------------------------------------------------------- Matthew R. Singer LM Technology Systems Engineer Systems & Software Consulting singer@osfrt.mro1.dec.com VxWorks/Unix/MS-DOS/X Window/Motif 508-467-9108 508-877-8736 - ------------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: MVME162 Flash Memory. Date: Thu, 28 Jul 1994 15:06:42 GMT From: barker@cds001.cebaf.gov (David Barker) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Message-ID: Reply-To: barker@cds001.cebaf.gov (David Barker) Sender: usenet@murdoch.acc.Virginia.EDU Hi, has anyone written code to program the MVME162 1MB of flash memory from VxWorks? We have done this from the 162bug system using the pflash command, but we would like to now do this dynamically from VxWorks. We have the spec sheets for the 28F020 Flash chips, and the 162 programmers reference guide, but this does not give enough detail to enable flash erase and write cycles. many thanks for any help. Dave Barker. CEBAF. Newport News. VA 23601. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Serial driver for board with MC68681 DUART Date: Thu, 28 Jul 1994 16:26:53 GMT From: van@venice.sedd.trw.com (Ken VanCouvering) Organization: TRW Systems Engineering & Development Division, Carson, CA Message-ID: <1994Jul28.162653.11788@venice.sedd.trw.com> References: <317r4k$nvb@liberator.et.tudelft.nl> Sender: news@venice.sedd.trw.com (USENET News) Victor R. Bom (vb@iriiw1.tudelft.nl) wrote: : Does anyone has a serial driver (tyCoDrv.c) for a board : containing a Motorola MC68681, that they are willing to share ? : This DUART is the communication chip used on the Struck STR612/CVC : CAMAC crate controller. : Thanks in advance, : vb@iri.tudelft.nl or vb@iriiw1.tudelft.nl I believe Wind River has the serial driver as well as the timer driver for the 68681. Ken --------------------------- Newsgroups: comp.os.vxworks Subject: Re: some useful networking info Date: Thu, 28 Jul 1994 14:47:22 GMT From: gerlach@netcom.com (Matthew H. Gerlach) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: ARP stands for Adress Resolution Protocol. It is method by which a machine can learn the hardware address of another given its IP address. The Sun like just about every IP talking host, maintains an arp table mapping hardware to to IP address mappings. As the other guy said, on a sun you can see this table with "arp -a". Entries in the ARP table age out. If you change a devices ethernet address, and don't want to wait for the Sun's arp table to age out, delete the arp entry with "arp -d boardname". Matthew H. Gerlach --------------------------- Newsgroups: comp.lang.c++,comp.object,comp.os.vxworks Subject: Device Drivers Date: Thu, 28 Jul 1994 17:10:11 GMT From: stephenw@Newbridge.COM (Stephen Williams) Organization: Newbridge Networks Corporation Message-ID: Reply-To: stephenw@Newbridge.COM Sender: usenet@Newbridge.COM I am looking for any stories people may like to share about writing Object-Oriented Device Drivers. We are using ObjecTime (A CASE tool), and would like to try to implement the drivers using this tool and C++. I am also looking for existing (object-oriented or not) device drivers to work under VxWorks for the MC68360 QUICC's network interface (ie: drivers for things like V.36, V.24, X.25, RS-232, RS-422, T1/E1, HDLC, async UART, sync UART, HDLC, etc. You get the idea) Please respond via e-mail, and I'll post all responses. Thanks. - --- Stephen Williams Telephone: (613) 591-3600 Ext. 3485 Newbridge Networks Corporation G3 Fax: (613) 591-3680 Internet: stephenw@Newbridge.Com --------------------------- Newsgroups: comp.os.vxworks,comp.lang.tcl Subject: Tcl for Vxworks Date: Thu, 28 Jul 94 16:55:04 GMT From: ruben@cs.washington.edu (Ruben Ortega) Organization: Computer Science & Engineering, U. of Washington, Seattle Message-ID: <1994Jul28.165504.28509@beaver.cs.washington.edu> Sender: news@beaver.cs.washington.edu (USENET News System) I saw a thread a few weeks back about Tcl for VxWorks. Was this extension a reality or just a figment of my imagination. IF it does exist, I would not mind getting a pointer to the ftp site. Thank you - -- - --------------------------------------------------------------------- Ruben E. Ortega | Dept. of CSE, University of Washington Ph.D. Grad Student | e-mail: ruben@cs.washington.edu - ---------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: OSI on VxWorks Date: Thu, 28 Jul 1994 17:28:54 GMT From: akr@acsu.buffalo.edu (Ajit K Ranganathan) Organization: UB Message-ID: Sender: nntp@acsu.buffalo.edu hi, i would like to know if anyone has worked on implementing OSI on vxworks. i would like some suggestions on how to go about doing this. thanks, ajit. my email address is akr@acsu.buffalo.edu akr@chort.cs.buffalo.edu also, this is for Bruce Baker who replied me. i have lost ur mail address by mistake.can u please email me ur address. i will mail in detail later to you. sorry for this personal reference. --------------------------- Newsgroups: comp.os.vxworks Subject: By-passing lengthy self-test Date: 29 Jul 1994 17:10:45 +1000 From: dmr@hercules.iassf.easams.com.au (Dewan RASHID) Organization: EASAMS (Australia) Pty Ltd Message-ID: <31aa1l$qo4@hercules.iassf.easams.com.au> Hi people: We have 6 MVME-167 VME processors, running VxWorks. We have got VxWorks EPROMS inserted in socket U1 and U2 of the 167 board to start the booting process. But in near future we want to use the 167-bug ROMs to use its debugging and diagnostic facility. I kept the 167-bug ROMs in their U1 and U2 sockets. We have installed two EPROMS of our own in U3 and U4 sockets. Now, VxWorks operating system is booting from these two EPROMS. We have configured the ENV parameters, so that the processor can boot from the BOOT EPROMs (by enabling the ROM BOOT). The booting scenario is as follows: - --- There is a lengthy self-test for around 5 minutes. Then the processor board switches to the ROM BOOTING procedure and ultimately we get the VxWorks prompt. - --- Now, we are trying to by-pass this lengthy self-test without elliminating the 167-bug EPROMS (because we also want to have this debugging and diagnostic facility). We can press ABORT button on the board to exit from self-test and can execute RB manually, but we want a automated procedure. Do you have any idea to achieve this. At the same time when we are at the VxWorks prompt, we can not use the "reboot" facility. We need to press RESET button on the processor board. Looking forward for some ideas from the VxWorks/MVME167 gurus. Thanks, Dewan. ====================================================================== Dewan M. Rashid | dmr@iassf.easams.com.au | EASAMS Australia (Ltd) | 61-2-367-4575 | GEC Marconi Systems. | | | | ====================================================================== The human brain is a complex organ with the wonderful power of enabling man to find reasons for continuing to believe whatever it is that he wants to believe. -Voltaire ====================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: ld68k core dumps Date: Fri, 29 Jul 1994 09:31:02 GMT From: aisic@actcom.co.il (Ilan Aisic) Organization: ACTCOM - ACTive COMmunication Ltd. - Internet Services Message-ID: Sender: news@wang.com Hi netters, We are developing code for VxWorks. We comile our code on Sun 4.1.x using the cross development commands to produce objects for the VxWorks. We compile with "cc68k -c -r -DCPU=MC68030 ...." The makefile finishes comilation and runs "ld68k -o -r " Which results with: "Segmentation fault (core dumped)" All this worked fine until yesterday afternoon when for some unknown reason, ld68k started to dump its core on us :-) It happens when we give it more than few object files to link together. We've tried to make more room in our filesystems and under /tmp but with no avail, we even rebooted our file server and the machine where we compile. We tried to link only few of the object files and it succeeds but when we add more object files it fails. Strangely enough, it doesn't seem to be consistant about the number fo files that are needed to crash it. This strengthened our theory that it happens because of some memory/disk space which it needs but we were unable to determine the needed resource. Because of this bug we are unable to proceed with our project. Any help will be greatly appreciated. Please post but also email. Attached: output from "trace ld68k..." Ilan Aisic, aisic@actcom.co.il Idepenedent Software Consultant tel: 972-4-836560, fax: 972-4-836547 - ----------- Below, please find a shortened version of the output produced by running Sun's "trace" on "ld68k": - ---- open ("/usr/lib/ld.so", 0, 0442120) = 3 read (3, "".., 32) = 32 mmap (0, 40960, 0x5, 0x80000002, 3, 0) = 0xf77e0000 mmap (0xf77e8000, 8192, 0x7, 0x80000012, 3, 32768) = 0xf77e8000 open ("/dev/zero", 0, 07) = 4 getrlimit (3, 0xf7fff818) = 0 mmap (0xf7800000, 8192, 0x3, 0x80000012, 4, 0) = 0xf7800000 close (3) = 0 getuid () = 1245 getgid () = 115 open ("/etc/ld.so.cache", 0, 0) = 3 fstat (3, 0xf7fff6b8) = 0 mmap (0, 4096, 0x1, 0x80000001, 3, 0) = 0xf77c0000 close (3) = 0 open ("/usr/openwin/lib", 0, 01010525) = 3 fstat (3, 0xf7fff6b8) = 0 mmap (0xf7802000, 8192, 0x3, 0x80000012, 4, 0) = 0xf7802000 getdents (3, 0xf78000f0, 8192) = 2852 getdents (3, 0xf78000f0, 8192) = 0 close (3) = 0 open ("/usr/lib/libc.so.1.8", 0, 0422160) = 3 read (3, "".., 32) = 32 mmap (0, 458764, 0x5, 0x80000002, 3, 0) = 0xf7730000 mmap (0xf779c000, 16384, 0x7, 0x80000012, 3, 442368) = 0xf779c000 close (3) = 0 open ("/usr/lib/libdl.so.1.0", 0, 0422200) = 3 read (3, "".., 32) = 32 mmap (0, 16396, 0x5, 0x80000002, 3, 0) = 0xf7710000 mmap (0xf7712000, 8192, 0x7, 0x80000012, 3, 8192) = 0xf7712000 close (3) = 0 close (4) = 0 getpagesize () = 4096 brk (0x28748) = 0 brk (0x29748) = 0 gettimeofday (0x25a60, 0) = 0 getrusage (0, 0x25170) = 0 getrusage (-1, 0xf7fff848) = 0 getuid () = 1245 dup2 (0, 16) = 16 ioctl (16, 0x20006601, 0) = 0 dup2 (1, 17) = 17 ioctl (17, 0x20006601, 0) = 0 dup2 (2, 18) = 18 ioctl (18, 0x20006601, 0) = 0 dup2 (16, 19) = 19 ioctl (19, 0x20006601, 0) = 0 getdomainname ("", 256) = 0 close (0) = 0 close (1) = 0 close (2) = 0 close (3) = -1 EBADF (Bad file number) . . close (255) = -1 EBADF (Bad file number) stat ("./", 0xf7ffe390) = 0 stat ("/", 0xf7ffe350) = 0 open ("./../", 0, 036734754630) = 0 fstat (0, 0xf7ffdeb0) = 0 brk (0x2c748) = 0 fcntl (0, 02, 0x1) = 0 fstat (0, 0xf7ffe390) = 0 getdents (0, 0x29198, 8192) = 100 close (0) = 0 open ("./../../", 0, 0) = 0 fstat (0, 0xf7ffdeb0) = 0 fcntl (0, 02, 0x1) = 0 fstat (0, 0xf7ffe390) = 0 getdents (0, 0x29198, 8192) = 384 close (0) = 0 open ("./../../../", 0, 0) = 0 fstat (0, 0xf7ffdeb0) = 0 fcntl (0, 02, 0x1) = 0 fstat (0, 0xf7ffe390) = 0 getdents (0, 0x29198, 8192) = 88 close (0) = 0 open ("./../../../../", 0, 0) = 0 fstat (0, 0xf7ffdeb0) = 0 fcntl (0, 02, 0x1) = 0 fstat (0, 0xf7ffe390) = 0 getdents (0, 0x29198, 8192) = 156 close (0) = 0 open ("./../../../../../", 0, 0) = 0 fstat (0, 0xf7ffdeb0) = 0 fcntl (0, 02, 0x1) = 0 fstat (0, 0xf7ffe390) = 0 getdents (0, 0x29198, 8192) = 140 close (0) = 0 open ("./../../../../../../", 0, 0) = 0 fstat (0, 0xf7ffdeb0) = 0 fcntl (0, 02, 0x1) = 0 fstat (0, 0xf7ffe390) = 0 open ("/etc/mtab", 0, 0666) = 1 ioctl (1, 0x40125401, 0xf7ffdc14) = -1 ENOTTY (Inappropriate ioctl for device) fstat (1, 0xf7ffdc88) = 0 brk (0x2f748) = 0 read (1, "/dev/sd0a / 4.2 rw,dev=0700 1 1\n".., 8192) = 788 lstat ("/home11", 0xf7ffdeb0) = 0 lstat ("/home11/..", 0xf7ffdeb0) = 0 close (1) = 0 close (0) = 0 getpid () = 6668 sigblock (0x2) = 0 sigvec (2, 0, 0xf7fff9a0) = 0 sigsetmask (0) = 0x2 sigblock (0x4000) = 0 sigvec (15, 0, 0xf7fff9a0) = 0 sigsetmask (0) = 0x4000 open ("/home25/vw/vw_gnu68k/sun4.68k/bi".., 0, 037) = 0 dup2 (0, 16) = 16 ioctl (16, 0x20006601, 0) = 0 getuid () = 1245 getgid () = 115 getgid () = 115 ioctl (16, 0x40125401, 0xf7fff87c) = -1 ENOTTY (Inappropriate ioctl for device) lseek (16, 0, 1) = 0 lseek (16, 0, 1) = 0 getpgrp (0) = 6667 sigblock (0x80000) = 0 sigvec (20, 0xf7fff884, 0xf7fff878) = 0 sigvec (20, 0xf7fff80c, 0) = 0 sigsetmask (0) = 0x80000 sigblock (0x80000) = 0 sigvec (20, 0xf7fff884, 0) = 0 sigvec (20, 0xf7fff80c, 0) = 0 sigsetmask (0) = 0x80000 sigblock (0) = 0 sigstack (0, 0xf7fff884) = 0 sigblock (0) = 0 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0 sigsetmask (0) = 0 read (16, "#!/bin/csh -f\n\nset cfile = $0\n\ni".., 1024) = 126 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 close (0) = 0 dup (19) = 0 close (1) = -1 EBADF (Bad file number) dup (17) = 1 close (2) = -1 EBADF (Bad file number) dup (18) = 2 close (0) = 0 close (1) = 0 close (2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 close (0) = -1 EBADF (Bad file number) dup (19) = 0 close (1) = -1 EBADF (Bad file number) dup (17) = 1 close (2) = -1 EBADF (Bad file number) dup (18) = 2 stat ("/bin/sunview", 0xf7ffec68) = 0 close (0) = 0 close (1) = 0 close (2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 sigblock (0x80000) = 0x2 sigblock (0x2) = 0x80002 sigvec (2, 0, 0xf7fff704) = 0 sigsetmask (0x80002) = 0x80002 vfork () = 6669 gettimeofday (0x2c63c, 0) = 0 sigblock (0x2) = 0x80002 sigvec (2, 0xf7fff704, 0) = 0 sigvec (2, 0xf7fff62c, 0) = 0 sigsetmask (0x80002) = 0x80002 sigsetmask (0x2) = 0x80002 sigblock (0x80000) = 0x2 sigsetmask (0x2) = 0x80002 sigblock (0x80000) = 0x2 sigblock (0) = 0x80002 sigpause (0x2) = -1 EINTR (Interrupted system call) - - SIGCHLD (20) wait4 (0, 0xf7ffebc4, 0x3, 0xf7ffeb7c) = 6669 wait4 (0, 0xf7ffebc4, 0x3, 0xf7ffeb7c) = -1 ECHILD (No children) sigcleanup () = 0 sigsetmask (0x2) = 0x80002 ioctl (17, 0x4004747c, 0xf7fff3ac) = 0 write (17, "Segmentation fault (core dumped)".., 33) = 33 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 sigblock (0x2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff774) = 0 close (0) = -1 EBADF (Bad file number) dup (19) = 0 close (1) = -1 EBADF (Bad file number) dup (17) = 1 close (2) = -1 EBADF (Bad file number) dup (18) = 2 close (0) = 0 close (1) = 0 close (2) = 0 sigblock (0) = 0x2 sigstack (0, 0xf7fff7fc) = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 read (16, "", 1024) = 0 ioctl (16, 0x40067408, 0xf7fff7a0) = -1 ENOTTY (Inappropriate ioctl for device) sigcleanup () = 0 sigblock (0) = 0x2 sigsetmask (0) = 0x2 exit (0) = ? --------------------------- End of New-News digest ********************** From ihw@rtp.co.uk Fri Jul 29 11:21:21 1994 From: ihw@rtp.co.uk (Ian Willats) Date: Fri Jul 29 11:21:29 PDT 1994 Subject: By-passing lengthy self-test (on MVME-167) dmr@iassf.easams.com.au asked: > Now, we are trying to by-pass this lengthy self-test without > elliminating the 167-bug EPROMS (because we also want to have > this debugging and diagnostic facility). We can press ABORT > button on the board to exit from self-test and can execute RB > manually, but we want a automated procedure. Do you have any > idea to achieve this. I think you can use the 167-bug "env" command to disable the self-test. It still takes about fifteen or twenty seconds to do the rom-boot search, though. > At the same time when we are at the VxWorks prompt, we can not > use the "reboot" facility. We need to press RESET button on the > processor board. This is probably because the routine "sysToMonitor()" in "sysLib.c" will be making a jump to where it thinks the VxWorks boot ROM code _normally_ lives, i.e. in U1/U2 not U3/U4. If you look at this function you'll see a line: FUNCPTR pRom = (FUNCPTR) (ROM_TEXT_ADRS + 8); Hopefully if you replace ROM_TEXT_ADRS with the base address of the ROMs in U3/U4 instead (0xffa00000 from memory), the "reboot()" function and ^X should work properly. Hope this helps, Ian ----------------------------------------------------------------------- e-mail: ihw@rtp.co.uk post: Real Time Products Ltd., tel: +44 21 333 6955 Unit 8, Holt Court, fax: +44 21 333 5433 Aston Science Park, Jennens Road, Birmingham. B7 4EJ England. ----------------------------------------------------------------------- From guthrie@power.amasd.anatcp.rockwell.com Fri Jul 29 13:33:25 1994 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Fri Jul 29 13:33:33 PDT 1994 Subject: CACHE_SNOOP_ENABLE Thanks for all of the replies to my question. I think I understand this now. I wanted to post a reply I got from Marc Shepard of Wind River Systems, Inc. This explains exactly what cacheLib does with the CACHE_SNOOP_ENABLE bit of USER_D_CACHE_MODE. > Basically the cache mode you select determines weather or not > the hardware's cache routines are actually called when you > use the FLUSH/INVALIDATE macros. > > There are several structures containing cache manipulation function pointers: > > cacheLib - the "true" cache manipulation routines for the hardware. > the CACHE_XXX macros access these functions. This structure would > have been better named "cacheTrueFuncs". > > cacheDmaFuncs - cache functions for manipulating driver buffers > obtained via cacheDmaMalloc(). Drivers use the CACHE_DMA_XXX > macros to access these functions in order to flush/invalidate. > > cacheUserFuncs - cache functions for manipulating buffers > passed to the driver by the user. Drivers use the > CACHE_USR_XXX macros to access these functions to flush/invalidate. > > The cache mode affects the function pointers in the cacheUserFuncs > and cacheDmaFuncs structures. > For example, in writethrough mode, the CACHE_USR_FLUSH > macro become a nop because the corresponding cacheUserFuncs.flushRtn > function pointer is set to NULL in write through mode. > Similarly, in snooping mode or with caches disables, *all* the cacheUsrFuncs > are set to NULL. > In copyback mode with no snooping, the usrFuncs are > simply set to the corresponding cacheLib function pointers. > If you have an MMU, then cacheDmaMalloc returns a buffer which has the > cache turned off, so the cacheDma flush/invalidate macros become nops. > If the board has no MMU, the the cacheDma functions are set just > like the cacheUsers functions. > This allows drivers to use the CACHE_DMA_XXX and CACHE_USR_XXX > macros, and have the driver still work (in theory) regardless of > the cache mode available on the board. > > -Marc > > -- > > -Marc Shepard > > ``` > (o o) > -----------------oOO--(_)--OOo-------------------- > marc@wrs.com (510)814-2142 > -------------------------------------------------- > From daemon@vxw.ee.lbl.gov Sat Jul 30 04:00:47 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Jul 30 04:00:57 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jul 30 04:00:35 PDT 1994 Subject: Re: 68060, MVME177 plans Subject: Re: some useful networking info Subject: MVME332 / 333 driver. Subject: Re: loading object file containing a huge array Subject: Re: By-passing lengthy self-test ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: 68060, MVME177 plans Date: Fri, 29 Jul 1994 01:42:52 GMT From: kevinr@ceco.ceco.com (Kevin R. Rumbaugh) Organization: Commonwealth Edison Co. Message-ID: References: In article clare@bisco.kodak.com (clare) writes: > >Does anyone have any information regarding VxWorks development packages >targetted towards the 68060/MVME177 platforms? Are there any immediate plans >to support this new platform? > We had a sales man in yesterday from Motorola and on their glossy for the 177 they said it had VxWorks support. I would call your WRS sales man and ask. If it is not out, it soon will be. The board is not all that changed from the 167 as it uses the same VME chip, same SCSI chip, same Ethernet chip, same NVRAM/clock chip, and the same paralle/serial chipset (I think on this last one). So all that said, it shouldn't take WRS more than a week at the most to do a BSP for it, unless they really modified the MMU again. Kevin Rumbaugh 'The Marauder' --- Commonwealth Edison --- A Unicom division 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 - -- Kevin Rumbaugh 'The Marauder' --- Commonwealth Edison --- A Unicom division --------------------------- Newsgroups: comp.os.vxworks Subject: Re: some useful networking info Date: 28 Jul 1994 23:51:49 GMT From: synergy@nic.cerf.net (John E. Clark) Organization: CERFnet Dial n' CERF Customer Message-ID: <319gal$3nu@news.cerf.net> References: <9407281901.AA26256@sadira.gb.nrao.edu> In article <9407281901.AA26256@sadira.gb.nrao.edu> tweadon@sadira.gb.nrao.edu (TIM WEADON) writes: +I learned the answer to Matthew Brown's problem (using arp -d) probably +9 months ago, and it has worked fine for me until recently. + +Sometimes when I try to delete my entry out of the stale arp table +the system (Sparc) says that it couldn't find this entry. But my +VxWorks system still fails to boot properly. If I look at the ethernet +number on the card I'm booting and manually add it to the arp list like: +arp -s myComputerName 8:0:3e:21:fb:b2 I think everyone should port 'BSD-4.4'(the most currently available) networking code to some target. Then the arcania associated with the berkeley TCP/IP stack should be well in hand, then some of the WRS 'oops' or SunOS, or what the heck, VMS with TGV's product would 'make sense'.(Well, if not port it, print it out as it is publicly available). I've not seen the above problem, but have for a long time seen the need for the 'arp -d' on a stale IP/ETHERNET association. We make CPU cards and use assigned IP number for test fixture setups. If the particular board is changed 'too quickly' and has a new ETHERNET address the problem occurs occasionally. --------------------------- Newsgroups: comp.os.vxworks Subject: MVME332 / 333 driver. Date: Fri, 29 Jul 94 12:26:29 GMT From: jpcalvez@ifremer.fr (Jean Pierre Calvez) Organization: Ifremer Message-ID: <1994Jul29.122629.29759@molene.ifremer.fr> References: <9407261720.AA00509@adac.com> Reply-To: jpcalvez@ifremer.fr Sender: news@molene.ifremer.fr Has anyone knowledge of a driver for MVME332 or MVME333 ? If yes, where is it available ? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: loading object file containing a huge array Date: Fri, 29 Jul 1994 20:37:46 GMT From: healy@nosc.mil (Mike Healy) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Jul29.203746.18315@nosc.mil> References: <9407261727.AA00582@adac.com> Sender: news@nosc.mil In article <9407261727.AA00582@adac.com> atl@adaclabs.com (Anthony Le) writes: > > >This is a problem related to loading in VxWorks when declare >a huge array in a program. > >When I declare a huge array of 2 MBytes (not use malloc() in >my program) I can not load the object file to SBC. It complains >about the memory patition error. > >But if I use malloc to allocate 2Mbytes, the loading is OK! and >program run fine. > In config.h and in the Makefile you need to increase the value of RAM_HIGH_ADDRESS so that you have a larger area of memory to load the system into. Then make bootrom.hex and burn new bootroms. I have RAM_HIGH_ADDRESS set to 0x400000 and have 4 MByte vxWorks images with 2 MByte symbol tables. This is vxWorks 5.1 on Force CPU-40s. Mike Healy ETA Technologies healy@nosc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Re: By-passing lengthy self-test Date: Fri, 29 Jul 1994 14:40:13 +0000 From: anj@mail.ast.cam.ac.uk (Andrew Johnson) Organization: Royal Greenwich Observatory Message-ID: References: In article <31aa1l$qo4@hercules.iassf.easams.com.au> dmr@hercules.iassf.easams.com.au (Dewan RASHID) writes: >We have 6 MVME-167 VME processors, running VxWorks. We have >got VxWorks EPROMS inserted in socket U1 and U2 of the 167 board >to start the booting process. >But in near future we want to use the 167-bug ROMs to use its >debugging and diagnostic facility. >I kept the 167-bug ROMs in their U1 and U2 sockets. We have >installed two EPROMS of our own in U3 and U4 sockets. Now, >VxWorks operating system is booting from these two EPROMS. >We have configured the ENV parameters, so that the processor >can boot from the BOOT EPROMs (by enabling the ROM BOOT). >The booting scenario is as follows: >--- >There is a lengthy self-test for around 5 minutes. Then the >processor board switches to the ROM BOOTING procedure and >ultimately we get the VxWorks prompt. >--- >Now, we are trying to by-pass this lengthy self-test without >elliminating the 167-bug EPROMS (because we also want to have >this debugging and diagnostic facility). We can press ABORT >button on the board to exit from self-test and can execute RB >manually, but we want a automated procedure. Do you have any >idea to achieve this. Your 167Bug is starting up in System mode (See the MVME167BUG/D2 manual, page 2-2). Use the ENV command to set this to Bug mode: 1. Turn the system on (or reset it) and Abort the self-tests. 2. Type ENV 3. Type B to Select Bug mode. 4. Type . to exit the ENV command. 5. Say Y to update the NVRAM parameters. The system should now come up in Bug mode without the self-test delays. You can also get it turn on the ROM-Boot from here, using later questions in ENV. I don't think you'll manage to get VxWorks to coexist with the Debug monitor though, if this is what you are trying to do. On a related question, has anyone managed to get MVME167Bug to boot VxWorks over the network without needing the VxWorks BootROMs installed? It seems to have all the necessary support for RARP, BOOTP and TFTP. If anyone already does this, could they drop me a line or post here; I haven't tried it yet, but would like to do this if it can be made to work. - - Andrew ,_}\_. http://cast0.ast.cam.ac.uk/~anj/ / \ anj@mail.ast.cam.ac.uk ~~~~~~~~| ,--/;. )~~~~ _ _ ., |/ (/ U / \ ___ _| |_ _ ___ _ _ .`., /_\ . . | - | | . | ~_| -_| |~| | wwWWWww' |_|_|_|_|___|_| |___|_____| --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Jul 31 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Jul 31 04:00:31 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jul 31 04:00:12 PDT 1994 Subject: Wanted: FAQ list Subject: Re: Serial driver for board with MC68681 DUART ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Wanted: FAQ list Date: 29 Jul 1994 18:58:23 -0000 From: dewaard@news.delphi.com (DEWAARD@DELPHI.COM) Organization: Delphi Internet Services Corporation Message-ID: <31bjgf$o7e@news.delphi.com> Hi all-- Could anyone tell me where I can find a VxWorks FAQ? Thanks in advance, Henk de Waard dewaard@delphi.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Serial driver for board with MC68681 DUART Date: 29 Jul 94 08:30:42 -0400 From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer) Organization: NRL SPACE SYSTEMS DIVISION Message-ID: <1994Jul29.083043.1404@nrlvx1.nrl.navy.mil> References: <317r4k$nvb@liberator.et.tudelft.nl> In article <317r4k$nvb@liberator.et.tudelft.nl>, vb@iriiw1.tudelft.nl (Victor R. Bom) writes: > > > Does anyone has a serial driver (tyCoDrv.c) for a board > containing a Motorola MC68681, that they are willing to share ? > > This DUART is the communication chip used on the Struck STR612/CVC > CAMAC crate controller. > > Thanks in advance, > > vb@iri.tudelft.nl or vb@iriiw1.tudelft.nl > WRS has one. They don't list it, you have to ask for it (well, that was our experience, anyway). - -- Doug Dyer - dyer@alx.sticomet.com | Real-time systems . * //[]// Software Technology, Inc. (STI) | Space flight/ground software ^^ . DC office: (703) 329-9707 | vxWorks BSPs, etc. . --------------------------- End of New-News digest ********************** From thor@thor.atd.ucar.edu Sun Jul 31 23:00:14 1994 From: thor@thor.atd.ucar.edu (Rich Neitzel) Date: Sun Jul 31 23:00:24 PDT 1994 This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx ------------------------------------------------ VxWorks sources: total 9486 -rw-r--r-- 1 thor staff 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor staff 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor staff 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor staff 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor staff 37126 Jun 12 1992 ansilib01 -rw-r--r-- 1 thor staff 18913 Jun 12 1992 ansilib02 -rw-r--r-- 1 thor staff 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor staff 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor staff 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor staff 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor staff 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor staff 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor staff 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor staff 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor staff 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor staff 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor staff 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor staff 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor staff 41669 Dec 6 1991 dhrystones01 -rw-r--r-- 1 thor staff 19170 Apr 1 1993 dirlib01 -rw-r--r-- 1 thor staff 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor staff 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor staff 11561 Nov 1 1991 flags_class.shar -rw-rw-r-- 1 thor rsf 88109 Jul 11 12:36 flash.zip -rw-rw-r-- 1 thor rsf 81201 Jul 11 11:44 flash2.zip -rw-r--r-- 1 thor staff 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor staff 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor staff 80491 May 8 1989 force.shar -rw-r--r-- 1 thor staff 2453 Mar 10 1993 gcc+68040 -rw-r--r-- 1 thor staff 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor staff 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor rsf 13275 Jul 12 08:02 index -rw-r--r-- 1 thor staff 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor staff 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor staff 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor staff 9079 Apr 2 1990 lclflag.shar -rw-r--r-- 1 thor rsf 174829 Dec 3 1993 lexyacc.tar.gz drwxr-xr-x 2 thor staff 512 Mar 21 12:15 libX11 -rw-r--r-- 1 thor staff 10747 Nov 3 1993 libg++-2.5-src.patch lrwxrwxrwx 1 root other 20 Mar 19 19:08 libg++-2.5.1-src.patch -> libg++-2.5-src.patch lrwxrwxrwx 1 root other 20 Mar 19 19:08 libg++-2.5.2-src.patch -> libg++-2.5-src.patch -rw-r--r-- 1 thor staff 1568 Nov 3 1993 libgcc2-2.5.0.patch -rw-r--r-- 3 thor staff 1545 Nov 3 1993 libgcc2-2.5.2.patch lrwxrwxrwx 1 root other 19 Mar 19 19:08 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch -rw-r--r-- 3 thor staff 1545 Nov 3 1993 libgcc2-2.5.5.patch -rw-r--r-- 3 thor staff 1545 Nov 3 1993 libgcc2-2.5.6.patch lrwxrwxrwx 1 root other 15 Mar 19 19:07 libio-2.5.1.patch -> libio-2.5.patch lrwxrwxrwx 1 root other 15 Mar 19 19:08 libio-2.5.2.patch -> libio-2.5.patch -rw-r--r-- 1 thor staff 1228 Dec 29 1993 libio-2.5.patch lrwxrwxrwx 1 root other 6 Mar 19 19:07 libx11 -> libX11 -rw-r--r-- 1 thor staff 3515 Mar 16 1993 loadmeter.shar -rw-r--r-- 1 thor staff 10399 May 4 1989 math.shar -rw-r--r-- 1 thor staff 11950 May 30 1989 math2 -rw-r--r-- 1 24 40 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor staff 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor staff 829713 Dec 17 1993 ntpv3.1.tar.gz -rw-r--r-- 1 thor staff 1010176 Nov 8 1993 ntpv3.tar.gz -rw-r--r-- 1 thor staff 1082 Dec 14 1993 objc.patch -rw-r--r-- 1 thor staff 19422 Mar 1 07:25 ping01 -rw-r--r-- 1 thor staff 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor staff 15418 May 30 1989 poolLib lrwxrwxrwx 1 root other 7 Mar 19 19:07 poollib -> poolLib -rw-r--r-- 1 thor staff 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor staff 6614 May 31 1989 semCnt lrwxrwxrwx 1 root other 6 Mar 19 19:07 semcnt -> semCnt -rw-r--r-- 1 thor staff 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor staff 41196 Oct 16 1992 stevie01 -rw-r--r-- 1 thor staff 35279 Oct 16 1992 stevie02 -rw-r--r-- 1 thor staff 35278 Oct 16 1992 stevie03 -rw-r--r-- 1 thor staff 35012 Oct 16 1992 stevie04 -rw-r--r-- 1 thor staff 34502 Oct 16 1992 stevie05 -rw-r--r-- 1 thor staff 37476 Oct 16 1992 stevie06 -rw-r--r-- 1 thor staff 30073 Oct 16 1992 stevie07 -rw-r--r-- 1 thor staff 31562 Oct 16 1992 stevie08 -rw-r--r-- 1 thor staff 37360 Oct 16 1992 stevie09 -rw-r--r-- 1 thor staff 20662 Oct 16 1992 stevie10 -rw-r--r-- 1 thor staff 25717 Oct 16 1992 stevie11 -rw-r--r-- 1 thor staff 28075 Oct 16 1992 stevie12 -rw-r--r-- 1 thor staff 31852 Oct 16 1992 stevie13 -rw-r--r-- 1 thor staff 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor staff 8424 Apr 1 1992 syslog.shar -rw-r--r-- 1 thor staff 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor staff 16171 Oct 9 1990 taskmon.shar -rw-rw-r-- 1 root other 416642 Jan 7 1994 tclvx7.0v4.tar.gz -rw-r--r-- 1 thor staff 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor staff 19912 Aug 27 1992 tp41.shar -rw-r--r-- 1 thor staff 25790 Nov 8 1990 ty335.shar -rw-r--r-- 2 thor rsf 44504 May 2 11:03 usrTime.shar -rw-r--r-- 2 thor rsf 44504 May 2 11:03 usrtime.shar -rw-r--r-- 1 thor rsf 4945 Apr 28 11:31 veclist01 -rw-r--r-- 1 thor staff 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor staff 43671 Nov 22 1991 vwcurses01 -rw-r--r-- 1 thor staff 40180 Nov 22 1991 vwcurses02 -rw-r--r-- 1 thor staff 38308 Nov 22 1991 vwcurses03 -rw-r--r-- 1 thor staff 31181 Nov 22 1991 vwcurses04 -rw-r--r-- 1 thor staff 31798 Nov 22 1991 vwcurses05 -rw-r--r-- 1 thor staff 31459 Nov 22 1991 vwcurses06 -rw-r--r-- 1 thor staff 24279 Nov 22 1991 vwcurses07 -rw-r--r-- 1 thor staff 5491 Dec 8 1993 vx_cplusplus -rw-r--r-- 1 thor rsf 42922 Jul 12 07:56 vxrouted01 -rw-r--r-- 1 thor rsf 40197 Jul 12 07:56 vxrouted02 -rw-r--r-- 1 thor rsf 43496 Jul 12 07:56 vxrouted03 -rw-r--r-- 1 thor rsf 37663 Jul 12 07:56 vxrouted04 -rw-r--r-- 1 thor rsf 32826 Jul 12 07:56 vxrouted05 -rw-r--r-- 1 thor rsf 34217 Jul 12 07:56 vxrouted06 -rw-r--r-- 1 thor rsf 40719 Jul 12 07:56 vxrouted07 -rw-r--r-- 1 thor rsf 15689 Jul 12 07:56 vxrouted08 -rw-r--r-- 1 thor staff 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor staff 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor staff 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor staff 4702 Jan 16 1992 wdog_class