From stan@rti.com  Wed Dec  1 00:31:15 1993
From: stan@rti.com (Stan Schneider)
Date: Wed Dec  1 00:31:25 PST 1993
Subject: Re: hole in the memory where the wind blows through...

>> Date: Mon, 29 Nov 1993 20:08:45 GMT
>> From: winans@xray.aps.anl.gov (John R. Winans)

>> Why does the following program continuously eat memory?
[...program deleted...]

>> When the file '/home/phebos/WINANS/dumbfile' is present (and has zero
>> bytes in it) the output from opener()'s memShow() says that I consume
>> 288 bytes each  time I go around the loop.  And once in a while, it
>> jumps by 1704.   

Well, I don't have time to figure out exactly _why_, but I can tell you who...

A display from HeapTrace after a bunch of fopen - fclose cycles:

    -> pFile = fopen(FileName, "r")
    pFile = 0x3ac190: value = 3840140 = 0x3a988c
    -> fclose(pFile)
    value = 0 = 0x0
    -> HeapTraceShow 10
     Blocks  Total   Call stack (to depth 10)
	7     1960  _funcCall _fopen _open _iosOpen _netOpen _netGet _ftpXfer 
                    _ftpHookup _socket _socreate
	1     1408  _ipintr _tcp_input _sonewconn _tcp_usrreq _tcp_attach
                    _tcp_newtcpcb _m_getclr _m_more _m_expand _m_clalloc


The 280-byte blocks (288 with header) are allocated by socreate.  The 1408-byte
block (that with a 288-byte block and header produces a 1704-byte jump) is an
mbuf allocated by m_clalloc down in the tcp code.

The 280-byte blocks are later reclaimed.  If you wait long enough, they are
freed (at least on my system).  Your "opener" program doesn't wait long
enough.  I imagine (guess) it has to do with the TCP socket shutdown state
machine.

The 1408-byte block appears to be permanently allocated.

This doesn't occur with an nfs-based kernel (as I posted last week).  I'll
leave it to the net.gods to explain the socreate buffering, it's after
midnight...


        -- 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  Wed Dec  1 04:01:58 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Dec  1 04:02:12 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec  1 04:01:48 PST 1993

        Subject: VME FDDI boards - info wanted
        Subject: Re: VME FDDI boards - info wanted
        Subject: Re: hole in the memory where the wind blows
        Subject: Re: VME I/O

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

Newsgroups: comp.os.vxworks
Subject: VME FDDI boards - info wanted
Date: 30 Nov 1993 12:35:15 -0600
From: KWAFFEN@syr.ge.com
Organization: UTexas Mail-to-News Gateway
Message-ID: <931130133905.2249d@syr.ge.com>
Sender: daemon@cs.utexas.edu

Hi-
I am looking for a VME based FDDI board which works with VxWorks. I will
need a couple of field tested (past beta site) boards early next year (jan), and
am hoping this news group has seen/used this type of board and can provide some 
insight, war stories, suggestions, warnings, vendor names, etc.

also - Can anybody point me in the right direction for finding/pricing cables
for FDDI (I need long lengths so optical cable is required)

thanx :-)

ps - my gateways news software seems to not post messages, so I am posting this
through mail - I am sorry if this message appears twice.

Kevin Waffenschmidt
kwaffen@gw.syr.ge.com



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

Newsgroups: comp.os.vxworks
Subject: Re: VME FDDI boards - info wanted
Date: Tue, 30 Nov 1993 18:52:34 GMT
From: mcgehee@icarus.tuc.noao.edu (Peregrine McGehee)
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Message-ID: <1993Nov30.115234@icarus.tuc.noao.edu>
References:  <931130133905.2249d@syr.ge.com>
Reply-To: mcgehee@icarus.tuc.noao.edu (Peregrine McGehee)
Sender: news@noao.edu

We have baselined our FDDI boards for the Gemini Telescopes Project as:
	Interphase 5211-D ($5995) which is supplied with a VxWorks driver
	Vx/DSP-5211-B Device Support Package.
This quote is from:
	CompuWare Corp, Scottsdale, AZ 602.998.8650
	They also will sell you source for the driver and test apps for ~$2K.

BTW:
	Does anyone have information on ATM boards and drivers???

Aloha,
	Peregrine

- --
Peregrine M. McGehee			Instrument Control Software Engineer
Gemini 8-m Telescopes Project		Internet: mcgehee@noao.edu

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

Newsgroups: comp.os.vxworks
Subject: Re: hole in the memory where the wind blows
Date: Tue, 30 Nov 1993 21:43:05 GMT
From: carroll@ast.saic.com (John Carroll)
Organization: SAIC
Message-ID: <1993Nov30.214305.12932@ast.saic.com>
References: <CH9ryM.FJG@mcs.anl.gov>
Reply-To: carroll@ast.saic.com
Sender: news@ast.saic.com

In article FJG@mcs.anl.gov, winans@xray.aps.anl.gov (John R. Winans) writes:
>
>Why does the following program continuously eat memory?
>
>=============================================================================
>#include <fcntl.h>
>#include <stdio.h>
> 
>opener()
>{
>  FILE  *pFile;
>  int   j;
>  char  FileName[] = "/home/phebos/WINANS/dumbfile";
> 
>  for (j=0; j<1000; j++)
>  {
>    pFile = fopen(FileName, "r");
>    fclose(pFile);
>    memShow(0);
>  }
>}
>opener2()
>{
>  int   fd;
>  int   j;
>  char  FileName[] = "/home/phebos/WINANS/dumbfile";
> 
>  for (j=0; j<1000; j++)
>  {
>    fd = open(FileName, O_RDONLY, 0);
>    close(fd);
>    memShow(0);
>  }
>}
>=============================================================================
>
>When the file '/home/phebos/WINANS/dumbfile' is present (and has zero bytes
>in it) the output from opener()'s memShow() says that I consume 288 bytes each 
>time I go around the loop.  And once in a while, it jumps by 1704.  
>
>When the file is not present at all, there is no memory leak.  It simply 
>appears that some memory was allocated and free'd again.
>

..

Results deleted

..

>It is also interesting to note that opener2() consumes the same 288 
>bytes-per-loop.  So I suspect that it is not the managemet of the buffers
>associated with the FILE structure.  
>
>To eliminate the possibility of this being caused by the FTP-based I/O 
>operations, could someone run the above code on an NFS based kernel?
>
>Do you guys out at WRS have anything to say about this?  Perhaps some docs 
>that I missed?
>
>By the way, the reason I need to be able to reopen files repeatedly is because 
>I have an application that must run continuously for more than 500 days at a 
>time.  And it must be able to re-read some configuration files via lex/yacc
>programs from time to time.  So far, I am putting up with the memory leaking 
>because I have not had the time to devote to it... read as "the thing does not 
>run long enough to consume itself" ;-)
>
>--John
>-- 
>! John Winans                     Advanced Photon Source  (Controls)    !
>! winans@mcs.anl.gov              Argonne National Laboratory, Illinois !
>!                                                                       !
>!"The large print giveth, and the small print taketh away." - Tom Waits !




>>>>> Summary of Results <<<<<

On VxWorks 5.02b (VADSworks 2.03b) for the MVME-167 there
is a memory leak when either DOS or NFS file systems attempt to
open files that do not exist using the "fopen" function.
The "open" function works without a memory leak on files that
do not exist.  Both functions work without leaking memory
on files that do exist.

What is interresting is that a memory leak occurs when opening and
closing a file that *does* exist using FTP using either open and not
fopen.

The following contains a listing of the memoryleak.c program
and the log of the results.  Look for ">>>> NOTE MEMORY LEAK <<<<"
to see the memory leaks in the log.

>>>> memoryleak.c program <<<<

#include <stdioLib.h>
#include <ioLib.h>
#include <vxWorks.h>
 
fopener( FileName, should_exist )
  char  *FileName;
  int   should_exist;
{
  FILE  *pFile;
 
  pFile = fopen(FileName, "r");
  if ( pFile == NULL )
  {
     if ( should_exist )
     {
       printf("\nFile %s ", FileName );
       printf( "does not exist\n" );
     }
  }
  else
  {
     if ( !should_exist )
     {
       printf("\nFile %s ", FileName );
       printf( "exists\n" );
     }
  }
  fclose(pFile);
}

opener( FileName, should_exist )
  char  *FileName;
  int   should_exist;
{
  int   fd;
 
  fd = open(FileName, O_RDONLY, 0);
  if ( fd == ERROR )
  {
     if ( should_exist )
     {
       printf("\nFile %s ", FileName );
       printf( "does not exist\n" );
     }
  }
  else
  {
     if ( !should_exist )
     {
       printf("\nFile %s ", FileName );
       printf( "exists\n" );
     }
  }
  close(fd);
}

memoryleak()
{
  char  NFSFileNameNoExists[] = "/home/gnc1/carroll/noexist";
  char  NFSFileNameExists[] = "/home/gnc1/carroll/junk";
  char  DOSFileNameNoExists[] = "DOS1:noexist";
  char  DOSFileNameExists[] = "DOS1:junk";

#define NUMBER_OF_FILES_TO_TEST 200

  int   i;

  printf( "\nStarting Memory Leak Test\n" );

  printf( "\nTesting NFS files that do not exist\n" );
    printf( "Testing fopen\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        fopener( NFSFileNameNoExists, 0 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );
    printf( "Testing open\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        opener( NFSFileNameNoExists, 0 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );

  printf( "\nTesting NFS files that do exist\n" );
    printf( "Testing fopen\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        fopener( NFSFileNameExists, 1 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );
    printf( "Testing open\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        opener( NFSFileNameExists, 1 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );

  printf( "\nTesting DOS files that do not exist\n" );
    printf( "Testing fopen\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        fopener( DOSFileNameNoExists, 0 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );
    printf( "Testing open\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        opener( DOSFileNameNoExists, 0 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );

  printf( "\nTesting DOS files that do exist\n" );
    printf( "Testing fopen\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        fopener( DOSFileNameExists, 1 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );
    printf( "Testing open\n" );
      printf( "\nMemory before the test\n" );
      memShow(0);
      printf( "\n" );
      for ( i = 0; i < NUMBER_OF_FILES_TO_TEST; i++ )
      {
        opener( DOSFileNameExists, 1 );
      } /* of for */
      printf( "\nMemory after the test\n" );
      memShow(0);
      printf( "\n" );

  printf( "\nEnding Memory Leak Test\n" );
}

>>>> Log of Results <<<<

>>> Login to the board <<<

%rlogin gncvme01

>>> Initialize the DOS DISK <<<
- -> < vxinit             
#
# Initialize the scsi device tables
#
..
- -> cd "/home/gnc1/carroll/gnc-code/memoryleak"
value = 0 = 0x0

>>> Copy a previously created file of 0 bytes <<<

- -> copy "junk", "DOS1:junk"                   
0 bytes copied.
value = 0 = 0x0
- -> cd "DOS1:"                                 
value = 0 = 0x0
- -> ls
JUNK
value = 0 = 0x0
- -> cd "/home/gnc1/carroll/gnc-code/memoryleak"
value = 0 = 0x0

>>> Run the program <<<

- -> ld < memoryleak.o
value = 0 = 0x0
- -> memoryleak
      
Starting Memory Leak Test

Testing NFS files that do not exist
Testing fopen

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15175484       22     689794  15156060
  alloc   1124036     7857        143        -
cumulative
  alloc   2309972     8784        262        -

>>>> NOTE MEMORY LEAK <<<<

Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   2317184     8984        257        -

Testing open

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   2317184     8984        257        -


Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   2317184     8984        257        -


Testing NFS files that do exist
Testing fopen

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   2317184     8984        257        -


Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   4009184     9584        418        -

Testing open

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   4009184     9584        418        -


Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   5693984     9984        570        -


Testing DOS files that do not exist
Testing fopen

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15168272       20     758413  15156060
  alloc   1131248     8057        140        -
cumulative
  alloc   5693984     9984        570        -

>>>> NOTE MEMORY LEAK <<<<

Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc   5701204    10184        559        -

Testing open

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc   5701204    10184        559        -


Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc   5701204    10184        559        -


Testing DOS files that do exist
Testing fopen

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc   5701204    10184        559        -


Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc  10630804    10784        985        -

Testing open

Memory before the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc  10630804    10784        985        -


Memory after the test
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free  15161052       16     947565  15156060
  alloc   1138468     8257        137        -
cumulative
  alloc  15553204    11184       1390        -


Ending Memory Leak Test
value = 25 = 0x19
- -> 

- -- 
John Carroll                                   | telephone: 619.458.5071
Science Applications International Corporation | fax: 619.558.1391
4161 Campus Point Drive MS E3R                 | email: carroll@ast.saic.com
San Diego, CA 92121                            |
- --


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

Newsgroups: comp.os.vxworks
Subject: Re: VME I/O
Date: Wed, 1 Dec 1993 05:23:15 GMT
From: carroll@ast.saic.com (John Carroll)
Organization: SAIC
Message-ID: <1993Dec1.052315.4456@ast.saic.com>
References: <9311302257.AA02532@lams.msd.lmsc.lockheed.com>
Reply-To: carroll@ast.saic.com
Sender: news@ast.saic.com

In article AA02532@lams.msd.lmsc.lockheed.com, markett@lams.msd.lmsc.lockheed.com (Ray Markett) writes:
>Version: VxWorks 5.1
>Host: Sun SparcStation 2
>Target: orVcpu30 ( 68030 3U VME )
>
>Our system is using two CPUs, a RAM card, and an ethernet card. We
>have the shared memory backplane network running for commuications between
>CPUs. We have sockets to workstatons and serial I/O to sensors and
>actuators. I've found sufficient documentation in the programmer's guide
>for these features, but I am having trouble with the following:
>
>I am adding an A to D board to the backplane (orVMIO 10 card with a VADC 
>21/22 piggyback card ). I am trying to latch a gate on the board
>by writing data to the appropriate address. It isn't working, and the
>money folks have taken away my VMetro bus analyzer :(. 
>The new card has short I/O base address 0xff1800.  Using m 0xff1800
>seems to work with the board in the backplane, and I get a bus error
>when I try to modify the address with the board pulled out of the
>backplane.
>
>I am trying to use memDrv and memDevCreate to create a psuedo I/O device, openthe device to get a file descriptor, and perform I/O with read and write. This"file like" I/O has worked well with the serial ports and sockets on VxWorks, and VME I/O on SunOS.  
>
>Is the way to go for VxWorks? Anyone have some sample code for VME I/O drivers
>and such?
>
>Any advice will be appreciated.
>
>Ray Markett


On the MVME-167 there is a sysLib routine to convert the short I/O address to the processor's
local bus address called sysBusToLocal.

Is this function available in your Board Support Package?

I don't know about the SPARC BSP but this function is required on the MVME-167 as it maps
short I/O to 0xffff0000.

John Carroll


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

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


From mitchell@harpo.aaec.com  Wed Dec  1 04:58:37 1993
From: mitchell@harpo.aaec.com
Date: Wed Dec  1 04:58:47 PST 1993
Subject: Re: VME I/O
>Submitted-by markett@lams.msd.lmsc.lockheed.com  Tue Nov 30 17:43:04 1993
>
>I am adding an A to D board to the backplane (orVMIO 10 card with a VADC 
>21/22 piggyback card ). I am trying to latch a gate on the board
>by writing data to the appropriate address. It isn't working, and the
>money folks have taken away my VMetro bus analyzer :(. 
>The new card has short I/O base address 0xff1800.  Using m 0xff1800
>seems to work with the board in the backplane, and I get a bus error
>when I try to modify the address with the board pulled out of the
>backplane.
>
>I am trying to use memDrv and memDevCreate to create a psuedo I/O device, openthe device to get a file descriptor, and perform I/O with read and write. This"file like" I/O has worked well with the serial ports and sockets on VxWorks, and VME I/O on SunOS.  
>
>Is the way to go for VxWorks? Anyone have some sample code for VME I/O drivers
>and such?

I've never used memDrv to access an I/O board, and doubt I ever will.  It
seems like an awful lot of overhead to read an A/D.  I always declare
structures that
look like the board as seen from VME, then assign the base address (after
sysBusToLocal) to a pointer to that structure.

Something like this:

struct AD_registers
{
  union
  {
    volatile short data;
  } r;

  union
  {
    volatile short control;
  } w;
}

struct AD_registers *ad_board;

ad_board = (struct AD_registers *)0xff1800;  /* should map with
sysBusToLocal */

ad_board->w.control = CONTROL_VALUE;
data = ad_board->r.data;


Using this structure for such a simple board is overkill, but you get the
idea.
The brave can use bitfields.  Many boards have "gaps" in thier address map
- which can be repesented by the proper sized array inside the structure.

Your problem may be that your board only responds to VME D16 (2-byte)
transfers.  The 'm' utility uses 2-byte transfers, the memDrv interface
probably uses 32 bit transfers (many CPU boards will break this up into two
D16 transfers (since you're in the A16 address space) using the 030/040
auto-bus sizing capabilities - but this would access two registers).  The
structure example above will force a D16 transfer (short), and also keep
gcc from getting overzealous in its optimizing (volatile).  This method
works quite well when there are many boards at contiguous addresses, then
you can do stuff like ad_board[3].r.data to get
the data from the fourth board.

Sun O/S requires you to use a VME device driver because of virtual memory,
multi-user, protection etc..  Why bring all that baggage into your RT
system?

hope this helps
acm
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |  

 
                                



From wdf@ferndown.ate.slb.com  Wed Dec  1 05:28:49 1993
From: wdf@ferndown.ate.slb.com
Date: Wed Dec  1 05:29:00 PST 1993
Subject: Re: hole in the memory where the wind blows through
John R. Winans wrote:

> Why does the following program continuously eat memory?
> :
> :
> To eliminate the possibility of this being caused by the FTP-based I/O 
> operations, could someone run the above code on an NFS based kernel?

My quick test showed that NFS open/close loses no memory, and fopen/fclose
loses 16 bytes. This is on 5.0.2b, which is probably not what you wanted !

Bill

 +-------------------------------------------------------------------------+
 | Bill Frewing                            Email: wdf@ferndown.ate.slb.com |
 | Schlumberger Technologies,              Phone: +44 202 893535           |
 | Ferndown Industrial Estate,             Fax:   +44 202 897097           |
 | Wimborne, Dorset,                       Telex: +51 41436                |
 | BH21 7PP, England                                                       |
 +-------------------------------------------------------------------------+


From lambert@cranky.ssc.gov  Wed Dec  1 06:14:57 1993
From: lambert@cranky.ssc.gov (David Lambert)
Date: Wed Dec  1 06:15:06 PST 1993
Subject: hole in the memory where the wind blows through
>> Why does the following program continuously eat memory?
>> :
>> :
>> To eliminate the possibility of this being caused by the FTP-based I/O 
>> operations, could someone run the above code on an NFS based kernel?

> My quick test showed that NFS open/close loses no memory, and fopen/fclose
> loses 16 bytes. This is on 5.0.2b, which is probably not what you wanted !
>
> Bill

Try adding the following to your startup file. By default VxWorks does not
close vestigial fds used by NFS.

#####
#
# Automatically close "extra" fds open on NFS read/writes.
nfsAutoClose=1


David Lambert
SSC Laboratories



From lambert@cranky.ssc.gov  Wed Dec  1 06:18:25 1993
From: lambert@cranky.ssc.gov (David Lambert)
Date: Wed Dec  1 06:18:38 PST 1993
Subject:  Re: hole in the memory where the wind blows through
  >> Why does the following program continuously eat memory?
  >> :
  >> :
  >> To eliminate the possibility of this being caused by the FTP-based I/O 
  >> operations, could someone run the above code on an NFS based kernel?
  
  > My quick test showed that NFS open/close loses no memory, and fopen/fclose
  > loses 16 bytes. This is on 5.0.2b, which is probably not what you wanted !
  >
  > Bill
  
  Try adding the following to your startup file. By default VxWorks does not
  close vestigial fds used by NFS.
  
  #####
  #
  # Automatically close "extra" fds open on NFS read/writes.
  nfsAutoClose=1
  
  
  David Lambert
  SSC Laboratories
  


From leonid@rst.hellnet.org  Wed Dec  1 06:36:05 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Wed Dec  1 06:36:13 PST 1993
Subject: Re: hole in the memory where the wind blows through...
The FTP I/O code in 5.0.x and 5.1 has a memory leak, it is SPR #2194,
and is supposed to be fixed in 5.1.1 that should be already out the door.
It is very simple to switch to RSH based I/O (or NFS) to quickly
get around thid problem though.
-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org


From daemon@vxw.ee.lbl.gov  Thu Dec  2 04:01:33 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Dec  2 04:01:43 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec  2 04:01:21 PST 1993

        Subject: Re: hole in the memory where the wind blows through...
        Subject: Re: Problems with large Standalone VxWorks
        Subject: Re: multicast

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

Newsgroups: comp.os.vxworks
Subject: Re: hole in the memory where the wind blows through...
Date: Wed, 1 Dec 1993 18:50:06 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems
Message-ID: <james.754771806@wrs.com>
References: <HEYES.93Nov22132356@dahp1.cebaf.gov> <anj.12.000A6411@mail.ast.cam.ac.uk> <CH9ryM.FJG@mcs.anl.gov>
Reply-To: james@wrs.com
Sender: news@wrs.com (News Manager)

winans@xray.aps.anl.gov (John R. Winans) writes:

>Why does the following program continuously eat memory?
<program deleted>
>Do you guys out at WRS have anything to say about this?  Perhaps some docs 
>that I missed?

It's not really loosing memory.  Check out Stan's message for more detail.
If you run a slightly modified version (file name changed, and a delay
added) you'll see what I mean:

#include <fcntl.h>
#include <stdio.h>
#include "memLib.h"

opener()
{
  FILE  *pFile;
  int   j;
  char  FileName[] = "/folk/james/zap/emptyfile";
  int   available;
  static int lastMem = 0;

  for (j=0; j<1000; j++)
  {
    pFile = fopen(FileName, "r");
    fclose(pFile);
    available = memPartAvailable (memSysPartId, 0, 0);
    printf ("change: %12d bytes, current available = %12d\n", available - lastMem, available);
    lastMem = available;
    taskDelay (5 * sysClkRateGet());
  }
}

You get:

(running on vxWorks 5.1.1)
- -> opener
change:      3145944 bytes, current available =      3145944
change:         -288 bytes, current available =      3145656
change:         -288 bytes, current available =      3145368
change:         -288 bytes, current available =      3145080
change:        -1704 bytes, current available =      3143376
change:         -288 bytes, current available =      3143088
change:         -288 bytes, current available =      3142800
change:         -288 bytes, current available =      3142512
change:        -1704 bytes, current available =      3140808
change:         -288 bytes, current available =      3140520
change:         -288 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
change:            0 bytes, current available =      3140232
...

- -- 
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
	 "Half of what he said meant something else, and the other half
			  didn't mean anything at all"

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

Newsgroups: comp.os.vxworks
Subject: Re: Problems with large Standalone VxWorks
Date: Wed, 1 Dec 1993 20:18:36 GMT
From: healy@nosc.mil (Mike Healy)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1993Dec1.201836.14462@nosc.mil>
References: <CH1vCt.791@leica.co.uk>
Sender: usenet@nosc.mil (Network News)

In article <CH1vCt.791@leica.co.uk> mikewd@leica.co.uk (Mike Wilmot-Dear) writes:
>
>We are having problems building a standalone VxWorks with our
>application linked in which seem to be related to the size of the
>executable. Although as far as we can see it should fit into memory.
>


We have a 5 meg vxWorks image with a 3.5 meg symbol table on one
of our boards. You have to upsize RAM_HIGH_ADDRESS in config.h
and in your Makefile. This is described somewhere in the WRS
documentation.

Mike Healy

healy@nosc.mil


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

Newsgroups: comp.os.vxworks
Subject: Re: multicast
Date: Wed, 1 Dec 1993 20:25:26 GMT
From: healy@nosc.mil (Mike Healy)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1993Dec1.202526.14549@nosc.mil>
References: <199311290041.AA05006@pike.ssd.ray.com>
Sender: usenet@nosc.mil (Network News)


I have been adding raw ethernet multicast support to
the vxWorks Force LANCE driver since 4.02. I gave the
changes to WRS but they didn't want to use it because
then they would have to support it across all platforms.

Mike Healy

healy@nosc.mil

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

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


From barry@mars.dgrc.doc.ca  Thu Dec  2 09:29:30 1993
From: barry@mars.dgrc.doc.ca (Barry Relf)
Date: Thu Dec  2 09:29:39 PST 1993
Subject: Appending to a file
Greetings!

I have a problem updating (ie: opening a file for append) using NFS from
vxWorks. I have tried using fopen() with a+ and open() with a O_RDWR and then 
FIOSEEK to the end of file.  Open() doesn't seem to support the O_APPEND flag.
When ever I attempt to update an existing file, the code doesn't complain, but 
a message is displayed on my console like:

/tmp/log: File exists.

and the file is not updated.  This message seems to display when I close the 
file.  Another problem I noticed, is that when I create my file with mode
0x644, the resulting file has mode 0x666!!

Can anyone help?

Thanks in advance.

Barry
---
Barry J. Relf 
Communication Research Centre
Ottawa, Ontario, Canada


From daemon@vxw.ee.lbl.gov  Fri Dec  3 04:01:54 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Dec  3 04:02:05 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec  3 04:01:41 PST 1993

        Subject: select system call
        Subject: Appending to a file over NFS
        Subject: BOOTP
        Subject: vxworks pseudo device driver?
        Subject: Re: BOOTP

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

Newsgroups: comp.os.vxworks
Subject: select system call
Date: Thu, 2 Dec 1993 14:55:20 GMT
From: kam@mr.picker.com (Ken Manley)
Organization: Picker International, NMR Division
Message-ID: <1993Dec2.145520.15348@picker.com>
Sender: news@picker.com

We have been experiencing some random, interrmittant, problems related
to the use of the select() system call. In trapping one instance of the
problem, select returned an indication that a single fd was ready to
be read, however, an examination of the bit mask returned showed that
(2) file descriptors had their related bits set. Has anyone else
experienced any problems with the call or have any clues as to what
the problem might be ?

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

Newsgroups: comp.os.vxworks
Subject: Appending to a file over NFS
Date: Thu, 2 Dec 93 14:35:55 GMT
From: barry@mars.dgrc.doc.ca (Barry Relf)
Organization: Communication Research Centre
Message-ID: <1993Dec2.143555.7662@clark.dgim.doc.ca>
Reply-To: barry@mars.dgrc.doc.ca
Sender: news@clark.dgim.doc.ca (#Usenet News)

Greetings!

I have a problem updating (ie: opening a file for append) using NFS from vxWorks.
I have tried using fopen() with a+ and open() with a FIOSEEK to the end of file. Open()
doesn't seem to support the O_APPEND flag.
When ever I attempt to update an existing file, the code doesn't complain, but a 
message is displayed on on console like:

/tmp/log: File exists.

and the file is not updated.  This message seems to display when I close the file.

Can anyone help?

Thanks in advance.

Barry
- ---
Barry J. Relf 
Communication Research Centre
Ottawa, Ontario, Canada
(613) 998-1469
               



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

Newsgroups: comp.os.vxworks
Subject: BOOTP
Date: Thu, 2 Dec 1993 20:05:54 GMT
From: farb@cc.bellcore.com(Glen Farbanish)
Organization: Bellcore
Keywords: BOOTP
Message-ID: <CHFBtv.Bxo@walter.bellcore.com>
Sender: farb@rockey (Glen Farbanish)

I am running vxWorks 5.0.3 (with some minor enh) for the 960 processor.  
My documentationdoes not talk at all about the Bootstrap Protocol
but I am prettysure vxWorks supports it.  True???  I know what BOOTP is but 
not how to use it.I need detailed info on how to use it on vxWorks or where I can find some.  

Thanks

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

Newsgroups: comp.os.vxworks
Subject: vxworks pseudo device driver?
Date: Thu, 2 Dec 1993 22:24:33 GMT
From: davem@micom.com (David Monachello)
Organization: Micom Communications Corp., Simi Valley, Ca.
Message-ID: <1993Dec2.222433.10950@micom.com>


hi,

I'm trying to add support for select() to a piece of code which is not a
vxworks device driver. Let call this piece of code the "foreign driver". 
I would like application code which is using the foreign driver to be 
able to block in a vxworks select() call waiting for event completion from 
the foreign driver and also from vxworks pipes and "normal" vxworks devices. 

Has anyone done something similar to this? I was thinking of writing a vxworks
device driver which would act as a surrogate for the foreign driver in the
select() call. When the foreign driver receives an event if would use the
selectLib call selWakeup() to inform select() that an event has occurred.

I'm looking for an example skeleton pseudo device driver as a starting point
for the surrogate driver. Does such a skeleton driver exist?

Anyway, thanks for help.

Dave Monachello
davem@micom.com
- -- 

**************************************************
* Dave Monachello @ Micom Communications Corp.   *
* email: davem@micom.com                         *

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

Newsgroups: comp.os.vxworks
Subject: Re: BOOTP
Date: Fri, 3 Dec 1993 00:30:05 GMT
From: kent@wrs.com (Kent Long)
Organization: Wind River Systems, Inc.
Keywords: BOOTP
Message-ID: <CHFo27.A3E@wrs.com>
References: <CHFBtv.Bxo@walter.bellcore.com>
Sender: news@wrs.com (News Manager)

farb@cc.bellcore.com(Glen Farbanish) writes:
>I am running vxWorks 5.0.3 (with some minor enh) for the 960 processor.  
>My documentationdoes not talk at all about the Bootstrap Protocol
>but I am prettysure vxWorks supports it.  True???  I know what BOOTP is but 
>not how to use it.I need detailed info on how to use it on vxWorks or where I can find some.  

The bootp protocol was added to VxWorks as part of the 5.1 release.  So,
you would have to upgrade to easily use bootp with your system.

The 5.1 documentation contains descriptions of how to use bootp with
VxWorks, along with a copy of the Carnegie-Mellon bootp server code
for use on hosts that do not have bootp as part of the standard
system (e.g. SunOS).

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com



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

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


From ericv@wrsec.fr  Fri Dec  3 06:16:12 1993
From: ericv@wrsec.fr (Ericv Eric Valette)
Date: Fri Dec  3 06:16:20 PST 1993
Subject: unsubscribe me



please  unsubscribe me 
exploder@wrsec.fr
	


From ericv@wrsec.fr  Fri Dec  3 06:16:25 1993
From: ericv@wrsec.fr (Ericv Eric Valette)
Date: Fri Dec  3 06:16:36 PST 1993
Subject: info



From daemon@vxw.ee.lbl.gov  Sat Dec  4 04:01:46 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Dec  4 04:01:56 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec  4 04:01:36 PST 1993

        Subject: Re: BOOTP
        Subject: Re: BOOTP
        Subject: Free lex and yacc for use with vxWorks

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

Newsgroups: comp.os.vxworks
Subject: Re: BOOTP
Date: Fri, 3 Dec 1993 14:42:20 GMT
From: thor@ymir.atd.ucar.edu (Richard Neitzel)
Organization: National Center for Atmospheric Research
Keywords: BOOTP
Message-ID: <1993Dec3.144220.17737@ncar.ucar.edu>
References: <CHFBtv.Bxo@walter.bellcore.com> <CHFo27.A3E@wrs.com>
Sender: thor@ymir (Richard Neitzel)

In article <CHFo27.A3E@wrs.com>, kent@wrs.com (Kent Long) writes:
|> The bootp protocol was added to VxWorks as part of the 5.1 release.  So,
|> you would have to upgrade to easily use bootp with your system.
|> 
|> The 5.1 documentation contains descriptions of how to use bootp with
|> VxWorks, along with a copy of the Carnegie-Mellon bootp server code
|> for use on hosts that do not have bootp as part of the standard
|> system (e.g. SunOS).
|> 
Of course, don't exspect to be able to use bootp on your VxWorks systems
as easy as that - at least not if you use the Tadpole TP41V (or any CPU
with the same BSP problem). Bootp realies on the fact that you identify
each managed target by its physical network address. WRS supplies a BSP
that hardcodes the physical address & only provides a routine in the
bootrom code to change that address. Unfortunately that routine is
interactive & I'm not excited about manually setting the address on
each boot. Worse, the runtime kernel undoes this, reverting to the
hardcoded address.

The obvious answer is to generate a seperate kernel for each target,
but that is exactly the opposite of what I see as bootp's utility
in the VxWorks world. I want to be able to generate one bootrom & one
runtime kernel & have my boards determine at boot time who they are.
I put in some code that reads the TP41V's switch block to generate
unique addresses, but I wish WRS would handle this instead of my having
fix it. 

- -- 
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: BOOTP
Date: 3 Dec 1993 16:22:22 GMT
From: mwette@csi.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Keywords: BOOTP
Message-ID: <2dnp3u$ef7@csi.jpl.nasa.gov>
References: <CHFBtv.Bxo@walter.bellcore.com> <CHFo27.A3E@wrs.com> <1993Dec3.144220.17737@ncar.ucar.edu>

In article <1993Dec3.144220.17737@ncar.ucar.edu>, thor@ymir.atd.ucar.edu (Richard Neitzel) writes:
|> In article <CHFo27.A3E@wrs.com>, kent@wrs.com (Kent Long) writes:
|> |> The bootp protocol was added to VxWorks as part of the 5.1 release.  So,
|> |> you would have to upgrade to easily use bootp with your system.
|> |> 
|> |> The 5.1 documentation contains descriptions of how to use bootp with
|> |> VxWorks, along with a copy of the Carnegie-Mellon bootp server code
|> |> for use on hosts that do not have bootp as part of the standard
|> |> system (e.g. SunOS).
|> |> 
|> Of course, don't exspect to be able to use bootp on your VxWorks systems
|> as easy as that - at least not if you use the Tadpole TP41V (or any CPU
|> with the same BSP problem). Bootp realies on the fact that you identify
|> each managed target by its physical network address. WRS supplies a BSP
|> that hardcodes the physical address & only provides a routine in the
|> bootrom code to change that address. Unfortunately that routine is
|> interactive & I'm not excited about manually setting the address on
|> each boot. Worse, the runtime kernel undoes this, reverting to the
|> hardcoded address.

I don't know exactly what's going on here, but I've been able to get
it to work OK.  When a SBC (single board computer) boots it broadcasts
its physical network address (in our case the ethernet number).  In
bootptab I associate that physical network address with a VxWorks
kernel sitting in /tftpboot on the boot host.  For our HKV4F

rtc1:\
        :sm=255.255.255.0:\
        :ht=ethernet:\
        :hd=/tftpboot/vxboot:\
        :ha=01.81.f9.02.01.cb:\
        :ip=138.159.180.21:\
        :bf=hkv4f.510.2:\
        :T17="bootHost:/export/root/rtc1":

This tells bootp to give "rtc1" the boot file
	/tftpboot/vxboot/hkv4f.510.2

In our case I like to run a start-up script that is unique to each
host.  The distributed bootp/VxWorks doens't support that :(.
However, later rfcs (can't remember which) defines a bootp tag (17)
for providing a root directory.  The version of bootp distributed w/
vxWorks allowes you to specify the tag via the "Txx" variable.  I've
modified the VxWorks kernel (all/usrConfig.c) to use this.  When my
VxWorks kernel (hkv4f.510.2) boots it mounts the directory bootHost
from the server, in this case
	bootHost:/export/root/rtc1	/
and then executes the startup script /vxinit.  This configuration is
similar to the way Sun handles diskless clients.  I even NFS mount
	bootHost:/export/exec/hkv4f
on /usr which provides misc binaries.  

Here's the "fix" for usrConfig.c.  There seems to be some problem,
either on the server or client side, which converts the tag id (17) to
0.  If someone knows where the problem is, I'd like to know.


*** usrConfig.c-orig	Fri Dec  3 08:19:17 1993
- --- usrConfig.c	Fri Dec  3 08:19:42 1993
***************
*** 1,3 ****
- --- 1,4 ----
+ #define MOUNT_VIA_BOOTP 1
  /* usrConfig.c - user-defined system configuration library */
  
  /* Copyright 1984-1992 Wind River Systems, Inc. */
***************
*** 544,549 ****
- --- 545,554 ----
      printf ("Memory Size: 0x%x.", sysMemTop () - (char *)LOCAL_MEM_LOCAL_ADRS);
      printf ("  BSP version %s.\n\n", bspVersion ());
  
+ #ifdef  MOUNT_VIA_BOOTP
+     bootpMountRoot();
+ #endif
+ 
  #ifdef	INCLUDE_STARTUP_SCRIPT			/* run a startup script */
      if (sysBootParams.startupScript [0] != EOS)
  	usrStartupScript (sysBootParams.startupScript);
***************
*** 619,621 ****
- --- 624,684 ----
      }
  
  #endif	/* INCLUDE_DEMO */
+ 
+ #ifdef MOUNT_VIA_BOOTP
+ #include "bootpLib.h"
+  
+ int
+ bootpMountRoot()
+ {
+     int ix;
+     char *ifName;
+     struct in_addr ipDest;
+     int port;
+     BOOTP_MSG bootpMsg;
+     u_int timeOut;
+     int code, leng;
+     char *roothost, *rootfsys, rootpath[128];
+     char *strchr();
+ 
+     ifName = "ei0";
+     ipDest.s_addr = htonl(hostGetByName("bootHost"));
+     port = 0;
+     memset(&bootpMsg, '\0', sizeof(bootpMsg));
+     bootpMsg.bp_hlen = 0;
+     bootpMsg.bp_vend[0] = 99;
+     bootpMsg.bp_vend[1] = 130;
+     bootpMsg.bp_vend[2] = 83;
+     bootpMsg.bp_vend[3] = 99;
+     bootpMsg.bp_vend[4] = 17;
+     bootpMsg.bp_vend[5] = 0;
+     bootpMsg.bp_vend[6] = 255;
+     timeOut = 300;
+     printf("Getting rootpath via bootp ."); fflush(stdout);
+     if (bootpMsgSend(ifName, &ipDest, port, &bootpMsg, timeOut) == OK) {
+       bootpMsg.bp_vend[bootpMsg.bp_vend[5]+6] = '\0';
+       for (ix = 4; ix < 64;) {
+ 	code = bootpMsg.bp_vend[ix++];
+ 	leng = bootpMsg.bp_vend[ix++];
+ 	if (code == 255) break;
+ 	if (code == 0) {		/* should be code == 17 !!! */
+ 	  memcpy(rootpath, &(bootpMsg.bp_vend[ix]), leng);
+ 	  rootpath[leng] = '\0';
+ 	  roothost = rootpath;
+ 	  rootfsys = strchr(rootpath, ':') + 1;
+ 	  rootfsys[-1] = '\0';
+ 	  nfsDrv();
+ 	  nfsAuthUnixSet("bootHost", 3450, 3260, 0, 0);
+ 	  nfsMount(roothost, rootfsys, "/");
+           cd("/");
+ 	  break;
+ 	}
+ 	ix += leng;
+       }
+       printf(".\n");
+     } else {
+       printf ("\nBOOTP attempt to get ROOTPATH failed, errno=%d\n", errno);
+     }
+     return 0;
+ }
+ #endif

- -- 
mwette@csi.jpl.nasa.gov

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

Newsgroups: comp.os.vxworks
Subject: Free lex and yacc for use with vxWorks
Date: Fri, 3 Dec 1993 23:21:30 GMT
From: winans@xray.aps.anl.gov (John R. Winans)
Organization: Argonne National Laboratory, Chicago Illinois
Message-ID: <CHHFJv.A44@mcs.anl.gov>
Sender: usenet@mcs.anl.gov

Over the past several weeks I have gotten a number of emails about lex and 
yacc sources.  Probably due to my posting in the fall about the use of them.
I have been recommending the use of flex, but had nothing to say for yacc,
because the only one I was aware of was bison, which carries a copyright
that makes it unattractive.  It simply says that you can only use it to create
software whose source and doc are to be freely available.

More recently, I have stumbled over the obvious... byacc.  It appears to be
fully functional and is the yacc that is shipped with teh NET2 release of
BSD UN*X.  And has a nice copyright.

Some of the folks here have done some minor hacking of the two packages so that
they generate C programs that have EVERYTHING defined as 'static' thus
making them suitable for use with vxWorks... that is you may place several
parsers into one object module w/o any trouble.

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

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

Anyway, they work the exact same way that the regular lex and yacc do, except 
that that since everything is static, you have to '#include' the lex-generated
program into your yacc-generated one and your yacc program has to have at least
one function that you put in it that is not static, if you ever wish to call it
from the outside world.  So then, a vxWorks shell callable yacc program 
(in a lex+yacc module) would look vaugely like this:

- --------------------------------------------------------------------
%%
YOUR YACC PROGRAM
%%

#include "lex.yy.c"

int MyYaccParser(char *f1)
{
  static int FirstFlag = 1;
 
  printf("processing file >%s<\n", f1);
 
  yyin = fopen(f1, "r");
  if (!FirstFlag) yyrestart(yyin);
  FirstFlag = 0;
  yyparse();
  fclose(yyin);
 
  return(0);
}
 
static int yyerror(char *str)
{
  printf("Error: %s\n", str);
  return(0);
}
- --------------------------------------------------------------------

If you download it, read all the README_JRW files.  They explain the above
as well as some other stuff... like the requirement for you to provide your
own static yyerror routine, the yyrestart stuff and so on.  When you
finish building byacc and flex, you should be able to do a make in my
ever-so-simple test directory and it should work (replace 'gcc' with any
other ansi compiler if you are not using gcc) and build 'prog' which an
'nm' command should show has no global 'yy' variables in it.

Have fun,
- --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 !

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

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


From satish@li.loral.com  Sat Dec  4 17:24:20 1993
From: Satish Mali <satish@li.loral.com>
Date: Sat Dec  4 17:24:27 PST 1993
Subject: Subscribe me for VxWorks user group

I could not reach vxwexplo-request@lbl.gov, hence this message is directed
to this account. I appreciate your help

Thank You

-satish


From mark@eminiar.jhuapl.edu  Mon Dec  6 11:09:23 1993
From: mark@eminiar.jhuapl.edu (Mark Switlick )
Date: Mon Dec  6 11:09:31 PST 1993
Subject: subscription
Mark D. Switlick
SFA Inc.
6 - S29
Johns Hopkins University Applied Physics Laboratory
Johns Hopkins Road, 
Laurel, Md. 20723-6099
Phone: 301-953-6000 ext 7321
mark@aplsun.jhuapl.edu

Currently I am working with vxWorks and VADSWorks in a MVME167 environment. 
The development platform is Sun 4.1+.  Applications are primarily 
communications over VME, Ethernet and FDDI.  I am new to this environment, but
I've been using vxWorks in other multi-processor environments, including other
Motorola, Mizar, Force and Heurikon cards.

Thank you for adding me to the exploder.

MDS


From markett@lams.msd.lmsc.lockheed.com  Mon Dec  6 13:48:39 1993
From: markett@lams.msd.lmsc.lockheed.com (Ray Markett)
Date: Mon Dec  6 13:48:49 PST 1993
Subject: Re: VME I/O
Many thanks to those who responded to my VME I/O questions. 

Ray Markett


From mmourier@netxwest.com  Tue Dec  7 10:47:07 1993
From: mmourier@netxwest.com (Marcelo C Mourier)
Date: Tue Dec  7 10:47:15 PST 1993
Subject: Non-blocking sockets in 5.0.2
How do you set up a socket for non-blocking operation in VxWorks 5.0.2? In BSD
Unix you do:

#include <socket.h>
#include <fcntl.h>

int sd;

sd = socket(.....);
fcntl(sd, F_SETFL, O_NONBLOCK);

5.0.2 doesn't have fcntl(), so how do you do it?

Thanks,

--
Marcelo


From daemon@vxw.ee.lbl.gov  Wed Dec  8 04:01:37 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Dec  8 04:01:45 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec  8 04:01:28 PST 1993

        Subject: NVRAM BOOT LINE
        Subject: Re: Non-blocking sockets in 5.0.2

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

Newsgroups: comp.os.vxworks
Subject: NVRAM BOOT LINE
Date: 7 Dec 1993 02:34:52 GMT
From: nam@peregrine.esl.com (Nam N. Nguyen)
Organization: Cornell Theory Center
Message-ID: <2e0q4c$85c@gatekeeper.esl.com>

I am using a FORCE 68K-40 board running vxWorks5.1 and am having this 
intermittent problem:  Once in a while, the boot line stored in the
non-volatile memory (at offset NV_BOOT_OFFSET) was clobbered up with
some garbage information, resulting in vxWorks not booting.

When this occurs in the lab, with Ethernet downloading, I can fix it 
easily by going into boot mode and correct the boot line's parameters.

However, when my computer is in stand-alone mode, without any 
interface to another computer, this causes serious problems.  So far,
when that happened, I had to connect a service terminal, modified the
boot line, and called function "sysNvRamSet()" to correct the non-volatile
ram.  But this is impossible in most cases.

Please help (via either e-mail or posting in this newsgroup).

Thank you very much,

Nam N.



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

Newsgroups: comp.os.vxworks
Subject: Re: Non-blocking sockets in 5.0.2
Date: 7 Dec 1993 23:14:28 GMT
From: litwin@litwin.jpl.nasa.gov (Todd Litwin)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Message-ID: <2e32ok$e27@elroy.jpl.nasa.gov>
References: <9312071807.AA05853@ajax.netx.com>

In article <9312071807.AA05853@ajax.netx.com> mmourier@netxwest.com (Marcelo C Mourier) writes:
>How do you set up a socket for non-blocking operation in VxWorks 5.0.2? In BSD
>Unix you do:
>
>#include <socket.h>
>#include <fcntl.h>
>
>int sd;
>
>sd = socket(.....);
>fcntl(sd, F_SETFL, O_NONBLOCK);
>
>5.0.2 doesn't have fcntl(), so how do you do it?

On 5.0.2b I do:

    #include <ioLib.h>

    int setting;

    setting = 1;
    ioctl(sd, FIONBIO, &setting);
- --
		Todd Litwin
		Jet Propulsion Laboratory
		(818) 354-5028
		litwin@robotics.jpl.nasa.gov

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

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


From pdw@sunbar.mc.duke.edu  Wed Dec  8 14:45:52 1993
From: "Patrick D. Wolf" <pdw@sunbar.mc.duke.edu>
Date: Wed Dec  8 14:46:01 PST 1993
Subject: X servers

Does anybody have experiance with X servers for the VME bus? I am familiar
with the Tadpole TPIGC and would be interested in hearing about experiances
with the Peritek and Vigra boards. Infomation about other vendors would also
be welcome.
Thanks in advance.

Please respond directly to:
pdw@sunbar.mc.duke.edu
Patrick Wolf
Department of Biomedical Engineering
Duke University
919-660-5114



From daemon@vxw.ee.lbl.gov  Thu Dec  9 04:01:41 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Dec  9 04:01:51 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec  9 04:01:31 PST 1993

        Subject: Looking for AT keyboard driver
        Subject: ISO9660 file system implementation
        Subject: Re: NVRAM BOOT LINE
        Subject: GNU ld and endl for g++
        Subject: Re: Appending to a file
        Subject: Training Schedules
        Subject: high speed TCP/IP with VxWorks

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

Newsgroups: comp.os.vxworks
Subject: Looking for AT keyboard driver
Date: 7 Dec 93 15:09:13 +0100
From: pquaaden@mswe.dnet.ms.philips.nl
Organization: Philips Medical Systems Nederland
Message-ID: <1993Dec7.150913.131656@mswe.dnet.ms.philips.nl>


Hi!

To interface an AT keyboard we are using an Intel 82C42PC chip with Phoenix 
firmware. Does anybody know whether driver software is available for this 
chip on a VxWorks platform??

Please, mail any remarks to

pquaaden@cardio1.ms.philips.nl

Thanks!

Peter Quaaden
Philips Medical Systems B.V.

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

Newsgroups: comp.os.vxworks
Subject: ISO9660 file system implementation
Date: 7 Dec 93 15:21:48 +0100
From: pquaaden@mswe.dnet.ms.philips.nl
Organization: Philips Medical Systems Nederland
Message-ID: <1993Dec7.152148.131657@mswe.dnet.ms.philips.nl>


Hi again!

Does anybody know whether an ISO9660 read-only file system implementation exists
for VxWorks??

Any remarks are welcome to:

pquaaden@cardio1.ms.philips.nl                  
  
Thanks!  
  
Peter Quaaden 
Philips Medical Systems B.V.      

~
~
~


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

Newsgroups: comp.os.vxworks
Subject: Re: NVRAM BOOT LINE
Date: Wed, 8 Dec 1993 15:53:28 GMT
From: miked@wrs.com (Mike Deliman)
Organization: Wind River Systems, Inc.
Message-ID: <CHq455.M7o@wrs.com>
References: <2e0q4c$85c@gatekeeper.esl.com>
Sender: news@wrs.com (News Manager)

In article <2e0q4c$85c@gatekeeper.esl.com> nam@peregrine.esl.com (Nam N. Nguyen) writes:
>I am using a FORCE 68K-40 board running vxWorks5.1 and am having this 
>intermittent problem:  Once in a while, the boot line stored in the
>non-volatile memory (at offset NV_BOOT_OFFSET) was clobbered up with
>some garbage information, resulting in vxWorks not booting.
>
>When this occurs in the lab, with Ethernet downloading, I can fix it 
>easily by going into boot mode and correct the boot line's parameters.
>
>However, when my computer is in stand-alone mode, without any 
>interface to another computer, this causes serious problems.  So far,
>when that happened, I had to connect a service terminal, modified the
>boot line, and called function "sysNvRamSet()" to correct the non-volatile
>ram.  But this is impossible in most cases.
>
>Please help (via either e-mail or posting in this newsgroup).
>
>Thank you very much,
>
>Nam N.

It is possible to override the NV_BOOT_LINE. One of my customers
recently needed this option, and had to use the DEFAULT_BOOT_LINE.

For the bootroms, you will need to modify bootConfig.c . For the kernel
image, usrNetwork.c (in $VX_BAP_BASE/src/config). 

Here's what I cooked up... (this is for the bootrom part, something
similar will need to be done for the kernel.):

- ------------------- begin included text (cut here) -------------------
What I'd do, is modify the usrBootLineInit code with IFDEF's. IFDEF out
the part that trys to use the NV_BOOT_LINE. If done right, the IFDEF
can be used to choose "use NV boot line" or "don't use NV boot line".
Below is an example of what *should* work!

- ------------------- begin included code (cut here) -------------------
/******************************************************************************
*
* usrBootLineInit - initialize system boot line
*
* Initializes system boot line as per specified start type.
* If this is a COLD boot, i.e., with CLEAR option to clear memory,
* then the boot line is initialized from non-volatile RAM, if any,
* otherwise from the compiled in default boot line.
*/

LOCAL void usrBootLineInit
    (
    int startType
    )
    {
    if (startType & BOOT_CLEAR)
        {
        /* this is a cold boot so get the default boot line */

#ifdef KEEP_NV_BOOT_LINE_IN           /* define to use NV_BOOT_LINE */

        if ((sysNvRamGet (BOOT_LINE_ADRS, BOOT_LINE_SIZE, 0) == ERROR)
||
            (*BOOT_LINE_ADRS == EOS))
            {
            /* either no non-volatile RAM or empty boot line */

            strcpy (BOOT_LINE_ADRS, DEFAULT_BOOT_LINE);
            }

#else   /* don't try to use NV_BOOT_LINE */

            strcpy (BOOT_LINE_ADRS, DEFAULT_BOOT_LINE);

#endif   /* KEEP_NV_BOOT_LINE_IN */
        }
    }
- ---------- end included text ------------


Good luck! Have a nice day....

           -mike
- -- 
- ------------------------------------------------------------------------------
  Mike Deliman, tech support hotline: 800-USA-4WRS, facsimile: 510-814-2164
        email:  miked@wrs.com (inet)  or [sun,uunet]!wrs!miked (uunet)
   Snail Mail:  Wind River Systems, 1010 Atlantic Ave, Alameda CA 94501 USA

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

Newsgroups: comp.os.vxworks
Subject: GNU ld and endl for g++
Date: Wed, 8 Dec 1993 18:37:05 GMT
From: wjasper@ds11.tx.ncsu.edu (Warren Jasper)
Organization: College of Textiles, North Carolina State University
Message-ID: <1993Dec8.183705.12274@ncsu.edu>
Reply-To: wjasper@tx.ncsu.edu
Sender: news@ncsu.edu (USENET News System)


Host: Sparc LX running Sun OS 4.1.3C
Target: MVME 167 running VxWorks 5.1
Compiler: gcc version 2.5.5

I have been trying for a week to make g++ into a cross compiler.  The problem
I found was that the loader from binutils, version 2.2 did not work
correctly.  The loader shipped with VxWorks is version 1.97.1  does the
trick.

Question:  Has anybody been able to cross-load g++ code using the gnu ld
version 2.2?  Is the problem with the new bfd library?

Also note:

extern "C" {
#include "vxWorks.h"
}

#include "/home/sun3/lib/g++-include/iostream.h"

extern "C" {
void __do_global_ctors();
void tester (int param);
}
void tester (int param)
{
    __do_global_ctors();
    cout << "  This is a Success. Isn't it? \n" ;
}  


Does not work.  I had the change the last line to:

    cout << "  This is a Success. Isn't it? \n" << endl ;

endl (endline) is a predefined ostream operation.  It should both insert
a newline and flush the ostream buffer.  Does anybody know why the ostream
buffer is not being flushed?

Thanks,

Warren
wjasper@tx.ncsu.edu


- -- 



	-- Warren

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

Newsgroups: comp.os.vxworks
Subject: Re: Appending to a file
Date: Wed, 8 Dec 1993 18:16:44 GMT
From: james@ystwyth.wrs.com (James Moore)
Organization: Wind River Systems
Message-ID: <JAMES.93Dec8101644@ystwyth.wrs.com>
References: <9312021729.AA02390@mars.dgrc.doc.ca>
Sender: news@wrs.com (News Manager)


In article <9312021729.AA02390@mars.dgrc.doc.ca> barry@mars.dgrc.doc.ca (Barry Relf) writes:

   When ever I attempt to update an existing file, the code doesn't complain, but 
   a message is displayed on my console like:

   /tmp/log: File exists.

   and the file is not updated.  This message seems to display when I close the 
   file.  Another problem I noticed, is that when I create my file with mode
   0x644, the resulting file has mode 0x666!!

   Can anyone help?

Looks like you're not using NFS, you're using netDrv.  Make sure
you're using filenames that don't look like "hostname:/foo/bar".  Any
time you see that "hostname:" element, it's a signal that you're using
netdrv.
- --
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
	 "Half of what he said meant something else, and the other half
			  didn't mean anything at all"

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

Newsgroups: comp.os.vxworks
Subject: Training Schedules
Date: 8 Dec 93 14:12:49 PST
From: meier@amazon.llnl.gov
Organization: Lawrence Livermore National Laboratory, NCD
Message-ID: <1993Dec8.141249.1@amazon.llnl.gov>

Could someone from Wind River please post a short list of the most recent
training class offerings, schedules, and costs.  I've tried the phone number
that I have, but it must be out of date - no one answers.

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

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

Newsgroups: comp.os.vxworks
Subject: high speed TCP/IP with VxWorks
Date: Wed, 8 Dec 1993 18:12:33 GMT
From: albertk@cs.kun.nl (Albert Koppes)
Organization: University of Nijmegen, The Netherlands
Message-ID: <CHqAKy.Jv0@sci.kun.nl>
Sender: news@sci.kun.nl (News owner)

As a followup to previous questions in this group, a more detailed
question about PPP over satellite.


Our future architecture: 

We have two hosts A and B:

One host A, a VME based processor running TCP/IP under 
VxWork.

The other host B , a VAX station running TCP/IP for OpenVMS.


Host A and B will communicate via a satellite link of 1 Mbps, and
will use about 10 TCP connections simultaneously.
We will be using PPP. 
Some of the TCP connections need to transfer data at a speed up to 200kbps, 
almost reaching the critical 10**5 bandwith*delay product. 


1. What is your opinion about the need for us to use extended window sizes ? 
The satellite link is supposed to have a BER of 10**(-7,-8).
 
2. Is anybody familiar with any implementation of extended windowsizes according to
RFC 1323 (or window scaling)  under VxWorks ?


3. Has somebody used PPP Protocol Field Compression and Address/Control Field
compression on such high speed links ? 


Thanks in advance for all suggestions and answers.
A summary will be provided to all interested.



Frank Zeppenfeldt
EUMETSAT
Germany



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

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


From mea@mclean.sparta.com  Thu Dec  9 08:35:41 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Dec  9 08:35:51 PST 1993
Subject: Re: PPP over satellites
Greetings!
 
Frank Zeppenfeldt writes:

> Our future architecture: 
> 
> We have two hosts A and B:
> 
... deleted ...
> 
> Host A and B will communicate via a satellite link of 1 Mbps, and
> will use about 10 TCP connections simultaneously.
> We will be using PPP. 
> Some of the TCP connections need to transfer data at a speed up to 200kbps, 
> almost reaching the critical 10**5 bandwith*delay product. 
> 
> 
> 1. What is your opinion about the need for us to use extended window sizes ? 
> The satellite link is supposed to have a BER of 10**(-7,-8).
>  
> 2. Is anybody familiar with any implementation of extended windowsizes according to
> RFC 1323 (or window scaling)  under VxWorks ?
> 
> 
> 3. Has somebody used PPP Protocol Field Compression and Address/Control Field
> compression on such high speed links ? 
> 

Our facility:  
                  #
                 / \                                                 
                /   \                                              
     A-( --- )-R     R-B-( ---- )-C                                       

Here at SPARTA we are using PPP via satellite running both VxWorks and
SunOS (X-Windows) code via a 9.6 KBit feed.  Not particularly speedy,
but quite effective (especially when using our compression software).
The "ping" times from A to C (via geosync sattelite and some
intermediate microwave hops and encryption hardware) are about 1.2
seconds.  We do use protocol/header compression (in addition to
compressing the data) and all of that seems to work well with a BER of
10**-6 or better.  I'm not familar with RFC 1323, but I doubt that our
implementation is using it.  The fastest I've run PPP is 56 KBPS, but
1 MBit should not represent a problem.

The issue with using PPP is that PPP by itself does not provide for
reliable transmission.  We sit PPP on top of HDLC LAP-B to deal with the
retransmissions at the data link layer and then use either our reliable
datagram protocol or TCP to handle the presentation/applications layer.
Of course, IP doesn't guarrantee delivery anyway.  So, your application
may not require the HDLC piece, but it does give you a bit more hedge/
buffering to make the link much more like a LAN.

Hope this helps,

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



From garyb@abekrd.co.uk  Thu Dec  9 16:14:15 1993
From: Gary Bartlett <garyb@abekrd.co.uk>
Date: Thu Dec  9 16:14:32 PST 1993
Subject: TTY driver LINE mode

Can  someone comment  on the  reason why  the VxWorks  5.1 TTY  driver's
OPT_CRMOD mode  converts NL to NL-CR  rather than the more  usual CR-NL.
Has anyone found that this causes problems with programs expecting CR-NL
end-of-line termination?   The 5.1  reference manual implies  that CR-NL
should be produced.

Thanks,
Gary


From daemon@vxw.ee.lbl.gov  Fri Dec 10 04:01:37 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Dec 10 04:01:46 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 10 04:01:26 PST 1993

        Subject: setsockopt
        Subject: Help With Interrupts

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

Newsgroups: comp.os.vxworks
Subject: setsockopt
Date: Thu, 9 Dec 1993 20:50:53 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: Bell-Northern Research, RTP, NC
Message-ID: <1993Dec9.205053.23588@nrtpa038.bnr.ca>
Sender: billag@b4pphff (Bill Gutknecht)

	Using: 	VxWorks 5.1
	H/W:	MVME 162-13

	What's the data structure passed to setsockopt when selecting
	SO_RCVTIMEO and SO_SNDTIMEO ???

	Thanks.

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

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

Newsgroups: comp.os.vxworks
Subject: Help With Interrupts
Date: 9 Dec 1993 23:37:08 GMT
From: edwink@orff.jpl.nasa.gov (Edwin Khachatourian)
Organization: JPL
Message-ID: <2e8cr4$18u@elroy.jpl.nasa.gov>

	Hi, I am in desparate need of help. I am using VxWorks 5.1 with a
68040 CPU on an MVME167 Chasis. I need to know how to set up an interrupt
routine that gets triggered upon the reception of a signal through the
serial or parallel ports. I also need to find out how to set up a time 
generated interrupt that gets triggered periodically (every 10 ms). I have
tried reading through the Vxworks manuals, and talking to the tech support
of Wind River Systems, but I haven't ben able to get anywhere.

	If anyone has example codes that can illustrate these things, please,
please, please, post them or Email them to: edwink@orff.jpl.nasa.gov

	I thank you all in advance, and I appreciate all the help I can get.





	Sincerely,
	Edwin Khachatourian
	/(o\
	\o)/


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

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


From garyb@abekrd.co.uk  Fri Dec 10 05:46:14 1993
From: Gary Bartlett <garyb@abekrd.co.uk>
Date: Fri Dec 10 05:46:25 PST 1993
Subject: tyDevInit sets errno to S_objLib_OBJ_UNAVAILABLE
Dear VxWorkers,

Can anyone tell me what/if I've done wrong.  I am creating my own serial
device driver  based on tyCoDrv.c.  I  have malloced space for  a TY_DEV
structure, and then called tyDevInit to initialise this structure.  This
call always  sets errno to 0x3d0002  (S_objLib_OBJ_UNAVAILABLE), despite
the fact that it returns OK (and the created device driver seems to work
perfectly).   Should I  be  setting something  in  the TY_DEV  structure
before calling tyDevInit()?

This is the code segment (VxWorks 5.1):

	STATUS myDevCreate(void)
	{
		TY_DEV_ID	pTyDev;

		pTyDev = (TY_DEV_ID)malloc(sizeof(TY_DEV));

		/* check for malloc failed omitted */

		/* errno here was 0 */
		if (tyDevInit(pTyDev, 512, 512, myTxStartup) != OK) {
			/* never reached */
			logMsg("tyDevInit() error\n");
			return (ERROR);
		}
		/* errno here is set to 0x3d0002 */

		/* goes on to call iosDevAdd() etc */
	}

Is this  a bug?  Do I  need to do  something else above?  Does  it sound
like I don't have a certain featured  selected in my BSP?  Or can I just
do an 'errno  = 0' after the successful call  to tyDevInit()?  It's very
disconcerting seeing errnos listed in my 'i' output.

Many thanks,
Gary


From mea@mclean.sparta.com  Fri Dec 10 06:20:50 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Dec 10 06:21:02 PST 1993
Subject: Re: Help with Interrupts
Greetings!

Edwin Khachatourian writes:

> 
> 	Hi, I am in desparate need of help. I am using VxWorks 5.1 with a
> 68040 CPU on an MVME167 Chasis. I need to know how to set up an interrupt
> routine that gets triggered upon the reception of a signal through the
> serial or parallel ports. I also need to find out how to set up a time 
> generated interrupt that gets triggered periodically (every 10 ms). I have
> tried reading through the Vxworks manuals, and talking to the tech support
> of Wind River Systems, but I haven't ben able to get anywhere.
> 

  There is already an interrupt service routine being used on your serial
ports.  Look in the tyCoDrv.c program for a routine name like "tyCoRxInt".
That routine is the receive interrupt routine for the serial ports.  If
you want to do additional work as the result of a receive character
interrupt, simply put the code in there *or* (a better solution) place
code in there to do interrupt-to-task communications (semGive, write to
a pipe, signal, etc.) and poke your task from the interrupt service
routine.  This technique is *better* because it minimizes the amount of
time in the ISR and improves the overall system latency.

  As for the periodic interrupt, there are several ways to do that one.
First, you could use watchdog timers, but you'll have to use sysClkRateSet
to set the system clock interrupt to 100 (10 ms interrupts).  However,
this technique suffers from clock skewing problems (you need to schedule
the next watchdog immediately after the first one goes off to do this,
but you will still get some skewing).

  The *best* way is to use one of the timers on the MVME167 PCC chip.
The WRS BSP doesn't turn these things on (at least not the 5.0.2 BSP)
so you'll have to look them up in the MVME167 manual and program them
accordingly.  There have been routines posted to the net that show how
to do this, but if you can't find them then e-mail me back and I'll
look through my stuff.  It turns out that there are many BSPs that don't
turn on all of the timers found on chips like the Zilog Z8536 CIO and
the Mot PCC.  That's what keeps us consultants in business ;-).

Hope this helps,


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


From chuckm@verdix.com  Fri Dec 10 06:50:14 1993
From: Chuck Meade <chuckm@verdix.com>
Date: Fri Dec 10 06:50:24 PST 1993
Subject: Re: comp.os.vxworks newsdigest 

>         Hi, I am in desparate need of help. I am using VxWorks 5.1 with a
> 68040 CPU on an MVME167 Chasis. I need to know how to set up an interrupt
> routine that gets triggered upon the reception of a signal through the
> serial or parallel ports. I also need to find out how to set up a time
> generated interrupt that gets triggered periodically (every 10 ms). I have
> tried reading through the Vxworks manuals, and talking to the tech support
> of Wind River Systems, but I haven't ben able to get anywhere.

Hi Edwin,

For the interrupt that you want to occur at 100Hz, I would use sysAuxClk
routines.  You can sysAuxClkRateSet(100) to get the interrupt to occur at 100
Hz, and you can use sysAuxClkConnect(funcPtr) to connect a routine to the
interrupt.  Then use sysAuxClkEnable() to start it running.

Chuck


From stan@rti.com  Fri Dec 10 08:25:26 1993
From: stan@rti.com (Stan Schneider)
Date: Fri Dec 10 08:25:35 PST 1993
Subject: Re: Help with Interrupts

>> Submitted-by mea@mclean.sparta.com  Fri Dec 10 06:20:50 1993

>>   The *best* way is to use one of the timers on the MVME167 PCC chip.
>> The WRS BSP doesn't turn these things on (at least not the 5.0.2 BSP)
>> so you'll have to look them up in the MVME167 manual and program them
>> accordingly.  There have been routines posted to the net that show how
>> to do this, but if you can't find them then e-mail me back and I'll
>> look through my stuff.  It turns out that there are many BSPs that don't
>> turn on all of the timers found on chips like the Zilog Z8536 CIO and
>> the Mot PCC.  That's what keeps us consultants in business ;-).
>> 

We have written a clock interface that allows VxWorks programs to easily
interface to multiple clocks.  We have drivers for the mv167 PCC clocks.  I'll
email a copy to all askers (or to the net if there's enough demand).  It's
often real useful to have 4 clocks instead of two!  BTW, if anyone is looking
to add clock drivers for other boards, you might want to take a look at our
driver structure...

        -- 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 hebo@mbari.org  Fri Dec 10 08:32:09 1993
From: Bob Herlien <hebo@mbari.org>
Date: Fri Dec 10 08:32:18 PST 1993
Subject: Re: comp.os.vxworks newsdigest 
> > serial or parallel ports. I also need to find out how to set up a time
> > generated interrupt that gets triggered periodically (every 10 ms). I have
> 
> For the interrupt that you want to occur at 100Hz, I would use sysAuxClk
> routines.  You can sysAuxClkRateSet(100) to get the interrupt to occur at 100
> Hz, and you can use sysAuxClkConnect(funcPtr) to connect a routine to the
> interrupt.  Then use sysAuxClkEnable() to start it running.

This works until you try to use spy(), which will grab sysAuxClk and reset
the rate on you.  This is rather annoying -- WRS apparently gives us a nice
set of auxiliary clock routines, and then takes them away if you want to
use another feature.

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


From Tracy_Dorsey@ccmail.gsfc.nasa.gov  Fri Dec 10 09:18:26 1993
From: Tracy_Dorsey@ccmail.gsfc.nasa.gov
Date: Fri Dec 10 09:18:36 PST 1993
Subject: card reboot signal




The following is an attached File item from cc:Mail.  It contains
eight bit information which had to be encoded to insure successful trans-
mission through various mail systems.  To decode the file use the UUDECODE
program.
--------------------------------- Cut Here ---------------------------------
begin 644 vx1
M``46```"``````````````````````````8````#````8@````,````%````
M90```0`````(```!90```!`````)```!=0```"`````"```!E0`````````!
M```!E0``"@!V>#$?__P`&JH&`!55!0`:J@2`%54$0!``!"`0``?P$```$!``
M`!`0```0$?S^$!```!`1_/X0$```$!'\`!`0```0$?S^$!```!`1_/X0$```
M$!``_A`0```0$?S^$!```!`1_/X0$```$!```!`0```0$```$!```!`?___P
M`````!___``?__X`'___`!___X`?___`'___X!____`?___P'___\!____`?
M___P'___\!____`?___P'___\!____`?___P'___\!____`?___P'___\!__
M__`?___P'___\!____`?___P'___\!____`?___P'___\!____``````])LL
M[_2;+.]+;0P`@````$U7,D1-5TE)````````````````````````````````
M`"X`+@`#````2`!(``````+:`BC_X?_B`OD"1@-'!2@#_``"````2`!(````
M``+:`B@``0```&0````!``$!`0````$G#P`!``$``````````````````@`9
M`9```````$`````````````!`````````````````````````H`!`````0``
M!A(!``(!+```````/``!`QJ```)F@```2(```$B```!(@```2(````$`#```
M(`X``/V`,S,`!@```````:````$````!;V8`````````"``)``$`````````
M`````````````````````````````HL```*+``````````````````````!:
M!`AACP`^5DP`0@-?``ABC0`_#6P`40-J``AC(0``````4@-X``ACFP``````
M4P.+``AD&@````!*T___``ADF`````!/[___``@``````BXE````$[D236EL
M97-T;VYE(%1E;7!L971E`````````````````````BX`````````````````
M````````````````````````````````````````````````````````````
M`````````````````````````````````````````````````````````8@!
M7@$T`0H`X`"V`(P`8@`X```````8``$`%0E(96QV971I8V$)2&5L=F5T:6-A
M````````````"@`#`!4`,````60```#*``D`````````````````````````
M````````````_____P```````````"#_____+@``(/____\N```@_____RX`
M`"#_____+@``(/____\N```@_____RX``"#_____+@``(/____\N```@____
M_RX``"#_____+@``(/____\N```@_____RX``"#_____+@``(/____\N```@
M_____RX``"#_____+@``(/____\N```@_____RX``"#_____+@``(/____\N
M```)```"R0```!``!0"$``8!```'`+,`"`"2````!@`````"R0```"H`````
M`C(```````$``````!4```````$``````#D```````$``````$8``````X@_
M/``QJ?`#DC\\`#&I\`.R/SP`,:GP`](_/``QJ?`$)C\\`#&I\`1Z/SP`,:GP
M!+H_/``QJ?`$\C\\`#&I\`4X/SP`,:GP!4P_/``QJ?`%9#\\`#&I\`6$/SP`
M,:GP!:0_/``QJ?`%Q#\\`#&I\`8J/SP`,:GP!I`_/``QJ?`&V#\\`#&I\`<:
M/SP`,:GP!X@_/``QJ?`'Y#\\`#&I\`@@/SP`,:GP"#8``%=EU7)E(')U;FYI
M;F<@86)O=70@-B!T87-K<R!O;B!A(&UV,30W(&-P=2!U<VEN9R!V>%=O<FMS
M(#4N,#(N(%=H96X@<')O8V5S<VEN9R!D871A(&9R;VT@=&AE('9M92!B=7,L
M('1H92!C<'4@8V%R9"!R96)O;W1S+B`@3W5R(&-O;G5R871I;VX@8V]N<VES
M=',@;VX@,R!M=C$T-R!C87)D<R!A;F0@;VYL>2!O;F4@<F5B;V]T<R!S;R!W
M92!A<'!E87)L96YT;'D@=&AE(')E8F]O="!S:6=N86P@;65T(&$@=GA7;W)K
M<R!S>7-T96T@<F5Q=6ER96UE;G1F:6=U<F%T:6]N(&-O;G-I<W1S(&]N(#,@
M;78Q-#<@8V%R9',@86YD(&]N;'D@;VYE(&-A<F0@<F5B;V]T<RP@<V\@=V4@
M87!P96%R;&5N=&QY('1H92!R96)O;W0@<VEG;F%L(&UE="!I<R!A('9X5V]R
M:W,@<WES=&5M(')E<75I<F5M96YT(&%N9"!N;W0@82!6344@8G5S(')E<75I
M<F5M96YT+B`@(%%U97-T:6]N("T@2&]W(&-A;B!W92!T96QL('5S:6YG('9X
M5V]R:W,@86YD(&ETU7,@9&5B=6=G:6YG(&-A<&%B;&ET:65S('=H:6-H('1A
M<VL@:7-S=65D('1H92!R96)O;W0@<VEG;F%L(&]R('=H870@=VAE<F4@=&AE
M(&QA<W0@:6YS=')U8W1I;VYS('!R;V-E<W-E9"!C86UE(&9R;VTN(%=E(&%L
M<V\@:&%V92!6344@8G5S(&%N86QY>F5R("!A="!O=7(@9&ES<&]S86P@:68@
M=')A8VMI;F<@979E;G1S(&]N('1H92!B=7,@=V]U;&0@8F4@:&5L<&9U;"X-
M#51H86YA;'EZ97(@(&%T(&]U<B!D:7-P;W-A;"!I9B!T<F%C:VEN9R!E=F5N
M=',@;VX@=&AE(&)U<R!W;W5L9"!B92!H96QP9G5L+@T-5&AA;FMS(&EN(&%D
M=F%N8V4@+2`-#51R86-Y($1O<G-E>2`@("`M+2T@("`@=')A8WE?9&]R<V5Y
M0&-C;6%I;"YG<V9C+FYA<V$N9V]V#0T@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`H,S`Q*2`R.#8M.3,Y,2`@("\@*#,P,2D@-3$S+34S
M-3,@`,<"'0``````%```MCP`"@"Y`$D`QP!>MD0````4``"V)``*``````%Q
M`F@`7@```!0``+9$``H`N0!E`,<"'0``````%```MCP`"@"Y`$D`QP!EMD0`
M```,``"V)`"Y`&4```'T`,<`90#'`AT```````'_``````']`"`L!3$@"&XP
M`````````````````````````$@`2`+2`AZ``(``@`"``````"``````````
M```_"_`!```,`````````````/\````````````````````"```````"_P@`
M```!_64``````?3__P`(``,```````````````````!(`$@"T@(>@`"``(``
M@``````@````````````/PO,`3$`#`````````````#_````````````````
M`````@```````?\``````0,`!A$&<0`(B6L```````````````````````0`
M2`!(`M("'@`*@`"``(``@``````P````````````/PNP`0,`#```````````
M``#_`````O`$5#\\`#6I\`2*/SP`-:GP!+(_/``UJ?`%*#\\`#6I\`5N/SP`
M-:GP!;`_/``UJ?`%[C\\`#6I\`9@/SP`-:GP!HX_/``UJ?`&OC\\`#6I\`=F
M/SP`-:GP",`_/``UJ?`*0C\\`#6I\`K:/SP`-:GP"VH_/``UJ?`+I#\\`#6I
M\`PD/SP`-:GP#&0_/``UJ?`,I#\\`#6I\`S>/SP`-:GP#30_/``UJ?`/FC\\
H`#6I\`_"/SP`-:GP$6H_/``UJ?`1T#\\`#6I\!'X/SP`-:GP$CX`````
  
end


From clegg@tesla.elen.ssd.fsi.com  Fri Dec 10 12:00:19 1993
From: ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg)
Date: Fri Dec 10 12:00:28 PST 1993
Hello,
I was wondering whether anybody has attempted to port the GNU
C compiler (V2.2.2) to VxWorks or the PC (OS2 or MSDOS 5.0)?
We have need of a portable GNU or other VxWorks compatible
Compiler/Assembler.

Thanks in Advance.
R. Clegg
FSI-SSD
"The best safety device in any plane is a well trained pilot"



From stan@rti.com  Fri Dec 10 12:46:33 1993
From: stan@rti.com (Stan Schneider)
Date: Fri Dec 10 12:46:43 PST 1993
Subject: Re: mv167 clock drivers

To all,

Yes, I know the PCC chip is the one VxWorks *does* use.  However, there are two
unused clocks on the vme2 chip; they're the ones our clock driver enables.

Sorry for the confusion.

PCC or VME2, the offer stands. :-)

        -- Stan
           stan@rti.com


From francis@wrs.com  Fri Dec 10 15:11:10 1993
From: "Francis St. Amant" <francis@wrs.com>
Date: Fri Dec 10 15:11:20 PST 1993
Subject: VxWorks training schedule
Timothy A. Meier writes in <1993Dec8.141249.1@amazon.llnl.gov>:
> Could someone from Wind River please post a short list of the most recent
> training class offerings, schedules, and costs.


The following are available VxWorks classes for Winter, 1994.  CA classes
are at the Wind River main office in Alameda California.  FL classes are at
our office in Orlando, Florida.


VxWorks Device Driver   (4 days-CA)     Dec. 13-16, 1993
VxWorks                 (5 days-CA)     Jan. 10-14 
VxWorks                 (5 days-FL)     Jan. 24-28
MicroWorks              (5 days-CA)     Jan. 31-Feb. 4
VxWorks                 (5 days-CA)     Feb. 7-11
VxWorks Device Driver   (4 days-CA)     Feb. 14-17
VxWorks                 (5 days-FL)     Feb. 28-Mar. 3
VxWorks                 (5 days-CA)     Mar. 14-18
VxWorks Device Driver   (4 days-CA)     Mar. 21-24


Please contact our Training Administrator, Anna Araneta, 510-814-2148
(voice), 510-814-2010 (fax), anna@wrs.com, for pricing and registration
information.

------------------------------------------------------------------------------
  Francis St. Amant             |       800-872-4977 voice
  Director of Customer Services |       510-814-2010 FAX 
  Wind River Systems            |       1010 Atlantic Avenue
  francis@wrs.com               |       Alameda, California, 94501 USA
------------------------------------------------------------------------------


From daemon@vxw.ee.lbl.gov  Sat Dec 11 04:01:37 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Dec 11 04:01:47 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec 11 04:01:29 PST 1993

        Subject: Porting "large" UNIX programs to VxWorks
        Subject: Re: Help With Interrupts
        Subject: Re: select system call
        Subject: Re: tyDevInit sets errno to S_objLib_OBJ_UNAVAILABLE
        Subject: ifShow network collisions - help

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

Newsgroups: comp.os.vxworks
Subject: Porting "large" UNIX programs to VxWorks
Date: 10 Dec 93 14:19:25 GMT
From: percosan@caip.rutgers.edu (Peter Percosan)
Organization: Rutgers Univ., New Brunswick, N.J.
Keywords: Global and static variables!
Message-ID: <Dec.10.09.19.24.1993.2068@caip.rutgers.edu>


Hello Net -

I am very new to VxWorks and, unfortunately, I am in the position of
having to port a UNIX utility that contains a large number global and
static variables.

The main issue here is that it may be possible for several "instances"
of the same program to be loaded into the system symbol table at once.
Clearly there will be a problem with symbol name clashes. Even worse,
it is possible for the application to be invoked once (initializing global
and static data, operating on this data, exiting) and then reinvoked
(with the global and static data in the state of the previous exit).

My question is: Is it possible to hide an application's symbols based
	        on an invocation?

I am sorry if this is a dumb question or has been addressed already.

Thanks
Pete Percosan
percosan@caip.rutgers.edu

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

Newsgroups: comp.os.vxworks
Subject: Re: Help With Interrupts
Date: Fri, 10 Dec 1993 21:37:25 GMT
From: chris@wrs.com (Chris Ford)
Organization: Wind River Systems, Inc.
Message-ID: <chris.755559445@wrs.com>
References: <2e8cr4$18u@elroy.jpl.nasa.gov>
Sender: news@wrs.com (News Manager)

I'll add my two cents to the replies that have already been posted.

edwink@orff.jpl.nasa.gov (Edwin Khachatourian) writes:
> ... I also need to find out how to set up a time 
> generated interrupt that gets triggered periodically (every 10 ms). I have
> tried reading through the Vxworks manuals ...

Because the MVME167 BSP supports an auxiliary clock, applications may use
that instead of the system clock.  A rate of 100 ticks per second will give
you a 10ms period.  Consult the on-line manual pages:

    % man mv167_sysAuxClkRateSet
    % man mv167_sysAuxClkConnect
    % man mv167_sysAuxClkEnable
    % man mv167_sysAuxClkDisable

Since the introduction of VxWorks 5.1, the config.h macros AUX_CLK_RATE_MIN
and AUX_CLK_RATE_MAX (defined as 3 and 5000 respectively for the MVME167 BSP)
tell you which rates are supported.

>	Sincerely,
>	Edwin Khachatourian

Have fun,
- -Chris Ford
 Wind River Systems

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

Newsgroups: comp.os.vxworks
Subject: Re: select system call
Date: 11 Dec 1993 01:20:45 GMT
From: claude@spc18.jpl.nasa.gov (Claude Felizardo)
Organization: Jet Propulsion Laboratory, Pasadena
Message-ID: <2eb79d$i2@elroy.jpl.nasa.gov>
References: <1993Dec2.145520.15348@picker.com>

In article <1993Dec2.145520.15348@picker.com>,
Ken Manley <kam@mr.picker.com> wrote:
>We have been experiencing some random, interrmittant, problems related
>to the use of the select() system call. In trapping one instance of the
>problem, select returned an indication that a single fd was ready to
>be read, however, an examination of the bit mask returned showed that
>(2) file descriptors had their related bits set. Has anyone else
>experienced any problems with the call or have any clues as to what
>the problem might be ?

  I guess I'm looking for the opposite.  Under Unix, a select() system
call can be interrupted by a signal but under vxWorks, it looks like the
only way I can return from a select() is if there is a socket to be
processed or it times out.  Is this correct?  The documentation doesn't
mention the EINTR that a unix man page mentions.  Do I have to enable
this or what?


- -- 
- -------------------------------------------------------------------
Claude A. Felizardo                      claude@kelvin.jpl.nasa.gov
Jet Propulsion Laboratory, M/S 525-3684              (818) 351-2341
4800 Oak Grove Dr., Pasadena, CA  91109

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

Newsgroups: comp.os.vxworks
Subject: Re: tyDevInit sets errno to S_objLib_OBJ_UNAVAILABLE
Date: Sat, 11 Dec 1993 01:51:35 GMT
From: kent@wrs.com (Kent Long)
Organization: Wind River Systems, Inc.
Message-ID: <CHuL60.MGH@wrs.com>
References: <13709.9312101205@ebony.abekrd.co.uk>
Sender: news@wrs.com (News Manager)


Gary Bartlett <garyb@abekrd.co.uk> writes:
>
>Can anyone tell me what/if I've done wrong.  

The good news is....nothing.  


>This
>call always  sets errno to 0x3d0002  (S_objLib_OBJ_UNAVAILABLE), despite
>the fact that it returns OK (and the created device driver seems to work
>perfectly).   

If the call returned OK, then it succeeded, period.  The value you are 
seeing is a common residual errno left behind during various phases of 
object creation and initialization.  If this is disconcerting, yes you 
can safely clear errno yourself.

In a nutshell, errno is only guaranteed to contain meaningful information
if a system call returns an error.

I hope this helps...

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

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

Newsgroups: comp.os.vxworks
Subject: ifShow network collisions - help
Date: Sat, 11 Dec 1993 03:12:42 GMT
From: dog@xdev.sunspot.noao.edu (Fritz Stauffer)
Organization: Computer, Hardware and Observatory Support
Message-ID: <1993Dec11.031242.25234@noao.edu>
Sender: news@noao.edu


	I am having flaky network problems with the 5.02 systems I am running.
	The configuration is 2 identical MV147's.  There is a master
	and a slave.  Both cpus load a working vxWorks system from rom.
	The load modules are then loaded.  The master has disc drive from
	which it loads the code.  The slave uses the master as the host and
	loads its modules from the master's disk.  This all works fine.
	The problem is, when I run 'ifShow' on the master, for every packet
	sent, there is a collision.  But, 'ifShow' on the slave does not
	show this at all.  The following are the 'ifShow' printouts:

Master ifShow "ln"

ln (unit number 0):
     Flags: (0x63) UP BROADCAST ARP RUNNING 
     Internet address: 146.5.21.2
     Broadcast address: 146.5.255.255
     Netmask 0xffff0000 Subnetmask 0xffff0000
     Ethernet address is 08:00:3e:20:ab:b4
     Metric is 0
     Maximum Transfer Unit size is 1500
     3748 packets received; 3726 packets sent
     1 input errors; 0 output errors
     3726 collisions

Slave ifShow "ln"

ln (unit number 0):
     Flags: (0x63) UP BROADCAST ARP RUNNING 
     Internet address: 146.5.21.3
     Broadcast address: 146.5.255.255
     Netmask 0xffff0000 Subnetmask 0xffff0000
     Ethernet address is 08:00:3e:20:ca:46
     Metric is 0
     Maximum Transfer Unit size is 1500
     31614 packets received; 23047 packets sent
     0 input errors; 0 output errors
     8 collisions

	What gives?  What does it mean when there is a collision?  Does
	it mean a retransmit?  It seems like a correctly working system
	would not have the # of collisions = # of packets sent.

	Thanks for any help.

	fritz stauffer
	national solar observatory
	sunspot, nm 88349

	fstauffer@sunspot.noao.edu

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

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


From dlr@electromac.mc.duke.edu  Mon Dec 13 05:51:44 1993
From: dlr@electromac.mc.duke.edu
Date: Mon Dec 13 05:51:52 PST 1993
Subject: subscribe
please add me to the exploder.

dlr@sunbar.mc.duke.edu


_______________________________________________________________
|  Dennis Rollins                      dlr@sunbar.mc.duke.edu |
|  Basic Arrhythmia Lab                                       |
|  Duke University Medical Center                             |
_______________________________________________________________


From Tracy_Dorsey@ccmail.gsfc.nasa.gov  Mon Dec 13 06:17:56 1993
From: Tracy_Dorsey@ccmail.gsfc.nasa.gov
Date: Mon Dec 13 06:18:05 PST 1993
Subject: tracking reboot signal

We're running about 6 tasks on a mv147 cpu using vxWorks 5.02. When processing 
data from the vme bus, the cpu card reboots.  Our configuration consists on 3 
mv147 cards and only one card reboots, so we appearlently the reboot signal met 
is a vxWorks system requirement and not a VME bus requirement.   Question - How 
can we tell using vxWorks and it's debugging capablities which task issued the 
reboot signal or what where the last instructions processed came from. We also 
have VME bus analyzer  at our disposal if tracking events on the bus would be 
helpful.

Thanks in advance - 

Tracy Dorsey    ---    tracy_dorsey@ccmail.gsfc.nasa.gov

                                    (301) 286-9391   / (301) 513-5353 


From rayssd!ssd.ray.com!fjr@uunet.uu.net  Mon Dec 13 07:03:10 1993
From: "Fred J. Roeber" <fjr@ssd.ray.com>
Date: Mon Dec 13 07:03:21 PST 1993
Subject: Re: ifShow network collisions - help
Fritz Stauffer writes:
>  	I am having flaky network problems with the 5.02 systems I am running.
>  	The configuration is 2 identical MV147's.  There is a master
>  	and a slave.  Both cpus load a working vxWorks system from rom.
>  	The load modules are then loaded.  The master has disc drive from
>  	which it loads the code.  The slave uses the master as the host and
>  	loads its modules from the master's disk.  This all works fine.
>  	The problem is, when I run 'ifShow' on the master, for every packet
>  	sent, there is a collision.  But, 'ifShow' on the slave does not
>  	show this at all.

You don't quite explain where you are using network connections and where
you are using backplane connections.  I will assume that both 147s are
connected to ethernet.  I am guessing that the high number of collisions
is due to the setting on the ethernet MAU for "heartbeat"/SQE being
set wrong.  Specifically, you likely need to check/reverse the setting for
the SQE signal on the network interface for the 147 that is getting all the
collisions.  It is a normal sign of an incorrect setting that every transfer
results in a collision indication back to the directly connected processor
(although data still gets transferred).  The whole area of SQE setting vs
heartbeat settings on MAUs is an area where you just have to try changing the
setting till it works I have found since the exact handling of the signal
is obscured by the fact that it works differently for "ethernet" compliant
networks as opposed to 802.3 compliant networks.   Fred

   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 177                  |
   |  Portsmouth, RI  02871-1087  (401) 842-4205           |
   |                   fjr@ssd.ray.com                     |



From tsilva@harpo.aaec.com  Mon Dec 13 10:29:53 1993
From: Tony Silva <tsilva@harpo.aaec.com>
Date: Mon Dec 13 10:30:03 PST 1993
Subject: Re: Porting "large" UNIX programs to VxWorks

On 10 Dec 93, Pete Percosan <percosan@caip.rutgers.edu> wrote:

>I am very new to VxWorks and, unfortunately, I am in the position of
>having to port a UNIX utility that contains a large number global and
>static variables.
>
>The main issue here is that it may be possible for several "instances"
>of the same program to be loaded into the system symbol table at once.
>Clearly there will be a problem with symbol name clashes. Even worse,
>it is possible for the application to be invoked once (initializing global
>and static data, operating on this data, exiting) and then reinvoked
>(with the global and static data in the state of the previous exit).
>
>My question is: Is it possible to hide an application's symbols based
>	        on an invocation?

For starters, you'll want to get familiar with "taskVarLib". The basic
idea is to convert your globals to unique copies which are
automatically saved/restored on context switches. Note that because of
the overhead involved, it's usually more efficient (though also more
work on your part) to avoid turning all of your global variables into
task variables. It's better to create only one task variable, viz., a
global pointer to a private (stack-based or dynamically-allocated)
structure which contains (what were) the global variables.  You might
also consider using the C preprocessor to map the original global
variable references into references through the new global/task
pointer.  We did this once before, even using "nm", "gdb", "sed", etc.
to mechanize the process of extracting and massaging symbol table
information. Unfortunately, this stuff is buried deep in our makefiles
and build scripts, and has a lot of other baggage associated with it,
so it would be tough for me to send it to you in any succinct form.

_______________________________________________________________________________

Tony Silva				tel:      (617)890-4200
Atlantic Aerospace Electronics Corp.	FAX:      (617)890-0224
470 Totten Pond Road			Internet: tsilva@aaec.com
Waltham, MA 02154


From daemon@vxw.ee.lbl.gov  Tue Dec 14 04:01:39 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Dec 14 04:01:50 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Dec 14 04:01:31 PST 1993

        Subject: Re: X servers
        Subject: Re: select system call
        Subject: System Configuration

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

Newsgroups: comp.os.vxworks
Subject: Re: X servers
Date: Mon, 13 Dec 1993 14:01:06 GMT
From: rypma@waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <CHz89v.Hpq@waterloo.hp.com>
References: <199312082245.RAA06858@pat.mc.duke.edu>
Sender: news@waterloo.hp.com (NetNews)

Patrick D. Wolf (pdw@sunbar.mc.duke.edu) wrote:

: Does anybody have experiance with X servers for the VME bus? I am familiar
: with the Tadpole TPIGC and would be interested in hearing about experiances
: with the Peritek and Vigra boards. Infomation about other vendors would also

We used a Vigra board to provide a frame buffer for an X server -
seemed to work well. We didn't. however, use the I/O stuff on the
board but chose to make a custom keyboard/mouse I/O board for our
own development needs.

As I remember, the frame buffer wasn't awfully fast and bit/byte/word
order from our HKV960E board gave us a giant headache, but what do you
expect when you bit twiddle and blast pixels across a VME bus :-)

Ted Rypma
HP Panacom (X terminal) Division

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

Newsgroups: comp.os.vxworks
Subject: Re: select system call
Date: Mon, 13 Dec 1993 19:53:39 GMT
From: jas@hplb.hpl.hp.com (Jan Schiefer)
Organization: Hewlett-Packard Laboratories, Bristol, England
Message-ID: <CHzoLG.LFK@hplb.hpl.hp.com>
References: <1993Dec2.145520.15348@picker.com> <2eb79d$i2@elroy.jpl.nasa.gov>
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)

Claude Felizardo (claude@spc18.jpl.nasa.gov) wrote:
>   I guess I'm looking for the opposite.  Under Unix, a select() system
> call can be interrupted by a signal but under vxWorks, it looks like the
> only way I can return from a select() is if there is a socket to be
> processed or it times out.  Is this correct?  The documentation doesn't
> mention the EINTR that a unix man page mentions.  Do I have to enable
> this or what?

This is documented in the Reference Manual under SigLib, section
'Function restarting'. As for leaving the select, you might want
to try to do a selWakeup() in the signal handler (no warranties,
as I haven't tried this and selWakeup() seems to be intended for
the driver level). See selectLib in the Reference Manual.

Good luck,

	Jan

- --
 Jan Schiefer, g0trr, jas@hplb.hpl.hp.com, HP Labs Bristol, UK.  +44 272 228344
Finally, I discovered a way to create lines longer then 80 columns, even on term

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

Newsgroups: comp.os.vxworks
Subject: System Configuration
Date: Tue, 14 Dec 1993 04:43:20 GMT
From: johnt@ee.ubc.ca (John Jay G. Tanlimco)
Organization: University of BC, Electrical Engineering
Message-ID: <1993Dec14.044320.12246@ee.ubc.ca>
Sender: johnt@ee.ubc.ca (John Jay G. Tanlimco)


To those using VxWorks 5.1 and MVME167:

Can you please tell me what you have in your realtime system?
(disk size, memory, slots, ...)
And what it is being used for, if possible.

Thanks.



- -- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Jay Tanlimco | University of British Columbia  | Someday, your forehead
                  | Dept. of Electrical Engineering | will have a sticker
johnt@ee.ubc.ca   | Vancouver,  B.C.,  CANADA       | saying "Intel Inside".
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

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


From clegg@tesla.elen.ssd.fsi.com  Tue Dec 14 10:18:27 1993
From: ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg)
Date: Tue Dec 14 10:18:36 PST 1993
The minute I released the note I sent on Friday Dec 10, I realized that it
was too vague.  I am therefore sending this new message describing my 
current situation more clearly:
We currently have compiled GNU C compilers for a Sun 4 and Sun 3.  However,
many of the sights we maintain will not have a Sun 4 or Sun 3 and therefore
we are looking for alternatives to generate COFF files for VxWorks.  This
compiler must be portable in a physical sense, i.e. the host processor
must be capable of being transported easily from site to site.  If it
is not, it must be already in existence at the site. 

Given these criteria, two alternatives seem possible:  Compile GNU to have
either the PC (386+) running DOS or OS2 (or UNIX?), or VxWorks itself as a
host and M68K as a target.

I am interested in communicating with someone who has attempted one of the
above and succeeded or discovered that pursuing these goals is difficult
at best.  Having read what little documentation I have found thus far
on compiling the GNU compiler for 386's I really don't feel comfortable
that they have actually gotten it to work on a PC.  The only encouraging
note I found in their documentation is a reference to bozotheclone as
a host argument.

Any examples or instructions for a successful build would be greatly
appreciated.

Thank You Again,
R. Clegg
FSI-SSD
"The best safety device in any plane is a well trained pilot"



From @npt.nuwc.navy.mil:nardone@mp34  Tue Dec 14 13:10:56 1993
From: nardone@mp34.lbl.gov (Rick Nardone)
Date: Tue Dec 14 13:11:05 PST 1993
Subject: Serial Interface Question
I'm looking for a way to set the parity, # data bits, and
# stop bits for a serial interface using ioctl( ) in VxWorks 5.1. 
I don't see the necessary #define options in ioLib.h ( FIOOPTIONS ).  
The Unix equivalent header file is termios.h.  

Thanks in advance,


Rick Nardone
nardone@mp34.nl.nuwc.navy.mil


From daemon@vxw.ee.lbl.gov  Wed Dec 15 04:01:09 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Dec 15 04:01:19 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec 15 04:01:02 PST 1993

        Subject: Re: Porting "large" UNIX programs to VxWorks

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

Newsgroups: comp.os.vxworks
Subject: Re: Porting "large" UNIX programs to VxWorks
Date: Wed, 15 Dec 1993 03:23:06 GMT
From: rypma@waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <CI242K.83A@waterloo.hp.com>
References: <9312131829.AA22393@harpo>
Sender: news@waterloo.hp.com (NetNews)

Tony Silva (tsilva@harpo.aaec.com) wrote:

: On 10 Dec 93, Pete Percosan <percosan@caip.rutgers.edu> wrote:

: >My question is: Is it possible to hide an application's symbols based
: >	        on an invocation?

: For starters, you'll want to get familiar with "taskVarLib". The basic
: idea is to convert your globals to unique copies which are

The gnu compiler for the i960 has a switch to make all globals relative
to a pointer tracked by the compiler (and set at task entry) - makes life
a lot easier.

Ted Rypma
HP Panacom Division
Waterloo, Ontario

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

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


From mea@mclean.sparta.com  Wed Dec 15 06:26:25 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Wed Dec 15 06:26:37 PST 1993
Subject: Re: Serial Interface Question
Greetings!

> Submitted-by: nardone@mp34.lbl.gov (Rick Nardone)
>  
> I'm looking for a way to set the parity, # data bits, and
> # stop bits for a serial interface using ioctl( ) in VxWorks 5.1. 
> I don't see the necessary #define options in ioLib.h ( FIOOPTIONS ).  
> The Unix equivalent header file is termios.h.  
> 

The way I've typically done this is to modify the tyIoctl routines in
the tyCoDrv.c for the appropriate BSP.  In there, simply add the
necessary routines (appropriately modified for your particular
UART/USART ;-) to make whatever changes you require.  Also, you may
have to set up your own include file to capture the differences between
ioLib.h and the termios.h ioctl facilities.  Simply make sure that
they're included when you recompile tyCoDrv.c and them include the same
file in any application that needs to call the new ioctls.

Hope this helps,

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


From markett@lams.lbl.gov  Wed Dec 15 12:20:35 1993
From: markett@lams.msd.lmsc.lockheed.com (Ray Markett)
Date: Wed Dec 15 12:20:43 PST 1993
Subject: Re:  Serial Interface Question
Rick Nardone asks,

I'm looking for a way to set the parity, # data bits, and
# stop bits for a serial interface using ioctl( ) in VxWorks 5.1. 
I don't see the necessary #define options in ioLib.h ( FIOOPTIONS ).  
The Unix equivalent header file is termios.h.  

Rick,

As far as I can tell, there is no termio structure in VxWorks. Instead of
setting up tm.c_cflag, tm.c_lflag, tm.c_iflag and such, you can use ioctl().
Like Unix, you can treat the serial device like a file. I hope this helps.

Ray Markett
(408) 756-1833
markett@lams.msd.lmsc.lockheed.com
 
Here is some sample code thar I use with VxWorks for serial I/O:

/******** init_chanx() sets serial lines for sensors and actuators ********/ 
 
init_chan0()
{
        fd0 = open("/tyCo/0",O_RDWR, 0x777);

        /* SET TTY PARAMETERS  */
        ioctl(fd0, FIOBAUDRATE, 2400); 
        ioctl(fd0,FIOSETOPTIONS,OPT_RAW);
        ioctl(fd0,FIOFLUSH,FIORFLUSH);
        ioctl(fd0,FIOFLUSH,FIOWFLUSH);
}

init_chan1()
{
        fd1 = open("/tyCo/1",O_RDWR, 0x777);

        /* SET TTY PARAMETERS  */
        ioctl(fd1, FIOBAUDRATE, 9600 );
        ioctl(fd1,FIOSETOPTIONS,OPT_RAW);
        ioctl(fd1,FIOFLUSH,FIORFLUSH);
        ioctl(fd1,FIOFLUSH,FIOWFLUSH);
}

/************** End of serial line initialization ********************/

/**************Code fragments that read a serial line****************/

char nss_bufi[INBUFSIZE];


nss_readchar()
{
read(fd1, nss_bufi, sizeof nss_bufi );
/*ioctl(fd1,FIOFLUSH,FIORFLUSH);*/
}
/***************End nss_readchar******************************************/

/*************Code fragments that read a serial line**********************/
dsu_read_data()
{
/* READ in charactors until LINE FEED is detected or until too DSU_PKTSIZE is reached */
/*
printf("dsu_read_data:In dsu_read_data\n"); 
printf("dsu_read_data:dsu_count is %d\n", dsu_count );
printf("dsu_read_data:DSU[dsu_count] is %d\n", DSU[dsu_count]);
*/
 
	do
	{
	dsu_readchar(); /*dsu_show_rec();*/
	DSU[dsu_count] = dsu_bufi[0];
	dsu_count++;
	}while( ((DSU[dsu_count-1]) != 0x0A ) && ( dsu_count < DSU_PKTSIZE) );
}




dsu_readchar(){

	/*printf("WAITING FOR DSU CHARACTOR\n");*/
  	read(fd0, dsu_bufi, sizeof dsu_bufi);
  	ioctl(fd0, FIOFLUSH, FIORFLUSH);

}
/*******************End read_dsu*******************************************/



/*************Code fragments that write to a serial line*******************/

char UU[STRLEN];

        sprintf(UU, "%f", fwdthrst);
	write(fd1, UU , sizeof UU);
	printf("trkPkt:SENT fwdthrst=%06.2f ", fwdthrst);
	for( i=0 ; i < STRLEN ; i++)
	checksum+=UU[i];
        		space[0]= 0x20; /*ASCII SPACE */        
        		write(fd1, space, sizeof space );
			checksum+=0x20;

/***************End*******************************************************/

/***************Code fragment that write to a serial line*****************/

	/*printf("total checksum=%X\n", checksum);*/
	checksum = checksum % 256;
	sprintf( chksum, "%X", checksum ); 
	/*printf("modulo checksum = %X\n", checksum  );*/
	write(fd1, chksum, sizeof chksum);

/*****************End***************************************************/

/************* Clean up returns ports to terminal mode ******************/

cleanup()
{

ioctl(fd0,FIOSETOPTIONS,OPT_TANDEM|OPT_7_BIT|OPT_CRMOD);
ioctl(fd1,FIOSETOPTIONS,OPT_TANDEM|OPT_7_BIT|OPT_CRMOD);
close(fd0);
close(fd1);

}

/***************End cleanup()********************************************/


From andy@oe.fau.edu  Wed Dec 15 15:11:37 1993
From: "Mr.Andrew Shein" <andy@oe.fau.edu>
Date: Wed Dec 15 15:11:46 PST 1993
Subject: Booting off a battery backed RAM disk
Hi 
   Has any been able to boot a system from a 
battery back RAM disk? Something like

boot device: ram=C00000

where the C00000 is the address of the ram disk.

				Thanks
				Andy Shein
				407 367 2854
				FAU Ocean Eng.





From daemon@vxw.ee.lbl.gov  Thu Dec 16 04:02:00 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Dec 16 04:02:10 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec 16 04:01:45 PST 1993

        Subject: Booting from NVRAM
        Subject: Backplane Communications
        Subject: how to join VxWorks user's group???
        Subject: Re: Booting off a battery backed RAM disk
        Subject: ieee-488

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

Newsgroups: comp.os.vxworks
Subject: Booting from NVRAM
Date: Wed, 15 Dec 1993 18:12:10 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <1993Dec15.181210.2329@nrtpa038.bnr.ca>
Sender: billag@b4pphff (Bill Gutknecht)

	Has anyone put the VxWorks boot code into NVRAM
	on any of the MVME boards?  I've got a MVME162-13 and 
	don't have any boot proms available ... i'd like to get
	some stuff out to test ... 
	
	Thanks.

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

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

Newsgroups: comp.os.vxworks
Subject: Backplane Communications
Date: Wed, 15 Dec 1993 18:39:24 GMT
From: campoe@jsc.nasa.gov (Alex Campoe)
Organization: NASA Johnson Space Center
Message-ID: <1993Dec15.183924.28913@aio.jsc.nasa.gov>
Reply-To: campoe@mickey.jsc.nasa.gov
Sender: usenet@aio.jsc.nasa.gov (USENET News Client)


Just a couple of questions. Right now, I have two CPU boards
on a VME backplane, no extra memory board. The anchor address is
0x600 on the master CPU. I understand that 512k of the system
memory on the master is set aside as shared memory, and I can
see this memory from processor #1 @ 0x1000600. Please excuse the
ignorance, but I have not done much with memory allocation and 
such. My questions are:

	-  How do I make use of this shared memory?
	-  In the manual, they mention 'mail-boxes', which sound like
	bus interrupts. How do I use them?
	-  Is there a way to set up semaphores on processes running
	on the different CPUs.
	-  Is there a FAQ for this group?

Any piece of code, book references, will be deeply apreciated.
- ---
#####################################################################
    ^^/^^/^^  /^^/^^/^^     Alex Campoe
   ^^/  /^^  /^^            Lockheed Engineering and Sciences Co.
  ^^/^^/^^  /^^             Houston, TX 
 ^^/  /^^  /^^/^^/^^        CAMPOE@MICKEY.JSC.NASA.GOV



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

Newsgroups: comp.os.vxworks
Subject: how to join VxWorks user's group???
Date: Wed, 15 Dec 1993 19:09:35 GMT
From: frank.vaughn@stpaul.ncr.com (Frank Vaughn)
Organization: NCR Network Products
Message-ID: <frank.vaughn.37.2D0F60EF@stpaul.ncr.com>
Sender: news@NCRTimes.stpaul.ncr.com

Could someone plz let me know how to join the vxWorks user's group?

Thanks;

Frank
- -----------------------------------------------------------------------------

Frank Vaughn            frank.vaughn@stpaul.ncr.com
(612)6382756

NCR Network Products Division

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

Newsgroups: comp.os.vxworks
Subject: Re: Booting off a battery backed RAM disk
Date: Thu, 16 Dec 1993 01:11:07 GMT
From: chris@wrs.com (Chris Ford)
Organization: Wind River Systems, Inc.
Message-ID: <chris.756004267@wrs.com>
References: <199312152312.AA19745@oe.fau.edu>
Sender: news@wrs.com (News Manager)

Hi,

"Mr.Andrew Shein" <andy@oe.fau.edu> writes:
> Has any been able to boot a system from a battery back RAM disk?
> Something like
>     boot device: ram=C00000
> where the C00000 is the address of the ram disk.

If you'd rather not write any new code, it would be simpler to "go"
to an image previously loaded in NVRAM:

    [VxWorks Boot]: g c00000
    Starting at 0xc00000...

A number of configurations are possible.  I would change ROM_TEXT_ADRS
to 0x00c00000 in the makefile(s) and config.h then build vxWorks.res_rom
or vxWorks.st_rom.

Have fun!
- -Chris Ford
 Wind River Systems Engineering

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

Newsgroups: comp.os.vxworks
Subject: ieee-488
Date: 16 Dec 1993 06:27:24 GMT
From: jguerin@tallowwood.awadi (John Guerin)
Organization: awadi
Message-ID: <2eov4cINN75k@myall.awadi.com.au>
Reply-To: jguerin@awadi.com.au

I have a rack containing a MVME167A CPU card and a MVME300A GPIB (IEEE-488)
card. I don't really want to write a GPIB driver.

Has any one got a working VxWorks (5.1) driver for the MVME300A that they
are prepared to sell?
The driver would need things such as error checking, timeout and
interrupt support.

Thanks,
	John


   ,--_|\
  /      \
  \_,-X_ /  <--- postal:   AWADI, PO BOX 161, Elizabeth 5112, Australia.
	v        internet: jguerin@awadi.com.au


- ---

End Of Message.



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

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


From mea@mclean.sparta.com  Thu Dec 16 06:21:26 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Dec 16 06:21:35 PST 1993
Subject: Re: Booting off a battery backed RAM disk
Greetings!

> Submitted-by: "Mr.Andrew Shein" <andy@oe.fau.edu>
>  
> Hi 
>    Has any been able to boot a system from a 
> battery back RAM disk? Something like
> 
> boot device: ram=C00000
> 
> where the C00000 is the address of the ram disk.

Yes, we have done this for use with PCMCIA SRAM boards.  Simply
modify the bootConfig.c (by hacking a copy of the scsiLoad routines)
to initialize the RAMdisk and then open the vxWorks file and read it
in.  I gave a presentation on this at the East Coast VxWorks Users
Group meeting.  I still have the charts and can mail you a copy
if you're interested.  They're in PowerPoint under windows but I can
send then as encapsulated Postscript if you don't have PCs or Macs
with PowerPoint.

Hope this helps,

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


From mea@mclean.sparta.com  Thu Dec 16 06:36:44 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Dec 16 06:36:53 PST 1993
Subject: Re: Booting from Battery backed up RAM
Greetings!

> From: chris@wrs.com (Chris Ford)
> 
> "Mr.Andrew Shein" <andy@oe.fau.edu> writes:
> > Has any been able to boot a system from a battery back RAM disk?
> > Something like
> >     boot device: ram=C00000
> > where the C00000 is the address of the ram disk.
> 
> If you'd rather not write any new code, it would be simpler to "go"
> to an image previously loaded in NVRAM:
> 
>     [VxWorks Boot]: g c00000
>     Starting at 0xc00000...
> 
> A number of configurations are possible.  I would change ROM_TEXT_ADRS
> to 0x00c00000 in the makefile(s) and config.h then build vxWorks.res_rom
> or vxWorks.st_rom.
> 

The down side of doing it this way is that if the RAM is coming from the
VMEbus, then I believe that every time something calls a routine from the
O/S (which is *still* out on the RAM board), you'll have to arbitrate
the bus.  This can result is incredible bus contention problems, and, 
because most external RAM boards are much slower than the on-board memory,
the overall performance of the system will be dismal.  

This is a good technique to use to test boot speeds, etc., but the next
problem you'll have to face is the loading of the symbol table.  The
only way around that is to build a "standalone" VxWorks image and place
that into RAM, but then there are further complications...  Do it
right, do it clean.  Put a DOS filesystem on the RAMdisk and add the
extra 30 lines to bootConfig and the extra 4 lines to usrConfig.  I
teach students how to do this in my Real time classes and it only takes
about an hour to make the changes and have new ROMs running.

Hope this helps,

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


From mitchell@harpo.aaec.com  Thu Dec 16 06:59:55 1993
From: mitchell@harpo.aaec.com
Date: Thu Dec 16 07:00:05 PST 1993
Subject: Re: Booting off a battery backed RAM disk
>Submitted-by andy@oe.fau.edu  Wed Dec 15 15:11:37 1993
>Submitted-by: "Mr.Andrew Shein" <andy@oe.fau.edu>
> 
>Hi 
>   Has any been able to boot a system from a 
>battery back RAM disk? Something like
>
>boot device: ram=C00000
>
>where the C00000 is the address of the ram disk.
>
>				Thanks
>				Andy Shein
>				407 367 2854
>				FAU Ocean Eng.
>
We did this under 4.1 and 5.0.2 on two different programs.  We modified
bootConfig.c to check for a boot device called 'nvram'.  If found, it would
do a ramDevCreate and dosFsDevInit as described in 4.6.6.3 of the 5.0.2
programmers guide.  Our code was very brain dead; the RAM starting address
and other parameters were defined at compile time.  A vxWorks shell script
was used to create the partition using ramDevCreate and dosFsMkfs and a
whole lot of copy calls to copy from the host's NFS mounted directory to
the NVM directory.

Our settup was fairly clumsy since the NVM stuff was hard-wired.  There
were
more changes to bootConfig.c and usrConfig.c than really needed because the
startup script and load file boot-paramters had their path altered
automatically if the NVM device was used.  My preference would be to make
the NVM tree look 
the same as the hosts's tree (using links on the host to keep the path
length short and sub-directories on the NVM disk as needed) to minimize
hacks to usrConfig.c.  If that were done, only bootLoad and netLoad in
bootConfig look like they need massaging.
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |  

 
                                



From hebo@mbari.org  Thu Dec 16 09:32:23 1993
From: Bob Herlien <hebo@mbari.org>
Date: Thu Dec 16 09:32:31 PST 1993
Subject: Re: Booting from NVRAM
> Sender: billag@b4pphff (Bill Gutknecht)
> 
> 	Has anyone put the VxWorks boot code into NVRAM
> 	on any of the MVME boards?  I've got a MVME162-13 and 
> 	don't have any boot proms available ... i'd like to get
> 	some stuff out to test ... 

We've put the VxWorks boot into flash on several MVME-162 boards.  It's 
fairly simple.  First, remove the jumper at J22 to enable PROM rather 
than flash.  You'll boot into 162Bug.  Then use the NIOC and NIOP commands
to load the VxWorks boot image into RAM (any convenient address).  Next,
use the PFLASH command to program the RAM image of VxWorks into flash.
Finally, remove the J22 jumper to enable flash, and you'll boot VxWorks.
Read the NIOC, NIOP, and PFLASH command descriptions in the 162Bug manual.

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


From donnie@verdix.com  Thu Dec 16 12:15:43 1993
From: donnie@verdix.com (Donnie Lewis)
Date: Thu Dec 16 12:15:53 PST 1993
Subject: VADSWorks consultant


Hello Everyone

Effective Dec 31, 1993, I will no longer be an employee at Verdix Corporation
due to the merger of Verdix with Rational Software Corporation.

I am offering my service as an independent VADSWorks consultant at a 
reasonal rate. I was a member of the customer support staff.
 
If interested please contact me at 703-370-5363 .That is also
my fx number. I will be able to get email at this address until Dec 31, 1993.
At this time, I will post a new internet address.


Donnie Lewis


From robert@orincon.com  Thu Dec 16 13:39:07 1993
From: robert@orincon.com (Robert Redfield)
Date: Thu Dec 16 13:39:14 PST 1993
Subject: Sun Exploder
Does anyone know how to subscribe to a Sun Bulletin board?
Thanks,
Rob Redfield
robert@orincon.com
(619)455-5530 x252


From daemon@vxw.ee.lbl.gov  Fri Dec 17 04:01:45 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Dec 17 04:01:56 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 17 04:01:34 PST 1993

        Subject: Re: Booting off a battery backed RAM disk
        Subject: Re: Booting from NVRAM
        Subject: NTP for VxWorks (request)

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

Newsgroups: comp.os.vxworks
Subject: Re: Booting off a battery backed RAM disk
Date: Thu, 16 Dec 1993 14:41:27 GMT
From: dat@noao.edu (D'Anne Thompson)
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Message-ID: <1993Dec16.144127.8172@noao.edu>
References: <199312152312.AA19745@oe.fau.edu>
Sender: news@noao.edu

From article <199312152312.AA19745@oe.fau.edu>, by "Mr.Andrew Shein" <andy@oe.fau.edu>:
> Hi 
>    Has any been able to boot a system from a 
> battery back RAM disk? Something like
> 
> boot device: ram=C00000
> 

We do this in almost all of our applications.  It works great!   The 
systems come up without any dependency upon the network and they have
access to a quaranteed file system (albeit small).  During the startup
script processing (from the ramdisk) we start the network code using
'usrNetInit'.  Develop the application using a normal host-server
arrangement and then "copy <app.o >/ram/app.o" to install the application
program to the ramdisk.  Change the boot parameters and press reset
and it's up within 30 seconds .

The details of how we do this were mailed to Wind River more than
3 years ago.

The bootrom code has to be modified, but this is very easy.  I'll generate
diffs and send them directly to Mr. Shein.

- -- 
D'Anne Thompson
National Optical Astronomy Observatories
P.O. Box 26732, Tucson, AZ 85726    (602) 325-9335
dat@noao.edu  {...}!uunet!noao.edu!dat

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

Newsgroups: comp.os.vxworks
Subject: Re: Booting from NVRAM
Date: Thu, 16 Dec 1993 17:19:07 GMT
From: miked@wrs.com (Mike Deliman)
Organization: Wind River Systems, Inc.
Message-ID: <CI51Fw.F7B@wrs.com>
References: <1993Dec15.181210.2329@nrtpa038.bnr.ca>
Sender: news@wrs.com (News Manager)

In article <1993Dec15.181210.2329@nrtpa038.bnr.ca> billag@b4pphff.bnr.ca (Bill Gutknecht) writes:
>	Has anyone put the VxWorks boot code into NVRAM
>	on any of the MVME boards?  I've got a MVME162-13 and 
>	don't have any boot proms available ... i'd like to get
>	some stuff out to test ... 
>	
>	Thanks.
>
>------------------------------------------------------------------------------
>Bill Gutknecht                  "When I die, I will go before Crom and he will 
>Bell Northern Research         	 ask me 'What is the Riddle of Steel?'  If I do
>Research Triangle Park, NC	 not know it, he will cast me out of Valhalla
>billag@bnr.ca			 and laugh at me ... "
>------------------------------------------------------------------------------

Here at WRS we use "tip" to connect a unix serial line to the
serial console of the target (eg: mv162).

On the mvme162, near the lower ejector, is a bank of jumpers [J22].
The inner-most pair is numbered 1-2.
The pair numbered 9-10 switches between PROM and FLASH. When installed, it
boots from PROM.

Leave the MBUG roms installed, and the following procedure may be used to burn
rom-immages into flash.

These instructinos assume you will be using bootrom.hex.

1) make the rom-image you desire (bootrom, vxWorks_rom, vxWorks.st_rom) and it's
   hex (s-record) equivalent (bootrom.hex...).

2) run "size68k" on the image, record the total size in hex.

3) tip into the serial port from the same directory the make was done in.

4) boot up, the MBUG> prompt should appear.

5) type "lo 0 10000"     <tells mbug to load from port 0, into ram, starting
			  at 0x10000>

6) type "~> bootrom.hex" <the ~ won't print; you will be prompted by tip for the
			  file name. It will shoot the hex-records to the mbug rom.
			  Tip reports the number of lines transimitted while it works.>

7) after the load is done, the MBUG prompt will come back.

8) execute "pflash 10000  size_in_hex ffa00000"
		            <MBUG will ask if you really want to program flash.
			     size_in_hex is from step 2 above.>

9) when this step is done, remove the board from the chassis, and remove the
   jumper from pins 9-10 on J22.

10) install the board in the chassis; it should bring up a VxWorks boot prompt.

- -- these steps will work with the mv162 for nearly any rom image. --


     Good luck!! I've done this with everything from bootrom.hex to 
     vxWorks.st_rom.hex with an application compiled in.

     Sincerely,

	 -mike
- -- 
- ------------------------------------------------------------------------------
  Mike Deliman, tech support hotline: 800-USA-4WRS, facsimile: 510-814-2164
        email:  miked@wrs.com (inet)  or [sun,uunet]!wrs!miked (uunet)
   Snail Mail:  Wind River Systems, 1010 Atlantic Ave, Alameda CA 94501 USA

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

Newsgroups: comp.os.vxworks,comp.protocols.time.ntp
Subject: NTP for VxWorks (request)
Date: Thu, 16 Dec 1993 21:13:11 GMT
From: steve@aplexus.jhuapl.edu (Steven Kahn)
Organization: Johns Hopkins U. Applied Physics Lab
Keywords: ntp, vxworks
Message-ID: <CI5C9z.B0D@netnews.jhuapl.edu>
Sender: usenet@netnews.jhuapl.edu

We are looking for an implementation of NTP that has been ported to
VxWorks. We anticipate a system with 10 - 20 chassis, each containing
Motorola boards (perhaps 167s) running VxWorks 5.1, and interconnected
via Ethernet and/or FDDI. Two to three of these chassis will receive
GPS time via IRIG-B, but the others must synchronize time via the LAN.
Accuracies in the order of 1 ms are desired.

Does anyone know of a port of NTP (or a subset thereof) that would meet
these requirements?

Thanks in advance for your help.

=============================================================================
Steven Kahn,  room 6-103			       Steven_Kahn@jhuapl.edu
Johns Hopkins University Applied Physics Lab
Laurel, MD 20723-6099					      +1 301 953 6812
=============================================================================

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

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


From mark@eminiar.jhuapl.edu  Fri Dec 17 06:30:50 1993
From: mark@eminiar.jhuapl.edu (Mark Switlick )
Date: Fri Dec 17 06:31:03 PST 1993
Subject: Controlling my  "tip" serial port from perl

----- Begin Included Message -----

From daemon Fri Dec 17 09:23:16 1993
Date: Fri, 17 Dec 93 09:23:14 EST
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: User unknown

I'm trying to access the same port that I have setup for a Unix "tip".
I want to run a set of benchmarks using a perl script over the serial port 
non-interactively.  Since tip has to be run interactively I can't use it.
I can open the port fine using perl's open call.  It appears that a write to 
the port actually sends what I wrote to vxWorks, but after that all bets are off.
It appears that the echo and maybe other parameters need to be changed on the
port using ioctl().  Perl uses ioctl(2) according to the bible, 
"Programming perl".  I'm trying to do this as follows, with the results below:

-----------begin perl program
#!/usr/local/bin/perl

require "sys/ioctl.ph";
require "sys/termio.ph";

#open /dev/ttya for read and write
open(TIP, "+</dev/ttya") || die "can't open /dev/ttya: $!";

#try getting setting using termio structure.  See /usr/include/sys/termio.h
ioctl(TIP,&TCGETA,$ttyget) || warn "ioctl TCGETA failed:\n sys_err $!" ;

#try getting setting using termios structure.  See /usr/include/sys/termios.h
ioctl(TIP,&TCGETS,$ttyget) || warn "ioctl TCGETS failed:\n sys_err $!" ;

exit;


-----------End perl program

-----------Results

ioctl TCGETA failed:
 sys_err Inappropriate ioctl for device at tmp_tip.pl line 10.
ioctl TCGETS failed:
 sys_err Inappropriate ioctl for device at tmp_tip.pl line 13.

-----------End Results

I don't necessarily need to use perl.  If anyone has done a similar thing or has
any ideas about what I've done wrong, please send it to me at my email address 
below.

Thanks,

MDS

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mark D. Switlick
SFA Inc.
JHUAPL
Johns Hopkins Road
Laurel, Md. 20723-6099
301-593-6000 ext. 7321
EMAIL mark@aplexus.jhuapl.edu
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


From leif@urban.tsl.uu.se  Fri Dec 17 08:30:00 1993
From: leif@urban.tsl.uu.se (Leif Thuresson)
Date: Fri Dec 17 08:30:13 PST 1993
Subject: setjmp/longjmp

I have a problem using setjmp/longjmp with GNU CC 2.2.3. When compiling with
the -O switch I get,

warning: variable `x' may be clobbered by `longjmp'

The manual say you should declare automatic variables volatile to prevent them
from being optimized into registers and thus getting this problem. This works
fine for simple variables but for pointers I still get the warning message.
What am I doing wrong ?


	- Leif


Leif Thuresson			leif@tsl.uu.se
The Svedberg laboratory, Uppsala, Sweden




From bclark@aoc.nrao.edu  Fri Dec 17 09:09:42 1993
From: Barry Clark <bclark@aoc.nrao.edu>
Date: Fri Dec 17 09:09:51 PST 1993
Subject: Script processing
Script processing apparently occurs by opening a fd on the script and
doing a ioGlobalStdSet to that fd.  This seems to me undesirable.  If
instead, it did a ioTaskStdSet, then one could stop in the middle of
a script and hold a conversation over the fd found by ioGlobalStdGet.


From daemon@vxw.ee.lbl.gov  Sat Dec 18 04:01:45 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Dec 18 04:01:54 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec 18 04:01:32 PST 1993

        Subject: standards benchmarks on VxWorks

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

Newsgroups: comp.os.vxworks
Subject: standards benchmarks on VxWorks
Date: Fri, 17 Dec 1993 14:31:11 GMT
From: eric@hpgnd153.grenoble.hp.com (Eric_Dumas)
Organization: Hewlett-Packard Company
Message-ID: <CI6oBz.950@grenoble.hp.com>
Sender: news@grenoble.hp.com (News Admin (F.Pernoud))

Hi,

I am looking for pointers on benchmarks (SPEC or parts of the SPEC suite or
real applications...) results with VxWorks in different configurations (processor, RAM size).

My objective is obviously to have some input for selecting processors
beyond the traditional MIPS numbers claimed by each vendor.

Thanks ahead of time for your help

Eric Dumas



 


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

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


From daemon@vxw.ee.lbl.gov  Sun Dec 19 04:01:46 1993
From: daemon@vxw.ee.lbl.gov
Date: Sun Dec 19 04:01:55 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Dec 19 04:01:38 PST 1993

        Subject: Experience with VxWorks on x86 Targets??

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

Newsgroups: comp.os.vxworks
Subject: Experience with VxWorks on x86 Targets??
Date: 18 Dec 1993 15:51:10 GMT
From: hatch1@llnl.gov (Jeffrey A. Hatch)
Organization: LLNL
Message-ID: <hatch1-181293074407@hatch-pb.llnl.gov>
Followup-To: comp.os.vxworks

I am starting a project requiring the use of an imbedded 486 running a
real-time, imbedded UNIX which must be capable of network booting
(diskless), shared memory, message passing, signals, semiphores (the
standard POSIX stuff), X-windows/Motif and remote procedure calls (RPC). 
One of the candidates for the OS is VxWorks. I would be very interested to
hear any comments from those who have used this product.  Does it work
well?  What are the pitfalls with this product?  Is there good support for
memory mapping to the ISA bus?  Can anyone out there recommend VxWorks for
this job.  Any comments on this subject would be appreciated.

- -jah

+----------------------------------------------------------------------------+
| Jeffrey A. Hatch                                                         
 |
| Lawrence Livermore National Laboratory                                   
 |
| P.O. Box 808, L-479                                                      
 |
| Livermore, CA  94551                                                     
 |
|                                                                          
 |
| email: hatch1@llnl.gov                                                   
 |
+----------------------------------------------------------------------------+

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

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


From daemon@vxw.ee.lbl.gov  Mon Dec 20 04:02:00 1993
From: daemon@vxw.ee.lbl.gov
Date: Mon Dec 20 04:02:27 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Dec 20 04:01:44 PST 1993

        Subject: Developing for VxWorks under OS/2.
        Subject: D/A Cards
        Subject: Pipes to other Computers?
        Subject: PPP for VxWorks
        Subject: Re: X servers
        Subject: Re: PPP over satellites
        Subject: Re: setsockopt
        Subject: Re: ifShow network collisions - help
        Subject: Re: ifShow network collisions - help
        Subject: Re: more on GNU C compilers
        Subject: Re: Pipes to other Computers?
        Subject: comp.os.vxworks Frequently Asked Questions (FAQ)

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

Newsgroups: comp.os.vxworks
Subject: Developing for VxWorks under OS/2.
Date: 19 Dec 1993 19:05:03 GMT
From: duffy@theory.chem.ubc.ca (Pat Duffy)
Organization: University of British Columbia, Vancouver, B.C., Canada
Message-ID: <2f28kv$rku@nntp.ucs.ubc.ca>

Hi All,

Just wondering:

What development tools exist which run natively under OS/2 (e.g.
source-level debuggers and the like) for VxWorks?  How much interest is
ther in the development of such tools (or the enhancement of same) if
they do not exist already?  Respond via E-Mail and I'll post a summary
if there's sufficient interest.
- -- 
Patrick Duffy, duffy@theory.chem.ubc.ca | Now I lay me down to bed 
                                        | Darkness won't engulf my head
                                        | I can see in infra-red
                                        | How I hate the night.       -Marvin

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

Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks,sci.electronics,comp.dsp
Subject: D/A Cards
Date: Sun, 19 Dec 1993 19:18:57 GMT
From: herman@phage.code71 (John W. Herman)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <herman.756328737@phage>
Sender: usenet@nosc.mil (Network News)


We are looking for 4 channal D/A cards for the audio frequency range.
We need on-board FIFO's and an external clock capability or on board
precision synthesizer.  The board also needs a driver for VxWorks
version 5.1.  Thank you.

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

Newsgroups: comp.os.vxworks
Subject: Pipes to other Computers?
Date: 20 Dec 1993 06:32 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <20DEC199306323253@kelvin.jpl.nasa.gov>

I'm trying to setup communications between a VxWorks computer and a Sun Sparc 10
using stream pipes.  A partition on the Sparc has been NFS mounted so it
is available to the VxWorks computer.  However, I've been unsuccessful in
getting to two computers to talk to each other via pipe.  Has anyone tried
to do a similar thing and have gotten it to work?
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | "Why must hailstones always
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 |  be the size of something
|_____|/  |_|/       |_____|/                     |  else?"   George Carlin 

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

Newsgroups: comp.os.vxworks
Subject: PPP for VxWorks
Date: Mon, 20 Dec 1993 07:46:27 GMT
From: dab@netcom.com (Don Brooks)
Organization: PEACEFUL STAR, Oakland, CA - Vox: 510.536.7607 Fax: 510.536.5889
Message-ID: <dabCIBpLG.94C@netcom.com>


I've ported pppd-1.3 to VxWorks 5.1 if anyone is interested.  The port
is available via anonymous ftp from netcom.com.  cd to pub/peacefulstar/dab
and get the file vpppd-1.0.tar.gz.  It's public domain.
 
Don Brooks		dab@netcom.com
PEACEFUL STAR 		Oakland, CA 
Vox: 510.536.7607 	Fax: 510.536.5889

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

Newsgroups: comp.os.vxworks
Subject: Re: X servers
Date: Mon, 20 Dec 1993 09:01:33 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBt2M.F6G@netcom.com>
References: <199312082245.RAA06858@pat.mc.duke.edu>

In article <199312082245.RAA06858@pat.mc.duke.edu> "Patrick D. Wolf" <pdw@sunbar.mc.duke.edu> writes:
>
>Does anybody have experiance with X servers for the VME bus? I am familiar
>with the Tadpole TPIGC and would be interested in hearing about experiances
>with the Peritek and Vigra boards. Infomation about other vendors would also
>be welcome.

i'm not sure if they're still around, but jupiter systems in alameda, ca,
used to sell very high-end x-server/terminals based on vxworks and vme bus.


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: PPP over satellites
Date: Mon, 20 Dec 1993 09:15:12 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBtpC.G8B@netcom.com>
References: <9312091634.AA19307@helios>

In article <9312091634.AA19307@helios> mea@mclean.sparta.com (Mike Anderson) writes:
>Here at SPARTA we are using PPP via satellite running both VxWorks and
>SunOS (X-Windows) code via a 9.6 KBit feed.  Not particularly speedy,
>but quite effective (especially when using our compression software).
>The "ping" times from A to C (via geosync sattelite and some
>intermediate microwave hops and encryption hardware) are about 1.2
>seconds.  We do use protocol/header compression (in addition to
>compressing the data) and all of that seems to work well with a BER of
>10**-6 or better.  I'm not familar with RFC 1323, but I doubt that our
>implementation is using it.

i think the original poster was interested in knowing large window
tcp option (as specified in rfc1323) intended for very large pipe,
high latency links requiring windows >65k.  not ppp level stuff.

also, w.r.t original poster's header compression queries, most p.d.
and commerical ppp's do this.  also, if you use slip you don't have to
compress linklevel headers (there are none!).  if your traffic is
such that ppp header compression will make a difference, why would
you use tcp large window option?


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: setsockopt
Date: Mon, 20 Dec 1993 09:15:53 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBtqH.GBM@netcom.com>
References: <1993Dec9.205053.23588@nrtpa038.bnr.ca>

In article <1993Dec9.205053.23588@nrtpa038.bnr.ca> billag@b4pphff.bnr.ca (Bill Gutknecht) writes:
>
>	What's the data structure passed to setsockopt when selecting
>	SO_RCVTIMEO and SO_SNDTIMEO ???


struct timeval *



Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: ifShow network collisions - help
Date: Mon, 20 Dec 1993 09:23:32 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBu38.HA4@netcom.com>
References: <1993Dec11.031242.25234@noao.edu>

In article <1993Dec11.031242.25234@noao.edu> dog@xdev.sunspot.noao.edu (Fritz Stauffer) writes:
>	What gives?  What does it mean when there is a collision?  Does
>	it mean a retransmit?  It seems like a correctly working system
>	would not have the # of collisions = # of packets sent.
>

not all network driver do this error/pkt cnt tallying correctly.
some will increment output packet counts once the packet is given
to ethernet chip, and count the output errors as the output completion
interrupts come in.  the output errors will usually incorporate
the collision count, but not all drivers may do this consistently.
sometimes this is inevitable (output count vs. output error) due
to the way driver and hardware interacts, but sometimes it's 
just due to neglect/oversight...


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: ifShow network collisions - help
Date: Mon, 20 Dec 1993 09:38:30 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBus6.IGq@netcom.com>
References: <199312122009.PAA02102@pike.ssd.ray.com>

In article <199312122009.PAA02102@pike.ssd.ray.com> "Fred J. Roeber" <fjr@ssd.ray.com> writes:
>(although data still gets transferred).  The whole area of SQE setting vs
>heartbeat settings on MAUs is an area where you just have to try changing the
>setting till it works I have found since the exact handling of the signal
>is obscured by the fact that it works differently for "ethernet" compliant
>networks as opposed to 802.3 compliant networks.   Fred
>

signal quality error (aka heartbeat) is intended to detect tranceivers
that are unable to detect collisions.  original ethernet spec didn't have
this; ieee802.3 added it.  if you have older equipment, or if you're
connecting to a repeater/repeater-chipset config, turn it off.  also,
in most normal "ethernet" cases, keep SQE off. (note, most, not all)
;-)


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: more on GNU C compilers
Date: Mon, 20 Dec 1993 09:45:42 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBv47.IuF@netcom.com>
References: <9312141520.AA01441@tesla.elen.ssd.fsi.com>

In article <9312141520.AA01441@tesla.elen.ssd.fsi.com> ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg) writes:
>Given these criteria, two alternatives seem possible:  Compile GNU to have
>either the PC (386+) running DOS or OS2 (or UNIX?), or VxWorks itself as a
>host and M68K as a target.

there's a company called hundred acre consulting in reno, nv.  800-245-2885

they'll give you a copy of the gcc configured to run on dos boxes for a
media distribution fee.  source code included.


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: Mon, 20 Dec 1993 09:50:56 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIBvCw.J62@netcom.com>
References: <20DEC199306323253@kelvin.jpl.nasa.gov>

In article <20DEC199306323253@kelvin.jpl.nasa.gov> baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:
>I'm trying to setup communications between a VxWorks computer and a Sun Sparc 10
>using stream pipes.  A partition on the Sparc has been NFS mounted so it
>is available to the VxWorks computer.  However, I've been unsuccessful in
>getting to two computers to talk to each other via pipe.  Has anyone tried
>to do a similar thing and have gotten it to work?


hmmm... perhaps i'm missing something but what does nfs mounted
filesystem have to do with pipe?  on bsd unix, pipe is just local socketpair.
on vxworks, pipe was (still is?) implemented as msg queues.  nothing to
do with filesystems or nfs or physical network/protocols.  am i confused?


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks,comp.answers,news.answers
Subject: comp.os.vxworks Frequently Asked Questions (FAQ)
Date: Mon, 20 Dec 1993 09:58:19 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded
Message-ID: <hjbCIBvp7.JMz@netcom.com>
Followup-To: comp.os.vxworks
Reply-To: hjb@netcom.com
Sender: hjb@netcom.com (squeedy)

Archive-name: vxworks-faq
Maintained-by: hjb@netcom.com
Last-modified: 1993/12/20
Version: 1.1

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

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

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

The FAQ is currently posted to comp.os.vxworks, news.answers and
comp.answers on the 15th of every month.  You can retrieve the latest copy
of this FAQ via anonymous FTP from rtfm.mit.edu in the directory
/pub/usenet-by-group/comp.os.vxworks.  Remember to use ASCII mode 
when transferring.

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

This FAQ is also available via anonymous ftp in:

	netcom.com:pub/hjb/vxfaq.Z

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

		TABLE OF CONTENTS

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

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

1. What is VxWorks?

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

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

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

2. Brief History of VxWorks

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

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

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

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

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

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

In Version 5.1:

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

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

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

4. What are the Latest versions of VxWorks?

As as of June 1993,

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

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

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

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

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

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

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

It is called the 'VxWorks Exploder'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wind C++ Gateway for ObjectCenter sold by WRS:

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

Note that this is the cost over and above ObjectCenter.

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

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

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

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

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

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

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

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

12. What are differences between UNIX and VxWorks?

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

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

For one thing, UNIX definitely is not realtime, whatever that means. 
[ editorial: To me personally, what realtime means is this -- when there
is a spinning process or task running like crazy doing some stuff
busily, I still want my system to respond immediately when I type a
character on my console keyboard.  VxWorks, and other real realtime
OS'es, do this.  UNIX and MS-DOG don't. ]

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

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

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

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

VxWorks: priority preemption, optional round-robin time-slicing.  
Traditional UNIX: prioritized round-robin time-slicing.  
Since VxWorks is just a glorified "program" it can be 
changed and customized pretty easily.  Task scheduling can
be customized as desired, for example.  Most people prefer priority based
preemption in the realtime world.  UNIX prefers "fair-share time-slicing".

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

VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX as
often misunderstood by some people.  The confusion perhaps is due to the
fact that UNIX hosts are used most widely to develop applications for 
VxWorks (and VxWorks itself).  [ editorial: Realtime UNIX sounds kind of like
Military Intelligence to me. (can you say, oxymoron?) ;-) ]

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

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

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

A WRS VxWorks 5.1 Benchmark Report hot off the press:

Benchmark numbers based on: mv167-25Mhz, 5.1

						        Cache	Cache 
Key Measurements        				Enabled	Disabled

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

Kernel Timings

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

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

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

Miscellaneous Operating System Timings

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

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

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

Floating-Point  
robot application       				18 sec  51 sec

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

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

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

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

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

No numbers available on latency.

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

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

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

15. What is the VxSim VxWorks Simulator?

Propaganda from WRS:

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

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

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

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

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

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

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

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

And Stan Schneider says,

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

And Leonid Rosenboim says,

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

And Kent Long says,

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

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

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


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

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

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

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

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


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

#define RSHD 514

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

   extern BOOT_PARAMS sysBootParams ;
   extern char *sysBootHost ;

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

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

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

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

   close(dataSock) ;
}

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

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

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

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

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

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

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

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

21. X for VxWorks

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

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

22. IEEE-488 (GPIB) driver for VxWorks

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

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

23. How does one disable NFS client caching?

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

26. How does one troubleshoot a backplane driver malfunction?

There are a few rules of thumb:

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

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

 3) verify all memory mapping and make sure there's no
	address conflicts on the bus

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

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

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

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

#include "selectLib.h"
...

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

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

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

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

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

Fix: do setsockopt() SO_REUSEADDR

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

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

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

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

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

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

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


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

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

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

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

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

The problem:

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

 long irint_count = 0;

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


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

 -> ld < sinTest.o

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

 -> irint_count

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



The answer:

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

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

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

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

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

37. Free SNMP for VxWorks

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

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

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

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

38. What third party products are available for VxWorks?

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

the file:

 netcom.com:pub/hjb/vxworkers.Z

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

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

 hjb@netcom.com.

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

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

 - flight simulators
 - radio and optical telescopes
 - automative ABS & realtime suspension
 - naviation systems
 - deep sea instrumentation
 - PBXs
 - traffic lights
 - modems
 - sonar systems

 [ editorial: And, regrettably, in: ]

 - military stuff

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

40. A complete list of CPU hardware supported by VxWorks

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

 netcom.com:pub/hjb/vxbsp.Z

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.Z

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.Z

Some evil VxWorkers have drivers for military/weapons systems.

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

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

Propaganda from WRS:

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

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

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

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

Propaganda from WRS:

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

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

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

44. How much is VxWorks?

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

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

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

45. What is MicroWorks?

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

 i960, 680x0, 683xx

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

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

Development License $12,500.

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

46. Other Unbundled Products for VxWorks?

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

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

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

47. How can I find out more about VxWorks?

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

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

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

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

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

Here are some other related newsgroups:

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

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

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

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

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

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

SUBSCRIBE PSOSUSER <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.

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

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

9999: Contributions to comp.os.vxworks FAQs.

The following net.folks, among others, have contributed to this posting:

 Name			email address
 ------------		----------------------------	
 Mark Linimon 		linimon@nominil.lonestar.org
 Geoff Espin		geoff@wrs.com
 Rev. Bob Crispen	crispen@foxy.boeing.com
 Stan Schneider		stan@rti.com
 Fred J Roeber		fjr@ssd.ray.com
 Marc Friedman		maf@verdix.com
 Joe Van Andel		vanandel@ncar.ucar.edu
 Bob Marino		ram@mr.picker.com
 Richard Kowalsky	cmdorat@tc.fluke.com 
 Kent Long		kent@wrs.com
 James Moore		james@wrs.com
 Chuck Meade		chuckm@verdix.com
 Patrick T. Pinkowski	ppinkow@jupiter.ksc.nasa.gov
 D'Anne Thompson	dat@noao.edu
 Leonid Rosenboim	leonid@rst.hellnet.org
 David Lim		lim@robotics.jpl.nasa.gov
 Richard Neitzel	thor@thor.atd.ucar.edu
 John Winas		winas@phebos.aps.anl.gov

I welcome flames, insults, accusations, reactions, additions, and
corrections to this posting via email:

 hjb@netcom.com 

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

===============================================================================

Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

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


From hill@luke.atdiv.lanl.gov  Mon Dec 20 09:27:34 1993
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Mon Dec 20 09:27:41 PST 1993
Subject: Re: comp.os.vxworks newsdigest

Hello,

> >	What's the data structure passed to setsockopt when selecting
> >	SO_RCVTIMEO and SO_SNDTIMEO ???
> 
> 
> struct timeval *

Are either of SO_RCVTIMEO or SO_SNDTIMEO operational under vxWorks 5.1?

I dont see them in the documentation.

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 bvance@sadira.gb.nrao.edu  Mon Dec 20 13:09:17 1993
From: bvance@sadira.gb.nrao.edu (BOB VANCE)
Date: Mon Dec 20 13:09:25 PST 1993
Subject: Re: comp.os.vxworks newsdigest
Can you please remove my name from the exploder group for
vxworks.  I do not check them any more and am not interested.
bvance



From daemon@vxw.ee.lbl.gov  Tue Dec 21 04:01:59 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Dec 21 04:02:11 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Dec 21 04:01:47 PST 1993

        Subject: Re: Booting from NVRAM
        Subject: Re: setjmp/longjmp
        Subject: Re: Pipes to other Computers?
        Subject: Remote Reboot of VxWorks processor
        Subject: Re: Pipes to other Computers?
        Subject: Re: comp.os.vxworks newsdigest
        Subject: Re: Pipes to other Computers?
        Subject: Re: Pipes to other Computers?
        Subject: Re: Pipes to other Computers?

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

Newsgroups: comp.os.vxworks
Subject: Re: Booting from NVRAM
Date: Fri, 17 Dec 93 14:23:13 GMT
From: mcdowell@exlog.com (long-haired leaping gnome)
Organization: Baker Hughes INTEQ, Inc.
Message-ID: <1993Dec17.142313.14465@exlog.com>
References: <1993Dec15.181210.2329@nrtpa038.bnr.ca>

In message <1993Dec15.181210.2329@nrtpa038.bnr.ca>billag@b4pphff.bnr.ca (Bill Gutknecht) asks:
>	Has anyone put the VxWorks boot code into NVRAM
>	on any of the MVME boards?  I've got a MVME162-13 and 
>	don't have any boot proms available ... i'd like to get
>	some stuff out to test ... 
	

My '162 board doesn't have enough NVRAM to boot off of. What is does have
enough of is FLASH EPROM. Programming that is a rather simple matter.
Follow the directions below (it's assuming a tip connection from a 
unix machine):

	1. Remove the 5th jumper from the top (with p1 and p2 
		connectors in the top and front panel in the
		bottom) in J22. 

	2. Establish a serial link between your host machine and
		the 162.

	3. Power up the 162. You will see the 162-BUG monitor. 
		Enter the commands as given, adjusting for your
		site specific pathnames and such:

	
	162-Bug>lo 0 10000
	>Local file name? /usr4/mcdowell/vw5.1/config/mv162/bootrom.hex
	8132 lines transferred in 6 minutes 11 seconds 
	!
	
	162-Bug>
	162-Bug>
	pflash 10000 2ffff ffa00000
	Source Starting/Ending Addresses      =00010000/0002FFFF
	Destination Starting/Ending Addresses =FFA00000/FFA1FFFF
	Number of Effective Bytes             =00020000 (&131072)
	
	Program FLASH Memory (Y/N)? y
	Zeroing Block Number     =00 ($FFA00000)
	Erasing Block Number     =00 ($FFA00000)
	Programming Block Number =00 ($FFA00000)
	FLASH Memory Programming Complete
	162-Bug>
	

	4. Power off the 162. Reinstall the jumper you removed in (1). 
		Boot the board. It will boot from the flash memory that
		has the newly loaded bootrom code.


That's it! 
- -- 
Steve McDowell			
Baker Hughes INTEQ, Inc.		bzero(brain_buffer, sizeof(brain));
Houston, Texas USA		 		
	

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

Newsgroups: comp.os.vxworks
Subject: Re: setjmp/longjmp
Date: Mon, 20 Dec 1993 13:14:23 GMT
From: jp_dejong@hgl.signaal.nl (Jong J.P. de)
Organization: Hollandse Signaal apparaten BV
Message-ID: <1993Dec20.131423.17296@hgl.signaal.nl>
References: <9312171630.AA03349@urban.tsl.uu.se>
Sender: usenet@hgl.signaal.nl (USENET News System)

Leif Thuresson (leif@urban.tsl.uu.se) wrote:

: I have a problem using setjmp/longjmp with GNU CC 2.2.3. When compiling with
: the -O switch I get,

: warning: variable `x' may be clobbered by `longjmp'

: The manual say you should declare automatic variables volatile to prevent them
: from being optimized into registers and thus getting this problem. This works
: fine for simple variables but for pointers I still get the warning message.
: What am I doing wrong ?

Try this:

/** don't fuzz with this code, it copes with an error in setjmp in VxWorks */        
static jmp_buf  env_1;        
static jmp_buf  env_2;        
static jmp_buf *env;        
/**/

{            
    /** don't fuzz with this code, it copes with an error in setjmp in VxWorks */        
    if (((unsigned int) &env_1[0] & (unsigned int) 0x7) != (unsigned int) 0) {        
        env = (jmp_buf *) & env_1[1];        
    } else {        
        env = (jmp_buf *) & env_1[0];        
    }        
    /**/        
    if ((error_number = setjmp (env)) != NULL) {        
        return error_number;        
    }        
}    

- --

 Joop de Jong                 DNCS-Systems
 (jp_dejong@hgl.signaal.nl)   Hollandse Signaalapparaten B.V.
=======================[ Unclassified ]=======================


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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: 20 Dec 1993 16:36 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <20DEC199316362346@kelvin.jpl.nasa.gov>
References: <20DEC199306323253@kelvin.jpl.nasa.gov> <hjbCIBvCw.J62@netcom.com>

In article <hjbCIBvCw.J62@netcom.com>, hjb@netcom.com (squeedy) writes...
>In article <20DEC199306323253@kelvin.jpl.nasa.gov> baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:
>>I'm trying to setup communications between a VxWorks computer and a Sun Sparc 10
>>using stream pipes.  A partition on the Sparc has been NFS mounted so it
>>is available to the VxWorks computer.  However, I've been unsuccessful in
>>getting to two computers to talk to each other via pipe.  Has anyone tried
>>to do a similar thing and have gotten it to work?
> 
> 
>hmmm... perhaps i'm missing something but what does nfs mounted
>filesystem have to do with pipe?  on bsd unix, pipe is just local socketpair.
>on vxworks, pipe was (still is?) implemented as msg queues.  nothing to
>do with filesystems or nfs or physical network/protocols.  am i confused?

There are two types of pipes, the regular pipes and the stream pipes.  
The stream pipes are sometimes called named pipes or FIFOs.  When you
create a stream pipe, you specify a filename for the pipe to attach to, thus
the need for the NFS partition.  In fact, when you call the pipeDevCreate()
routine from VxWorks, the first parameter is a filename.

It may be that because VxWorks implements its pipes are message queues, it
is incompabible when outside computers try to attach to it.  I just
want to verify if this is true or not.

Also, this it *not* the same as TCP/IP sockets.  I would prefer to use
the stream pipes because they are easier to setup and give you more
flexibility than the sockets. 
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | "Why must hailstones always
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 |  be the size of something
|_____|/  |_|/       |_____|/                     |  else?"   George Carlin 

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

Newsgroups: comp.os.vxworks
Subject: Remote Reboot of VxWorks processor
Date: Mon, 20 Dec 1993 19:59:45 GMT
From: carroll@ast.saic.com (John Carroll)
Organization: SAIC
Message-ID: <1993Dec20.195945.3594@ast.saic.com>
Reply-To: carroll@ast.saic.com
Sender: news@ast.saic.com

We have 12 processors in 7 different crates that I would like to reboot
remotely without having to rlogin to each board and type "reboot".

Does anyone have a program which sends an RPC command or something
to reboot each processor? (RSH does not work with 5.02b).

I am using VxWorks 5.02b and am hoping to upgrade to 5.1 once VADSworks 3.0
is available - so solutions for either operating system are welcome.

Thanks in Advance,

- -- 
John Carroll                                   | telephone: 619.458.5071
Science Applications International Corporation | fax: 619.558.1391
4161 Campus Point Drive MS E3R                 | email: carroll@ast.saic.com
San Diego, CA 92121                            |
- --


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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: Mon, 20 Dec 1993 22:07:09 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCICtFy.6Ms@netcom.com>
References: <20DEC199306323253@kelvin.jpl.nasa.gov> <hjbCIBvCw.J62@netcom.com> <20DEC199316362346@kelvin.jpl.nasa.gov>

In article <20DEC199316362346@kelvin.jpl.nasa.gov> baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:
>
>There are two types of pipes, the regular pipes and the stream pipes.  
>The stream pipes are sometimes called named pipes or FIFOs.  When you
>create a stream pipe, you specify a filename for the pipe to attach to, thus
>the need for the NFS partition.  In fact, when you call the pipeDevCreate()
>routine from VxWorks, the first parameter is a filename.
>

sorry but the "filename" you provide is not a file name; it's just
a "name" for the io device, giving name to the pipe you're creating (thus,
named pipe).  vxworks device names do not necessary have a corresponding
node in the filesystem -- just malloced piece of memory used to identify
device drivers. pipe is implemented on top of msg queue facility, as
a device driver, with no relation what-so-ever to filesystems.  in fact,
vxworks does not have a real "filesystem" (as in unix); they're just
io devices as well, going thru ios subsystem.  but that's a different
issue all together.

>It may be that because VxWorks implements its pipes are message queues, it
>is incompabible when outside computers try to attach to it.  I just
>want to verify if this is true or not.

in short, again, vxworks implements pipe's as msg queues.  it has nothing 
to do with filesystems.  the name you provide is not used as a filename.
it's just a token/id for the device used inside vxworks.

>
>Also, this it *not* the same as TCP/IP sockets.  I would prefer to use
>the stream pipes because they are easier to setup and give you more
>flexibility than the sockets. 

re: flexibility: sockets are more flexible (bsd unix pipe is implemented on
top of sockets -- just one counter-example for your assumption that sockets
are less flexible).  using sockets you can control a number of things,
such as preservation of record boundaries, etc.  but that's another issue.


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: comp.os.vxworks newsdigest
Date: Mon, 20 Dec 1993 22:12:34 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCICtoy.71A@netcom.com>
References: <9312201727.AA22385@luke.atdiv.lanl.gov>

In article <9312201727.AA22385@luke.atdiv.lanl.gov> hill@luke.atdiv.lanl.gov (Jeff Hill) writes:
>
>
>Are either of SO_RCVTIMEO or SO_SNDTIMEO operational under vxWorks 5.1?

no.  vxworks 5.1 network code is still based on bsd tahoe release which
never made use of these socket level timeout specifications (they were
just there to be set and read, nobody used them).

bsd networking release 2 (more recent update with a lot of enhancements)
does use  them to timeout while waiting for send/recv to complete.
perhaps wind river will upgrade to net-2 code level. perhaps not.
there is a port of net2 to older releases of vxworks done outside wind
river.  the port is not available for "public consumption", but easy
to duplicate.  write me if you're interested.


Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: 21 Dec 1993 00:40 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <21DEC199300404664@kelvin.jpl.nasa.gov>
References: <20DEC199306323253@kelvin.jpl.nasa.gov> <hjbCIBvCw.J62@netcom.com> <20DEC199316362346@kelvin.jpl.nasa.gov> <hjbCICtFy.6Ms@netcom.com>

In article <hjbCICtFy.6Ms@netcom.com>, hjb@netcom.com (squeedy) writes...
>In article <20DEC199316362346@kelvin.jpl.nasa.gov> baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:
>>
>>There are two types of pipes, the regular pipes and the stream pipes.  
>>The stream pipes are sometimes called named pipes or FIFOs.  When you
>>create a stream pipe, you specify a filename for the pipe to attach to, thus
>>the need for the NFS partition.  In fact, when you call the pipeDevCreate()
>>routine from VxWorks, the first parameter is a filename.
>>
> 
>sorry but the "filename" you provide is not a file name; it's just
>a "name" for the io device, giving name to the pipe you're creating (thus,
>named pipe).  

You're correct, I should of said i/o device instead of filename.

>vxworks does not have a real "filesystem" (as in unix); they're just
>io devices as well, going thru ios subsystem.  but that's a different
>issue all together.

Which is precisely why we have a NFS-mounted disk partition, in an
attempt to get the stream pipes to work.  Stream pipes are normally
created by attaching to a shared file between tasks.

>>It may be that because VxWorks implements its pipes are message queues, it
>>is incompabible when outside computers try to attach to it.  I just
>>want to verify if this is true or not.
> 
>in short, again, vxworks implements pipe's as msg queues.  it has nothing 
>to do with filesystems.  the name you provide is not used as a filename.
>it's just a token/id for the device used inside vxworks.
> 
>>
>>Also, this it *not* the same as TCP/IP sockets.  I would prefer to use
>>the stream pipes because they are easier to setup and give you more
>>flexibility than the sockets. 
> 
>re: flexibility: sockets are more flexible (bsd unix pipe is implemented on
>top of sockets -- just one counter-example for your assumption that sockets
>are less flexible).  using sockets you can control a number of things,
>such as preservation of record boundaries, etc.  but that's another issue.

If I can't get the stream pipes to work in VxWorks, then I'll fall back to
using sockets.  Sockets don't provide priority bands like the stream pipes, and
the sockets have a more cumbersome setup.
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | "Why must hailstones always
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 |  be the size of something
|_____|/  |_|/       |_____|/                     |  else?"   George Carlin 

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: Tue, 21 Dec 1993 02:11:28 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCID4r5.y7@netcom.com>
References: <20DEC199316362346@kelvin.jpl.nasa.gov> <hjbCICtFy.6Ms@netcom.com> <21DEC199300404664@kelvin.jpl.nasa.gov>

In article <21DEC199300404664@kelvin.jpl.nasa.gov> baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:
>
>Which is precisely why we have a NFS-mounted disk partition, in an
>attempt to get the stream pipes to work.  Stream pipes are normally
>created by attaching to a shared file between tasks.

again, not a "file", but io device, which has nothing to do with filesystem
of any kind, including nfs in vxworks.  the name you use is just a string
identifier, not a file name.  there is no reason to believe mounting
an nfs filesytem will have any affect on pipeDrv.

>If I can't get the stream pipes to work in VxWorks, then I'll fall back to
>using sockets.  Sockets don't provide priority bands like the stream pipes, and
>the sockets have a more cumbersome setup.

are we talking about the pipe facility in vxworks here?  vxworks pipeDrv
does not provide "priority bands".  all messages are delivered at normal
priority.  if you want prioritized message delivery use message queue directly
instead.  but that won't work over different machine boundaries either.

perhaps you're using something home-grown?

Hwa-Jin Bae  (hjb@netcom.com)  			510-466-9166 (msg/page)	
PEACEFUL STAR Consultants -- "Hackers R Us"	510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125		510-536-5889 (fax)

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: 21 Dec 1993 07:28 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <21DEC199307284932@kelvin.jpl.nasa.gov>
References: <20DEC199316362346@kelvin.jpl.nasa.gov> <hjbCICtFy.6Ms@netcom.com> <21DEC199300404664@kelvin.jpl.nasa.gov> <hjbCID4r5.y7@netcom.com>

In article <hjbCID4r5.y7@netcom.com>, hjb@netcom.com (squeedy) writes...
>an nfs filesytem will have any affect on pipeDrv.
> 
> 
>are we talking about the pipe facility in vxworks here?  vxworks pipeDrv
>does not provide "priority bands".  all messages are delivered at normal
>priority.  if you want prioritized message delivery use message queue directly
>instead.  but that won't work over different machine boundaries either.

Apparently VxWorks doesn't support stream pipes.  That's really too bad. 
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | "Why must hailstones always
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 |  be the size of something
|_____|/  |_|/       |_____|/                     |  else?"   George Carlin 

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

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


From SB06684@msgate.emis.hac.com  Tue Dec 21 08:28:56 1993
From: SB06684@msgate.emis.hac.com
Date: Tue Dec 21 08:29:04 PST 1993
Subject: Storage Media
From: Iveland, Scott T
Date: Tue, Dec 21, 1993 8:29 AM
Subject: Storage Media
To: vxworks Exploder
I need some advice on storage media. I have an application where we are taking 
data from an airborne camera. The data comes from the camera into RAM in a VME 
chassis. After 640 Mbytes of data is collected we need to store it as the 
aircraft swings around to take another swath of data. Our first iteration of 
this used a magneto-optical drive to store the data. The camera resolution was 
much smaller and the amount of data collected was only 64 Mbytes/swath. The MO 
drive worked OK, but it was slow. The data rate of the MO drive will be 
unacceptable for the new system. 

Does anyone have information on tape drives & vxWorks drivers?
 What kind of data rates can you write to them? 
Do you have to go back to the start of the tape every time you want to add a 
file to it? If so, how long does that operation take?

Are there any other options for high density, fast access, removable storage 
media?

Thanks in advance
Scott Iveland



From zander@luke.atdiv.lanl.gov  Tue Dec 21 09:09:24 1993
From: zander@luke.atdiv.lanl.gov (Mark Zander)
Date: Tue Dec 21 09:09:32 PST 1993
Subject: Re: Pipes to other Computers?
Ron Baalke writes:

> Apparently VxWorks doesn't support stream pipes.  That's really too bad. 

Just to add to the confusion.  I've used named pipes on Sun OS, a couple
of versions ago.  Unfortunately one of the limits of named pipes at that
time was that it did not work between two different computers, even though
they are using the same file server!  So unless your stream pipes have
added functionality, I'm not sure that they'll allow you to communicate
between two different computer systems anyway.  Hopefully you have
tried this out between two Unix systems and verified that it does
work?


---------------------------------------------------------
|							|
|	Mark Zander					|
|	Los Alamos National Laboratory			|
|	Accelerator Operations and Technology Division	|
|	Controls and Automation Group			|
|	MS-H820						|
|	Los Alamos, NM 87545				|
|							|
|	phone: 505-665-0690				|
|	fax:   505-665-5107				|
|	email: mez@lanl.gov				|
|							|
---------------------------------------------------------



From mitchell@harpo.aaec.com  Tue Dec 21 09:56:33 1993
From: mitchell@harpo.aaec.com
Date: Tue Dec 21 09:56:42 PST 1993
Subject: Re: Storage Media
>Submitted-by SB06684@msgate.emis.hac.com  Tue Dec 21 08:28:56 1993
>Submitted-by: SB06684@msgate.emis.hac.com
> 
>From: Iveland, Scott T
>Date: Tue, Dec 21, 1993 8:29 AM
>Subject: Storage Media
>To: vxworks Exploder
>I need some advice on storage media. I have an application where we are taking 
>data from an airborne camera. The data comes from the camera into RAM in a VME 
>chassis. After 640 Mbytes of data is collected we need to store it as the 
>aircraft swings around to take another swath of data. Our first iteration of 
>this used a magneto-optical drive to store the data. The camera resolution was 
>much smaller and the amount of data collected was only 64 Mbytes/swath. The MO 
>drive worked OK, but it was slow. The data rate of the MO drive will be 
>unacceptable for the new system. 
>
>Does anyone have information on tape drives & vxWorks drivers?
> What kind of data rates can you write to them? 
>Do you have to go back to the start of the tape every time you want to add a 
>file to it? If so, how long does that operation take?
>
>Are there any other options for high density, fast access, removable storage 
>media?
>
>Thanks in advance
>Scott Iveland
>

We did a similar RF data collection system.  We dumped the data to DRAM
boards
(~40 MB/sec over VSB), then during the aircraft turn, moved it off to a
Exabyte tape unit.  With VME memory boards running at (I think)
128Meg/board, a 640Meg dram array isn't all that big.  As long as you have
enough time to get the data onto the tape during the turn (500K a second
??) this should work fine.
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |  

 
                                



From visicom!VisiCom.COM!bart@lbl.gov  Tue Dec 21 13:20:48 1993
From: Bart Helms <bart@visicom.com>
Date: Tue Dec 21 13:21:01 PST 1993
Subject: vxWorks 5.0.3 serial i/o problems

I am currently working with vxWorks 5.0.3 on a target consisting of a
Compaq DeskPro 66M with a SMC Elite 16T LAN adapter installed.  The problem
that I am having is that I do not receive any interrupts for the second
serial port.  I appears that the IRQ for the LAN card and the second serial
port conflict.  I have tried programming the LAN card to utilize a different
IRQ and made the appropriate changes in the config.h file, but this doesn't
appear to have any effect.

Has anyone else encountered this problem, is there a workaround, or am I
just doing something wrong??

 ---------------------------------------------------------------
 | Bart Helms                   Voice:  (206) 574-5368         |
 | Software Engineer                                           |
 | VisiCom Labs                 E-Mail: bart_helms@visicom.com |
 | Vancouver, WA                                               |
 ---------------------------------------------------------------



From rec@aussie.ucsd.edu  Tue Dec 21 14:12:40 1993
From: rec@aussie.ucsd.edu (Richard E. Currier)
Date: Tue Dec 21 14:12:49 PST 1993
Subject: Re: comp.os.vxworks newsdigest

 
Can you please remove my name from the exploder group for
vxworks.  I do not check them any more and am not interested.
bvance

	rcurrier@ucsd.edu


From daemon@vxw.ee.lbl.gov  Wed Dec 22 04:01:03 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Dec 22 04:01:13 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec 22 04:00:54 PST 1993

        Subject: Re: Pipes to other Computers?
        Subject: Looking for SBUS digital I/O board w/driver
        Subject: Re: Pipes to other Computers?
        Subject: Rebooting 68040 via backplane
        Subject: Re: Rebooting 68040 via backplane

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: 21 Dec 1993 19:11 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <21DEC199319112103@kelvin.jpl.nasa.gov>
References: <20DEC199316362346@kelvin.jpl.nasa.gov> <hjbCICtFy.6Ms@netcom.com> <21DEC199300404664@kelvin.jpl.nasa.gov> <hjbCID4r5.y7@netcom.com>

In article <hjbCID4r5.y7@netcom.com>, hjb@netcom.com (squeedy) writes...
>In article <21DEC199300404664@kelvin.jpl.nasa.gov> baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:
>>
>>If I can't get the stream pipes to work in VxWorks, then I'll fall back to
>>using sockets.  Sockets don't provide priority bands like the stream pipes, and
>>the sockets have a more cumbersome setup.
> 
>are we talking about the pipe facility in vxworks here?  vxworks pipeDrv
>does not provide "priority bands".  all messages are delivered at normal
>priority.  if you want prioritized message delivery use message queue directly
>instead.  but that won't work over different machine boundaries either.

Unfortunately, the problem with message queues is you can't do a select
on them.  The priority bands are a feature of stream pipes.  

>perhaps you're using something home-grown?

Yes, it's call UNIX :-).  You can setup communications between tasks
running on different computers if both computers support stream pipes.
This is an alternative to sockets.
Stream pipes are supported in Unix, but apparently not in VxWorks.
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | "Why must hailstones always
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 |  be the size of something
|_____|/  |_|/       |_____|/                     |  else?"   George Carlin 

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

Newsgroups: comp.os.vxworks
Subject: Looking for SBUS digital I/O board w/driver
Date: Tue, 21 Dec 1993 20:04:09 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.93Dec21150409@squash.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Sender: news@cs.cmu.edu (Usenet News System)


Hello all,

We're looking for an SBus card to acquire some 16-bit wide digital
data with a Themis Sparc-2SE CPU board. Ideally, we'd be looking for a
board that comes with a VxWorks 5.1 driver (or for which there exists
one in the PD). 
I know there must be many such boards out there, but if someone could
recommend one that has worked in a VxWorks environment, that would
give us a head start on the search!
Please e-mail to hmp@cs.cmu.edu if you have any advice to offer.

Thanks, and happy holidays to you all!

- -Henning

- --
                     Fast, Cheap, Good: Choose Any Two

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: Tue, 21 Dec 1993 23:50:10 GMT
From: kent@wrs.com (Kent Long)
Organization: Wind River Systems, Inc.
Message-ID: <CIEsvo.28w@wrs.com>
References: <hjbCICtFy.6Ms@netcom.com> <21DEC199300404664@kelvin.jpl.nasa.gov> <hjbCID4r5.y7@netcom.com>
Sender: news@wrs.com (News Manager)

In article <hjbCID4r5.y7@netcom.com> hjb@netcom.com (squeedy) writes:
>>
>there is no reason to believe mounting
>an nfs filesytem will have any affect on pipeDrv.

Hwa-Jin is right.  Since the VxWorks pipe interface is built on
top of message queues, it can only be used in those situations where
you could just use the msgQ's directly.  Which, for now at least, means
only on VxWorks.

>vxworks pipeDrv
>does not provide "priority bands".  all messages are delivered at normal
>priority.  if you want prioritized message delivery use message queue directly
>instead.  

Actually, normal VxWorks message queues do not have per-message priorities
either.  There is an option during msgQSend() to have the message queued
in FIFO order (MSG_PRI_NORMAL) or directly to the front of the queue
(MSG_PRI_URGENT), but that's it.

WRS is currently finishing an add-on release which will provide a number
of interfaces from the POSIX.1b (formerly POSIX.4) spec, including
message queues.  POSIX message queues do indeed have per-message priorities.
However, pipes will continue to be implemented on top of the older,
non-prioritized queues.

Bye for now,

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

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

Newsgroups: comp.os.vxworks
Subject: Rebooting 68040 via backplane
Date: Tue, 21 Dec 1993 14:44:29 GMT
From: NSEMICH@relay.nswc.navy.mil (Neal E. Semich)
Organization: NSWCDD, Dahlgren, VA 22448
Message-ID: <NSEMICH.1.2D170BCD@relay.nswc.navy.mil>
Sender: news@relay.nswc.navy.mil (newserver)


System : One Force SPARC 2CE and one Motorola 68040 in a VME backplane system. 
              The SPARC is the system controller board.  The SPARC is running 
              4.1.3 and the 68040 is running VxWorks 5.0.3.

Problem : When system is initially powered up, 68040 board times out before the
                SPARC can complete its boot sequence.  The 68040 will then not 
                boot until an '@' is typed at the terminal or the RESET switch 
                is pressed.

Question : Is there any way to delay the 68040 from booting OR is there a way 
                to send a reboot over the backplane.


Thanks in advance and have a Happy Holiday.

Neal
Neal E. Semich
Naval Surface Warfare Center
Dahlgren Division Code F33
Dahlgren, VA  22448-5000
(703) 663-6278
nsemich@relay.nswc.navy.mil      ; input user's common ID




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

Newsgroups: comp.os.vxworks
Subject: Re: Rebooting 68040 via backplane
Date: Wed, 22 Dec 1993 06:56:05 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCIFCLI.C2z@netcom.com>
References: <NSEMICH.1.2D170BCD@relay.nswc.navy.mil>

NSEMICH@relay.nswc.navy.mil (Neal E. Semich) writes:


>System : One Force SPARC 2CE and one Motorola 68040 in a VME backplane system. 
>              The SPARC is the system controller board.  The SPARC is running 
>              4.1.3 and the 68040 is running VxWorks 5.0.3.

change TIMEOUT in bootConfig.c.  default is 7 seconds, change it to something
longer.

>Neal E. Semich
>Naval Surface Warfare Center

hey! thanks for using vxworks.

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

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


From dlr@electromac.mc.duke.edu  Wed Dec 22 06:25:12 1993
From: dlr@electromac.mc.duke.edu
Date: Wed Dec 22 06:25:21 PST 1993
Subject: Re: Storage Media

>From: Iveland, Scott T
>Date: Tue, Dec 21, 1993 8:29 AM
>Subject: Storage Media
>To: vxworks Exploder
>I need some advice on storage media. I have an application where we are taking 
>data from an airborne camera. The data comes from the camera into RAM in a VME 
>chassis. After 640 Mbytes of data is collected we need to store it as the 
>aircraft swings around to take another swath of data. Our first iteration of 
>this used a magneto-optical drive to store the data. The camera resolution was 
>much smaller and the amount of data collected was only 64 Mbytes/swath. The MO 
>drive worked OK, but it was slow. The data rate of the MO drive will be 
>unacceptable for the new system. 
>
>Does anyone have information on tape drives & vxWorks drivers?
> What kind of data rates can you write to them? 
>Do you have to go back to the start of the tape every time you want to add a 
>file to it? If so, how long does that operation take?
>
>Are there any other options for high density, fast access, removable storage 
>media?
>
>Thanks in advance
>Scott Iveland
>

  Our lab has a data acquisition system that generates a 2.1 Mbyte data stream
which we dump to tape in real time.  We use a VLDS tape drive from Metrum 
Information Systems, ph. (303) 773-4700.  The unit we have can record a 
continous data stream of 4 Mbytes per second.  It uses VHS tapes for the storage 
media.  You do not have to rewind the tape to add more data and it will not 
overwrite previous data if it has been rewound.




_______________________________________________________________
|  Dennis Rollins                      dlr@sunbar.mc.duke.edu |
|  Basic Arrhythmia Lab                                       |
|  Duke University Medical Center                             |
_______________________________________________________________


From daemon@vxw.ee.lbl.gov  Thu Dec 23 04:01:42 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Dec 23 04:01:50 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec 23 04:01:33 PST 1993

        Subject: PCC2 CHIP

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

Newsgroups: comp.os.vxworks
Subject: PCC2 CHIP
Date: 23 Dec 1993 00:09:09 GMT
From: edwink@orff.jpl.nasa.gov (Edwin Khachatourian)
Organization: JPL
Message-ID: <2fanj5$688@elroy.jpl.nasa.gov>


	Hi, does anyone have any experience with programming the PCC2 chip
on the 167. I know that VxWorks provides support routines for interfacing
with this chip in "pccchip.h" & "pccchip2.h" header files.

	What I need to do with this chip is that I am supposed to receive a 
pulse through the PRFAULT* pin 100 times a second from an external source. 
I need to set up the chip so that the chip will generate an edge sensitive interrupt which will invoke an ISR that I have tied to the vector of the
generated interrupt. 

	Can you please tell me how I can accomplish this, & how can I tell 
what interrupt is being generated when I receive the pulse.

	Thank you very much,
	Edwin Khachatourian
	edwink@orff.jpl.nasa.gov

	/(o\
	\o)/

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

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


From pak@rtp.co.uk  Thu Dec 23 05:22:05 1993
From: pak@rtp.co.uk (Paul Keir)
Date: Thu Dec 23 05:22:21 PST 1993
Subject: ARCNET for VxWorks


Has anyone out there got an ARCNET driver to sit under TCP/IP for a
VxWorks target ?  I guess we'd need source as we will want to get
it going for a PC target.

Any help would be much appreciated.

Regards,

Paul Keir

Real Time Products Ltd
pak@rtp.co.uk


From daemon@vxw.ee.lbl.gov  Fri Dec 24 04:01:44 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Dec 24 04:01:54 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 24 04:01:34 PST 1993

        Subject: Re: PCC2 CHIP
        Subject: Booting 68040 from CDROM

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

Newsgroups: comp.os.vxworks
Subject: Re: PCC2 CHIP
Date: Thu, 23 Dec 1993 13:17:20 GMT
From: peterm@offprs.uucp (Eric PETERMANN)
Organization: Motorola Computer Group, Paris France 
Message-ID: <1993Dec23.131720.14822@phx.mcd.mot.com>
References:  <2fanj5$688@elroy.jpl.nasa.gov>
Sender: peterm@offprs (Eric PETERMANN)


In article <2fanj5$688@elroy.jpl.nasa.gov>, edwink@orff.jpl.nasa.gov (Edwin Khachatourian) writes:
|> 
|> 	Hi, does anyone have any experience with programming the PCC2 chip
|> on the 167. I know that VxWorks provides support routines for interfacing
|> with this chip in "pccchip.h" & "pccchip2.h" header files.
|> 
|> 	What I need to do with this chip is that I am supposed to receive a 
|> pulse through the PRFAULT* pin 100 times a second from an external source. 
|> I need to set up the chip so that the chip will generate an edge sensitive interrupt which will invoke an ISR that I have tied to the vector of the
|> generated interrupt. 
|> 
|> 	Can you please tell me how I can accomplish this, & how can I tell 
|> what interrupt is being generated when I receive the pulse.
|
The pccchip is MVME147 pccchip2 is 167.

The MVME167/187 Programmer's Reference Guide will describe in chapter 3 the insider information on the PCCchip2 you need :

The VxWorks BSP will initialize the Vector Base register (@ $FFF42003)to a value (suggested value is $50) thus encoding all interrupt sources that the PCC2chip handles.

PRFAULT is $53 if conventional programming of this register was used by WindRiver. 

You will also have to watch out for the following bit settings :

Printer Fault Int. Contr. register @ $FFF42031
bits E/L  IEN PLTY and IL[0-2]

Printer Input Status Reg @ $FFF42036
bits FLT and PINT
Interrupt Level Mask Reg. @ $FFF4203F
bits 0-2

AND 

General Control Reg. @ $FFF42002
bit MIEN

This bit is probably set already by the BSP because the WIND kernel will use one of the PCC2chip2's built-in timers...but check it out just in case.

NOTE : these are all 8 bit accesses so you need to MOVE.B to them (VMEchip2 is 32bit access only)
- -- 
Eric
================================================================================
Eric Petermann                  E-mail:peterm@france.europe.mcd.mot.com 
Motorola Computer Group             

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

Newsgroups: comp.os.vxworks
Subject: Booting 68040 from CDROM
Date: Thu, 23 Dec 1993 21:06:27 GMT
From: NSEMICH@relay.nswc.navy.mil (Neal Semich)
Organization: NSWCDD, Dahlgren, VA 22448
Message-ID: <NSEMICH.3.2D1A0853@relay.nswc.navy.mil>
Sender: news@relay.nswc.navy.mil (newserver)


System : Three (3) Motorola 68040 processors and a couple of interface boards 
              in a VME cage.  Using VADSWorks to develop the system and the 
              version of VxWorks is 5.0.3.

Currently we load the processors via Ethernet from a BriteLite IPX.  We need 
to start load from a different device.  We have looked at a couple of 
different options (flash memory, hard drive, Exabyte).  All of these options 
are viable, but the program could be destroyed/overwritten.  Also we need 
the capability of loading different programs easily. We are thinking about 
using a CDROM for loading to overcome this problem.  Problem is we have never 
done this.  Does anybody have any information on this?  If this is possible is 
it similar to a hard drive which it is recommended to format as a DOS drive?

Thanks,
   Neal
Neal Semich

nsemich@relay.nswc.navy.mil      ;  My opinion and only my opinion!!!!




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

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


From daemon@vxw.ee.lbl.gov  Thu Dec 30 04:01:52 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Dec 30 04:02:01 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec 30 04:01:42 PST 1993

        Subject: Re: Pipes to other Computers?
        Subject: Re: Pipes to other Computers?

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: Wed, 29 Dec 1993 18:15:16 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems
Message-ID: <james.757188916@wrs.com>
References: <20DEC199306323253@kelvin.jpl.nasa.gov>
Reply-To: james@wrs.com
Sender: news@wrs.com (News Manager)


baalke@kelvin.jpl.nasa.gov (Ron Baalke) writes:

>Unfortunately, the problem with message queues is you can't do a select
>on them.  The priority bands are a feature of stream pipes.

You can't do a select on a message queue, but you can on a vxWorks
pipe.  However, this doesn't solve the priority issue for you.

I've found this thread a little confusing, as I think people are using
the same names to talk about very different things.  I'm guessing that
Ron's using streams on a Solaris machine, and wants to do something
like an fattach(streamFD, "/exportedFileSystem/streamdescriptor") on
both Solaris and vxWorks.  The answer to this request is that vxWorks
doesn't have STREAMS support right now.

UNIX named pipes, which are limited to one machine, boil down to
UNIX-domain sockets, and, as far as I can tell, have nothing
whatsoever to do with Ron's original question.

>Yes, it's call UNIX :-).  You can setup communications between tasks
>running on different computers if both computers support stream pipes.
				                          ^^^^^^^^^^^^

I think this phrase is part of the problem.  To me, it means a variety
of different things.  Pre-solaris Sunos supports stream pipes in a
couple different ways (named pipes and pipes created with the pipe()
call), but this support doesn't extend to transfers between machines.
VxWorks has support for pipes, although not really stream pipes as
pipeDrv is message-oriented.  You could set up a socket pair on
VxWorks as a stream pipe though.

- -- 
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
	 "Half of what he said meant something else, and the other half
			  didn't mean anything at all"

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

Newsgroups: comp.os.vxworks
Subject: Re: Pipes to other Computers?
Date: 29 Dec 1993 19:14 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <29DEC199319140573@kelvin.jpl.nasa.gov>
References: <20DEC199306323253@kelvin.jpl.nasa.gov> <james.757188916@wrs.com>

In article <james.757188916@wrs.com>, james@wrs.com writes...
> 
>I've found this thread a little confusing, as I think people are using
>the same names to talk about very different things.  I'm guessing that
>Ron's using streams on a Solaris machine, and wants to do something
>like an fattach(streamFD, "/exportedFileSystem/streamdescriptor") on
>both Solaris and vxWorks.  The answer to this request is that vxWorks
>doesn't have STREAMS support right now.

This is exactly what I was asking.

>> You can setup communications between tasks
>>running on different computers if both computers support stream pipes.
>				                          ^^^^^^^^^^^^> 
>I think this phrase is part of the problem.  To me, it means a variety
>of different things.  Pre-solaris Sunos supports stream pipes in a
>couple different ways (named pipes and pipes created with the pipe()
>call), but this support doesn't extend to transfers between machines.
>VxWorks has support for pipes, although not really stream pipes as
>pipeDrv is message-oriented.  You could set up a socket pair on
>VxWorks as a stream pipe though.

I was just looking to see if there was an alternative to using sockets,
but it looks like there isn't for Solaris/VxWorks communications.

And in case you're wondering, the application I'm working on is to
record the signal from the Galileo spacecraft when it arrives at Jupiter
and combine the signals from different antennas to boost the signal
level.
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | "Why must hailstones always
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 |  be the size of something
|_____|/  |_|/       |_____|/                     |  else?"   George Carlin 

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

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


From daemon@vxw.ee.lbl.gov  Fri Dec 31 04:01:35 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Dec 31 04:01:43 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 31 04:01:26 PST 1993

        Subject: Where is Leonid Rosenboim?

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

Newsgroups: comp.os.vxworks
Subject: Where is Leonid Rosenboim?
Date: Thu, 30 Dec 1993 17:28:29 GMT
From: geurin@TexasEx.nosc.mil (Chance C. Geurin)
Organization: NCCOSC, RDT&E, San Diego, Ca
Message-ID: <1993Dec30.172829.11950@nosc.mil>
Reply-To: geurin@nosc.mil
Sender: usenet@nosc.mil (Network News)

Has anybody heard from or talked with Leonid Rosenboim?  I can no longer
send him Email at his last known address:  RST.HellNet.org.

Thanks,
- -------------------------------------------------------------------------------
Chance C. Geurin
Naval Command, Control & Ocean Surveillance Center, Research, Development,
Test & Evaluation Division (NCCOSC RDT&E or just NRaD).
San Diego, Ca
geurin@nosc.mil
- -------------------------------------------------------------------------------


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

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


From thor@thor.atd.ucar.edu  Fri Dec 31 23:00:27 1993
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Fri Dec 31 23:00:36 PST 1993
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

total 4156
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor        37126 Jun 12  1992 ansilib01
-rw-r--r--  1 thor        18913 Jun 12  1992 ansilib02
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6  1991 dhrystones01
-rw-r--r--  1 thor        19170 Apr  1  1993 dirlib01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1  1991 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         2453 Mar 10  1993 gcc+68040
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor        12091 Dec  8 10:36 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
-rw-r--r--  1 thor        10747 Nov  3 11:54 libg++-2.5-src.patch
lrwxrwxrwx  2 thor           20 Nov 19 13:44 libg++-2.5.1-src.patch -> libg++-2.5-src.patch
lrwxrwxrwx  2 thor           20 Nov 19 13:44 libg++-2.5.2-src.patch -> libg++-2.5-src.patch
-rw-r--r--  1 thor         1568 Nov  3 11:54 libgcc2-2.5.0.patch
-rw-r--r--  3 thor         1545 Nov  3 11:55 libgcc2-2.5.2.patch
lrwxrwxrwx  1 thor           19 Nov 19 13:45 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch
-rw-r--r--  3 thor         1545 Nov  3 11:55 libgcc2-2.5.5.patch
-rw-r--r--  3 thor         1545 Nov  3 11:55 libgcc2-2.5.6.patch
lrwxrwxrwx  2 thor           15 Nov 19 13:45 libio-2.5.1.patch -> libio-2.5.patch
lrwxrwxrwx  2 thor           15 Nov 19 13:45 libio-2.5.2.patch -> libio-2.5.patch
-rw-r--r--  1 thor         1228 Dec 29 09:51 libio-2.5.patch
lrwxrwxrwx  1 root            6 Aug 14  1991 libx11 -> libX11
-rw-r--r--  1 thor         3515 Mar 16  1993 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor       829713 Dec 17 08:10 ntpv3.1.tar.gz
-rw-r-----  1 thor      1010176 Nov  8 13:42 ntpv3.tar.gz
-rw-r--r--  1 thor         1082 Dec 14 09:09 objc.patch
-rw-r--r--  1 thor        19593 Dec  8 10:43 ping01
-rw-r--r--  1 thor        20494 Oct 31  1991 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Aug 14  1991 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31  1991 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Aug 14  1991 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        41196 Oct 16  1992 stevie01
-rw-r--r--  1 thor        35279 Oct 16  1992 stevie02
-rw-r--r--  1 thor        35278 Oct 16  1992 stevie03
-rw-r--r--  1 thor        35012 Oct 16  1992 stevie04
-rw-r--r--  1 thor        34502 Oct 16  1992 stevie05
-rw-r--r--  1 thor        37476 Oct 16  1992 stevie06
-rw-r--r--  1 thor        30073 Oct 16  1992 stevie07
-rw-r--r--  1 thor        31562 Oct 16  1992 stevie08
-rw-r--r--  1 thor        37360 Oct 16  1992 stevie09
-rw-r--r--  1 thor        20662 Oct 16  1992 stevie10
-rw-r--r--  1 thor        25717 Oct 16  1992 stevie11
-rw-r--r--  1 thor        28075 Oct 16  1992 stevie12
-rw-r--r--  1 thor        31852 Oct 16  1992 stevie13
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor         8424 Apr  1  1992 syslog.shar
-rw-r--r--  1 thor        15096 Oct  2  1991 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-rw-r--  1 root       556461 Oct  9 14:19 tclvx7.0.v2.tar.gz
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        19912 Aug 27  1992 tp41.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor         5608 Dec  2  1992 veclist01
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22  1991 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22  1991 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22  1991 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22  1991 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22  1991 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22  1991 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22  1991 vwcurses07
-rw-r--r--  1 thor         5491 Dec  8 10:40 vx_cplusplus
-rw-r--r--  1 thor        29720 Aug 28  1991 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28  1991 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28  1991 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16  1992 wdog_class



From leonid@rst.hellnet.org  Mon Dec 13 10:58:28 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Mon Dec 13 10:58:42 PST 1993
Subject: Re: help- problem with "open" and memory reqt
>hsingnan@ivo.jpl.nasa.gov (Dan Chang) writes:
> Does anyone know the memory requirements to simply open 
> a file for binary read (using open statement). I was surprised
> to see the error msg: ...

When using netDrv with either RSH or FTP, an open() call will copy
the entire file into VxWorks memory before retrning. With NFS
and local file systems (e.g. SCSI) this does not happen.

-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org