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 <pardoe@ncp.gpt.co.uk> 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 <pardoe@ncp.gpt.co.uk> 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: <Cs85Gz.qA@wrs.com>


    

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: <Cs874D.7LG@lcpd2.SanDiegoCA.NCR.COM>
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: <Cs9rCF.Gon@murdoch.acc.Virginia.EDU>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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 <irwin@neosoft.com>
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: <CsJ17B.K8F@vcd.hp.com>
References: <CsHqy5.FwA@vcd.hp.com>
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: <CsHA94.ECK@wrs.com>
References: <RAMEY.94Jun28144036@gnat.den.mmc.com>
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: <CsHqy5.FwA@vcd.hp.com>

In article <CsHqy5.FwA@vcd.hp.com>, 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: <CsHqy5.FwA@vcd.hp.com>
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: <rls.773529024@frank>



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: <CsJE9K.8D8@wrs.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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 <wfogleso@astro.ge.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <scott@indev.interactive.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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 <pean@mbari.org>
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]" <mike@imatron.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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" <AMMGR@msgate.emis.hac.com>
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/<BSP>/vxWorks
and $VXWORKS/config/<BSP>/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 <bootDir> */
 
    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/<BSP>/vxWorks
and $VXWORKS/config/<BSP>/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 <bootDir> */
 
    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/<BSP>/vxWorks
and $VXWORKS/config/<BSP>/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 <bootDir> */
 
    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/<BSP>/vxWorks
and $VXWORKS/config/<BSP>/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 <bootDir> */
 
    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/<BSP>/vxWorks
>and $VXWORKS/config/<BSP>/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 <bootDir> */
> 
>    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: <robnettCsnto7.5Mw@netcom.com>
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" <pdw@sunbar.mc.duke.edu>
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" <andy@oe.fau.edu>
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" <C43TLM_at_US-SBDSO-CC07@ccintgw.dso.delcoelect.com>
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: <None>
        Subject: flash file system code available

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: <None>
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: <MSGATE.AMMGR.752151080094188FMSGATE@EMIS.HAC.COM>
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 <has@snmy.info.kobelco.co.jp>
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" <pdw@sunbar.mc.duke.edu> 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 <kevinb@spacecom.com>
Organization: SpaceCom Systems, Inc.
Message-ID: <Csy9rK.1Ku@spacecom.com>
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: <rls.774565195@frank>



	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: <rls.774565638@frank>
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" <csuka@heracc.desy.de>
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: <Ct7InM.JBG@tc.fluke.COM>

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(<expected VME IACK status/id byte>)"
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]" <mike@imatron.com>
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 <trest@visicom.com>
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 <mjeronis@astro.ge.com>
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 <trest@visicom.com>
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: <CtCnJ0.FHE@acsu.buffalo.edu>
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" <ddowning@well.sf.ca.us>
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: <CtHx9C.3yD@bisco.kodak.com>
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: <CtInLs.6Bo@metronet.com>

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" <pdw@sunbar.mc.duke.edu>
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: <cleaves%mickey.UUCP%denali.UUCP@cub.kscorp.com>
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: <CtJo3B.GzH@oasis.icl.co.uk>
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: <CtLC8p.Lr7@oasis.icl.co.uk>
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" <mwbrown@somnet.sandia.gov>
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: <jfinleyCtM5Cw.4G7@netcom.com>
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: <johnx.775342520@wrs.com>
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: <jfinleyCtMtIM.BAF@netcom.com>
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 <trest@visicom.com>
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" <mwbrown@somnet.sandia.gov> 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: <Ctnon6.n4w@murdoch.acc.Virginia.EDU>
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: <gerlachCtnnqz.Bt@netcom.com>

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: <CtnuCz.5Bx@Newbridge.COM>
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: <Ctnv87.Hsu@acsu.buffalo.edu>
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: <Ctp3rr.FIC@actcom.co.il>
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 <outputfile> -r <object modules...>"

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: <CtoI3I.Jv0@ceco.ceco.com>
References: <CtHx9C.3yD@bisco.kodak.com>

In article <CtHx9C.3yD@bisco.kodak.com> 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: <anj.158.013BCA4E@mail.ast.cam.ac.uk>
References: <davidh.621.0010C572@harlequin.co.uk>

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