From stan@rti.com  Fri Apr  1 00:15:44 1994
From: stan@rti.com (Stan Schneider)
Date: Fri Apr  1 00:15:57 PST 1994
Subject: Re: Slow backplane net in vxWorks 5.0.2b
>> Submitted-by LAJOIE@yalph2.physics.yale.edu  Thu Mar 31 14:31:03 1994

>> Does anyone have any suggestions for improving the backplane performance with
>> vxWorks 5.0.2b? 
>> 
If you have any way of causing interrupts, don't use polling.  It can make a
huge difference.

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================


From daemon@vxw.ee.lbl.gov  Sat Apr  2 04:00:22 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr  2 04:00:31 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr  2 04:00:13 PST 1994

        Subject: Re: VxWorks rshd?
        Subject: IDE/floppy Device Drivers for I960

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

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks rshd?
Date: 01 Apr 1994 20:51:36 GMT
From: pjg@parint.esl.com (Paul Gyugyi)
Organization: ESL, Inc.
Message-ID: <PJG.94Apr1125136@parint.esl.com>
References: <9403311855.AA13012@rti.com>

   >> We have targets running VxWorks that I would like to set up for
   >> manufacturing test, by loading a diagnostic RPC server that I wrote for
   >> the test application.  The way it works now, a test technician would
   >> have to run the commands needed to start the server (nfsMount(), cd(),
   >> ld(), rpcInit() and sp()) by logging in to the vxWorks shell.  There are
   ...
   >> server to handle the requests from the Sun.  Does anybody know a way to
   >> do this?

   There are three ways I know of...

4) Write a program on the SUN that calls fp=popen("rlogin target","w")
to open a connection to the target.  You can then call
fprintf(fp,"< script_file") just as if you  were in the shell.

The following code snippet will rlogin into a target and do an "i"
command.  The output of the i command will appear in stdout, so
you can pipe it to grep, etc.
One warning, sometimes characters get lost in transmission without
the fflush and sleep calls.  I'm not sure this is the most reliable
way of doing things, but what do you expect from a dozen lines of
code? :).

# UNIX/SUN4.1.3 program to get a list of tasks running on the target.
#include <stdio.h>
#include <stdlib.h>
main()
{
  FILE *fp;

  fp = popen("rlogin target","w");
  fprintf(fp,"i\n");
  fflush(fp);
  sleep(2);
  fprintf(fp,"logout\n");
  fflush(fp);
  pclose(fp);
}

- --
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
| Paul Gyugyi                      scrabble...click...snap...  |
| gyugyi@earthsea.stanford.edu     Paul_Gyugyi@smtp.esl.com    |
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=


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

Newsgroups: comp.os.vxworks
Subject: IDE/floppy Device Drivers for I960
Date: Fri, 1 Apr 1994 23:33:53 GMT
From: allender@caffeine.tucson.ibm.com (Mark Allender)
Organization: IBM System Storage Division -- Device Driver Development
Keywords: Device Driver, IDE, floppy, i960
Message-ID: <CnLtGH.Lqu@hawnews.watson.ibm.com>
Reply-To: allender@vnet.ibm.com
Sender: news@hawnews.watson.ibm.com (NNTP News Poster)

Has anyone written a device driver for an IDE controller and/or a
floppy driver under the i960 platform for VxWorks runtime?

I have heard that Wind River has an IDE/floppy driver for the 486
chip, but I don't know if there is one for the 960.  If the 486 is the
only IDE dd that is available from Wind River, has anyone looked into
porting that driver to the 960 platform?

Any comments or help would be appreciated.

- -- 
- -Mark Allender                            < insert standard disclaimer here > 
- -IBM -- SSD Tucson
- -Device Driver Development
- -allender@vnet.ibm.com

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

End of New-News digest
**********************


From daemon@vxw.ee.lbl.gov  Sun Apr  3 04:00:24 1994
From: daemon@vxw.ee.lbl.gov
Date: Sun Apr  3 04:00:33 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Apr  3 04:00:15 PDT 1994

        Subject: Debugging/Purifying a multi-tasking application
        Subject: booting vxWorks V5.1.1 from backplane network

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

Newsgroups: comp.os.vxworks
Subject: Debugging/Purifying a multi-tasking application
Date: 2 Apr 1994 13:34:19 GMT
From: chandy@hellix.inria.fr (Chandra Shekhar)
Organization: INRIA, Sophia-Antipolis (Fr)
Keywords: debugging, multi-tasking, memory
Message-ID: <2njs8r$f7r@sophia.inria.fr>


Hi folks,

I am working on a VxWorks application that involves several
interacting tasks. There is an error in my code somewhere
which causes a hard system crash, without telling me where
the fault occurred. Whenever I try to debug it, either
using VxGDB or the VxWorks shell debugger, no error occurs,
and the application runs smoothly. 

I guess when I am in the debug mode, the timing of the tasks
gets changed, so the crash-causing condition does not occur.

So how do I go about localising the fault? What I would like
to do is to "step" through the entire application, and find
out precisely what combination of circumstances causes the
crash. Unfortunately, I know no way of doing this. I can only
step through one task at a time, and that disrupts the normal
scheduling of tasks. 

One way of detecting memory usage errors (which are the probable
cause of system crashes) is to use the "Purify" program. However,
I don't know if I can use this with a VxWorks program.

Any ideas will be greatly appreciated.

Chandra Shekhar

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

Newsgroups: comp.os.vxworks
Subject: booting vxWorks V5.1.1 from backplane network
Date: Fri, 1 Apr 1994 01:57:34 GMT
From: rick@neopath.wa.com (Rick Bauer)
Organization: NeoPath Inc.
Keywords: backplane network
Message-ID: <1994Apr1.015734.20073@neopath.wa.com>
Reply-To: rick@neopath.wa.com
Sender: news@neopath.wa.com

     We are attempting to boot a multi-CPU system, 680x0 series, using a
back plane network with VxWorks, "version 5.1.1".  The Host CPU, procnum
0, is a Force FRC30 CPU board, and the slave CPU, procnum 1, is a
Motorola MVME162 CPU board.  The Host CPU has an ethernet connection to
our SUN4 network.  We are using the new smNetLib to boot the MVME162
from the backplane network using the HOST CPU as a gateway to our Sun4
development network.  We can boot the FRC30 CPU successfully, but we
have not been able to boot the MVME162.

     We have configured the Host CPU as a gateway on the Sun network to
our VmeBus backplane network.  The Host is configured to establish the
back plane network memory pool in its Dual Ported RAM.  The Host CPU
seems to initialize the backplane network correctly: we have examined
the memory locations recommended by WindRiver and the values agree with
the documentation.  To simplify our configuration, we have disabled all
MMU and CACHE support in the kernel for the FRC30 and the MVME162.  We
also configured the backplane network to use polling.

     We have configured the slave CPU to boot from the shared memory
device, "sm0".  From the slave CPU we are able to examine successfully
the backplane network memory locations on the Host CPU corresponding to
backplane anchor memory address that we established in the MVME162 boot
parameters.  When we boot the MVME162 after booting the FRC30, the
MVME162 attaches to the backplane network, "sm0", and then attaches the
network interface, "lo0".  The slave does seem to wait for the Host CPU
to initialize the backplane network with the values described by the
"5.1.1" documentation.  However, the boot sequence fails as soon as the
MVME162 attempts loading the VxWorks kernel from the network.  The error
message is:

     Error loading file: errno = 0xd
     Can't load boot file!!

     If we query the backplane network, smNetShow, after the MVME162
boot fails, the report inidicates that only CPU 0 is attached to sm0.
This seems to contradict the boot messages from the MVME162 indicating
that the CPU succesfully attached to both sm0 and lo0.

     The boot files for the FRC30 and the MVME162 are both on the same
sun4 host.  The sun4 host has been configured to allow both target CPUs
access to the workstation as remote hosts.  The FRC30 CPU also appears as
the gateway to our backplane network in the routing tables displayed by
our network server.

     We are stumped!!! Everthing seems configured correctly, yet the
MVME162 won't boot.  If anyone has experience with back plane networks
in a similar configuration, we would greatly appreciate any help you can
give us in solving this problem.

Thanks,

   Rick Bauer

   NeoPath
   1750 112th Ave NE
   Suite B101
   Bellevue WA 98004

   Phone: 206-455-5932
   Email: rick@neopath.wa.com



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

End of New-News digest
**********************


From pardo@sun-valley.stanford.edu  Sun Apr  3 21:22:23 1994
From: pardo@sun-valley.stanford.edu (Gerardo Pardo-Castellote)
Date: Sun Apr  3 21:22:31 PDT 1994
Subject: Re: Debugging/Purifying a multi-tasking application

>I am working on a VxWorks application that involves several
>interacting tasks. There is an error in my code somewhere
>which causes a hard system crash, without telling me where
>the fault occurred. Whenever I try to debug it, either
>using VxGDB or the VxWorks shell debugger, no error occurs,
>and the application runs smoothly. 

If your tasks are accesing shared data (as opposed to just
communicating with messages) you may be experiencing a race condition
where if one task happens to be scheduled while the other was modifying
the shared data structures in such a way that the "state" was
inconsistent (e.g. one task is adding something to a linked lists anw
while the list is temporarily 'inconsistent' the other task takes the
processor and tries to traverse the list.).

>One way of detecting memory usage errors (which are the probable
>cause of system crashes) is to use the "Purify" program. However,
>I don't know if I can use this with a VxWorks program.


If you may have a memory thrasing problem, It shouldn't be too hard to
trace it down with an appropriate tool. We use HeapCheck a tool that
comes with the RTILib package from Real-Time Innovations. It allows you
to determine if your heap is corrupted and trace down the task that
corrupts the memory. I've tracked down several memory thrasing problem
in our systems with it.

Other than that I would suggest trying to simplify your code to the
minimum # of tasks that still exhibit the problem or, suspend from the
shell one task at at time in the hope of isolating a single one whose
presence exhibits the problem and then look at the data it accesses and
protect it with locks. You could also try setting break-points at
diferent places from the shell (or vxgdb) but as you mentioned, this
may make the problem go away (which is why I think you have a race
condition).

> I can only step through one task at a time, and that disrupts the normal
> scheduling of tasks. 

That's not totally correct. you can start several concurent vxgdb
sessions and and step on both tasks simultaneously. It is quite painful
though.


Good luck,


	Gerardo.

-------------------------------------------------------------------
  Gerardo Pardo-Castellote       [ pardo@sun-valley.stanford.edu ]
  Aerospace Robotics Laboratory  [ (415) 723-3677 ]
----



From daemon@vxw.ee.lbl.gov  Mon Apr  4 04:00:18 1994
From: daemon@vxw.ee.lbl.gov
Date: Mon Apr  4 04:00:27 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Apr  4 04:00:10 PDT 1994

        Subject: fork/exec/wait in VxWorks

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

Newsgroups: comp.os.vxworks
Subject: fork/exec/wait in VxWorks
Date: Mon, 4 Apr 1994 03:00:14 GMT
From: ericp@netcom.com (Eric Peterson)
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Message-ID: <ericpCnpsCE.At7@netcom.com>

	Is there an easy (or at least straightforward) method for emulating the
	Unix fork/exec/wait tasking primitives in VxWorks?  I'm doing some
	porting of some Unix apps, and I would think that this pops up quite
	often (I searched the FAQ without luck).  Also, is the SIGCHLD signal
	really implemented to be generated upon (sub)-task exit, or is it just
	there to make things compile :-)?  The man pages aren't too clear on
	signal behavior.

Thanks in advance,
Eric

- -- 
Eric Peterson  WB6PYK AX.25: wb6pyk@n6mbr AMPRNET: [44.6.0.133] ericp@netcom.com

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

End of New-News digest
**********************


From prb@aplexus.jhuapl.edu  Mon Apr  4 05:14:13 1994
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Mon Apr  4 05:14:22 PDT 1994
Subject: Re: Debugging/Purifying a multi-tasking application

> Newsgroups: comp.os.vxworks
> Subject: Debugging/Purifying a multi-tasking application
> Date: 2 Apr 1994 13:34:19 GMT
> From: chandy@hellix.inria.fr (Chandra Shekhar)
> Organization: INRIA, Sophia-Antipolis (Fr)
> Keywords: debugging, multi-tasking, memory
> Message-ID: <2njs8r$f7r@sophia.inria.fr>
> 
> 
> Hi folks,
> 
> I am working on a VxWorks application that involves several
> interacting tasks. There is an error in my code somewhere
> which causes a hard system crash, without telling me where
> the fault occurred. Whenever I try to debug it, either
> using VxGDB or the VxWorks shell debugger, no error occurs,
> and the application runs smoothly. 
> 
> I guess when I am in the debug mode, the timing of the tasks
> gets changed, so the crash-causing condition does not occur.
> 
> So how do I go about localising the fault? What I would like
> to do is to "step" through the entire application, and find
> out precisely what combination of circumstances causes the
> crash. Unfortunately, I know no way of doing this. I can only
> step through one task at a time, and that disrupts the normal
> scheduling of tasks. 
> 
> One way of detecting memory usage errors (which are the probable
> cause of system crashes) is to use the "Purify" program. However,
> I don't know if I can use this with a VxWorks program.
> 
> Any ideas will be greatly appreciated.
> 
> Chandra Shekhar
> 


You might try getting a copy of WindView from vxWorks.
You could configure it in the instrumentation mode.
Then after a crash you can reset, upload the windview buffer
and look at a graphical representation of what was happening
prior to the crash. This assumes that you set windview up so that
the windview buffer doesn't get cleared on powerup.


	Paul Bade



From leonid@rst.co.il  Mon Apr  4 05:34:25 1994
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Mon Apr  4 05:34:41 PDT 1994
Subject: Re: fork/exec/wait in VxWorks
>ericp@netcom.com (Eric Peterson) writes:
>	Is there an easy (or at least straightforward) method for emulating the
>	Unix fork/exec/wait tasking primitives in VxWorks?  I'm doing some
>	porting of some Unix apps, and I would think that this pops up quite
>	often (I searched the FAQ without luck).  Also, is the SIGCHLD signal
>	really implemented to be generated upon (sub)-task exit, or is it just
>	there to make things compile :-)?  The man pages aren't too clear on
>	signal behavior.

Please excuse me saying so, but this question clearly shows that Eric
doesn't really understand what VxWorks is, (or what Unix is for that matter,
or both).

The whole idea behind fork() is to create an exact duplicate of the parent
process, but which is entirely independent of it, i.e. all the child's
writable memory is its own private copy. Nower days fork(0 doesn't really
copy the entire parent data and stack memory, but uses the Virtual Memory
mechanism to duplicate only those pages which are subsequently modified
by either the parent or child processes. This saves a lot of juice,
but the semantics are the same.

Here is an example, before calling fork() the parent had a global
variable xxGlobal with value of say 11. After fork returns, both the
parent and child view of this variable shows the same vaue, 11.
But should either child or parent change this variable at any time,
that change will not be reflected to the other, because although in those
two processes the address of xxGlobal is the same, these addresses refer to
distinct physical addresses in memory.

In order to be able to implement such semantics to the full extent, one
needs complete VIrtual Memory with On-Demand Paging mechanism
undeneath. VxWorks does not support such a Virtual Memory scheme,
and I doubt that any OS that does implement VM can be called
Real-Time in the true sense of the term. VM adds enourmous context
switching overhead, and increases inter-task resource sharing overhead
by an order of magnitude.

As to exec(), it can be simulated with moduleLib() (e.g. ld() ) functions,
but without fork() that won't be the same thing ever.

wait() and SIGCHLD have no meaning within VxWorks tasking scheme,
but they both can be easily implemented using taskDeleteHooks.
In VxWorks there are no parent-child relations between tasks,
but that can be added quite easily to emulate wait() and SIGCHILD 
semantics.

I hope this clarifies some points.
-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@rst.co.il
  [ Wind River Systems Distributor and Systems Integrator ]


From ma@tadpole.com  Mon Apr  4 06:55:36 1994
From: ma@tadpole.com (Mark Armitage)
Date: Mon Apr  4 06:55:44 PDT 1994
Subject: Re: Memory Problems:  Copyback vs Writethrough

> Enabling the MMU to use writethrough mode (or no caching at all)
> resulted in success.  Mind you, this is a single processor
> system.  Also, you MUST write something to every memory location
> in order to set the parity bits BEFORE you can do a read.  We
> used bzero() to do this before adding the memory to the system
> pool, and all worked ell for writethrough mode, but it still
> blew chunks in copyback mode.
> 
> Heurikon was extremely helpful in finding the problem; however,
> we're still not sure WHY it happens.

I think that your problem is because the 040 has to have a whole cache line
valid (or invalid).  So if the processor writes to part of the line, the
cache has to read the rest of the line from memory to get valid data for the
whole line!  I know it sounds a bit perverse, but I think that's the right
explanation.

Mark Armitage
Tadpole Technology
ma@tadpole.com


From daemon@vxw.ee.lbl.gov  Tue Apr  5 04:00:22 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Apr  5 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Apr  5 04:00:13 PDT 1994

        Subject: NVRAM Help!
        Subject: Re: Debugging/Purifying a multi-tasking application

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

Newsgroups: comp.os.vxworks
Subject: NVRAM Help!
Date: Mon, 4 Apr 1994 15:57:05 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: BNR Inc., RTP, NC
Message-ID: <CnqsB9.KyL@nrtpa22.bnr.ca>
Sender: billag@b4pphff (Bill Gutknecht)

	I have an application that needs to store some information in
	NVRAM (btw ... I'm using a MVME162-13 ...) and that address 
	space is around 0xfffc0000 ... but guess what ... that's where
	vxWorks boot info is ... 

	Anyone know where this ends and a safe place to start is?

	Thanks!

- ------------------------------------------------------------------------------
Bill Gutknecht                  "If I die, I will go before Crom and he will 
BNR/Northern Telecom             ask me 'What is the Riddle of Steel?'  If I do
Research Triangle Park, NC       not know it, he will cast me out of Valhalla
billag@bnr.ca                    and laugh at me ... "
- ------------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: Debugging/Purifying a multi-tasking application
Date: 4 Apr 1994 19:47:41 GMT
From: schuweil@forge.fnal.gov (greg schuweiler)
Organization: FERMILAB, Batavia, IL
Keywords: debugging, multi-tasking, memory
Message-ID: <2npqst$l9k@fnnews.fnal.gov>
References: <2njs8r$f7r@sophia.inria.fr>

In article <2njs8r$f7r@sophia.inria.fr>, chandy@hellix.inria.fr (Chandra Shekhar) writes:
|> 
|> Hi folks,
|> 
|> I am working on a VxWorks application that involves several
|> interacting tasks. There is an error in my code somewhere
|> which causes a hard system crash, without telling me where
|> the fault occurred. Whenever I try to debug it, either
|> using VxGDB or the VxWorks shell debugger, no error occurs,
|> and the application runs smoothly. 
|> 
|> I guess when I am in the debug mode, the timing of the tasks
|> gets changed, so the crash-causing condition does not occur.
|> 
|> So how do I go about localising the fault? What I would like
|> to do is to "step" through the entire application, and find
|> out precisely what combination of circumstances causes the
|> crash. Unfortunately, I know no way of doing this. I can only
|> step through one task at a time, and that disrupts the normal
|> scheduling of tasks. 
|> 
|> One way of detecting memory usage errors (which are the probable
|> cause of system crashes) is to use the "Purify" program. However,
|> I don't know if I can use this with a VxWorks program.
|> 
|> Any ideas will be greatly appreciated.
|> 
|> Chandra Shekhar

- -- 
You might try compiling the offending code with both -g and -O.  This will 
cause some surprizing results as the next statement to execute may not be 
the one you expect.  Some variables may no longer exist, and some statements
many possibly be outside of loops.  But it is very possible to debug 
optimized code.  You will just need to run through the code with vxgdb a 
few times.

Good luck

=========================================================================
Greg Schuweiler                     The standard disclaimer applies
schuweil@forge.fnal.gov             to all I may have said, may say,
(708) 840-2665                      and/or may do.  It does not reflect,
                                    the feelings of my employer.  Heck,
                                    if it did, we would lose our funding. 

            Like a rock, I stand against the wind
=========================================================================


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

End of New-News digest
**********************


From kruk@lannet.com  Tue Apr  5 04:30:09 1994
From: kruk@lannet.com (Meir Kruk)
Date: Tue Apr  5 04:30:18 PDT 1994
Subject: WindC++ version of VxGDB on i960 does not work
Hello,

I have a question to you vxWorks/C++ users out there. Has anyone worked 
with the VxGDB on a C++ application?

My problem is as follows:

I have installed an evaluation copy of WindC++ 1.0 beta on Sun4 station
running VxWorks 5.1.1 , for i960CA custom target.
I have started VxGDB, attached to the target, attached to tasks, etc.
VxGDB recognizes the C++ language , but I could not make it recognize
line numbers of C++ source, nor could I make VxGDB display the C++
source in any way.

DEMONSTRATION PROCEDURE :

Compile/link a C++ application with -g, by using the following makefile:
   INC = -I$(VW)/h
   ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS
   all:  myProg.C
      CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C
      gnm960 -pv myProg.o | munch960 > __ctordtor.c
      gcc960 -g $(ARCH) -c __ctordtor.c
      gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o

Start VxGDB :
   vxgdb -t 960++ 

Attach target:
   target vxworks target_ip_addr vxWorks.st

Load the C++ application into the target from VxGDB and issue the
command "list" with either file name or function name.

The debugger reports:
   "No line number information"

Does this sound familiar to anybody?


Any help or suggestions would be appreciated.

Thanks,

Meir.

--------------------------------------------------------------------
Meir Kruk                             |      Email:  kruk@lannet.com
LANNET Data Communication Ltd.        |      Tel:      972-3-6458398
Atidim Technology Park,Bldg. 3        |      Fax:      972-3-6487146
Tel Aviv 61131, Israel                |
--------------------------------------------------------------------


From tweadon@sadira.gb.nrao.edu  Tue Apr  5 06:00:49 1994
From: tweadon@sadira.gb.nrao.edu (TIM WEADON)
Date: Tue Apr  5 06:00:57 PDT 1994
Subject: Re: WindC++ version of VxGDB on i960 does not work

I posted something on this a few weeks ago, it was about the shell but
sounds like it applies here also. 

When using C++ you either choose "INCLUDE _CPLUS" or "INCLUDE_CPLUS_MIN".
inside your configAll.h file. In VW5.1.1 WRS made a BOO-BOO! They force
you to include only one or the other. If you choose both then you get
a compile error in usrConfig.c. But in src/config/usrExtra.c they make
a compile time check to see if they both are defined. If so then they
set sysCplusEnable = TRUE; sysCplusEnable must = TRUE for the shell,
and probably the debugger, to try to interpret C++ commands and display
C++ lines and variables. 

First, set sysCplusEnable = TRUE from the shell. If this fixes your problem
then you know that it is your only problem. If it doesn't then you know it
is only one of your problems. If you are going to use C++ you must modify
usrExtra.c and change the line which checks
(INCLUDE_CPLUS) && (INCLUDE_CPLUS_MIN) is true to 
(INCLUDE_CPLUS) || (INCLUDE_CPLUS_MIN).

Tim Weadon
National Radio Astronomy Observatory
Green Bank, WV. 24944
(304) 456-2120


From daemon@vxw.ee.lbl.gov  Wed Apr  6 04:00:27 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr  6 04:00:38 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr  6 04:00:16 PDT 1994

        Subject: Setting the MVME167 clock chip?
        Subject: Fixed: memPartFree error with copyback caching enabled (167)
        Subject: BOOTP server on VxWorks target
        Subject: Re: Memory Problems:  Copyback vs Writethrough
        Subject: unsupported software for DT1492
        Subject: How to install a digital to analog board for a sun1e target?
        Subject: References
        Subject: Naming System Objects

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

Newsgroups: comp.os.vxworks
Subject: Setting the MVME167 clock chip?
Date: Tue, 5 Apr 1994 15:30:17 GMT
From: curry@tc.fluke.COM (John Curry)
Organization: Fluke Corporation, Everett, WA
Message-ID: <CnsLqs.D5u@tc.fluke.COM>

Before getting too deep into the documentation, does anyone out there
have any information on setting and retrieving the time of day from the 
MVME167 clock chip? What I looking for is some way to maintain the 
time between VxWorks boots without having to access a host computer.
 
Thanks for any help.
  
John Curry


- -- 
- ----------------------------------------------------------------------------
 John Curry                                       Fluke Corporation
 curry@tc.fluke.com                               6920 Seaway Blvd  m/s 178D
 206-356-5708                                     Everett, Wa. 98206 
- ----------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Fixed: memPartFree error with copyback caching enabled (167)
Date: Tue, 5 Apr 1994 20:23:51 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Keywords: VxWorks bug
Message-ID: <georg.765577431@sgl.ists.ca>
Sender: news@newshub.ists.ca

This is a followup to an earlier message describing a nasty memPartFree bug
under VxWorks 5.1.1 on the MVME167 with the CPU data cache enabled in
copyback mode. We have now found a workaround for the bug, which appears
to be inside VxWorks. No exact cause yet, we have opened a TSR with Wind
River and they are looking into it.

The situation which triggers the bug is a long series of reads from a dosFs
file on a SCSI disk. The data is passed through rpc stuff by our application
(an NFS server) and then returned via sockets to the external client.
Occasionally new dosFs files are opened and read, and there is lots of
unrelated malloc() activity such as performed by rpc/network routines.
The 68040 data cache is enabled with the 167's DRAM set for copyback caching.
The effect of the bug is corruption of the system memory pool leading to
memPartFree errors and errors in the file data read from disk.

It was discovered fairly early that changing the entire system memory pool's
cache attributes to writethrough made the problem disappear. Therefore it
is due to a cache inconsistency. A subsequent exhaustive search was made for
the particular malloc() buffers which need to be made writethrough by 
replacing specific pairs of malloc()/free() calls with alternate calls
named valloc3() and vfree3(). The alternate calls change the cache attributes 
of the memory obtained by malloc() to writethrough, and then restore the
attributes to copyback when freeing. 

We found that none of our application malloc() calls were causing the problem.
This was as suspected, since cache inconsistency is most likely related to
DMA, which VxWorks does internally. We finally found that the internal buffer
used by VxWorks for dosFs read() calls was the problem. Data is copied from
the VxWorks internal buffer to the user's buffer during read() calls using
bcopy(). The VxWorks internal buffer was found to have regular cache 
attributes (copyback). When patched to use the alternate valloc3()/vfree3()
calls, the memory problems disappeared. Information on the exact patching
process and the VxWorks malloc()/free() call locations is available to anyone
who wants to know.

The memory errors seemed to happen when
some other task independently performing malloc()/free() happened to
re-use the same memory area as previously used for the internal I/O buffer. 
Therefore an unrelated task generates the actual error message on a free() call.
What we suspect is happening is that information from the data cache is
being written out after the original I/O buffer has been freed.
Our system is a 33 MHz MVME167 with 32 Mbytes of memory (16 MB of which are
in a separate memory pool and not available to VxWorks), a Seagate Barracuda
2.1 GB SCSI disk, and no other processors. We do have some memory and custom
cards sitting on VME but the memory is not used and the custom cards are not
believed to be a factor. Some mention was made of a VMEchip2 TAS problem
affecting the data cache, but we don't use TAS over VME.

I'll post a quick note if we find out the actual cause of this bug...

Georg.
- -- 
Georg Feil
Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

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

Newsgroups: comp.os.vxworks
Subject: BOOTP server on VxWorks target
Date: Mon, 4 Apr 1994 15:26:17 GMT
From: pnarayan@hns.com (Padmini Narayan)
Organization: Hughes Network Systems Inc.
Keywords: VxWorks, BOOTP
Message-ID: <1994Apr4.152617.15454@hns.com>
Sender: news@hns.com (USENET news system)


At  HNS we might require VxWorks targets to act as BOOTP servers off
of which other VxWorks targets can boot. As of now, only thr BOOTP client
features have been implemented in VxWorks. Does any one out there know
of a BOOTP server implementation on VxWorks targets? I would really
like to know if this is possible at all.

Any thoughts/information on this will be much appreciated.

(Please e-mail responses to pnarayan@hns.com)

Thanks in advance
- -- Padmini

^^^^^^^^^^^^^^^^^^^^^^^
Padmini Narayan
pnarayan@hns.com
Embedded Software Group
Hughes Network Systems

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

Newsgroups: comp.os.vxworks
Subject: Re: Memory Problems:  Copyback vs Writethrough
Date: Tue, 5 Apr 1994 22:49:31 GMT
From: jfinley@netcom.com (John Finley)
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Message-ID: <jfinleyCnt62J.8nE@netcom.com>
References: <199404010251.VAA19381@piglet.INS.CWRU.Edu>

Erik C. Orange (ah442@cleveland.freenet.edu) wrote:
: We have had similar experiences with the copyback vs writethrough
: memory problem.

: Our situation:  Our CPU is a Heurikon HKV4F 68040.  We purchased
: a Micro Memory 8MB dynamic RAM board.  After properly configuring
: VxWorks 5.1 to access address space in extended VME space, we
: added the board to our system and tried to utilize it as VxWorks
: system pool.  We found that we could NOT enable copyback mode
: on the MMU; any attempt to access the memory caused a parity
: error on the memory board (and a VxWorks bus error).

: Enabling the MMU to use writethrough mode (or no caching at all)
: resulted in success.  Mind you, this is a single processor
: system.  Also, you MUST write something to every memory location
: in order to set the parity bits BEFORE you can do a read.  We
: used bzero() to do this before adding the memory to the system
: pool, and all worked ell for writethrough mode, but it still
: blew chunks in copyback mode.

: Heurikon was extremely helpful in finding the problem; however,
: we're still not sure WHY it happens.

When you write to a memory location set in copyback mode and there's
a cache miss, the MMU first reads the whole cache line into the
cache, then updates the location you're writing to. That's where
the parity error is coming from. You ought to be able to clear the
board uncached, then turn on copyback.

- -John
jfinley@netcom.com

: Erik

: --
: Erik C. Orange                        FRD Industrial Automation
: Systems Engineer                      Avery-Dennison Corporation
: ah442@cleveland.Freenet.Edu           Concord, OH

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

Newsgroups: comp.os.vxworks
Subject: unsupported software for DT1492
Date: 5 Apr 94 15:51:21 PDT
From: meier@rogue.llnl.gov
Organization: Lawrence Livermore National Laboratory, NCD
Message-ID: <1994Apr5.155121.1@rogue.llnl.gov>


I am relatively new to VxWorks and am trying to put together a little data
acquisition system.  I have a Data Translations DT1492 multi-function board and
would like to use the a/d's.  I am aware that there is supposed to be some
software in the "unsupported" directory, but I can't manage to find it.  Is
there an ftp site I could download some code, and what files do I need?.  I am
using VxWorks ver 5.0.1.   Any other experience you can share would be helful,
thanks.


- -- 
                           Timothy A. Meier
                           meier3@llnl.gov
                Lawrence Livermore National Laboratory
                       University of California

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

Newsgroups: comp.os.vxworks
Subject: How to install a digital to analog board for a sun1e target?
Date: 5 Apr 1994 23:19:06 GMT
From: letchu@zoe.as.utexas.edu (Lakshmanan Narayanan)
Organization: University of Texas, McDonald Observatory
Message-ID: <2nsrla$lkm@geraldo.cc.utexas.edu>

I am using a sun1e target and my host is Sun4. Presently I'm trying to install
a digital to analog board (DVME-622) which is factory configured for A24/D16 address space. The base address on this board is $fc0100. I tried to configure this board for the VME A24/D16 address space defined in the memDesc.c file, but am having difficulty in accessing the registers on the board. Whenever I tried doing a memory dump on the registers on this board I get a "Data Access Exception" error from vxworks. The size of the board is 256 bytes.

If anyone has experienced a similar problem or have any suggestions regarding 
this problem, your help would be much appreciated.

Thanks.

Lakshmanan Narayanan
(letchu@seuss.cc.utexas.edu)
University of Texas at Austin
Department of Astronomy

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

Newsgroups: comp.os.vxworks
Subject: References
Date: Mon, 4 Apr 1994 16:44:52 GMT
From: dowlati@claude.ma30.bull.com (Saadat Dowlati)
Organization: Bull HN Information Systems Inc.
Message-ID: <1994Apr4.164452.23292@claude.ma30.bull.com>
Sender: news@claude.ma30.bull.com (Network News)

I would appreciate any pointers to papers/books on VxWorks.
- --
Thanks,


- -- 
Saadat Dowlati		   Affiliation:	Zenith Data Systems, Groupe Bull
Voice:	(508) 294-3426			Technology Park, MA02-400S
Fax:	(508) 294-3054			Billerica, Massachusetts 01821-4199
E-mail:	S.Dowlati@bull.com     

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

Newsgroups: comp.os.vxworks
Subject: Naming System Objects
Date: 5 Apr 1994 23:33:07 -0400
From: alexm@shakespeare.gsfc.nasa.gov (Alex Measday)
Organization: NASA Goddard Space Flight Center
Message-ID: <2ntahj$2hm@shakespeare.gsfc.nasa.gov>

In a number of library functions I have written, I make use of "named"
system objects (e.g., semaphores): the object's name is stored in the
system symbol table with its value being the object's ID (or a suitable
handle).  Different tasks can then access the object by name.

When an object is first referenced by a task, the library function must
determine if the object already exists (i.e., is in the symbol table).
If so, the function simply returns the handle retrieved from the symbol
table.  If the object doesn't exist yet, the function must create the
object and enter its name-handle mapping in the symbol table.

Because creating the object and entering its name in the symbol table
are two separate operations, there is a problem with multiple tasks
trying to simultaneously create an object. I describe my single-CPU
approach below, but I'm wondering

        (1) if there are better ways of doing this, and
        (2) how do I handle it in a multi-processing configuration
            using VxMP?

Using the example of a named semaphore, my code would do the following
(in PDL):

        CALL taskLock() to lock the processor.
        Lookup the semaphore's name in the system symbol table.
        IF found THEN
            The name's value is the semaphore ID.
        ELSE
            Create a new semaphore.
            Store its name and ID in the system symbol table.
        ENDIF
        CALL taskUnlock() to unlock the processor.

My real code is somewhat more complicated, but follows the basic outline.
For instance, my implementation of event flags allocates a memory structure
which contains two semaphore IDs (an update semaphore and a wait-for-change
semaphore) and a reference counter (so I know when to finally delete an
event flag cluster).

The task locking approach works on a single CPU.  The code is conditionally
compiled so that, under VxMP (which we will be getting), the shared memory
versions of the memory allocation, semaphore creation, and symbol table
functions are used.  However, locking a single CPU won't work in a
multi-CPU setup.  Any ideas?

                            Thanks
                                Alex Measday
                                Integral Systems, Inc.
                                alexm@milton.gsfc.nasa.gov
- -- 
                                Alex Measday
                                Integral Systems, Inc.
                                alexm@milton.gsfc.nasa.gov

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

End of New-News digest
**********************


From rmk@ssd.ray.com  Wed Apr  6 05:46:55 1994
From: Kulakowski <rmk@ssd.ray.com>
Date: Wed Apr  6 05:47:02 PDT 1994
Subject: D/A Needed
HELP!

I'm looking for a D/A module, hopefully with vxWorks support, with the
following characteristics:

* At least 260kHz sample clock
* Preferably at least 8 channels per module (we need 24 total)
* Either DMA or fifo per channel (This is the hardest requirement!)
* 12 bit samples or better.
* Analog output going right into a big amp so drive less important

Any pointers to just vendors are appreciated but if you've used them and
can give experience data, better yet.

Thanks in advance!
Rich

  ----------------------------------------------------------------------
  *  Rich Kulakowski            *  Raytheon ED, Portsmouth Facility    *
  *                             *  1847 West Main Road,  Mail Stop 177 *
  *  rmk@ssd.ray.com            *  Portsmouth, RI  02871-1087          *
  *                             *  (401) 842-4210                      *
  ----------------------------------------------------------------------



From LAHTINEN@tsl.uu.se  Wed Apr  6 07:39:43 1994
From: LAHTINEN@tsl.uu.se
Date: Wed Apr  6 07:39:55 PDT 1994
Subject: Thanks


I want to thank Victor Potter, John Carroll and Michael Hanson 
for their advice about how to configure VxWorks boot PROMs on 
an MVME167. Now we are booting VxWorks from the second bank of 
sockets and having 167-Bug PROMs on the original sockets. 

	Best regards,
	               Mikko Lahtinen
	               The Svedberg Laboratory
	               Uppsala
	               Sweden


From howard@sidney.nosc.mil  Wed Apr  6 07:46:55 1994
From: howard@sidney.nosc.mil (Mike Howard)
Date: Wed Apr  6 07:47:05 PDT 1994
Subject: FDDI Driver
The project I am working on uses a FDDI ring for broadcast data transmission from the sensor terminus to several processing sub-systems.  I currently have this up and working with a Force 30 CPU (68030), an Interphase 4211 FDDI board, vxWorks 5.0.2b and the AP Labs FDDI driver ver 1.4.  However, we are switching over to vxWorks 5.1.1 and a Synergy SV400 CPU (68040).  I have source for the FDDI driver and have hacked at it to get it to compile for 5.1.1 but still am not able to get it working properly (hangs in the ifAddrSet call).  Before I expend more time time on this, does anyone know if there is an updated driver for the 4211 FDDI and vxWorks 5.1.X already in existance??
 								Thanks in advance
               __  __  __                     
             /  \/  \/  \  o    /_          /^\    /
                /   /   /      /__)  __       /   /
               /   /   /  /   / \   /__)     /---/
              /   /   /__/\__/  /___\___    /   / o

------------------------------------------------------------------
                                |
 ^   ^                          | G. "Mike" Howard
(o) (o)   You want it WHEN????  | NRad Code 714
 - ^ -                          | Rm 234, Bldg 106, Bayside
 \ O /                          | (619) 553-1524
   -                            | e-mail howard@sidney.nosc.mil
                                |
------------------------------------------------------------------
 


From prb@aplexus.jhuapl.edu  Wed Apr  6 08:30:31 1994
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Wed Apr  6 08:30:40 PDT 1994
Subject: Re: FDDI Driver

Mike Howard writes:

> 
> The project I am working on uses a FDDI ring for broadcast data transmission from the sensor terminus to several processing sub-systems.  I currently have this up and working with a Force 30 CPU (68030), an Interphase 4211 FDDI board, vxWorks 5.0.2b and the AP Labs FDDI driver ver 1.4.  However, we are switching over to vxWorks 5.1.1 and a Synergy SV400 CPU (68040).  I have source for the FDDI driver and have hacked at it to get it to compile for 5.1.1 but still am not able to get it working properly (hangs in the ifAddrSet call).  Before I expend more time time on this, does anyone know if there is an updated driver for the 4211 FDDI and vxWorks 5.1.X already in existance??
> 


I will be looking for an FDDI board in the near future.
One requirement is that there is a driver available
that is compatible with 5.1.1.   So, any information about
the interphase board or other vendor's boards would be appreciated.


	Thanks,



+====================================================================+
|       __     ____         __     __                                |
|      /\ \   /  \ \       /\_\__ /\ \      Johns Hopkins University |
|     /  \_\ | /\ \ \     / / /\_\\ \ \     Applied Physics Lab.     |
|    / /\ | |\ \/  \ \   / / / / / \ \ \                             |
|   /  \/ |_| \  /\ \_\ / / / / /   \ \ \   Paul R. Bade             |
|  / /\__/_/   \ \ \/_// / / / /    / / /   (301)-953-6000 x8681     |
| / / /         \ \_\  \ \/ / /    / / /    prb@aplexus.jhuapl.edu   |
| \/_/           \/_/   \__/_/     \/_/                              |
|               __     ____         __       __                      |
|              /\ \   /  \ \       /\ \     /\ \                     |
|             /  \_\ | /\ \ \     /  \_\   /  \ \                    |
|            / /\ | |\ \/  \ \   / /\ |_| / /\ \ \                   |
|           /  \/ |_| \  /\ \_\ / / / | | \/ /  \ \                  |
|          / /\  / /   \ \ \/_// / / / /    / /\ \_\                 |
|          \ \/ / /     \ \_\  \ \/ / /     \/ / / /                 |
|           \__/_/       \/_/   \__/_/        /_/_/                  |
|                                                                    |
+====================================================================+



From dwampl@atl.com  Wed Apr  6 09:45:58 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Wed Apr  6 09:46:11 PDT 1994
Subject: Re: WindC++ version of VxGDB on i960 does not work
I have not encountered this problem with WindC++ for the 68K.  My naive first
guess would be that the "coff" format has something to do with it.

A few other tidbits to keep in mind:  Make sure that you specify the directory
where the sources are located (with the "directory name") command.  Also, I
recall circumstances where there was confusion between the real source file 
name and the intermediate C file generated by CenterLine's CC.  The latter is 
usually in a tmp directory and has a name w/ the process ID embedded in it.  
However, normally, the correct C++ file is referenced.  (It's been a while since
this happened; it may have even occurred will trying to use a generic gdb built
from the "net", rather than vxgdb....)

Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|        "We begin bombing in five minutes...."  7:^]             |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+


From @sequent.kiae.su,@avdsys.uucp:avd@avdsys.msk.su  Wed Apr  6 12:00:49 1994
From: Alexey V. Demyanov <avd@avdsys.msk.su>
Date: Wed Apr  6 12:00:58 PDT 1994
Subject: Hello from Russia
Hi

I'm VxWorks distributor in Russia.
I'm going to build VxWorks Users Group in Russia.
Could somebody tell me about how this UG should be arranged and
how it is functioning.

Thanks in advance
Alexey


From mea@mclean.sparta.com  Wed Apr  6 13:01:59 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Wed Apr  6 13:02:08 PDT 1994
Subject: Re: FDDI Driver
Greetings!

> Submitted-by: howard@sidney.nosc.mil (Mike Howard)
>  
> The project I am working on uses a FDDI ring for broadcast data
>transmission from the sensor terminus to several processing
>sub-systems.  I currently have this up and working with a Force 30 CPU
>(68030), an Interphase 4211 FDDI board, vxWorks 5.0.2b and the AP Labs
>FDDI driver ver 1.4.  However, we are switching over to vxWorks 5.1.1
>and a Synergy SV400 CPU (68040).  I have source for the FDDI driver and
>have hacked at it to get it to compile for 5.1.1 but still am not able
>to get it working properly (hangs in the ifAddrSet call).  Before I
>expend more time time on this, does anyone know if there is an updated
>driver for the 4211 FDDI and vxWorks 5.1.X already in existance??  
>

SPARTA has a driver for the 4211/5211 that works with both 5.0.X and 
5.1.X.  SPARC, 68K and i960 processor flavors are supported.  For the
5211, BLT, MBLT and VME64 modes of transfer are supported.  There is
a charge for the driver but it's CHEAP (we opted for the turbo Pascal
pricing model).  We're sustaining ~3 MBytes/sec blaster/blastee transfers 
using a Heurikon HKV4D (33 MHz 68040) and the 5211.  We also take 
Mastercard and Visa :-).

Regards and sorry for the sales pitch,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      
 


From daemon@vxw.ee.lbl.gov  Thu Apr  7 04:00:27 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr  7 04:00:41 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr  7 04:00:17 PDT 1994

        Subject: Puzzling Priorities 
        Subject: EPICS drivers for CAN
        Subject: vxWorks and mice?
        Subject: VxWorks rshd?
        Subject: Re: Setting the MVME167 clock chip?
        Subject: A token based protocol for VxWorks ???
        Subject: Invisible Memory!

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

Newsgroups: comp.os.vxworks
Subject: Puzzling Priorities 
Date: Wed, 6 Apr 1994 14:04:36 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: BNR Inc., RTP, NC
Message-ID: <CnuCFw.ICs@nrtpa22.bnr.ca>
References:  <1994Apr4.164452.23292@claude.ma30.bull.com>
Sender: billag@b4pphff (Bill Gutknecht)

	I've been working two projects, but they seem to have the
	same problem.

	1)  a low level TCP/IP server app.
	2)  a RPC based server app.

	In case (1) I must run the task at a priority of 2 to get any
	response to it.  In case (2), I must kill the portmapper and run
	at priority 2 (its default is 100).

	This seems odd to me since all of the other tasks are just 
	hanging out and doing nothing.  I'd think that higher priorities
	should work.  For the most part, I've been using vxWorks as 
	a weird/wonderful type of Unix ... but now, I think, I am bitten
	by the RTOS aspects.

	Any insights as to why I must run these tasks at such a high 
	priority?  I use pri=2 because that's what telnetd and rlogind
	are (and are similar in function) I'd think that if WR sets the
	portmapper to pri=100, it should work there ... 

	BTW ... In these cases, the applications are running by themselves.
	(ie. nothing else loaded cept the OS).  vvWorks 5.1.1, MVME162-13.

	Thanx.

- ------------------------------------------------------------------------------
Bill Gutknecht                  "If I die, I will go before Crom and he will 
BNR/Northern Telecom             ask me 'What is the Riddle of Steel?'  If I do
Research Triangle Park, NC       not know it, he will cast me out of Valhalla
billag@bnr.ca                    and laugh at me ... "
- ------------------------------------------------------------------------------

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

Newsgroups: comp.realtime,comp.os.vxworks,comp.arch.bus.vmebus
Subject: EPICS drivers for CAN
Date: Wed, 6 Apr 1994 15:42:21 GMT
From: mpuig@iac.es (Martm Pi )
Organization: Instituto de Astrofmsica de Canarias
Keywords: EPICS,CAN,VxWorks,VME
Message-ID: <mpuig.6.2DA2D85C@iac.es>

Hi all,

At IAC we are experimenting using CANbus systems in telescope
control applications. Currently we have a PC-CAN node in the
system but we are looking for CAN/VME cards with EPICS drivers
(running with VxWorks).

Somebody know if exist EPICS drivers for CAN, RS-232 and TCP/IP ?

Thanks in advance,

Martm

- --------------------------------------------------------------------------
MARTI PI i PUIG,  Software Engineering Department
Instituto de Astrofisica de Canarias (IAC)
c/ Via Lactea s/n                                  Phone: +34-22-605-355
38200 La Laguna (Tenerife)                           Fax: +34-22-605-210 
Canary Islands. SPAIN                              Email: mpuig@iac.es 

                                            

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

Newsgroups: comp.os.vxworks
Subject: vxWorks and mice?
Date: 6 Apr 1994 18:10:58 GMT
From: cro@pathos.caltech.edu (John Cromer)
Organization: California Institute of Technology, Pasadena
Keywords: mouse
Message-ID: <2nutvi$c2b@gap.cco.caltech.edu>

Greetings vxworkers.

Does anyone know of any mouse-support functions available for VxWorks --
either for a serial mouse (Motorola or Heurikon CPU serial ports) or
special boards with custom mouse input?

Email or net pointers appreciated.

John 

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

Newsgroups: comp.os.vxworks
Subject: VxWorks rshd?
Date: 6 Apr 1994 18:45:51 GMT
From: mmccrore@tpd.dsccc.com (Martin McCrorey)
Organization: DSC Communications Corporation, Plano, Texas USA
Message-ID: <2nv00v$6fq@tpd.dsccc.com>

Thanks for all the suggestions.  The popen() idea looked like the best
bet, since I was trying to avoid adding to or changing the production
software load (e.g., adding vxrshd), so I started with that idea.  I
ended up opening a pair of pipes, forking, duping the pipes to the stdin
and stdout of the child and using execl() to rlogin.  Then I wrote a
state machine in the parent process to interact with the vxWorks target
(via the pipes) and set up my RPC server.  Works great, and I got to
learn some basic Unix IPC stuff that I needed to know anyway.

- --Martin McCrorey

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

Newsgroups: comp.os.vxworks
Subject: Re: Setting the MVME167 clock chip?
Date: Wed, 6 Apr 1994 22:59:05 GMT
From: winans@xray.aps.anl.gov (John R. Winans)
Organization: Argonne National Laboratory, Chicago Illinois
Message-ID: <Cnv16J.MCL@mcs.anl.gov>
References: <CnsLqs.D5u@tc.fluke.COM>
Sender: usenet@mcs.anl.gov

In article <CnsLqs.D5u@tc.fluke.COM> curry@tc.fluke.COM (John Curry) writes:
>Before getting too deep into the documentation, does anyone out there
>have any information on setting and retrieving the time of day from the 
>MVME167 clock chip? What I looking for is some way to maintain the 
>time between VxWorks boots without having to access a host computer.

It is well shown on page 1-32 of the mv167 'grey book' named "Single Board 
Computers Programmer's Reference Guide."

FFFC1FF0  8080 8080 8080 803D  0014 5517 0406 0494  .......=..U.....
			       | |  | |  | |  | |
	CONTROL ---------------| |  | |  | |  | |
	SECONDS -----------------+  | |  | |  | |
	MINUTES --------------------+ |  | |  | |
	HOURS   ----------------------+  | |  | |
	DAY     -------------------------+ |  | |
	DATE    ---------------------------+  | |
	MONTH   ------------------------------+ |
	YEAR    --------------------------------+

The control bits are discussed there as well, but all you wanna do is read
it, here is all you probably need.

- --John
- -- 
! John Winans                     Advanced Photon Source  (Controls)    !
! winans@phebos.aps.anl.gov       Argonne National Laboratory, Illinois !
!                                                                       !
!"The large print giveth, and the small print taketh away." - Tom Waits !

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

Newsgroups: comp.os.vxworks
Subject: A token based protocol for VxWorks ???
Date: 7 Apr 1994 01:42:38 GMT
From: segrest@bobseg.enet.dec.com ()
Organization: Me and only Me
Message-ID: <2nvoee$hf7@sousa.ako.dec.com>
Reply-To: segrest@bobseg.enet.dec.com ()


Greetings,

Does anyone know of a token oriented network interface that has been developed
for VxWorks?  

A client of mine needs to use a unique hardware interface and is
looking for a way to interface the IP+ICMP layer in the VxWorks stack to his
hardware.  The hardware attaches to a bus type architecture that does not 
have any form of collision detection.  As a result we are looking for a token
oriented solution.  My hope is that someone else might have implemented a token
oriented interface and would be willing to make the source code available for
a reasonable fee.

- -- 
Bob Segrest

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

Newsgroups: comp.os.vxworks
Subject: Invisible Memory!
Date: Thu, 7 Apr 1994 10:04:21 GMT
From: ebg@hoshi.hip.atr.co.jp (Ed Gamble)
Organization: ATR Human Information Processing Research Labs., Japan
Message-ID: <EBG.94Apr7100422@hoshi.hip.atr.co.jp>
Sender: news@hip.atr.co.jp (USENET News System)


Well not quite invisible...  but inaccessible.  

We've got a problem with vxWorks 5.1 interboard memory access:
given a 16Mb MVME 167 (board 'A') and a 16Mb MVME 167 (board 'B'), 
board A can only access the lower 8 Mb of board B and visa-versa.
Both boards boot successfully over the shared memory network 
from an 8 Mb MVME 147 in slot 0. 

I'm sure this is really simple...  It is only the upper 8 Meg that can't be
accessed (with vxMemProbe() or d() for example) from another board.

Below is our sysProcNumSet().  VMECHIP2_VSAR1, VMECHIP2_VSATR1 and
VMECHIP2_VSAMSR seem to be set correctly?  We have also modified (and
examined) sysPhysMemDesc; the non-local addresses and sizes seem correct
and are consistent/identical accross boards.  We have not modified
sysHwInit() or sysHwInit2().  Presumably unrelated - we have also modified
sysBusToLocalAdrs() and sysLocalToBusAdrs() to do things more reasonably
with a boards' own VME address.  The config.h variable LOCAL_MEM_BUS_A24 is
ignored (since 16Meg is not in A24 space) and has a value unrelated to
16Meg. 

Our sysHwConfigShow() routine illustrates our configuration.

We've presented this problem to support@wrs.com with no results; presumably
the problem it is either too trivial or too difficult?

void sysProcNumSet (int procNum)
{
    int memsize;
    sysProcNum = procNum;
    memsize = (4 << (*MEMC_MCR & 0x07));  /* Value agrees with below */
    {
      /* Megabytes */
      int its_mem_base = ITS_MEMORY_ADRS;
      int its_mem_top  = ITS_MEMORY_ADRS + ITS_MEMORY_SIZE - 1;
      /* 64k Blocks */
      int its_mem_base_block = 0x0000ffff & (its_mem_base >> 16);
      int its_mem_top_block  = 0x0000ffff & (its_mem_top  >> 16);

      *VMECHIP2_VSAR1  = (its_mem_top_block << 16) | its_mem_base_block;
      *VMECHIP2_VSATR1 =  its_mem_base_block;
    }
    *VMECHIP2_VSAMSR |= (VSAMSR1_SNP_WSD |
			 VSAMSR1_WP	|
			 VSAMSR1_SUP	|
			 VSAMSR1_USR	|
			 VSAMSR1_A32	|
			 VSAMSR1_D64	|
			 VSAMSR1_BLK	|
			 VSAMSR1_PGM	|
			 VSAMSR1_DAT);	/* all but A24 */

    if (sysProcNum < 15)
	{
	memsize = *VMECHIP2_LBTVCR;
	memsize &= ~(0xfff00000);	/* clear bits */
        *VMECHIP2_LBTVCR = (memsize | (sysProcNum << 20) |
			    (GCSR_GROUP_ADDR << 24));
	}
}


AAAA > sysHwConfigShow ()
Processor 1 Hardware Configuration
  Model                     : Motorola MVME167
  CPU Speed (MHz)           : 33
  Local Memory Address      : 0x00000000  /* 0 always        */
        Memory Size         : 0x01000000  /* sysMemTop()     */
  VME   Memory Start        : 0x02800000  /* ITS_MEMORY_ADRS */
  VME   Memory End (+ 1)    : 0x03800000  /* ITS_MEMORY_SIZE */

  Hardware Registers
  VME Chip2 VSAR1           : 0x037f0280  /* Read from VMECHIP2_VSAR1 */
  VME Chip2 VSATR1          : 0x00000280  /* Read from VMECHIP2_VSATR1*/

  Other ITS Processors      :    Start       Size
    0                       : 0x02000000 0x00800000   /* Used in ...        */
    1 (A)                   : 0x02800000 0x01000000   /* ... sysPhysMemDesc */
    2 (B)                   : 0x03800000 0x01000000

BBBB > sysHwConfigShow ()
Processor 2 Hardware Configuration
  Model                     : Motorola MVME167
  CPU Speed (MHz)           : 33
  Local Memory Address      : 0x00000000
        Memory Size         : 0x01000000
  VME   Memory Start        : 0x03800000
  VME   Memory End (+ 1)    : 0x04800000

  Hardware Registers (read)
  VME Chip2 VSAR1           : 0x047f0380
  VME Chip2 VSATR1          : 0x00000380

  Other ITS Processors      :    Start       Size
    0                       : 0x02000000 0x00800000
    1 (A)                   : 0x02800000 0x01000000
    2 (B)                   : 0x03800000 0x01000000

0 > sysHwConfigShow ()
Processor 0 Hardware Configuration
  Model                     : Motorola MVME147
  CPU Speed (MHz)           : 0
  Local Memory Address      : 0x00000000
        Memory Size         : 0x00800000
  VME   Memory Start        : 0x02000000
  VME   Memory End (+ 1)    : 0x02800000

  Other ITS Processors      :    Start       Size
    0                       : 0x02000000 0x00800000
    1 (A)                   : 0x02800000 0x01000000
    2 (B)                   : 0x03800000 0x01000000


- -- Ed

Ed Gamble
Invited Researcher
ATR Human Information Processing
  Research Laboratory                     Phone: +81-7749-5-1036  
2-2 Hikari-dai, Seika-cho, Soraku-gun	  Fax:   +81-7749-5-1008  
Kyoto 619-02 JAPAN			  Email: ebg@hip.atr.co.jp

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

End of New-News digest
**********************


From rab@csg.lbl.gov  Thu Apr  7 09:16:53 1994
From: rab@csg.lbl.gov (Robert Belshe)
Date: Thu Apr  7 09:17:01 PDT 1994
Subject: Re: FDDI Driver


We are also planning to use FDDI soon.   

We are using vxWorks 5.1  and will use a MVME166 processor for the
FDDI.

In this application, data will be sent from the VME data acquisition
system ( via UDP multicast, if possible) to a small number of
sparcStations located nearby.

We have identified 3 possibilities at this point:

     AP Labs 5.1  driver with Interphase 5211

     Radstone Technology 5.1 driver with PME FDDI-1

     Ross Microsystem driver with Rockwell CMC1156

Any information or suggestions on these or other solutions
would be greatly appreciated.

		Thanks,   Bob

   +----------------------------------------------------------+
   |  Robert Belshe                       rab@lbl.gov         |
   |  50B-4235                            Voice 510-486-7509  |
   |  Lawrence Berkeley Laboratory        FAX   510-486-5977  |
   |  Berkely, CA 94720                                       |
   +----------------------------------------------------------+



From daemon@vxw.ee.lbl.gov  Fri Apr  8 04:00:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr  8 04:00:34 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr  8 04:00:13 PDT 1994

        Subject: X input extension
        Subject: Final answer on copyback memPartFree problem
        Subject: Re: Slow backplane net in vxWorks 5.0.2b
        Subject: Re: booting vxWorks V5.1.1 from backplane network
        Subject: Re: fork/exec/wait in VxWorks
        Subject: MVME167 Clone ?

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

Newsgroups: comp.os.vxworks
Subject: X input extension
Date: 7 Apr 1994 11:59:18 GMT
From: hcl@vmsfo.vingmed.no (Hans Chr. Loenstad)
Organization: VINGMED SOUND A/S
Keywords: X11
Message-ID: <2o0sim$iea@vmsfo.lys.vingmed.no>
Reply-To: hcl@vingmed.no
Sender: hcl@vmsfo (Hans Chr. Loenstad)


Has anyone ported the X11R5 input extension client side library
to vxworks?


		Regards


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

Newsgroups: comp.os.vxworks
Subject: Final answer on copyback memPartFree problem
Date: Thu, 7 Apr 1994 17:37:51 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Keywords: bug bug bug
Message-ID: <georg.765740271@sgl.ists.ca>
Sender: news@newshub.ists.ca

Well, I think we now know everything there is to know about the memPartFree()
problem we were having. The original subject here was "memPartFree error with
copyback caching enabled (167)". Other past subjects that possibly related to
the same problem include "Large disk writes w/cache cause MVME167 to freeze".
Apparently the root cause is a snooping problem related to TAS on the
VME bus, and is Motorola's fault.

The solution to the problem is the "MV167 VME TAS patch" from Wind River. 
It consists of a number of configuration changes (config.h, usrConfig.c etc.)
and is reproduced below. Strangely, it has not been assigned an SPR number
because, according to Wind River, the new version of the 167 BSP has fixed
the problem so no SPR is necessary(?). This situation may have changed since
the memos I received were written. Our related TSR number was 16443, which may
help others to track things down.

I had already come up with my own patch that worked in a completely different
(and very specific) way, and the WRS patch seemed not to apply to our problem.
However I tested the patch anyway and sure enough it fixes our problem.
As a bonus, SCSI performance seems to have improved slightly.

This whole affair stinks as far as I'm concerned. I wish Wind River had been
much more specific about who could be affected by this bug (i.e. potentially
anybody doing SCSI I/O on a 162 or 167) and had publicized the problem and
the patch at a much higher priority. Although the bug stems from a hardware
problem, the bottom line is VxWorks doesn't work without the patch.

Thanks to Jerald Pendleton at Wind River and Margaret Votava at Fermilab.

Georg.

- --------------------------- MV162/167 VME TAS patch ------------------------
] 						Date: 03-02-1994
] 						Submitted by: Vinai Kolli
] 
] 
] 			Sub: 	Configuration changes 
] 				which provide workaround for the 
] 				back plane problem for the motorolla mvme162.
] -----------------------------------------------------------------------------
] 
] Due to snoop problems with the Test And Set (TAS) command from the
] VMEbus the following modifications are necessary until the TAS
] command can be snooped from the VMEbus.  The shared memory pool
] will be defined in low memory, and will be marked as non-cacheable
] by the local processor.  The VMEchip will have the snoop control
] bits turned off.  This will not effect the cache and snooping for
] the on-board devices such as ethernet and SCSI, as snooping will
] still be turned on for those devices.
] The size of the memory required for the shared memory should be a multiple
] of 8k which is the default page size for the mmu.
] Any interprocessor communication which is done through a shared memory
] should make sure that the cache is disabled for that shared memory location.
] These changes would be in effect until motorolla fixes the snooping 
] problems. The following changes apply to mvme162 and mvme167
] 
] 	File		Changes
] ------------------------------------------------------------------------------
] 	config.h	define RAM_LOW_ADRS as 0x20000
] 			define SM_MEM_SIZE  as 0xe000 (64k -8k)
] 			define SM_OBJ_MEM_SIZE as 0x10000 (64k)
] 			define SM_MEM_ADRS as 
] 			RAM_LOW_ADRS - (SM_MEM_SIZE + SM_OBJ_MEM_SIZE)
] 			define  SM_OBJ_MEM_ADRS as
] 			RAM_LOW_ADRS - SM_OBJ_MEM_SIZE
] 			Specifically to mvme167 the macro
] 			USER_D_CACHE_MODE should be defined as
] 			(CACHE_COPYBACK | CACHE_SNOOP_ENABLE)
] 	
] 	MakeSkel	change RAM_LOW_ADRS to 0x20000
] 
] 	sysLib.c	In the function sysHwInit2() add a function code
] 			shown below to the end of the function which disables
] 			the cache for the pages dedicated to the shared 
] 			memory.
] 			
] 			void sysHwInit2 (void)
] 			{
] 			 
] 			....
] 			....
] 			....
] 
] 			#ifdef INCLUDE_MMU_BASIC
] 			    (void) vmBaseStateSet (NULL, (void *)SM_MEM_ADRS,
]                         		SM_MEM_SIZE + SM_OBJ_MEM_SIZE,
]                            		VM_STATE_MASK_CACHEABLE,
]                            		VM_STATE_CACHEABLE_NOT);
] 			#endif /* INCLUDE_MMU_BASIC */
] 
] 			#ifdef INCLUDE_MMU_FULL    /* unbundled mmu product */
] 			(void) vmStateSet (NULL, (void *)SM_MEM_ADRS,
] 					SM_MEM_SIZE + SM_OBJ_MEM_SIZE,
]                        			VM_STATE_MASK_CACHEABLE,
]                        			VM_STATE_CACHEABLE_NOT);
] 			#endif /* INCLUDE_MMU_FULL */
] 			}
] 
] 	sysLib.c 	In the function sysProcNumSet() inhibit the snooping
] 			by programming the snoop bits in the vmechip2 as
] 			shown below
] 			change the following Macros 
] 			from				to
] 			-----------------------------------------------
] 			(write sink data)		(snoop inhibit)
] 			VSAMSR2_SNP_WSD			VSAMSR2_SNP_INHIBIT
] 			VSAMSR1_SNP_WSD			VSAMSR1_SNP_INHIBIT
] 
] 		
] 
- -- 
Georg Feil
Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

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

Newsgroups: comp.os.vxworks
Subject: Re: Slow backplane net in vxWorks 5.0.2b
Date: 7 Apr 1994 23:39:40 GMT
From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae)
Organization: Silicon Graphics, Inc., Mountain View, CA
Message-ID: <2o25js$l9h@fido.asd.sgi.com>
References: <01HAMP4HXGPCI2IK63@yalph2.physics.yale.edu>

In article <01HAMP4HXGPCI2IK63@yalph2.physics.yale.edu>,
 <LAJOIE@yalph2.physics.yale.edu> wrote:
>We have a backplane network under vxWorks 5.0.2b that includes 10 processors 
>(4 Matrix MD-CPU338's and 6 GMS v49's).  The master processor has 512k 
>allocated for the shared memory, and all processors ar using mailbox 
>interrupts.  Due to a bug with the Matrix CPU's, we are forced to use the 
>software TAS.
>

software TAS is a very slow mechanism (it is a dumb spin-lock).  it's
unfortunate that both the old and new BP drivers in vxworks use TAS at all.
one way to make things go much faster would be to eliminate any need for
TAS.  a pair of simple shared, half-duplex message queue with a set of
pointers can be used to construct such a device driver.  this will work well
even on CPU's that have problems supporting RMW cycle in hardware.

another area that can be improved is eliminating unnecessary copies (this is
not the cause of your performance problem).  both the old and new BP drivers
copy the data from sender to the receiver, while reception code is optimized
to avoid copying when possible.  when i last optimized the old BP driver, i
did the reception side copy-avoidance, which helped a lot, but i didn't do
the same for the sender side, because it required a significant rewrite.
considering that WRS has recently re-written the BP driver (SM driver), it's
surprising that they did not do this work to help the performance.

hwajin
PEACEFUL STAR

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

Newsgroups: comp.os.vxworks
Subject: Re: booting vxWorks V5.1.1 from backplane network
Date: 7 Apr 1994 23:44:01 GMT
From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae)
Organization: Silicon Graphics, Inc., Mountain View, CA
Keywords: backplane network
Message-ID: <2o25s1$lgr@fido.asd.sgi.com>
References: <1994Apr1.015734.20073@neopath.wa.com>

In article <1994Apr1.015734.20073@neopath.wa.com>,
Rick Bauer <rick@neopath.wa.com> wrote:
>
>     Error loading file: errno = 0xd
>     Can't load boot file!!
>
>     If we query the backplane network, smNetShow, after the MVME162
>boot fails, the report inidicates that only CPU 0 is attached to sm0.
>This seems to contradict the boot messages from the MVME162 indicating
>that the CPU succesfully attached to both sm0 and lo0.
>

i'll make an obvious suggestion: in situations like this, it helps to bring
up two boards independently (i.e. boot each one over ethernet or by some
other means) and initialize the BP network interface by hand, verifying step
by step what occurs.  once you get the BP network to communicate properly
this way, you can attempt to boot. you can set breakpoints in the code,
examine BP memory pool for heartbeat, excercise various functionalities to
get confidence before you attempt the boot up sequence.  trying to debug
when booting process fails is hard; you have no resort.

hwajin
PEACEFUL STAR

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

Newsgroups: comp.os.vxworks
Subject: Re: fork/exec/wait in VxWorks
Date: 7 Apr 1994 23:56:39 GMT
From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae)
Organization: Silicon Graphics, Inc., Mountain View, CA
Message-ID: <2o26jn$lsn@fido.asd.sgi.com>
References: <ericpCnpsCE.At7@netcom.com>

In article <ericpCnpsCE.At7@netcom.com>,
Eric Peterson <ericp@netcom.com> wrote:
>	Is there an easy (or at least straightforward) method for emulating the
>	Unix fork/exec/wait tasking primitives in VxWorks?  I'm doing some
>	porting of some Unix apps, and I would think that this pops up quite
>	often (I searched the FAQ without luck).  Also, is the SIGCHLD signal
>	really implemented to be generated upon (sub)-task exit, or is it just
>	there to make things compile :-)?  The man pages aren't too clear on
>	signal behavior.

as far as i know this is not easy in vxworks.  there is no resource
management or reclamation per task in vxworks tasking model.  implementing
this correctly will require a significant rewrite, or addtion of code, or
uglification.  i believe SIGCHLD does not work, based on my experiences on
vxworks 5.0 (last one i've worked on years ago), there is no parent/child
relationship between tasks.  nor is there group/session, nor is there
inheritable resources (such as descriptors), etc.  vxworks indeed is very
different from UNIX... although i've heard that WRS is working on POSIX
compatibility issues.

hwajin
PEACEFUL STAR


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

Newsgroups: comp.realtime,comp.os.vxworks,comp.os.lynx,comp.sys.m68k
Subject: MVME167 Clone ?
Date: Thu, 7 Apr 1994 21:39:41 GMT
From: mmourier@atmsys.com (Marcelo C Mourier)
Organization: AMP/ATM Systems Inc.
Message-ID: <Cnws66.GAt@isthmus.atmsys.com>
Followup-To: comp.realtime
Reply-To: mmourier@atmsys.com
Sender: news@isthmus.atmsys.com

I just found out the price of the MVME167-002A boards... :-(

Does anybody know of another board with similar characteristics? I don't 
even need all the features of the MVME167... Specifically, I'm looking for 
a board with a 68LC040 @ 25MHz, 8MB RAM, EPROM, UART, timer, and Ethernet. 
Ideally, the UART and Ethernet would be the same type used in the MVME167. 
I don't need SCSI and don't need VME either...  :-)

Any help will be greatly appreciated!

+---------------------------------+-----------------------------------------+
| Marcelo Mourier                 |                                         |
| ATM Systems                     |  (this space intentionally left blank)  |
| A division of Connectware, Inc. |                                         |
| mmourier@atmsys.com             |                                         |
+---------------------------------+-----------------------------------------+


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

End of New-News digest
**********************


From ddavies@sim.es.com  Fri Apr  8 07:51:12 1994
From: ddavies@sim.es.com (Doug Davies)
Date: Fri Apr  8 07:51:25 PDT 1994
Subject: Re: comp.os.vxworks newsdigest
> Marcelo Mourier writes:
>
> I just found out the price of the MVME167-002A boards... :-(
> 
> Does anybody know of another board with similar characteristics? I don't 
> even need all the features of the MVME167... Specifically, I'm looking for 
> a board with a 68LC040 @ 25MHz, 8MB RAM, EPROM, UART, timer, and Ethernet. 
> Ideally, the UART and Ethernet would be the same type used in the MVME167. 
> I don't need SCSI and don't need VME either...  :-)

Take a look at the Motorola MVME162.  It has the features that
you are after at a significantly lower cost.  We've used it and
are quite pleased.  It is closely compatible with the MVME167.

Good luck.

-Doug
--------------------------------------------------------------------------------
Douglas Davies (software engineer) |
Evans & Sutherland                 | "Never underpay your software engineers"
INTERNET: ddavies@jaba.sim.es.com  |                     -Jurassic Park Moral


From daemon@vxw.ee.lbl.gov  Sat Apr  9 04:00:22 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr  9 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr  9 04:00:13 PDT 1994

        Subject: ld error
        Subject: Motorola 162 with Octal 422 IP
        Subject: Ethernet network lockout during application execution
        Subject: h
        Subject: VxWorks memory/rom requirements

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

Newsgroups: comp.os.vxworks
Subject: ld error
Date: Fri, 8 Apr 1994 14:05:12 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: BNR Inc., RTP, NC
Message-ID: <Cny1sr.LD0@nrtpa22.bnr.ca>
Sender: billag@b4pphff (Bill Gutknecht)

- -> ld < coatd
value = 3782388 = 0x39b6f4
- -> perror
S_objLib_OBJ_ID_ERROR
value = 22 = 0x16
- ->

	This seemed to show up when I added an additional procedure
	to the object module.  I'm at a loss as to what is really 
	the problem (and I don't want to take the procedure back out.)

	Can someone give me some insight on how to figure out what this
	really means?  Thanks.

	[vxWorks5.1.1 MVME162-13]
 
- ------------------------------------------------------------------------------
Bill Gutknecht                  "If I die, I will go before Crom and he will 
BNR/Northern Telecom             ask me 'What is the Riddle of Steel?'  If I do
Research Triangle Park, NC       not know it, he will cast me out of Valhalla
billag@bnr.ca                    and laugh at me ... "
- ------------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Motorola 162 with Octal 422 IP
Date: Thu, 7 Apr 1994 17:52:15 GMT
From: davel@fairmpc.fairfld.mcd.mot.com (David Lowery)
Organization: Motorola Computer Group, Fairfield Sales Office
Message-ID: <1994Apr7.175215.3211@phx.mcd.mot.com>
Sender: davel@fairmpc (David Lowery)



I have a customer who is having some problems using the Greensprings Octal 422
IP on our 162.  Has anyone out there had any experience with this IP using
the VxWorks drivers?  Octal 232 seems to work ok.

Any info would be appreciated.

Thanks, Dave
- -- 
[ David W. Lowery                     Voice: 201-808-2436                  ]
[ Motorola Computer Group             Fax  : 201-808-0359                  ]
[ 100 Passaic Ave.                    Pager: 1-800-SKY-PAGE Pin#: 8551615  ]
[ Fairfield, NJ 07004                 Email: davel@fairfld.mcd.mot.com     ]   

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

Newsgroups: comp.os.vxworks
Subject: Ethernet network lockout during application execution
Date: Thu, 31 Mar 1994 19:30:16 GMT
From: jhgriff@sed.csc.com (Jeffery H. Griffith)
Organization: Computer Sciences Corporation
Keywords: ethernet
Message-ID: <CnJnIH.AM3@sed.csc.com>

Our system is configued as follows:

Heurikon hkv960d board running VxWorks 5.1.1 in a VME chassis booting
over the backplane.

Problem:

After booting vxWorks over the VME backplane, the ethernet interface is
enabled using the "if" routines.  Routes are set up properly and data
flows successfully through the ethernet interface, UNLESS a process on the
i960 begins execution and does not block.  The executing task is set at the
lowest priority yet is never interrupted and the ethernet traffic completely
stops.  Adding taskDelay to the task does allow ethernet traffic to get
through but are unacceptable for our application.  It is my understanding
that the low priority task should always be interrupted by the netTask.
In all other instances, this task does indeed get interrupted by every other
task on the system.  Any suggestions? (email reply would be appreciated).

Thanks,

Jeffery Griffith
Computer Sciences Corporation
jhgriff@sed.csc.com

- -- 
- -- 
Jeffery Griffith                   |
Computer Sciences Corporation      |
jhgriff@sed.csc.com                | 

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

Newsgroups: comp.os.vxworks
Subject: h
Date: Fri, 08 Apr 1994 22:34:05 GMT
From: hschneid@gauss.cfm.udec.cl (Heinz Schneider F.)
Organization: Universidad de Concepcion, Concepcion - Chile
Message-ID: <1994Apr08.223405.141164@halcon.dpi.udec.cl>
Sender: usenet@halcon.dpi.udec.cl

gdhsdjfsduud
kdfjslkduier
dfklsdgs$lkdgs

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

Newsgroups: comp.os.vxworks
Subject: VxWorks memory/rom requirements
Date: 8 Apr 94 14:56:09
From: jmorris@hot.caltech.edu (John Morris)
Organization: Caltech Control Lab
Message-ID: <JMORRIS.94Apr8145609@hot.mu.caltech.edu>

I've got a couple of questions on VxWorks memory/rom requirements:

* how much RAM is necessary to support the standard development
  environment with backplane/serial/ethernet drivers and shared
  memory
* how much ROM is necessary to boot VxWorks from either the
  backplane or serial port

Thanks,

John C. Morris             -----|-----     e-mail: jmorris@hot.caltech.edu
Caltech, M/C 116-81     *>=====[_][ )      work:   (818) 395-4855,3218,2179
Pasadena, CA  91125           _'_`_        FAX:    (818) 795-1547

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

End of New-News digest
**********************


From stan@rti.rti.com  Sat Apr  9 10:45:29 1994
From: stan@rti.rti.com (Stan Schneider)
Date: Sat Apr  9 10:45:39 PDT 1994
Subject: Re: Ethernet network lockout during application execution
>> Date: Thu, 31 Mar 1994 19:30:16 GMT
>> From: jhgriff@sed.csc.com (Jeffery H. Griffith)

>> ...The executing task is set at the
>> lowest priority yet is never interrupted and the ethernet traffic completely
>> stops.  Adding taskDelay to the task does allow ethernet traffic to get
>> through but are unacceptable for our application.  It is my understanding
>> that the low priority task should always be interrupted by the netTask.

Sounds like you're using polling communications for your backplane net.  The
poll task runs at the lowest priority (255); anything that uses all the CPU
will lock it out, thereby never giving the tNetTask any reason to wake up.  You
have three choices.  1) configure your backplane to use interrupt
communications (best).  2) put both tasks at the same prio & turn on
time-slicing (may work, but net latency will be increased).  3) live with the
taskDelays.

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================




From rdmacko@somnet.sandia.gov  Mon Apr 11 08:10:50 1994
From: RD Mackoy <rdmacko@somnet.sandia.gov>
Date: Mon Apr 11 08:10:59 PDT 1994
Subject: User Group Meeting?
Hello,
	Have there been any plans made for the west coast user group
meeting yet?
Thanks,
RD Mackoy		rdmacko@somnet.sandia.gov
Sandia National Labs	505-844-1911
PO Box 5800 		505-844-4797
Albuquerque, NM		87185-0635




From GNPW81A@prodigy.com  Mon Apr 11 20:53:00 1994
From: GNPW81A@prodigy.com (MR ROBERT D STEELE)
Date: Mon Apr 11 20:53:09 PDT 1994
Subject: taskDelay

The system I have inherited has a low priority task polling on a socket
with a 0 wait. For reference this low priority task is name ui_task
(user interface). There is a higher priority task which is consuming 92%
of the CPU. This high priority task is name ctrl_task (control).

Timing ui_task from an external bus analyzer shows that is takes as long
as 700 milliseconds to complete. When I suspend ctrl_task and time ui_task
it takes 0.17 milliseconds to complete.

I have a lower priority task yet that is getting completely starved by the
ui_task. In an attempt to get this task to have a little time to run
I added a taskDelay(1) to the loop in ui_task. Not only did this low priority
task get a chance to run, but the ui_task now took only 150-200 milliseconds
to complete.

My question is: "Why the apparent improvement in ui_task when I am running
it as a periodic task running at 60 Hertz.

I am using vxWorks version 5.1.1 and the system is running on a MVME 167-31A
processor. The system clock is set to 60 Hertz. ctrl_task is running
off of the auxillary clock and is running at 400 Hertz.

If anyone has any ideas and/or need any more information to help me feel
free to write or call.


                                Robert Steele
                                steele@telerobotics.jpl.nasa.gov
                                (818) 354-4847



From daemon@vxw.ee.lbl.gov  Tue Apr 12 04:00:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Apr 12 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Apr 12 04:00:15 PDT 1994

        Subject: ??? driver for HP VME laser interferometer boards???
        Subject: Green Card Lottery- Final One?

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

Newsgroups: comp.os.vxworks
Subject: ??? driver for HP VME laser interferometer boards???
Date: 11 Apr 1994 18:03:37 GMT
From: EJMOLER@lbl.gov (edward moler)
Organization: Lawrence Berkeley Laboratory
Message-ID: <2oc3dp$6it@overload.lbl.gov>
Sender: eddie@ux5.lbl.gov (edward moler)

	Howdy.  Are there any drivers out there written for the Hewlett-Packard
Laser Interferometer boards for VME??? I know that HP doesn't have any.
					Thanks in advance,

					Eddie Moler
					Lawrence Berkeley Laboratories
					EJMOLER@LBL.GOV

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

Newsgroups: comp.os.vxworks,maus.sys.atari.okami
Subject: Green Card Lottery- Final One?
Date: 12 Apr 1994 07:56:14 GMT
From: nike@indirect.com (Laurence Canter)
Organization: Canter & Siegel
Message-ID: <2odk6u$36u@herald.indirect.com>

Green Card Lottery 1994 May Be The Last One!
THE DEADLINE HAS BEEN ANNOUNCED.

The Green Card Lottery is a completely legal program giving away a 
certain annual allotment of Green Cards to persons born in certain 
countries. The lottery program was scheduled to continue on a 
permanent basis.  However, recently, Senator Alan J Simpson 
introduced a bill into the U. S. Congress which could end any future 
lotteries. THE 1994 LOTTERY IS SCHEDULED TO TAKE PLACE 
SOON, BUT IT MAY BE THE VERY LAST ONE.

PERSONS BORN IN MOST COUNTRIES QUALIFY, MANY FOR 
FIRST TIME.

The only countries NOT qualifying  are: Mexico; India; P.R. China; 
Taiwan, Philippines, North Korea, Canada, United Kingdom (except 
Northern Ireland), Jamaica, Domican Republic, El Salvador and 
Vietnam. 

Lottery registration will take place soon.  55,000 Green Cards will be 
given to those who register correctly.  NO JOB IS REQUIRED.

THERE IS A STRICT JUNE DEADLINE. THE TIME TO START IS 
NOW!!

For FREE information via Email, send request to
cslaw@indirect.com


- -- 
*****************************************************************
Canter & Siegel, Immigration Attorneys
3333 E Camelback Road, Ste 250, Phoenix AZ  85018  USA
cslaw@indirect.com   telephone (602)661-3911  Fax (602) 451-7617

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

End of New-News digest
**********************


From daemon@vxw.ee.lbl.gov  Wed Apr 13 04:00:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr 13 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr 13 04:00:14 PDT 1994

        Subject: Any horror stories about 5.1.1 vs 5.1
        Subject: Looking for Xm/Xt libraries for vxWorks

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

Newsgroups: comp.os.vxworks
Subject: Any horror stories about 5.1.1 vs 5.1
Date: 12 Apr 1994 15:02:55 GMT
From: bt@ssec.wisc.edu (Bill Taylor)
Organization: University of Wisconsin, Madison, Space Science and Engr Cntr
Message-ID: <2oed6v$j0b@spool.cs.wisc.edu>

I have a client who must get a fix to the ethernet driver in the 
Mot 167 card board support and it was combined with a 5.1 to 5.1.1
change. Should I be concerned about two changes at once to them.

Time is pressing so I can not test it as long as I might like.


???????

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

Newsgroups: comp.os.vxworks
Subject: Looking for Xm/Xt libraries for vxWorks
Date: 12 Apr 1994 20:33:20 GMT
From: ahein@bssv01.hac.com (Alan Hein)
Organization: Hughes Aircraft Company
Keywords: vxworks motif
Message-ID: <2of0ig$3id@hacgate2.hac.com>

     We're developing a Motif application for use under vxWorks, and we are
seeing crashes which look like they might be re-entrancy problems within
Xm/Xt.   We use several processes, each with their own display connection,
but running at different priorities.  We don't access widgets created 
within a process in any other process. Apparently, however, when a higher
priority process activates while a lower priority process was in the 
middle of doing something, we sometimes crash within an Xm/Xt routine, due
to corrupted data base.  

     We began our development with Wind River's windX package, and we had
good success up to the point where we just couldn't live with some of the
problems in Motif 1.1. Apparently, Wind River decided to drop X/Motif as
a product line, and we had to make a hasty switch to Motif 1.2.3 from another
Vendor.

     Has anyone experienced such problems with Motif under vxworks?  Were you
able to work around it?  Can you point me towards any vendors which supply
re-entrant Xm/Xt libraries for vxWorks?  (Motif 1.2.3 or later).

     We're also worried about memory leaks and fragmentation over long periods
of use.  Is anyone aware of any 3rd party memory management packages which
might help us out here?


Thanks!

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

End of New-News digest
**********************


From hebo@mbari.org  Wed Apr 13 10:07:52 1994
From: Bob Herlien <hebo@mbari.org>
Date: Wed Apr 13 10:08:00 PDT 1994
Subject: Re: comp.os.vxworks newsdigest
>      We're developing a Motif application for use under vxWorks, and we are
> seeing crashes which look like they might be re-entrancy problems within
> Xm/Xt.   We use several processes, each with their own display connection,
> but running at different priorities.  We don't access widgets created 
> within a process in any other process. Apparently, however, when a higher
> priority process activates while a lower priority process was in the 
> middle of doing something, we sometimes crash within an Xm/Xt routine, due
> to corrupted data base.  

I've never used X/Motif under VxWorks, so take this with a grain of salt
(i.e., WRS may have an improved Motif).  But neither Motif nor the Xt
Intrinsic library is reentrant, at least in their standard Unix form.
They're also synchronous -- you can't make Xt/Motif calls from within
a signal handler, for example, due to lack of reentrancy.  The standard
answer for "how do I update my display to reflect a real-time event?" is
to use a TimeOutProc or WorkProc.  XtAppAddTimeOut and XtAppAddWorkProc
can be called asynchronously, I believe.

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org


From sugar2!focal.com!john@netcom.com  Wed Apr 13 18:09:57 1994
From: john@focal.com (John Calvin)
Date: Wed Apr 13 18:10:06 PDT 1994
Subject: Remember this one? (Scripts)
	A while back (last August I think) there was some discussion about 
starting up a script file from within a program, and how to handle the standard
I/O redirections.  Can anyone refresh me on how this is done?  

	I've tried the following, but its as if the redirected script file is
never being run.  The test script file is being accessed over NFS and is set to
777 but has'nt improved matters. Regretably with the shell gone when this is 
running, its a little hard to tell whats going on inside.
~Code Segment.

    /* open test file */
    inFd1 = open ("test.vxw", READ, 0); 
 
    /*
     * Kill the interactive shell session.
     * and flush any outstanding io operations 
     */ 
    oldShellId = taskNameToId (shellTaskName);
    taskDelete (oldShellId);
    ioctl ( STD_IN, FIOFLUSH, OPT_TERMINAL );
 
    /*
     * Save old I/O pointers.
     */
    old = ioGlobalStdGet (STD_IN);
 
    /* 
     * Fire off a new shell, with redirected input. 
     */ 
    shellInit (SHELL_STACK_SIZE, FALSE);
    shell (FALSE)  /*<- Do I need this or does shellInit do spawn the shell?*/ 
 
    /* 
     * ID the newly spawned shell, so we can direct its input.
     */ 
    newShellId = taskNameToId (shellTaskName);
 
    ioTaskStdSet (newShellId, inFd1, 0);   /* Specify task specific input */
    /*ioGlobalStdSet (STD_IN, inFd1);*/    /* Specify global input source */
                                           /* Neither seem to work.       */  
 
    /* 
     * Hang around untill spawned shell exits on its own. 
     */ 
     do 
     { 
        taskDelay ((sysClkRateGet ())/2); 
     } while (IdtaskNameToId (shellTaskName) != ERROR); 
 
 
    /*
     * After script processor shell ends, restart an interactive one
     */
    shell (TRUE);
    ioGlobalStdSet (STD_IN, old);          /* Return to old I/O paths */
 
    close (inFd1);
 
 
Any Ideas or comments would be appreciated, and would certainly save some time.
The key thing here is in the redirections, as I want to modify this once it works
to take input from a pipe fd, rather than a file fd. 
Thanks in advance.

John Calvin
Calvin@netcom.com
--------------------------------------------------------------------------------- 


From daemon@vxw.ee.lbl.gov  Thu Apr 14 04:00:25 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr 14 04:00:34 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr 14 04:00:14 PDT 1994

        Subject: WindC++ GateWay for i960 and CenterLine S/W Products 

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

Newsgroups: comp.os.vxworks
Subject: WindC++ GateWay for i960 and CenterLine S/W Products 
Date: Wed, 13 Apr 1994 14:09:58 GMT
From: ihab@bcarh52d.bnr.ca (Ihab Mahna)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <1994Apr13.140958.3561@bcarh54a.bnr.ca>
Sender: ihab@bcarh52d (Ihab Mahna)


Hello,

I am going to install the evaluation copy of WindC++ Gateway and CenterLine software (ObjectCenter,CodeCenter, ObjectCenter).

Here is My Setup:- 

Host	: Sun sparc + Sun OS (4.1.3)
Target	: i960 + VxWorks 5.1.1

Currently we are using VxGDB+GNU compiler as a development environment, 
all our code for the target is written in C and assembly. We are thinking 
about switching to a more integrated development environment that works with VxWorks (As far as I know CenterLine products is the only choice).

Is there any one up there has a similar setup ? 
Please give me your opinion about it.


Regards,
Ihab, Mahna 				Phone:(613) 765-4284
Bell-Northern Research Ltd. 		Fax: (613) 763-2626
Ottawa, Ontario, Canada (K1Y 4H7) 	Email: "ihab@bnr.ca" 

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

End of New-News digest
**********************


From pak@rtp.co.uk  Thu Apr 14 05:25:21 1994
From: pak@rtp.co.uk (Paul Keir)
Date: Thu Apr 14 05:25:32 PDT 1994
Subject: Profibus


Hi there,

Can anyone help ?  I'm trying to find out if there is any VxWorks support for
Profibus.  Any information regarding VxWorks drivers/boards or whatever would
be useful.

Thanks.

Paul Keir
pak@rtp.co.uk


From dwampl@atl.com  Thu Apr 14 09:21:28 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Thu Apr 14 09:21:46 PDT 1994
Subject: Re: Vx Exploder Digest

> Subject: WindC++ GateWay for i960 and CenterLine S/W Products 
> ... 
> I am going to install the evaluation copy of WindC++ Gateway and CenterLine software (ObjectCenter,CodeCenter, ObjectCenter).
> 
> Here is My Setup:- 
> 
> Host	: Sun sparc + Sun OS (4.1.3)
> Target	: i960 + VxWorks 5.1.1
> ... 
> Is there any one up there has a similar setup ? 
> Please give me your opinion about it.
> 
 
I am using the same setup, with the exception that we use the 68K.  I use 
objectcenter for testing and evaluating our code on the Sun before moving it to
the target.  It is a wonderful environment, but it is a real resource code.
Make sure that you have lots of RAM in your workstation.  A relatively fast
SPARC would help, too.

On the Vxworks side, the full functionality of OC isn't available.  You can only
use their so-called "process-debugging mode" (pdm), which is basically a very-
nice front end for gdb (more useful than vxgdb).  It is bigger and more
resource hungry than vxgdb, but is much better for complex debugging
sessions, especially when you need to display complex data, such as objects.

I have had occasional problems w/ OC crashing will debugging Vxworks code, and
it really would be nice if all of OC's functionality could be used.  Never the
less, I strongly recommend it for working with WindC++.

By the way, a suggestion WindC++.  The "munching" of global, static objects
is a pain; be sure that you not only munch your own C++ code, but also the
C++ libraries, especially "iostreams".  If you don't, you can't use "cout", etc.


Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|                 "I feel your pain...."  =:O]                    |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+


From franks@se01.wg2.waii.com  Thu Apr 14 09:40:32 1994
From: franks@se01.wg2.waii.com (Jeffrey L. Franks)
Date: Thu Apr 14 09:40:42 PDT 1994
Subject: Questions About Real-time C++ VxWorks Embedded Systems

We are contemplating using C++ (CenterLine C++ & gcc) with VxWorks in a VME
  environment using 68030 or better.  Our application will make
  heavy use of iostreams class library, NFS, sockets, etc.


Are there any developers who would like to share their experiences of
  using C++ with VxWorks in a real-time environment?

Can you brielfy describe your application(s)?

What were the severe gotcha's?

Have you found the CenterLine/gcc/VxWorks development environment to be stable?

What's been your experience with debugging the target using Vxgdb++ and
  CenterLine on the target. Any gotcha's or insurmountable problems.

Does the iostreams class library work as expected?

What 3rd party class libraries are you using?

Have you discovered any problems using 3rd party class libraries, i.e.:
  re-entrancy or thread-safe issues, other?

Has anyone ported or used RogueWave class libraries with VxWorks?


----------------
Jeff Franks                    Western Geophysical Exploration Products
____    ____     ____          a division of Western Atlas International Inc.
\   \  /   /\   /   /\         
 \   \/   /  \ /   /  \        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  \  /   / \  /   /\   \       Internet  :  franks@wg2.waii.com
   \/___/   \/___/  \___\      Voice     :  (713) 964-6199



From westley@hercules.calspan.com  Thu Apr 14 13:17:49 1994
From: westley@hercules.calspan.com (Terry J. Westley)
Date: Thu Apr 14 13:18:09 PDT 1994
Subject: help wanted: floating point does not work in MVME167
Floating point does not work correctly on at least two MVME167s we have
running VxWorks 5.0.2b.  I haven't tested the other ones, but they are
running the same kernel.

The following program was compiled with the VxWorks distributed GNU
C compiler as well as with the Sun/SPARC compiler:

---------------------- cut here ---------------------------
#include <stdio.h>
#include <math.h>

main() { 

   double a, b, c;

   a = -11.00557;
   b =   6.28319;
   c = fmod (a, b);

   printf ("%f\n", c);
}
---------------------- cut here ---------------------------

The results are as follows:

-> ld < fmod
value = 0 = 0x0
-> sp _main
task spawned: id = 0xfbaaac, name = t1
value = 16493228 = 0xfbaaac
-> -.155999

When run in the Sun, this program yields the following (correct) result:

-4.722380

As far as I can tell from the manuals I have, the kernel was built 
correctly for floating point by defining the following:

#define INCLUDE_MC68881         /* MC68881/2 float point co-processor */
#define INCLUDE_FLOATING_POINT  /* floating point I/O */

Yes, I know that the 68040 basic floating point is built-in and the high-level
operations are done in software, but the manual says to use these ifdefs.

In addition, lkup confirms that "mathHardInit" is in the symbol table and
"mathSoftInit" is not.

Any ideas?



From stan@rti.com  Thu Apr 14 14:19:24 1994
From: stan@rti.com (Stan Schneider)
Date: Thu Apr 14 14:19:40 PDT 1994
Subject: Re: Remember this one? (Scripts)

>> Submitted-by sugar2!focal.com!john@netcom.com  Wed Apr 13 18:09:57 1994

>> 	A while back (last August I think) there was some discussion about 
>> starting up a script file from within a program, and how to handle the
>> standard I/O redirections. 

>> <program deleted.>

One way to do this is to just read the file yourself, and call "execute(line)"
for each line.  It's a lot easier than redirection.  I.e:

    char line[256];
    fp = fopen("test.vxw", "r");
    while (fgets(line, 255, fp) != EOF) {
	if (execute(line) == ERROR) {barf; break;}
    }
    fclose(fp);

You may want to call "shellLock" around this.

>> Regretably with the shell gone when this is running, its a little hard
>> to tell whats going on inside.

You should take a look at "rshell", the reentrant shell program in RTILib.  It
lets you open multiple connections to your target.  It can also execute a file
of simple "shell" commands directly.

Hope this helps,

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================




From ddavies@sim.es.com  Thu Apr 14 14:47:45 1994
From: ddavies@sim.es.com (Doug Davies)
Date: Thu Apr 14 14:48:08 PDT 1994
Subject: Re: help wanted: floating point does not work in MVME167
The "fmod" thang...

> The results are as follows:
> 
> -> ld < fmod
> value = 0 = 0x0
> -> sp _main
> task spawned: id = 0xfbaaac, name = t1
> value = 16493228 = 0xfbaaac
> -> -.155999
> 
> When run in the Sun, this program yields the following (correct) result:
> 
> -4.722380

Once again, "fmod" on 68040 base machines is broken in the 5.0.2
release of vxWorks.

As many times as this has come up here recently, I think that WRS
ought to alert their customers using 5.0.2 on 68040 based machines
that "fmod" is broken (and also that there are other floating point
problems with 5.0.2), with a general announcement.

It seems to me that many vxWorks users have wasted a *LOT* of
time debugging the "fmod" thang on 5.0.2.  What a waste...  Of
course the solution is to move to 5.1.1.  We are currently in
the middle of that "move" which has cost us almost 3 months so
far on a project that couldn't afford the delay, and we're not
there yet...

Anyway, as far as your floating point problem goes... don't
rely on "fmod" in 5.0.2 on a 68040 based machine.

-Doug
--------------------------------------------------------------------------------
Douglas Davies (software engineer) |
Evans & Sutherland                 | "Never underpay your software engineers"
INTERNET: ddavies@jaba.sim.es.com  |                     -Jurassic Park Moral


From daemon@vxw.ee.lbl.gov  Fri Apr 15 04:00:19 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr 15 04:00:27 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr 15 04:00:11 PDT 1994

        Subject: Motorola MVME162 Real Time Clock and VxWorks clock
        Subject: Motorola/GreenSpring IEEE-488 IP driver
        Subject: Unloading .o files ?

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

Newsgroups: comp.os.vxworks
Subject: Motorola MVME162 Real Time Clock and VxWorks clock
Date: 14 Apr 1994 12:18 PST
From: cadfael@reg.triumf.ca (MORRIS, DAVID)
Organization: TRIUMF: Tri-University Meson Facility
Keywords: VxWorks, Real Time Clock, MVME162
Message-ID: <14APR199412184604@reg.triumf.ca>

When VxWorks boots, should it look at the Real Time Clock chip on the
Motorola MVME162 and initialize the internal clock routine automatically?
It does not appear to in my installation and I have not found an
explanation. If anyone has the answer and a code example...

				Thanks!

				Dave Morris
				TRIUMF-UBC
				604-222-1047


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

Newsgroups: comp.os.vxworks
Subject: Motorola/GreenSpring IEEE-488 IP driver
Date: 14 Apr 1994 13:14 PST
From: cadfael@reg.triumf.ca (MORRIS, DAVID)
Organization: TRIUMF: Tri-University Meson Facility
Keywords: MVIP300, IP-488, IEEE-488
Message-ID: <14APR199413144688@reg.triumf.ca>

Has anyone got a VxWorks compatible driver written for the
Motorola MVIP300 or GreenSpring IP-488 IEEE-488 IP module?

A WindRiver tech at a Real Time Tradeshow in Vancouver mentioned
there might be a quasi-sanctioned driver out there. If anyone
has experiences (hopefully happy ones) with either of these
products (they are identical) please contact me.

I am using an MVME-162 with VxWorks 5.1

				Dave Morris
				TRIUMF-UBC
				604-222-1047


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

Newsgroups: comp.os.vxworks
Subject: Unloading .o files ?
Date: 14 Apr 1994 19:30:32 GMT
From: worrall@scrap.ssec.wisc.edu (Thomas Worrall)
Organization: Space Science & Engr. Ctr.
Message-ID: <2ok5ko$lhe@spool.cs.wisc.edu>
Reply-To: worrall@ssec.wisc.edu

Say I load a .o file

	-> ld < DANGEROUS.o

and I run some DANGEROUS functions.  But then I want the system to
be wholesome and safe again.  Is there anyway to "unload" these functions
so some innocent passer by couldn't accidentally type in a DANGEROUS 
function and be maimed or worse?

Besides rebooting the system, I mean.  That's what we do now.

- -- 
Thomas Worrall				      Internet:    worrall@ssec.wisc.edu
Space Science and Engineering Center	      
1225 West Dayton			      Tel. 608-263-2566
University of Wisconsin, Madison 53706	      Fax  608-262-5974

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

End of New-News digest
**********************


From dwampl@atl.com  Fri Apr 15 10:10:33 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Fri Apr 15 10:10:42 PDT 1994
Subject: More on C++ and Vxworks

> From rdmacko@somnet.sandia.gov Fri Apr 15 06:12:38 1994
> Date: Fri, 15 Apr 1994 07:13:33 -0600
> From: RD Mackoy <rdmacko@somnet.sandia.gov>
> To: dwampl@atl.com
> Subject: Re: Vx Exploder Digest
> Newsgroups: comp.os.vxworks
> Organization: Sandia National Laboratories
> Cc: 
> Content-Length: 350
> 
> Could you please expound on the munching the libraries?  

When you use "CC" (i.e. "cfront") on the Sun, the link step performed by
CC invokes a tool called "munch", which reads the object code, finds all global,
static objects, and creates a startup function (called before "main") which 
will invoke all the constructors for those objects.  A comparable function is
created to call all the corresponding destructors when "exit" is called.
All of this is transparent to us developers.

Since VxWorks doesn't require the same "all-in-one" link philosophy, it is 
necessary for the developer to do this "munch" step.  It can only be done ONCE,
because it creates two global C functions, one that invokes all the constructors
and one that invokes all the destructors.  This is true even if your approach
is to do a complete link of a bootable kernel, and then download object code 
on top of it; you get only one "munch".

The basic algorithm for the munch process is as follows:

1) Run "nm68k" on all the object code (kernel - if you put the C++ libs. there,
your application code, etc....).

2) Pipe the output of (1) through "munch68k", and redirect the output to a
C file.

3) Compile the C file with gcc68k (NOT CC68k).

4) Do an incremental link of the output object file with the rest of the object
code.


Since there is no "main" in your code, you have to invoke the two, 
aforementioned global constructor and destructor functions explicitly.  
This is done either using an "automatic" strategy or by calling the functions 
"cplusCtors()" and "cplusDtors()", respectively.  All of this confusion is 
described in the WindC++ users guide.

> Also, I have a 
> problem using vxgdd and c++ code.  Every time I try to run a routine on
> the target ('030) it says it cannot create task on target.  Any ideas?

Vxgdb has problems with mangled function names.  If you have a C++
function, it understands what to do if you issue the command "break func_name",
but the command "run func_name" doesn't work (you get that cryptic message 
about not being able to create a task).  Go figure....  However, it does
understand the mangled version of the name.  (In fact, for member functions,
even "break class::member" may not work; I can't recall just now....)

In our case, most of our subsystem-to-subsystem interactions are done through 
non-member functions with C-name "binding" (most of the subsystems are actually
in C, so this is mandatory.)  When I want to step through C++ code w/ vxgdb,
I usually do "break C_func", or list the C++ file and set a breakpoint on the
appropriate line number.

ObjectCenter is a little better at handling C++ debugging on VxWorks, but I've
had problems w/ it crashing occasionally.

I'm also posting other information to the "exploder" in response to another 
query.

Dean


+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|                 "I feel your pain...."  =:O]                    |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+


From dwampl@atl.com  Fri Apr 15 10:35:21 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Fri Apr 15 10:35:30 PDT 1994
Subject: Re: Questions About Real-time C++ VxWorks Embedded Systems

> Subject: Questions About Real-time C++ VxWorks Embedded Systems
> 
> We are contemplating using C++ (CenterLine C++ & gcc) with VxWorks in a VME
>   environment using 68030 or better.  Our application will make
>   heavy use of iostreams class library, NFS, sockets, etc.
> 
> Are there any developers who would like to share their experiences of
>   using C++ with VxWorks in a real-time environment?

OK.

> Can you brielfy describe your application(s)?

A fairly large and complicated medical application using the 68k.

> What were the severe gotcha's?

The file iostreams were broken in the beta of WindC++.  It reflected a bug in
the implementation of multiple inheritance (a lesson for those who want to use
multiple inheritance!).  I believe that the "V1.0" version is supposed to be 
fixed.  

See also the following.

> 
> Have you found the CenterLine/gcc/VxWorks development environment to be stable?

It feels like beta-ware, but it is stable enough.  We are avoiding multiple
inheritance, for safety.  Also, we decided not to use the template mechanism in cfront.  It is confusing, slow, and the error checking seems to be poor.  We
decided that it was too risky for our novice environment.  Your mileage may
vary....

> 
> What's been your experience with debugging the target using Vxgdb++ and
>   CenterLine on the target. Any gotcha's or insurmountable problems.
> 
It doesn't handle mangled names very well.  For example, you can set a break
point in a C++ function, but to actually "run func", you have to use the 
mangled version of the name.

Use ObjectCenter if you can.  It handles names better and its data display is
much better.  However, it is a resource hog, is a bit slow, and occasionally
crashes while debugging.

> Does the iostreams class library work as expected?
>
Except for the aforementioned bugs, yes.  Note that you have to "munch" the
streams library yourself to get "cout", "cin", etc. to work.  The WindC++
docs. don't make this requirement clear.  (I'm posting a separate note on 
"munching".)

> What 3rd party class libraries are you using?
>
None right now.  We didn't have the time to evaluate them, or the critical need.
However, our next round of development will address this issue.

On libraries, if you are thinking about using X, be warned that we had 
memory leak problems with "WindX", the Vxworks X library port.  We switched
to an X/Motif port from a company named "Visicom".
 
> Have you discovered any problems using 3rd party class libraries, i.e.:
>   re-entrancy or thread-safe issues, other?
>
Can't offer any help here.
 
> Has anyone ported or used RogueWave class libraries with VxWorks?
>
I would like to try this one myself.... 
> 

Another point, I don't know if speed of compilation and size of code is 
critical, but I think you pay a penalty in both areas if you use "cfront". 
I can't really say how big the "size" penalty is, but compile times aren't
speedy.

Hope this helps.  I think that I can safely recommend WindC++.  Plan on spending
some time figuring it out and getting it working.  Also, using ObjectCenter is
definitely recommended.  We try to test our code on the Sun before downloading
to the target.  On the Sun, you can at least use the full power of OC, while
only a subset is available on the Vxworks target.  Even there, it offers many
advantages over vxgdb.

Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|        "We begin bombing in five minutes...."  7:^]             |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+



From stan@rti.com  Fri Apr 15 11:23:47 1994
From: stan@rti.com (Stan Schneider)
Date: Fri Apr 15 11:23:56 PDT 1994
Subject: Re: Unloading .o files ?
>> Date: 14 Apr 1994 19:30:32 GMT
>> From: worrall@scrap.ssec.wisc.edu (Thomas Worrall)

>> Say I load a .o file
>> 
>> 	-> ld < DANGEROUS.o
>> 
>> and I run some DANGEROUS functions.  But then I want the system to
>> be wholesome and safe again.  Is there anyway to "unload" these functions
>> so some innocent passer by couldn't accidentally type in a DANGEROUS 
>> function and be maimed or worse?
>> 

Under VxWorks 5.1.x, you can use 'unld "DANGEROUS.o"' (or use the module id,
see "moduleShow").  Under 5.0.x, you can't unload the object & reclaim the
space, but you could remove the symbols from the symbol table with symRemove.
That would prevent unnecessary maiming.

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================


From daemon@vxw.ee.lbl.gov  Sat Apr 16 04:00:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr 16 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr 16 04:00:10 PDT 1994

        Subject: HDLC for the 85230
        Subject: dosFs questions

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

Newsgroups: comp.os.vxworks
Subject: HDLC for the 85230
Date: Fri, 15 Apr 1994 18:40:56 GMT
From: maillet@wrs.com (Al Maillet)
Organization: Wind River Systems, Inc.
Message-ID: <CoBD8A.AKt@wrs.com>

Hi,

Does anyone out there have an HDLC (synchronous) serial driver
written for the 85230 duart.  Any help would be greatly appreciated.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 

  Al Maillet                           al@wrs.com
  Wind River Systems, Inc.             Southwest Application Engineer
  8910 University Center Lane          Phone: (619)597-2477
  Suite 300                            Fax:   (619)558-8918
  San Diego, CA 92122-2477
- -- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 

  Al Maillet                           al@wrs.com
  Wind River Systems, Inc.             Southwest Application Engineer

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

Newsgroups: comp.os.vxworks
Subject: dosFs questions
Date: Sat, 16 Apr 1994 03:28:37 GMT
From: dfox@netcom.com (Don Fox)
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Message-ID: <dfoxCoC1np.K2L@netcom.com>

Has anyone been successful at getting floppies (formatted on a vxworks target)
to be readable on a PC running DOS 5.0?  The floppies will be read fine by
the target if they are formatted on the PC.  The configuration information
If I were to believe ndd, then the cause would be an invalid disk table
in the boot record.  When I looked at the disk via HEX edit, I noticed that
the media descriptor was 0x00 instead of 0xF0.  The media byte via the
dosFsConfigShow command was 0xf0.  I haven't looked at many of the other
bytes yet (only because I didn't have a handy reference for "DOGFS".) 
I plan to look into this further, however, I have to believe that this problem
has been encountered more than once!  

I would also like to format a harddrive and pass it between a PC and the 
target.  I realize there are some problems with this as well, but I have
to ask if anyone has successfully done this too.  

I am running a MV147 target under 5.1 with a TEAC SCSI drive.  I am using 
dosFsDevInit, and the FIODISKFORMAT, FIODISKINIT ioctl calls.  ( I can be 
more specific if need be.)

Any help would be appreciated.   Thanks in advance.

	-Don Fox (dfox@netcom.com)

Also: 	Does anyone have any information on the dosFsSysId and dosFsSysExtId
	commands?  I did see any docs or man pages for these.


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

End of New-News digest
**********************


From daemon@vxw.ee.lbl.gov  Sun Apr 17 04:00:19 1994
From: daemon@vxw.ee.lbl.gov
Date: Sun Apr 17 04:00:27 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Apr 17 04:00:11 PDT 1994

        Subject: re: FDDI Driver

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

Newsgroups: comp.os.vxworks
Subject: re: FDDI Driver
Date: Sat, 16 Apr 1994 19:35:21 +0000
From: pdg@samal.demon.co.uk (Paul Goffin)
Organization: Home
Message-ID: <766524921snz@samal.demon.co.uk>
References: <9404071616.AA20009@csg.lbl.gov>
Reply-To: pdg@samal.demon.co.uk
Sender: usenet@demon.co.uk

In article <9404071616.AA20009@csg.lbl.gov>
           rab@csg.lbl.gov "Robert Belshe" writes:

>We are using vxWorks 5.1  and will use a MVME166 processor for the
>FDDI.

>In this application, data will be sent from the VME data acquisition
>system ( via UDP multicast, if possible) to a small number of
>sparcStations located nearby.

>     Radstone Technology 5.1 driver with PME FDDI-1

We (Radstone) also have Solaris drivers for this card.  Handy
if you're using FORCE SPARC VME cards.  We're also close to
having a vxWorks BSP for the FDDI-1.

Paul  (working for, but not posting from Radstone Technology).
                                                              
- -- 
- ---
Paul D. Goffin   +    pdg@samal.demon.co.uk          +44 525 373931
                 +    my system; my opinions.

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

End of New-News digest
**********************


From visicom!VisiCom.COM!trest@lbl.gov  Sun Apr 17 08:14:56 1994
From: Mike Trest <trest@visicom.com>
Date: Sun Apr 17 08:15:06 PDT 1994
Subject: re: comp.os.vxworks newsdigest






> >      We're developing a Motif application for use under vxWorks, and we are
> > seeing crashes which look like they might be re-entrancy problems ...
> 
> I've never used X/Motif under VxWorks, so take this with a grain of salt
> (i.e., WRS may have an improved Motif).  But neither Motif nor the Xt




> Intrinsic library is reentrant, at least in their standard Unix form.

The VX-Windows product from VisiCom Laboratories provides a fully
"reentrant-safe" X and Motif.  The product is mature, having been
in the field for several years with both small project and large
OEM applications.  We have never had a reported corruption due
to the X or Motif libraries or from using the VX-Windows server.

> They're also synchronous -- you can't make Xt/Motif calls from within
> a signal handler, for example, due to lack of reentrancy.

You can with VX-Windows, however, a preferred design would be to keep
the interrupt or signal handler routine very small by simply setting
a flag or giving a semaphore which is acted upon by another task
outside of the interrupt context.  It could be done in signal 
handlers, it but should not be done in interrupt handlers.

> . ... .  The standard
> answer for "how do I update my display to reflect a real-time event?" is
> to use a TimeOutProc or WorkProc.  XtAppAddTimeOut and XtAppAddWorkProc
> can be called asynchronously, I believe.

Good answer, for UNIX.  In VX-Windows you can make any call almost anytime
when to do so would not violate common practice and rules of VxWorks.

The VX-Windows server and all provided X/Motif libs are VxWorks "safe".
Likewise, your client application programs automatically become
VxWorks "safe" when compiled with the VX-Windows provided Makefiles
and *.h files.  In fact, VX-Windows provides automatic protection for
closing all files and freeing all un-freed malloc's when you exit
your client or your client task aborts.  Yes, this even includes
the malloc's which X/Motif lib routines do internally without
your knowledge.

..mike..
====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================




From mea@mclean.sparta.com  Mon Apr 18 08:33:13 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Apr 18 08:33:24 PDT 1994
Subject: Re: Teac SCSI Floppy problems
Greetings!

> From: dfox@netcom.com (Don Fox)
> 
> Has anyone been successful at getting floppies (formatted on a vxworks target)
> to be readable on a PC running DOS 5.0?  The floppies will be read fine by
> the target if they are formatted on the PC.  The configuration information
> If I were to believe ndd, then the cause would be an invalid disk table
> in the boot record.  When I looked at the disk via HEX edit, I noticed that
> the media descriptor was 0x00 instead of 0xF0.  The media byte via the
> dosFsConfigShow command was 0xf0.  I haven't looked at many of the other
> bytes yet (only because I didn't have a handy reference for "DOGFS".) 
> I plan to look into this further, however, I have to believe that this problem
> has been encountered more than once!  
> 
> I would also like to format a harddrive and pass it between a PC and the 
> target.  I realize there are some problems with this as well, but I have
> to ask if anyone has successfully done this too.  
> 
> I am running a MV147 target under 5.1 with a TEAC SCSI drive.  I am using 
> dosFsDevInit, and the FIODISKFORMAT, FIODISKINIT ioctl calls.  ( I can be 
> more specific if need be.)
> 

We use these floppy drives all the time in my intermediate real-time 
training course wherein we use the floppies in both Sun and PC (MSDOG
5.0 and 6.X) drives as data exchange.  We set them up as boot devices
for VxWorks and make new boot roms, etc. as part of the class labs.
The secret is to program all of the page 1 parameters (about 32 Bytes 
worth) not just the page 0 (4 bytes).  I have a working driver that I'd 
be happy to send you if you're interested.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      


From daemon@vxw.ee.lbl.gov  Tue Apr 19 04:00:33 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Apr 19 04:01:09 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Apr 19 04:00:13 PDT 1994

        Subject: reboot entire vme crate?
        Subject: Re: reboot entire vme crate?
        Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]

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

Newsgroups: comp.os.vxworks
Subject: reboot entire vme crate?
Date: 18 Apr 1994 15:06:31 GMT
From: worrall@scrap.ssec.wisc.edu (Thomas Worrall)
Organization: Space Science & Engr. Ctr.
Message-ID: <2ou7ln$8f3@spool.cs.wisc.edu>
Reply-To: worrall@ssec.wisc.edu

We have several boards running vxworks in a vme crate.  Is there
anyway to make the master processor reboot the other boards remotely?

In fact when I reboot() just the master, I can no longer talk to the
other boards.  That doesn't seem right.  Am I doing something wrong.

Many thanks for your sage advice.

- -- 
Thomas Worrall				      Internet:    worrall@ssec.wisc.edu
Space Science and Engineering Center	      
1225 West Dayton			      Tel. 608-263-2566
University of Wisconsin, Madison 53706	      Fax  608-262-5974

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

Newsgroups: comp.os.vxworks
Subject: Re: reboot entire vme crate?
Date: Mon, 18 Apr 1994 21:53:42 GMT
From: ChatterjeeS@lfwc.lockheed.com (Shash Chatterjee)
Organization: Lockheed Fort Worth Company
Message-ID: <CoH65K.7Dq@butch.lmsc.lockheed.com>
References:  <2ou7ln$8f3@spool.cs.wisc.edu>
Reply-To: ChatterjeeS@lfwc.lockheed.com
Sender: news@butch.lmsc.lockheed.com

In article <2ou7ln$8f3@spool.cs.wisc.edu>, worrall@scrap.ssec.wisc.edu (Thomas Worrall) writes:
|> We have several boards running vxworks in a vme crate.  Is there
|> anyway to make the master processor reboot the other boards remotely?
|> 
|> In fact when I reboot() just the master, I can no longer talk to the
|> other boards.  That doesn't seem right.  Am I doing something wrong.
|> 
|> Many thanks for your sage advice.
|> 
|> -- 
|> Thomas Worrall				      Internet:    worrall@ssec.wisc.edu
|> Space Science and Engineering Center	      
|> 1225 West Dayton			      Tel. 608-263-2566
|> University of Wisconsin, Madison 53706	      Fax  608-262-5974

Check your CPU users manual.  The boards we use, Force CPU-30s, 31s, etc have
a jumper that selects whether RESET drives the VME RESET as well.

- -- 

+--------------------------------------------------------------------+
+ EMAIL: ChatterjeeS@lfwc.lockheed.com                               +
+--------------------------------------------------------------------+
+ Shash Chatterjee                                                   +
+ Electronic Systems Design & Integration                            +
+ Lockheed Fort Worth Company                                        +
+ P.O. Box 748, MZ1719       VOICE: (817) 763-1495                   +
+ Ft. Worth, TX 76101        FAX:   (817) 777-2115                   +
+--------------------------------------------------------------------+


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

Newsgroups: comp.os.vxworks,comp.answers,news.answers
Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]
Date: Tue, 19 Apr 1994 09:27:46 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded
Message-ID: <hjbCoI2AA.KqK@netcom.com>
Followup-To: comp.os.vxworks
Reply-To: hjb@netcom.com
Sender: hjb@netcom.com

Archive-name: vxworks-faq
Maintained-by: hjb@netcom.com
Last-modified: April 17, 1994
Version: 1.5

This is the list of frequently asked questions (and their answers) for
the newsgroup comp.os.vxworks. 

Where possible, pointers to existing information are included here, rather
than rehashing that information again.

If you haven't already done so, now is as good a time as any to read the
guide to Net etiquette which is posted to news.annouce.newusers regularly.
You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know
about smileys, followups and when to reply by email to postings.

The FAQ is currently posted to comp.os.vxworks, news.answers and
comp.answers on the 15th of every month.  

This FAQ was compiled by hjb@netcom.com using comments by readers of
comp.os.vxworks as well as his own limited knowledge of VxWorks.  Credits
appear at the end.  Comments and indications of doubt are enclosed in []s in
the text.  Each section begins with dashes ("-") on a line of their own,
then the section number.  This should make searching for a specific section
easy.

This FAQ is also available via anonymous ftp in:
	rtfm.mit.edu:/pub/usenet/news.answers/vxworks-faq.Z
	ftp.uu.net:/usenet/news.answers/vxworks-faq.Z 
	cs.toronto.edu:/pub/usenet/comp.answers/vxworks-faq.Z
	netcom.com:/pub/hjb/vxfaq.gz

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

		TABLE OF CONTENTS

	1. What is VxWorks? 
	2. Brief History of VxWorks
	3. What are some of the major features of VxWorks?
	4. What are the Latest versions of VxWorks?
	5. Where is the archive site for user-contributed code?
	6. What application notes are available from Wind River?
	7. How can I join the VxWorks user's group?
	8. Is comp.os.vxworks also available via a mailing list?
	9. Can I use gcc or g++ with VxWorks?
	10. Other C/C++ Compiler tools for VxWorks?
	11. Which cross-debuggers can I use with VxWorks?
	12. What are differences between traditional UNIX and VxWorks?
	13. What are the performance/benchmark numbers for WIND kernel?
	14. What are the performance/benchmark numbers for VxWorks TCP/IP?
	15. What is the VxSim VxWorks Simulator?
	16. Can I use one boot EPROM for multiple boards on the same net?
	17. What's the deal with 68881 FPU code in interrupt handlers?
	18. Why does ls() not work on netDrv devices?
	19. Why can't I do ".." at top level directories or NFS mount points?
	20. Why do I have trouble using relative symbolic links with NFS?
	21. X for VxWorks
	22. IEEE-488 (GPIB) driver for VxWorks
	23. How does one disable NFS client caching?
	24. Why doing a lot of slipInit()/slipDelete() cause routing 
		table corruption?
	25. How does one get better network I/O performance?
	26. How does one troubleshoot a backplane driver malfunction?
	27. How do I add select support to my driver?
	28. bind() gets EADDRINUSE, how do I fix it?
	29. Common errors in interrupt handlers with floating point 
		co-proc hardware
	30. Finding entry point of a given module using its name
	31. The problem with irint() in earlier (5.0.2 ?) releases
	32. What are +T, +I thingies in the "i" output?
	33. Gotchas w.r.t watchdogs
	34. Is it possible to delete a memory partition in VxWorks?
	35. rename() does not work in netDrv and nfsDrv filesystems, why?
	36. Free NFS Server for VxWorks
	37. Free SNMP for VxWorks
	38. What third party products are available for VxWorks?
	39. What kind of products have been developed using VxWorks?
	40. A complete list of CPU hardware supported by VxWorks
	41. A complete list of peripheral devices supported by VxWorks
	42. What's with these unbundled "accessories"?
	43. How come my 5.0.2 BSP isn't available in 5.1, damn it?
	44. How much is VxWorks?
	45. What is MicroWorks?
	46. Other Unbundled Products for VxWorks?
	47. How can I find out more about VxWorks?
	48. What other net.resources are available on real-time systems?
	49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?  
	50. Free lex and yacc for use with VxWorks
	51. timer_gettime() bug
	52. bogus INCLUDE_TCP_DEBUG
	53. free ppp for VxWorks
	54. how to disable cache on mc68040 or mc68030 using TT regs?
	55. work-arounds for ms-dos filesystem bug when lseek() past eof
	56. TCL for VxWorks
	57. adding default route
	58. adjusting network driver MTU size
	59. tcpdump like utility for vxworks
	60. VxWorks performance on i960 -- unofficial benchmark
	61. VxWorks SCSI Performance -- unofficial benchmark
[new]	62. VME bus arbitration gotchas
[new]	63. 5.1.X new MMU supporting code gotchas, as explained in the Manual
[new]	64. "Cannot Boot. Error 0x1a9" while downloading/booting
[new]	65. problem with qsort in some versions of VxWorks
[new]	66. fmod fiasco
[new]	67. MVME167 copyback cache and various problems
[new]	68. unloading objects
	9999. Contributions to comp.os.vxworks FAQs.

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

1. What is VxWorks?

VxWorks, from Wind River Systems, is a networked real-time operating
system designed to be used in a distributed environment.  It runs on a
wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel
i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems. 
It requires a host workstation for program development; supported host
platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS. 

It does not run development systems software such as compiler, linker
and editor on the target machine.  The development environment is based
on cross-development or remote-development method.  You will need a
UNIX machine of some sort (e.g. SUN's) to run the compilers and
debuggers.  The compiled application code can be downloaded to the
target and runs as part of the VxWorks image.  During the development
phase or thereafter, individual object code (.o files) can be
downloaded dynamically to running target system.  Finished applications
can be ROM'ed or whatever.

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

2. Brief History of VxWorks

Based on what I have heard from David Wilner and others, WRS was
started by Jerry Fiddler and David Wilner in Jerry's garage as a
contract/consultant shop for realtime, embedded systems and other fun
things.  Francis Coppola was one of the earlier customers.

They wrote a bunch of neat programs for their work and found that they
liked them a great deal themselves, and added more excellent features
to the system, eventually adding some things unheard of in
embedded/realtime market in those days such TCP/IP networking. And
continued to pioneer in this area by adding NFS, etc.

VxWorks was the name given the collection of software which ran on
top of various realtime kernels including VRTX and pSOS as well an
earlier slower version of WIND kernel.  [ editorial:
VxWorks no longer runs on other kernels; it now runs exclusively on 
its own WIND kernel since the 5.0 release, for which the WIND was 
rewritten by John Fogelin. ]

They got more people interested in the system and became successful.
And moved from a little building in Emeryville to a larger one. And
eventually to the present site in Alameda.  And hired a  lot of people.
 
WRS sold many many more copies of this system and continues to grow
like a real successful company.

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

3. What are some of the major features of VxWorks?

In Version 5.1:

 - wind kernel unlimited tasks
 - 256 priorities
 - binary, counting mutex semaphores
 - message q's
 - POSIX pipes
 - sockets
 - shared memory
 - profiling utilities
 - ethernet support (i596, LANCE, NIC, SONIC)
 - SLIP (no PPP yet)
 - backplane driver for network
 - rlogin (server & client)
 - telnet (server only)
 - rpc (no rpcgen)
 - nfs (client)
 - ftp (server & client)
 - tftp (client & server)
 - rsh
 - bootp
 - proxyarp
 - C-interpreter shell (incomplete but useful)
 - symbolic debugging
 - disassembly
 - performmance monitoring tools
 - exception handling
 - signal handling (not quite UNIX compatible)
 - dynamic object image loader
 - system symbol table
 - system info utilities
 - libraries of 600+ utility routines
 - remote source level debugger(VxGDB)
 - SCSI support
 - DOS & RT11 & Raw filesystems.
 - "full ANSI"
 - "POSIX I/O"

It is a good idea to get a copy of VxWorks manuals before purchasing
the system.  WRS can provide you with such documentation.  As far as I
know there is no "VxBook" in the bookstores.

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

4. What are the Latest versions of VxWorks?

As as of June 1993,

     5.0.3.: TRON will be discontinued.
     5.0.3 : i386
     5.0.5 : r3000
     5.1   : 680x0, 683xx, i960, SPARC
     i386 and r3000 will be upgraded to 5.1.

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

5. Where is the archive site for user-contributed code?

The VxWorks archive system is available for FTP as thor.atd.ucar.edu.
It is also accessible via email server at vxworks_archive@ncar.ucar.edu.
Questions should be directed to its maintainer, Richard Neitzel
<thor@thor.ucar.edu>.

To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix

A summary of the archives is periodically posted to comp.os.vxworks.

Some of the usual titles available:

ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench
cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress
flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2
lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe
poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod
tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar
vxtool, vxview, xc

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

6. What application notes are available from Wind River?

  List of Wind Technical Notes

 Motorola MV147 Slave Base Control       9-1
 System hang during lkup( ) output       10-1
 Reserving Memory                        11-1
 Serial IO Vanishing                     13-1
 NFS: problems with writing files        14-1
 Which interrupts does VxWorks use?      15-1
 Debugging ftp problems                  18-1
 Interrupt handlers, floating point      19-1
 Booting From a Memory Board             22-1
 Changing Network Interfaces             23-1
 Writing Non-buffered Sockets            24-1
 RPC and VxWorks                         25-1
 Using SCSI devices with VxWorks 5.x     26-1
 The Select Facility in VxWorks          28-1
        Using on-board Serial Ports  	 29-1
        Problems with ls()   		 30-1
 SCSI     				 31-1
 Trouble Shooting Booting Problems       32-1

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

7. How can I join the VxWorks user's group?

For User Group info contact WRS or Eric Rabinowitz of Panoramic Systems at:

 elr@netcom.com   or  ericr@wrs.com 
 phone: 408-289-7757

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

8. Is comp.os.vxworks also available via a mailing list?

Lawrence Berkeley Labs maintains an automated mailing list which is
bi-directionally gatewayed to comp.os.vxworks

It is called the 'VxWorks Exploder'.

Mail to vxwexplo@lbl.gov is automatically mailed to a number
of sites, including Wind River.

Send subscription request to vxwexplo-request@lbl.gov.

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

9. Can I use gcc or g++ with VxWorks?

WRS's gcc GNU Toolkit distribution can be reshipped in its entirety. 
WRS charges are for media and support, so obviously copies thereof
don't matter to them.

Lots of customers use g++ as provided by the "net" --
see the VxWorks Archive information below.

You can get a generic freely distributable GCC/G++ and compile your
code for VxWorks.  Or you can just get a copy from someone who has a
working GCC cross-development setup from WRS.

WRS worked with Cygnus to polish up their release of GCC but a generic
GCC distribution works just fine as well.

For MC68K targets:
 You can also use native SunOS 4.X cc running on Sun-3's.
 You can also use various other free m68k C compilers
 such as lcc, sozobon, etc. provided that you're willing
 to hack on them.

Richard Neitzel (thor@thor.atd.ucar.edu) writes,

Thanks to some feedback I've corrected the archive instructions on how to
build gcc, libgcc and libg++ for VxWorks. To make my life simpler the
patches referenced are no longer included in the vx_cplusplus file. Instead
there are now seperate patch files for the effected parts:

libg++-2.5-src.patch: Patches libg++/src.
libgcc2-2.5.0.patch: Patch libgccc2.c for gcc-2.5.0.
libgcc2-2.5.2.patch: Patch libgcc2.c for gcc-2.5.2.
libio-2.5.patch: Patch the stream library.

See VxWorks Archive information in this FAQ for details on how to 
get these files.

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

10. Other C/C++ Compiler tools for VxWorks?

WRS re-sells (re-engineered?) CenterLine cfront product and WindC++
Gateway for CenterLine ObjectCenter. They come with browsers, etc. 
Not free.

Wind C++ Gateway for ObjectCenter sold by WRS:

$995 / user 1-4 copies
$875 / user 5-9 copies

Note that this is the cost over and above ObjectCenter.

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

11. Which cross-debuggers can I use with VxWorks?

GDB & other more expensive tools from WRS, MicroTec Research, etc.

WRS sells a lightly modified version of xxgdb which has a lousy GUI
interface.  In 5.1 xvxgdb may have been slightly improved -- but the
ObjectCenter C++ with VxWorks solution provides better GUI interface.
      
With a little bit of hacking, regular GDB works just fine.  Personally,
I find GUI to a debugger gets in the way of real work.  I use GNU Emacs
GDB interface which works well and can be easily customized.

There might be some old VxWorks customers that also use VxWorks-aware 
dbxtool on Sun machines.  This used to be maintained and sold by SUN
Consulting.

If you're only interested in debugging your "application" on VxWorks,
the vxgdb approach (using RPC) works just fine.

If you are rather more interested in the guts of the system as well as
your application you might want to spend some time building
cross-debugging tools from generic GDB distribution into VxWorks.

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

12. What are differences between traditional UNIX and VxWorks?

They're both hacks.  UNIX has a larger installed base. :-)

Seriously though, similarities end there, IMHO.  VxWorks does have a
lot of UNIX "compatible" routines in the user libraries.  So porting a
UNIX application is not that hard.  But there are enough differences to
make such a port take longer than normally expected.

VxWorks runs in one mode.  No protected vs. user mode switching is
done.  Running in supervisor mode on most processors, and not using
traps for system calls, VxWorks can achieve minimal overhead on a given
piece of hardware than UNIX.  Programming on VxWorks can be more tricky
than UNIX for the same reason.

UNIX provides resource reclamation; by default, VxWorks does not.  [
editorial: using deleteHooks or whatever, you could implement this on
your own.]  Instead programmers write what they need as needed.  As a
result, the context switch time in VxWorks is on the order of a few
micro-seconds (since there is a lot smaller context to save and
restore). VxWorks does not have full "process"; it only has tasks, or
"threads", or light weight processes as some people like to call them.

Like any other multi-threaded environments (or MP environments), care
should be taken when writing multi-tasking code.  Each routine should
be written carefully to be re-entrant (if it is going to be called from
multiple contexts), semaphores are used a lot for this. And static
variables are frowned upon.  Sometimes, when porting a UNIX
application, you may need to add "task variables" for this reason (as
done for rpcLib in VxWorks).

VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented
as semaphores).  Traditional UNIX: high interrupt latency (e.g. spl's
are implemented as interrupt lock and unlock calls).

VxWorks: priority interrupt-driven preemption, optional round-robin
time-slicing.  Traditional UNIX: prioritized round-robin preemptive
time-slicing.  Since VxWorks is just a glorified "program" it can be
changed and customized pretty easily.  Task scheduling can be
customized as desired, for example.

VxWorks networking code, however, is very UNIX compatible [editorial:
it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe
release ].  It is relatively easy to port socket based code to
VxWorks.  [ editorial: except the not-so-compatible hostLib routines,
etc.]

VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX
as often misunderstood by some people.  The confusion perhaps is due to
the fact that UNIX hosts are used most widely to develop applications
for VxWorks (and VxWorks itself).

There are a lot more differences!  In short, UNIX is a nice system to
run emacs on.  VxWorks is much better at playing pin-ball game
machines.

Having said all this, I should also note that there are Realtime capable
UNIX systems out there.  Most of these systems do not come close to
the capabilities and performance of VxWorks in realtime processing.
An exception to this might be QNX, which is a very well designed
Realtime POSIX operating system.  

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

13. What are the performance/benchmark numbers for WIND kernel?

A WRS VxWorks 5.1 Benchmark Report hot off the press:

Benchmark numbers based on: mv167-25Mhz, 5.1

						        Cache	Cache 
Key Measurements        				Enabled	Disabled

Raw Context Switch Time 				4 us    14 us
Cyclic Test Time        				172 us  638 us
Suspend/Switch/Resume/Switch    			23 us   86 us

Kernel Timings

Task Related
taskSpawn       					124 us  370 us
taskInit        					58 us   181 us
taskActivate    					12 us   33 us
taskDelete      					101 us  303 us
Task Create / Delete    				249 us  684 us
taskLock
        CASE 1: no lock 				3 us    4 us
        CASE 2: lock exists     			2 us    5 us
taskUnlock
        CASE 1: no lock 				2 us    12 us
        CASE 2: lock exists     			5 us    6 us
taskSuspend
        CASE 1: ready task      			11 us   30 us
        CASE 2: pended task     			9 us    19 us
        CASE 3: suspended task  			8 us    19 us
        CASE 4: delayed task    			9 us    19 us
taskResume
        CASE 1: ready task      			6 us    19 us
        CASE 2: pended task     			10 us   19 us
        CASE 3: suspended task  			13 us   30 us
        CASE 4: delayed task    			9 us    18 us

Semaphore Related
semBCreate      					66 us   152 us
semCCreate      					46 us   150 us
semMCreate      					45 us   139 us
semDelete
        Binary  					49 us   157 us
        Counting        				49 us   163 us
        Mutual Exclusion        			48 us   157 us
semGive
        CASE 1: tasks in queue  
        Binary  					18 us   44 us
        Counting        				20 us   46 us
        Mutual Exclusion        			25 us   59 us
        CASE 2: no tasks in queue       
        Binary  					4 us    8 us
        Counting        				5 us    11 us
        Mutual Exclusion        			6 us    15 us

semTake
CASE 1: semaphore available     
        Binary  					4 us    9 us
        Counting        				5 us    11 us
        Mutual Exclusion        			5 us    13 us
        CASE 2: semaphore unavailable   
        Binary  					10 us   25 us
        Counting        				11 us   27 us
        Mutual Exclusion        			4 us    12 us
Semaphore Give / Take
        Binary  					7 us    15 us
        Counting        				9 us    21 us
        Mutual Exclusion        			10 us   26 us
semFlush
        Binary  					11 us   20 us
        Counting        				11 us   20 us
        Mutual Exclusion        			10 us   16 us

Miscellaneous Operating System Timings

Message Queue Related
msgQCreate      					93 us   280 us
msgQDelete      					71 us   229 us
msgQSend
        CASE 1: task pending    			39 us   102 us
        CASE 2: no tasks pending        		23 us   64 us
        CASE 3: queue full      			14 us   45 us
msgQReceive
        CASE 1: message available       		20 us   62 us
        CASE 2: message unavailable     		15 us   41 us

Memory Related
malloc  						28 us   81 us
free            					32 us   104 us

Watchdog Related
wdCreate        					42 us   106 us
wdDelete
        CASE 1: timer started   			48 us   160 us
        CASE 2: timer not started       		44 us   150 us
wdStart
        CASE 1: timer in queue  			20 us   70 us
        CASE 2: no timer in queue       		18 us   55 us
wdCancel					        11 us   34 us

Floating-Point  
robot application       				18 sec  51 sec

[ editorial:
If you care enough to count pico-seconds in comparing realtime
kernels, you  might want to actually get each of the evaluation copies
from various vendors and test them yourself.  But remember benchmarks
are misleading and almost always biased and inaccurate.  Given similar
benchmark numbers, give or take a few microseconds, etc., your dollars
are better spent in getting something you'll enjoy using. ]

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

14. What are the performance/benchmark numbers for VxWorks TCP/IP?

According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet)

				 w/ cache 	 w/o cache enabled
 TCP/IP Throughput (KB/sec)      859 KB/sec      682 KB/sec

No numbers available on latency.

Using a reasonably fast processor 25Mhz MC68040 and a reasonably well
made ethernet chip like SONIC or LANCE put together on a reasonable board
design will achieve TCP throughput close to full bandwidth of ethernet.

[ editorial:
This, of course, is rather slow in comparison with other fast
implementations, since a 16Mhz MC68020 with onboard LANCE 
or a PeeCee with an ethernet board can easily do the same.
I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC
that does: 1170KB/sec.  ]

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

15. What is the VxSim VxWorks Simulator?

Propaganda from WRS:

 It really is VxWorks running under UNIX!  So sure it
 is not realtime, although all tasks and resources interact
 in the same way -- great for prototyping "high-level" code.
 Using the simulator saves wear and tear on h/w.  It (only)
 allows sytem level debugging with native GDB.

 Portably written object code compiled for VxSim (for SunOS SPARC)
 will usually load without recompilation on a SPARC target.  And,
 BTW under 5.1 switching from one architecture to anthoer really is
 pretty painless.

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

16. Can I use one boot EPROM for multiple boards on the same net?

WRS provides EPROMs with a default bogus bootline, virtually all
boards come with non-valiatile RAM which is set as soon as the user
fills in his parameters (which include CPU #).  Therefore 1 EPROM may
be duplicated and used in all boards at a site.  If the board does not
contain nvram then ROMs have to be specially blown, unless a custom
scheme for reading some switches or something is coded to index into a
bootline table.  In 5.1 BOOTP is supported -- no more repeated EPROM
burning is necessary.

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

17. What's the deal with 68881 FPU code in interrupt handlers?

In general, FP context is optimally saved only when the scheduler
notices that the new task coming in also uses the fpu (VX_FP_TASK).
ISRs don't.  If no tasks are using the FPU then ISRs may go ahead,
unless different levels of ISRs could interrupt each other and again
cause a protocol violation.

And Stan Schneider says,

You have to set the "VX_FP_TASK" option flag when you spawn your task.  You
also need to make sure you don't use the FPU in any interrupt service
routines.  Even if your code uses no floating point, some (brain-dead)
compilers save some FPU registers at the start of all routines if there's any
floating point in the file.  That's not usually a problem if you're using the
gcc compiler (at least with the "-O" flag on).  A sure way to check is via the
dissassembler.

And Leonid Rosenboim says,

This problem is quite common, and really simple to fix, all you have to
do is make sure that all tasks that do a float operation ever, will
be spawned with the VX_FP task option set. This is the best and only
solution. Also, if you run floating operations in ISRs care must be taken,
to call fppSave() and fppRestore(). Also if you are using 5.1 on a 68040,
there is a bug in the compiler that you must work around:

	If you write an ISR that uses float instructions, it is not
	enougth just to call fppSave()/fppRestore(), since the compiler
	for 68040 inserts FP instructions BEFORE your first line
	of C code, hence you need to write a dummy ISR that:

 	dummyIsr()
	{
		fppSave( .. );
		yourRealISR();
		fppRestore( ... );
	}

And Kent Long says,

This was indeed a real problem in the context switch code in 5.0.x which
was corrected in 5.1.

In both OS versions, there is an optimization that causes the FP context
to be swapped only when the incoming task has been spawned with the
floating point (VX_FP) flag set.  In 5.0.x, the copying-in of the FP context
was done via an fppSave() call.  This created problems if a new FP
task was created after a previous FP task had been pre-empted by a non-FP
task in the middle of an instruction.  The new task ended up with a 
mid-instruction context (which causes the protocol violation), and the 
old swapped-out FP task ultimately ended up with its context set to IDLE 
(which is equally incorrect).

In 5.1, the FP context initialization was changed so that when a task
is created, a pre-defined IDLE frame is copied into that tasks's context.
Since there is no assumption about current FP state (as with fppSave),
task creation is now decoupled from the regular switch logic.


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

18. Why does ls() not work on netDrv devices?

Because the way directory information retrieval IOCTL calls are not acompatible
between different types of "filesystems" in VxWorks.  Another reason why
some think VxWorks filesytem does not exist; they're just a collection of
ioDevice drivers, and there is not a real consistent "design" to it.

The lsOld() should work on "filesystems" that does not support ls().

Chuck Mead proposes the following special routine in case lsOld() does not
work for you:


#include "vxWorks.h"
#include "bootLib.h"

#define RSHD 514

STATUS lsHost(path)
   char  *path ;
{
   char *lsString;
   int dataSock ;
   int n ;
   char nextChar ;

   extern BOOT_PARAMS sysBootParams ;
   extern char *sysBootHost ;

   if (path == (char *) NULL)
   {
      lsString = (char *) malloc(4) ;
      strcpy(lsString, "ls") ;
   }
   else
   {
      lsString = (char *) malloc(strlen(path) + 5) ;
      sprintf(lsString, "%s%s", "ls ", path) ;
   }

   dataSock = rcmd (sysBootHost, RSHD, sysBootParams.usr,
        sysBootParams.usr, lsString, (int *) NULL) ;

   if (dataSock == ERROR)
   {
      printf("Error opening socket") ;
      return (ERROR) ;
   }

   n = fioRead(dataSock, &nextChar, 1) ;
   while (n == 1)
   {
      printf("%c",nextChar) ;
      n = fioRead(dataSock, &nextChar, 1) ;
   }

   close(dataSock) ;
}

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

19.  Why can't I do ".." at top level directories or NFS mount points?

Because, again, VxWorks does not really have a "filesystem" as most people
understand it.  The top level directories are just implemented as device
driver "node", which is used to identify the ioDev associated with the
specific VxWorks "filesystem".  Since there is no underlying filesystem
layer, the story ends there.  When you're at the top of the directory
hierarchy within a given ioDev/filesytem, you simply cannot do "..".

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

20. Why do I have trouble using relative symbolic links with NFS?

See [Q: Why can't I do ".." at top level directories or NFS mount points?]
above.  This is just another problem caused by the fact that a real filesystem
does not exist for VxWorks.  NFS client implementation actually does implement
the symbolic links correctly, using lookup and readlink.  The problem is
due to the fact that, for some relative links that use ".." or whatever, that
crosses over filesystems, VxWorks cannot have underlying subsystem that will
handle file pathname to device mapping.  

Using absolute symbolic links work just fine (i.e. full path name from top).

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

21. X for VxWorks

WRS has a product called windX which supports Motif. There is also
libX11 contribution in the VxWorks Archive. This package is perhaps
fairly old and out of date. Essentially, to port X stuff to VxWorks
you'll need to do make sure code is re-entrant everywhere.  There is a
"multi-thread" safe version of Xlib available somewhere on the net, one
might try porting that.  There are also vendors that have built X servers
using VxWorks.  Jupiter Systems, in Alameda, makes high-end X server
machines based on VxWorks.  Other X terminal vendors (HP?) also use VxWorks.

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

22. IEEE-488 (GPIB) driver for VxWorks

 - National Instruments has lots of GPIB stuff
 - THEMIS computers has TSVME-409 whic hincludes a GPIB interface.
 - APLABS probably has some GPIB stuff too.

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

23. How does one disable NFS client caching?

VxWorks caches read and write requests in NFS client code.
To completely disable read and write cache, set nfsCacheSize to 0.
To just flush the write cache as needed, use nfsCacheFlush() or
FIOSYNC ioctl().

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

24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption?

This is due to a bug in slipDelete() and/or if_dettach().  slipDelete()
calls if_dettach() to clean up after itself (SLIP network interface driver).
Not only is if_dettach() misspelled, it also doesn't do a complete job.
One deficiency is that it does not delete routes that are pointing to the
interface being deleted.  This is remedied via another function that deletes
all routes for a give netif device driver.  [ ifRouteDelete() ??? ]
slipDelete() does call this routine to delete routes.  Another problem is
that if_dettach() does not delete a pointer to the netif device driver 
structure in the global in_ifaddr linked list.  The in_ifaddr list is
used by the network kernel code to find IP addresses of available network
interfaces, among other things.  This lack of proper cleanup turns out to 
be a rather hard-to-find memory corruption problem in network code, and
usually manifests itself as routing table corruptions.

To fix this add the following routine, and call it right after calling
slipDelete:

void in_ifaddr_remove(ifp)
        struct ifnet *ifp;  /* ifp = ifunit("sl0") before slipDelete() called */
{
        struct in_ifaddr *ia, *prev_ia;
 
        if (!ifp) 
                return;
 
        prev_ia = 0;
 
        for (ia = in_ifaddr; ia; ia = ia->ia_next) {
                if (ia->ia_ifp == ifp) {
                        if (prev_ia)
                                prev_ia->ia_next = ia->ia_next;
                        else
                                in_ifaddr = ia->ia_next;
                        return;
                }
                prev_ia = ia;
        }
}

This, along with the route cleanup, should be incorporated into if_detach().

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

25. How does one get better network I/O performance?

Most of the overhead is due to socket to network core interface overhead.
The copy that happens between the socket layer and network core code
can be avoided by using the routines in uipc_socket.c (as in BSD tahoe
release code available on various archive sites) and using mbufs directly.

You can also try using raw etherLib routines.  However, etherLib also
does copying between user application and network driver.

If you must use the socket interface (sockLib), make sure you tune the
socket level buffers sizes to optimal values using setsockopt() calls
SO_SNDBUF and SO_RCVBUF.  You might also just try changing the globals
that control the following default parameters to larger numbers (all
the way upto 48K):

 tcp_sendspace (default 4K)
 tcp_recvspace (default 4K)
 udp_sendspace (default 2K)
 udp_recvspace (default 4K)

To get around extra latency in some cases, you might turn on TCP_NODELAY
option on TCP sockets.

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

26. How does one troubleshoot a backplane driver malfunction?

There are a few rules of thumb:

 1) Try the simplest case first -- use polling instead of
	bus or mailbox interrupts and software test-and-set
	instead of hardware test-and-set.  See if this
	works first.  And then try hardware test-and-set
	and then the desired mailbox or bus interrupt.

 2) Use bpShow() to see what's up.  Also look for magic code
	0x1234 in share mem area being used for messages,
	and verify heartbeat is being incremented.
	At the "anchor" you should see the magic code (4 bytes)
	followed by a long word which should be incrementing (the
	heartbeat) every second.

 3) Verify all memory mapping and make sure there's no
	address conflicts on the bus, and the anchor area is
	properly set up.  If the anchor and ring buffer area
	is on a CPU, make sure the sysLib.c:sysHwInit()
	does the right thing to allow access to on-board memory
	by other CPU's in the chassis.  Be careful, as some
	VxWorks BSP's turn off on-board memory access by other CPU's
	if the CPU is not processor 0.  This should be changed
	if your anchor CPU is not processor 0 (first CPU in
	VME chassis/backplane) -- this is a boot time configuration 
	parameter [ based on the assumption that bpInit() will be done
	by the processor 0 ].

 4) Make sure bus controller is functioning properly.
	Some combinations of boards might not work well
	especially if your system controller board
	arbitrates the bus in one way and other boards
	expect to be arbitrated in a different way.
	Sometimes you might need to use a separate
	system controller.  Of course, also make sure
	you only have one bus master.  And that your VME
	bus strappings (BREQ, IACK daisychains) are right.

 5) Call Wind River's VxWorks tech-support... 

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

27. How do I add select support to my driver?

#include "selectLib.h"
...

xxx_init(...)
{
	 ...
	 selWakeupListInit(&xxxdev->selwakeupList);
	 ...
}

xxx_ioctl(...)
{
	 ...
	 switch(request_type) {
	 ...
	 case FIOSELECT:
		  selNodeAdd(&xxxdev->selwakeupList,
			   (SEL_WAKEUP_NODE *)request_arg);
		  if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD)
			   && readable_condition_is_met)
			   selWakeup((SEL_WAKEUP_NODE*)request_arg);
		  if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE)
			   && writable_condition_is_met)
			   selWakeup((SEL_WAKEUP_NODE*)request_arg);
		  break;
	 ...
	 case FIOUNSELECT:
		  selNodeDelete(&xxxdev->selWakeupList,
			   (SEL_WAKEUP_NODE*)request_arg);
		  break;
	 ...
	 }
}

And, add calls to selWakeup() as appropriate in your interrupt handlers
and read/write routines as selective conditions are toggled or satisfied.

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

28. bind() gets EADDRINUSE, how do I fix it?

Fix: do setsockopt() SO_REUSEADDR

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

29. Common errors in interrupt handlers with floating point co-proc hardware

Don't forget to use:
 fppSave()
 fppRestore()

Interrupt handler encapsulation code doesn't always save fpp registers for you.

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

30. Finding entry point of a given module using its name

Example from a poster in vxworks newsgroup (who?):


 FUNCPTR  start;  /* found entry point goes here */
 UINT8    symType;
 int      tid;

 if(symFindByName(sysSymTbl,"_nlos_start",(char**)&start,&symType)==OK){
	/* taskSpawn(name,priority,options,stacksize,entryAddress,arg1,..) */

	tid = taskSpawn("nlos",TASK_PRI_NLOS,SPAWN_OPTS,STACK_SIZE_NLOS,start,
	arg1,arg2,.....);
 }

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

31. The problem with irint() in earlier (5.0.2 ?) releases

The problem:

 /* Include Files */
 #include "vxWorks.h"
 #include "math.h"

 long irint_count = 0;

 sinTest()
 {
	  int sinTable;
 
	  while(1)
	  {
		   sinTable = irint(sin(4./1024.*(2.*3.14))*10.);
		   irint_count++;
	  }
 }


 % cc68k -I/vxworks/vw/h -c sinTest.c

 -> ld < sinTest.o

 /* 0x08 Option = VX_FP_TASK within taskLib.h */
 -> taskSpawn ("sinTest", 100, 0x08, 4000, sinTest)
 /* OR without the Floating Point Option */
 -> sp sinTest

 -> irint_count

 Bus Error
 Program Counter: 0xb0ac0124
 Status Register: 0x3004
 Access Address : 0xb0ac0120
 Special Status : 0x01e6
 Task: 0xfcb82c "sinTest"

The answer:

Submitted-by wrs!yuba!kent@uunet.uu.net  Fri Sep 27 18:55:25 1991
Submitted-by: wrs!yuba!kent@uunet.uu.net (Kent Long)

 > In the function irint, there is a bug that sets the floating point
 > Exception enable byte register to random values.  Here is the
 > disasembled code:
 >
 >                         _irint:
 > 00e034  4e56 0000                LINK  .W    A6,#0
 > 00e038  f227 6b80                FMOVE .X    F7,-(A7)
 > 00e03c  f22e 5780 0008           FMOVE .D    ($8,A6),F7
 > 00e042  f22e 6380 0008           FMOVE .L    F7,($8,A6)
 > 00e048  202e 0008                MOVE  .L    ($8,A6),D0
 >
 > 00e04c  f201 9000                FMOVE .L    D1,#<FPCR>

<insert audible groan here>

 > 00e050  504f                     ADDQ  .W    #8,A7
 > 00e052  4e5e                     UNLK        A6
 > 00e054  4e75                     RTS
 >
 >    Line 0e04c is the line that sets the FPCR to some random value,
 > as D1 is unknown going into the function.  I rewrote the routine,
 > without line 0e4c, and everything works fine.
 >    If anyone out there knows why this line was put in, I would
 > appreciate knowing.  Hope this may keep someone else from spending
 > a couple of days tracking down this problem.
 
I have confirmed that this is a bug in all 5.x versions of VxWorks for
the 68k.  (In fact, it's in 4.0.2 as well.)  As Mark correctly observed,
the problem is that the FPCR register is erroneously being set.
 
This was a simple cut-and-paste error in the VxWorks source module.
The line which sets the FPCR should instead be restoring the value
of FP7, which was saved on the stack earlier (as you can see in the
code above).  So, it would appear that another side effect of this
bug is to clobber FP7.
  
The fix is pretty simple.  The following patch scripts should get things
back to what they should be.  (You can just include the appropriate lines
in your startup script, or enter them from the VxWorks shell.)
 
For VxWorks 5.0.1 and 5.0.2:
 
        pMathPatch = mathHardIrint + 0x18;
        *pMathPatch = (short) 0xf21f;
        pMathPatch = mathHardIrint + 0x1a;
        *pMathPatch = (short) 0x4b80;
 
This bug does NOT affect VxWorks 5.1.  The disassembled code for Vx5.1,
(HK68K/V3D) is:
                        _mathHardIrint:
2042e58  4e56 0000                LINK  .W    A6,#0
2042e5c  f227 6800                FMOVE .X    F0,-(A7)
2042e60  f22e 5400 0008           FMOVE .D    (0x8,A6),F0
2042e66  f22e 6000 0008           FMOVE .L    F0,(0x8,A6)
2042e6c  202e 0008                MOVE  .L    (0x8,A6),D0
2042e70  f21f 4800                FMOVE .X    (A7)+,F0
2042e74  4e5e                     UNLK        A6
2042e76  4e75                     RTS

Kent Long further clarifies,

This was indeed a real problem in the context switch code in 5.0.x which
was corrected in 5.1.

In both OS versions, there is an optimization that causes the FP context
to be swapped only when the incoming task has been spawned with the
floating point (VX_FP) flag set.  In 5.0.x, the copying-in of the FP context
was done via an fppSave() call.  This created problems if a new FP
task was created after a previous FP task had been pre-empted by a non-FP
task in the middle of an instruction.  The new task ended up with a 
mid-instruction context (which causes the protocol violation), and the 
old swapped-out FP task ultimately ended up with its context set to IDLE 
(which is equally incorrect).

In 5.1, the FP context initialization was changed so that when a task
is created, a pre-defined IDLE frame is copied into that tasks's context.
Since there is no assumption about current FP state (as with fppSave),
task creation is now decoupled from the regular switch logic.

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

32. What are +T, +I thingies in the "i" output?

The following is an excellent description of all these symbols by many people
on the net, including "Fred J. Roeber" and others:

Description                                 Status symbol
=====================================       ===============
<blah> and task's priority inherited         <blah> + I                    
Delayed and suspended                        DELAY+S
Pended and suspended                         PEND+S
Pended and Delayed                           PEND+T
Pended, delayed and suspended                PEND+S+T

The DELAY state indicates that the task has done some sort of delayed
call while PEND means the task has done something that caused it to
block like trying to semTake a semaphore someone else was holding.
PEND+T means that the task is both delaying and pending; it has done a
semTake with a timeout. +I means that the task has (temporarily)
inherited a higher priority through the use of a mutex semaphore.

The priority inheritance protocol also accounts for the ownership of
more than one mutual exclusion semaphore at a given time.  A task in
such a situation will execute at the priority of the highest priority
task blocked on any of the owned resources.  The task will return to
its normal, or standard, priority only after relinquishing all of the
mutual exclusion semaphores with the inversion safety option enabled.

If you use nested mutex semaphores with priority inheritance turned on then
when a task inherits a high priority due to some inner semaphore it owns,
it doesn't lose that priority until it relinquishes all the semaphores it
holds.  This doesn't quite follow the rules for priority inheritance (to
the extent that there really are any rules) in that normally, a task's
inherited priority should decrease as it releases each nested semaphore to
whatever the priority ceiling is for the semaphores it still holds.  Getting
this incremental priority reduction to work right in practice, though,
is extremely difficult (some of the SUN papers on the Solaris real time
scheduling indicate that this was one of the hardest things for SUN to
get right in their OS upgrades).  Given that VxWorks is a real time embedded
OS, I, for one, don't care if WRS uses the current implementation even
though it isn't "pure" because the result is a more reliable implementation
that runs more deterministically.  Anyway, my guess is that you will find
that you have some nested semaphore code where you are doing something
after releasing one of the nested semaphores that shouldn't be done at a
high priority.  

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

33. Gotchas w.r.t watchdogs

watchdog handlers run at interrupt level.  You should not use
routines that can block in interrupt level code.  Frequent mistakes:
using printf() in watchdog routines -- use logMsg() instead.

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

34. Is it possible to delete a memory partition in VxWorks?

No.  memPartDestroy() is not really implemented.  Perhaps it will
be in the future.  Currently it just returns ERROR.  

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

35. rename() does not work in netDrv and nfsDrv filesystems, why?

Because rename() is not implemented for netDrv (although it could be),
and nfsDrv does not implement rename() completely either.

Talk to WRS to get these fixed.

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

36. Free NFS Server for VxWorks

A free, incomplete, sample implementation (i.e. hack) of NFS Server
for VxWorks is available in:

 netcom.com:/pub/hjb/vxnfsd.tar.gz

There is a README file there that describes further details.  The current
snapshot of this implementation is a result of a couple of days of 
hacking, doesn't do everything right, and intended for educational and
further hacking purpose.

There is someone else who's porting the MS-DOS PC-based nfs server (SOSS?)
to VxWorks.  Not clear on its availability yet (let me know!)

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

37. Free SNMP for VxWorks

hoff@bnlux1.bnl.gov (Lawrence T. Hoff) reports,

We ported the CMU SNMPv2 code to vxWorks 5.1. This latest round of posts has
prompted me to put it in anonymous ftp (ctrldev1.rhic.bnl.gov --
130.199.96.82).

SNMP Research sells VxWorks compatible port of their SNMP implementation
with support.  Their's cost $$$$$, though.

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

38. What third party products are available for VxWorks?

I tried to include the third party products, list of consultants,
services, goodies, etc. available for VxWorks from various sources but...
there are too many to list here.  Instead,

the file:

 netcom.com:/pub/hjb/vxworkers.gz

is updated in realtime to contain a list of individuals and companies
that offer help, services (paid or unpaid), and goods for VxWorks.

To get a copy (if you don't have ftp access) or to be listed in this file, 
please contact or send info in ASCII to:

 hjb@netcom.com.

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

39. What kind of products have been developed using VxWorks?

 - Flight simulators
 - Radio and optical telescopes
 - Automative ABS & realtime suspension
 - Naviation systems
 - Deep sea instrumentation
 - PBXs
 - Traffic lights
 - Modems
 - Sonar systems
 - Comm/weather satellite test equipment.
 - X terminals
 - PostScript laser printers

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

40. A complete list of CPU hardware supported by VxWorks

Complete list of WRS supported BSP's are available in:

 netcom.com:/pub/hjb/vxbsp.gz

VxWorks runs on a lot of different hardware.  Majority of hardware
supported is based on VME bus.  Porting VxWorks to a new VME board
based on MC68K takes only a few days, give or take a week, depending
on your karmic condition at the time.  A lot of the ports are
initially done by the customers and later "approved" by WRS, for
which they charge, in order to keep them on "supported" list.

Porting to a new "architecture" (new processor) takes longer.
This varies more widely -- from a few months to a few years.

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

41. A complete list of peripheral devices supported by VxWorks

Complete list of WRS supported BSP's are available in:

 netcom.com:/pub/hjb/vxbsp.gz

VxWorks supports a wide variety of devices.  A lot of device drivers 
are written both by customers and WRS staff.  There are device drivers
for almost popular available ethernet chips (except perhaps SEEQ and
Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async
COMM chip, etc.), little I/O thingies in micro-controllers (MC68302
serial I/O, etc.), SCSI, etc.

Customers of VxWorks, hackers and other hardware vendors (especially
VME) usually have a VxWorks driver for their board.  There are drivers
for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers,
frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch
toy games.

A list of available device driver for VxWorks can be found in:

 netcom.com:/pub/hjb/vxdrivers.gz

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

42. What's with these unbundled "accessories"?

Propaganda from WRS:

 The new product/feature doesn't need to wait for the
 next OS release.  Only the users who want/need it pay for it 
 lengthens price list which keeps individual items lower
 but still enhances WRS revenue growth.

 Please Note:
 WRS still always adds features to the core product, and
 has never taken items out of core product to make them
 unbundled.  Unlike UNIX vendors and others.

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

43. How come my 5.0.2 BSP isn't available in 5.1, damn it?

Propaganda from WRS:

 WRS tries to give customers 1 year warning when any product
 may be discontinued.  Unfortunately, all the bugs in
 the notification system are still to be worked out.
 Complain vehemently to your sales rep. if he didn't
 keep you informed.  WRS BSP obsoletion policy is primarily
 based on BSP volume and h/w avalability.

The 5.1 Guide and Release Notes provide a step by step recipe to
upgrade from 5.0.2 -- minimal changes,  start by ANISifying.  The BSP
Port Kit 1.1 provides extensive  info for the masochist.

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

44. How much is VxWorks?

 In general: Not free, in fact, quite the opposite.

 - Development License $23.5K (per project?)
 - Source $120K.
 - Target Licenses from $1000 for single quantity to $10 for 100,000+.

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

45. What is MicroWorks?

VxWorks is also available as a kernel-only product (MicroWorks 1.0) for
 the following processors:

 i960, 680x0, 683xx

MicroWorks is -- half the product at a half the price.

It has no network, native debug, shell, or profiling.  Comes with
VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0
also included -- this is the debug agent which allows true system
level debugging in ISR or wherever.  In future, VxWorks may also be
able to work with VxMon.

Development License $12,500.

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

46. Other Unbundled Products for VxWorks?

Other unbundled "accessory" products are: VxMP ($4K) which is an
extended shared memory capabilities for the kernel allowing semaphores
and other objects to be manipulated over the backplane transparently
(really!).

VxVMI ($3K) is a library of virtual memory interface routines allowing
text & kernel data protection.  complementary products: BSP Port Kit
1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++
Gateway for ObjectCenter ($?K's), and Realtime Innovations StethoScope (3K).

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

47. How can I find out more about VxWorks?

 Read: comp.os.vxworks
 Email: inquiries@wrs.com
 Call: 1-800-KIK-WIND

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

48. What other net.resources are available on real-time systems?

There is at least one other newsgroup devoted exclusively to a particular
vendor's real-time operating system:

comp.os.os9  Discussions about the OS/9 operating system.

Here are some other related newsgroups:

comp.arch		Computer architecture.
comp.arch.bus.vmebus	Hardware and software for VMEbus Systems.
comp.os.misc		General OS-oriented discussion not carried elsewhere.
comp.realtime		Issues related to real-time computing.
comp.os.os9		Issues related to OS9 and OS9000 realtime OS.

There are too many other newsgroups devoted to computer operating systems
to list here.  The interested reader is advised to check the "newsgroups"
file on a local news service machine.

The automatic server for users of pSOS RTOS is now in place.

PSOSUSER - A list intended for the discussion of topics relating to
           pSOSystem and other products of Integrated Systems Inc.,
           Software Components Group.

Send articles to psosuser@isi.com and administrative requests to
listserver@isi.com.

If you aren't already subscribed and would like to, please send a mail
message to listserv@isi.com containing the following in the body of
the message

SUBSCRIBE PSOSUSER <substitute your full name here>

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

49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?  

Use ioctl() instead.

...
{
	...
	int on = 1;	/* turn it on */
	...
	ioctl(fd, FIONBIO, &on);
	...
}

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

50. Free lex and yacc for use with VxWorks

John Winas (winas@phebos.aps.anl.gov) writes,

I just (moments ago) uploaded the two packages to thor.ncar.ucar.edu where
the vxWorks archive is.  When ever the maintainer moves it into the release
area they will be available to everyone.  I named the file lexyacc.tar.Z
and it contains all of the sources and make files for you to build them.
It all seems to work perfectly on my sun sparc running 4.1.3.  The
only thing you have to configure is the full path name to where you wish
to keep flex so that it can find its skeleton file when you use it to
lexify your .l files.  Byacc has no skeleton files and simply needs to 
be in your path.

This file is now available in:

	epics.aps.anl.gov:/pub/lexyacc.tar.Z

I am interested in any bugs found in because we are using them here.  Feel
free to email me at winans@phebos.aps.anl.gov.

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

51. timer_gettime() bug

[ From: kent@wrs.com (Kent Long) ]

In article <9311230139.AA21147@focal.com> bobk@focal.com (Bob Klawuhn) writes:
>I am currently trying to user the timerLib to obtain
>the amount of time that a timer has left before it
>expires. I am trying to use the timer_gettime function. 
>The value that it seems to return is always the time
>that the start timer was given, not what is left on the
>timer.


This is indeed a bug in the 5.1 and 5.1.1 VxWorks versions.
It is now being tracked as WRS SPR #2673.

As a workaround, the following could be done following the
timer_gettime() call, to convert the erroneous results into
the desired remainder value:


     #include "private/timerLibP.h"
     struct timespec timeNow;

     (void) clock_gettime (CLOCK_REALTIME, &timeNow);
     TV_SUB (timerid->exp.it_value, timeNow);

...which leaves the remainder in it_value.

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

52. bogus INCLUDE_TCP_DEBUG

[ From: hipp@wrs.com (Emily Hipp) ]

>Bus Error
>Program Counter: 0x0001c738
>Status Register: 0x3000 
>Access Address : 0xbfbfbfd3
>Special Status : 0x0505
>Task: 0x3dcc54 "tExcTask"
>TCP tracing not enabled (use INCLUDE_TCP_DEBUG).  

This is misleading information.  INCLUDE_TCP_DEBUG is not supported
as a configAll.h include option.

[ editorial: 
  INCLUDE_TCP_DEBUG never got integrated into VxWorks config files.
  To get around this bug, until WRS fixes it, either unset SO_DEBUG 
  socket option using getsockopt()/setsockopt(), or call tcpTraceInit() (sp?)
  which will drag in tcp_debug.o and set the tcp_trace() routine to
  be called when debug option is set on TCP sockets.
]

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

53. free ppp for VxWorks

Is available via anonymous ftp 

	netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz

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

54. how to disable cache on mc68040 or mc68030 using TT regs?

[ From: Steve Morris <morriss@smtplink.indigo.co.il> ]

        /**************************/
        /* for 68030 (e.g. mv147) */
        /**************************/
        
        /* 2 large areas, R/W, cache disabled */
        #define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
        #define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
        
        test_tt ()
        {
            register int *pVal;
            int ttVal;
            
            pVal = &ttVal;
            
            ttVal = TT0_VALUE;
            asm ("pmove %0,tt0" : : "g" (*pVal));
            ttVal = TT1_VALUE;
            asm ("pmove %0,tt1" : : "g" (*pVal));
        }
        
        /**************************/
        /* for 68040 (e.g. mv167) */
        /**************************/
        
        /* 2 large areas, R/W, cache disabled */
        #define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
        #define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
        
        test_dtt ()
        {
            asm ("movec %0,dtt0" : : "r" (DTT0_VALUE));
            asm ("movec %0,dtt1" : : "r" (DTT1_VALUE));
        }

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

55. work-arounds for MS-DOS filesystem bug when lseek() past eof

[From: georg@sgl.ists.ca (Georg Feil)] 

[editorial: This is a workaround for the bug in VxWorks ms-dos
implementation which produces incorrect error return on write() after
lseek() beyond eof.  N.B.: VxWorks versions upto 5.1.1 have buggy IO
system layer that does not support "correct" write() to normal files.
When writing to a file via write() expect to check the return value
even if it is not ERROR. Unlike most other systems (e.g. UNIX) VxWorks
write() upto version 5.1.1 will return number of bytes actually written
even when write() was not completely successful on devices that are
not marked non-blocking and/or are subject to flow control. ]

There's been enough heated debate on this so I'm sending out my brute force
workaround. Thanks to Kent Long who managed to let slip enough information
on the bug to identify the prerequisite: lseek() past the end of file.

My workaround simply extends a file by writing 0's on the end whenever there
is a seek past the end. (This may result in a file being extended when it
shouldn't have been, i.e. no write follows the seek, but what the hell.)
Use file_seek() below instead of lseek() to seek. Note that file_seek() is
not meant to be plug-replaceable with lseek(), that feature is not
required in our system. 'zero8k' is a character array of 8192 zero bytes.


int file_seek(int fd, int offset)
/*
 * Sets the byte offset for the next write or read from a file.
 * Simple interface to lseek() function. This returns ERR_NONE iff the actual
 * actual seek offset returned by lseek() exactly matches the desired offset.
 * 'fd' is the file descriptor to seek on.
 * 'offset' is the absolute file position to seek to in bytes, where 0 is
 *          the beginning of file.
 * Return value is error code (not a VxWorks error code, another type).
 */
{
   STATUS st;
   struct stat filestat;        /* file status info obtained from fstat() */
   int aoff;        /* actual seek offset returned by lseek() */
   long int fillsz;    /* (***) for SPR #2739 kludge */
   long int fillamt;   /* (***) for SPR #2739 kludge */

   if (FileDebug && Verbose>=2)  {
      wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n",
                                                                  offset,fd);
   }

   /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with
        transfer count too low but errno not set after seeking past current
        end of file). Note that this may extend the file prematurely, i.e.
        even if no write() calls follow the seek. */
   /* get current file size */
   st=fstat(fd, &filestat);
   if (st==VX_ERROR)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n",
                                                           fd, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   /* manually extend file using zero writes if seek offset past end of file
        (note: tried ioctl() with FIOTRUNC, but this only works to shorten
        files! */
   if (offset>filestat.st_size)  {
      /* seek to the end of the file first */
      errno=0;
      aoff=lseek(fd, filestat.st_size, SEEK_SET);
      if (aoff != filestat.st_size)  {
         /* returned value should always match 'filestat.st_size' */
         if (Verbose>0)  {
            wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n",
                                     fd, aoff, filestat.st_size, vw_errmsg(0));
         }
         return(ERR_VXIO);
      }

      /* fill file with zeroes to bring length up to 'offset' */
      fillsz=offset-filestat.st_size;
      while (fillsz>0)  {
         if (fillsz>8192)
            fillamt=8192;
         else 
            fillamt=fillsz;

         errno=0;
         aoff=write(fd, zero8k, fillamt);
         if (aoff == VX_ERROR)  {
            if (Verbose>0)  {
               wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n",
                                       fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
            }
            return(ERR_VXIO);
         }

         if (aoff != fillamt)  {
            if (Verbose>0)  {
               wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n",
                       fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0));
            }
            return(ERR_VXIO);
         }

         fillsz -= fillamt;
      }

      /* flush the output to disk immediately */
      st=ioctl(fd, FIOFLUSH, 0);
      if (st!=VX_OK)  {
         if (Verbose>0)  {
            wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n",
                                       fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
         }
         return(ERR_VXIO);
      }
   }

   /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */


   errno=0;
   aoff=lseek(fd, offset, SEEK_SET);
   if (aoff == VX_ERROR)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n",
                                                     offset, fd, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   /* returned value should always match 'offset' */
   if (aoff != offset)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n",
                                             fd, aoff, offset, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   return(ERR_NONE);
}

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

56. TCL for VxWorks

[ From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) ]

Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is
on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz

If you've ever been frustrated that the VxWorks shell is not re-entrant, 
and has no control flow (e.g. if then else, switch, case ),
then you will find TCL very useful since it is a very complete language,
that allows you to add your own application specific commands to
the interpreter.

I find it invaluable for system testing, since I register TCL commands for
all major functionality of my real-time application.  This allows me
to test most pieces of my data acquisition system from a command line,
and build nice flexible scripts to test and operate my system.  As a
matter of fact, I can even invoke specific methods of C++ classes via
TCL.

Also, you can control your real-time system from a Unix workstation by
sending TCL commands from either a TCL or Tk/TCL application (via
tclTCP).  I find that sending TCL commands (which are just strings) is
much easier and more flexible than writing a Remote Procedure Call
(RPC) for each piece of functionality that I need to remotely invoke.

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

57. adding default route

A default route is a route table entry with destination field set to 0.
To do the equivalent of "route add default gateway metric" in VxWorks,
do:
	routeAdd("0",addr_of_gateway);

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

58. adjusting network driver MTU size

VxWorks network driver are compatible (mostly) with tahoe BSD drivers.
To change MTU you should modify "if_mtu" field of "struct ifnet" you
pass to ether_attach() or if_attach().

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

59. tcpdump like utility for vxworks

Take a look at a hacked up packet trace program in:

	netcom.com:/pub/hjb/vxsniff.c.gz

[editorial: if you have something better, let me know]

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

60. VxWorks performance on i960 -- unofficial benchmark

[ From: djanssen@mswe.dnet.ms.philips.nl (Ton Janssen, 62203 (TSSW)) ]

We did some measurements on a Heurikon HK80/V960E.
Equiped with I960CA on 33MHz. Here they are:

Test-item			Conditions			Time in us
==========================================================================
- - semGive/semTake pair		(binary semaphore)		11,2
- - taskSpawn			(+/- 8 processes active)       790,0
- - taskIdVerify							 0,72
- - taskSuspend/taskResume pair	(+/- 8 processes active)	32,6
- - lstAdd/lstDelete pair		(10 nodes in list)		 3,9
- - msgQNumMsgs							 1,2
- - msgQReceive 			(NOWAIT, no message available)	16,8
- - rngBufPut/rnBufGet pair	(0x20 bytes)			24,5
- - msgQSend/msgQReceive pair	(NOWAIT, no arguments)		65,7
- - bcopy				(Quad aligned data)		 0,515/Quad
- - mutliply two floats		(depends on the value!)		 1,6
- - multiply two doubles		(   ''     ''    )		 2,6
- - Raw context switch		(8 processes active)		34,0

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

61. VxWorks SCSI Performance -- unofficial benchmark

[ From: mea@mclean.sparta.com (Mike Anderson) ]

System     : Heurikon HK68G/V4D  
             (33 MHz 68040, 16 MB RAM, NCR53C710 SCSI 
              w/ Hk SCSI DMA routines in Asynchronous SCSI mode)

VxWorks    : 5.1.1 (Yes, using Heurikon VxWorks 5.1 BSP)

Disk       : Seagate ST11200N (1 GB SCSI)

File System:  VxWorks RAW partition mounted as "/sd1/"

Clock Rate :  60 Hz

Approach: 

  My application has the data coming in in 16Kbyte chunks.  So, I devised
a piece of test code that would allow me to specify how many 16K chunks
I sent to the disk in each write and how many total bytes to write.
The actual number of bytes written is generally a little larger
(typically one more block size) due to the quick and dirty way I wrote
the code, but the calculations are based on the actual number of bytes
written to the disk.  The technique I used was to write a block to the
disk starting at the end of the last write and then seek back to
relative zero and write the current pointer (just as I would in real
life to know how many bytes had been streamed total).  Also, you 
may notice the disk seek time coming into effect in the 200MByte files.

Here are the results:

Buffer Size     Total Requested     Bytes/sec       total secs
16K             1024000 (1 MB)      1,032,192       1.000   secs
               10240000 (10 MBs)    1,036,087       9.883   secs
              102400000 (100 MBs)   1,049,538      97.566   secs
              204800000 (200 MBs)   1,043,123     196.333   secs

32K             1024000             1,613,193       0.650   secs
               10240000             1,627,997       6.300   secs
              102400000             1,627,980      62.900   secs
              204800000             1,610,485     127.166   secs

48K             1024000             1,935,360       0.533   secs
               10240000             1,994,712       5.150   secs
              102400000             1,992,209      51.416   secs
              204800000             1,970,335     103.950   secs

64K             1024000             2,169,467       0.483   secs
               10240000             2,244,905       4.583   secs
              102400000             2,246,332      45.600   secs
              204800000             2,216,450      92.400   secs

96K             1024000             2,495,409       0.433   secs
               10240000             2,580,480       4.000   secs
              102400000             2,571,534      39.833   secs
              204800000             2,533,374      80.866   secs

128K            1024000             2,621,440       0.400   secs
               10240000             2,761,250       3.750   secs
              102400000             2,771,147      36.983   secs
              204800000             2,726,693      75.133   secs

256K            1024000             2,859,752       0.366   secs
               10240000             3,130,077       3.350   secs
              102400000             3,139,304      32.650   secs
              204800000             3,083,428      66.483   secs

512K            1024000             3,145,728       0.333   secs
               10240000             3,346,519       3.133   secs
              102400000             3,361,846      30.566   secs
              204800000             3,298,416      62.150   secs

1024K           1024000             3,311,292       0.316   secs
               10240000             3,475,942       3.016   secs
              102400000             3,487,345      29.466   secs
              204800000             3,416,806      60.150   secs

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

62. VME bus arbitration gotchas

[ From: mea@mclean.sparta.com (Mike Anderson) ]

> Sender: Rob Steele, e-mail: steele@telerobotics.jpl.nasa.gov
> 
> 
> I have the following VME hardware configuration:
> 
>   VME MOTES chassis:
>      1 Motorola system controller card,
>      6 Huerikon 68020 CPU boards (HKV2A),
>      1 Micro Memory shared memory cards,
>      1 Bit-3 memory interface card,
>      2 XYCOM parallel boards, and
>      1 Excelan ethernet cards.
> 
>      VadsWorks 2.0.1 (equivalent to vxWorks 5.0).
> 
> I am unable to consistently boot the chassis. I will get bus errors and file
> not present errors during the boot process on different boards. On rare
> occasions it will boot. To get it to boot I halt the boot process on the last
> 4 boards in the chassis and let the first two boot. After that I boot the
> last 4 one at a time.
> 

This sounds like the bus arbitration bug biting.  If the Heurikon
boards are all at the same bus grant level (they typically come from
the factory set for BG3) then you will experience "random" failures
that manifest themselves as bus errors when a board is requesting
access to the bus and the bus is so busy that the bus watchdog timer
(1.6ms on the HKV2F I think) expires.  This is proper behaviour.  The
watchdog timer is designed to alert the task that it was unsuccessful
in accessing a VME address in the alotted time and to signal that
failure with a bus error.

Now, there are several ways to fix this problem.  One which I heard
about was to modify the boot ROMs to insert a variable length delay so
the first CPU booted immediately, the second booted 30 secs later the
third 60 secs later, etc.  This approach was clearly a software hack
trying to get around a hardware problem that was obviously not
understood.  This approach *may* get the boards to boot, but with heavy
bus traffic during execution, they will continue to exhibit bus
errors.  You see, because the VMEbus is a daisy chain, the first CPU in
the chain has an inherently higher priority than all others that follow
it.  The 2nd board gets the next highest priority, etc.  This means
that a graph of bus access at a given BG level looks something like
this:

    %  60  |
           |                                              
    A  50  | * 
           |                                             
    C  40  |
           |                                                  
    C  30  |     
           |      *                                       
    E  20  |      
           |          *                                           
    S  10  |        
           |              *                                        
    S   0  |------------------*---*--                                 
              1   2   3   4   5   6                                   
              # CPUs @ BG level 

I.e., it is roughly an exponential decay such that, given that the
level of bus activity is moderately high, the first 1-3 CPUs will hog
85-95% of the bus cycles and CPUs 4 and beyond will exhibit bus
errors.  If the bus activity level is very high such as during a boot
up via the backplane, you may not be able to get past CPU 2 before bus
errors manifest themselves.

Now, as I said, there are other ways to circumvent this problem.
Boards equipped with the VIC68 VMEbus interface, for instance, can have
their bus timeouts changed to the point of an infinite wait (i.e., the
bus watchdog is disabled).  This is still just a kludge that masks the
real problem of a poorly thought-out arbitration scheme.  With this
approach, *real* bus errors resulting from errant pointers and/or
failed boards are never reported and the system just seems to hang.

The REAL solution to this problem is to adjust the arbitration levels
of the CPUs.  In the VMEbus, there are 4 levels of arbitration (0-3)
where level 3 is the highest priority.  By default, virtually all
manufacturers ship their boards configured for BG3.  Therein lies the
problem.  What the real-time designer needs to do is to realize this
and make adjustments.  Within the 4 BG levels, there are two modes of
operation: 1) priority and 2) round robin.  Priority mode means that
requests at level 3 will be honored before requests at level 2.  Level
2 before level 1 and so on.  This means that with priority mode
arbitration, put your highest priority boards at level 3 and distribute
the other boards at the other levels according to their relative
priorities.

On the other hand, round robin arbitration mode means that all 4 BG
levels are treated equally and each level gets a fair slice of the pie
so to speak.  Use this mode when you have lots of boards, but no one
has an inherently higher priority than any other.  With this approach,
we've been able to get as many as 16 CPUs running in the same backplane
(4 at each level) without experiencing bus error problems due to
arbitration.  Remember, just because the boards are at different BG
levels doesn't circumvent the implied priorities of the CPUs at the
*same* level based on the bus daisy chain.

Typically, these modes are configurable on the system controller either
through a jumper, PAL or software bit twiddling.  However, there are
boards that are hardwired for arbitration level 3 and they can't be
changed.  The Force SPARC 1E board is one of them.  This means that
you'll have to use these boards sparingly in VxWorks chassis (i.e.,
probably no more than 3-4 booting up from the backplane but probably
more if you boot each of them up from local Ethernet).  I understand
that the SPARC 2CE board uses the same VMEbus interface as the 1E which
simply means that the bus errors will happen twice as fast.  Hopefully,
the 3E board will get a real bus interface on it if it ever comes out.

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

63. 5.1.X new MMU supporting code gotchas, as explained in the Manual

Carl Lacy points out:

   1)  Programmer's Guide, Chapter 8.3, page 319
		How to setup the the MMU for VMEbus address spaces

   2)  5.1 Known Problems, Apr '93, page 5
		"Several BSPs turn on basic MMU support ... even if
		this option is not specified in configAll.h"

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

64. "Cannot Boot. Error 0x1a9" while downloading/booting

This is usually due to the built-in 'feature' inside UNIX inetd program.
The inetd tries to protect itself against clients that tries to connect
too often too quick as a security measure, and disallows more than a 
certain number of connections per given period.  When this happens, you
will usually see some error messages about "looping..." in syslog (if
your syslog is configured correctly) on your UNIX server (where inetd
is running).  You can either try "kill -HUP inetd_process_id" to get
out of this looping mode by sending HUP signal to inetd, or try and
install the patched version of inetd that has larger default limit for
looping detection (some OS vendors will supply this to you), or just
get a copy of BSD UNIX distribution of inetd source code and compile it
with larger default values for looping and use it instead.

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

65. problem with qsort in some versions of VxWorks

Some version of VxWorks are shipped with incorrect qsort(), to remedy
this problem, get a copy of qsort() from BSD UNIX distribution and 
compile it.

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

66. fmod fiasco

From: jbrandt@sadira.gb.nrao.edu (JOE BRANDT)

remainder = fmod(value, divisor) - floating point modulus routine.

The fmod math subroutine for MC68040 (mv167) based systems has been a
topic of discussion on the exploder for many months now. The first
discussions centered around the routine's accuracy (or even
correctness). Recently I found that the execution time for the fmod
subroutine is highly dependent upon the ratio of the values passed as
arguments. At a ratio of about 50,000 I was seeing execution times of
30ms!  The VxWorks exploder FAQ now includes a proposed replacement
routine for 68040 systems, however, I have examined this routine and
found it to be grossly in error in cases where the divisor is less than
1.0.

Fortunately, I have found public domain source, authored by Sun Micro, 
for an alternative algorithm. This algorithm claims an exact result. 
It can be found at:
    ftp: plan9.att.com in /netlib/fdlibm/e_fmod.c.Z 
    (I believe ftp.uu.net has copies also).
This appears to be a ieee 754 compliant routine. (I'm not sure what that
means, but it sounds good).

Execution times for this routine are in the range of 7.6 to 100 usec's.


From: vince@rti.com (Vince Chen)

> Submitted-by jbrandt@sadira.gb.nrao.edu  Thu Mar 24 12:41:16 1994
> Submitted-by: jbrandt@sadira.gb.nrao.edu (JOE BRANDT)
> 
> While I currently am not questioning the accuracy of the fmod() function,
> the performance of it on the mv167 card (68040) is certainly an issue.
> 
> Here's some benchmarks from my 5.1/mv167 system:
> 
> -> timexN(fmod, 49999.9, 1.0)
> timex: 25 reps, time per rep = 30661 +/- 666 (2%) microsecs
> 
> -> timexN(fmod, 2.0, 1.0)
> timex: 50000 reps, time per rep = 9 +/- 0 (0%) microsecs
> 
> -> timexN(fmod, 499.9, 1.0)
> timex: 2525 reps, time per rep = 305 +/- 6 (1%) microsecs
> 
> Note the dependency on value. Unfortunately I am doing an fmod on the
> modified julian date (which is currently in the 50,000 range). which
> took an amazing 30ms/call !
> 
> Wow, can some elaborate on the algorithm being used here. seems like it's
> a straight while loop!

I believe it is a while loop.  A while loop is faster in some situations,
but obviously no in yours!

Until WindRiver resolves the problem w/ the Motorola Floating Point 
Exception library, you may want to roll your own on this one.
The code below on our 167/25MHz VxWorks 5.1 consistently results in 30 usecs.

double myfmod1( double arg1, double arg2 )
{
    return (arg1 - ((int) (arg1 / arg2)) * arg2);
}

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

67. MVME167 copyback cache and various problems

From: georg@sgl.ists.ca (Georg Feil)

Well, I think we now know everything there is to know about the memPartFree()
problem we were having. The original subject here was "memPartFree error with
copyback caching enabled (167)". Other past subjects that possibly related to
the same problem include "Large disk writes w/cache cause MVME167 to freeze".
Apparently the root cause is a snooping problem related to TAS on the
VME bus, and is Motorola's fault.

The solution to the problem is the "MV167 VME TAS patch" from Wind River. 
It consists of a number of configuration changes (config.h, usrConfig.c etc.)
and is reproduced below. Strangely, it has not been assigned an SPR number
because, according to Wind River, the new version of the 167 BSP has fixed
the problem so no SPR is necessary(?). This situation may have changed since
the memos I received were written. Our related TSR number was 16443, which may
help others to track things down.

I had already come up with my own patch that worked in a completely different
(and very specific) way, and the WRS patch seemed not to apply to our problem.
However I tested the patch anyway and sure enough it fixes our problem.
As a bonus, SCSI performance seems to have improved slightly.

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

68. unloading objects

From: stan@rti.com (Stan Schneider)

Under VxWorks 5.1.x, you can use 'unld "file.o"' (or use the module id,
see "moduleShow").  Under 5.0.x, you can't unload the object & reclaim the
space, but you could remove the symbols from the symbol table with symRemove.
That would prevent unnecessary maiming.

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

9999: Contributions to comp.os.vxworks FAQs.

The following net.folks, among others, have contributed to this posting:
[ If you have contributed, but are not listed here please me know. ]

 Name			email address
 ------------		----------------------------	
 Mike Anderson		mea@mclean.sparta.com
 Mark Linimon 		linimon@nominil.lonestar.org
 Geoff Espin		geoff@wrs.com
 Rev. Bob Crispen	crispen@foxy.boeing.com
 Stan Schneider		stan@rti.com
 Fred J Roeber		fjr@ssd.ray.com
 Marc Friedman		maf@verdix.com
 Joe Van Andel		vanandel@ncar.ucar.edu
 Emily Hipp		hipp@wrs.com
 Bob Marino		ram@mr.picker.com
 Richard Kowalsky	cmdorat@tc.fluke.com 
 Kent Long		kent@wrs.com
 James Moore		james@wrs.com
 Chuck Meade		chuckm@verdix.com
 Patrick T. Pinkowski	ppinkow@jupiter.ksc.nasa.gov
 D'Anne Thompson	dat@noao.edu
 Leonid Rosenboim	leonid@rst.hellnet.org
 David Lim		lim@robotics.jpl.nasa.gov
 Richard Neitzel	thor@thor.atd.ucar.edu
 John Winas		winas@phebos.aps.anl.gov
 Lawrence T. Hoff	hoff@bnlux1.bnl.gov 
 Georg Feil		georg@sgl.ists.ca
 Steve Morris		morriss@smtplink.indigo.co.il
 Don Brooks		dab@netcom.com
 Ton Janssen		djanssen@mswe.dnet.ms.philips.nl
 Brian Brunner		brunner%mother@icarus.ssd.loral.com
 Carl Lacy		lacy@draper.com
 Joe Brandt		jbrandt@sadira.gb.nrao.edu
 Vince Chen		vince@rti.com

I welcome flames, insults, accusations, reactions, additions, and
corrections to this posting via email:

 Hwa-Jin Bae
 PEACEFUL STAR
 hjb@netcom.com 

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

===============================================================================
- -- 
hwajin
PEACEFUL STAR

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

End of New-News digest
**********************


From vx_list@mars.psf.ge.com  Tue Apr 19 05:20:02 1994
From: vx_list@mars.psf.ge.com
Date: Tue Apr 19 05:20:17 PDT 1994
Subject: Posting rejected
Your posting to list VX_LIST was rejected.
Reason: message size limit exceeded (maximum allowed: 65536 bytes)
The first few lines of your message are included herein for reference:

Submitted-by daemon@vxw.ee.lbl.gov  Tue Apr 19 04:00:33 1994
Submitted-by: daemon@vxw.ee.lbl.gov
 
Comp.Os.Vxworks Daily Digest    Tue Apr 19 04:00:13 PDT 1994

        Subject: reboot entire vme crate?
        Subject: Re: reboot entire vme crate?
        Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]

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



From vx_list@mars.psf.ge.com  Tue Apr 19 05:20:07 1994
From: vx_list@mars.psf.ge.com
Date: Tue Apr 19 05:20:26 PDT 1994
Subject: Posting rejected
Your posting to list VX_LIST was rejected.
Reason: message size limit exceeded (maximum allowed: 65536 bytes)
The first few lines of your message are included herein for reference:

Submitted-by daemon@vxw.ee.lbl.gov  Tue Apr 19 04:00:33 1994
Submitted-by: daemon@vxw.ee.lbl.gov
 
Comp.Os.Vxworks Daily Digest    Tue Apr 19 04:00:13 PDT 1994

        Subject: reboot entire vme crate?
        Subject: Re: reboot entire vme crate?
        Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]

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



From sstern@atl.com  Tue Apr 19 14:58:13 1994
From: sstern@atl.com (Steven Stern)
Date: Tue Apr 19 14:58:30 PDT 1994
Subject: DOS Partitioning hard disks from VxWorks 5.1
Hello:

Does anyone have any code or information they would like to share regarding
DOS partitioning hard disks from VxWorks 5.1?

Thank you,
sjs
/=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\
|  Steven Stern                         email:  sstern@atl.com  |
|  Advanced Technology Laboratories                             |
|  MS: 264                              office: (206) 487-7002  |
|  22100 Bothell Everett Highway        fax:    (206) 486-5220  |
|  Bothell, WA  98041-3003                                      |
\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/


From daemon@vxw.ee.lbl.gov  Wed Apr 20 04:00:25 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr 20 04:00:38 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr 20 04:00:14 PDT 1994

        Subject: Re: ld error
        Subject: Please check your mailers!
        Subject: Re: HDLC for the 85230
        Subject: Re: Questions About Real-time C++ VxWorks Embedded Systems
        Subject: MARKET SURVEY

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

Newsgroups: comp.os.vxworks
Subject: Re: ld error
Date: Tue, 19 Apr 1994 16:46:02 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems
Message-ID: <james.766773962@wrs.com>
References: <Cny1sr.LD0@nrtpa22.bnr.ca>
Reply-To: james@wrs.com
Sender: news@wrs.com (News Manager)

billag@b4pphff.bnr.ca (Bill Gutknecht) writes:

>-> ld < coatd
>value = 3782388 = 0x39b6f4
>-> perror
>S_objLib_OBJ_ID_ERROR

ld() returns MODULE_ID, so the load is succeeding.  The error number
is left over from some earlier error in the task.
- -- 
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
		   Why in the world is Volkswagen so obsessed
			     with far fig newtons?

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

Newsgroups: comp.os.vxworks
Subject: Please check your mailers!
Date: 19 Apr 1994 17:48:34 GMT
From: thor@ymir.atd.ucar.edu (Rich Neitzel)
Organization: National Center for Atmospheric Research
Message-ID: <2p15hi$otu@ncar.ucar.edu>
Sender: thor@ymir (Rich Neitzel)

Periodically the archive's email server receives mail that does not have
a fully qualified retrun host address. This causes the request to bounce.
Some times I can figure out where the mail arrived from by looking at the
sendmail log, but some mailers aren't even giving me enough to work on.
For example:

cadfael@decu16

Whoever you are, your mail isn't going to get answered! Please check with
your systems administrator about this!
- -- 
Richard Neitzel thor@thor.atd.ucar.edu          Torren med sitt skjegg
National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000	                Gjx'i med sitt shinn
303-497-2057                                    jagar borni inn.

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

Newsgroups: comp.os.vxworks
Subject: Re: HDLC for the 85230
Date: 19 Apr 1994 11:07 PST
From: waters@reg.triumf.ca (WATERS,GRAHAM)
Organization: TRIUMF: Tri-University Meson Facility
Message-ID: <19APR199411070474@reg.triumf.ca>
References: <CoBD8A.AKt@wrs.com>

In article <CoBD8A.AKt@wrs.com>, maillet@wrs.com (Al Maillet) writes...

>Does anyone out there have an HDLC (synchronous) serial driver
>written for the 85230 duart.  Any help would be greatly appreciated.
> 
>  Al Maillet                           al@wrs.com
>  Wind River Systems, Inc.             Southwest Application Engineer

I have drivers/libraries and application software for the Siemens 82532
multiprotocal chip (SYNC/ASYNC serial communication HDLC/SDLC protocol).
Maybe there is some compatibility. This is running well in our inhouse
designed VME module running vxWorks for the mc68332.

 Graham Waters                          waters@reg.triumf.ca
 TRIUMF                                 Control Systems Engineer.
 Meson Research Facility,
 4004 Wesbrook Mall,
 Vancouver, B.C. Canada.
 V6T 2A3


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

Newsgroups: comp.os.vxworks
Subject: Re: Questions About Real-time C++ VxWorks Embedded Systems
Date: 17 Apr 1994 11:54:59 +1000
From: rjl@f111.iassf.easams.com.au (Rohan LENARD)
Organization: EASAMS (Australia) Pty Ltd
Message-ID: <2oq4tj$qvr@f111.iassf.easams.com.au>
References: <9404151734.AA01489@atl.com>

Hi there folks,

In article <9404151734.AA01489@atl.com>,
Dean Wampler (dwampl@atl.com) <dwampl@atl.com> wrote:
>
>> Subject: Questions About Real-time C++ VxWorks Embedded Systems
>> 
>> We are contemplating using C++ (CenterLine C++ & gcc) with VxWorks in a VME
>>   environment using 68030 or better.  Our application will make
>>   heavy use of iostreams class library, NFS, sockets, etc.
>> 
>> Are there any developers who would like to share their experiences of
>>   using C++ with VxWorks in a real-time environment?
>
>OK.
>
>> Can you brielfy describe your application(s)?
>
>A fairly large and complicated medical application using the 68k.
>

A fairly large aircraft avionics simulator using the 68k.

>> What were the severe gotcha's?
>
>The file iostreams were broken in the beta of WindC++.  It reflected a bug in
>the implementation of multiple inheritance (a lesson for those who want to use
>multiple inheritance!).  I believe that the "V1.0" version is supposed to be 
>fixed.  
>

We use gcc on its own, with support from Cygnus (info@cygnus.com), and have a
fully working libg++ for vxworks. Infact we've built libg++ into our kernel,
so we don't have to link against it.

>> Have you found the CenterLine/gcc/VxWorks development environment to be stable?
>
>It feels like beta-ware, but it is stable enough.  We are avoiding multiple
>inheritance, for safety.  Also, we decided not to use the template mechanism in cfront.  It is confusing, slow, and the error checking seems to be poor.  We
>decided that it was too risky for our novice environment.  Your mileage may
>vary....
>

With support from Cygnus we get fast patches to the compiler / libraries when
their is a problem. IMHO WRS are not really interested in gcc for VxWorks (as
a C++ compiler) as they've got other products of their own.

>> 
>> What's been your experience with debugging the target using Vxgdb++ and
>>   CenterLine on the target. Any gotcha's or insurmountable problems.
>> 
>It doesn't handle mangled names very well.  For example, you can set a break
>point in a C++ function, but to actually "run func", you have to use the 
>mangled version of the name.
>

I expect this will be fixed in a newer version of vxgdb.  vxgdb is supported 
by cygnus (ie. they write the code for it and the rdb support for the kernel
- - or at least that's what the source suggests).

>> What 3rd party class libraries are you using?
>>

Booch Components, with lots of success.  Had to add #pragma's everywhere to
make them work with gcc, though.

> 
>> Have you discovered any problems using 3rd party class libraries, i.e.:
>>   re-entrancy or thread-safe issues, other?
>>

The Booch Components provide classes which are guarded and synchronised.  This
allows you to specify different types of MUTEX's.  I think guarded just
prevents you reading when someone else is writing, but synchronised allows
only on user in a critical section at a time.

>Can't offer any help here.
> 
>> Has anyone ported or used RogueWave class libraries with VxWorks?
>>
>I would like to try this one myself.... 
>> 

I seem to remember that RogueWave does not work with gcc, or something like
that they wouldn't support it with gcc.

>
>Another point, I don't know if speed of compilation and size of code is 
>critical, but I think you pay a penalty in both areas if you use "cfront". 
>I can't really say how big the "size" penalty is, but compile times aren't
>speedy.
>

Get a faster cross development machine :-).  We're using HP700 series
machines, and get very quick compilations consistantly.

>Hope this helps.  I think that I can safely recommend WindC++.  Plan on spending
>some time figuring it out and getting it working.  Also, using ObjectCenter is
>definitely recommended.  We try to test our code on the Sun before downloading
>to the target.  On the Sun, you can at least use the full power of OC, while
>only a subset is available on the Vxworks target.  Even there, it offers many
>advantages over vxgdb.
>

Not trying to be a spoiler, but I think that ObjectCenter has a reputation for
getting very slow as the application size grows. However it does have some
nice features...

Regards,
	Rohan
- -- 
- ----------------------------------------------------------------------------
rjl@iassf.easams.com.au	| "In the beginning there was cave man, and he had a
Rohan Lenard            |  club, which he used to seduce woman.  Hence the
+61-2-367-4555          |  saying `not tonight dear I've got a headache'"

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

Newsgroups: comp.os.vxworks
Subject: MARKET SURVEY
Date: Wed, 20 Apr 1994 03:17:06 GMT
From: sngmedia@world.std.com
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <CoJFsJ.M4J@world.std.com>

We are a small, dedicated group of people desperately trying to get
a video production company off the ground.

Recently, we secured enough financial backing to produce several
videos on the subject of personal computing.

Because we don't have the financial resources to perform a
traditional market analysis, we considered several alternatives and
concluded that we should consult the people of the Internet, who
are technically proficient and tend to be enthusiastic personal
computer users.  

We would like you to indicate which three of the below described
videos would appeal to you most.

Please note that each video synopsis is numbered.  When you are
ready to send your response, please specify the numbers
corresponding to your three video selections, and use commas to
separate the numbers.

For example, if you choose selections four, eight, and eleven, the
body of your letter would simply be:

4,8,11

and nothing more.

When you send back your response, please specify "MARKET SURVEY" in
the subject field.  Then, direct your response back to
sngmedia@world.std.com.

Please realize that this is not an advertisement, or solicitation. 
We simply would like to know your response.  You will not be
contacted further.

Thank you in advance for your help and cooperation.

Tom and Randi Fecker
sngmedia@world.std.com.

Please select three videos that interest you most:

1. The Internet Pilot's Guide
A plain English guide to getting around on the Internet by veteran
users.  How to use Internet resources to send/receive e-mail, and
to search for documents and files relating to a particular subject. 
How to use LISTSERVs, GOPHER, ARCHIE, WWW and WAIS.  How to use FTP
and Telnet to access remote computers for file transfers, remote
logins, etc.  Also, learning how to observe Internet's
"netiquette."  And how to access multimedia Mosaic bulletin boards.

2. How to Make Money at Home With Your PC I -- Successful PC-Based
Businesses
Meet five successful entrepreneurs who started their own home-based
businesses using a PC.  Includes businesses that provide typing
services, mailing list management, horoscopes, bookkeeping, and
even a software developer who does not know how to program -- he
hires other people to implement his software designs.  Includes
ideas for two dozen home-based businesses you can start using your
PC.

3. How to Make Money at Home With Your PC II: Portfolio Management.
Whether you manage your own portfolio for investment gains, or you
take on clients for a consulting fee, a PC can give you powerful
tools for portfolio management.  Meet three successful home-based
portfolio managers who use their PCs to maximize profits.  They'll
inspire you, and share some tricks of the trade that can help you
land clients and get started.  We'll also show you how to determine
which software applications will meet your needs, and which online
services will satisfy your requirements.

4. How to Make Money at Home With Your PC III: Telecommuting
Learn how to use your PC to telecommute to companies across America
that are looking for specialized consultants with skills like
bookkeeping, software design and programming, editorial and script
writing, technical proofreading, graphic design, copywriting, and
more.  Includes interviews with three successful telecommuters who
use their PCs, faxes, modems and phones to serve distant clients,
and information about a telecommuting referral service that could
help you find employers.

5. How to Upgrade Your Hard Drive, Step-By-Step
From choosing your new hard drive, through ordering, installing and
testing it.  This plain English video shows you how to do the job
correctly, one simple step at a time.  Using industry-wide
standards, we'll show you what all hard drives have in common. 
Includes how to determine if your controller will support a
particular hard drive.  How to remove the old drive, and install,
format and test the new drive.  Includes a discussion on the
differences between the various standards.

6. How to Design Your Own PC
You don't have to be an engineer to design and build the PC of your
dreams.  This plain English video shows you how to figure out the
PC design that is best for you, how to specify components, how to
make sure they'll work together, and where to buy them.  You'll end
up with a top quality system that will save you money.

7. How to Build Your Own PC
Once you've designed your PC, we'll show you how to build it.  The
actual process will take you only a few hours.  Using an easy-to-
understand method, we'll show you how to inspect, install and test
components.  Includes tips and tricks from computer production
experts.  The technical skills can be easily mastered by almost
anyone, and you probably already own most of the tools you would
need.
8. How to Increase Your Computer's Memory
This plain English video shows you how to determine whether your
computer memory can be increased, and how to do the job correctly,
one step at a time.  You'll learn about industry-wide standards for
memory, how to configure additional RAM and cache, how and where to
buy RAM chips, and three ways to eliminate low-quality RAM chips.
Covers all phases of the process from opening your computer, to
testing your memory.  Includes discussions on how to ensure your
DOS set-up is able to access all available memory, and how to use
various memory management software applications.

9. How to Use MS-Windows 3.1
This powerful graphical user interface can help you work smarter
and faster, but the manual and the online tutorial that come with
Windows leave many questions unanswered.  This plain English, step-
by-step video will show you how to install Windows on your computer
and set it up to get optimum performance.

10.  How to Find a Job in the Information Age
A PC can give you an incredible advantage when you're searching for
a new job -- or even a new career.  But you have to know just how
it can help you.  In this video, an experienced employment
counselor will show you how to tap the power in your PC to find job
leads, create a winning resume and customized cover letters, tap
into databases and find bulletin boards that will lead you to job
openings, and use online services to research potential employers.

11. How to Install a Sound Card in Your Computer
Here's how to add incredible stereo sound to your computer with
step-by-step help. In plain English, you'll learn how to determine
if your computer can support a sound card, how and where to buy a
high-quality sound card.  How to open your computer, and install
and test the sound card.

12. How to Install a CD-ROM Drive in Your Computer
Using simple tools, this plain English video shows you how to
install a CD-ROM Drive in your computer.  You'll learn how to make
sure your computer can support a CD-ROM drive -- and what to do if
it can't.  Covers internal vs. external drives, how and where to
buy a high quality CD-ROM drive, what you need to know about
differing industry standards, preparing the drive bay, testing and
trouble-shooting.  Covers SCSI and IDE.

13. How to Fix the Most Common Computer Problems
Your computer serviceman may not want you to know this, but all you
need is the know-how you'll get from this video, simple tools, and
easily-obtainable diagnostic software -- and you can fix most
common problems you'll ever encounter with a PC.

14. What to Do When a Virus Strikes Your Computer
Viruses can come from almost anywhere: a colleague or friend's
disks, a network, a bulletin board, even commercial software.  If
you ignore the first warning signs, a virus can wipe out your data
and permanently damage your computer's memory.  In plain English,
this video will tell you how to scan disks for viruses, how to
check downloaded files from bulletin boards, how to set up a virus
prevention program for your home or office computer, and how and
where to buy the best anti-virus software.  We'll also cover the
pros and cons of the antivirus software in DOS 6.X and Windows 3.X,
how to use antivirus software, and more.

15. How Your PC Works: Inside the Case
Here's a down-to-earth explanation of how your PC actually
processes information, and what really goes on inside the case. 
You'll get a guided tour of the insides of a PC, learn about how
the various components work and how they communicate with each
other, and get a clear explanation of technical terms.  A must for
anyone who wants to really understand how to program, use and
repair a PC.

16. How to Create Config.Sys, Autoexec.Bat and Batch Files
These basic files can make it much easier to use your computer --
or cause incredible headaches if they are not written properly for
your particular software and peripherals.  Now you don't have to be
at the mercy of murky tech manuals, because we'll show you how to
create files that work for your system -- step-by-step, in plain
English.  You'll learn how to write, modify and test Autoexec.Bat
and Config.Sys files; and how to create batch files.

17. How to Add a Modem or Faxmodem to Your Computer
Here's the easy way to add a modem or faxmodem to your computer,
with step-by-step guidance from this plain English video.  You'll
learn how to determine if your computer can support a modem or
faxmodem, and what to do if it can't, how to choose and buy the
best modem or faxmodem, how to open your computer, and install the
modem or faxmodem, how to test it, how to quickly eliminate common
problems, and how to set your modem or faxmodem correctly.

18. How to Make Money at Home With Your Computer
The information age is opening up incredible new opportunities for
PC owners to make undreamed of money, using skills and knowledge
you may already have!  Here's inside information on the ten most
promising telecommuting jobs and 12 small businesses you can run
right from your home, using your PC.  Includes profiles of PC
owners who are actually running PC-based home businesses.

19. The Super-Highway Roadmap
This is your guide to where to go and what to see.  You can make
incredible contacts and gather powerful, valuable information on
the Internet, but the problem is that most people can't begin to
imagine the potential of something that seems so abstract.  This
plain English video will introduce you to the Internet, and make
these opportunities concrete.  Includes interviews with 7 people
who did the impossible by gathering information and making contacts
on the Internet.

20. How to Upgrade and Repair Your PC I: Basic
This is the video your repairman doesn't want you to know about! 
Since the components of most PCs are highly modular, PC repair is
easier than you think.  Just pinpoint the problem component, unplug
it, remove a few screws, replace it, and presto! You're in business
again.  This step-by-step video shows you how to pinpoint problems
and replace your PC's components, using ordinary household tools.

21. How to Upgrade and Repair Your PC II: Multimedia
Here's how to save big money on a PC with all the latest multimedia
peripherals.  You learn how to determine if your PC can be
upgraded, how to upgrade your video card and bus, and how to add a
CD-ROM drive, sound card, video accelerator, and more.  Presented
in plain English.  The procedures you'll learn require ordinary
household tools -- nothing fancy!

22. Plain English Guide to DOS 6+.
The powerful sub-programs buried deep within DOS 6.0 and higher can
help you work smarter and faster, but the manual and the online
tutorial that come with DOS leave many questions unanswered. This
plain English, step-by-step video will show you how to install DOS
on your computer and set it up to get optimum performance. In
addition to DOS commands, you'll learn how to use the shell,
defragmentation, scan and antivirus programs that come with DOS.

23. Home Financial Management on a PC.
Your computer can help you create and manage a budget, keep track
of your credit card accounts, handle your tax deductions, and
reconcile your bank accounts.  But that's not all!  You can also
determine whether you should pay down your mortgage, finance a new
car or pay cash, buy or rent your home, and how much you'll need
for retirement.  The financial information your computer can give
you might mean the difference between just getting by and a very
comfortable lifestyle -- if you ask the right questions and use
your PC to develop a financial strategy.

24. The Online Bulletin Board Guide
Bulletin boards can be the on-ramps to the Information Super
Highway -- if you know how to access and use them.  This step-by-
step guide shows you how to find bulletin boards, set-up your
modem, log on, find out what they have to offer, find bulletin
board users who share your interests, search for information, and
upload and download files.


Thank you.

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

End of New-News digest
**********************


From daemon@vxw.ee.lbl.gov  Thu Apr 21 04:00:28 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr 21 04:00:41 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr 21 04:00:14 PDT 1994

        Subject: Re: WindC++ version of VxGDB on i960 does not work
        Subject: Re: More on C++ and Vxworks

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

Newsgroups: comp.os.vxworks
Subject: Re: WindC++ version of VxGDB on i960 does not work
Date: Mon, 18 Apr 1994 14:20:49 GMT
From: ckolli@hns.com (Chakravarthy Kolli)
Organization: Hughes Network Systems Inc.
Message-ID: <1994Apr18.142049.8098@hns.com>
References:  <9404051135.AA09511@zoo.lannet.com>
Sender: news@hns.com (USENET news system)

In article <9404051135.AA09511@zoo.lannet.com>, kruk@lannet.com (Meir Kruk) writes:
|> Hello,
|> 
|> I have a question to you vxWorks/C++ users out there. Has anyone worked 
|> with the VxGDB on a C++ application?
|> 
|> My problem is as follows:
|> 
|> I have installed an evaluation copy of WindC++ 1.0 beta on Sun4 station
|> running VxWorks 5.1.1 , for i960CA custom target.
|> I have started VxGDB, attached to the target, attached to tasks, etc.
|> VxGDB recognizes the C++ language , but I could not make it recognize
|> line numbers of C++ source, nor could I make VxGDB display the C++
|> source in any way.

    Shouldn't you be using VxGDB++?. VxGDB shuld not have a problem with
the excutable as 'c' is involved, but to display line info. you need
VxGDB++.

chak kolli

|> 
|> DEMONSTRATION PROCEDURE :
|> 
|> Compile/link a C++ application with -g, by using the following makefile:
|>    INC = -I$(VW)/h
|>    ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS
|>    all:  myProg.C
|>       CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C
|>       gnm960 -pv myProg.o | munch960 > __ctordtor.c
|>       gcc960 -g $(ARCH) -c __ctordtor.c
|>       gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o
|> 
|> Start VxGDB :
|>    vxgdb -t 960++ 
|> 
|> Attach target:
|>    target vxworks target_ip_addr vxWorks.st
|> 
|> Load the C++ application into the target from VxGDB and issue the
|> command "list" with either file name or function name.
|> 
|> The debugger reports:
|>    "No line number information"
|> 
|> Does this sound familiar to anybody?
|> 
|> 
|> Any help or suggestions would be appreciated.
|> 
|> Thanks,
|> 
|> Meir.
|> 
|> --------------------------------------------------------------------
|> Meir Kruk                             |      Email:  kruk@lannet.com
|> LANNET Data Communication Ltd.        |      Tel:      972-3-6458398
|> Atidim Technology Park,Bldg. 3        |      Fax:      972-3-6487146
|> Tel Aviv 61131, Israel                |
|> --------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: More on C++ and Vxworks
Date: 21 Apr 1994 07:35:04 +1000
From: rjl@f111.iassf.easams.com.au (Rohan LENARD)
Organization: EASAMS (Australia) Pty Ltd
Message-ID: <2p4768$kfg@f111.iassf.easams.com.au>
References: <9404151709.AA01331@atl.com>

In article <9404151709.AA01331@atl.com>,
>Since there is no "main" in your code, you have to invoke the two, 
>aforementioned global constructor and destructor functions explicitly.  
>This is done either using an "automatic" strategy or by calling the functions 
>"cplusCtors()" and "cplusDtors()", respectively.  All of this confusion is 
>described in the WindC++ users guide.

With gcc from Cygnus or from the appropriate ftp site, you can have a main,
and you just do _main to run it. No big deal (global and static constructors
are AUTOMATICALLY done for you)

>
>> Also, I have a 
>> problem using vxgdd and c++ code.  Every time I try to run a routine on
>> the target ('030) it says it cannot create task on target.  Any ideas?
>
>Vxgdb has problems with mangled function names.  If you have a C++
>function, it understands what to do if you issue the command "break func_name",
>but the command "run func_name" doesn't work (you get that cryptic message 
>about not being able to create a task).  Go figure....  However, it does
>understand the mangled version of the name.  (In fact, for member functions,
>even "break class::member" may not work; I can't recall just now....)
>

There's a simple solution here.  When you do run func_name it sends a command
to the VxWorks machine to spawn the task (using the rdb support in the kernel).
The kernel doesn't really know about C++, thus it needs the mangled names -
in the same way that starting a function from the debug login needs mangled
C++ names.  vxgdb is doing the right thing.  Now maybe I should ask cygnus to
get gdb to mangle the names before sending the request, but then that doesn't
help many other people :-)


Regards,
	Rohan


- -- 
- ----------------------------------------------------------------------------
rjl@iassf.easams.com.au	| "In the beginning there was cave man, and he had a
Rohan Lenard            |  club, which he used to seduce woman.  Hence the
+61-2-367-4555          |  saying `not tonight dear I've got a headache'"

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

End of New-News digest
**********************


From cpd@one.one.com  Thu Apr 21 05:17:54 1994
From: cpd@one.com (Chris P. Domin)
Date: Thu Apr 21 05:18:04 PDT 1994
Subject: 68k a.out to COFF conversion utility
Greetings.

I am a developer using Wind River's VxWorks development platform on a Sun-4.
I am currently trying to find a utility program, runnable on a Sun-4
workstation, which will convert a file from a.out format (in actuality,
VxWorks 68K object) to Unix System V COFF format (also 68K).  

Does anyone know if there is a standard utility which will do this conversion?

Regards,

Chris Domin


================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================
Open Networks Engineering (ONE)         Fax:       (313) 996-9908  
777 Eisenhower Pkwy, Suite 650          Voice:     (313) 996-9900 ext. (1) 232
Ann Arbor, Michigan 48108               Internet:  cpd@one.com
================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================


From dwampl@atl.com  Thu Apr 21 09:55:40 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Thu Apr 21 09:55:57 PDT 1994
Subject: Re: WindC++ version of VxGDB on i960 does not work

> Subject: Re: WindC++ version of VxGDB on i960 does not work
> ...
> |> I have installed an evaluation copy of WindC++ 1.0 beta on Sun4 station
> |> running VxWorks 5.1.1 , for i960CA custom target.
> |> I have started VxGDB, attached to the target, attached to tasks, etc.
> |> VxGDB recognizes the C++ language , but I could not make it recognize
> |> line numbers of C++ source, nor could I make VxGDB display the C++
> |> source in any way.
> 
>     Shouldn't you be using VxGDB++?. VxGDB shuld not have a problem with
> the excutable as 'c' is involved, but to display line info. you need
> VxGDB++.
> 
> chak kolli

The invocation of vxgdb for the 68k is "vxgdb -t 68k++".  Hence, I think that
his invocation (shown below) "vxgdb -t 960++" is correct.
 
> |> 
> |> DEMONSTRATION PROCEDURE :
> |> 
> |> Compile/link a C++ application with -g, by using the following makefile:
> |>    INC = -I$(VW)/h
> |>    ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS
> |>    all:  myProg.C
> |>       CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C
> |>       gnm960 -pv myProg.o | munch960 > __ctordtor.c
> |>       gcc960 -g $(ARCH) -c __ctordtor.c
> |>       gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o
> |> 
> |> Start VxGDB :
> |>    vxgdb -t 960++ 
> |> 
> |> Attach target:
> |>    target vxworks target_ip_addr vxWorks.st
> |> 
> |> Load the C++ application into the target from VxGDB and issue the
> |> command "list" with either file name or function name.
> |> 
> |> The debugger reports:
> |>    "No line number information"
> |> 
> |> Does this sound familiar to anybody?
> |> 

My 68k versions of the above commands look the same, except for the "coff" and
"-ACA".  I am not experiencing this problem.  I assume that -ACA flag is for 
the "960CA" processor.  I would guess that the "coff" format has something to 
do with this problem, but I don't know enough about either gdb or coff to
know....  Has WRS been any help?

> |> 
> |> Any help or suggestions would be appreciated.
> |> 
> |> Thanks,
> |> 
> |> Meir.
> |> 
> |> --------------------------------------------------------------------
> |> Meir Kruk                             |      Email:  kruk@lannet.com
> |> LANNET Data Communication Ltd.        |      Tel:      972-3-6458398
> |> Atidim Technology Park,Bldg. 3        |      Fax:      972-3-6487146
> |> Tel Aviv 61131, Israel                |
> |> --------------------------------------------------------------------
> 

Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|        "We begin bombing in five minutes...."  7:^]             |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+



From dwampl@atl.com  Thu Apr 21 09:56:33 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Thu Apr 21 09:57:04 PDT 1994
Subject: Re: More on C++ and Vxworks
> Subject: Re: More on C++ and Vxworks
> ... 
> In article <9404151709.AA01331@atl.com>,
 >
> >Vxgdb has problems with mangled function names.  If you have a C++
> >function, it understands what to do if you issue the command "break func_name",
> >but the command "run func_name" doesn't work (you get that cryptic message 
> >about not being able to create a task).  Go figure....  However, it does
> >understand the mangled version of the name.  (In fact, for member functions,
> >even "break class::member" may not work; I can't recall just now....)
> >
> 
> There's a simple solution here.  When you do run func_name it sends a command
> to the VxWorks machine to spawn the task (using the rdb support in the kernel).
> The kernel doesn't really know about C++, thus it needs the mangled names -
> in the same way that starting a function from the debug login needs mangled
> C++ names.  vxgdb is doing the right thing.  Now maybe I should ask cygnus to
> get gdb to mangle the names before sending the request, but then that doesn't
> help many other people :-)

There would be a problem if gdb tried to do this; gcc and "cfront" use slightly
different name-mangling algorithms.  Gdb would need to support both, since
"WindC++" uses cfront, while many people use the gcc for C++.
  
> 
> 
> Regards,
> 	Rohan
> 
> 
> - -- 
> - ----------------------------------------------------------------------------
> rjl@iassf.easams.com.au	| "In the beginning there was cave man, and he had a
> Rohan Lenard            |  club, which he used to seduce woman.  Hence the
> +61-2-367-4555          |  saying `not tonight dear I've got a headache'"
> 

Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|                 "I feel your pain...."  =:O]                    |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+


From enorgren@ehsl.mitre.org  Thu Apr 21 12:45:53 1994
From: enorgren@ehsl.mitre.org (Eric J Norgren)
Date: Thu Apr 21 12:46:02 PDT 1994
Subject: Serial I/F Boards / Drivers

Any assistance with the following questions would be greatly
appreciated.  Please send responses to the following:

	enorgren@ehsl.mitre.org

Thank you in advance for your help.

Eric Norgren

*********************************************************************
1. Has anyone purchased, developed, +/or implemented a VxWorks driver 
for a PTI-330 board?  Any information regarding work in progress on 
any PTI-330 VxWorks drivers would also be helpful.  

2. In a more general sense does anyone have any information on an
intelligent ( microprocessor-based )  8 serial port or better 
( ideally 16 ports ) VME-based communications interface board with
the following critical requirements:

	a. each serial port must support the "transparent" mode of
	operation.  This "transparent" mode is the transmission and
	reception of raw data without the application of any serial
	protocol.

	b. the source clock frequency for each serial channel must be
	able to be sourced from an external clock source.

	c. VxWorks driver support

Features which would be nice:

	a. DMA transfer capability
	b. VME-64 support
	c. Maximum baud rate of up to 1 Megabit/channel
*********************************************************************


From daemon@vxw.ee.lbl.gov  Sat Apr 23 04:00:21 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr 23 04:00:30 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr 23 04:00:12 PDT 1994

        Subject: NFS Download to memory
        Subject: Re: NFS Download to memory

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

Newsgroups: comp.os.vxworks
Subject: NFS Download to memory
Date: 20 Apr 1994 16:06:21 GMT
From: breen@inetgw.fsc.ibm.com ()
Organization: IBM
Message-ID: <2p3jtt$p61@eagle.bet.ibm.com>
Reply-To: breen@vnet.ibm.com

I need to download a large file, ~500 meg, from my host, a RS/6000, to
global memory on my VME chasis. Currently I am using 'open' and 'fioread'
to perform this download. The file is mounted via nfs and I can load it
at a rate of .415 megabytes/sec, which is too slow. Is there a way to
speed this transfer up by using some sort of caching?

I would appreciate it if anyone that had ideas on how to speed up this 
transfer from the host to the chassis could them to me or post them
to the group. Thanks in advance.



Scott




 Scott Breen                   	RSCS:           breen@owego
 Loral Federal Systems         	Email:          breen@vnet.ibm.com 
 D/324 B/304A MD/0534          	External phone: 607-751-6217      
 Owego, NY 13827               	Tieline:        662-6217	                       
  

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

Newsgroups: comp.os.vxworks
Subject: Re: NFS Download to memory
Date: Fri, 22 Apr 1994 17:33:34
From: anj@mail.ast.cam.ac.uk (Andrew Johnson)
Organization: Royal Greenwich Observatory
Message-ID: <anj.46.00118FBF@mail.ast.cam.ac.uk>
References: <2p3jtt$p61@eagle.bet.ibm.com>

Scott Breen writes:

>I need to download a large file, ~500 meg, from my host, a RS/6000, to
>global memory on my VME chasis. Currently I am using 'open' and 'fioread'
>to perform this download. The file is mounted via nfs and I can load it
>at a rate of .415 megabytes/sec, which is too slow. Is there a way to
>speed this transfer up by using some sort of caching?

>I would appreciate it if anyone that had ideas on how to speed up this 
>transfer from the host to the chassis could them to me or post them
>to the group. Thanks in advance.

You look like you're doing pretty well at the moment if you've got an Ethernet 
cable in there (10 Mega-bits per second raw physical rate).  I can't comment 
on how fast you could go, but I guess you'd find it hard to go very much 
faster.  If you need anything like an order of magnitude speedup, you'll have 
to use a hardware solution, and connect your RS/6000 to the VMEbus directly.  
Bit-3 sell a suitable MCA to VMEbus adapter card-pair which should give you up 
to something like 26 Mbytes/second. I would also check out Performance 
Technologies, and there may be other suppliers of similar adapters.


  _        _                   _     _
 / \ ___ _| |_ _ ___ _   _    | |___| |_ ___ ___ ___ ___
| - |   | . | ~_| -_| |~| |  _| | . |   |   |_ -| . |   |
|_|_|_|_|___|_| |___|_____| |___|___|_|_|_|_|___|___|_|_|

anj@mail.ast.cam.ac.uk        Royal Greenwich Observatory
Tel 0223-374823       Fax 0223-374700       Cambridge, UK

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

End of New-News digest
**********************


From daemon@vxw.ee.lbl.gov  Mon Apr 25 04:00:28 1994
From: daemon@vxw.ee.lbl.gov
Date: Mon Apr 25 04:00:37 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Apr 25 04:00:15 PDT 1994

        Subject: Re: X input extension
        Subject: Re: More on C++ and Vxworks

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

Newsgroups: comp.os.vxworks
Subject: Re: X input extension
Date: 22 Apr 1994 21:17:14 GMT
From: gene@visicom.com (Gene Kennon)
Organization: VisiCom Laboratories, Inc.
Message-ID: <2p9esq$9vt@corona.VisiCom.COM>
References: <2o0sim$iea@vmsfo.lys.vingmed.no>
Sender: -Not-Authenticated-[7339]

VisiCom has ported the X11R5 input extension client-side library to
VxWorks 5.1.1.  Although, not shipped with VX-Windows 2.0, it, along
with other extensions, will be included in the next release (also to
support Motif 1.2.4 for more memory leak fixes). 

VX-Windows customers can contact me for more details at (619) 457-2111.

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

Newsgroups: comp.os.vxworks
Subject: Re: More on C++ and Vxworks
Date: 25 Apr 1994 09:24:17 +1000
From: rjl@f111.iassf.easams.com.au (Rohan LENARD)
Organization: EASAMS (Australia) Pty Ltd
Message-ID: <2pev31$8fl@f111.iassf.easams.com.au>
References: <9404211653.AA02139@atl.com>

In article <9404211653.AA02139@atl.com>,
Dean Wampler (dwampl@atl.com) <dwampl@atl.com> wrote:
>:> Subject: Re: More on C++ and Vxworks
[..snip..]
>
>There would be a problem if gdb tried to do this; gcc and "cfront" use slightly
>different name-mangling algorithms.  Gdb would need to support both, since
>"WindC++" uses cfront, while many people use the gcc for C++.
>  

Maybe, maybe not.  Since vxgdb already supports both arm and gnu style name
demangling.  Once the name has been mangled, both schemes look identical
under VxWorks.  So all that is needed is to add support for arm style 
mangling.

Information on demangling from info page for gdb -
:: `set demangle-style STYLE'
::      Choose among several encoding schemes used by different compilers
::      to represent C++ names.  The choices for STYLE are currently:
:: 
::     `auto'
::           Allow GDB to choose a decoding style by inspecting your
::           program.
:: 
::     `gnu'
::           Decode based on the GNU C++ compiler (`g++') encoding
::           algorithm.
:: 
::     `lucid'
::           Decode based on the Lucid C++ compiler (`lcc') encoding
::           algorithm.
:: 
::     `arm'
::           Decode using the algorithm in the `C++ Annotated Reference
::           Manual'.  *Warning:* this setting alone is not sufficient to
::           allow debugging `cfront'-generated executables.  GDB would
::           require further enhancement to permit that.
:: 

Regards,
	Rohan








- -- 
- ----------------------------------------------------------------------------
rjl@iassf.easams.com.au	| "In the beginning there was cave man, and he had a
Rohan Lenard            |  club, which he used to seduce woman.  Hence the
+61-2-367-4555          |  saying `not tonight dear I've got a headache'"

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

End of New-News digest
**********************


From kruk@lannet.com  Tue Apr 26 07:56:44 1994
From: kruk@lannet.com (Meir Kruk)
Date: Tue Apr 26 07:57:06 PDT 1994
Subject: WindC++ version of VxGDB on i960 works

I would like to thank all who responed to my mail about "WindC++ version
of VxGDB on i960", especially Dean Wampler.

I have succeeded in activating the VxGDB on a C++ source files.

As I see, there is a problem in the compilation process. I have changed
the make file for the compilation process as following:

Old makefile:
-------------
   INC = -I$(VW)/h
   ARCH = -ACA -Fcoff -DCPU=I960CA -DVXWORKS
   all:  myProg.C
      CC960 -g -ansi -Wall -pipe -nostdinc $(INC) $(ARCH) +a1 +V -c myProg.C
      gnm960 -pv myProg.o | munch960 > __ctordtor.c
      gcc960 -g $(ARCH) -c __ctordtor.c
      gld960 -g -ACA -Fcoff -r -o myProg.out __ctordtor.o myProg.o

New makefile:
-------------
C1FLAGS = -ACA -Fcoff -g -I$(VW)/h -ansi -Wall -DCPU=I960CA -pipe -nostdinc -DVX_IGNORE_GNU_LIBS -c -E
CFLAGS = -ACA -Fcoff -g -I$(VW)/h -ansi -Wall -DCPU=I960CA -pipe -nostdinc -DVX_IGNORE_GNU_LIBS -c
LDFLAGS = -ACA -r -Fcoff
CCFLAGS =  +V -F -.i

.SUFFIXES : .o .C
.C.o:
	CC960 $(CCFLAGS) $(CFLAGS) $*.C
	/bin/cat $*.i | awk '{ if ((index ($$3, "__builtin_") > 0) || (index ($$3, "__alignof__") > 0) ) {next} else {print} }' > $*.c
	$(gcc960) $(C1FLAGS) -o $*.i $*.c
	sed -e '1d' $*.i > $*.i.tmp
	mv $*.i.tmp $*.i
	$(gcc960) $(CFLAGS) -o $*.o $*.i

all:	myProg.out

myProg.out: myProg.o
	gnm960 -pv myProg.o | munch960 > __ctordtor.c
	gcc960 -ACA -Fcoff -DCPU=I960CA -pipe -c __ctordtor.c
	gld960 $(LDFLAGS) -o myProg.out __ctordtor.o myProg.o


SPR 2496 in "WindC++ Gateway for i960 - Release Notes" describe's this 
solution for another problem. 


Meir.

--------------------------------------------------------------------
Meir Kruk                             |      Email:  kruk@lannet.com
LANNET Data Communication Ltd.        |      Tel:      972-3-6458398
Atidim Technology Park,Bldg. 3        |      Fax:      972-3-6487146
Tel Aviv 61131, Israel                |
--------------------------------------------------------------------


From LAJOIE@yalph2.physics.yale.edu  Tue Apr 26 13:01:53 1994
From: LAJOIE@yalph2.physics.yale.edu
Date: Tue Apr 26 13:02:06 PDT 1994
Subject: backplane load errors
I have a backplane network with 10 processors ( 4 Matrix MX330's and 6 GMS 
V49's); the network is set up to use mailbox interrupts and for the most 
part seems to work fine.  However, abot 30% of the time when I try to load 
an object file I get the following error message after a LONG pause (about 
4 minutes):


-> ld < aioTest.o
can't open input 'aioTest.o'
  errno = 0x36 (S_errno_ECONNRESET)

I'm not sure what this means, or how to fix the problem.  Any ideas?

John Lajoie
Yale University Physics Department
lajoie@yalph1.physics.yale.edu



From daemon@vxw.ee.lbl.gov  Wed Apr 27 04:00:26 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr 27 04:00:37 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr 27 04:00:17 PDT 1994

        Subject: ntp for VxWorks
        Subject: Re: More on C++ and Vxworks
        Subject: VxWorks emacs users - check out cc-mode
        Subject: How to cancel a message?
        Subject: Re: ntp for VxWorks

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

Newsgroups: comp.os.vxworks,comp.protocols.time.ntp
Subject: ntp for VxWorks
Date: 26 Apr 1994 17:29:42 GMT
From: michael@arc.nasa.gov
Organization: NASA Ames Research Center, Moffett Field, CA
Message-ID: <2pjj26$bre@news.arc.nasa.gov>
Reply-To: michael@arc.nasa.gov

Is there a version of ntp out there that will allow a VxWorks (Sun 1/E)
system to be an ntp server for some Sun Workstations?

Michael Pruznick
Sterling Software
NASA AMES Research Center.







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

Newsgroups: comp.os.vxworks
Subject: Re: More on C++ and Vxworks
Date: Tue, 26 Apr 1994 18:02:15 GMT
From: scotth@snake.com (Scott Herzinger)
Organization: Wind River Systems
Message-ID: <SCOTTH.94Apr26110217@snake.com>
References: <9404211653.AA02139@atl.com>
Sender: news@wrs.com (News Manager)

In article <9404211653.AA02139@atl.com> dwampl@atl.com (Dean Wampler (dwampl@atl.com)) writes:

   :> >Vxgdb has problems with mangled function names.  If you have a C++
   :> >function, it understands what to do if you issue the command "break func_name",
   :> >but the command "run func_name" doesn't work (you get that cryptic message 
   :> >about not being able to create a task).  Go figure....  However, it does
   :> >understand the mangled version of the name.  (In fact, for member functions,
   :> >even "break class::member" may not work; I can't recall just now....)
   :> >
....
   There would be a problem if gdb tried to do this; gcc and "cfront" use slightly
   different name-mangling algorithms.  Gdb would need to support both, since
   "WindC++" uses cfront, while many people use the gcc for C++.

In general, both the VxWorks shell and the WindC++ version of VxGDB
2.0 understand cfront-mangled names.

If the VxGDB command "run func_name" doesn't work, it's likely a
configuration problem, or maybe you're using a beta version (this
feature was somewhat broken during beta). By the same token, you
should be able to invoke, disassemble, etc. functions from the VxWorks
shell in the same way, e.g. "l func_name" or "sp func_name". If
func_name is overloaded, the user is prompted with a menu containing
the signatures of the various versions, and is permitted to choose the
desired one.

Some folks have noted the known problem in VxWorks 5.1.1 in which C++
support is not correctly initialized in src/config/usrExtra.c. This
problem, and the solution are documented in a Read Me First page in
the WindC++ package. It's important to go through the simple procedure
(one page, just a couple steps). Failing to do so will cause the shell
to fail to recognized cfront-mangled names.

Hope this helps.

Scott Herzinger
Wind River Systems

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

Newsgroups: comp.os.vxworks
Subject: VxWorks emacs users - check out cc-mode
Date: Tue, 26 Apr 1994 16:54:54 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems
Message-ID: <james.767379294@wrs.com>
Reply-To: james@wrs.com
Sender: news@wrs.com (News Manager)


If you use emacs to write code using WRS coding conventions, you
should check out cc-mode (in the archives, and recently posted to
gnu.emacs.sources).  It understands all of the WRS conventions, unlike
c-mode.  It's slower than c-mode, but not intolerably so.

Here's the entry from my .emacs file that I'm using to get WRS style:

(autoload 'c++-mode "cc-mode" "C++ Editing Mode" t)
(autoload 'c-mode   "cc-mode" "C Editing Mode" t)
(setq auto-mode-alist
      (append '(("\\.C$"  . c++-mode)
		("\\.cc$" . c++-mode)
		("\\.c$"  . c-mode)   ; to edit C code
		("\\.h$"  . c-mode)   ; to edit C code
		) auto-mode-alist))

(defconst wrs-c-style
  '("WRS Coding conventions"
    (c-tab-always-indent           . t)
    (c-hanging-braces-alist        . ((block-open after before)
				      (brace-list-open)))
    (c-hanging-colons-alist        . ((member-init-intro before)
				      (inher-intro)
				      (case-label after)
				      (label after)
				      (access-key after)))
    (c-cleanup-list                . (scope-operator
				      empty-defun-braces
				      defun-close-semi))
    (c-offsets-alist               . ((statement-block-intro . 0)
				      (defun-open            . 4)
				      (arglist-close         . 0)
				      (arglist-intro         . 0)
				      (class-open            . 4)
				      (class-close           . 4)
				      (topmost-intro-cont    . 4)))
    (c-echo-semantic-information-p . t)
    )
  "WRS Coding Conventions")

(defun wrs-c-mode-common-hook ()
  ;; set up for my perferred indentation style, but  only do it once
  (let ((my-style "WRS Coding conventions"))
    (or (assoc my-style c-style-alist)
	(setq c-style-alist (cons wrs-c-style c-style-alist)))
    (c-set-style my-style))
  
  ;; keybindings for both C and C++.  We can put these in c-mode-map
  ;; because c++-mode-map inherits it
  (define-key c-mode-map "\C-m" 'newline-and-indent)
  )

(add-hook 'c-mode-common-hook 'wrs-c-mode-common-hook)


- -- 
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
		   Why in the world is Volkswagen so obsessed
			     with far fig newtons?

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

Newsgroups: comp.os.vxworks
Subject: How to cancel a message?
Date: 26 Apr 1994 22:12:27 GMT
From: kendalla@pogo.wv.tek.com (Kendall P Auel)
Organization: Tektronix, Inc.,  Wilsonville, OR
Message-ID: <2pk3kb$q2g@gazette.wv.tek.com>
Reply-To: kendalla@pogo.WV.TEK.COM

If I have posted a message (msgQSend) and then later decide
to cancel it, is there an accepted method to remove it
from the message queue?  I can think of one or two ways
to hack out a solution but thought I would check here to
see if others have come up with a better way.  Thanks!

- -- 

Kendall Auel                  Tektronix, Inc.
kendalla@pogo.wv.tek.com      Wilsonville, OR

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

Newsgroups: comp.os.vxworks,comp.protocols.time.ntp
Subject: Re: ntp for VxWorks
Date: Wed, 27 Apr 1994 02:36:04 GMT
From: jfinley@netcom.com (John Finley)
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Message-ID: <jfinleyCowCK5.6My@netcom.com>
References: <2pjj26$bre@news.arc.nasa.gov>
Followup-To: comp.os.vxworks,comp.protocols.time.ntp

michael@arc.nasa.gov wrote:
: Is there a version of ntp out there that will allow a VxWorks (Sun 1/E)
: system to be an ntp server for some Sun Workstations?

: Michael Pruznick
: Sterling Software
: NASA AMES Research Center.

I guess you'd get synchronization, but for accuracy, the clock chip
on the 1E is pretty lousy off-the-shelf (the MK48T02, not the ticker)
You can tune it by poking some register, but I've never tried that.
Has anyone else tried tuning it? ("You can tune a 1E, but you can't
tune a" ... never mind.)

- ---
John Finley
jfinley@netcom.com
john@sd.aplabs.com

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

End of New-News digest
**********************


From daemon@vxw.ee.lbl.gov  Thu Apr 28 04:00:30 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr 28 04:00:38 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr 28 04:00:15 PDT 1994

        Subject: Re: ntp for VxWorks

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

Newsgroups: comp.os.vxworks,comp.protocols.time.ntp
Subject: Re: ntp for VxWorks
Date: Wed, 27 Apr 1994 13:16:28
From: anj@mail.ast.cam.ac.uk (Andrew Johnson)
Organization: Royal Greenwich Observatory
Message-ID: <anj.52.000D46A4@mail.ast.cam.ac.uk>
References: <2pjj26$bre@news.arc.nasa.gov>

In article <2pjj26$bre@news.arc.nasa.gov> michael@arc.nasa.gov writes:

>Is there a version of ntp out there that will allow a VxWorks (Sun 1/E)
>system to be an ntp server for some Sun Workstations?

Yes, look in the VxWorks archive (thor.atd.ucar.edu, although I haven't 
been able to connect to it recently) for ntpv3.1.tar.  It's not the latest 
version of ntp, and I think it's aimed at VxWorks 5.0.2 only.

I haven't actually tried it, I just know it's there.


  _        _                   _     _
 / \ ___ _| |_ _ ___ _   _    | |___| |_ ___ ___ ___ ___
| - |   | . | ~_| -_| |~| |  _| | . |   |   |_ -| . |   |
|_|_|_|_|___|_| |___|_____| |___|___|_|_|_|_|___|___|_|_|

anj@mail.ast.cam.ac.uk        Royal Greenwich Observatory
Tel +44 223-374823    Fax +44 223-374700    Cambridge, UK

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

End of New-News digest
**********************


From hebo@mbari.org  Thu Apr 28 09:01:51 1994
From: Bob Herlien <hebo@mbari.org>
Date: Thu Apr 28 09:01:59 PDT 1994
Subject: Re: comp.os.vxworks newsdigest
> In article <2pjj26$bre@news.arc.nasa.gov> michael@arc.nasa.gov writes:
> 
> >Is there a version of ntp out there that will allow a VxWorks (Sun 1/E)
> >system to be an ntp server for some Sun Workstations?
> 
> Yes, look in the VxWorks archive (thor.atd.ucar.edu, although I haven't 
> been able to connect to it recently) for ntpv3.1.tar.  It's not the latest 
> version of ntp, and I think it's aimed at VxWorks 5.0.2 only.

Yes, Steve Layton did the NTP 3.1 port for VxWorks.   His code uses my
original usrTime library which I did 2.5 years ago for the NTP 1.0 port.
I *think* (but haven't used it) that Steve's code was for 5.0.2, but I
would guess it should work on 5.1 just fine.  *My* code, however, was
written for VxWorks 4.x.  I mailed a version of usrTime for VxWorks 5.1.1
to the archive administrator over a month ago, but I haven't seen it show
up in the archives.  Paging Richard Neitzel...

If anybody wants a copy of the updated usrTime for vxWorks 5.1.1, send
me an email request.  [Note - usrTime is a libary of Unix compatible time
functions for VxWorks.  It includes time(), stime(), adjtime(), asctime(),
ctime(), gmtime(), localtime(), gettimeofday(), and settimeofday()].

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org


From busch@daacdev1.stx.com  Thu Apr 28 12:51:25 1994
From: Jim Busch <busch@daacdev1.stx.com>
Date: Thu Apr 28 12:51:37 PDT 1994
Subject: interrupt processing on a Heurikon/5.1


	When running a Heurikon 68040 and processing level 2 or level 3 
        interrupts of the values 64, 128 and 192 with a VxWorks 5.1 kernel, 
        a bus error is received which suspends the "tNetTask".  The processor 
        continues processing the interrupts until a second bus error is received
   which suspends the "tLogTask" and halts the processor.  The aforementioned 
        interrupts function perfectly on a Heurikon 68040 which is executing a 
        VxWorks 5.0.2 kernel.


        Why does this function properly with a 5.0.2 kernel but not with the 5.1
          kernel?   

        Are there files in VxWorks which need to be explicitly included when
          building the kernel in order to handle interrupts?

        Is there some limitation in the Heurikon BSP with respect to interrupts?
 
 Thanks...Jim


From hill@luke.atdiv.lanl.gov  Thu Apr 28 17:21:37 1994
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Thu Apr 28 17:21:45 PDT 1994
Subject: assert()

Hello all,

Perhaps it would be useful if the __assert() implementation under vxWorks
had a run time option that caused it to call logMsg() instead of fprintf()?
It also might be be useful if __assert() could be configured to call 
taskSuspend(taskIdSelf()) instead of abort() when debugging?

Jeff


______________________________________________________________________
Jeffrey O. Hill			Internet	hill@atdiv.lanl.gov
LANL MS H820			Voice		505 665 1831
Los Alamos, NM USA 87545	FAX		505 665 5107




From daemon@vxw.ee.lbl.gov  Fri Apr 29 04:00:20 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr 29 04:00:29 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr 29 04:00:12 PDT 1994

        Subject: re: comp.os.vxworks newsdigest
        Subject: Heurikon vs Motorola?

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

Newsgroups: comp.os.vxworks
Subject: re: comp.os.vxworks newsdigest
Date: 28 Apr 1994 18:07:18 GMT
From: thor@ymir.atd.ucar.edu (Rich Neitzel)
Organization: National Center for Atmospheric Research
Message-ID: <2pou0m$oj4@ncar.ucar.edu>
References: <199404281601.JAA24891@nak.berkeley.edu>
Sender: thor@ymir (Rich Neitzel)

In article <199404281601.JAA24891@nak.berkeley.edu>, Bob Herlien 
<hebo@mbari.org> writes:
|> > In article <2pjj26$bre@news.arc.nasa.gov> michael@arc.nasa.gov writes:
|> > 
|> written for VxWorks 4.x.  I mailed a version of usrTime for VxWorks 5.1.1
|> to the archive administrator over a month ago, but I haven't seen it show
|> up in the archives.  Paging Richard Neitzel...
|> 
It's in there now. Sorry, but the switch to Solaris 2 has been a higher
priority. Not to mention the flurry of updates wu-ftp has gone through :-{.

- -- 
Richard Neitzel thor@thor.atd.ucar.edu          Torren med sitt skjegg
National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000	                Gjx'i med sitt shinn
303-497-2057                                    jagar borni inn.

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

Newsgroups: comp.os.vxworks
Subject: Heurikon vs Motorola?
Date: 28 Apr 1994 21:42:04 GMT
From: cro@pathos.caltech.edu (John Cromer)
Organization: California Institute of Technology, Pasadena
Message-ID: <2ppajc$ik9@gap.cco.caltech.edu>

I'm having a difficult time choosing between Motorola and Heurikon CPUs
for a VxWorks VME system.  The MV167 family seems to get the latest 
releases of VxWorks first and to be discussed frequently on this group
as well as at the VxWorks users group meetings.  But, I guess since we're
not going to buy a hundred of them, Motorola seems to be fairly 
unresponsive with information, quotes, etc.  On the other hand, Heurikon
has a good reputation and they seem to be more responsive to our
inquiries.  The boards themselves (MVME167-032a vx HK68G/V4D) don't seem
to be that different technically.

Any of you VxWorks users have any comments in this regard -- testimonials,
flames, experiences pleasant and unpleasant?

Email or posts welcome.

John



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

End of New-News digest
**********************


From mea@mclean.sparta.com  Fri Apr 29 04:09:41 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Apr 29 04:09:56 PDT 1994
Subject: Re: interrupt processing on a Heurikon/5.1
Greetings!

> Submitted-by: Jim Busch <busch@daacdev1.stx.com>
> 
> 	When running a Heurikon 68040 and processing level 2 or level 3 
>         interrupts of the values 64, 128 and 192 with a VxWorks 5.1 kernel, 
>         a bus error is received which suspends the "tNetTask".  The processor 
>         continues processing the interrupts until a second bus error is received
>    which suspends the "tLogTask" and halts the processor.  The aforementioned 
>         interrupts function perfectly on a Heurikon 68040 which is executing a 
>         VxWorks 5.0.2 kernel.
> 
> 
>         Why does this function properly with a 5.0.2 kernel but not with the 5.1
>           kernel?   
> 
>         Are there files in VxWorks which need to be explicitly included when
>           building the kernel in order to handle interrupts?
> 
>         Is there some limitation in the Heurikon BSP with respect to interrupts?

Well, one possibility is that you have the CMC ENP10 card support routines
turned on.  They use Interrupt level 3 and Interrupt Vector 192 as their defaults.
Check your VxWorks by doing a:

-> lkup "attach"

If you see an enpattach, exattach or anything like that other than eiattach,
then you may be experiencing a conflict.  To solve this, simply go into the
config.h in the Heurikon's directory and do a:

#ifdef INCLUDE_ENP
#undef INCLUDE_ENP
#endif

If this is not the case and the Heurikon board is the V4D (the one with 
the VIC64 interface chip), then the problem could be a bug in the VIC64
arbiter.  There is a known problem with two signals (BBSY* and AM5) which
can occasionally glitch high.  This can cause bus errors because it can
result in two masters being on the bus at the same time.  The cause of the
problem is noise as a result of ground bounce due to an inadequate supply
of ground pins in close proximity to those two signal pins.  Cypress
is currently revising the VIC64 to ignore this noise.

A temporary fix for the BBSY* glitch is to use a separate system controller.
As for the AM5 glitch (a problem for D64 block transfers), it causes the 
slave VIC64 to see a different address modifier code during the cycle when
AM codes are supposed to be stable.  The symptom is a bus error on the 
*master's* cycle.  A temporary fix is to disable the enhanced turbo mode
in the block transfer definition register (bit 5) (I believe that 5.0.2
didn't enable this bit in the first place).  A 10-layer backplane
has also proven to be an effective measure against both of these problems.

I assume that this could be a problem for any board that uses the VIC64
chipset.  For a replacement VIC64 as soon as Cypress can do the rev, 
contact Heurikon (provided that it's a Heurikon board ;-) at (800) 327-1251.


Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      


From rcm@ssd.ray.com  Fri Apr 29 06:05:55 1994
From: Mandler <rcm@ssd.ray.com>
Date: Fri Apr 29 06:06:02 PDT 1994
Subject: Ethernet driver code
Greetings!
For an existing in-house project, we purchased a VxWorks source license to
build in enhanced libraries and make some other custom changes. One of the
changes was to the 'if_ln.c' ethernet driver to allow modification of the
logical address filter bits on the LANCE chip to support multicasting. At
present, I would like to incorporate similar changes into the mvme167 driver
for another project which has no source license. I thought I remembered
that driver code was available even without a source license, but I don't
see it in my 167 package. Am I remembering incorrectly, or is that code
available?
    _____________________________________________________________________
   |  Roland C Mandler,  Raytheon Equipment Division Portsmouth facility |
   |  1847 West Main Road,  Mail Stop 188                                |
   |  Portsmouth, RI  02871-1087  (401) 842-4228                         |
   |                                                                     |
   |    rcm@ssd.ray.com                                                  |
   |_____________________________________________________________________|



From mea@mclean.sparta.com  Fri Apr 29 08:05:23 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Apr 29 08:05:32 PDT 1994
Subject: Re:  Ethernet driver code
That driver is not included in source form for the MV167 BSP.  However,
it is available from Wind River for extra $$$.  I think that the 167
uses the Intel 82596 (if_ei.c) driver.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      


From hlg%matrx@concert.net  Fri Apr 29 08:11:48 1994
From: hlg@matrx.matrix.com (Louis Gray)
Date: Fri Apr 29 08:11:56 PDT 1994
Subject: Re: comp.os.vxworks newsdigest 
Bob,

If it wouldn't be too much trouble, I would like to get a copy of your
usrTime library.  My user address is:

	hlg@matrix.com

Thanks In advance,

-- 
- HL -

===============================================================================

"We conclude that the Texas Constitution accords individuals greater safeguards
 to their personal freedom than its federal counterpart does."
					   - Texas Third Court of Appeals, 1992



From mea@mclean.sparta.com  Fri Apr 29 08:18:25 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Apr 29 08:18:36 PDT 1994
Subject: RE: Heurikon vs. Motorola
Greetings!

  Here at SPARTA, we use oodles of the Heurikon boards in our projects.
I have always had quite good responsiveness from Heurikon sales
critters as well as Heurikon hardware/software tech support.  Their
warranty is 1 year on the boards and they provide free tech support
for that year via their 800 number.  Yes, they tend to lag behind
WRS in their release shedule by 2-4 months.  However, when you get
the BSP, it also tends to be both better debugged and well tuned
to take advantage of the on-board features such as DMA controllers.

  Motorola has NEVER been very responsive to me.  Of course, I only
use a few hundred CPUs a year, so I don't tend to attract their
attention.  You may also notice that you see more problems 
regarding Motorola products here on the net.  Whether that's 
due to just more Motorola boards being out there, or there really
are more problems with them is unclear, however.  For my money
(and sanity) I'd pick Heurikon over Motorola every time.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      


From tweadon@sadira.gb.nrao.edu  Fri Apr 29 10:31:33 1994
From: tweadon@sadira.gb.nrao.edu (TIM WEADON)
Date: Fri Apr 29 10:31:42 PDT 1994
Subject: RE: Heurikon vs. Motorola
We don't have the number of cards that SPARTA does but I have to say that
we have had excellent technical support on all our Motorola products. 

Tim Weadon
National Radio Astronomy Observatory
Green Bank, WV. 


From daemon@vxw.ee.lbl.gov  Sat Apr 30 04:00:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr 30 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr 30 04:00:13 PDT 1994

        Subject: VxWorks and BOOTP information needed
        Subject: Help! How to run code in ROMs but not is OS.
        Subject: Re: Heurikon vs Motorola?

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

Newsgroups: comp.os.vxworks
Subject: VxWorks and BOOTP information needed
Date: Fri, 29 Apr 1994 14:08:27 GMT
From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld)
Organization: Hollandse Signaal apparaten BV
Message-ID: <1994Apr29.140827.23919@hgl.signaal.nl>
Sender: usenet@hgl.signaal.nl (USENET News System)

Hello,

I need to use a VxWorks target on ethernet via a 'bootp' server.
The server is a SUN workstation (SunOS 4.1.x).
The VxWorks 5.1.1 target has 'bootp' functionality built in the bootprom.

question :
*********     "is there someone out there who has got vxworks and
	       bootp working on SUN ?"

We tried the 'unsupported' VxWorks 5.1.1 version of the 'bootp' software.
It will not work.

Please email me.




	--Ben--


- -- 
==============================================================================
= B.J.M. Vloedbeld    Dept:SDA-DID-DIM   Org:Hollandse Signaalapparaten B.V. =
= Adress : P.O.box 42 7550 GD Hengelo, The Netherlands                       =
= Phone :+31-74-483994 FAX:+31-74-484009  email:bjm_vloedbeld@hgl.signaal.nl =
=============================================================[Unclassified]===

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

Newsgroups: comp.os.vxworks
Subject: Help! How to run code in ROMs but not is OS.
Date: 29 Apr 1994 11:20:47 -0500
From: sabolcik@natinst.com (Ross Sabolcik)
Organization: National Instruments, Austin, TX
Message-ID: <2prc4v$4ne@eagle.natinst.com>

Hello:

I am currently trying to find out if there is a way to determine if I
am running code from within the Bootroms, or in the loaded version of
the Operating System.

My problem is that I need to perform some system initialization only
once during the boot-up procedure.  Currently this initialization is
being done in sysHwInit() in sysLib.c.  sysHwInit() is called by
usrInit() in both bootConfig.c and usrConfig.c.  I want a piece of
code within sysHwInit to be run only in the bootConfig case.  I am
trying to determine if there are any global variables which tell me if
bootConfig or usrConfig is the calling routine?

Another possible solution is to modify the Makefile to only
conditionally include the code if sysLib.c is being built for the
bootRom target or the vxWorks(.st) target.  This final solution is
less than ideal since this code is destined for the BSP which must use
all of the default vxWorks stuff for the directory tree outside of
vw/config/target.

Any suggestions?

- --------------------------------------------------------------------------------
                                 Ross Sabolcik
                             VXI Software Engineer
                              National Instruments          
                           6504 Bridge Point Parkway
                             Austin, TX 78730-5039                             
- --------------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: Heurikon vs Motorola?
Date: 29 Apr 1994 17:29:45 GMT
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <2prg69$so@grover.jpl.nasa.gov>
References: <2ppajc$ik9@gap.cco.caltech.edu>

In article <2ppajc$ik9@gap.cco.caltech.edu>, cro@pathos.caltech.edu (John Cromer) writes:
|> I'm having a difficult time choosing between Motorola and Heurikon CPUs
|> for a VxWorks VME system.  The MV167 family seems to get the latest 
|> releases of VxWorks first and to be discussed frequently on this group
|> as well as at the VxWorks users group meetings.  But, I guess since we're
|> not going to buy a hundred of them, Motorola seems to be fairly 
|> unresponsive with information, quotes, etc.  On the other hand, Heurikon
|> has a good reputation and they seem to be more responsive to our
|> inquiries.  The boards themselves (MVME167-032a vx HK68G/V4D) don't seem
|> to be that different technically.
|> 
|> Any of you VxWorks users have any comments in this regard -- testimonials,
|> flames, experiences pleasant and unpleasant?
|> 
|> Email or posts welcome.

While I have had no experience w/ Motorola, I will say something about
Heurikon.  A while ago I bitched on the net about lack of support for
our VxWorks/Heurikon combination.  I would have to say that Heurikon
took this very seriously and took care of our immediate problems right
away and then took action to solve the problems overall.

Matt
- -- 
mwette@csi.jpl.nasa.gov

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

End of New-News digest
**********************


From stan@rti.com  Sat Apr 30 14:41:23 1994
From: stan@rti.com (Stan Schneider)
Date: Sat Apr 30 14:41:33 PDT 1994
Subject: Re: VxWorks and BOOTP information needed
>> Date: Fri, 29 Apr 1994 14:08:27 GMT
>> From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld)

>> question :
>> *********     "is there someone out there who has got vxworks and
>> 	       bootp working on SUN ?"
>> 
>> We tried the 'unsupported' VxWorks 5.1.1 version of the 'bootp' software.
>> It will not work.
>> 

We have bootp working from both SunOS 4 and Solaris hosts.  This is from the
notes, it was some time ago (i.e. no promises)...

  1. Create a file called "strings.h" with these contents (optional on SunOS4):
	#define bcopy(s, d, n)  memmove(d, s, n)
	#define bzero(d, n)  memset(d, 0, n)
	#define bcmp(b1, b2, n) memcmp(b1, b2, n)
	
	#include <string.h>

  2. Change '#include <strings.h>' to '#include "strings.h"' in all .c files

  3. Add '#include <fcntl.h>' and '<sys/termios.h>' to bootpd.c

  4. >>>> Change "char buf[1024]" to "int buf[1024]" in bootpd.c
                  ^^^^                ^^^
	This is the real problem---otherwise you get an alignment fault.  The
	code uses buf[] in all sorts of unorthodox ways; it has to be quad
	aligned!

  5. Change the makefile (Solaris only): 
	Add "-lnsl -lsocket" to the link libraries.

  6. Uncomment CONFFILE and DUMPFILE & set to local files (optional)

  7. make CC=gcc

  8. Add bootps and bootpc to NIS or NIS+ services database.

  9. Add your target to the ethers database.

 10. Make sure the permissions on the boot files, etc. are set so anyone can
     read them!

 11. Follow the normal instructions (i.e. set up your bootptab, su root, run
     "./bootpd -s", ...)

Drop me an email if you have any trouble; I can send you our complete sources &
makefile.  The real gotcha is #4; that took us a few hours to figure out.


        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================



From thor@thor.atd.ucar.edu  Sat Apr 30 23:00:15 1994
From: thor@thor.atd.ucar.edu (Rich Neitzel)
Date: Sat Apr 30 23:00:24 PDT 1994
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
------------------------------------------------
VxWorks sources:

total 8508
-rw-r--r--   1 thor     staff      22132 Jun 18  1990 ansi.p1
-rw-r--r--   1 thor     staff      22717 Jun 18  1990 ansi.p2
-rw-r--r--   1 thor     staff      24174 Jun 18  1990 ansi.p3
-rw-r--r--   1 thor     staff       8108 Jun 18  1990 ansi.patch1
-rw-r--r--   1 thor     staff      37126 Jun 12  1992 ansilib01
-rw-r--r--   1 thor     staff      18913 Jun 12  1992 ansilib02
-rw-r--r--   1 thor     staff       2671 Jan  2  1990 benchmarks
-rw-r--r--   1 thor     staff       7168 Jul 13  1989 bitcnt
-rw-r--r--   1 thor     staff      11437 Feb 15  1991 c++builtin.shar
-rw-r--r--   1 thor     staff      22330 Apr  4  1990 c++headers.p1
-rw-r--r--   1 thor     staff      22775 Apr  4  1990 c++headers.p2
-rw-r--r--   1 thor     staff      29052 Dec  6  1989 camaclib1
-rw-r--r--   1 thor     staff      25095 Dec  6  1989 camaclib2
-rw-r--r--   1 thor     staff      31005 Dec  6  1989 camaclib3
-rw-r--r--   1 thor     staff      37770 Dec 21  1989 cbench.shar
-rw-r--r--   1 thor     staff       7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--   1 thor     staff       5853 May 31  1989 crc.shar
-rw-r--r--   1 thor     staff       8917 Oct  9  1990 deadman.shar
-rw-r--r--   1 thor     staff      41669 Dec  6  1991 dhrystones01
-rw-r--r--   1 thor     staff      19170 Apr  1  1993 dirlib01
-rw-r--r--   1 thor     staff      25681 Aug 29  1989 dt1451
-rw-r--r--   1 thor     staff       5944 Apr 26  1989 fcompress.shar
-rw-r--r--   1 thor     staff      11561 Nov  1  1991 flags_class.shar
-rw-r--r--   1 thor     staff      44762 Jul 18  1990 force.p1
-rw-r--r--   1 thor     staff      40154 Jul 18  1990 force.p2
-rw-r--r--   1 thor     staff      80491 May  8  1989 force.shar
-rw-r--r--   1 thor     staff       2453 Mar 10  1993 gcc+68040
-rw-r--r--   1 thor     staff       6106 Oct 10  1989 getdate
-rw-r--r--   1 thor     staff       9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--   1 thor     rsf        12427 Apr 28 11:53 index
-rw-r--r--   1 thor     staff       2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--   1 thor     staff      35245 Oct  9  1990 joblib2.p1
-rw-r--r--   1 thor     staff      18110 Oct  9  1990 joblib2.p2
-rw-r--r--   1 thor     staff       9079 Apr  2  1990 lclflag.shar
-rw-r-----   1 thor     rsf       174829 Dec  3 15:49 lexyacc.tar.gz
drwxr-xr-x   2 thor     staff        512 Mar 21 12:15 libX11
-rw-r--r--   1 thor     staff      10747 Nov  3 11:54 libg++-2.5-src.patch
lrwxrwxrwx   1 root     other         20 Mar 19 19:08 libg++-2.5.1-src.patch -> libg++-2.5-src.patch
lrwxrwxrwx   1 root     other         20 Mar 19 19:08 libg++-2.5.2-src.patch -> libg++-2.5-src.patch
-rw-r--r--   1 thor     staff       1568 Nov  3 11:54 libgcc2-2.5.0.patch
-rw-r--r--   3 thor     staff       1545 Nov  3 11:55 libgcc2-2.5.2.patch
lrwxrwxrwx   1 root     other         19 Mar 19 19:08 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch
-rw-r--r--   3 thor     staff       1545 Nov  3 11:55 libgcc2-2.5.5.patch
-rw-r--r--   3 thor     staff       1545 Nov  3 11:55 libgcc2-2.5.6.patch
lrwxrwxrwx   1 root     other         15 Mar 19 19:07 libio-2.5.1.patch -> libio-2.5.patch
lrwxrwxrwx   1 root     other         15 Mar 19 19:08 libio-2.5.2.patch -> libio-2.5.patch
-rw-r--r--   1 thor     staff       1228 Dec 29 09:51 libio-2.5.patch
lrwxrwxrwx   1 root     other          6 Mar 19 19:07 libx11 -> libX11
-rw-r--r--   1 thor     staff       3515 Mar 16  1993 loadmeter.shar
-rw-r--r--   1 thor     staff      10399 May  4  1989 math.shar
-rw-r--r--   1 thor     staff      11950 May 30  1989 math2
-rw-r--r--   1 24       40         26655 Nov 15  1990 monitor.shar
-rw-r--r--   1 thor     staff      18733 Jun 14  1990 msgque_class.shar
-rw-r--r--   1 thor     staff     829713 Dec 17 08:10 ntpv3.1.tar.gz
-rw-r-----   1 thor     staff    1010176 Nov  8 13:42 ntpv3.tar.gz
-rw-r--r--   1 thor     staff       1082 Dec 14 09:09 objc.patch
-rw-r--r--   1 thor     staff      19422 Mar  1 07:25 ping01
-rw-r--r--   1 thor     staff      20494 Oct 31  1991 pipe.shar
-rw-r--r--   1 thor     staff      15418 May 30  1989 poolLib
lrwxrwxrwx   1 root     other          7 Mar 19 19:07 poollib -> poolLib
-rw-r--r--   1 thor     staff      13204 Oct 31  1991 ring.shar
-rw-r--r--   1 thor     staff       6614 May 31  1989 semCnt
lrwxrwxrwx   1 root     other          6 Mar 19 19:07 semcnt -> semCnt
-rw-r--r--   1 thor     staff       2308 Jan  2  1990 ss1.bnch
-rw-r--r--   1 thor     staff      41196 Oct 16  1992 stevie01
-rw-r--r--   1 thor     staff      35279 Oct 16  1992 stevie02
-rw-r--r--   1 thor     staff      35278 Oct 16  1992 stevie03
-rw-r--r--   1 thor     staff      35012 Oct 16  1992 stevie04
-rw-r--r--   1 thor     staff      34502 Oct 16  1992 stevie05
-rw-r--r--   1 thor     staff      37476 Oct 16  1992 stevie06
-rw-r--r--   1 thor     staff      30073 Oct 16  1992 stevie07
-rw-r--r--   1 thor     staff      31562 Oct 16  1992 stevie08
-rw-r--r--   1 thor     staff      37360 Oct 16  1992 stevie09
-rw-r--r--   1 thor     staff      20662 Oct 16  1992 stevie10
-rw-r--r--   1 thor     staff      25717 Oct 16  1992 stevie11
-rw-r--r--   1 thor     staff      28075 Oct 16  1992 stevie12
-rw-r--r--   1 thor     staff      31852 Oct 16  1992 stevie13
-rw-r--r--   1 thor     staff      16225 Oct 10  1989 string.shar
-rw-r--r--   1 thor     staff       8424 Apr  1  1992 syslog.shar
-rw-r--r--   1 thor     staff      15096 Oct  2  1991 task_class.shar
-rw-r--r--   1 thor     staff      16171 Oct  9  1990 taskmon.shar
-rw-rw-r--   1 root     other     416642 Jan  7 14:41 tclvx7.0v4.tar.gz
-rw-r--r--   1 thor     staff      10523 May 31  1989 tod.shar
-rw-r--r--   1 thor     staff      19912 Aug 27  1992 tp41.shar
-rw-r--r--   1 thor     staff      25790 Nov  8  1990 ty335.shar
-rw-r--r--   1 thor     rsf        44371 Apr 28 11:35 usrTime.shar
-rw-r--r--   1 thor     rsf         4945 Apr 28 11:31 veclist01
-rw-r--r--   1 thor     staff      25814 Apr 26  1989 vtape.shar
-rw-r--r--   1 thor     staff      43671 Nov 22  1991 vwcurses01
-rw-r--r--   1 thor     staff      40180 Nov 22  1991 vwcurses02
-rw-r--r--   1 thor     staff      38308 Nov 22  1991 vwcurses03
-rw-r--r--   1 thor     staff      31181 Nov 22  1991 vwcurses04
-rw-r--r--   1 thor     staff      31798 Nov 22  1991 vwcurses05
-rw-r--r--   1 thor     staff      31459 Nov 22  1991 vwcurses06
-rw-r--r--   1 thor     staff      24279 Nov 22  1991 vwcurses07
-rw-r--r--   1 thor     staff       5491 Dec  8 10:40 vx_cplusplus
-rw-r--r--   1 thor     staff      29720 Aug 28  1991 vxrsh.p1
-rw-r--r--   1 thor     staff      26002 Aug 28  1991 vxrsh.p2
-rw-r--r--   1 thor     staff      13713 Aug 28  1991 vxrsh.p3
-rw-r--r--   1 thor     staff       4702 Jan 16  1992 wdog_class
-rw-r--r--   1 thor     rsf         6851 Apr 28 11:53 xxx