From owner-vxwexplo-process  Tue Dec  1 09:29:03 1998
From: Hamid Shoaee <hamid@SLAC.Stanford.EDU>
Date: Tue Dec  1 09:29:06 PST 1998
Subject: Booting VxWorks from Flash memory or eproms


Does anyone know if it's possible to boot VxWorks from flash memory or 
EPROM rather than through the network. In particular, it would be very 
useful if at boot time it could check for the presence of boot image in 
flash/prom and failing that then it would try the network option. I would 
appreciate any information on this option.

Hamid Shoaee
Stanford Linear Accelerator Center
Stanford, CA



From owner-vxwexplo-process  Tue Dec  1 11:29:32 1998
From: "Keith Buchanan" <Keith_Buchanan@SPARTA.com>
Date: Tue Dec  1 11:29:35 PST 1998
Subject: RE: Booting VxWorks from Flash memory or eproms

> Does anyone know if it's possible to boot VxWorks from flash memory or
> EPROM rather than through the network. In particular, it would be very
> useful if at boot time it could check for the presence of boot image in
> flash/prom and failing that then it would try the network option. I would
> appreciate any information on this option.

VxWorks will boot from EPROM or flash if your target and BSP author chose to
support and test the options.  The programmer's guide includes instructions
on how compile standalone versions (compressed, uncompressed, text in ROM,
etc) of vxWorks that includes your application.

SPARTA often modifies the boot sequence, adding the capability to boot from
a file system in memory.(could be flash, EPROM, NVRAM, etc)  The boot
sequence then convienently resembles the network boot cycle.(provided WRS
continues to support startup scripts!!)  It is fairly easy to alter the boot
sequence to try multiple boot options.  The current boot options already
return control to the boot configuration interface when they fail.  You just
have to insert code to try again in a chosen order.


adios
----------------------------------
     /\\     Thomas Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  519 Interstate 30
 / \\\\\  \\ Suite 140
 \  \\\\\ // Rockwall, TX 75087
  \  //////
   \//////   Voice: 972 672 9657
    \////    FAX:   972 722 1216
     \//     WWW:   www.sparta.com




From owner-vxwexplo-process  Tue Dec  1 11:54:52 1998
From: Fred Roeber <froeber@bbn.com>
Date: Tue Dec  1 11:54:56 PST 1998
Subject: Re: Booting VxWorks from Flash memory or eproms

Hamid Shoaee asks about vxworks:

> Does anyone know if it's possible to boot VxWorks from flash memory or
> EPROM rather than through the network. In particular, it would be very
> useful if at boot time it could check for the presence of boot image in
> flash/prom and failing that then it would try the network option. I would
> appreciate any information on this option.

This is definitely possible. We have systems that boot standalone right
from FLASH. The normal VxWorks bootrom starts up a minimalistic version
of VxWorks from EPROM. We took parts of the bootrom code (from
config/all/bootConfig.c) and parts of the normal downloaded VxWorks
image (from config/all/usrConfig.c) and melded them together to get a
full function standalone image. I suggest studying the code components
that are built into the bootrom image for your board and downloaded
image to see how the two images work. Then you can just cut-and-paste
from the two images to get the image you want.   Fred

-- 
   |      Fred J Roeber,  BBN Systems & Technologies      |
   |    4 John Clarke Road   Middletown, RI  02842-5202   |
   |          froeber@bbn.com     401-848-3548            |
   | TraceMaker product manager -> www.tracemaker.bbn.com |


From owner-vxwexplo-process  Tue Dec  1 12:10:21 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Tue Dec  1 12:10:25 PST 1998
Subject:  sysBusToLocalAdrs()

VxWorks 5.3.1
MVME2700 1.1/4

I have a question about the behavior of sysBusToLocalAdrs().  But first, I'd
like to share my own observations.

The mv2604 BSP man page for sysLocalToBusAdrs() says:  "This routine returns
a VMEbus address as it would be seen on the bus.  The local address that is
passed into this routine is the address of the local resource as seen by the
CPU."  Indeed, this routine works as described.

The mv2604 BSP man page for sysBusToLocalAdrs() says:  "This routine returns
a local address that is used to access the VMEbus.  The bus address that is
passed into this routine is the VMEbus address as it would be seen on the
bus."  This description seems a little vague, and I could interpret it in
two ways:

1)  The local address returned is always assumed to be off-board.  If you
tried to use the address to access an on-board resource, it would fail.  For
example, if the calling board were mapped to the VMEbus, the CPU address of
local memory were zero, the VMEbus address of the board were 0x08000000, and
the CPU address of VMEbus location 0x08000000 were 0x10000000, the value
returned by sysBusToLocalAdrs() when called with a bus address of 0x08000000
would be 0x10000000.

2) The local address returned is appropriate for either on-board or
off-board accesses.  For example, if the calling board were mapped to the
VMEbus, the CPU address of local memory were zero, the VMEbus address of the
board were 0x08000000, and the CPU address of VMEbus location 0x08000000
were 0x10000000, the value returned by sysBusToLocalAdrs() when called with
a bus address of 0x08000000 would be 0.

I know for a fact that the mv2604/mv2700 implementation of
sysBusToLocalAdrs() matches interpretation 1).  My question (finally) is: 
Do other BSPs intepret the behavior of sysBusToLocalAdrs() the same way? 
I'd appreciate a response from as wide a variety of BSP users as possible.

Thanks in advance.

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com


From owner-vxwexplo-process  Tue Dec  1 12:42:11 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Tue Dec  1 12:42:14 PST 1998
Subject: Booting VxWorks from Flash memory or eproms -Reply

Hamid,

It is possible to boot VxWorks from flash or ROM, though booting from ROM or the network is not an
either/or proposition (unless you design your own application to boot from ROM which, in turn,
boots VxWorks from ROM or in the "traditional" manner).  The procedure for building a standalone
VxWorks is documented in the Tornado User's Guide in the "Creating Bootable Applications"
section.  The actual process of getting into your flash is hardware-specific.

HTH

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com

>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/01/98 11:29am >>>
Submitted-by owner-vxwexplo-process  Tue Dec  1 09:29:03 1998
Submitted-by: Hamid Shoaee <hamid@SLAC.Stanford.EDU>


Does anyone know if it's possible to boot VxWorks from flash memory or 
EPROM rather than through the network. In particular, it would be very 
useful if at boot time it could check for the presence of boot image in 
flash/prom and failing that then it would try the network option. I would 
appreciate any information on this option.

Hamid Shoaee
Stanford Linear Accelerator Center
Stanford, CA



From owner-vxwexplo-process  Tue Dec  1 15:39:53 1998
From: pbrett@hathaway-systems.com
Date: Tue Dec  1 15:39:57 PST 1998
Subject: Re: Booting VxWorks from Flash memory or eproms


-----Original Message-----
From: the vxWorks Users Group Exploder <vxwexplo@lbl.gov>
To: vxworks_users@csg.lbl.gov <vxworks_users@csg.lbl.gov>
Date: Tuesday, December 01, 1998 3:07 PM
Subject: Booting VxWorks from Flash memory or eproms


>Submitted-by owner-vxwexplo-process  Tue Dec  1 09:29:03 1998
>Submitted-by: Hamid Shoaee <hamid@SLAC.Stanford.EDU>
>
>
>Does anyone know if it's possible to boot VxWorks from flash memory or
>EPROM rather than through the network. In particular, it would be very
>useful if at boot time it could check for the presence of boot image in
>flash/prom and failing that then it would try the network option. I would
>appreciate any information on this option.
>
>
Yes. Pretty much anything is possible. I have worked on two projects which
have taken radically different approaches to this.

1) The highly custommised version.

The hardware has 16 MB of DRAM and 1 MB flash.  Some standalone code
(written in a combination of assember and C) resides in the bootblock of the
flash device. The memory is arranged so that the bootblock is pointed to by
the reset vector. On reset, the initial code which runs sets up global
descriptor tables etc (x86 architecture) and copies another program from the
bootblock to DRAM. The thread of execution then jumps to this point in DRAM.
The remainder of the flash is divided into code blocks and configuration
blocks. CRCs of these blocks are now checked. If any do not match, then the
system prints a message to the LCD and waits for code / configuration to be
sent using XModem to a serial port. Once the transfer is complete, the
system reboots.
If the CRCs check out OK, the vxWorks image (with application statically
linked to it) is copied from flash to DRAM. finally the custom code jumps to
the entry point of the vxWorks image.
The main reason for the complexity of this solution was that no vxWorks
image would fit into the bootblock of the selected flash device.


2) If you do not want to damage brain cells

The other project uses a SanDisk flash disk. This device looks pretty much
like a standard IDE disk.
First boot a PC with the SanDisk installed to DOS. Format the SanDisk, and
run vxsys on it. Next make bootrom_uncmp and vxWorks. From bootrom_uncmp
create bootrom.sys by "vxcopy bootrom_uncmp bootrom.sys" copy bootrom.sys
followed by vxWorks and vxWorks.sym onto the SanDisk. Install the SanDisk in
the target and boot the system with a bootline something like:
ata=0,0(0, 0){HOST:}/ata0/vxWorks e={target_ip_address} h =
{host_ip_address} u = {user_name} pw = {password} tn = {target name} o =
{ethernet device}

It is unlikely that either of these solutions will entirely meet your needs,
but I hope they will give you an idea of what is possible and the work
involved.
My employer will not allow me to release source, but if I can be of any
further help otherwise, let me know.

Regards,
        Pete



From owner-vxwexplo-process  Tue Dec  1 15:51:21 1998
From: "John R. Moore III" <jrm@mclean.sparta.com>
Date: Tue Dec  1 15:51:24 PST 1998
Subject: Re: sysBusToLocalAdrs()

A constant source of confusion: 
	Because sysBusToLocalAdrs and sysLocalToBusAdrs are not inverses of
each other, and usually only have enough information to do the address
translation in one direction, interpretation 2 does not work in the
general case.  I haven't seen a BSP whose sysBusToLocalAdrs would know
that you were selecting the calling boards local address if presented
with its VME slave address.  Of course you could extend the function
yourself to do this.  The MV162 (68k), MV167(68k), Heurikon V4D(68k),
Themis SPARC, Force SPARC, and the VME based x86 processors that I have
worked with all adhere to interpretation 1.  The set of registers (on
the VME interface chip) that allow master access to the bus, will
reflect how sysBusToLocalAdrs functions, and the set of registers that
control slave access to the board, reflect how sysLocalToBusAdrs
functions.  

  


the vxWorks Users Group Exploder wrote:
...
> I have a question about the behavior of sysBusToLocalAdrs().  But
> first, I'd
> like to share my own observations.
 ...
> The mv2604 BSP man page for sysBusToLocalAdrs() says:  "This routine
> returns
> a local address that is used to access the VMEbus.  The bus address
> that is
> passed into this routine is the VMEbus address as it would be seen on
> the
> bus."  This description seems a little vague, and I could interpret it
> in
> two ways:
...
> 2) The local address returned is appropriate for either on-board or
> off-board accesses.  For example, if the calling board were mapped to
> the
> VMEbus, the CPU address of local memory were zero, the VMEbus address
> of the
> board were 0x08000000, and the CPU address of VMEbus location
> 0x08000000
> were 0x10000000, the value returned by sysBusToLocalAdrs() when called
> with
> a bus address of 0x08000000 would be 0.
> 
> I know for a fact that the mv2604/mv2700 implementation of
> sysBusToLocalAdrs() matches interpretation 1).  My question (finally)
> is:
> Do other BSPs intepret the behavior of sysBusToLocalAdrs() the same
> way?
> I'd appreciate a response from as wide a variety of BSP users as
> possible.
 
-- 

------------------------------------------------------------ 
|John R. Moore              | Voice -> 703 448 1683 x229   | 
|Principal Engineer         | FAX   -> 703 893 5494        | 
|EMAIL:                     | On the WEB!                  | 
|jrm@mclean.sparta.com      | http://www.mclean.sparta.com | 
|___________________________|______________________________| 
|                                     |                    | 
|     /\\     SPARTA, Inc.            |                    | 
|    ///\\    7926 Jones Branch Drive |                    | 
|   /////\\   Suite 900               |                    | 
|  /////  \\  McLean, VA 22102        |                    | 
| / \\\\\  \\ 703-448-0120            |         	   | 
| \  \\\\\ //                         |                    | 
|  \  //////                          |                    | 
|   \//////   SPARTA                  |                    | 
|    \////    Pride In Performance    |                    | 
|     \//     --------------------    |                    | 
------------------------------------------------------------


From owner-vxwexplo-process  Tue Dec  1 16:25:51 1998
From: "James B. Hawthorne" <jbhawth@aptec.com>
Date: Tue Dec  1 16:25:54 PST 1998
Subject: Connecting a PC to VxWorks NFS Server

VxWorkers-

I am trying to connect a PC running Hummingbird's NFS Client software to an
MVME162-533 running Tornado with the NFS Server option turned on. We have
been able to mount the exported directories from a UNIX machine running
Solaris and have verified proper configuration of the VxWorks NFS server.
When trying to connect with Hummingbird from the PC, it seems to expect the
server to be running pcnfsd or hclnfsd. This makes sense on a UNIX server
but I am not aware of any such daemon that runs on the VxWorks system.

Does anyone have experience with this type of configuration and were you
successful in making the connection?

Stuck in HELLstf at White Sands Missle Range...

Jim

************************************************************
Jim Hawthorne                   Voice: (505) 767-1228
Applied Technology Associates   Fax:   (505) 768-1379
1900 Randolph Road SE           email: jbhawth@aptec.com
Albuquerque, NM 87106           Web:   http://www.aptec.com/
************************************************************



From owner-vxwexplo-process  Tue Dec  1 16:32:29 1998
From: Tom Antles <antles@spk.hp.com>
Date: Tue Dec  1 16:32:32 PST 1998
Subject: dosFsLib patch increases mem usage 8X or more

tornado vxworks


Has anyone else run into memory usage problems with the latest dosFsLib
Patch? ( I believe it was approx 8/98 and goes by any of the following SPRs:
21475, 9465, 4061, 8721, 9057 ...)

This dosFsLib patch is requesting more than 1.5Mbytes of memory while
running in the bootrom and causing memPartAlloc failures.  A comparison
before and after the patch shows:

  - pre dosFsLib patch: 
	The call to dosFsDevInit from usrIdeConfig resulted in alloc of
        ~200Kbytes 

  - post dosFsLib patch: 
	The call to dosFsDevInit from usrIdeConfig resulted in memPartAlloc
        failure after allocating 1.5Mbytes.

This means that it requested almost 8 times more memory and still didn't get
enough. This is a problem since this is happening in a bootcode executing at
RAM_HIGH_ADRS, where we typically only allocate 1Meg total space for both
code and system memory partition (we tried 2Meg for the experiment above and
still didn't get enough - the code was approx 500Kbytes, the free list
1.5Mbytes).


Fundamentally it seems that something must be wrong to need 1.5MBytes to
represent the ~300 files on our hard drive.  Also, the 8X growth factor
doesn't seem right either.

Even though I haven't checked yet, it most likely means that our
applications will need/use this much more memory too, which is not desirable
either.


 Tom Antles
 antles@spk.hp.com
 Phone: (509) 921-3590
 Fax:   (509) 921-3991


From owner-vxwexplo-process  Wed Dec  2 10:30:57 1998
From: Anthony Le <anthony.le@lamrc.com>
Date: Wed Dec  2 10:31:00 PST 1998
Subject: VxWorks and PC104

Hi Users:

Does anyone currently use the generic VxWorks 486 kernel with PC104 board?

I am also looking for Analog IO and Digital IO modules for PC104 which VxWorks currently supports.

If you have this PC104 configuration, I like to hear from you.

Anthony Le
LAM Research Corp.
anthony.le@lamrc.com





From owner-vxwexplo-process  Wed Dec  2 15:03:44 1998
From: Hesham_Elbakoury@BayNetworks.COM (Hesham Elbakoury)
Date: Wed Dec  2 15:03:47 PST 1998
Subject: VxWorks vx other Real-time OS


  From your experience with vxWorks and windRiver systems what are the most 
  important reasons why one would choose VxWorks instead of another real-time
  OS like Nucleus ?

  Regards

  Hesham



From owner-vxwexplo-process  Thu Dec  3 01:41:16 1998
From: "Alex Reznik" <alexr@telegate.co.il>
Date: Thu Dec  3 01:41:21 PST 1998
Subject: Re: Booting VxWorks from Flash memory or eproms

                        Hi,

             the answer is: "shurely, YES". There is the special kind  of
vxWorks' image  which is called "vxWorks ROM-resident".
            This image can be built by usual make procedure from a standard
BSP. The details are described in the "Configuration" section of "vxWorks
Programmers Guide". The only preparation that is not described there and
seems absolutely necessary is to adjust jumpers on your target in purpose to
start from the address which is assigned to the EPROM with vxWorks.
            There is the second possibility - to use any of FlashFile
systems which are implemented for vxWorks:
to put (to copy) the vxWorks image onto the Flash device, and to change
slightly the file "bootConfig.c" of
your BSP. The goal of this change is to define a Flash device as one of
possible "boot devices". Then you should build the modified vxWorks bootROM.
           If your vxWorks bootROM will understand a Flash device as one of
"boot" devices you are free to use
the same vxWorks image for downloading both from network and from the Flash
(just copy it on the Flash device).
          Regards,
         Alex Reznik.

alexr@telegate.co.il

>
>Does anyone know if it's possible to boot VxWorks from flash memory or
>EPROM rather than through the network. In particular, it would be very
>useful if at boot time it could check for the presence of boot image in
>flash/prom and failing that then it would try the network option. I would
>appreciate any information on this option.
>
>Hamid Shoaee
>Stanford Linear Accelerator Center
>Stanford, CA
>




From owner-vxwexplo-process  Thu Dec  3 01:51:26 1998
From: "Alex Reznik" <alexr@telegate.co.il>
Date: Thu Dec  3 01:51:29 PST 1998
Subject: Re:  sysBusToLocalAdrs()

Hello,
for mv2304 BSP (MVME23XX boards) it is right too.

Enjoy,
Alex Reznik

Telegate Ltd
alexr@telegate.co.il

-Subject: sysBusToLocalAdrs()


>Submitted-by owner-vxwexplo-process  Tue Dec  1 12:10:21 1998
>Submitted-by: Charlie Grames <cgrames@mdc.com>
>
>VxWorks 5.3.1
>MVME2700 1.1/4
>
>I have a question about the behavior of sysBusToLocalAdrs().  But first,
I'd
>like to share my own observations.
>
>The mv2604 BSP man page for sysLocalToBusAdrs() says:  "This routine
returns
>a VMEbus address as it would be seen on the bus.  The local address that is
>passed into this routine is the address of the local resource as seen by
the
>CPU."  Indeed, this routine works as described.
>
>The mv2604 BSP man page for sysBusToLocalAdrs() says:  "This routine
returns
>a local address that is used to access the VMEbus.  The bus address that is
>passed into this routine is the VMEbus address as it would be seen on the
>bus."  This description seems a little vague, and I could interpret it in
>two ways:
>
>1)  The local address returned is always assumed to be off-board.  If you
>tried to use the address to access an on-board resource, it would fail.
For
>example, if the calling board were mapped to the VMEbus, the CPU address of
>local memory were zero, the VMEbus address of the board were 0x08000000,
and
>the CPU address of VMEbus location 0x08000000 were 0x10000000, the value
>returned by sysBusToLocalAdrs() when called with a bus address of
0x08000000
>would be 0x10000000.
>
>2) The local address returned is appropriate for either on-board or
>off-board accesses.  For example, if the calling board were mapped to the
>VMEbus, the CPU address of local memory were zero, the VMEbus address of
the
>board were 0x08000000, and the CPU address of VMEbus location 0x08000000
>were 0x10000000, the value returned by sysBusToLocalAdrs() when called with
>a bus address of 0x08000000 would be 0.
>
>I know for a fact that the mv2604/mv2700 implementation of
>sysBusToLocalAdrs() matches interpretation 1).  My question (finally) is:
>Do other BSPs intepret the behavior of sysBusToLocalAdrs() the same way?
>I'd appreciate a response from as wide a variety of BSP users as possible.
>
>Thanks in advance.
>
>Charlie Grames
>The Boeing Company
>(314) 233-1956
>Charles.R.Grames@boeing.com
>




From owner-vxwexplo-process  Thu Dec  3 11:28:44 1998
From: Anthony Le <anthony.le@lamrc.com>
Date: Thu Dec  3 11:28:47 PST 1998
Subject: [Fwd: VxWorks and PC104 (fwd)]

This is a multi-part message in MIME format.
--------------A0DBFF75ACF9B61628DB4C22
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------A0DBFF75ACF9B61628DB4C22
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <petri@esrf.fr>
Received: from lamrc.lamrc.com by softeng.lamrc.com (4.1/SMI-4.1)
	id AA18225; Thu, 3 Dec 98 04:27:47 PST
Received: from serverm.lamrc.com by lamrc.lamrc.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI)
	for <anthony.le@lamrc.lamrc.com> id EAA16346; Thu, 3 Dec 1998 04:27:31 -0800
Received: from out.esrf.fr (firewall.esrf.fr [193.49.43.1])
	by serverm.lamrc.com (8.9.0/8.9.0) with SMTP id EAA17831
	for <anthony.le@lamrc.com>; Thu, 3 Dec 1998 04:26:41 -0800 (PST)
Received: (from uucp@localhost) by out.esrf.fr (8.6.10/8.6.10) id NAA08370 for <anthony.le@lamrc.com>; Thu, 3 Dec 1998 13:21:41 +0100
Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3)
	id tmp008241; Thu Dec  3 13:20:50 1998
Received: from freak.esrf.fr (freak.esrf.fr [160.103.5.78]) by esrf.esrf.fr (8.6.10/8.6.9) with SMTP id NAA09799; Thu, 3 Dec 1998 13:23:35 +0100
Received: from localhost by freak.esrf.fr with SMTP
	(1.37.109.4/16.2) id AA01175; Thu, 3 Dec 98 13:25:21 +0100
Sender: petri@esrf.fr
Message-Id: <3666832F.D98EB2CD@esrf.fr>
Date: Thu, 03 Dec 1998 13:25:20 +0100
From: Petri Makijarvi <petri@esrf.fr>
Organization: E.S.R.F.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX A.09.01 9000/715)
Mime-Version: 1.0
To: anthony.le@lamrc.com
Subject: Re: VxWorks and PC104 (fwd)
References: <199812031203.NAA24215@libra.esrf.fr>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
X-Mozilla-Status2: 00000000

Hi,

one of my Tornado/vxWorks/68k using colleagues forwarded this mail to me, don't
know its origin but I will try to answer nevertheless...


> Forwarded message:

> Subject: VxWorks and PC104
>
> Hi Users:
>
> Does anyone currently use the generic VxWorks 486 kernel with PC104 board?
>
> I am also looking for Analog IO and Digital IO modules for PC104 which VxWorks
> currently supports.
>
> If you have this PC104 configuration, I like to hear from you.
>
> Anthony Le
> LAM Research Corp.
> anthony.le@lamrc.com

I have used in an odd project a vxWorks 486 kernel on a PC/104 CPU board. I don't
know what you mean with "generic" but I presume that you mean the original one in
the Tornado 1.0.1 BSP delivery. I couldn't get my PC/104 running with that, but
that is probably because I didn't use any IDE, spinning hard disk but the local
MS-DOS FAT12 Flash hard disk. Additionally I had an onboard Ethernet controller
so to me it was a natural thing to regenerate the kernel with my settings. It
worked fine in my project. I have written some integration details for my PC/104
superMOPSpro CPU board in:

http://www.esrf.fr/computing/cs/sysadmin/rtk/pc104project/howto/vxworks.htm

The configuration settings  you could find by browsing a little the project's
download area in

http://www.esrf.fr/computing/cs/sysadmin/rtk/pc104project/howto/download/

We didn't use any particular PC/104 I/O cards with vxWorks in the project, but
just on-board resources, such as serial lines. Everything went well with the
project and I was happy with Tornado/vxWorks. But today we have big Flash-IDE
disks and we put Linux on them - its free... You'll find more details in the
above site, as well.

Hope that this helped you a bit,

Petri

--
Petri Makijarvi - European Synchrotron Radiation Facility
mailto:petri@esrf.fr - http://www.esrf.fr/computing/cs/sysadmin/rtk/
tel: +33-(0)4.76.88.22.50 fax: +33-(0)4.76.88.20.20
E.S.R.F.  B.P 220 F-38043 Grenoble Cedex   France





--------------A0DBFF75ACF9B61628DB4C22--



From owner-vxwexplo-process  Tue Dec  8 02:17:41 1998
From: Mark Armstrong <msa@kaon.co.uk>
Date: Tue Dec  8 02:17:44 PST 1998
Subject: VxWorks NFS and the automounter on Solaris 2.6

Hello everyone,

	I'm sure some of you remember VxWorks 5.2 and that it can be 
	setup to allow NFS mountable disks.

	This works great with Solaris 2.4, you can even mount 
	and auto-mount VxWorks RAM disks without a problem. 
	Then Sun in there wisdom moved onto NFS version 3 for 
	Solaris 2.5 and 2.6.  You can still mount but auto-mounting
	no longer works.

	The Solaris machine complains:

>	automountd[]: 	No network locking on VW-TARGET
>			Contact admin to install server change.

	Does anyone know a quick fix for this?


	Hope someone can help.

	Mark Armstrong
	Kaon Ltd.


From owner-vxwexplo-process  Tue Dec  8 05:35:56 1998
From: heller@nm.picker.com (Mark Heller)
Date: Tue Dec  8 05:35:59 PST 1998
Subject: blaster/blastee programs for vxWorks



Hello All,

	I'm trying to find the blaster/blastee for
	Vxworks to enable me to test networking 
	performance.

	Any pointers would be appriciated.

	Thanks in advance.

-------
-Mark
-------
Mark Heller
Picker International Inc.
Nuclear Medicine Division

heller@nm.picker.com

VxWorks Tornado VxWorks Tornado


From owner-vxwexplo-process  Tue Dec  8 06:52:27 1998
From: Jerald Pendleton <jerald@wrs.com>
Date: Tue Dec  8 06:52:30 PST 1998
Subject: Re: blaster/blastee programs for vxWorks

At 05:36 AM 12/8/98 -0800, the vxWorks Users Group Exploder wrote:
>Submitted-by owner-vxwexplo-process  Tue Dec  8 05:35:56 1998
>Submitted-by: heller@nm.picker.com (Mark Heller)
>
>
>
>Hello All,
>
>	I'm trying to find the blaster/blastee for
>	Vxworks to enable me to test networking 
>	performance.
>
>	Any pointers would be appriciated.
>
>	Thanks in advance.
>
>-------
>
>VxWorks Tornado VxWorks Tornado
>

All the demo code (blaster and blastee are part of the demo code) can
be found on Windsurf.

HTH,
Jerald Pendleton
------------
Manager - WRS Sustaining Engineering
email:  jerald@wrs.com
"Exacerbate Obfuscation"


From owner-vxwexplo-process  Tue Dec  8 08:37:57 1998
From: Ian.Kerr@bae.co.uk
Date: Tue Dec  8 08:38:00 PST 1998
Subject: Tornado/VxWorks

Hello,

Does anyone know if any version of VxWorks has been certified to the 
      following FAA (and CAA in the UK) required standard?

      RTCA (Requirements and Technical Concepts for Aviation)
      DO-178B
      "Software Considerations in Airborne Systems and Equipment 
      Certification"

      Some systems integrators have been unable to use it as they may 
      have had problems with certification. Some seem to be planning to 
      use it on their aircraft. Anyone?

N.B. Can some one post this to comp.risks and relay the results back as 
      we do not have the technology here? Thanks in advance.

Ian Kerr.


From owner-vxwexplo-process  Tue Dec  8 10:57:09 1998
From: Alistair Adams <aadams@octanttech.com>
Date: Tue Dec  8 10:57:13 PST 1998
Subject: Unresolved symbols in a loaded module

VxWorks 5.3
PowerPC

Does anyone know if there is a way to determine if there are any
unresolved symbols in a loaded module.

The documantation for loadModuleAt() states that NULL will be returned
if there are unresolved symbols.
I believe this may have been true for VxWorks 5.2 but it certainly does
not appear to be true for the version we are using.

Alistair Adams
Octant Technologies Inc.



From owner-vxwexplo-process  Tue Dec  8 11:01:03 1998
From: Kevin Bradley <kb+@andrew.cmu.edu>
Date: Tue Dec  8 11:01:06 PST 1998
Subject: GCC, Linux, VxWorks Page:  New Home

Announcing the new home of the "GCC for VxWorks under Linux" 
page, now hosted by Sparta:

    http://linux.sparta.com/VxWorks

The new page maintainer is Bruce O. Benson (benson@sparta.com);
redirect any queries to him.

I hope you will find the page useful.  As compiler technology
is always advancing (witness the successes of egcs,
http://egcs.cygnus.com) faster than "official" releases of compilers
(gcc 2.7.2, included
in the Tornado 1.0.1 release, is dated Nov. 29, 1995 on Sunsite --
http://metalab.unc.edu/pub/gnu/), enterprising software designers
will want to use the advanced features in new compilers.  Building
your own GNU cross-compiler is feasible under most UNIX systems
(and under NT as well); this page just addresses an observed lack
for VxWorks.

All queries to the old address will be pointed to the new host.


                                                    -- Kevin




From owner-vxwexplo-process  Tue Dec  8 12:54:30 1998
From: "Blake, Don" <don.blake@lmco.com>
Date: Tue Dec  8 12:54:34 PST 1998
Subject: RE: Tornado/VxWorks (DO-178B Certification)

We had a couple of conversations with Wind River about DO-178B
certification.  We discussed the possibility of WRS supplying a "kit" that
would facilitate certification of a system that used VxWorks.  So far, we
have had no feedback from WRS.  I believe that they didn't feel there was a
large enough market to justify the required investment.  Depending on the
DO-178B level desired, this could be quite an investment.

Don

Donald R. Blake
Sr. Programmer
Lockheed Martin Federal Systems
1802 State Route 17C
Owego, NY   13827-3994

	-----Original Message-----
	From:	vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov]
	Sent:	Tuesday, December 08, 1998 11:38 AM
	To:	vxworks_users@csg.lbl.gov
	Subject:	Tornado/VxWorks

	Submitted-by owner-vxwexplo-process  Tue Dec  8 08:37:57 1998
	Submitted-by: Ian.Kerr@bae.co.uk

	Hello,

	Does anyone know if any version of VxWorks has been certified to the

	      following FAA (and CAA in the UK) required standard?

	      RTCA (Requirements and Technical Concepts for Aviation)
	      DO-178B
	      "Software Considerations in Airborne Systems and Equipment 
	      Certification"

	      Some systems integrators have been unable to use it as they
may 
	      have had problems with certification. Some seem to be planning
to 
	      use it on their aircraft. Anyone?

	N.B. Can some one post this to comp.risks and relay the results back
as 
	      we do not have the technology here? Thanks in advance.

	Ian Kerr.
	


From owner-vxwexplo-process  Tue Dec  8 14:01:20 1998
From: "Pete Brett" <pete@imc4.eej.ulst.ac.uk>
Date: Tue Dec  8 14:01:24 PST 1998
Subject: Re: Unresolved symbols in a loaded module

>
>Does anyone know if there is a way to determine if there are any
>unresolved symbols in a loaded module.
>


How are you loading the module? When I execute ld < {module_name} from the
host or target resident shell, any unresolved symbol names are printed out.
When I use the debugger to load the module, a message box appears in Tornado
showing me the names of any unresolved symbols.

I am using Tornado 1.0.1 for an x86 target.

If you are using loadModuleAt() from your code, it should be fairly easy to
generate an object file with a symbol which is not present in the target and
use the debugger to check the returned value. You could also try printErrno
from the shell, perror or logMsg("<place your string here %s",
(int)strerror(errnoGet()),0,0,0,0,0); in your code after the call to
loadModule.

Hope this helps,
        Pete



From owner-vxwexplo-process  Tue Dec  8 14:07:47 1998
From: "Michael Baumann" <baumann@proton.llumc.edu>
Date: Tue Dec  8 14:07:50 PST 1998
Subject: Throw/Catch


We have a developer here that has decided that using the Throw/Catch
exception handling of C++ would be a good thing.
Mental judgements aside, we have attempted this with the bundled
G++ that comes with Tornado, and have run into a sticky wicket -
to wit: Using the -fhandle_exceptions introduces a number of undefined
symbols, that appear to deal with setting up and dealing with
the jumps needed to do exception processing.
Is there some trick I am not aware of, or am I SOL?
Target system is 68K (MVME 167)

--
Michael Baumann  Optivus Technology Inc.|Loma Linda University Medical
Center
San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu




From owner-vxwexplo-process  Tue Dec  8 15:03:01 1998
From: Andreas Wolf <ahw@mps.OHIO-STATE.EDU>
Date: Tue Dec  8 15:03:05 PST 1998
Subject: RE: Throw/Catch

Hi,

 > Submitted-by: "Michael Baumann" <baumann@proton.llumc.edu>
 > 
 > We have a developer here that has decided that using the Throw/Catch
 > exception handling of C++ would be a good thing.
 > Mental judgements aside, we have attempted this with the bundled
 > G++ that comes with Tornado, and have run into a sticky wicket -
 > to wit: Using the -fhandle_exceptions introduces a number of undefined
 > symbols, that appear to deal with setting up and dealing with
 > the jumps needed to do exception processing.
 > Is there some trick I am not aware of, or am I SOL?
 > Target system is 68K (MVME 167)
 > 

	The GNU C++ compiler coming with Tornado (Ver 2.7.2)
	is *not* capable of generating reentrant exeception code!
	I would not use it!!!
	However, if you like adventures you can still try it... ;-)

	Then you need to switch on not only -fhandle_exceptions
	but also -frtti, which gives you the needed runtime type info
	to catch the correct classes in your code.
	Problem is, that you must compile *all* C++ code with
	that options, since it changes the basic class layout
	adding virtual methods/classes.
	As you might guess, this is impossible if you use
	'iostream' classes, since you do not have the source code!!

	Conclusion: Give up on exceptions!

	I use this opportunity to urge WRS to come up with a
	better compiler! (Instead of just another (better?) Tornado
	version ;-)
	I saw some code in egcs-1.1b that might make all these
	headaches go away...

	Does anybody care at WRS? Are C++ programmer's that rare,
	still?

		Andreas =:-)


From owner-vxwexplo-process  Tue Dec  8 22:58:28 1998
From: Yves LEDUC <yleduc@oceanet.fr>
Date: Tue Dec  8 22:58:32 PST 1998
Subject: ASM 68k on Tornado-VxWorks / NT4.0

I am  a old programmer on 68k, but I am beginner on Tornado VxWorks.
Do you have some informations and examples od ASM 68k programs,
particulary  for interrupt and use with Tornado-gdb.
Thanks in advance 
Yves
-----------------
Yves LEDUC
Indsutrial computing teacher
LPT de la  SALLE
NANTES
FRANCE
-----------------
yleduc@oceanet.fr
---------------------


From owner-vxwexplo-process  Wed Dec  9 00:46:28 1998
From: stevens <stevens@ims.fhg.de>
Date: Wed Dec  9 00:46:32 PST 1998
Subject: Thanks: CORBA for VxWorks

Hi VxWorkers !

Thank you for all the answers to the CORBA for VxWorks-questions.

To our solution:
We will use Visibrokers CORBA-ORB, because it is the only one which has
an IIOP-engine for CPU32. ORBIX has no IIOP-Engine implemented yet. TAO
is a very interesting and a very cheap solution, but there is no support
and compiling TAO for Motorola's 68332 is not possible without a lot of
changes to the sources.
Visibroker's CORBA-ORB uses only 1.5 megs of RAM at runtime with the
operation system build in.
If somebody know a better solution. Please let me know.

CU in the VxWorks-exploder,
Torsten Stevens

--

**************************************************************************

fraunhofer institute of microelectronic circuits and systems
department sat
name       torsten stevens           mailto:stevens@ims.fhg.de
address    finkenstrasse 61          phone      +0049/203/3783-238
           47057 duisburg            fax        +0049/203/3783-266
           germany
           http://www.fhg.de/depts/ims-du-e.html
**************************************************************************





From owner-vxwexplo-process  Wed Dec  9 01:55:18 1998
From: Martin Schrape <MSchrape@atomika.com>
Date: Wed Dec  9 01:55:49 PST 1998
Subject: Re: Throw/Catch

Hi Michael,
I already write my code with C++ exception handling, waiting
for Tornado II that will be available in spring.

-Martin
---------------------------------------------------------------
Dipl.-Phys. Martin Schrape                  schrape@atomika.com
Senior Software Engineer                 Tel. +49 89 315 891 34
Atomika Instruments GmbH                  Fax +49 89 315 59  21
Bruckmannring 40                         http://www.atomika.com  
85764 Oberschleissheim/Munich, Germany   
---------------------------------------------------------------

At 14:07 12/8/98 -0800, you wrote:
>Submitted-by owner-vxwexplo-process  Tue Dec  8 14:07:47 1998
>Submitted-by: "Michael Baumann" <baumann@proton.llumc.edu>
>
>
>We have a developer here that has decided that using the Throw/Catch
>exception handling of C++ would be a good thing.
>Mental judgements aside, we have attempted this with the bundled
>G++ that comes with Tornado, and have run into a sticky wicket -
>to wit: Using the -fhandle_exceptions introduces a number of undefined
>symbols, that appear to deal with setting up and dealing with
>the jumps needed to do exception processing.
>Is there some trick I am not aware of, or am I SOL?
>Target system is 68K (MVME 167)
>
>--
>Michael Baumann  Optivus Technology Inc.|Loma Linda University Medical
>Center
>San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu



From owner-vxwexplo-process  Wed Dec  9 20:24:45 1998
From: Garry Kraemer <gkraemer@netzone.com>
Date: Wed Dec  9 20:24:49 PST 1998
Subject: MVME2604 Printer Driver

vxWorks users,

I'm looking for a printer driver for the MVME2604.

Can anyone provide assistance in getting the printer port attached to vxWorks?

Thanks in advance.

Garry Kraemer, Raytheon Systems (602) 935-2214


From owner-vxwexplo-process  Thu Dec 10 07:09:40 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Thu Dec 10 07:09:43 PST 1998
Subject: WTX Timeout

VxWorks 5.3.1
MVME2700 1.1/4

Can anyone tell me _exactly_ what it means when you get a WTX timeout in
WindSh?  I know that a WTX timeout may occur if you are attempting to load a
large load module with symbol synchronization enabled, but I corrected for
that by using symSyncTimeoutSet() to increase the timeout to something
sufficiently large.

My recent WTX timeout errors don't appear to be correlated to anything in
particular, so I really don't know where they are coming from.  I can leave
my WindSh up with nothing special running on the target and still get them. 
Any ideas?  I'd appreciate any feedback.  Thanks.

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com


From owner-vxwexplo-process  Thu Dec 10 08:12:59 1998
From: Piero Giorgio Degiorgis <degiorgis@to.infn.it>
Date: Thu Dec 10 08:13:02 PST 1998
Subject: kbhit() function


Hello All,

In my application, I need to test if a character on the keyboard has been
typed (to exit from a loop that runs forever on a well defined line of
code). The getchar() function is suspensive, it blocks the software
every cycle so this way does not work. 
If I have to use the Microsoft C++ environment, I could use the primitive
kbhit(). Does somebody know a similar way with vxWorks?

Thanks in advance,

- Piero Giorgio DEGIORGIS,                                              
- Universita' degli Studi di TORINO (ITALY)    
- sperimental physics department and INFN,     
- Via Pietro GIURIA 1, 10125, TORINO (ITALY)    
- 0039 11 6707332, E-mail: degiorgis@to.infn.it  




From owner-vxwexplo-process  Thu Dec 10 13:39:33 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Thu Dec 10 13:39:37 PST 1998
Subject: kbhit() function -Reply

Piero,

If the keyboard on your system is treated as a terminal input, you can use
ioctl() calls to allow immediate processing of all inputs and to determine
when inputs have been provided.  See the description of tyLib in the VxWorks
Reference Manual for details.

Following is a piece of code I wrote to wait up to a certain amount of time
for the user to press a key on the console keyboard during booting:

/*
TSS	Set the console for normal terminal operation, except allow immediate
TSS	processing of all inputs.  This operation also causes all waiting
TSS	inputs to be flushed, reducing the chance that a stray input will be
TSS	interpreted as an intentional break request.  
*/
	ioctl(consoleFd,FIOSETOPTIONS,OPT_TERMINAL^OPT_LINE);

/*
TSS	Calculate the tick at which to continue booting, and wait until the
TSS	timeout period has expired or a key is pressed.
*/
	continueTick = tickGet() + (timeout * sysClkRateGet());
	do
	    ioctl(consoleFd,FIONREAD,(int)&bytesWaiting);
	while ((tickGet() < continueTick) && (bytesWaiting == 0));

/*
TSS	Return the console to normal terminal operation.  This operation also
TSS	causes all waiting inputs to be flushed.
*/
	ioctl(consoleFd,FIOSETOPTIONS,OPT_TERMINAL);

/*
TSS	If a key was pressed...
*/
	if (bytesWaiting)
     {
		.
		.
		.

HTH

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com


>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/10/98 10:13am >>>
Submitted-by owner-vxwexplo-process  Thu Dec 10 08:12:59 1998
Submitted-by: Piero Giorgio Degiorgis <degiorgis@to.infn.it>


Hello All,

In my application, I need to test if a character on the keyboard has been
typed (to exit from a loop that runs forever on a well defined line of
code). The getchar() function is suspensive, it blocks the software
every cycle so this way does not work. 
If I have to use the Microsoft C++ environment, I could use the primitive
kbhit(). Does somebody know a similar way with vxWorks?

Thanks in advance,

- Piero Giorgio DEGIORGIS,                                              
- Universita' degli Studi di TORINO (ITALY)    
- sperimental physics department and INFN,     
- Via Pietro GIURIA 1, 10125, TORINO (ITALY)    
- 0039 11 6707332, E-mail: degiorgis@to.infn.it  



From owner-vxwexplo-process  Fri Dec 11 01:35:41 1998
From: Harald Grundner <harald.grundner@ri.dasa.de>
Date: Fri Dec 11 01:35:45 PST 1998
Subject: Re: kbhit() function

>Submitted-by owner-vxwexplo-process  Thu Dec 10 08:12:59 1998
>Submitted-by: Piero Giorgio Degiorgis <degiorgis@to.infn.it>
>
>
>Hello All,
>
>In my application, I need to test if a character on the keyboard has been
>typed (to exit from a loop that runs forever on a well defined line of
>code). The getchar() function is suspensive, it blocks the software
>every cycle so this way does not work. 
>If I have to use the Microsoft C++ environment, I could use the primitive
>kbhit(). Does somebody know a similar way with vxWorks?


Hi Piero,

here's some code that should do the trick.

    Harald


#include <stdio.h>     /* printf() */
#include <tyLib.h>     /* FIOSETOPTIONS */
#include <assert.h>    /* assert() */
#include <taskLib.h>   /* taskDelay() */
#include <sysLib.h>    /* sysClkRateGet() */

static int keyhit(void);

void test(void)
  {
  char key;
  int testCount = 0;
  int options;


  /* Save options */
  options = ioctl (0, FIOGETOPTIONS, 0);

  /* Enter raw mode */
  ioctl (0, FIOSETOPTIONS, OPT_TERMINAL & ~OPT_LINE & ~OPT_ECHO);

  printf("Press any key to stop\n");
  while (!(key = keyhit()))
    {
    printf("Test %d\n", testCount++);
    taskDelay (sysClkRateGet());
    } /* while !keyhit() */

  /* Leave raw mode */
  ioctl (0, FIOSETOPTIONS, options);

  printf("\nKey was %d = %.4X = %c\n", key, key, key);
  } /* test */

static int keyhit(void)
  {
  int nread;
  int rc;
  int oneChar;

  /* probe STDIN to see if operator entered any characters */
  rc = ioctl(0, FIONREAD, (int) &nread);
  assert(rc != ERROR);
  if (nread)
    {                           /* got a char */
    /* flush all the characters entered */
    for (; nread; nread--)
      oneChar = getchar();

    return oneChar;
    }
  return 0;
} /* keyhit */





From owner-vxwexplo-process  Fri Dec 11 08:27:40 1998
From: David Laight <dsl@tadpole.co.uk>
Date: Fri Dec 11 08:27:43 PST 1998
Subject: Re: kbhit() function


> >Hello All,
> >
> >In my application, I need to test if a character on the keyboard has been
> >typed (to exit from a loop that runs forever on a well defined line of
> >code). The getchar() function is suspensive, it blocks the software
> >every cycle so this way does not work. 
> >If I have to use the Microsoft C++ environment, I could use the primitive
> >kbhit(). Does somebody know a similar way with vxWorks?
> 
> 
> Hi Piero,
> 
> here's some code that should do the trick.
> 
>     Harald
> 
 
>   /* probe STDIN to see if operator entered any characters */
>   rc = ioctl(0, FIONREAD, (int) &nread);

It ought to be possible to use poll() here instead of the FIONREAD ioctl.
I also remember a reference to setting 'NONBLOCK' mode.

Which is best probably depends on the structure of your app.

	David


----------------------------------------------------------------
David Laight                          email: dsl@tadpole.co.uk
Tadpole Technology plc                phone: +44 1223 278 256
Cambridge, UK                         fax:   +44 1223 278 201



From owner-vxwexplo-process  Fri Dec 11 10:22:37 1998
From: Lori Fraleigh <lori@rti.com>
Date: Fri Dec 11 10:22:41 PST 1998
Subject: Re: VxWorks Hung Telnet Session


Tim -

What BSP are you using?  I've seen this problem with the ebsa285 BSP
(ARM SA110) for VxWorks 5.3.1 and have filed TSR 11538.  The ebsa285 BSP
included the SENS stack by default so this bug may or may not also exist 
on other BSPs if you have SENS installed.  I don't know.

The problem is due to inefficient use of network buffers (M_BLKs and 
clusters).  The printf blocks on a semaphore trying to get a network buffer 
to send the data out over the socket. There is a workaround while you wait 
for a fix.  In target/h/netBufLib.h, change:

#define NUM_NET_MBLKS                 400     /* no. mBlks to initialize */

to

#define NUM_NET_MBLKS               20000    /* no. mBlks to initialize */

or some other number large enough to make your problems go away.

WRS just released a SENS 1.1 update.  If the bug existed on other
platforms, it may be fixed in the update. It does not cover the ARM 
platform though.  I'm waiting to hear when a fix for ARM will be 
released. The problem has already been acknowledged and fixed in 
Tornado 2 / VxWorks 5.4.  

Regards,
Lori
-- 
Lori Fraleigh       Real-Time Innovations        http://www.rti.com
lori@rti.com        408-720-8312 ext. 121         Fax: 408-734-5009


Tim Sohacki wrote:
> 
> Can anyone provide any insight into the following problem?
> Thanks for your help.
> 
> Cheers,
> Tim
> 
> > I'm running into some trouble with the Target Shell's IO
> > when I have multiple tasks printing to the STDOUT device.
> > I have narrowed the scenario down to something very simple:
> >
> > 1. Telnet into a target:
> >
> >     % telnet 47.192.0.165
> >     Trying...
> >     Connected to 47.192.0.165.
> >     Escape character is '^]'.
> >     Local flow control off
> >
> >     ->
> >
> >  2.  Type the following command:
> >
> >     -> sp i
> >     task spawned: id = 0x1b71238, name = t7
> >     value = 28774968 = 0x1b71238
> >
> > And that's all you need.  The Telnet session (target shell)
> > is now hung.  No I/O is possible until the target is rebooted.
> > It's possible, although I cannot confirm, that both STDIN and
> > STDOUT are PENDED waiting to take some semaphore.
> >
> >
> 
> --
> Tim Sohacki, Nortel Networks
> email: sohacki@nortelnetworks.com


From owner-vxwexplo-process  Tue Dec 15 09:09:37 1998
From: ksamavedam@hns.com (Krishna Samavedam)
Date: Tue Dec 15 09:09:40 PST 1998
Subject: VxWorks max FTp sessions


HI,
	I d like to know how to configure the vxWorks FTP server
	with regard to max number of sessions it can support simultaniously.
	
	If there is no such support, how can I control the number of
	sessions with the default configuration.

thanx in advance
krishna


From owner-vxwexplo-process  Tue Dec 15 12:01:22 1998
From: "Victor Wu" <vwu@telogy.com>
Date: Tue Dec 15 12:01:27 PST 1998
Subject: Help://Motorola MC68360 SCC UART serial driver


vxWorks Tornado

Hi, all,

We need to set the serial speed as 115200, but only 38400 is achieved.

I checked MC68360 serial driver file m68360Sio.c, there is  a line :
if (arg >=  50 && arg <= 38400)
{
	...
}

After I modified to:
if (arg >=  50 && arg <= 115200)

The speed 57600 is achieved. But 115200 is still failed.

Have someone done the similar things ? Do I need to modify the driver
register setting  in order to achieve 115200 speed ?

Thanks.

Victor Wu
MTS
Telogy Networks Inc.
(301)515-6624
vwu@telogy.com





From owner-vxwexplo-process  Tue Dec 15 14:10:32 1998
From: Cecil Mathews <cecil.mathews@dlcc.com>
Date: Tue Dec 15 14:10:36 PST 1998
Subject: Re:VxWorks Max Ftp Sessions

There is a compile time definition in ftpdlib.h

ftpdMaxClients = 4.

You can change that





From owner-vxwexplo-process  Wed Dec 16 04:00:22 1998
From: daemon@csg.lbl.gov
Date: Wed Dec 16 04:00:26 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Wed Dec 16 04:00:13 PST 1998

        Subject: Re: PowerPc assembler & system tick accuracy
        Subject: Problem in booting VxWorks
        Subject: Tornado II
        Subject: Re: Strange behaviour with global variable : have you seen it before?
        Subject: Is this Veritas NG
        Subject: Re: VxWorks max FTp sessions
        Subject: netBufLib question
        Subject: Question on SENS drivers
        Subject: Sporadic interrupts from Industry Pack - vw5.2 - MVME162
        Subject: Dec Ethernet Driver?
        Subject: Re: DMA on MVME2600
        Subject: Re: Build Output Requires Prompting? (Update)
        Subject: PCI ATM NIC
        Subject: Re: Dec Ethernet Driver?

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

Newsgroups: comp.arch.embedded,comp.sys.powerpc.tech,comp.sys.powerpc,comp.os.vxworks
Subject: Re: PowerPc assembler & system tick accuracy
Date: 15 Dec 1998 13:23:47 GMT
From: laire@basis.owl.de (Ralph Schmidt)
Organization: Privates Internet Ost-Westfalen-Lippe
Message-ID: <755nt3$ji7$1@pri.owl.de>
References: <36760043.5D1F4E4E@ecitele.com>

On 12/15/98, Yosi Yarchi wrote:
>Hello all
>
>The following is source copied from vxWorks system timer interrupt
>routine, which is based on the decrementer function of the PowerPc 
(in
>this case: MPC860). I'm looking for some explanation about the syntax 
in
>this code: (1) what is the %0 (implemented by the compiler as r9
>register). (2) what means the colon character (appears at the 
begining

seperates the 
1) output
2) input
3) trashed memory/register

definition of a gcc inline asm function.


>of the last 3 lines). (3) what means of the "r", "3", and "cc" 
commands
>which have special inverted commas (" ")? as I could see, these lines
>have no effect on the code generated by the compiler. (4) can someone
>explain me the trick of compensation of the interrupt latency which 
is
>implemented here in the loop(it required because the decrementer is 
not
>auto reloaded)?
>
>Thank you
>Yosi
>
>
>
>
>
>__asm__ ("
>    mfdec       3
>sysClkIntLoop:
>    add.        3, %0, 3
>    ble         sysClkIntLoop           /* check if we missed tick(s) 
*/
>
>    mtdec       3"
>    :                                   /* no output operands  */

Here you define the output register of an (inline) assembler function

>    : "r" (decCountVal)                 /* input operand, %0 =
>decCountVal */

%0 is a integer "register" defined by the compiler which
is loaded with  the value decCountVal.
You could also create more arguments and the compiler would
use the right registers.

>    : "3", "cc"/* side-effects: r3 clobbered, 'condition code' is

"3"== register 3
"cc" == condition code which are changed by the "add."

>clobbered */
>    );
>

defines the registers which are trashed by this operation.

All that is explained in the gcc docs.


- -- 
Ralph Schmidt,laire@popmail.owl.de(private),NextMail welcome

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

Newsgroups: comp.os.vxworks
Subject: Problem in booting VxWorks
Date: 15 Dec 1998 15:30:24 GMT
From: chandraj@nortel.ca (Chandan Rajah)
Organization: Bell Northern Research
Message-ID: <755vag$7s2@bmdhh222.europe.nortel.com>

Hi,

I am working with the vxwork on the VME architechture on a SunSprac card.
 The problem I'm facing is that when i boot the card with VxWorks,
 i get the VxWorks banner and then i get the following message...

Cannot regiister service: RPC: Timed out
rdbTask: couldn't open RDB service
Unable to open startup script

- -> i
undefined symbol 'i'

But coincidently the other card seems to be working perfectly.
 It is not a NFS problem as the same card had been working for
 sometime in the past with the same configuration.

The other problem is that when I try to do an 
ldf ("/bnr/rchtools/automation/ttf/vme/bootnet/bootrom_uncmp",0,0x100,1)

It returns an error message 'Program to big for flash memory'
 but again the same thing is working for the other card.

Crisis situation, kindly advise
- --- Chandan !!! E-Mail: chandraj@wipsys.soft.net

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

Newsgroups: comp.os.vxworks
Subject: Tornado II
Date: Tue, 15 Dec 1998 10:57:47 -0800
From: Edward LaPier <edward.lapier@lmco.com>
Organization: Lockheed Martin Federal Systems, Owego, NY
Message-ID: <3676B12B.8BE52903@lmco.com>

VxWorks Greetings!

    I am trying to get some information on Tornado II.  If anyone out
there in VxWorks Land has been using the BETA version and has
information about PROS/CONS it would be greatly appreciated.


                    Thanks in advance!

                    Ed

- --
- -------------------------------------------------------------------
Edward LaPier - <edward.lapier@lmco.com>
Lockheed Martin Federal Systems
1801 State Route 17C  Mail Drop 0302
Owego, NY 13827-3994
Voice: (607) 751-4296
- -------------------------------------------------------------------



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

Newsgroups: comp.os.vxworks
Subject: Re: Strange behaviour with global variable : have you seen it before?
Date: Tue, 15 Dec 1998 07:56:12 -0800
From: "Joseph R Hansen" <hansen@cel.chinalake.navy.mil>
Organization: NAWCWPNS
Message-ID: <75615e$3f11@news.nawcwpns.navy.mil>
References: <7543t6$p8p$1@nnrp1.dejanews.com> <754t9l$ejc$1@nnrp1.dejanews.com>

Mittal,

My "solution" is a bit different from John's.  It has been my experience
with VxWorks that a task will continue to run until it gives the shell a
reason to check on other tasks' status (poor wording, but a task will run
until it comes to a taskDelay, semTake, or some other basic function that
interrupts its flow of control).

Your task "TaskInit" never prints because it never runs.  It never runs
because the shell never interrupts "RxFunc" from running.  I _believe_ that
if you use printf instead of logMsg, it will work.  I seem to remember that
there is a taskDelay in the printf function, but not in logMsg (I could be
wrong here; corrections from the group gladly accepted).

I don't know if this will give you what you need, but as I said, this has
been my experience.  Good luck.  Oh, and I do agree with John that you
should make Count volatile (especially if accessed from two different object
files).

Joseph Hansen
NAWCWPNS China Lake
Code 471500D
China Lake, CA  93555
hansen@cel.chinalake.navy.mil
(760) 939-6999



john@kivala.com wrote in message <754t9l$ejc$1@nnrp1.dejanews.com>...
>In article <7543t6$p8p$1@nnrp1.dejanews.com>,
>  newsmine@my-dejanews.com wrote:
>> Hi VxGurus,
>>
>> While doing some simple timer-driven code on VxWorks, I saw the following
>> strange behaviour. Here's what I have : Tornado on Nt 4.0, VxWorks 5.3.1,
>> gcc 2.7.2 and a PPC860 board. My compilation flags are
>...edit
>> int Count;
>...
>
>My guess is that "int Count" wants to be "volatile int Count".
>The compiler might be sticking it in a register and never
>re-getting it from memory, unless you have a "sufficiently
>complicated" line of code between uses of Count (case 3).
>
>This is not too hard to check:
>objdumpppc --disassemble file.o > file.lst
>(A reading knowledge of any given assembly language is far
>easier than a writing knowledge thereof.)
>
>If this is what's happening, and maybe even if it's not, the
>lesson is that if you have any variables shared by more than
>one task (or isr), then they should be volatile, since you
>don't (in general) know when task A is going to switch out
>and task B is going to switch in. This is a different kind
>of protection than that achieved by intLock, taskLock, or
>a semaphore.
>
>John
>
>--------------------------------------------------
> John Finley                 Kivala Systems, Inc.
> Project Manager                   (619) 689-0032
> john@kivala.com            http://www.kivala.com
>--------------------------------------------------
> VxTool - Build Tornado Apps with MS Visual Basic
>--------------------------------------------------
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



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

Newsgroups: comp.os.vxworks
Subject: Is this Veritas NG
Date: Sat, 12 Dec 1998 11:09:56 -0800
From: "Dave41" <dlimato@nospampacbell.net>
Organization: SBC Internet Services
Message-ID: <rGFc2.3740$RM4.37637@typhoon-sf.snfc21.pbi.net>

Is this a VXFS type ng. If so I'd like to pose questions. If not does anyone
know of a ng that discusses VXFS?

Dave



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

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks max FTp sessions
Date: Tue, 15 Dec 1998 13:56:48 -0500
From: Douglas Fraser <dwfraser@lucent.com>
Organization: Lucent Technologies
Message-ID: <3676B0F0.F88E04C1@lucent.com>
References: <981215120856.ZM1775@dcn49.hns.com>

Krishna Samavedam wrote:
> 
> HI,
>         I d like to know how to configure the vxWorks FTP server
>         with regard to max number of sessions it can support simultaniously.
> 
>         If there is no such support, how can I control the number of
>         sessions with the default configuration.
> 

Check the programmers reference manual for tftpdInit.
The last arg is the max number of connections.

- -- 
Doug Fraser
dwfraser@lucent.com

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

Newsgroups: comp.os.vxworks,cisco.eng.cr.su-dev-vxworks
Subject: netBufLib question
Date: Tue, 15 Dec 1998 11:31:16 -0800
From: "Sohail M. Parekh" <sparekh@cisco.com>
Organization: Cisco Systems
Message-ID: <3676B904.F715282D@cisco.com>
Reply-To: sparekh@cisco.com

Hello,

I cannot seem to find a netBufLib routine that helps connect two (or
more) mblks to form a chain. If someone could point me in the right
direction.

Regards,

Sohail

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

Newsgroups: comp.os.vxworks
Subject: Question on SENS drivers
Date: Tue, 15 Dec 1998 11:59:16 -0800
From: "Sohail M. Parekh" <@cisco.com>
Organization: Cisco Systems
Message-ID: <3676BF94.A1B06812@cisco.com>
Reply-To: @cisco.com

Hello,

Any idea if SENS END drivers TYPICALLY support scatter-Gather chains. I
am using m-blk chains which I would like the END driver to send as a
single block.

Regards,

Sohail

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

Newsgroups: comp.os.vxworks
Subject: Sporadic interrupts from Industry Pack - vw5.2 - MVME162
Date: Tue, 15 Dec 1998 16:36:08 -0800
From: David Morris 222-7450 <cadfael@triumf.ca>
Organization: TRIUMF
Message-ID: <36770077.E63CBB2E@triumf.ca>

Hello

  I'm getting some peculiar behaviour with an interrupt from an ADC/DAC
Industry Pack board, and am searching for any suggestions.

  Computer is MVME162 running vw5.2. Industry Pack is TEWS Datentechnik
TIP850 ADC/DAC board.

  The IP generates an interrupt on end-of-conversion. Most of the time
it works but every now and then I get a flurry of timeouts from the
semaphore.

  The GCR for the IPIC on 162 is set up as:

  *((unsigned char *) (MVME162_IPIC_ADDRESS + 0x18 + cPosition)) = 0x00;

  This means no memory access, no recovery time, no Error* signal. I
tried changing recovery time to see if that was the problem but with no
luck.

  The ICR for the IPIC on 162 is set up as:

  *((unsigned char *) (MVME162_IPIC_ADDRESS + 0x10 + cPosition * 2)) =
0x15 - cPosition;
  *((unsigned char *) (MVME162_IPIC_ADDRESS + 0x11 + cPosition * 2)) =
0x15 - cPosition;

  This means Low level ints, ints enabled, int level depends on position
on board.

  The interrupt service routine is connected to some arbitrary vector.
(There doesn't seem to be much info about what numbers to select for
vector numbers, but that's another story)

  A task runs to scan the eight ADC channels in a while loop. The format
for each channel is set up, then the command register is written to
start the collection. Then a semaphore is taken until the interrupt
occurs.

  while () /* loop through all channels */
  {
    sCmdStatus = iChannel | (iDifferential << 4) |
(tip850Board->ADC[iChannel].iGain << 5) |
                (iGainSettle << 7) | (iInterrupt << 8);

    * (tip850Board->psADC_CSR) = sCmdStatus;
    * (tip850Board->psADC_CON) = 0xff; /* dummy write to trigger ADC */

    sResult = semTake(sidTip850ADCComplete, 1); /* block until
collection done */
    sData = * (tip850Board->psADC_DAT); /* collect data */
  }

  The interrupt routine just gives the semaphore back, allowing the
collection to happen.

  void tip850IntADC()
  {
    semGive(sidTip850ADCComplete);
  }

  My error diagnostic printouts show the collection completed. I've
tried making the timeout on the semTake longer, but no luck there; the
conversion takes 10 usec, not 1/60th second. It happens on all channels
although mostly on channel 0. I've tried double triggering, a long delay
between setup and trigger, etc.etc.etc.

  Does anyone have any ideas? Thanks in advance!

- --
David B Morris                          TRIUMF
Systems Designer/Analyst                Canada's National Meson Facility
cadfael@triumf.ca                       4004 Wesbrook Mall
604-222-7450                            Vancouver, B.C. V6T 2A3

"Remember, no matter where you go, there you are." - Buckaroo Banzai




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

Newsgroups: comp.os.vxworks
Subject: Dec Ethernet Driver?
Date: Tue, 15 Dec 1998 17:23:32 -0800
From: Frankie Sierra <sierra@teralogic-inc.com>
Message-ID: <36770B93.DCE5CB9A@teralogic-inc.com>

I am looking for a Dec 21140, or 21143 Ethernet driver for use with
VxWorks 5.1.3? Anyone done this? Any issues, caviats?

Frankie Sierra
sierra@teralogic-inc.com



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

Newsgroups: comp.os.vxworks
Subject: Re: DMA on MVME2600
Date: Wed, 16 Dec 1998 13:55:22 +0900
From: "Young-Han, Kim" <yhkim@softec.co.kr>
Organization: Softec Engineering Co., Ltd.
Message-ID: <757ei3$gll$1@news.kornet.nm.kr>
References: <MVnd2.3598$o4.14087066@WReNphoon1>
Reply-To: "Young-Han, Kim" <support@softec.co.kr>

Dear Philippe,

  I don't have the experience for VME DMA transfer.
  Our company is the agent of DY4 Systems.
  Our customer wants to use the VME DMA transfer.
  So, somedays ago, I was look into the UNIVERSE manual.
  The DY4 CPU used the UNIVERSE.
  In my opinion, if know the UNIVERSE manual and the base address
of UNIVERSE, anybody can make the DMA transfer program.

  You can solve this problem as follow
  1. ask to the Motorola or the agent
  2. solve by yourself.
     In this case,
        First of all, You must know the VMEbus Interface Chip and
        the base address of VMEbus Interface Chip.
        Maybe, it is not so easy to get the base address of
        VMEbus Interface Chip. So, ask to Motorola.
        Then you must get the manual of the VMEbus Interface Chip.
        If you can refer the manual, maybe, you can make
        the program for VME DMA transfer.


Best Regards
Young-Han, Kim / R&D


Philippe Duhoux was wrote...
>Bonjour,
>does someone have experience in DMA transfers on
>MVME2600?
>In my particalar case, I shall transfer CPU data
>from/to an external VME board in A32/D32 space.
>
>Thanks for any hint.
>
>Best regards,
>Philippe
>
>================================================================
>Philippe Duhoux                         Tel: (+49)
>89-3200-6523
>Software Engineer VLT                   Fax: (+49)
>89-3200-6494
>CCD Cameras & Instrument Motors
>Karl-Schwarzschild-Str.2
>European Southern Observatory           D-85748 Munich
>- Germany
>E-Mail : pduhoux@eso.org                WWW
>http://www.eso.org
>================================================================
>
>
>
>*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here
(tm) ***

                             ?
                            '''
                           (o o)
- -----------------------oOO--(_)--Oo-----------------------
                   Young-Han, Kim / R&D
                E-mail : support@softec.co.kr

                Softec Engineering Co., Ltd.
4F, Shinil B/D, #196-1, Poi-Dong, Kangnam-Ku, Seoul, Korea
                   Tel : ++ 82 2 575 7311
                   Fax : ++ 82 2 575 7314
                Http://www.softec.co.kr
- -----------------------------------------------------------




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

Newsgroups: comp.os.vxworks
Subject: Re: Build Output Requires Prompting? (Update)
Date: Tue, 15 Dec 1998 03:44:18 GMT
From: paulvroberts@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <754lui$8je$1@nnrp1.dejanews.com>

Tim Sohacki wrote:
>
> Update ... on one machine, it appears to be an interaction with
> Norton Anti-virus.  On the other, it's something else, though
> we don't know what yet.
>
> Cheers,
> Tim
>

Thanks to you and Philip Gaglia for giving me the idea that it was the virus
checker.

I have verified this to be the case on the Win 95 machines that had problems.
We are running McAfee VShield 3.2.0, and if you disable it, Tornado make
windows then work fine.

Oh the joy of developing under Windows...

Paul Roberts.

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: PCI ATM NIC
Date: Wed, 16 Dec 1998 11:22:21 +0200
From: "Udi Nir" <udi_nir@ncc.co.il>
Organization: NetVision Israel	
Message-ID: <757u7f$7eq$1@news.netvision.net.il>

I am looking for a commercial PCI ATM NIC (e.g. OC3) that has drivers for
VxWorks.
The only requirements are to be able to set up a connection and send/receive
AAL5 PDUs (no need for IP etc.)

Thanks in advance,
Udi




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

Newsgroups: comp.os.vxworks
Subject: Re: Dec Ethernet Driver?
Date: Wed, 16 Dec 1998 05:40:00 -0500
From: Dan DeVault <devault@ibm.net>
Organization: IBM.NET
Message-ID: <36778DFF.D92F63F2@ibm.net>
References: <36770B93.DCE5CB9A@teralogic-inc.com>

Wind River has a driver that works with the SENS stack.  At least for
the Motorola MTX604 BSP.  We are trouble shooting some problems with it
now.

Dan DeVault
IBM Global Network
devault@ibm.net

Frankie Sierra wrote:

> I am looking for a Dec 21140, or 21143 Ethernet driver for use with
> VxWorks 5.1.3? Anyone done this? Any issues, caviats?
>
> Frankie Sierra
> sierra@teralogic-inc.com


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

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


From owner-vxwexplo-process  Wed Dec 16 07:51:39 1998
From: tpbiele@sandia.gov
Date: Wed Dec 16 07:51:42 PST 1998
Subject: Problems with the floor() function on MV2604

Fellow vxworks users,

I believe I have discovered two double floating point numbers that the floor() function on 
an MV2604 board does work correctly on.  The code snippet that I used and the output that I got are shown
below.  I would appreciate any feedback.

******************************** Begin Function ******************************************

#include "vxworks.h"
#include "math.h"
#include "stdio.h"

void floorchk(void)
{
  double temp;
  double temp1;
  long *pLong;

  temp = -1327828.87015908;
  pLong = (long *)&temp;

  /* change the LSW slightly */
  pLong[1] = 0xdec2beca;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);


  /* change the LSW slightly */
  pLong[1] = 0xdec2becb;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);


  /* change the LSW slightly */
  pLong[1] = 0xdec2becc;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);


  /* change the LSW slightly */
  pLong[1] = 0xdec2becd;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);



  /* change the LSW slightly */
  pLong[1] = 0xdec2bece;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);
}

******************************** End Function ******************************************



******************************** Begin Output ******************************************

pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECA
floor(-1327828.870159) = -1327829.000000


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECB
floor(-1327828.870159) = -1327829.000000


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECC
floor(-1327828.870159) = -1327828.870159


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECD
floor(-1327828.870159) = -1327828.870159


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECE
floor(-1327828.870159) = -1327829.000000

******************************** End Output ******************************************

--------------------------------------------------------
E-mail: tpbiele@sandia.gov
Date: 12/16/1998
Time: 08:39:31

This message was sent by Z-Mail Pro - from NetManage
NetManage - delivers Standards Based IntraNet Solutions
--------------------------------------------------------



From owner-vxwexplo-process  Wed Dec 16 10:56:55 1998
From: "Minbo Shim" <mshim@rst.com>
Date: Wed Dec 16 10:56:59 PST 1998
Subject: VwWorks: A16 VME for PowerPC (MVME2700)

Vxworks gurus:

I have some difficulties to get access to a register in the A16-based
I/O board. 

Here is the story. We have an A16-based VMEbus I/O board with short
addressing map that tells us where to go to see the contents of some
registers in it. Suppose the local address to one of the registers is
0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that 
VME MASTER WINDOW for A16 SPACE is following:

	/*
	 * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks
	 * This maps: MPU RANGE:     0xfbff0000 - 0xfbffffff
	 *        to: PCI RANGE:     0xfbff0000 - 0xfbffffff
	 *        to: VME RANGE:     0xfbff0000 - 0xfbffffff
	 */
	#  define VME_A16_MSTR_LOCAL    0xfbff0000
	#  define VME_A16_MSTR_SIZE     0x00010000 /* 64K */
	#  define VAL_LSI3_BS_VALUE     (VME_A16_MSTR_LOCAL)
	
I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value:

	{
	(void *) VME_A16_MSTR_LOCAL,
	(void *) VME_A16_MSTR_LOCAL,
	VME_A16_MSTR_SIZE,
	VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
	VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
	},

However, every try to get access to "0xfbff6005" has been failed in the sense
that the contents are NOT what we expect.

Does anybody know what I am missing?

Your help would be greatly appreciated.


-------------------------
MINBO SHIM; mshim@rst.com
Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
ROBOTIC SYSTEMS TECHNOLOGY
1234 Tech Court, Westminster, MD 21157 



From owner-vxwexplo-process  Wed Dec 16 11:35:06 1998
From: Alan K Biocca <akbiocca@swrlnx.als.lbl.gov>
Date: Wed Dec 16 11:35:09 PST 1998
Subject: filtered article viewing


I have just setup a web-accessible viewing area for rejected articles.
If you are concerned that a posting did not come through the
exploder check there after 20 minutes or so and see if your article
was filtered out. The filename contains an error message that
should help you know which filter was triggered.

http://csg.lbl.gov/vx_explo.html

I fixed a bug yesterday that prevented the digests from the newsgroup
from being emailed. They were reaching the archive but were being
rejected by sendmail. This should be fixed now, we will be watching
it the next few days.

Alan K Biocca
VxWorks Exploder Program Author



From owner-vxwexplo-process  Wed Dec 16 11:54:53 1998
From: "Minbo Shim" <mshim@rst.com>
Date: Wed Dec 16 11:54:57 PST 1998
Subject: VxWorks: shared memory network for PowerPC (MVME2700)

Vxworks gurus:

I am trying to make a SM network with the proxy arp for the powerpc
boards (mvme2700). As described in the Programmer's manual, I included the
following in the "configAll.h":

	#define INCLUDE_PING
	#define INCLUDE_SM_NET
	#define INCLUDE_PROXY_SERVER
	#define INCLUDE_SM_SEQ_ADDR
	#define INCLUDE_PROXY_DEFAULT_ADDR

And for the master:

	#define PROXY_ARP_MASTER
	#define SM_OFF_BOARD FALSE

and for the slave:

	#define PROXY_ARP_SLAVE
	#define SM_OFF_BOARD TRUE

By doing so, I want slaves to use the memory on the master starting at
0x01000000 (16MB) with the size of 1MB. Here is the configuation (config.h)

	#define SM_ANCHOR_OFFSET 0x4100  /* default for PowerPC */
	#define SM_ANCHOR_ADRS  ((sysProcNumGet() == 0) ? \
       	 ((char*) (LOCAL_MEM_LOCAL_ADRS + SM_ANCHOR_OFFSET)) : \
	        ((char*) (VME_A32_MSTR_LOCAL + SM_ANCHOR_OFFSET)))
	#define SM_MEM_ADRS      0x01000000  
	#define SM_MEM_SIZE      0x00100000
	#define SM_OBJ_MEM_ADRS  (SM_MEM_ADRS+SM_MEM_SIZE)
	#define SM_OBJ_MEM_SIZE  0x00100000 

After rebuilding vxWorks images, the master seems happy by attaching net
work interface sm0 to the anchor point (0x4100). I verify that the heartbeat 
on the master is alive by looking at the 5th 4-byte word. In order to get the
VMEbus (A32) address, I used "sysLocalToBusAdrs(0x0d,0x4100,&adrs)" which
returns 0x8004100. I used this address as the share memory anchor address
for all slaves (sm=0x8004100). However slaves are complaining that the address
is not corretly mapped somehow. Clients keep saying the following without
granting the vxworks prompt:

	Backplane anchor at 0x8004100... Attaching network interface sm0... done.
	smIsAlive:  readyValue = 0xffffffff, heartbeat = 0x0

Does anybody know what I did wrong in setting up the shared memory network with
the proxy arp?

Your help would be greatly appreciated.

Regards,

-----------------
MINBO SHIM; mshim@rst.com
Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
ROBOTIC SYSTEMS TECHNOLOGY
1234 Tech Court, Westminster, MD 21157 


From owner-vxwexplo-process  Wed Dec 16 12:21:38 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Wed Dec 16 12:21:42 PST 1998
Subject: VwWorks: A16 VME for PowerPC (MVME2700) -Reply

Minbo,

The addressing looks fine.  How are you doing your accesses?  The 6005
address suggests that you are addressing by byte.  If so, your code should
be doing something equivalent to:

    someCharVar = *(char *)0xfbff6005;

(though hopefully more elegantly).  In particular, the d() funciton is
probably not useful, because it reads from memory 32 bits at a time.  If
your board does not respond to D32 bus cycles, you get bus errors and
useless data.

HTH

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com

>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/16/98 12:57pm >>>
Submitted-by owner-vxwexplo-process  Wed Dec 16 10:56:55 1998
Submitted-by: "Minbo Shim" <mshim@rst.com>

Vxworks gurus:

I have some difficulties to get access to a register in the A16-based
I/O board. 

Here is the story. We have an A16-based VMEbus I/O board with short
addressing map that tells us where to go to see the contents of some
registers in it. Suppose the local address to one of the registers is
0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that 
VME MASTER WINDOW for A16 SPACE is following:

	/*
	 * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks
	 * This maps: MPU RANGE:     0xfbff0000 - 0xfbffffff
	 *        to: PCI RANGE:     0xfbff0000 - 0xfbffffff
	 *        to: VME RANGE:     0xfbff0000 - 0xfbffffff
	 */
	#  define VME_A16_MSTR_LOCAL    0xfbff0000
	#  define VME_A16_MSTR_SIZE     0x00010000 /* 64K */
	#  define VAL_LSI3_BS_VALUE     (VME_A16_MSTR_LOCAL)
	
I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value:

	{
	(void *) VME_A16_MSTR_LOCAL,
	(void *) VME_A16_MSTR_LOCAL,
	VME_A16_MSTR_SIZE,
	VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
	VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
	},

However, every try to get access to "0xfbff6005" has been failed in the
sense
that the contents are NOT what we expect.

Does anybody know what I am missing?

Your help would be greatly appreciated.


-------------------------
MINBO SHIM; mshim@rst.com
Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
ROBOTIC SYSTEMS TECHNOLOGY
1234 Tech Court, Westminster, MD 21157 



From owner-vxwexplo-process  Wed Dec 16 12:24:44 1998
From: Tom Antles <antles@spk.hp.com>
Date: Wed Dec 16 12:24:47 PST 1998
Subject: Re: Problems with the floor() function on MV2604

vxwexplo@lbl.gov (the vxWorks Users Group Exploder) wrote:

I am not surprised.

In the past (> 1 yr) we had problems with the fmod function returning the
incorrect value on mv2603.  We were sent several 'fixes' that each revealed
successive problems deeper in their math libraries.  We finally gave up and
hacked a very non-elegant fix for ourselves. I am not sure if we even told
them thier 'fixes' were still broken or if these deeper library problems
were ever fixed on subsequent BSP patches/releases or not.

Tom


vxworks tornado

> Submitted-by owner-vxwexplo-process  Wed Dec 16 07:51:39 1998
> Submitted-by: tpbiele@sandia.gov
> 
> Fellow vxworks users,
> 
> I believe I have discovered two double floating point numbers that the floor() function on 
> an MV2604 board does work correctly on.  The code snippet that I used and the output that I got are shown
> below.  I would appreciate any feedback.
> 
> ******************************** Begin Function ******************************************
> 
> #include "vxworks.h"
> #include "math.h"
> #include "stdio.h"
> 
> void floorchk(void)
> {
>   double temp;
>   double temp1;
>   long *pLong;
> 
>   temp = -1327828.87015908;
>   pLong = (long *)&temp;
> 
>   /* change the LSW slightly */
>   pLong[1] = 0xdec2beca;
> 
>   printf("\npLong[0] = 0x%X\n", pLong[0]);
>   printf("pLong[1] = 0x%X\n", pLong[1]);
>   temp1 = floor(temp);
>   printf("floor(%f) = %f\n\n", temp, temp1);
> 
> 
>   /* change the LSW slightly */
>   pLong[1] = 0xdec2becb;
> 
>   printf("\npLong[0] = 0x%X\n", pLong[0]);
>   printf("pLong[1] = 0x%X\n", pLong[1]);
>   temp1 = floor(temp);
>   printf("floor(%f) = %f\n\n", temp, temp1);
> 
> 
>   /* change the LSW slightly */
>   pLong[1] = 0xdec2becc;
> 
>   printf("\npLong[0] = 0x%X\n", pLong[0]);
>   printf("pLong[1] = 0x%X\n", pLong[1]);
>   temp1 = floor(temp);
>   printf("floor(%f) = %f\n\n", temp, temp1);
> 
> 
>   /* change the LSW slightly */
>   pLong[1] = 0xdec2becd;
> 
>   printf("\npLong[0] = 0x%X\n", pLong[0]);
>   printf("pLong[1] = 0x%X\n", pLong[1]);
>   temp1 = floor(temp);
>   printf("floor(%f) = %f\n\n", temp, temp1);
> 
> 
> 
>   /* change the LSW slightly */
>   pLong[1] = 0xdec2bece;
> 
>   printf("\npLong[0] = 0x%X\n", pLong[0]);
>   printf("pLong[1] = 0x%X\n", pLong[1]);
>   temp1 = floor(temp);
>   printf("floor(%f) = %f\n\n", temp, temp1);
> }
> 
> ******************************** End Function ******************************************
> 
> 
> 
> ******************************** Begin Output ******************************************
> 
> pLong[0] = 0xC13442D4
> pLong[1] = 0xDEC2BECA
> floor(-1327828.870159) = -1327829.000000
> 
> 
> pLong[0] = 0xC13442D4
> pLong[1] = 0xDEC2BECB
> floor(-1327828.870159) = -1327829.000000
> 
> 
> pLong[0] = 0xC13442D4
> pLong[1] = 0xDEC2BECC
> floor(-1327828.870159) = -1327828.870159
> 
> 
> pLong[0] = 0xC13442D4
> pLong[1] = 0xDEC2BECD
> floor(-1327828.870159) = -1327828.870159
> 
> 
> pLong[0] = 0xC13442D4
> pLong[1] = 0xDEC2BECE
> floor(-1327828.870159) = -1327829.000000
> 
> ******************************** End Output ******************************************
> 
> --------------------------------------------------------
> E-mail: tpbiele@sandia.gov
> Date: 12/16/1998
> Time: 08:39:31
> 
> This message was sent by Z-Mail Pro - from NetManage
> NetManage - delivers Standards Based IntraNet Solutions
> --------------------------------------------------------


 Tom Antles
 antles@spk.hp.com
 Phone: (509) 921-3590
 Fax:   (509) 921-3991


From owner-vxwexplo-process  Wed Dec 16 12:33:48 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Wed Dec 16 12:33:52 PST 1998
Subject: Problems with the floor() function on MV2604 -Reply

I ran the test case on both a 2604 and a 2700 and had no problems with it.

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com

>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/16/98 09:51am >>>
Submitted-by owner-vxwexplo-process  Wed Dec 16 07:51:39 1998
Submitted-by: tpbiele@sandia.gov

Fellow vxworks users,

I believe I have discovered two double floating point numbers that the floor() function on 
an MV2604 board does work correctly on.  The code snippet that I used and the output that I got are
shown
below.  I would appreciate any feedback.

******************************** Begin Function ******************************************

#include "vxworks.h"
#include "math.h"
#include "stdio.h"

void floorchk(void)
{
  double temp;
  double temp1;
  long *pLong;

  temp = -1327828.87015908;
  pLong = (long *)&temp;

  /* change the LSW slightly */
  pLong[1] = 0xdec2beca;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);


  /* change the LSW slightly */
  pLong[1] = 0xdec2becb;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);


  /* change the LSW slightly */
  pLong[1] = 0xdec2becc;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);


  /* change the LSW slightly */
  pLong[1] = 0xdec2becd;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);



  /* change the LSW slightly */
  pLong[1] = 0xdec2bece;

  printf("\npLong[0] = 0x%X\n", pLong[0]);
  printf("pLong[1] = 0x%X\n", pLong[1]);
  temp1 = floor(temp);
  printf("floor(%f) = %f\n\n", temp, temp1);
}

******************************** End Function ******************************************



******************************** Begin Output ******************************************

pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECA
floor(-1327828.870159) = -1327829.000000


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECB
floor(-1327828.870159) = -1327829.000000


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECC
floor(-1327828.870159) = -1327828.870159


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECD
floor(-1327828.870159) = -1327828.870159


pLong[0] = 0xC13442D4
pLong[1] = 0xDEC2BECE
floor(-1327828.870159) = -1327829.000000

******************************** End Output ******************************************

--------------------------------------------------------
E-mail: tpbiele@sandia.gov
Date: 12/16/1998
Time: 08:39:31

This message was sent by Z-Mail Pro - from NetManage
NetManage - delivers Standards Based IntraNet Solutions
--------------------------------------------------------



From owner-vxwexplo-process  Wed Dec 16 14:18:07 1998
From: "Carl C. Chesbrough" <carl@themis.com>
Date: Wed Dec 16 14:18:11 PST 1998
Subject: Re: VxWorks: shared memory network for PowerPC (MVME2700)

VxWorks...

From the slave CPU you should be able to display memory and see
the readyValue of 0x12345678 or 0x87654321.  It should be the
same as displaying memory on the master at 0x4100.  Typically
I will boot the slave CPU from ethernet and then take the value
returned by sysLocalToBusAdrs() of 0x8004100 and use that in
the sysBusToLocalAdrs(0xd,0x8004100,&slaveAdrs).  This needs
to be run on the slave as the VME address of 0x8004100 may not
be accessed using 0x8004100 on the slave.

HTH,
-Carl.


> After rebuilding vxWorks images, the master seems happy by attaching net
> work interface sm0 to the anchor point (0x4100). I verify that the heartbeat 
> on the master is alive by looking at the 5th 4-byte word. In order to get the
> VMEbus (A32) address, I used "sysLocalToBusAdrs(0x0d,0x4100,&adrs)" which
> returns 0x8004100. I used this address as the share memory anchor address
> for all slaves (sm=0x8004100). However slaves are complaining that the address
> is not corretly mapped somehow. Clients keep saying the following without
> granting the vxworks prompt:
> 
> 	Backplane anchor at 0x8004100... Attaching network interface sm0... done.
> 	smIsAlive:  readyValue = 0xffffffff, heartbeat = 0x0
> 
> Does anybody know what I did wrong in setting up the shared memory network with
> the proxy arp?
> 
> Your help would be greatly appreciated.

********************************************************************
*                                                                  *
* Carl C. Chesbrough              Telephone: (510) 252-0870 x 126  *
* Themis Computer                 Facsimile: (510) 490-5529        *
* 3185 Laurelview Court           E-Mail   : carl@themis.com       *
* Fremont, California 94538                                        *
*                                                                  *
********************************************************************


From owner-vxwexplo-process  Wed Dec 16 14:30:54 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Wed Dec 16 14:30:58 PST 1998
Subject: VxWorks: shared memory network for PowerPC (MVME2700) -Reply

Minbo,

8004100 is the VMEbus address.  You need to use the processor address that correlates to that
VMEbus address.  You can determine that by using sysBusToLocalAdrs:

    sysBusToLocalAdrs(0x0d,0x8004100,&adrs)

By default, adrs should be 10004100 for the 2700.

Good luck!

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com

>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/16/98 01:54pm >>>
Submitted-by owner-vxwexplo-process  Wed Dec 16 11:54:53 1998
Submitted-by: "Minbo Shim" <mshim@rst.com>

Vxworks gurus:

I am trying to make a SM network with the proxy arp for the powerpc
boards (mvme2700). As described in the Programmer's manual, I included the
following in the "configAll.h":

	#define INCLUDE_PING
	#define INCLUDE_SM_NET
	#define INCLUDE_PROXY_SERVER
	#define INCLUDE_SM_SEQ_ADDR
	#define INCLUDE_PROXY_DEFAULT_ADDR

And for the master:

	#define PROXY_ARP_MASTER
	#define SM_OFF_BOARD FALSE

and for the slave:

	#define PROXY_ARP_SLAVE
	#define SM_OFF_BOARD TRUE

By doing so, I want slaves to use the memory on the master starting at
0x01000000 (16MB) with the size of 1MB. Here is the configuation (config.h)

	#define SM_ANCHOR_OFFSET 0x4100  /* default for PowerPC */
	#define SM_ANCHOR_ADRS  ((sysProcNumGet() == 0) ? \
       	 ((char*) (LOCAL_MEM_LOCAL_ADRS + SM_ANCHOR_OFFSET)) : \
	        ((char*) (VME_A32_MSTR_LOCAL + SM_ANCHOR_OFFSET)))
	#define SM_MEM_ADRS      0x01000000  
	#define SM_MEM_SIZE      0x00100000
	#define SM_OBJ_MEM_ADRS  (SM_MEM_ADRS+SM_MEM_SIZE)
	#define SM_OBJ_MEM_SIZE  0x00100000 

After rebuilding vxWorks images, the master seems happy by attaching net
work interface sm0 to the anchor point (0x4100). I verify that the heartbeat 
on the master is alive by looking at the 5th 4-byte word. In order to get the
VMEbus (A32) address, I used "sysLocalToBusAdrs(0x0d,0x4100,&adrs)" which
returns 0x8004100. I used this address as the share memory anchor address
for all slaves (sm=0x8004100). However slaves are complaining that the address
is not corretly mapped somehow. Clients keep saying the following without
granting the vxworks prompt:

	Backplane anchor at 0x8004100... Attaching network interface sm0... done.
	smIsAlive:  readyValue = 0xffffffff, heartbeat = 0x0

Does anybody know what I did wrong in setting up the shared memory network with
the proxy arp?

Your help would be greatly appreciated.

Regards,

-----------------
MINBO SHIM; mshim@rst.com
Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
ROBOTIC SYSTEMS TECHNOLOGY
1234 Tech Court, Westminster, MD 21157 



From owner-vxwexplo-process  Wed Dec 16 15:24:59 1998
From: "Wu, Don (HT-EX)" <DWu@GI.com>
Date: Wed Dec 16 15:25:02 PST 1998
Subject: database products on VxWorks

VxWorkers,

Any one knows about commercial database products running on VxWorks? We'd
like a database product that is popular, reliable and mature. Any
recommendation is welcome

Regards,

Don Wu        Ph.D 
System Technologies, Digital Network Systems
General Instrument Corporation
Tel: (215)323-1518 (office), Email: dwu@gi.com



From owner-vxwexplo-process  Wed Dec 16 16:11:48 1998
From: Alistair Adams <aadams@octanttech.com>
Date: Wed Dec 16 16:11:52 PST 1998
Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700)

Assuming you have set up to use EXTENDED VME, I would say your address correct.

Another possibility is the user/supervisor setting of the Address Modifier used for
the A16 master window. The default setting for access to A16 VMEbus is to use a
user mode address modifier. If your I/O board only responds to supervisor addresses
then that might explain your problem. Look at the VAL_LSI3_CTL setting in mv2600.h.

Alistair Adams
Octant Technologies Inc.

the vxWorks Users Group Exploder wrote:

> Submitted-by owner-vxwexplo-process  Wed Dec 16 10:56:55 1998
> Submitted-by: "Minbo Shim" <mshim@rst.com>
>
> Vxworks gurus:
>
> I have some difficulties to get access to a register in the A16-based
> I/O board.
>
> Here is the story. We have an A16-based VMEbus I/O board with short
> addressing map that tells us where to go to see the contents of some
> registers in it. Suppose the local address to one of the registers is
> 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that
> VME MASTER WINDOW for A16 SPACE is following:
>
>         /*
>          * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks
>          * This maps: MPU RANGE:     0xfbff0000 - 0xfbffffff
>          *        to: PCI RANGE:     0xfbff0000 - 0xfbffffff
>          *        to: VME RANGE:     0xfbff0000 - 0xfbffffff
>          */
>         #  define VME_A16_MSTR_LOCAL    0xfbff0000
>         #  define VME_A16_MSTR_SIZE     0x00010000 /* 64K */
>         #  define VAL_LSI3_BS_VALUE     (VME_A16_MSTR_LOCAL)
>
> I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value:
>
>         {
>         (void *) VME_A16_MSTR_LOCAL,
>         (void *) VME_A16_MSTR_LOCAL,
>         VME_A16_MSTR_SIZE,
>         VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
>         VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
>         },
>
> However, every try to get access to "0xfbff6005" has been failed in the sense
> that the contents are NOT what we expect.
>
> Does anybody know what I am missing?
>
> Your help would be greatly appreciated.
>
> -------------------------
> MINBO SHIM; mshim@rst.com
> Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
> ROBOTIC SYSTEMS TECHNOLOGY
> 1234 Tech Court, Westminster, MD 21157



From owner-vxwexplo-process  Wed Dec 16 16:13:11 1998
From: "Carl C. Chesbrough" <carl@themis.com>
Date: Wed Dec 16 16:13:14 PST 1998
Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply

Minbo,

You can use the m() function, giving it a parameter of 1 to do 8-bit
access rather than 16-bit accesses.  I thought that the default d()
access was 16-bits.  You can specify the size with the 3rd parameter
to the d() function.

  -> m 0xfbff6005,1

or

  -> d 0xfbff6005, 1, 1
                   ^  ^
    # of bytes ----|  |
    access size ------|

HTH,
-Carl.

********************************************************************
*                                                                  *
* Carl C. Chesbrough              Telephone: (510) 252-0870 x 126  *
* Themis Computer                 Facsimile: (510) 490-5529        *
* 3185 Laurelview Court           E-Mail   : carl@themis.com       *
* Fremont, California 94538                                        *
*                                                                  *
********************************************************************


> The addressing looks fine.  How are you doing your accesses?  The 6005
> address suggests that you are addressing by byte.  If so, your code should
> be doing something equivalent to:
> 
>     someCharVar = *(char *)0xfbff6005;
> 
> (though hopefully more elegantly).  In particular, the d() funciton is
> probably not useful, because it reads from memory 32 bits at a time.  If
> your board does not respond to D32 bus cycles, you get bus errors and
> useless data.
> 
> HTH
> 
> Charlie Grames
> The Boeing Company
> (314) 233-1956
> Charles.R.Grames@boeing.com
> 
> >>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/16/98 12:57pm >>>
> Submitted-by owner-vxwexplo-process  Wed Dec 16 10:56:55 1998
> Submitted-by: "Minbo Shim" <mshim@rst.com>
> 
> Vxworks gurus:
> 
> I have some difficulties to get access to a register in the A16-based
> I/O board. 
> 
> Here is the story. We have an A16-based VMEbus I/O board with short
> addressing map that tells us where to go to see the contents of some
> registers in it. Suppose the local address to one of the registers is
> 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that 
> VME MASTER WINDOW for A16 SPACE is following:
> 
> 	/*
> 	 * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks
> 	 * This maps: MPU RANGE:     0xfbff0000 - 0xfbffffff
> 	 *        to: PCI RANGE:     0xfbff0000 - 0xfbffffff
> 	 *        to: VME RANGE:     0xfbff0000 - 0xfbffffff
> 	 */
> 	#  define VME_A16_MSTR_LOCAL    0xfbff0000
> 	#  define VME_A16_MSTR_SIZE     0x00010000 /* 64K */
> 	#  define VAL_LSI3_BS_VALUE     (VME_A16_MSTR_LOCAL)
> 	
> I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value:
> 
> 	{
> 	(void *) VME_A16_MSTR_LOCAL,
> 	(void *) VME_A16_MSTR_LOCAL,
> 	VME_A16_MSTR_SIZE,
> 	VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
> 	VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
> 	},
> 
> However, every try to get access to "0xfbff6005" has been failed in the
> sense
> that the contents are NOT what we expect.
> 
> Does anybody know what I am missing?
> 
> Your help would be greatly appreciated.
> 
> 
> -------------------------
> MINBO SHIM; mshim@rst.com
> Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
> ROBOTIC SYSTEMS TECHNOLOGY
> 1234 Tech Court, Westminster, MD 21157 


From owner-vxwexplo-process  Thu Dec 17 01:31:04 1998
From: "Michael Lawnick" <lawnick@nw.softec.de>
Date: Thu Dec 17 01:31:07 PST 1998
Subject: Re: VxWorks: shared memory network for PowerPC (MVME2700)

Check wether slave-bootrom and master-kernel have set the same
#define EXTENDED_VME
There has been a version shift from Rev3 (#undef) to Rev4(#define)

> Vxworks gurus:
> 
> I am trying to make a SM network with the proxy arp for the powerpc
> boards (mvme2700). As described in the Programmer's manual, I included the
> following in the "configAll.h":
> 
MfG
Lawnick, SOFTEC GmbH

==============================================
SOFTEC GmbH               Tel +49-731-96600-0
Promenade 17              Fax +49-731-96600-23
D-89073 Ulm               Michael Lawnick
Germany                   lawnick@softec.de
==============================================


From owner-vxwexplo-process  Thu Dec 17 04:00:25 1998
From: daemon@csg.lbl.gov
Date: Thu Dec 17 04:00:30 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Thu Dec 17 04:00:13 PST 1998

        Subject: Re: Network misbeviour
        Subject: Re: Network misbeviour
        Subject: DEC 21140 driver on pc486: some fixes
        Subject: PPP Connect Problems
        Subject: DEC 21140 driver on pc486: some fixes
        Subject: DEC 21140 driver on pc486: some fixes
        Subject: Re: MPC860 chip select & cache problems
        Subject: Re: Looking for 860SAR ATM driver for VxWorks ??
        Subject: large files and rawFs ?
        Subject: Strange behaviour with global variable : have you seen it before?
        Subject: Re: Tornado + Version Control integration
        Subject: PERL on VxWorks?
        Subject: Re: Build Output Requires Prompting?
        Subject: Re: Strange behaviour with global variable : have you seen it before?
        Subject: BOOTP / RARP server
        Subject: Re: DMA on MVME2600
        Subject: Re: DMA on MVME2600

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

Newsgroups: comp.os.vxworks
Subject: Re: Network misbeviour
Date: Wed, 16 Dec 1998 17:36:57 +0000
From: Ian Love <ijl@wireplay.bt.co.uk>
Organization: BT Labs - but speaking only for myself
Message-ID: <3677EFB9.203@wireplay.bt.co.uk>
References: <758neq$5ql$1@news.ncal.verio.com>

Dave Craig wrote:
> 
> Here are some symptoms that we have in our system that I'm looking for some
> insight into. We run on x86 with SENS...
> 
> * Two processors on a switched ethernet system communicate with each other
> by broadcasting UDP messages.
> 
> * If severely loaded, one processor (lets call it A) gets into a state where
> it no longer seems to get messages broadcast from B in real time. They
> appear to accumulate in a buffer somewhere before finally the whole lot
> avalanches through. No messages appear to be lost.
:
:

I am running MV2305 _without_ SENS, and am seeing same behaviour:
raised SPR116776  with WRS some time back: no response as yet but they
have given me source for the dc ethernet driver so I can instrument it.
(not done yet)

I had a set of test apps sending lots of small *TCP* packets to another
card, which turned the packets round and returned them to a receiving
app. 
The packets contain the sending end 'tick' time.
Each sender sends a packet every 100ms.
Sporadically, one of the receivers (which are measuring latency),
report a latency of 300ms for one packet, 200 for next and 100 for next,
implying that something is not dealing with THAT PARTICULAR CONNECTION'S
DATA for a while.
This is happening even when we run the ethernet interfaces at 100Mb,
Full Duplex, back-to-back!

options:
	1) interface (in my case dc) driver problem
		- but it only affects SOME of the connections using
			the interface?
	2) TCP/IP problem
		- but it affects your UDP as well, so:
	3) IP problem
		- but I have non-SENS, and you have SENS

(3) is favorite, but what if the driver is causing the IP layer to
'back off' by not responding or returning some kind of error....?

WRS are being their usual responsive selves.....
Suggest you add your weight to the SPR!

regards
Ian Love,

The views expressed above are my own and not those of my employer

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

Newsgroups: comp.os.vxworks
Subject: Re: Network misbeviour
Date: Wed, 16 Dec 1998 09:56:42 -0800
From: "Dave Craig" <dcraig@euphonix.com>
Organization: Verio Northern California's Usenet News Service
Message-ID: <758s8i$80p$1@news.ncal.verio.com>
References: <758neq$5ql$1@news.ncal.verio.com> <3677EFB9.203@wireplay.bt.co.uk>

Thanks Ian, it sounds like it might be the same problem. I'll go and read up
on the SPR. In our case if the processor A (which has got into the "bad"
state) stops receiving any new packets, then there are likely to be a number
of packets that are sitting not being processed somewhere in the stack of
that processor. These can be flushed through by some number of new packets
arriving. This would seem to be the same as your case where a couple of
packets got delayed and then flushed through (the 300ms and 200ms latency
ones),

Thanks again

Dave.




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

Newsgroups: comp.os.vxworks
Subject: DEC 21140 driver on pc486: some fixes
Date: Mon, 14 Dec 1998 18:06:01 GMT
From: david.hagood@ifrsys.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <753k27$ahj$1@nnrp1.dejanews.com>
References: <366E73A6.32FD2550@sktc.net>

<cont from prev msg>
     *             |-------------------------------------|
     *             |           The transmit buffers      |
     *             |       (DC_BUFSIZ * dcNumTds)        |
     *             |-------------------------------------|
     *             |           Setup Filter Frame        |
     *             |           (FLTR_FRM_SIZE)           |
     *             |-------------------------------------|
     */

    /* zero the shared memory */
    bzero ( (char *) pShMem, (int) sz );

    /* carve Rx memory structure */

  pDrvCtrl->rxRing = (DC_RDE *) (((int)pShMem + 0x07) & ~0x07); /* wd align
*/  pDrvCtrl->dcNumRds = dcNumRds;	    /* receive ring size */ 
pDrvCtrl->rxIndex = 0;

    /* Set up the Rx descriptors */

    rmd = pDrvCtrl->rxRing;                      /* receive ring */
    buf = (char *)(rmd + pDrvCtrl->dcNumRds);
    for (ix = 0; ix < pDrvCtrl->dcNumRds; ix++, rmd++, buf += DC_BUFSIZ)
        {

        pTemp = DC_CACHE_VIRT_TO_PHYS (buf);	/* convert to PCI  phys addr */
	pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp));
	rmd->rDesc2 = PCISWAP((ULONG)pTemp);	/* buffer address 1 */
	rmd->rDesc3 = 0;			/* no second buffer */

	/* buffer size */
	rmd->rDesc1 = PCISWAP(RDESC1_RBS1_VAL(DC_BUFSIZ) |
			      RDESC1_RBS2_VAL(0));

	if (ix == (pDrvCtrl->dcNumRds - 1))	/* if its is last one */
	    rmd->rDesc1 |= PCISWAP(RDESC1_RER);	/* end of receive ring */

	rmd->rDesc0 = PCISWAP(RDESC0_OWN);	/* give ownership to lance */
        }

    /* setup Rx loaner pool */

    pDrvCtrl->nLoanRx = dcLPool;
    for (ix = 0; ix < dcLPool; ix++, buf += DC_BUFSIZ)
	{
        pDrvCtrl->lPool[ix] = buf;
        pDrvCtrl->refCnt[ix] = 0;
        pDrvCtrl->pRefCnt[ix] = & pDrvCtrl->refCnt[ix];
	}

    /* carve Tx memory structure */

  pDrvCtrl->txRing = (DC_TDE *) (((int)buf + 0x07) & ~0x07); /* qword align
*/  pDrvCtrl->dcNumTds = dcNumTds;  /* transmit ring size */ 
pDrvCtrl->txIndex = 0;	pDrvCtrl->txDiIndex = 0;

    /* Setup the Tx descriptors */

    tmd = pDrvCtrl->txRing;                 /* transmit ring */
    buf = (char *)(tmd + pDrvCtrl->dcNumTds);
    for (ix = 0; ix < pDrvCtrl->dcNumTds; ix++, tmd++, buf += DC_BUFSIZ)
        {
        pTemp = DC_CACHE_VIRT_TO_PHYS (buf);	/* convert to PCI phys addr */
	pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp));
	tmd->tDesc2 = PCISWAP((ULONG)pTemp);	/* buffer address 1 */
	tmd->tDesc3 = 0;			/* no second buffer */

	tmd->tDesc1 = PCISWAP((TDESC1_TBS1_PUT(0) |
			       TDESC1_TBS2_PUT(0) |
			       TDESC1_IC	  | 	/* intrpt on xmit */
			       TDESC1_LS          |	/* last segment */
			       TDESC1_FS));		/* first segment */

	if (ix == (pDrvCtrl->dcNumTds - 1))	/* if its is last one */
	    tmd->tDesc1 |= PCISWAP(TDESC1_TER);	/* end of Xmit ring */

	tmd->tDesc0 = 0 ;			/* clear status */
        }

    /* carve Setup Filter Frame buffer */

  pDrvCtrl->pFltrFrm = (ULONG *)(((int)buf + 0x07) & ~0x07); /* word align */
 buf += FLTR_FRM_SIZE;

    /* Flush the write pipe */

    CACHE_PIPE_FLUSH ();

    /* Device Initialization */

    dcChipReset (pDrvCtrl);			/* reset the chip */

    pTemp = DC_CACHE_VIRT_TO_PHYS (pDrvCtrl->rxRing);
    pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp));

    dcCsrWrite (devAdrs, CSR3, ((ULONG)pTemp));	/* recv descriptor */
    pTemp = DC_CACHE_VIRT_TO_PHYS (pDrvCtrl->txRing);
    pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp));

    dcCsrWrite (devAdrs, CSR4, ((ULONG)pTemp));	/* xmit descriptor */

    /* get the ethernet address */

/* RCP: If DEC21140 make an alternate call */
    if (!DEC21140(pDrvCtrl->dcOpMode))
    {
       if (dcEnetAddrGet (devAdrs, (char *) pDrvCtrl->idr.ac_enaddr, 6) != OK)
	   logMsg ("dc: error reading ethernet rom\n", 0,0,0,0,0,0);
    }
    else
/* Get the ethernet address for the DEC21140 */
    {
       if (dc21140EnetAddrGet (devAdrs, (char *) pDrvCtrl->idr.ac_enaddr, 6)
	   != OK)
	   logMsg ("dc21140: error reading ethernet rom\n", 0,0,0,0,0,0);
    }

/* RCP: Check to see if Full Duplex mode set */
    if ((pDrvCtrl->dcOpMode & DC_FULLDUPLEX_FLAG) &&
	(pDrvCtrl->dcOpMode != NONE))
    	dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_FD));

/* RCP: DEC21040 Specific Setup */
    if (!DEC21140(pDrvCtrl->dcOpMode))
    {
        dcAuiTpInit (devAdrs);			/* configure AUI or 10BASE-T */
/* RCP: Added initialization of CSR6 to turn off Promiscuous and Multicast */
	dcCsrWrite (devAdrs, CSR6, 0x0);
    }
    else
    {
/* RCP: DEC21140 Setup - these modes must be set before start Xmitter */

/* Default to 10BT */
    	uTemp = dcCsrRead(devAdrs, CSR6);
        uTemp = uTemp | CSR6_TTM | CSR6_BIT25;

/* Now verify the parameters passed to configure the interface further */
   	if ((pDrvCtrl->dcOpMode & DC_100_MB_FLAG) &&
	    (pDrvCtrl->dcOpMode != NONE))
	{

/* Hard Coded values from SROM offset to start 100MB testing.  The actual
code should  be imbellished to handle the configuration for other possible
interfaces other then  100BaseTx.  This information will be stored in the
DC21140 Info Leaf of the SROM.	In the case of the DEC520-AA PMC, the
starting offset for the DEC21140 Info Leaf  is 0x41.  This location contains
some basic capabilities of the interface and the  initial state of CSR12. 
Also there is a block count for the total number of interfaces	supported by
the interface card.  For testing the default values for the SYM_SCR 
(100MBaseTx) port will be used.  The information for this interface starts in
offset	0x49. The configuration for Full Duplex starts in offset 0x4D. 
Potentially the driver	could be altered to do some autosensing and
configuration, but for now arguments will  be passed to the driver to
configure it.

*/
	   dcCsrWrite (devAdrs, CSR12, INIT_CSR12);
	   dcCsrWrite (devAdrs, CSR12, SYM_MODE);

   	   if ((pDrvCtrl->dcOpMode & DC_HBE_FLAG) &&
		(pDrvCtrl->dcOpMode != NONE))
		uTemp = (uTemp & ~CSR6_TTM) | CSR6_PS;
	   else
		uTemp = (uTemp & ~CSR6_TTM) | CSR6_PS | CSR6_HBD ;

	   uTemp = uTemp | (((pDrvCtrl->dcOpMode & DC_SCRAMBLER_FLAG) &&
		  (pDrvCtrl->dcOpMode != NONE)) ? CSR6_SCR : 0) |
		  (((pDrvCtrl->dcOpMode & DC_PCS_FLAG) &&
		  (pDrvCtrl->dcOpMode != NONE)) ? CSR6_PCS : 0);
	}
        else /* DDH hard wired to light up the Ziatech boards */
        {

	   dcCsrWrite (devAdrs, CSR12, 0x1FF);
           uTemp = CSR6_BIT25 | CSR6_TTM | CSR6_PS;

	    dcCsrWrite(devAdrs,CSR12,0x1FF);
	    mdio_write(devAdrs,8,4,0x1e1);
	    mdio_write(devAdrs,8,0,0x3100);
        }

	dcCsrWrite (devAdrs, CSR6, uTemp);
    }

/* RCP: End of DEC21140 Code Addition */

    /* clear the status register */

    dcCsrWrite (devAdrs, CSR5, 0xffffffff);

    /* set the operating mode to start Xmitter only */

/* RCP: Modify this call to accomodate DEC21140 , add the Setting of Bit 25*/
    dcCsrWrite (devAdrs, CSR6,
	       (dcCsrRead (devAdrs, CSR6) |  CSR6_ST | CSR6_BIT25));

/* RCP: Added Loopback modes */

    if ((pDrvCtrl->dcOpMode & DC_ILOOPB_FLAG) &&
	(pDrvCtrl->dcOpMode != NONE))

/* RCP: Internal loopback selected */
    	dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_OM_ILB));
    else

    	if ((pDrvCtrl->dcOpMode & DC_ELOOPB_FLAG) &&
	    (pDrvCtrl->dcOpMode != NONE))
/* RCP: External loopback selected */
	   dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_OM_ELB));

    /* Xmit a Filter Setup Frame */

    dcFltrFrmXmit (pDrvCtrl, (char *) pDrvCtrl->idr.ac_enaddr, 1);

    /* set operating mode any additional operational mode set by user */

  dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) |  CSR6_SR  | /* start
receiver */			    (((pDrvCtrl->dcOpMode &
DC_MULTICAST_FLAG) &&				       (pDrvCtrl->dcOpMode !=
NONE)) ? CSR6_PM: 0) |				  (((pDrvCtrl->dcOpMode &
DC_PROMISCUOUS_FLAG) && 			       (pDrvCtrl->dcOpMode !=
NONE)) ? CSR6_PR: 0)			  ));

    /* set up the interrupts */
/* RCP: Modified to accomodate DEC21140 */
    if (!DEC21140(pDrvCtrl->dcOpMode))
    	dcCsrWrite (devAdrs, CSR7, (
			       CSR7_NIM |	/* normal interrupt mask */
			       CSR7_RIM |	/* rcv  interrupt mask */
			       CSR7_TIM |	/* xmit interrupt mask */
			       CSR7_TUM |	/* xmit buff unavailble mask */
			       CSR7_AIM |	/* abnormal interrupt mask */
			       CSR7_SEM |	/* system error mask */
			       CSR7_LFM |	/* link fail mask */
			       CSR7_RUM		/* rcv buff unavailable mask */
			       ));
/* RCP: Removed CSR7_LFM for DEC21140 */
    else
    	dcCsrWrite (devAdrs, CSR7, (
			       CSR7_NIM |	/* normal interrupt mask */
			       CSR7_RIM |	/* rcv  interrupt mask */
			       CSR7_TIM |	/* xmit interrupt mask */
			       CSR7_TUM |	/* xmit buff unavailble mask */
			       CSR7_AIM |	/* abnormal interrupt mask */
			       CSR7_SEM |	/* system error mask */
			       CSR7_RUM		/* rcv buff unavailable mask */
			       ));

    sysLanIntEnable (ilevel);                   /* enable LANCE interrupts */

    pDrvCtrl->idr.ac_if.if_flags |= (IFF_UP | IFF_RUNNING | IFF_NOTRAILERS);

    /* Set our flag */

    pDrvCtrl->attached = TRUE;

    return (OK);
    }

/*******************************************************************************
*
* dcReset - reset the interface
*
* Mark interface as inactive & reset the chip
*/

LOCAL void dcReset
    (
    int unit
    )
    {
    DRV_CTRL *pDrvCtrl = & drvCtrl [unit];

    pDrvCtrl->idr.ac_if.if_flags = 0;
    dcChipReset (pDrvCtrl);                           /* reset LANCE */
    }

/*******************************************************************************
*
* dcInt - handle controller interrupt
*
* This routine is called at interrupt level in response to an interrupt from
* the controller.
*/

LOCAL void dcInt
    (
    DRV_CTRL *	pDrvCtrl	/* pointer to device control struct */
    )
    {
    DC_TDE *	tmd;		/* pointer to Xmit ring descriptor */
    ULONG	stat;		/* status register */
    ULONG	devAdrs;	/* device address */
    devAdrs = pDrvCtrl->devAdrs;


    /* Read the device status register */

    stat = dcCsrRead(devAdrs, CSR5);

    /* clear the interrupts */

    dcCsrWrite(devAdrs, CSR5, stat);

    /* If false interrupt, return. */

    if ( ! (stat & (CSR5_NIS | CSR5_AIS)) )
        return;

    /* Check for system error */

    if (stat & CSR5_SE)
        {
        ++pDrvCtrl->idr.ac_if.if_ierrors;

        /* restart chip on fatal error */

	pDrvCtrl->idr.ac_if.if_flags &= ~(IFF_UP | IFF_RUNNING);

	(void) netJobAdd (
			 (FUNCPTR)dcRestart,
			 pDrvCtrl->idr.ac_if.if_unit,
			 0,0,0,0
			 );
	return;
        }

    /* Have netTask handle any input packets */

    if ((stat & CSR5_RI) && (!(stat & CSR5_RPS)))
        {
	(void) netJobAdd (
			 (FUNCPTR)dcHandleRecvInt,
			 (int)pDrvCtrl,
			 0,0,0,0
			 );
	/* disable the Rx intr, re-enable in dcHandleRecvInt() */

	dcCsrWrite(devAdrs, CSR7, (stat & ~CSR7_RIM));
        }

    /*
     * Did LANCE update any of the TMD's?
     * If not then don't bother continuing with transmitter stuff
     */

    if (!(stat & CSR5_TI))
        return;

    while (pDrvCtrl->txDiIndex != pDrvCtrl->txIndex)
        {
        /* disposal has not caught up */

        tmd = pDrvCtrl->txRing + pDrvCtrl->txDiIndex;

        /* if the buffer is still owned by LANCE, don't touch it */

        DC_CACHE_INVALIDATE (tmd, TMD_SIZ);
        if (tmd->tDesc0 & PCISWAP(TDESC0_OWN))
            break;

        /* now bump the tmd disposal index pointer around the ring */

        pDrvCtrl->txDiIndex = (pDrvCtrl->txDiIndex + 1) % pDrvCtrl->dcNumTds;

        /*
         * TDESC0.ES is an "OR" of LC, NC, UF, EC.
         * here for error conditions.
         */

        if (tmd->tDesc0 & PCISWAP(TDESC0_ES))
            {

            pDrvCtrl->idr.ac_if.if_oerrors++;     /* output error */
            pDrvCtrl->idr.ac_if.if_opackets--;

            /* If error was due to excess collisions, bump the collision
             * counter.
             */
            if (tmd->tDesc0 & PCISWAP(TDESC0_EC))
                pDrvCtrl->idr.ac_if.if_collisions += 16;

	    /* bump the collision counter if late collision */

            if (tmd->tDesc0 & PCISWAP(TDESC0_LC))
                pDrvCtrl->idr.ac_if.if_collisions++;

            /* check for no carrier */

            if (tmd->tDesc0 & PCISWAP(TDESC0_NC | TDESC0_LO | TDESC0_LF))
                logMsg ("dc%d: no carrier\n",
                    pDrvCtrl->idr.ac_if.if_unit, 0,0,0,0,0);

            /* Restart chip on fatal errors.
             * The following code handles the situation where the transmitter
             * shuts down due to an underflow error.  This is a situation that
             * will occur if the DMA cannot keep up with the transmitter.
             * It will occur if the LANCE is being held off from DMA access
             * for too long or due to significant memory latency.  DRAM
             * refresh or slow memory could influence this.  Many
             * implementation use a dedicated LANCE buffer.  This can be
             * static RAM to eliminate refresh conflicts; or dual-port RAM
             * so that the LANCE can have free run of this memory during its
             * DMA transfers.
             */

            if (tmd->tDesc0 & PCISWAP(TDESC0_UF))
                {
                pDrvCtrl->idr.ac_if.if_flags &= ~(IFF_UP | IFF_RUNNING);
                (void) netJobAdd (
                                 (FUNCPTR)dcRestart,
                                 pDrvCtrl->idr.ac_if.if_unit,
                                 0,0,0,0
                                 );
                return;
                }
            }
	tmd->tDesc0 = 0;	/* clear all error & stat stuff */
        }

    /* Flush the write pipe */

    CACHE_PIPE_FLUSH ();

    }

/*******************************************************************************
*
* dcHandleRecvInt - task level interrupt service for input packets
*
* This routine is called at task level indirectly by the interrupt
* service routine to do any message received processing.
*/

LOCAL void dcHandleRecvInt
    (
    DRV_CTRL *	pDrvCtrl	/* pointer to device control struct */
    )
    {
    DC_RDE *	rmd;		/* pointer to Rx ring descriptor */

    while ((rmd = dcGetFullRMD (pDrvCtrl)) != NULL)
    	dcRecv (pDrvCtrl, rmd);

  /* re-enable the Rx interrupt */  dcCsrWrite (pDrvCtrl->devAdrs, CSR7,
(dcCsrRead (pDrvCtrl->devAdrs, CSR7) |					     
   CSR7_RIM));	}

/*******************************************************************************
*
* dcGetFullRMD - get next received message RMD
*
* Returns ptr to next Rx desc to process, or NULL if none ready.
*/

LOCAL DC_RDE * dcGetFullRMD
    (
    DRV_CTRL *	pDrvCtrl	/* pointer to device control struct */
    )
    {
    DC_RDE *	rmd;		/* pointer to Rx ring descriptor */

    /* Refuse to do anything if flags are down */

    if  (
        (pDrvCtrl->idr.ac_if.if_flags & (IFF_UP | IFF_RUNNING) ) !=
        (IFF_UP | IFF_RUNNING)
        )
        return ((DC_RDE *) NULL);


  rmd = pDrvCtrl->rxRing + pDrvCtrl->rxIndex;  /* form ptr to Rx desc */

    DC_CACHE_INVALIDATE (rmd, RMD_SIZ);


    if ((rmd->rDesc0 & PCISWAP(RDESC0_OWN)) == 0)
        return (rmd);
    else
        return ((DC_RDE *) NULL);
    }

/*******************************************************************************
*
* dcRecv - process the next incoming packet
*
*/

LOCAL STATUS dcRecv
    (
    DRV_CTRL *	pDrvCtrl,	/* pointer to device control struct */
    DC_RDE *	rmd		/* pointer to Rx ring descriptor */
    )
    {
    ENET_HDR *	pEnetHdr;	/* pointer to ethernet header */
    MBUF *	pMbuf = NULL;	/* pointer to mbuf */
    u_long	pPhys;
    UCHAR *	pData;		/* pointer to data */
    int		len;		/* length */
    USHORT	ether_type;	/* ether packet type */

    /* Packet must be checked for errors. */

    if  (rmd->rDesc0 & PCISWAP(RDESC0_ES)) /* If error flag */
        {
	/* error can occur on overflow, crc error, collision,
	 * frame too long, runt frame or length error
	 */
        ++pDrvCtrl->idr.ac_if.if_ierrors;       /* bump error stat */
        goto cleanRXD;                          /* skip to clean up */
        }

    ++pDrvCtrl->idr.ac_if.if_ipackets;		/* bump statistic */

    len = RDESC0_FL_GET(PCISWAP(rmd->rDesc0));	/* frame length */

    len -= 4; 	/* Frame length includes CRC in it so subtract it */

    /* Get pointer to packet */

    pEnetHdr = DC_CACHE_PHYS_TO_VIRT(PCI_TO_MEM_PHYS(PCISWAP(rmd->rDesc2)));
    DC_CACHE_INVALIDATE (pEnetHdr, len);   /* make the packet data coherent */

    /* call input hook if any */

    if ((etherInputHookRtn == NULL) || ((*etherInputHookRtn)
       (& pDrvCtrl->idr.ac_if, (char *) pEnetHdr, len)) == 0)
        {
        /* Adjust length to size of data only */

        len -= SIZEOF_ETHERHEADER;

        /* Get pointer to packet data */

        pData = ((u_char *) pEnetHdr) + SIZEOF_ETHERHEADER;

        ether_type = ntohs ( pEnetHdr->type );

        /* OK to loan out buffer ? -> build an mbuf cluster */

	if ((pDrvCtrl->nLoanRx > 0) && (USE_CLUSTER (len))
	    &&
	    ((pMbuf = build_cluster (pData, len, & pDrvCtrl->idr, MC_LANCE,
	     pDrvCtrl->pRefCnt [(pDrvCtrl->nLoanRx - 1)], dcLoanFree,
	     (int) pDrvCtrl, (int) pEnetHdr,
	     (int) pDrvCtrl->pRefCnt [(pDrvCtrl->nLoanRx - 1)])) != NULL))
	    {
            pPhys = (u_long) DC_CACHE_VIRT_TO_PHYS(MEM_TO_PCI_PHYS(
		    (pDrvCtrl->lPool[--pDrvCtrl->nLoanRx])));
	    rmd->rDesc2 = PCISWAP(pPhys);
	    }
        else
            {
            if ((pMbuf = bcopy_to_mbufs (pData, len, 0, & pDrvCtrl->idr.ac_if,
                pDrvCtrl->memWidth)) == NULL)
		{
                ++pDrvCtrl->idr.ac_if.if_ierrors;	/* bump error stat */
                goto cleanRXD;
		}
            }

        /* send on up... */

        do_protocol_with_type (ether_type, pMbuf, & pDrvCtrl->idr, len);

/* RCP: This is a redundant increment of incoming packets, removed from
original driver */ /*  ++pDrvCtrl->idr.ac_if.if_ipackets;*/	/* bump
statistic */

        }

    /* Done with descriptor, clean up and give it to the device. */

    cleanRXD:

    /* clear status bits and give ownership to device */

    rmd->rDesc0 = PCISWAP(RDESC0_OWN);

    /* Flush the write pipe */

    CACHE_PIPE_FLUSH ();

    /* Advance our management index */

    pDrvCtrl->rxIndex = (pDrvCtrl->rxIndex + 1) % pDrvCtrl->dcNumRds;

    return (OK);
    }

/*******************************************************************************
*
* dcOutput - the driver output routine
*
*/

LOCAL int dcOutput
    (
    IDR  *	pIDR,		/* pointer to interface data record */
    MBUF *	pMbuf,		/* pointer to mbuf */
    SOCK *	pDest		/* pointer to destination sock */
    )
    {
    char 	destEnetAddr [6];	/* space for enet addr */
    USHORT	packetType;		/* type field for the packet */
    DRV_CTRL *	pDrvCtrl;		/* pointer to device control struct */
    DC_TDE *	tmd;			/* pointer to Tx ring descriptor */
    char *	buf;			/* pointer to buffer */
    int		len;			/* length */

    /* Check ifnet flags. Return error if incorrect. */

    if  (
        (pIDR->ac_if.if_flags & (IFF_UP | IFF_RUNNING)) !=
        (IFF_UP | IFF_RUNNING)
        )
        return (ENETDOWN);

    /* Attempt to convert socket addr into enet addr and packet type.
     * Note that if ARP resolution of the address is required, the ARP
     * module will call our routine again to transmit the ARP request
     * packet.  This means we may actually call ourselves recursively!
     */

  if (convertDestAddr (pIDR,pDest, destEnetAddr, &packetType, pMbuf) ==
FALSE)	return (OK);  /* I KNOW returning OK is stupid, but it is correct */

    /* Get driver control pointer */

    pDrvCtrl = & drvCtrl [pIDR->ac_if.if_unit];

    /* Obtain exclusive access to transmitter.  This is necessary because
     * certain events can cause netTask to run a job that attempts to transmit
     * a packet.  We can only allow one task here at a time.
     */

    semTake (pDrvCtrl->TxSem, WAIT_FOREVER);

    /* See if next TXD is available */

    tmd = pDrvCtrl->txRing + pDrvCtrl->txIndex;

    DC_CACHE_INVALIDATE (tmd, TMD_SIZ);

    if  (
        ((tmd->tDesc0 & PCISWAP(TDESC0_OWN)) != 0) ||
        (
        ((pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds) == pDrvCtrl->txDiIndex
	)
        )
        {
        m_freem (pMbuf);            /* Discard data */
        goto outputDone;
        }

    /* Get pointer to transmit buffer */

  buf = (char *)DC_CACHE_PHYS_TO_VIRT(PCI_TO_MEM_PHYS(PCISWAP(tmd->tDesc2)));

    /* Copy packet from MBUFs to our transmit buffer.  MBUFs are
     * transparently freed.
     */
    bcopy_from_mbufs ((buf + SIZEOF_ETHERHEADER), pMbuf, len,
		      pDrvCtrl->memWidth);

    /* Fill in the Ethernet header */

    bcopy (destEnetAddr, buf, 6);
    bcopy ( (char *) pIDR->ac_enaddr, (buf + 6), 6);
    ((ENET_HDR *)buf)->type = htons(packetType);

    tmd->tDesc0 = 0;				/* clear buffer error status */
    tmd->tDesc1 &= PCISWAP(~TDESC1_TBS1_MSK);
    tmd->tDesc1 |= PCISWAP(TDESC1_TBS1_PUT(max (ETHERSMALL,
						(len + SIZEOF_ETHERHEADER))));
    tmd->tDesc0 = PCISWAP(TDESC0_OWN); 		/* give ownership to device */

    CACHE_PIPE_FLUSH ();			/* Flush the write pipe */

    /* Advance our management index */

    pDrvCtrl->txIndex = (pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds;

    if (dcKickStartTx)
    	dcCsrWrite(pDrvCtrl->devAdrs, CSR1, CSR1_TPD);	/* xmit poll demand */

    /* Bump the statistic counter. */

    pIDR->ac_if.if_opackets++;

    outputDone:

    /* Release exclusive access. */

    semGive (pDrvCtrl->TxSem);

    return (OK);

    }

/*******************************************************************************
*
* dcIoctl - the driver I/O control routine
*
* Process an ioctl request.
*/

LOCAL int dcIoctl
    (
    IDR  *	ifp,		/* pointer interface data record */
    int		cmd,		/* command */
    caddr_t	data		/* data */
    )
    {
    int 	error = 0;
    DRV_CTRL *  pDrvCtrl = (DRV_CTRL *)ifp;	/* pointer to device */
    switch (cmd)
        {
        case SIOCSIFADDR:
            ifp->ac_ipaddr = IA_SIN (data)->sin_addr;
            break;

        case SIOCSIFFLAGS:
            /* No further work to be done */
            break;

        case IFF_PROMISC:	/* set device in promiscuous mode */
	    dcCsrWrite (pDrvCtrl->devAdrs, CSR6,
			(dcCsrRead(pDrvCtrl->devAdrs, CSR6) | CSR6_PR));
	    break;

        default:
            error = EINVAL;
        }

  return (error);  }
/****************************************************************************
*** * * dcChipReset - hardware reset of chip (stop it) */

LOCAL int dcChipReset
    (
    DRV_CTRL *	pDrvCtrl	/* pointer to device control structure */
    )
    {
    ULONG  	devAdrs = pDrvCtrl->devAdrs;	/* device base address */
    ULONG	volatile ix;				/* index */

    dcCsrWrite(devAdrs, CSR6, CSR6_PS);		/* stop rcvr & xmitter */

    dcCsrWrite(devAdrs, CSR7, 0);		/* mask interrupts */

    dcCsrWrite(devAdrs, CSR0, CSR0_SWR);

    /* Wait Loop, Loop for at least 50 PCI cycles according to chip spec */
    for (ix = 0; ix < 0x1000; ix++)
	dcCsrRead(devAdrs,CSR0);

    /* any additional bus mode | give xmit & rcv process equal priority */

    dcCsrWrite (devAdrs, CSR0, dcCSR0Bmr | CSR0_BAR);

    for (ix = 0; ix < 0x1000; ix++)		/* loop for some cycles */
	;

    return (OK);
    }

/*******************************************************************************
*
* dcAuiTpInit - initialize either AUI or 10BASE-T connection
*
* This function configures 10BASE-T interface. If the link pass state is
* not achieved within two seconds then the AUI interface is initialized.
*/

LOCAL void dcAuiTpInit
    (
    ULONG       devAdrs        /* device base I/O address */
    )
    {

    /* reset the SIA registers */

    dcCsrWrite (devAdrs, CSR13, 0);
    dcCsrWrite (devAdrs, CSR14, 0);
    dcCsrWrite (devAdrs, CSR15, 0);

    /* configure for the 10BASE-T */

    dcCsrWrite (devAdrs, CSR13, CSR13_CAC_CSR);	/* 10BT auto configuration */

    taskDelay (sysClkRateGet() * 2);		/* 2 second delay */

    if (dcCsrRead (devAdrs, CSR12) & (CSR12_LKF | CSR12_NCR))
	{
	/* 10BASE-T not connected initialize interface for AUI */

	dcCsrWrite (devAdrs, CSR13, 0);		/* reset SIA registers */
	dcCsrWrite (devAdrs, CSR14, 0);
	dcCsrWrite (devAdrs, CSR15, 0);

	/* AUI auto configuration */
	dcCsrWrite (devAdrs, CSR13, (CSR13_AUI_TP | CSR13_CAC_CSR));
	}
    }

/*******************************************************************************
*
* dcCsrWrite - select and write a CSR register
*
*/
LOCAL void dcCsrWrite
    (
    ULONG 	devAdrs,		/* device address base */
    int 	reg,			/* register to select */
    ULONG 	value			/* value to write */
    )
    {
#ifdef MEM_MAPPED
    volatile ULONG *	csrReg;

    csrReg = (ULONG *)(devAdrs + (reg * DECPCI_REG_OFFSET));

    /* write val to CSR */

    *(csrReg) = PCISWAP(value);
#else
    sysOutLong(devAdrs+(reg* DECPCI_REG_OFFSET),value);
#endif
    }

/*******************************************************************************
*
* dcCsrRead - select and read a CSR register
*
*/

LOCAL ULONG dcCsrRead
    (
    ULONG	devAdrs,		/* device address base */
    int		reg			/* register to select */
    )
    {
#ifdef MEM_MAPPED
    volatile ULONG *	csrReg;			/* csr register */
    ULONG	csrData;		/* data in csr register */

    csrReg = (ULONG *)(devAdrs + (reg * DECPCI_REG_OFFSET));

    csrData = *csrReg;

    /* get contents of CSR */

    return ( PCISWAP(csrData));
#else
    return sysInLong(devAdrs + (reg * DECPCI_REG_OFFSET));
#endif
    }

/*******************************************************************************
*
* dcRestart - restart the device after a fatal error
*
* This routine takes care of all the messy details of a restart.  The device
* is reset and re-initialized.  The driver state is re-synchronized.
*/

LOCAL void dcRestart
    (
    int 	unit		/* unit to restart */
    )
    {
    ULONG	status;		/* status register */
    int		ix;		/* index variable */
    DC_RDE *	rmd;		/* pointer to receive descriptor */
    DC_TDE *	tmd;		/* pointer to Xmit descriptor */
    DRV_CTRL *	pDrvCtrl = & drvCtrl [unit];
    rmd = pDrvCtrl->rxRing;      /* receive ring */
    tmd = pDrvCtrl->txRing;      /* transmit ring */

    pDrvCtrl->idr.ac_if.if_flags &= ~(IFF_UP | IFF_RUNNING );
    fprintf (stderr, "Fatal Error. DEC Ethernet Chip Restarted\n");

    status = dcCsrRead(pDrvCtrl->devAdrs, CSR6);
    dcCsrWrite (pDrvCtrl->devAdrs, CSR6, 0);	/* reset mode register */

    for (ix = 0; ix < pDrvCtrl->dcNumRds; ix++, rmd++)
        {
	/* buffer size */
	rmd->rDesc1 = PCISWAP(RDESC1_RBS1_VAL(DC_BUFSIZ) |
			      RDESC1_RBS2_VAL(0));

	if (ix == (pDrvCtrl->dcNumRds - 1)) /* if its is last one */
	rmd->rDesc1 |= PCISWAP(RDESC1_RER); /* end of receive ring */

	rmd->rDesc0 = PCISWAP(RDESC0_OWN); /* give ownership to lance */
        }

    for (ix = 0; ix < pDrvCtrl->dcNumTds; ix++, tmd++)
        {
	tmd->tDesc1 = PCISWAP((TDESC1_TBS1_PUT(0) |
			       TDESC1_TBS2_PUT(0) |
			       TDESC1_IC	  | 	/* intrpt on xmit */
			       TDESC1_LS          |	/* last segment */
			       TDESC1_FS));		/* first segment */

	if (ix == (pDrvCtrl->dcNumTds - 1))	/* if its is last one */
	    tmd->tDesc1 |= PCISWAP(TDESC1_TER);	/* end of Xmit ring */

	tmd->tDesc0 = 0 ;			/* clear status */
        }

    /* clear the status register */

    dcCsrWrite (pDrvCtrl->devAdrs, CSR5, 0xffffffff);

    dcCsrWrite (pDrvCtrl->devAdrs, CSR6, status);	/* restore mode */

    pDrvCtrl->idr.ac_if.if_flags |= (IFF_UP | IFF_RUNNING | IFF_NOTRAILERS);

    }

/*******************************************************************************
*
* dcLoanFree - return the given buffer to loaner pool
*
* This routine returns <pRxBuf> to the pool of available loaner buffers.
* It also returns <pRef> to the pool of available loaner reference counters,
* then zeroes the reference count.
*
* RETURNS: N/A
*/

LOCAL void dcLoanFree
    (
    DRV_CTRL *	pDrvCtrl,	/* pointer to device control structure */
    char *	pRxBuf,		/* pointer to receive buffer to free */
    UINT8 *	pRef		/* pointer to reference count */
    )
    {
    /* return loaned buffer to pool */

    pDrvCtrl->lPool[pDrvCtrl->nLoanRx] = pRxBuf;

    /* return loaned reference count to pool */

    pDrvCtrl->pRefCnt[pDrvCtrl->nLoanRx++] = pRef;

    /* reset reference count - should have been done from above, but... */

    *pRef = 0;
    }
<cont next msg>

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: PPP Connect Problems
Date: Wed, 16 Dec 1998 11:21:48 -0700
From: Rick Busser <rickb@sitera.com>
Organization: Dimensional Communications
Message-ID: <3677FA3C.E807A865@sitera.com>

I'm trying to run VxWorks on a MIPS BSP using PPP as the boot device.
When I attach COM2 on my NT machine to COM2 from the MIPS board I see
garbage instead of WDB READY.  I have the serial ports set up the same
way, 9600, 8 data, 1 stop, no flow control.  Does anyone have any ideas
on what to change so I can get WDB READY on COM2?  Has anyone else had
this problem?
I changed the VxWorks image to echo all characters typed on COM2 and
then I see the WDB READY message.  But then I can't run target server
because the boot never finishes.


- --
Rick Busser                            rickb@sitera.com
Software Engineer                      (303) 651-1935 x256
SiTera Corporation                     (303) 651-1199 fax
1820 Lefthand Circle                   Longmont, CO  80501



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

Newsgroups: comp.os.vxworks
Subject: DEC 21140 driver on pc486: some fixes
Date: Mon, 14 Dec 1998 18:04:06 GMT
From: david.hagood@ifrsys.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <753jum$adq$1@nnrp1.dejanews.com>
References: <366E73A6.32FD2550@sktc.net>

After much slogging, I've managed to get the DEC 21140 network driver for
VxWorks (the if_dcfast.c driver) working under x486 VxWorks. I'll list my
changes and attach my file here in case anybody cares.

The changes: 1) I hardwired the initialization of the MII PHY chip. The may
not work for everybody but it got me going. 2) I hardwired the parameters to
the init call. I didn't write the code to parse the PCI information and find
the board, so you'll have to find your board. Use the PCISHOW library
routines. 3) The code to read the MAC address out of the 21140 EEPROM was
broken for little-endian machines. 4) The code to place the ethernet packet
type into the ethernet header was broken for little-endian machines.

Other useful info: The DEC21140 is no longer a Digital Equipment Corp. chip:
Intel now owns it. If you want info, go to www.intel.com, not
www.digital.com.

Here's the changed file:
 /* if_dcFast.c - DEC 21040 PCI Ethernet LAN network interface driver */

/* Copyright 1984-1995 Wind River Systems, Inc. */
#include "copyright_wrs.h"
/*
modification history
- --------------------
01e,06mar96,rcp  added support for the DEC21140 100Mbit Controller
01d,05sep95,vin  added filter Frame setup, added PROMISCOUS MODE to ioctl,
		 changed all ln references to dc, added flag DC_MULTICAST_FLAG.
01c,05apr95,vin  added AUI/10BASE-T dynamic configuration support.
01b,31mar95,caf  changed name from "dcPci" to "dc".
01a,03mar95,vin	 written.
*/

/* FROM ROB PERSONS - Motorola Computer Group (March 06, 1996)
The comments below describe the primary operation and configuration of
the DEC 21X40 driver.  Differences between the two DEC parts will be
outlined in this section and how the original driver was modified to
accomodate the differences.

The DEC21140 is very similar to the original DEC21040 but it also has the
ability to operate on networks at 100-Mb/s along with 10-Mb/s.  The
physical interface is no longer part of the chip so configuration of
the CSR registers which control the AUI and TP interfaces is no longer
applicable.  This part now provides 100-Mb/s MII/SYM 10-Mb/s Serial
intefaces which are then converted to the appropriate external interface
with some additional hardware.  Most of the driver will be uneffected
by the new part.

In the early stages of the driver initialization, the driver will
use the Configuration ID Register (CFID) to determine which of the
two parts is to be used.  A global flag will indicate which device
is in use and its state will be used along with the driver modifications
to accomodate the DEC21140.

The Status Register (CSR5) has three bits which have different behavior.
Bit 12 (Link Fail Status) and Bit 10 (AUI/TP Status) are no longer used
by the DEC21140.  Bit 11 in the DEC21040 indicates a Full-Duplex Short
Frame was Received which in the DEC21140 it indicates the General Purpose
Timer(GPT)  has expired.  The GPT is a new feature with the DEC21140.  Bit
11 is currently not used in the drive and there are no plans on adding support
for the GPT so at this time it will be ignored.

The Operating Mode Register (CSR6) is significantly different.  Many of the
bits reflect the difference in the MII/SYM interface for the 100-Mb/s
interface.  To make the driver as flexible as possible, logic will be added
to the dcattach function to allow for the configuration of all these
control bits at driver configuration.  The following modes will be added:

DEC21140 Flag	- This flag indicates the driver will be operating with
		  a DEC21140 chip and not the DEC21040.
100Mb/s Mode	- This flag will be used to set a bits in the CSR6 for the
		  DEC21140.  The Transmit Threshold Mode and Heartbeat Disable
		  bits will be effect.
Scramble Mode 	- The scrambler function is active and the MII/SYM port
	          transmits and received scrambled symbols.
PCS Function	- The PCS functions are active and MII/SYM port operates
		  in symbol mode.  All MII/SYM port cont andol signals are
		  generated internally bits will be effect.
Port Select	- When selected the MII/SYM mode is active.  All 100-Mb/s
		  modes require this.
Full Duplex Mode- When selected the Lance Chip Operates in Full Duplex Mode.
		  It is important that the can operate in Full Duplex mode
		  as well.
Int Loopback    - An additional mode was added for doing internal loopback.
Ext Loopback    - An additional mode was added for doing external loopback.
HB Enable	- An additional mode was added for testing, enableing heartb.

If none of these mode bits are selected, the DEC21140 will default to the
MII interface with transmit FIFO thresholds appropriate for 10-Mb/s.

Additional code will be added to deal with the different Serial ROM
interface. The DEC21140 now has a new interface to access a R/W ROM part to
store ethernet addresses.  The dcEnetAddrGet will be modified to add the
proper logic to read the DEC21140 Serial ROM interface.  No logic will be
added to reprogram the value.  It turns out the DEC PMC 520-AA only stores
the last 2 bytes of the ethernet address in the ROM.  The driver will make
the assumption that the VENDOR ID portion extends to from 0-3 where bytes 0-2
are the manufacturers assigned values and byte 3 is assigned by DEC for the
class of products.

The remaining Host to Controller interface is identical and should not be
effected by the new part.

*/



/*
This module implements the DEC 21040-PCI Ethernet 32 bit network interface
driver.

The DEC 21040-PCI ethernet controller is inherently little endian because
the chip is designed to operate on a PCI bus which is a little endian
bus. The software interface to the driver is divided into three parts.
The first part is the PCI configuration registers and their set up.
This part is done at the BSP level in the various BSPs which use this
driver. The second and third part are dealt in the driver. The second
part of the interface comprises of the I/O control registers and their
programming. The third part of the interface comprises of the descriptors
and the buffers.

This driver is designed to be moderately generic, operating unmodified
across the range of architectures and targets supported by VxWorks.  To
achieve this, the driver must be given several target-specific parameters,
and some external support routines must be provided.  These parameters,
and the mechanisms used to communicate them to the driver, are detailed
below.  If any of the assumptions stated below are not true for your
particular hardware, this driver will probably not function correctly with
it.

This driver supports upto 4 lance units per CPU.  The driver can be
configured to support big-endian or little-endian architectures.  It
contains error recovery code to handle known device errata related to DMA
activity.

This driver configures the 10BASE-T interface by default and waits for
two seconds to check the status of the link. If the link status is fail
then it configures the AUI interface.

Big endian processors can be connected to the PCI bus through some
controllers which take care of hardware byte swapping. In such cases all the
registers which the chip DMA s to have to be swapped and written to, so that
when the hardware swaps the accesses, the chip would see them correctly. The
chip still has to be programmed to operated in little endian mode as it is on
the PCI bus. If the cpu board hardware automatically swaps all the accesses
to and from the PCI bus, then input and output byte stream need not be
swapped.

BOARD LAYOUT
This device is on-board.  No jumpering diagram is necessary.

EXTERNAL INTERFACE This driver provides the standard external interface with
the following exceptions.  All initialization is performed within the attach
routine; there is no separate initialization routine.  Therefore, in the
global interface structure, the function pointer to the initialization
routine is NULL.

The only user-callable routine is dcattach(), which publishes the `dc'
interface and initializes the driver and device.

TARGET-SPECIFIC PARAMETERS
.iP "bus mode"
This parameter is a global variable that can be modified at run-time.

The LAN control register #0 determines the bus mode of the device,
allowing the support of big-endian and little-endian architectures.
This parameter, defined as "ULONG dcCSR0Bmr", is the value that will
be placed into LANCE control register #0. The default is mode is little
Endian.
For information about changing this parameter, see the manual
.I "DEC  Local Area Network Controller DEC21040 or DEC21140 for PCI."

.iP "base address of device registers"
This parameter is passed to the driver by dcattach().

.iP "interrupt vector"
This parameter is passed to the driver by dcattach().

This driver configures the LANCE device to generate hardware interrupts
for various events within the device; thus it contains
an interrupt handler routine.  The driver calls intConnect() to connect
its interrupt handler to the interrupt vector generated as a result of
the LANCE interrupt.

.iP "interrupt level"
This parameter is passed to the driver by dcattach().

Some targets use additional interrupt controller devices to help organize
and service the various interrupt sources.  This driver avoids all
board-specific knowledge of such devices.  During the driver's
initialization, the external routine sysLanIntEnable() is called to
perform any board-specific operations required to allow the servicing of a
LANCE interrupt.  For a description of sysLanIntEnable(), see "External
Support Requirements" below.

This parameter is passed to the external routine.

.iP "shared memory address"
This parameter is passed to the driver by dcattach().

The LANCE device is a DMA type of device and typically shares access to
some region of memory with the CPU.  This driver is designed for systems
that directly share memory between the CPU and the LANCE.  It
assumes that this shared memory is directly available to it
without any arbitration or timing concerns.

This parameter can be used to specify an explicit memory region for use
by the LANCE.  This should be done on hardware that restricts the LANCE
to a particular memory region.  The constant NONE can be used to indicate
that there are no memory limitations, in which case, the driver
attempts to allocate the shared memory from the system space.

.iP "shared memory size"
This parameter is passed to the driver by dcattach().

This parameter can be used to explicitly limit the amount of shared
memory (bytes) this driver will use.  The constant NONE can be used to
indicate no specific size limitation.  This parameter is used only if
a specific memory region is provided to the driver.

.iP "shared memory width"
This parameter is passed to the driver by dcattach().

Some target hardware that restricts the shared memory region to a
specific location also restricts the access width to this region by
the CPU.  On these targets, performing an access of an invalid width
will cause a bus error.

This parameter can be used to specify the number of bytes of access
width to be used by the driver during access to the shared memory.
The constant NONE can be used to indicate no restrictions.

Current internal support for this mechanism is not robust; implementation
may not work on all targets requiring these restrictions.

.iP "shared memory buffer size"
This parameter is passed to the driver by dcattach().

The driver and LANCE device exchange network data in buffers.  This
parameter permits the size of these individual buffers to be limited.
A value of zero indicates that the default buffer size should be used.
The default buffer size is large enough to hold a maximum-size Ethernet
packet.

.iP "pci Memory base"
This parameter is passed to the driver by dcattach(). This parameter
gives the base address of the main memory on the PCI bus.

.iP "dcOpMode"
This parameter is passed to the driver by dcattach(). This parameter
gives the mode of initialization of the device. The mode flags for both
the DEC21040 and DEC21140 interfaces are listed below.

DC_PROMISCUOUS_FLAG     0x01
DC_MULTICAST_FLAG	0x02

The mode flags specific to the DEC21140 interface are listed below.

DC_100_MB_FLAG          0X04
DC_21140_FLAG           0x08
DC_SCRAMBLER_FLAG       0X10
DC_PCS_FLAG             0x20
DC_PS_FLAG              0x40

The Full Duplex Mode was added to the driver.
DC_FULLDUPLEX_FLAG      0x80

Loopback mode flags
DC_ILOOPB_FLAG          0x100
DC_ELOOPB_FLAG          0x200
DC_HBE_FLAG	        0x400


.iP "Ethernet address"
This is obtained by the driver by reading an ethernet ROM register
interfaced with the device.

.LP

EXTERNAL SUPPORT REQUIREMENTS
This driver requires one external support function:
.iP "void sysLanIntEnable (int level)" "" 9 -1
This routine provides a target-specific enable of the interrupt for
the LANCE device.  Typically, this involves interrupt controller hardware,
either internal or external to the CPU.

This routine is called once, from the dcattach() routine.
.LP

SEE ALSO: ifLib,
.I "DECchip 21040 or 21140 Ethernet LAN Controller for PCI."
*/

#include "vxWorks.h"
#include "stdlib.h"
#include "taskLib.h"
#include "logLib.h"
#include "intLib.h"
#include "netLib.h"
#include "stdio.h"
#include "stdlib.h"
#include "sysLib.h"
#include "iv.h"
#include "memLib.h"
#include "cacheLib.h"
#include "sys/ioctl.h"
#include "etherLib.h"

#ifndef DOC             /* don't include when building documentation */
#include "net/mbuf.h"
#endif  /* DOC */

#include "net/protosw.h"
#include "sys/socket.h"
#include "errno.h"

#include "net/if.h"
#include "net/route.h"

#include "netinet/in.h"
#include "netinet/in_systm.h"
#include "netinet/in_var.h"
#include "netinet/ip.h"
#include "netinet/if_ether.h"
#include "net/if_subr.h"
#include "semLib.h"

#include "if_dcFast.h"	/* device description header */

/* defines */
#define DC_BUFSIZ      (ETHERMTU + SIZEOF_ETHERHEADER + 6)

#define MAX_UNITS       4	/* maximum units supported */
#define DC_L_POOL	0x10	/* number of Rx loaner buffers in pool */
#define LOOP_PER_NS 4
#define DELAY(count)	{\
			volatile int cx = 0;\
			for (cx = 0; cx < (count); cx++);\
			}
#define NSDELAY(nsec)	{\
			volatile int nx = 0;\
			volatile int loop = (int)(nsec*LOOP_PER_NS);\
			for (nx = 0; nx < loop; nx++);\
			}
/* RCP: Added DEC Part Check */
#define DEC21140(x)	 ((x & DC_21140_FLAG) && (x != NONE))
/*
 * If DC_KICKSTART_TX is TRUE the transmitter is kick-started to force a
 * read of the transmit descriptors, otherwise the internal polling (1.6msec)
 * will initiate a read of the descriptors.  This should be FALSE is there
 * is any chance of memory latency or chip accesses detaining the LANCE DMA,
 * which results in a transmitter UFLO error.  This can be changed with the
 * global dcKickStartTx below.
 */
#define DC_KICKSTART_TX TRUE

/* Cache macros */

#define DC_CACHE_INVALIDATE(address, len) \
        CACHE_DRV_INVALIDATE (&pDrvCtrl->cacheFuncs, (address), (len))

#define DC_CACHE_VIRT_TO_PHYS(address) \
        CACHE_DRV_VIRT_TO_PHYS (&pDrvCtrl->cacheFuncs, (address))

#define DC_CACHE_PHYS_TO_VIRT(address) \
        CACHE_DRV_PHYS_TO_VIRT (&pDrvCtrl->cacheFuncs, (address))

/* memory to PCI address translation macros */

#define PCI_TO_MEM_PHYS(pciAdrs) \
	((pciAdrs) - (pDrvCtrl->pciMemBase))

#define MEM_TO_PCI_PHYS(memAdrs) \
	((memAdrs) + (pDrvCtrl->pciMemBase))

/* Typedefs for external structures that are not typedef'd in their .h files
*/

typedef struct mbuf MBUF; typedef struct arpcom IDR;  /* Interface Data
Record wrapper */ typedef struct ifnet IFNET;  /* real Interface Data Record
*/ typedef struct sockaddr SOCK;

/* The definition of the driver control structure */

typedef struct drv_ctrl
    {
    IDR		idr;			/* Interface Data Record */
    int		dcNumRds;		/* RMD ring size */
    int		rxIndex;                /* index into RMD ring */
    DC_RDE *	rxRing;			/* RMD ring */
    int		dcNumTds;		/* TMD ring size */
    int		txIndex;		/* index into TMD ring */
    int		txDiIndex;		/* disposal index into TMD ring */
    DC_TDE *	txRing;			/* TMD ring */
    BOOL        attached;               /* indicates unit is attached */
    SEM_ID      TxSem;                  /* transmitter semaphore */
    ULONG	dcOpMode;		/* mode of operation */
    int         ivec;                   /* interrupt vector */
    int         ilevel;                 /* interrupt level */
    ULONG	devAdrs;                /* device structure address */
    ULONG	pciMemBase;		/* memory base as seen from PCI*/
    int         memWidth;               /* width of data port */
    CACHE_FUNCS cacheFuncs;             /* cache function pointers */
    int		nLoanRx;		/* number of Rx buffers left to loan */
    char	*lPool[DC_L_POOL];	/* receive loaner pool ptrs */
    UINT8	*pRefCnt[DC_L_POOL];	/* stack of reference count pointers */
    UINT8	refCnt[DC_L_POOL];	/* actual reference count values */
    ULONG *	pFltrFrm;		/* pointer to setup filter frame */
    } DRV_CTRL;

#define DRV_CTRL_SIZ		sizeof(DRV_CTRL)
#define RMD_SIZ			sizeof(DC_RDE)
#define TMD_SIZ			sizeof(DC_TDE)

/* globals */

/*  RCP: Reference Removed for new function IMPORT void sysLanIntEnable ();
*/ IMPORT BOOL arpresolve (); /* IMPORT unsigned char dcEnetAddr []; *//*
Ethernet address to load into lance */


BOOL 	dcKickStartTx 	= DC_KICKSTART_TX;
ULONG	dcCSR0Bmr	= 0x8000;	/* cache align 16 words */

/* locals */

LOCAL DRV_CTRL  drvCtrl [MAX_UNITS];	/* array of driver control structs */

LOCAL int	dcNumRds  = NUM_RDS;	/* number of ring descriptors */
LOCAL int	dcNumTds  = NUM_TDS;	/* number of xmit descriptors */
LOCAL int 	dcLPool = DC_L_POOL;

/* forward static functions */

LOCAL void 	dcReset (int unit);
LOCAL void 	dcInt (DRV_CTRL *pDrvCtrl);
LOCAL void 	dcHandleRecvInt (DRV_CTRL *pDrvCtrl);
LOCAL STATUS 	dcRecv (DRV_CTRL *pDrvCtrl, DC_RDE *rmd);
LOCAL int 	dcOutput (IDR *ifp, MBUF *m0, SOCK *dst);
LOCAL int 	dcIoctl (IDR *ifp, int cmd, caddr_t data);
LOCAL int 	dcChipReset (DRV_CTRL *pDrvCtrl);
LOCAL DC_RDE *	dcGetFullRMD (DRV_CTRL *pDrvCtrl);
LOCAL void	dcAuiTpInit (ULONG devAdrs);
LOCAL void 	dcCsrWrite (ULONG devAdrs, int reg, ULONG value);
LOCAL ULONG 	dcCsrRead (ULONG devAdrs, int reg);
LOCAL void 	dcRestart (int unit);
LOCAL STATUS 	dcEnetAddrGet (ULONG devAdrs, char * enetAdrs, int len);
LOCAL STATUS 	dc21140EnetAddrGet (ULONG devAdrs, char * enetAdrs, int len);
LOCAL BOOL 	convertDestAddr (IDR * pIDR, SOCK * pDestSktAddr,
				 char * pDestEnetAddr, u_short * pPacketType,
				 MBUF * pMbuf);
LOCAL void 	dcLoanFree (DRV_CTRL *pDrvCtrl, char *pRxBuf, UINT8 *pRef);
LOCAL int	dcFltrFrmSetup (DRV_CTRL * pDrvCtrl, char * pPhysAdrsTbl,
				int tblLen);
LOCAL int	dcFltrFrmXmit (DRV_CTRL * pDrvCtrl, char * pPhysAdrsTbl,
			       int tblLen);


#ifdef DC_DEBUG
void dcCsrShow (ULONG devAdrs);
#endif /* DC_DEBUG */

/* RCP: Add utilities to read entries in Serial ROM for DEC21140 */
USHORT dcReadRom (ULONG devAdrs, UCHAR lineCnt);
int dcViewRom (ULONG devAdrs, UCHAR lineCnt, int cnt);

/* RCP: Temporary reference of new global symbol */
LOCAL STATUS sysLanIntEnable (int Level);

/* The MII functions were borrowed from the Linux Tulip driver
 */
/* MII transceiver control section.
   Read and write the MII registers using software-generated serial
   MDIO protocol.  See the MII specifications or DP83840A data sheet
   for details. */

/* The maximum data clock rate is 2.5 Mhz.  The minimum timing is usually
   met by back-to-back PCI I/O cycles, but we insert a delay to avoid
   "overclocking" issues or future 66Mhz PCI. */
#define mdio_delay() sysInLong(mdio_addr)

/* Read and write the MII registers using software-generated serial
   MDIO protocol.  It is just different enough from the EEPROM protocol
   to not share code.  The maxium data clock rate is 2.5 Mhz. */
#define MDIO_SHIFT_CLK		0x10000
#define MDIO_DATA_WRITE0	0x00000
#define MDIO_DATA_WRITE1	0x20000
#define MDIO_ENB		0x00000		/* Ignore the 0x02000 databook
setting. */
#define MDIO_ENB_IN		0x40000
#define MDIO_DATA_READ		0x80000

static int mdio_read(int ioaddr, int phy_id, int location)
{
	int i;
	int read_cmd = (0xf6 << 10) | (phy_id << 5) | location;
	int retval = 0;
	int mdio_addr = CSR(ioaddr,CSR9);

	/* Establish sync by sending at least 32 logic ones. */
	for (i = 32; i >= 0; --i)
	{
		sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1);
		mdio_delay();
		sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1 |
MDIO_SHIFT_CLK);
		mdio_delay();
	}
	/* Shift the read command bits out. */
	for (i = 15; i >= 0; --i)
	{
		int dataval = (read_cmd & (1 << i)) ? MDIO_DATA_WRITE1 : 0;

		sysOutLong(mdio_addr,MDIO_ENB | dataval);
		mdio_delay();
		sysOutLong(mdio_addr,MDIO_ENB | dataval | MDIO_SHIFT_CLK);
		mdio_delay();
	}
	/* Read the two transition, 16 data, and wire-idle bits. */
	for (i = 19; i > 0; --i)
	{
		sysOutLong(mdio_addr,MDIO_ENB_IN);
		mdio_delay();
		retval = (retval << 1) | ((sysInLong(mdio_addr) &
MDIO_DATA_READ) ? 1 : 0);
		sysOutLong(mdio_addr,MDIO_ENB_IN | MDIO_SHIFT_CLK);
		mdio_delay();
	}
	return (retval>>1) & 0xffff;
}

static void mdio_write(int ioaddr, int phy_id, int location, int value)
{
	int i;
	int cmd = (0x5002 << 16) | (phy_id << 23) | (location<<18) | value;
	int mdio_addr = CSR(ioaddr,CSR9);

	/* Establish sync by sending 32 logic ones. */
	for (i = 32; i >= 0; i--)
	{
		sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1);
		mdio_delay();
		sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1 |
MDIO_SHIFT_CLK);
		mdio_delay();
	}
	/* Shift the command bits out. */
	for (i = 31; i >= 0; i--)
	{
		int dataval = (cmd & (1 << i)) ? MDIO_DATA_WRITE1 : 0;
		sysOutLong(mdio_addr,MDIO_ENB | dataval);
		mdio_delay();
		sysOutLong(mdio_addr,MDIO_ENB | dataval | MDIO_SHIFT_CLK);
		mdio_delay();
	}
	/* Clear out extra bits. */
	for (i = 2; i > 0; i--)
	{
		sysOutLong(mdio_addr,MDIO_ENB_IN);
		mdio_delay();
		sysOutLong(mdio_addr,MDIO_ENB_IN | MDIO_SHIFT_CLK);
		mdio_delay();
	}
	return;
}
/* End functions borrowed from Linux */


/*******************************************************************************
*
* dcattach - publish the `dc' network interface.
*
* This routine publishes the `dc' interface by filling in a network interface
* record and adding this record to the system list.  This routine also
* initializes the driver and the device to the operational state.
*
* The <unit> parameter is used to specify the device unit to initialize.
*
* The <devAdrs> is used to specify the I/O address base of the device.
*
* The <ivec> parameter is used to specify the interrupt vector associated
* with the device interrupt.
*
* The <ilevel> parater is used to specify the level of the interrupt which
* the device would use.
*
* The <memAdrs> parameter can be used to specify the location of the
* memory that will be shared between the driver and the device.  The value
* NONE is used to indicate that the driver should obtain the memory.
*
* The <memSize> parameter is valid only if the <memAdrs> parameter is not
* set to NONE, in which case <memSize> indicates the size of the
* provided memory region.
*
* The <memWidth> parameter sets the memory pool's data port width (in bytes);
* if it is NONE, any data width is used.
*
* The <pciMemBase> parameter defines the main memory base as seen from PCI bus.
*
* The <dcOpMode> parameter defines the mode in which the device should be
* operational.
*
* RCP:  Added for DEC21140 Serial ROM
*
* BUGS
* To zero out LANCE data structures, this routine uses bzero(), which
* ignores the <memWidth> specification and uses any size data access to
* write to memory.
*
* RETURNS: OK or ERROR.
*/

STATUS dcattach
    (
    int		unit,		/* unit number */
    ULONG	devAdrs,	/* LANCE I/O address */
    int		ivec,		/* interrupt vector */
    int		ilevel,		/* interrupt level */
    char *	memAdrs,	/* address of memory pool (-1 = malloc it) */
    ULONG	memSize,	/* only used if memory pool is NOT malloc()'d */
    int		memWidth,	/* byte-width of data (-1 = any width) */
    ULONG	pciMemBase,	/* main memory base as seen from PCI bus */
    int		dcOpMode	/* mode of operation */
    )
    {
    DRV_CTRL *		pDrvCtrl;	/* pointer to drvctrl */
    unsigned int	sz;		/* temporary size holder */
    char *		pShMem;		/* start of the LANCE memory pool */
    char *		buf;		/* temp buffer pointer */
    void *		pTemp;		/* temp pointer */
    DC_RDE *		rmd;		/* pointer to rcv descriptor */
    DC_TDE *		tmd;		/* pointer to xmit descriptor */
    int			ix;		/* counter */
/* RCP: Added temporary value */
    ULONG		uTemp;		/* temporary storage */

    /* Sanity check the unit number */
    if (unit < 0 || unit >= MAX_UNITS)
        return (ERROR);

    /* Ensure single invocation per system life */

    pDrvCtrl = & drvCtrl [unit];

    if (pDrvCtrl->attached)
        return (OK);

    pDrvCtrl->ivec	= ivec;			/* interrupt vector */
    pDrvCtrl->ilevel	= ilevel;		/* interrupt level */
    pDrvCtrl->devAdrs	= devAdrs;		/* LANCE I/O address */
    pDrvCtrl->pciMemBase  = pciMemBase;		/* pci memory base */
    pDrvCtrl->memWidth 	= memWidth;		/* memory width */
    pDrvCtrl->dcOpMode	= dcOpMode;		/* mode of operation */

    /* Publish the interface data record */

    ether_attach (
		  & pDrvCtrl->idr.ac_if,
		  unit,
		  "dc",
		  (FUNCPTR) NULL,
		  (FUNCPTR) dcIoctl,
		  (FUNCPTR) dcOutput,
		  (FUNCPTR) dcReset
		 );

    /* Create the transmit semaphore. */

    if ((pDrvCtrl->TxSem = semMCreate (SEM_Q_PRIORITY | SEM_DELETE_SAFE |
				       SEM_INVERSION_SAFE)) == NULL)
        {
        printf ("dc: error creating transmitter semaphore\n");
        return (ERROR);
        }

    /* Establish size of shared memory region we require */

    if ((int) memAdrs != NONE)  /* specified memory pool */
	{
	sz  = (memSize - (RMD_SIZ + TMD_SIZ + (dcLPool * DC_BUFSIZ) +
			  FLTR_FRM_SIZE))
	      / ((2 * DC_BUFSIZ) + RMD_SIZ + TMD_SIZ);
	dcNumRds = max (sz, MIN_RDS);
	dcNumTds = max (sz, MIN_TDS);
	}

    /* add it all up - allow for alignment adjustment */

    sz = ((dcNumRds + 1) * RMD_SIZ) + (dcNumRds * DC_BUFSIZ) +
	 ((dcNumTds + 1) * TMD_SIZ) + (dcNumTds * DC_BUFSIZ) +
	 (DC_BUFSIZ * dcLPool) + FLTR_FRM_SIZE;

    /* Establish a region of shared memory */

    /* OK. We now know how much shared memory we need.  If the caller
     * provides a specific memory region, we check to see if the provided
     * region is large enough for our needs.  If the caller did not
     * provide a specific region, then we attempt to allocate the memory
     * from the system, using the cache aware allocation system call.
     */

    switch ( (int) memAdrs )
        {
        default :       /* caller provided memory */
            if ( memSize < sz )     /* not enough space */
                {
                printf ( "dc: not enough memory provided\n" );
                return ( ERROR );
                }
            pShMem = memAdrs;             /* set the beginning of pool */

            /* assume pool is cache coherent, copy null structure */

            pDrvCtrl->cacheFuncs = cacheNullFuncs;

            break;

        case NONE :     /* get our own memory */

            /* Because the structures that are shared between the device
             * and the driver may share cache lines, the possibility exists
             * that the driver could flush a cache line for a structure and
             * wipe out an asynchronous change by the device to a neighboring
             * structure. Therefore, this driver cannot operate with memory
             * that is not write coherent.  We check for the availability of
             * such memory here, and abort if the system did not give us what
             * we need.
             */

            if (!CACHE_DMA_IS_WRITE_COHERENT ())
                {
                printf ( "dc: device requires cache coherent memory\n" );
                return (ERROR);
                }

            pShMem = (char *) cacheDmaMalloc ( sz);

            if ((int)pShMem == NULL)
                {
                printf ( "dc: system memory unavailable\n" );
                return (ERROR);
                }

            /* copy the DMA structure */

            pDrvCtrl->cacheFuncs = cacheDmaFuncs;

            break;
        }

    if (intConnect ((VOIDFUNCPTR *)INUM_TO_IVEC(ivec),dcInt,(int)pDrvCtrl)
        == ERROR)
        return (ERROR);

    /*                        Turkey Carving
     *                        --------------
     *
     *                          LOW MEMORY
     *             |-------------------------------------|
     *             |         The Rx descriptors          |
     *             | (dcNumRds * sizeof (DC_RDE))        |
     *             |-------------------------------------|
     *             |          The receive buffers        |
     *             |       (DC_BUFSIZ * dcNumRds)        |
     *             |-------------------------------------|
     *             |         The Rx loaner pool          |
     *             |        (DC_BUFSIZ * dcLPool)        |
     *             |-------------------------------------|
     *             |         The Tx descriptors          |
     *             | (dcNumTds *  sizeof (DC_TDE))       |
cont next messg

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: DEC 21140 driver on pc486: some fixes
Date: Mon, 14 Dec 1998 18:06:47 GMT
From: david.hagood@ifrsys.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <753k3l$aht$1@nnrp1.dejanews.com>
References: <366E73A6.32FD2550@sktc.net>

<cont from prev msg 2>

/*******************************************************************************
*
* dcEnetAddrGet - gets the ethernet address from the ROM register.
*
* This routine gets the ethernet address from the ROM register.
* This routine returns the ethernet address into the pointer supplied to it.
*
* RETURNS: OK/ERROR
*/

LOCAL STATUS dcEnetAddrGet
    (
    ULONG	devAdrs,	/* device base I/O address */
    char * 	enetAdrs,	/* pointer to the ethernet address */
    int		len		/* number of bytes to read */
    )
    {
    FAST ULONG	csr9Value;		/* register to hold CSR9 */
    int		ix;			/* index register */
    BOOL	eRomReady = FALSE;	/* ethernet ROM register state */

    dcCsrWrite (devAdrs, CSR9, 0);	/* reset rom pointer */

    while (len > 0)
	{
	for (ix = 0; ix < 10; ix++)	/* try at least 10 times */
	    {
	    if ((csr9Value = dcCsrRead (devAdrs, CSR9)) & CSR9_DNV)
		{
		eRomReady = FALSE;
	    	DELAY(500);
		}
	    else
		{
		*enetAdrs++ = (UCHAR) csr9Value;
		len--;
		eRomReady = TRUE;
		break;
		}
	    }
	}

    if (!eRomReady)
    	return (ERROR);
    else
	return (OK);
    }

/*******************************************************************************
*
* RCP : New utility for DEC21140
* dc21140EnetAddrGet - gets the ethernet address from the ROM register
*
* This routine gets the last two bytes of the ethernet address from the ROM
* register and concantenates this value to the predefined values for DEC PMCs..
* This routine returns the ethernet address into the pointer supplied to it.
*
* The procedure could be expanded in the future to allow for modification of
* Ethernet addresses in the serial ROM.  It will have to be modified to
* accomodate the differences in the onboard 100Mb/s ethernet on future
* Motorola products.
*
* RETURNS: OK/ERROR
*/

LOCAL STATUS dc21140EnetAddrGet
    (
    ULONG	devAdrs,	/* device base I/O address */
    char * 	enetAdrs,	/* pointer to the ethernet address */
    int		len		/* number of bytes to read */
    )
    {
    int		i,ix,		/* index register */
    		tmpInt;		/* temporary int */
    union mixed
    {
    	char	Char[4];	/* temporary 2 by char */
	USHORT	Short[2];	/* temporary USHORT */
    } tmp;

    for (i = DEC_PMC_POS, ix = 0; i<(3+DEC_PMC_POS); i++, ix++)
    {
    	if ((tmp.Short[0] = dcReadRom (devAdrs, i)) == (USHORT)ERROR)
	   return (ERROR);
#if (_BYTE_ORDER == _BIG_ENDIAN)
	enetAdrs[ix++] = tmp.Char[1];
	enetAdrs[ix]   = tmp.Char[0];
#else
	enetAdrs[ix++] = tmp.Char[0];
	enetAdrs[ix]   = tmp.Char[1];
#endif
    }
    tmpInt = -1;
    return (OK);
    }


/*******************************************************************************
*
* dcFltrFrmXmit - Transmit the setup filter frame.
*
* This routine transmits the setup filter frame.
* The setup frame is not transmitted actually over the wire. The setup frame
* which is transmitted is 192 bytes. The tranmitter should be in an on state
* before this function is called. This call has been coded so that the
* setup frame can be transmitted after the chip is done with the
* intialization taking into consideration for adding multicast support.
*
* RETURNS: OK/ERROR
*/

LOCAL int dcFltrFrmXmit
    (
    DRV_CTRL *	pDrvCtrl, 	/* pointer to device control structure */
    char * 	pPhysAdrsTbl, 	/* pointer to physical address table */
    int 	tblLen		/* size of the physical address table */
    )
    {
    volatile DC_TDE *	tmd;		/* pointer to Tx ring descriptor */
    ULONG * 	pBuff;		/* pointer to the Xmit buffer */
    int		status = OK;	/* intialize status as OK */
    ULONG	csr7Val;	/* value in CSR7 */
    semTake (pDrvCtrl->TxSem, WAIT_FOREVER);

    if (dcFltrFrmSetup (pDrvCtrl, pPhysAdrsTbl, tblLen) != OK)
	{
	status = ERROR;		/* not able to set up filter frame */
	goto setupDone;		/* set up done */
	}

    /* See if next TXD is available */

    tmd = pDrvCtrl->txRing + pDrvCtrl->txIndex;

    DC_CACHE_INVALIDATE (tmd, TMD_SIZ);

    if  (
        ((tmd->tDesc0 & PCISWAP(TDESC0_OWN)) != 0) ||
        (
        ((pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds) == pDrvCtrl->txDiIndex
	)
        )
	{
	status = ERROR;		/* not able to set up filter frame */
	goto setupDone;		/* set up done */
	}

    /* Get pointer to transmit buffer */

    pBuff = DC_CACHE_PHYS_TO_VIRT(PCI_TO_MEM_PHYS(PCISWAP(tmd->tDesc2)));

    /* copy into Xmit buffer */

    bcopyLongs ((char *)pDrvCtrl->pFltrFrm, (char *)pBuff,
		FLTR_FRM_SIZE_ULONGS);

    tmd->tDesc0 = 0;				/* clear buffer error status */
    tmd->tDesc1 |= PCISWAP(TDESC1_SET);		/* frame type as set up */
    tmd->tDesc1 &= PCISWAP(~TDESC1_TBS1_MSK);
    tmd->tDesc1 |= PCISWAP(TDESC1_TBS1_PUT(FLTR_FRM_SIZE));
    tmd->tDesc0 = PCISWAP(TDESC0_OWN); 		/* give ownership to device */

    CACHE_PIPE_FLUSH ();			/* Flush the write pipe */

    /* Advance our management index */

    pDrvCtrl->txIndex   = (pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds;
    pDrvCtrl->txDiIndex = (pDrvCtrl->txDiIndex + 1) % pDrvCtrl->dcNumTds;

    csr7Val = dcCsrRead (pDrvCtrl->devAdrs, CSR7);

    dcCsrWrite(pDrvCtrl->devAdrs, CSR7, 0);	/* mask interrupts */

    if (dcKickStartTx)
    {

    	dcCsrWrite(pDrvCtrl->devAdrs, CSR1, CSR1_TPD);	/* xmit poll demand */
    }

    /* wait for the own bit to change */
    while (tmd->tDesc0 & PCISWAP (TDESC0_OWN))
    {
    }

    tmd->tDesc0 = 0;				/* clear status bits */
    tmd->tDesc1 &= PCISWAP(~TDESC1_SET);

    dcCsrWrite(pDrvCtrl->devAdrs, CSR7, csr7Val); /* restore value */

    setupDone:

    /* Release exclusive access. */

    semGive (pDrvCtrl->TxSem);

    return (status);
    }

/*******************************************************************************
*
* dcFltrFrmSetup - set up the filter frame.
*
* This routine sets up the filter frame to filter the physical addresses
* on the incoming frames. The setup filter frame buffer is 192 bytes. This
* setup frame needs to be transmitted before transmitting and receiving
* any frames.
*
* RETURNS: OK/ERROR
*/

LOCAL int dcFltrFrmSetup
    (
    DRV_CTRL *	pDrvCtrl, 	/* pointer to device control structure */
    char * 	pPhysAdrsTbl, 	/* pointer to physical address table */
    int 	tblLen		/* size of the physical address table */
    )
    {
    int		ix;		/* index variable */
    int		jx; 		/* inner index variable */
    ULONG *	pFltrFrm;	/* pointer to the filter frame */
    USHORT *	pPhysAddrs;	/* pointer to the physical addresses */

    if (tblLen > FLTR_FRM_ADRS_NUM)
	return (ERROR);

    pFltrFrm = pDrvCtrl->pFltrFrm;

    for (ix = 0; ix < FLTR_FRM_SIZE_ULONGS; ix++)
	*pFltrFrm++ = FLTR_FRM_DEF_ADRS;

    pFltrFrm = pDrvCtrl->pFltrFrm;
    pPhysAddrs = (USHORT *) (pPhysAdrsTbl);

    for (ix = 0; ix < tblLen; ix++)
	{
	for (jx = 0; jx < (FLTR_FRM_ADRS_SIZE/sizeof (USHORT)); jx++)
	    {
#if (_BYTE_ORDER == _BIG_ENDIAN)
	    *pFltrFrm =  (*pPhysAddrs << 16);
#else
	    *pFltrFrm = *pPhysAddrs;
#endif
	    pPhysAddrs++;
	    pFltrFrm++;
	    }
	}
    return (OK);
    }

#include "sys/socket.h"

/*******************************************************************************
*
* convertDestAddr - converts socket addr into enet addr and packet type
*
*/

LOCAL BOOL convertDestAddr
    (
    IDR *pIDR,                          /* ptr to i/f data record */
    SOCK *pDestSktAddr,                 /* ptr to a generic sock addr */
    char *pDestEnetAddr,                /* where to write enet addr */
    u_short *pPacketType,               /* where to write packet type */
    MBUF *pMbuf                         /* ptr to mbuf data */
    )
    {

    /***** Internet family *****/

    {
    struct in_addr destIPAddr;              /* not used */
    int trailers;                           /* not supported */

     if (pDestSktAddr->sa_family == AF_INET)
        {
        *pPacketType = ETHERTYPE_IP;            /* stuff packet type */
        destIPAddr = ((struct sockaddr_in *) pDestSktAddr)->sin_addr;

        if (!arpresolve (pIDR, pMbuf, &destIPAddr, pDestEnetAddr, &trailers))
            return (FALSE);     /* if not yet resolved */

        return (TRUE);
        }
    }


    /***** Generic family *****/

    {
    ENET_HDR *pEnetHdr;

  if (pDestSktAddr->sa_family == AF_UNSPEC)  {	pEnetHdr = (ENET_HDR *)
pDestSktAddr->sa_data;	/* ptr to hdr */  bcopy (pEnetHdr->dst,
pDestEnetAddr, 6);  /* copy dst addr */  *pPacketType = pEnetHdr->type;  /*
copy type */  return (TRUE);  }  }


    /* Unsupported family */

    return (FALSE);

    } /* End of convertDestAddr() */

/* END OF FILE */


/*******************************************************************************
*
* RCP : New utility for DEC21140
* dcReadRom - reads an specified entry in the Serial ROM
*
* This routine uses the line number passed to the function and returns
* the two bytes of information that is associated with it.  This will later
* be used by the dc21140GetEthernetAdr function.  It can also be used to
* review the ROM contents itself.
*
* The function must first send some initial bit paterns to the CSR9 which
* contains the Serial ROM Control bits.  Then the line index into the ROM
* will be evaluated bit by bit to program the ROM.  The 2 bytes of data
* will be extracted and processed into a normal pair of bytes.
*
* RETURNS: Short Value in ROM/ERROR
*/

#define BASE CSR9_SSR_FLAG|CSR9_SWO_FLAG

USHORT dcReadRom
    (
    ULONG	devAdrs,	/* device base I/O address */
    UCHAR	lineCnt 	/* Serial ROM line Number */
    )
    {
    int		ix, 			/* index register */
    		intCnt;		/* address loop count */
    USHORT	tmpShort;
    ULONG	tmpLong;

/* Is the line offset valid, and if so, how large is it */

    if (lineCnt > SROM_SIZE)
    {
	printf ("dcReadRom FAILED, bad lineCnt\n");
    	return (ERROR);
    }
    if (lineCnt < 64)
    {
	intCnt = 6;
	lineCnt = lineCnt << 2;  /* Prepare lineCnt for processing */
    }
    else
	intCnt = 8;

/* Command the Serial ROM to the correct Line */

/* Preamble of Command */
    dcCsrWrite (devAdrs, CSR9, 0x00000000|BASE);	/* Command 1 */
    NSDELAY (30);

    dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE);	/* Command 2 */
    NSDELAY (50);
    dcCsrWrite (devAdrs, CSR9, 0x00000003|BASE);	/* Command 3 */
    NSDELAY (250);
    dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE);	/* Command 4 */
    NSDELAY (100);


/* Command Phase */

    dcCsrWrite (devAdrs, CSR9, 0x00000005|BASE);	/* Command 5 */
    NSDELAY (150);
    dcCsrWrite (devAdrs, CSR9, 0x00000007|BASE);	/* Command 6 */
    NSDELAY (250);
    dcCsrWrite (devAdrs, CSR9, 0x00000005|BASE);	/* Command 7 */
    NSDELAY (250);
    dcCsrWrite (devAdrs, CSR9, 0x00000007|BASE);	/* Command 8 */
    NSDELAY (250);
    dcCsrWrite (devAdrs, CSR9, 0x00000005|BASE);	/* Command 9 */
    NSDELAY (100);
    dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE);	/* Command 10 */
    NSDELAY (150);
    dcCsrWrite (devAdrs, CSR9, 0x00000003|BASE);	/* Command 11 */
    NSDELAY (250);
    dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE);	/* Command 12 */
    NSDELAY (100);

/* Address Phase */

    for (ix=0; ix < intCnt; ix++)
    {
	tmpLong = (lineCnt & 0x80)>>5;	/* Extract and move bit to bit 3) */
/* Write the command */
    	dcCsrWrite (devAdrs, CSR9, tmpLong | 0x00000001|BASE);/* Command 13 */
    	NSDELAY (150);
    	dcCsrWrite (devAdrs, CSR9, tmpLong | 0x00000003|BASE);/* Command 14 */
    	NSDELAY (250);
    	dcCsrWrite (devAdrs, CSR9, tmpLong | 0x00000001|BASE);/* Command 15 */
    	NSDELAY (100);

	lineCnt = lineCnt<<1;  /* Adjust significant address bit */
    }

    	NSDELAY (150);

/* Data Phase */

    tmpShort =0;
    for (ix=15; ix >= 0; ix--)
    {
/* Write the command */
    	dcCsrWrite (devAdrs, CSR9, 0x00000003|BASE);		/* Command 16 */
    	NSDELAY (100);
/* Extract the data */
    	tmpShort |= (((dcCsrRead (devAdrs, CSR9) & 0x00000008)>>3)
		   <<ix); 				/* Command 17 */
    	NSDELAY (150);
    	dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE);		/* Command 18 */
    	NSDELAY (250);

    }

/* Finish up command */
    dcCsrWrite (devAdrs, CSR9, 0x00000000);	/* Command 19 */
    NSDELAY (100);

    return (tmpShort);
    }

/* RCP: Function to read all of serial rom and store the data in the
        data structure passed to the function.  The count value will
        indicate how much of the serial rom to read.  The routine with also
        swap the the bytes as the come in. */

void dcReadAllRom
    (
    ULONG	devAdrs,	/* device base I/O address */
    UCHAR	*buffer,	/* destination bufferr */
    int		cnt             /* Amount to extract in bytes */
    )
    {

    USHORT total, index;
    union tmp_type {
        USHORT Short;
    	char   Byte [2];	/* temporary 2 by char */
    } tmp;

    total = 0;
    for (index=0, total=0; total < cnt/2; index+=2, total++)
    {
	tmp.Short = dcReadRom (devAdrs, total);
	buffer[index]=tmp.Byte[1];
	buffer[index+1]=tmp.Byte[0];
    }
    }

#ifdef DC_DEBUG

int dcViewRom
    (
    ULONG	devAdrs,	/* device base I/O address */
    UCHAR	lineCnt,	/* Serial ROM line Number */
    int		cnt             /* Amount to display */
    )
    {

    USHORT total;
    union tmp_type {
        USHORT Short;
    	char   Byte [2];	/* temporary 2 by char */
    } tmp;


    if (lineCnt/2 < 0 || lineCnt/2 > SROM_SIZE)
	return (ERROR);

    total = 0;
    while (lineCnt/2 < SROM_SIZE && cnt > 0)
    {
	if (!(total%16))
	   printf ("\nValues for line %2d =>0x  ", total);
	tmp.Short = dcReadRom (devAdrs, lineCnt);
	printf ("%4x ",tmp.Short);
	lineCnt++ ;
	total +=2;
	cnt -=2;
    }
    printf ("\n");
    return (total);
    }


void dcCsrShow
    (
    ULONG devAdrs
    )
    {
    printf ("\n");
    printf ("CSR0\t 0x%x\n", dcCsrRead(devAdrs, CSR0));
    printf ("CSR1\t 0x%x\n", dcCsrRead(devAdrs, CSR1));
    printf ("CSR2\t 0x%x\n", dcCsrRead(devAdrs, CSR2));
    printf ("CSR3\t 0x%x\n", dcCsrRead(devAdrs, CSR3));
    printf ("CSR4\t 0x%x\n", dcCsrRead(devAdrs, CSR4));
    printf ("CSR5\t 0x%x\n", dcCsrRead(devAdrs, CSR5));
    printf ("CSR6\t 0x%x\n", dcCsrRead(devAdrs, CSR6));
    printf ("CSR7\t 0x%x\n", dcCsrRead(devAdrs, CSR7));
    printf ("CSR8\t 0x%x\n", dcCsrRead(devAdrs, CSR8));
    printf ("CSR9\t 0x%x\n", dcCsrRead(devAdrs, CSR9));
    printf ("CSR10\t 0x%x\n", dcCsrRead(devAdrs, CSR10));
    printf ("CSR11\t 0x%x\n", dcCsrRead(devAdrs, CSR11));
    printf ("CSR12\t 0x%x\n", dcCsrRead(devAdrs, CSR12));
    printf ("CSR13\t 0x%x\n", dcCsrRead(devAdrs, CSR13));
    printf ("CSR14\t 0x%x\n", dcCsrRead(devAdrs, CSR14));
    printf ("CSR15\t 0x%x\n", dcCsrRead(devAdrs, CSR15));

    }
#endif /* DC_DEBUG */

/*  RCP:  New Versions of code that will be added to the BSP later. */
/****************************************************************************
** * * sysLanIntEnable - enable the LAN interrupt * * This routine enables
interrupts at a specified level for the on-board * LAN chip.  LAN interrupts
are controlled by the IBC chip. * The LANCE chip on this board is on the PCI
bus. The PCI interrupts should * be routed through the IBC to the processor.
LANCE chip asserts PCI IRQ0 * which has to be routed through IBC to generate
ISA IRQ10. This routing * done through programming the PCI route registers in
the IBC chip. * * RETURNS: OK, always. * * SEE ALSO: sysLanIntDisable() */

STATUS sysLanIntEnable
    (
     int intLevel 		/* interrupt level to enable */
    )
    {
    sysIntEnablePIC (intLevel);
    return (OK);
    }

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.arch.embedded,comp.os.vxworks,comp.sys.m68k,comp.sys.powerpc.tech
Subject: Re: MPC860 chip select & cache problems
Date: Tue, 15 Dec 1998 11:37:26 +1100
From: Tom Evans <nobody@nowhere.tennyson.com.au>
Organization: OzEmail Ltd.
Message-ID: <3675AB2C.54F6@nowhere.tennyson.com.au>
References: <01be1f17$2c190a60$a1b975c0@euronet.euronet> <36680FE4.CB0BAC46@lucent.com> <74hppu$afb@hoax.cse.tek.com> <F3nzv0.3Jo.7.denx@denx.muc.de> <753et4$7c0$1@nntp3.uunet.ca>

mdapoz@cambriansys.com wrote:
 
> Both data and instruction caches are broken in Rev B parts.  Besides
> the Motorola documented cache problems, there is a new problem with
> the instruction cache.  It appears that if the instruction cache is
> enabled and an exception occurs (eg. the decrementer goes off) during
> branch prediction, occasionaly the instructions are not restarted properly.
> The problem only occurs in Rev B parts and appears to be fixed in Rev C.
> Below is a test case that I've come up with which demonstrates the problem.
> I'll be submitting this to Motorola once I figure out where to send it.

    http://www.mot-sps.com/sps/General/feedback.html

Don't paste too much into the "Message or Question" box. I've had
trouble
with these systems before (Scientific American blows up at about 500
bytes).

You'll get an "Issue Reference Number", which you have to use in
subsequent
correspondence.

Let us know what happens.

Tom Evans
initialSurname@somewhere

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

Newsgroups: comp.os.vxworks
Subject: Re: Looking for 860SAR ATM driver for VxWorks ??
Date: Mon, 14 Dec 1998 22:14:49 GMT
From: newsmine@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <7542km$o27$1@nnrp1.dejanews.com>
References: <36751F02.B7B97050@cselt.it>

Hi Achille,

There are a few companies in North America that I have come across that
specifically work in this area:

1.Inverness : http://www.invernessinc.com
2.Trillium  : http://www.trillium.com
3.Harris & Jeffries : http://www.hjinc.com

There are also the traditional networking equipment companies that deal with
end-to-end ATm systems : cisco, newbridge, nortel and lucent to name a few.

In Germany, you may want to try Cellware at (I think) www.cellware.de.

Mittal


In article <36751F02.B7B97050@cselt.it>,
  Achille Montanaro <Achille.Montanaro@cselt.it> wrote:
> Hi,
> I'm going to use the PowerPC860SAR which includes an ATM controller with
> UTOPIA interface.
> I'm looking for VxWorks drivers which support Lan Emulation and/or
> Classical IP Over ATM.
> Could anyone give me information about where I can find those drivers ?
> Thanks in advance
>
>


- --
Mittal Monani
Spacebridge Networks Corporation  Hull J8X 3R1

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: large files and rawFs ?
Date: 14 Dec 1998 14:39:31 -0800
From: nigel@idiom.com (Nigel Standing)
Organization: Idiom
Message-ID: <754433$2ud$1@idiom.com>

Have a project which is currently using rawFs to access disk data
which is less than LONG_MAX in size, but there is a new requirement
to modify the system to handle data greater than LONG_MAX in size
(well large disks are cheap these days :-)

My question, has anyone attempted this ?

My initial idea was just to use multiple seeks to overcome the
limitation of the "long offset". But then realized that if rawFs
doesn't keep track of byte positions greater than LONG_MAX, then
it wouldn't work.

Thanks for any help,

Nigel -

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

Newsgroups: comp.os.vxworks
Subject: Strange behaviour with global variable : have you seen it before?
Date: Mon, 14 Dec 1998 22:36:22 GMT
From: newsmine@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <7543t6$p8p$1@nnrp1.dejanews.com>

Hi VxGurus,

While doing some simple timer-driven code on VxWorks, I saw the following
strange behaviour. Here's what I have : Tornado on Nt 4.0, VxWorks 5.3.1,
gcc 2.7.2 and a PPC860 board. My compilation flags are

- -BC:\Tornado/host/x86-win32/lib/gcc-lib/
- -mcpu=860
- -ansi
- -nostdinc
- -O2
- -fvolatile
- -f no-builtin
- -fno-for-scope
- -Wall
- -I/h -IC:\Tornado/host/include -IC:\Tornado\target\config\all -IC:
\Tornado\target/h -IC:\Tornado\target/src/config -IC:\Tornado\target/src/drv
- -DCPU=PPC860

A global variable called count that is increased each time a timer interrupted
function is run. However, this changed value is not always reflected in other
functions. Here are the three scenarios


int Count;

void
RxFunc (char * SomePtr)

{
/* This function is connected to an external timer and runs every 0.5 second
   Count is increrased each time
*/

    logMsg ("Mittal After msg rx count %d message %s\n", Count++,
            (int)SomePtr,0,0,0,0);
}

I tried each of the following functions with RxFunc one at a time. Ran them
from the shell as ->sp TaskInit

Flavor 1
~~~~~~~~
void
TaskInit ()
{

    while (Count < 5 );
    printf ("After while loop\n"); <----- I never reach this line. Count keeps
                                          increasing beyond 5.
}


Flavor 2
~~~~~~~~
void
TaskInit ()
{

    while (Count < 5 )
    {
        if (Count >=5) break;
    }
    printf ("After while loop\n"); <----- I still never reach this line. Count
                                          still keeps going up.
}

Flavor 3
~~~~~~~~

void
TaskInit ()
{

    while (Count < 5 )
    {
        logmsg ("Inside while : count %d\n", Count,0,0,0,0,0);
    }
    printf ("After while loop\n"); <----- Now I reach here!!.
}


I am really confused by this strange behaviour. Am I doing somethin wrong or
is this a bug in gcc or VxWorks? Is there some wierd compiler optimization
going on here?

I'll really appreciate your experience on anything like this.

Thanks,
Mittal
- --
Mittal Monani
Spacebridge Networks Corporation  Hull J8X 3R1

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: Re: Tornado + Version Control integration
Date: Wed, 16 Dec 1998 18:01:04 -0800
From: Matthew Downs <mdowns@ada.com>
Organization: Another Netscape Collabra Server User
Message-ID: <367865E0.34EB0D02@ada.com>
References: <36784811.108860281@news.phoenix.net>

Peter Weatherall wrote:

> Has anyone integrated Tornado with a source code version control
> system ? Some IDEs have this built-in. Any ideas about what is the
> best approach with Tornado...
>
> Thanks
> Peter

I 've done it, but you don't want to......Unfiortunately, the concept of
source control is a foreign idea to those that make the product.
Actually, I shouldn't say that, but it seems like it is true. My main
suggestion is to put the entire tree under control and replicate it
where necessary.

DON'T use PVCS, if you are, I'm sorry.

Matt


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

Newsgroups: comp.os.vxworks
Subject: PERL on VxWorks?
Date: Thu, 17 Dec 1998 14:16:29 +1100
From: "Breck Thomas" <wtf@posnet.com.au>
Organization: OzEmail Ltd.
Message-ID: <759son$vd6$1@reader1.reader.news.ozemail.net>

Hi,
    Does anyone know if PERL 5 will run on VxWorks.

I have contacted Wind River and had no response yet.

Please send replies to breck@posnet.com.au


Thanks in advance

- --
Breck



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

Newsgroups: comp.os.vxworks
Subject: Re: Build Output Requires Prompting?
Date: Wed, 16 Dec 1998 21:06:53 -0700
From: Michael Oehrli <oehrli@usa.net>
Organization: Raytheon Optical Systems, Inc.
Message-ID: <3678835D.A33C412@usa.net>
References: <36704BD9.E91CCF8D@americasm01.nt.com>

Tim Sohacki wrote:

> We recently installed Tornado 1.0.1 on a particular Win 95 PC.
>
> If I try to build the BSP with:
>    Project->Make MV1603->Common Targets->vxWorks
>
> something very odd occurs ... a build output window appears,
> but it has no output.  Pressing a key on the keyboard results
> in the first command (say ccppc) executing.  Each command
> must be prompted in a similar manner.
>
> The same thing occurs if you use a default generated
> Wind River Makefile on your own "Hello world!" program,
> or one of our application programs.
>
> However, the demo builds without prompting using the Makefile at:
>    $WIND_BASE/target/src/demo/color/Makefile ...
>
> Any suggestions?  Has anyone encountered anything like this?
> All other PC installations work okay (though not as well as
> our Unix installations).
>
> Cheers,
> Tim
>
> --
> Tim Sohacki, Nortel Networks
> email: sohacki@nortelnetworks.com

I recently installed VxWorks on a Win95 machine.  However, the first
thing I did was "Configured BSP."  I believe it's a selection under one
of the menus.  You are then thrown into WindConfig which lets you select
the various components to add or you can just select the defaults.  Then
you must save the configuration and afterwards build it.


- --
Michael Oehrli
Senior Software Engineer
Raytheon Optical Systems, Inc.
http://wwp.mirabilis.com/10888574




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

Newsgroups: comp.os.vxworks
Subject: Re: Strange behaviour with global variable : have you seen it before?
Date: Tue, 15 Dec 1998 05:49:42 GMT
From: john@kivala.com
Organization: Kivala Systems, Inc.
Message-ID: <754t9l$ejc$1@nnrp1.dejanews.com>
References: <7543t6$p8p$1@nnrp1.dejanews.com>

In article <7543t6$p8p$1@nnrp1.dejanews.com>,
  newsmine@my-dejanews.com wrote:
> Hi VxGurus,
>
> While doing some simple timer-driven code on VxWorks, I saw the following
> strange behaviour. Here's what I have : Tornado on Nt 4.0, VxWorks 5.3.1,
> gcc 2.7.2 and a PPC860 board. My compilation flags are
...edit
> int Count;
...

My guess is that "int Count" wants to be "volatile int Count".
The compiler might be sticking it in a register and never
re-getting it from memory, unless you have a "sufficiently
complicated" line of code between uses of Count (case 3).

This is not too hard to check:
objdumpppc --disassemble file.o > file.lst
(A reading knowledge of any given assembly language is far
easier than a writing knowledge thereof.)

If this is what's happening, and maybe even if it's not, the
lesson is that if you have any variables shared by more than
one task (or isr), then they should be volatile, since you
don't (in general) know when task A is going to switch out
and task B is going to switch in. This is a different kind
of protection than that achieved by intLock, taskLock, or
a semaphore.

John

- --------------------------------------------------
 John Finley                 Kivala Systems, Inc.
 Project Manager                   (619) 689-0032
 john@kivala.com            http://www.kivala.com
- --------------------------------------------------
 VxTool - Build Tornado Apps with MS Visual Basic
- --------------------------------------------------

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: BOOTP / RARP server
Date: Thu, 17 Dec 1998 10:16:54 -0000
From: "Facilities Rolls-Royce" <emtd.derby@dial.pipex.com>
Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom)
Message-ID: <75almq$o2i$1@plug.news.pipex.net>

Does anyone have any experience of running either a BOOTP server or a RARP
(Reverse Address Resolution Protocol) server under VxWorks?

I require it for a pressure measurement system utilising PSI 9016 pressure
"bricks".

The Tornado distribution includes an unsupported CMU bootp server, intended
for the Unix host. Is this a good starting point, or is there somewhere
better to start from.


Paul Tyler
Measurement Systems Specialist
Rolls-Royce E&MT Department Automation Team



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

Newsgroups: comp.os.vxworks
Subject: Re: DMA on MVME2600
Date: 17 Dec 1998 11:13:39 GMT
From: ag@devsoft.devsoft.com (Armin Gruner)
Organization: Customer of SpaceNet GmbH
Message-ID: <slrn77hpra.2p3.ag@devsoft.devsoft.com>
References: <MVnd2.3598$o4.14087066@WReNphoon1>

In article <MVnd2.3598$o4.14087066@WReNphoon1>, Philippe Duhoux wrote:
>Bonjour,
>does someone have experience in DMA transfers on
>MVME2600?
>In my particalar case, I shall transfer CPU data
>from/to an external VME board in A32/D32 space.
>
>Thanks for any hint.
>
>Best regards,
>Philippe
>
>================================================================
>Philippe Duhoux                         Tel: (+49)
>89-3200-6523
>Software Engineer VLT                   Fax: (+49)
>89-3200-6494
>CCD Cameras & Instrument Motors
>Karl-Schwarzschild-Str.2
>European Southern Observatory           D-85748 Munich
>- Germany
>E-Mail : pduhoux@eso.org                WWW
>http://www.eso.org
>================================================================

Hi,
we were in the need for the same thing. I have added a DMA driver
for the Universe chip, though we are using a MVME2700 board. But
I think that makes no difference. 
If you're interested in the source code, get back to me.

Regards
	Armin

- -- 

    Armin Gruner
    Forschung und Entwicklung

- --
Armin Gruner, /dev Software GmbH                        Fon +49-89-286 598 43
Gabelsberger Str. 51                                    mailto:ag@devsoft.com
D-80333 Muenchen                                       http://www.devsoft.com
                                     

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

Newsgroups: comp.os.vxworks
Subject: Re: DMA on MVME2600
Date: 17 Dec 1998 11:15:52 GMT
From: ag@devsoft.devsoft.com (Armin Gruner)
Organization: Customer of SpaceNet GmbH
Message-ID: <slrn77hpva.2p3.ag@devsoft.devsoft.com>
References: <MVnd2.3598$o4.14087066@WReNphoon1>

In article <MVnd2.3598$o4.14087066@WReNphoon1>, Philippe Duhoux wrote:
>Bonjour,
>does someone have experience in DMA transfers on
>MVME2600?
>In my particalar case, I shall transfer CPU data
>from/to an external VME board in A32/D32 space.
>
>Thanks for any hint.
>
>Best regards,
>Philippe
>
>================================================================
>Philippe Duhoux                         Tel: (+49)
>89-3200-6523
>Software Engineer VLT                   Fax: (+49)
>89-3200-6494
>CCD Cameras & Instrument Motors
>Karl-Schwarzschild-Str.2
>European Southern Observatory           D-85748 Munich
>- Germany
>E-Mail : pduhoux@eso.org                WWW
>http://www.eso.org
>================================================================

Hi,
we were in the need for the same thing. I have added a DMA driver
for the Universe chip, though we are using a MVME2700 board. But
I think that makes no difference. 
If you're interested in the source code, get back to me.

Regards
	Armin

- -- 

    Armin Gruner
    Forschung und Entwicklung

- --
Armin Gruner, /dev Software GmbH                        Fon +49-89-286 598 43
Gabelsberger Str. 51                                    mailto:ag@devsoft.com
D-80333 Muenchen                                       http://www.devsoft.com
                                     

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

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


From owner-vxwexplo-process  Thu Dec 17 07:46:19 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Thu Dec 17 07:46:22 PST 1998
Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply -Reply

Carl, Minbo, and whoever else is interested,

This is a tangent to the original question, but the d() command does not necessarily _access_
memory the way you request it to _display_ it.  When I use d() with default nunits and width
parameters to look at memory on the VMEbus with an MVME2700, I see a single-byte access at the
beginning and end of each 16-byte segment (this is vxMemProbe() making sure the memory is
present) followed by four 32-bit accesses.  Memory is displayed in 16-bit units, however, followed
by its ASCII representation.

I guess the point is this:  If you are not looking at well-behaved memory, you can't count on d() to
access it properly.  Use a shell construct such as the following, instead:

    val = (char)*0xffbf6005

By the way:  You need to be careful with the m() command, too, because it reads the memory to
display the current content before you write to it.  If you try to modify a memory location for which an
action is performed if it is read, you will get an unexpected side effect.  I would recommend this
shell construct, instead:

    *0xffbf6005 = (char)val

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com

>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/16/98 06:13pm >>>
Submitted-by owner-vxwexplo-process  Wed Dec 16 16:13:11 1998
Submitted-by: "Carl C. Chesbrough" <carl@themis.com>

Minbo,

You can use the m() function, giving it a parameter of 1 to do 8-bit
access rather than 16-bit accesses.  I thought that the default d()
access was 16-bits.  You can specify the size with the 3rd parameter
to the d() function.

  -> m 0xfbff6005,1

or

  -> d 0xfbff6005, 1, 1
                   ^  ^
    # of bytes ----|  |
    access size ------|

HTH,
-Carl.

********************************************************************
*                                                                  *
* Carl C. Chesbrough              Telephone: (510) 252-0870 x 126  *
* Themis Computer                 Facsimile: (510) 490-5529        *
* 3185 Laurelview Court           E-Mail   : carl@themis.com       *
* Fremont, California 94538                                        *
*                                                                  *
********************************************************************


> The addressing looks fine.  How are you doing your accesses?  The 6005
> address suggests that you are addressing by byte.  If so, your code should
> be doing something equivalent to:
> 
>     someCharVar = *(char *)0xfbff6005;
> 
> (though hopefully more elegantly).  In particular, the d() funciton is
> probably not useful, because it reads from memory 32 bits at a time.  If
> your board does not respond to D32 bus cycles, you get bus errors and
> useless data.
> 
> HTH
> 
> Charlie Grames
> The Boeing Company
> (314) 233-1956
> Charles.R.Grames@boeing.com
> 
> >>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/16/98 12:57pm >>>
> Submitted-by owner-vxwexplo-process  Wed Dec 16 10:56:55 1998
> Submitted-by: "Minbo Shim" <mshim@rst.com>
> 
> Vxworks gurus:
> 
> I have some difficulties to get access to a register in the A16-based
> I/O board. 
> 
> Here is the story. We have an A16-based VMEbus I/O board with short
> addressing map that tells us where to go to see the contents of some
> registers in it. Suppose the local address to one of the registers is
> 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that 
> VME MASTER WINDOW for A16 SPACE is following:
> 
> 	/*
> 	 * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks
> 	 * This maps: MPU RANGE:     0xfbff0000 - 0xfbffffff
> 	 *        to: PCI RANGE:     0xfbff0000 - 0xfbffffff
> 	 *        to: VME RANGE:     0xfbff0000 - 0xfbffffff
> 	 */
> 	#  define VME_A16_MSTR_LOCAL    0xfbff0000
> 	#  define VME_A16_MSTR_SIZE     0x00010000 /* 64K */
> 	#  define VAL_LSI3_BS_VALUE     (VME_A16_MSTR_LOCAL)
> 	
> I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value:
> 
> 	{
> 	(void *) VME_A16_MSTR_LOCAL,
> 	(void *) VME_A16_MSTR_LOCAL,
> 	VME_A16_MSTR_SIZE,
> 	VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE |
VM_STATE_MASK_CACHEABLE,
> 	VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
> 	},
> 
> However, every try to get access to "0xfbff6005" has been failed in the
> sense
> that the contents are NOT what we expect.
> 
> Does anybody know what I am missing?
> 
> Your help would be greatly appreciated.
> 
> 
> -------------------------
> MINBO SHIM; mshim@rst.com
> Voice: (410) 876-9200 (#189), Fax: (410) 876-9470
> ROBOTIC SYSTEMS TECHNOLOGY
> 1234 Tech Court, Westminster, MD 21157 



From owner-vxwexplo-process  Thu Dec 17 15:05:17 1998
From: "John L Hagen" <jlhagen@crnotes.collins.rockwell.com>
Date: Thu Dec 17 15:05:21 PST 1998
Subject: Multiple ethernet port - routing troubles.



Hi All,

vxWorks / powerPC
First off, sorry for the extreme length of this note.

I'm having trouble understanding how the routing tables are used in
vxWorks.
My network background is very limited and I'm hoping someone can point out
the obvious things I'm missing and provide any pointers.

We're running vxWorks 5.3.1 on a MVME2604 board (BSP 1.1/4) - connected
via pci expansion to multiple 4-port ethernet cards (DEC21140/DEC21143).
In this example the [ifShow "dc"] command shows that 4 ports are attached.
The [routeAdd] and [routeShow] commands give the following tables...

ROUTE NET TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
131.198.68.0     131.198.68.249   3      1       206           dc0
131.198.68.0     131.198.68.202   1      0       0             dc0
131.198.69.0     131.198.69.63    1      0       0             dc12
131.198.69.0     131.198.69.62    1      0       0             dc11
131.198.69.0     131.198.69.61    1      0       0             dc10
131.198.69.0     131.198.69.60    1      0       0             dc9
------------------------------------------------------------------------
ROUTE HOST TABLE
destination      gateway          flags  Refcnt  Use   Interface
------------------------------------------------------------------------
127.0.0.1        127.0.0.1        5      1       11            lo0
131.198.69.44    131.198.69.60    5      0       0             dc9
------------------------------------------------------------------------
The dc0 interface is used to boot the os image from our company network.
Subnet 69 is just one I made up - but the addresses are unique and not
registered with the company network.

At this point I can delete/add [routeAdd..] single routing paths using dc9
or 10
or 11 etc... I can ping to and from the powerpc ports individualy from
another
computer(dolch3/4) on the subnet 69. I can repeat this with some
consistency with any
one of my added interfaces. e.g.

dolch4 is alive
PING dolch4 (131.198.69.44): 56 data bytes
64 bytes from dolch4 (131.198.69.44): icmp_seq=0. time=960. ms
64 bytes from dolch4 (131.198.69.44): icmp_seq=1. time=0. ms
64 bytes from dolch4 (131.198.69.44): icmp_seq=2. time=1488. ms
64 bytes from dolch4 (131.198.69.44): icmp_seq=3. time=528. ms
64 bytes from dolch4 (131.198.69.44): icmp_seq=4. time=368. ms
64 bytes from dolch4 (131.198.69.44): icmp_seq=5. time=1152. ms
64 bytes from dolch4 (131.198.69.44): icmp_seq=6. time=192. ms
----dolch4 PING Statistics----12 packets transmitted, 7 packets received,
41% packet lossround-trip (ms)  min/avg/max = 0/669/1488

Given, the packet loss is terrible! The problem I don't understand is
when I add a second route using a different interface on the powerpc
things don't go as I expect them. I'm expecting to be able to
ping dolch4(.44) using dc9 and communicate with dolch3(.48) using dc10.
Is this correct???

ROUTE NET TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
131.198.68.0     131.198.68.249   3      1       224           dc0
131.198.68.0     131.198.68.202   1      0       0             dc0
131.198.69.0     131.198.69.63    1      0       0             dc12
131.198.69.0     131.198.69.62    1      0       0             dc11
131.198.69.0     131.198.69.61    1      0       0             dc10
131.198.69.0     131.198.69.60    1      0       0             dc9
------------------------------------------------------------------------
ROUTE HOST TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
127.0.0.1        127.0.0.1        5      1       15            lo0
131.198.69.44    131.198.69.60    5      0       16            dc9
131.198.69.48    131.198.69.61    5      0       0             dc10
------------------------------------------------------------------------

When I try a single ping over the second route the system gets crazy and
the
tornado tools wonder off to ???. e.g. a reboot is needed.

ping "dolch3",1,0
can't read "event": no such variable
value = -1 = 0xffffffff
-> Error while polling for events:
    WTX Error 0x10197 (EXCHANGE_TIMEOUT)
-> Error while polling for events:
    WTX Error 0x10197 (EXCHANGE_TIMEOUT)
etc...

This happens if I repeat the process and try to ping over the first dc9
route after just adding the second dc10 route. I can see from our ethernet
analyzer that the ping command actually results in ARPs going out and
responses are generated by the second computer. But vxWorks now seems to be
lost and the tools are no longer communicating with the target and I have
to reboot the system.

I know it's not that tuff - It just hasn't dawned on me what I'm doing
wrong.
Any help is appreciated.

John Hagen
Rockwell Collins
jlhagen@cacd.rockwell.com





From owner-vxwexplo-process  Thu Dec 17 15:28:40 1998
From: "TEM Koshimizu, Kazu" <KKoshimizu@scl.telusa.com>
Date: Thu Dec 17 15:28:43 PST 1998
Subject: vxworks binary semaphore

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE2A14.80C58676
Content-Type: text/plain

Hello,

Does anyone know the way to find out the task did the last semTake() for
specific b-sem ?

Thanks in advance.
KazuKoshimizu / TokyoElectron

------_=_NextPart_001_01BE2A14.80C58676
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>vxworks binary semaphore</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hello,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Does anyone know the way to find out the task did the last semTake() for specific b-sem ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Thanks in advance.</FONT>
<BR><FONT SIZE=2 FACE="Arial">KazuKoshimizu / TokyoElectron</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE2A14.80C58676--


From owner-vxwexplo-process  Thu Dec 17 18:23:16 1998
From: Fred Roeber <froeber@BBN.COM>
Date: Thu Dec 17 18:23:20 PST 1998
Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply -Reply

On Thu, 17 Dec 1998, Carl C. Chesbrough answered a question about A16 access:

> You can use the m() function, giving it a parameter of 1 to do 8-bit
> access rather than 16-bit accesses.  I thought that the default d()
> access was 16-bits.  You can specify the size with the 3rd parameter
> to the d() function.

I never realized that the "d" command supported the same width argument
that the "m" command did.

If anyone is interested in how these commands work, they are delivered
in source form with VxWorks. Just look in the file src/usr/usrLib.c.
Default command uses 16 bit accesses the way Carl thought (at least in
my VxWorks 5.3 copy of the code).

Fred

   |      Fred J Roeber,  BBN Systems & Technologies      |
   |    4 John Clarke Road   Middletown, RI  02842-5202   |
   |          froeber@bbn.com     401-848-3548            |
   | TraceMaker product manager -> www.tracemaker.bbn.com |



From owner-vxwexplo-process  Thu Dec 17 21:50:43 1998
From: "Keith Buchanan" <Keith_Buchanan@SPARTA.com>
Date: Thu Dec 17 21:50:46 PST 1998
Subject: RE: Multiple ethernet port - routing troubles.

> Is this correct???
>
> ROUTE NET TABLE
> destination      gateway          flags  Refcnt  Use           Interface
> ------------------------------------------------------------------------
> 131.198.68.0     131.198.68.249   3      1       224           dc0
> 131.198.68.0     131.198.68.202   1      0       0             dc0
> 131.198.69.0     131.198.69.63    1      0       0             dc12
> 131.198.69.0     131.198.69.62    1      0       0             dc11
> 131.198.69.0     131.198.69.61    1      0       0             dc10
> 131.198.69.0     131.198.69.60    1      0       0             dc9
> ------------------------------------------------------------------------
> ROUTE HOST TABLE
> destination      gateway          flags  Refcnt  Use           Interface
> ------------------------------------------------------------------------
> 127.0.0.1        127.0.0.1        5      1       15            lo0
> 131.198.69.44    131.198.69.60    5      0       16            dc9
> 131.198.69.48    131.198.69.61    5      0       0             dc10
> ------------------------------------------------------------------------

You have multiple net routes to the 69 net which should work (though they
don't make much sense) but there is no guarantee which path the data will
take.  Since there is only physical port on the 68 net, there should only be
one route.  Are you trying to setup 2 logical addresses for dc0?  I think
(anyone know for sure?) the SENS stack will do that but not the normal stack
that comes with Tornado.  The point to point routes on the 69 net conflict
with the net routes on the 69 net.  You shouldn't do this unless the
POINTOPOINT flag is set for the interface.

Try this...

If you are trying to set up multiple point to point connections with each
physical port, put them on seperate nets.  A true point-to-point route
requires that the Ethernet driver support the ioctls that setup
point-to-point operation.  Often times, ethernet drivers (other than PPP and
SLIP) do not include this capability because it is strictly unnecessary for
devices that can broadcast.  Eliminate one of the 68 net routes unless you
have the SENS stack and are using multiple logical IP addresses on dc0.


HTH
----------------------------------
     /\\     Thomas Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  519 Interstate 30
 / \\\\\  \\ Suite 140
 \  \\\\\ // Rockwall, TX 75087
  \  //////
   \//////   Voice: 972 672 9657
    \////    FAX:   972 722 1216
     \//     WWW:   www.sparta.com




From owner-vxwexplo-process  Fri Dec 18 01:39:29 1998
From: David Laight <dsl@tadpole.co.uk>
Date: Fri Dec 18 01:39:33 PST 1998
Subject: Re: Multiple ethernet port - routing troubles.


You need to read up on IP routing.

In practise you need to:
  1) Put each interface on a system into a DIFFERENT subnet
  2) Connect each interface to a diferent physical LAN
  3) Only have one system/router linking any two subnets
     A problem because I don't believe you can disable IP-Forwarding in vxWorks.

If you don't do the above packets will not go out the expected interfaces.

Another possible area of confusion is that the typical Unix 'ping' does an 
address to name lookup on every returned packet.  Misconinfigured DNS and the 
broken resolv code can cause this to take a long time.

	David

> Hi All,
> 
> vxWorks / powerPC
> First off, sorry for the extreme length of this note.
> 
> I'm having trouble understanding how the routing tables are used in
> vxWorks.
> My network background is very limited and I'm hoping someone can point out
> the obvious things I'm missing and provide any pointers.
> 
> We're running vxWorks 5.3.1 on a MVME2604 board (BSP 1.1/4) - connected
> via pci expansion to multiple 4-port ethernet cards (DEC21140/DEC21143).
> In this example the [ifShow "dc"] command shows that 4 ports are attached.
> The [routeAdd] and [routeShow] commands give the following tables...
> 
> ROUTE NET TABLE
> destination      gateway          flags  Refcnt  Use           Interface
> ------------------------------------------------------------------------
> 131.198.68.0     131.198.68.249   3      1       206           dc0
> 131.198.68.0     131.198.68.202   1      0       0             dc0
> 131.198.69.0     131.198.69.63    1      0       0             dc12
> 131.198.69.0     131.198.69.62    1      0       0             dc11
> 131.198.69.0     131.198.69.61    1      0       0             dc10
> 131.198.69.0     131.198.69.60    1      0       0             dc9
> ------------------------------------------------------------------------
> ROUTE HOST TABLE

> 
> Given, the packet loss is terrible! The problem I don't understand is
No packets are being lost - just long latencies somewhere...

> when I add a second route using a different interface on the powerpc
> things don't go as I expect them. I'm expecting to be able to
> ping dolch4(.44) using dc9 and communicate with dolch3(.48) using dc10.
> Is this correct???
Use a different subnet for the seond interface


> John Hagen
> Rockwell Collins
> jlhagen@cacd.rockwell.com
> 



----------------------------------------------------------------
David Laight                          email: dsl@tadpole.co.uk
Tadpole Technology plc                phone: +44 1223 278 256
Cambridge, UK                         fax:   +44 1223 278 201



From owner-vxwexplo-process  Fri Dec 18 08:30:59 1998
From: daemon@csg.lbl.gov
Date: Fri Dec 18 08:31:03 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Fri Dec 18 04:00:14 PST 1998

        Subject: Asserting RTS/CTS using Z85C30 UART Driver
        Subject: Re: Tornado + Version Control integration
        Subject: Re: Build Output Requires Prompting? (Update)
        Subject: Re: Dec Ethernet Driver?
        Subject: Re: PowerPc assembler & system tick accuracy
        Subject: Test
        Subject: Timeouts and signals
        Subject: VxWorks on Acer/Igel X terminal
        Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver
        Subject: Re: Tornado + Version Control integration
        Subject: How to get the system time on Vxworks.
        Subject: Re: Booting VxWorks from hard-disk
        Subject: Re: Multiple ethernet port - routing troubles.
        Subject: Re: Cross Reference File from ld68k
        Subject: Re: FAT disk full detection
        Subject: Re: FAT disk full detection
        Subject: RTIs HeapCheck()

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

Newsgroups: comp.os.vxworks
Subject: Asserting RTS/CTS using Z85C30 UART Driver
Date: Thu, 17 Dec 1998 09:02:42 -0800
From: Tom jackson <tjackson@denali.neopath.com>
Organization: NeoPath Inc
Message-ID: <36793932.F79C32CA@denali.neopath.com>
Reply-To: tjackson

Anybody know how to assert/deassert the RTS/CTS lines using the Z35C30
driver in VxWorks?  Thanks

Thomas B. Jackson
Neopath, Inc.
Phone: 425-869-7284
Fax:   425-869-5325

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

Newsgroups: comp.os.vxworks
Subject: Re: Tornado + Version Control integration
Date: Thu, 17 Dec 1998 08:44:41 -0800
From: Matthew Downs <mdowns@ada.com>
Organization: Another Netscape Collabra Server User
Message-ID: <367934F9.AA220556@ada.com>
References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il>

But try and install patches to the OS......not an easy job! The whole
philosophy of how they patch the os is flawed inmy opinion.

Matt

Saffi Hartal wrote:

> Hi Peter Most people use make external IDE different from Tornado (we use
> CodeWright), with version control.
> It is a good solution that works fine.
>
> do it and enjoy your work.
>         Saffi
>
> Peter Weatherall wrote in message <36784811.108860281@news.phoenix.net>...
> >Has anyone integrated Tornado with a source code version control
> >system ? Some IDEs have this built-in. Any ideas about what is the
> >best approach with Tornado...
> >
> >
> >Thanks
> >Peter


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

Newsgroups: comp.os.vxworks
Subject: Re: Build Output Requires Prompting? (Update)
Date: Tue, 15 Dec 1998 10:59:44 -0700
From: Mike Stimpson <mstimp@utsci.com>
Organization: Utah Scientific, Inc.
Message-ID: <3676A390.41C6@utsci.com>
References: <754lui$8je$1@nnrp1.dejanews.com>

paulvroberts@my-dejanews.com wrote:
> 
> Tim Sohacki wrote:
> >
> > Update ... on one machine, it appears to be an interaction with
> > Norton Anti-virus.  On the other, it's something else, though
> > we don't know what yet.
> >
> > Cheers,
> > Tim
> >
> 
> Thanks to you and Philip Gaglia for giving me the idea that it was the virus
> checker.
> 
> I have verified this to be the case on the Win 95 machines that had problems.
> We are running McAfee VShield 3.2.0, and if you disable it, Tornado make
> windows then work fine.

Some virus checkers work by not allowing anyone other than a recognized
list of programs to write executable files.  You might be able to tell
the anti-virus software that Tornado (or some specific sub-program
thereof) is legitimately able to write executables...

> Oh the joy of developing under Windows...

"Here's a nickel, kid.  Get yourself a better computer."
   - a UNIX user in a Dilbert cartoon
- -- 
Mike Stimpson (mstimp@utsci.com)

Opinions expressed are not necessarily those of the management...

The more I work as an engineer, the more I disbelieve the theory of
evolution.

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

Newsgroups: comp.os.vxworks
Subject: Re: Dec Ethernet Driver?
Date: Thu, 17 Dec 1998 14:41:52 -0700
From: Rick Busser <rickb@sitera.com>
Organization: Dimensional Communications
Message-ID: <36797AA0.51496C34@sitera.com>
References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> <75bmv6$79n$1@nnrp1.dejanews.com>

I am trying to use this driver on a MIPS BSP and am having problems getting it to
work.  What is the parameter string that you are using?  Also how did you
determine what interrupt level/vector the card is configured for?
Thanks

gtsang@glenayre.com wrote:

> In article <36778DFF.D92F63F2@ibm.net>,
>   Dan DeVault <devault@ibm.net> wrote:
> > Wind River has a driver that works with the SENS stack.  At least for
> > the Motorola MTX604 BSP.  We are trouble shooting some problems with it
> > now.
> >
> > Dan DeVault
> > IBM Global Network
> > devault@ibm.net
>
> Hi Dan,
>
> We have almost the exact config (MVME604, SENS) and I am having problem
> bringing the driver up for DEC21143 (we did so for DEC21140). We have already
> found a few bugs in this "END" driver.
>
> Gilbert Tsang
> Glenarye R&D Inc.
>
> >
> > Frankie Sierra wrote:
> >
> > > I am looking for a Dec 21140, or 21143 Ethernet driver for use with
> > > VxWorks 5.1.3? Anyone done this? Any issues, caviats?
> > >
> > > Frankie Sierra
> > > sierra@teralogic-inc.com
> >
> >
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

- --
Rick Busser                            rickb@sitera.com
Software Engineer                      (303) 651-1935 x256
SiTera Corporation                     (303) 651-1199 fax
1820 Lefthand Circle                   Longmont, CO  80501



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

Newsgroups: comp.arch.embedded,comp.sys.powerpc.tech,comp.sys.powerpc,comp.os.vxworks
Subject: Re: PowerPc assembler & system tick accuracy
Date: 15 Dec 1998 11:05:08 -0500
From: Bill Pringlemeir <bpringlemeir@yahoo.com>
Organization: PSINet
Message-ID: <un24ppf0r.fsf@teklogix.com>
References: <36760043.5D1F4E4E@ecitele.com>
Followup-To: comp.sys.powerpc.tech

[follow-ups set]
Please don't cross post to this many newsgroups.

The Gnu documentation on the assembler provides the syntax for the
asm command.  It is similar to a 'printf' or 'scanf'.  The %0 means
that the first arguement is taken from the list that follows.  In
this case, what ever register the compiler decides to put decCountVal
in.  The colon is used to seperate the output of the __asm__ statement
from the arguement list.  This is documented in your GNU toolKit user's
guide which comes with VxWorks.  Version 2.7 has the info on pg 129, and
it is listed as 'Assembler Instructions with C expression operands'.
You should RTFM.

As for the trick with this code;  It is what it doesn't say, the code
will invalidate cache due to the change of the SPR value.  This was discussed
here recently.  A better solution is to use one of the 16 RISC timers that 
are available on the PowerPC.  Wind River doesn't provide these, but it would
take at most two days to write them (plus an AUX clock to use SPY).

Ok if you really want to know, read the VxWorks comment starting with:

"The PowerPC decrementer doesn't reload the value by itself. The reload.."

It wants to get the new value into the SPR as soon as possible because the
decrementer doesn't reload.  They load it with a value that will cause an
interrupt every xx milliseconds.  Missing time in the reload will cause an
extra delay.  If you use the RISC timers you can avoid this because they 
support reloading (restart).  So the better 'trick' is to use hardware that 
fits the application.

Good luck,
Bill

>>>>> "Yosi" == Yosi Yarchi <yosiy@ecitele.com> writes:

    Yosi> Hello all The following is source copied from vxWorks system
    Yosi> timer interrupt routine, which is based on the decrementer
    Yosi> function of the PowerPc (in this case: MPC860). I'm looking
    Yosi> for some explanation about the syntax in this code: (1) what
    Yosi> is the %0 (implemented by the compiler as r9 register). (2)
    Yosi> what means the colon character (appears at the begining of
    Yosi> the last 3 lines). (3) what means of the "r", "3", and "cc"
    Yosi> commands which have special inverted commas (" ")? as I
    Yosi> could see, these lines have no effect on the code generated
    Yosi> by the compiler. (4) can someone explain me the trick of
    Yosi> compensation of the interrupt latency which is implemented
    Yosi> here in the loop(it required because the decrementer is not
    Yosi> auto reloaded)?

- -- 
Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/"

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

Newsgroups: comp.os.vxworks
Subject: Test
Date: Tue, 15 Dec 1998 16:28:41 GMT
From: wlbrown@netcom.com (William L. Brown Jr.)
Organization: Netcom
Message-ID: <wlbrownF40Lru.3v0@netcom.com>
Sender: wlbrown@netcom13.netcom.com

This is a test of the vxWorks exploder.  No adjustment of your
set is necessary.


           --+---+   \/		-bill
      ++---+ |[]]|_^_[]		wlbrown@netcom.com
     _|____+-+___|____|_	Concord, CA
     | o+o +-+ <>--<>-= \	C-250 #302 - "Amazing Grace"
				a.k.a. wlbrown@lbl.gov

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

Newsgroups: comp.os.vxworks
Subject: Timeouts and signals
Date: Thu, 17 Dec 1998 23:15:19 GMT
From: Ephraim Ezekiel <eezekiel@bbn.com>
Organization: Quarry Technologies
Message-ID: <3679902D.B21503A9@bbn.com>

VxWorks provides a way of getting a signal synchronously
using sigTimedWait() rather than calling an asynchonous
signal handler..

Does anyone know if I can call timer_create() and get the
signal via this synchronous interface? The documentation for
the timers indicates that a signal handler must be installed
in order to process the timeout.

Thanks,
- - Ephraim


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

Newsgroups: comp.os.vxworks
Subject: VxWorks on Acer/Igel X terminal
Date: 17 Dec 98 23:52:36 GMT
From: engel@math.uni-siegen.de
Message-ID: <36799944.0@rainbow.hrz.uni-siegen.de>
Sender: Michael Engel <engel@jordan.numerik.math.uni-siegen.de>

Hi,

please excuse me if this posting is a little off-topic ...

I just obtained a X terminal "Etherminal" from a german company named
Igel. Upon further investigation I found out that this is an OEM'd
Acer ViewX terminal based on a LSI Logic MIPS LR33020 CPU and running
VxWorks. Imagine my surprise when I found out that I could telnet to
my X terminal and actually get a login prompt ;-).

Here my problem begins: the X11R5 X window server that comes with the 
terminal seems to be quite buggy - it usually doesn't survive a Netscape
session. There is no support whatsoever for the terminals any more and the
latest software release is from 1996. So I decided to try implementing
a more recent version of X myself. As I own no VxWorks development
license (and I'm afraid I won't be able to afford one as I have to live
on a student's budget ...) I got the idea of porting some other OS to 
this X terminal. Linux or NetBSD are possibly out of reach as the LR33020
doesn't have an MMU - but Minix would probably fit quite well. I have
some MIPS programming experience from the DECstation Linux port, so this
isn't all new to me.

So, my vague hope is that one of you might have worked on the VxWorks 
port to the ViewX X terminal and can provide me with information on the
hardware of this terminal (I/O addresses, interrupt vectors used, IC 
datasheets). I would be quite happy if I could make something more useful 
out of that nice little terminal box ... it would make a really nice
diskless workstation as it is expandable to 64 MB RAM with standard 
PS/2 SIMM modules.

Best regards,
	Michael Engel	(engel@unix-ag.org)


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

Newsgroups: comp.os.vxworks
Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver
Date: Thu, 17 Dec 1998 16:39:55 -0800
From: Matthew Downs <mdowns@ada.com>
Organization: Another Netscape Collabra Server User
Message-ID: <3679A45B.C2E8E588@ada.com>
References: <36793932.F79C32CA@denali.neopath.com>

Tom jackson wrote:

> Anybody know how to assert/deassert the RTS/CTS lines using the Z35C30
> driver in VxWorks?  Thanks
>
> Thomas B. Jackson
> Neopath, Inc.
> Phone: 425-869-7284
> Fax:   425-869-5325

85C30 or 35C30? I've used the 85C30 in my time, but not a 35C30.



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

Newsgroups: comp.os.vxworks
Subject: Re: Tornado + Version Control integration
Date: Thu, 17 Dec 1998 16:39:00 -0800
From: Matthew Downs <mdowns@ada.com>
Organization: Another Netscape Collabra Server User
Message-ID: <3679A423.AC5EAECC@ada.com>
References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il> <1998121719370883839@zetnet.co.uk>

David & Bella Aldrich wrote:

> Wind River announced in a recent seminar that Tornado II will have
> hooks to allow 3rd party tools to interface to the development
> environment. They mentioned version control systems in particular.
>
> David

I'll have to go check the information about the beta. I'm on the Beta
list and should have caught that one. If so, it about time!



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

Newsgroups: comp.os.vxworks
Subject: How to get the system time on Vxworks.
Date: Thu, 17 Dec 1998 19:17:08 -0800
From: Venkat Emani <cemani@qualcomm.com>
Organization: QUALCOMM, Incorporated; San Diego, CA, USA
Message-ID: <3679C934.DC671165@qualcomm.com>



Greetings Folks,

I would appreciate if someone can help me in the following regard.

I am trying to  get the system time from  within the program.

     My code looks like this:


   #include <time.h>
  ........

  time_t    tm Time  =  time(NULL) ;

   struct tm * tmp  =  localtime(&tmTime) ;

    .....

   I thought tmTime should contain the no. of seconds from Jan 1st.
1970  ( At least on Solaris and NT it's like that )
   However, tmTime is  set to the  no. of seconds  elapsed since the
card was booted last.  ( Which meant  if I run it
   in 5 minutes after booting my MC card, tmTime was being set to   5 *
60 = 300 . As a result the localtime() routine
   sets the time to Jan 1st 1970 ,  00:05:00   which was n't what I
wanted.

   Please let me know  how I can get the system Time .

My apologies if this  question was previously answered. Please point me
to that.

 Thanks,

Ven.


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

Newsgroups: comp.os.vxworks
Subject: Re: Booting VxWorks from hard-disk
Date: Tue, 15 Dec 1998 22:29:03 GMT
From: david.hagood@ifrsys.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <756nra$1r8$1@nnrp1.dejanews.com>
References: <7422lv$lg7@news.or.intel.com> <3667470D.AA598FFD@know_spam.wrs.com>

I've tried to boot VxWorks from a hard disk only to fail miserably.

The disk is partitioned with a FAT-16 partition as the first primary
partition. That partition is bootable (marked active).

I do a vxsys c:\, and it works.
I copy a:bootrom.sys c:\bootrom.sys, and it works
I verify that bootrom.sys is contiguous.
I reboot the machine.
VxLd complains that it cannot find bootrom.sys

The bootrom.sys I copied over loaded fine from the floppy.

I created the file system from VxWorks, so it ought to be a configuration
that VxWorks likes.

Any ideas?

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: Re: Multiple ethernet port - routing troubles.
Date: Fri, 18 Dec 1998 06:37:48 -0500
From: Dan DeVault <devault@ibm.net>
Organization: IBM.NET
Message-ID: <367A3E8C.7B96F011@ibm.net>
References: <862566DD.007EA688.00@crnotes.collins.rockwell.com>

John,
           If you are using the dec21x40end driver with SENS then that would
explain some of your troubles.   We are currently troubleshooting this driver
for dropped packets and xsmit problems.  This driver can receive packets at a
great rate.  However it seems to have some problems in its transmit logic.
I'll post more once we figure out if it is the driver or something else.

Dan DeVault
IBM Global Network

John L Hagen wrote:

> Hi All,
>
> vxWorks / powerPC
> First off, sorry for the extreme length of this note.
>
> I'm having trouble understanding how the routing tables are used in
> vxWorks.
> My network background is very limited and I'm hoping someone can point out
> the obvious things I'm missing and provide any pointers.
>
> We're running vxWorks 5.3.1 on a MVME2604 board (BSP 1.1/4) - connected
> via pci expansion to multiple 4-port ethernet cards (DEC21140/DEC21143).
> In this example the [ifShow "dc"] command shows that 4 ports are attached.
> The [routeAdd] and [routeShow] commands give the following tables...
>
> ROUTE NET TABLE
> destination      gateway          flags  Refcnt  Use           Interface
> ------------------------------------------------------------------------
> 131.198.68.0     131.198.68.249   3      1       206           dc0
> 131.198.68.0     131.198.68.202   1      0       0             dc0
> 131.198.69.0     131.198.69.63    1      0       0             dc12
> 131.198.69.0     131.198.69.62    1      0       0             dc11
> 131.198.69.0     131.198.69.61    1      0       0             dc10
> 131.198.69.0     131.198.69.60    1      0       0             dc9
> ------------------------------------------------------------------------
> ROUTE HOST TABLE
> destination      gateway          flags  Refcnt  Use   Interface
> ------------------------------------------------------------------------
> 127.0.0.1        127.0.0.1        5      1       11            lo0
> 131.198.69.44    131.198.69.60    5      0       0             dc9
> ------------------------------------------------------------------------
> The dc0 interface is used to boot the os image from our company network.
> Subnet 69 is just one I made up - but the addresses are unique and not
> registered with the company network.
>
> At this point I can delete/add [routeAdd..] single routing paths using dc9
> or 10
> or 11 etc... I can ping to and from the powerpc ports individualy from
> another
> computer(dolch3/4) on the subnet 69. I can repeat this with some
> consistency with any
> one of my added interfaces. e.g.
>
> dolch4 is alive
> PING dolch4 (131.198.69.44): 56 data bytes
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=0. time=960. ms
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=1. time=0. ms
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=2. time=1488. ms
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=3. time=528. ms
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=4. time=368. ms
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=5. time=1152. ms
> 64 bytes from dolch4 (131.198.69.44): icmp_seq=6. time=192. ms
> ----dolch4 PING Statistics----12 packets transmitted, 7 packets received,
> 41% packet lossround-trip (ms)  min/avg/max = 0/669/1488
>
> Given, the packet loss is terrible! The problem I don't understand is
> when I add a second route using a different interface on the powerpc
> things don't go as I expect them. I'm expecting to be able to
> ping dolch4(.44) using dc9 and communicate with dolch3(.48) using dc10.
> Is this correct???
>
> ROUTE NET TABLE
> destination      gateway          flags  Refcnt  Use           Interface
> ------------------------------------------------------------------------
> 131.198.68.0     131.198.68.249   3      1       224           dc0
> 131.198.68.0     131.198.68.202   1      0       0             dc0
> 131.198.69.0     131.198.69.63    1      0       0             dc12
> 131.198.69.0     131.198.69.62    1      0       0             dc11
> 131.198.69.0     131.198.69.61    1      0       0             dc10
> 131.198.69.0     131.198.69.60    1      0       0             dc9
> ------------------------------------------------------------------------
> ROUTE HOST TABLE
> destination      gateway          flags  Refcnt  Use           Interface
> ------------------------------------------------------------------------
> 127.0.0.1        127.0.0.1        5      1       15            lo0
> 131.198.69.44    131.198.69.60    5      0       16            dc9
> 131.198.69.48    131.198.69.61    5      0       0             dc10
> ------------------------------------------------------------------------
>
> When I try a single ping over the second route the system gets crazy and
> the
> tornado tools wonder off to ???. e.g. a reboot is needed.
>
> ping "dolch3",1,0
> can't read "event": no such variable
> value = -1 = 0xffffffff
> -> Error while polling for events:
>     WTX Error 0x10197 (EXCHANGE_TIMEOUT)
> -> Error while polling for events:
>     WTX Error 0x10197 (EXCHANGE_TIMEOUT)
> etc...
>
> This happens if I repeat the process and try to ping over the first dc9
> route after just adding the second dc10 route. I can see from our ethernet
> analyzer that the ping command actually results in ARPs going out and
> responses are generated by the second computer. But vxWorks now seems to be
> lost and the tools are no longer communicating with the target and I have
> to reboot the system.
>
> I know it's not that tuff - It just hasn't dawned on me what I'm doing
> wrong.
> Any help is appreciated.
>
> John Hagen
> Rockwell Collins
> jlhagen@cacd.rockwell.com


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

Newsgroups: comp.os.vxworks
Subject: Re: Cross Reference File from ld68k
Date: Fri, 18 Dec 1998 11:39:09 GMT
From: whd@directors-1.zetnet.zet (Ag@whd)
Organization: White Horse Design
Message-ID: <367f3ebd.2868169@znews.zetnet.co.uk>
References: <361A29E9.46DFD4C@email.mot.com>
Reply-To: whd@directors-1.zetnet.zet

On Tue, 06 Oct 1998 09:32:09 -0500, Lance C Brown
<lbrown1@email.mot.com>  penned these words:

>I was trying to use 'ld68k --cref' and it seems that the
>GNU Toolkit manual says this supported, but WindRiver
>didn't build ld68k with this option turned on.  So does
>anyone know how to generate a Cross Reference
>file without 'ld68k --cref'?

I know that for ldppc the -Map option is case SENSITIVE.
Worth checking this on your ld68k.

Adrian

WWW    WWW Adrian Gothard                 
WWW ww WWW White Horse Design
WWWWWWWWWW 			
WWWW  WWWW whd@zetnet.co.uk, http://www.users.zetnet.co.uk/whd
- ---
Designers of video capture/filter/processing systems for aircraft

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

Newsgroups: comp.os.vxworks
Subject: Re: FAT disk full detection
Date: Fri, 18 Dec 1998 11:41:09 GMT
From: whd@directors-1.zetnet.zet (Ag@whd)
Organization: White Horse Design
Message-ID: <36803f38.2990259@znews.zetnet.co.uk>
References: <6vi3b8$hi@overload.lbl.gov> <3620bc4d.30983072@znews.zetnet.co.uk> <3626639D.DB5A97B7@lynx.tsb.ca>
Reply-To: whd@directors-1.zetnet.zet

On Thu, 15 Oct 1998 17:05:33 -0400, Yibing Fan <yibing@lynx.tsb.ca>
penned these words:

>  Adrian,
>
>Following 3 lines code will do what you want:
>
> int fd = open(YOUR_DOSSF_NAME, O_WRONLY, 0);
> ioctl(fd, FIONFREE, (int)&freeMem);
> close(fd);
>
>Where freeMem is an int your declared to hold return value.

Thanks, but I did not post the original query.

Adrian

WWW    WWW Adrian Gothard                 
WWW ww WWW White Horse Design
WWWWWWWWWW 			
WWWW  WWWW whd@zetnet.co.uk, http://www.users.zetnet.co.uk/whd
- ---
Designers of video capture/filter/processing systems for aircraft

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

Newsgroups: comp.os.vxworks
Subject: Re: FAT disk full detection
Date: Fri, 18 Dec 1998 11:41:40 GMT
From: whd@directors-1.zetnet.zet (Ag@whd)
Organization: White Horse Design
Message-ID: <36813f59.3023573@znews.zetnet.co.uk>
References: <6vi3b8$hi@overload.lbl.gov> <3620bc4d.30983072@znews.zetnet.co.uk> <3626639D.DB5A97B7@lynx.tsb.ca>
Reply-To: whd@directors-1.zetnet.zet

On Thu, 15 Oct 1998 17:05:33 -0400, Yibing Fan <yibing@lynx.tsb.ca>
penned these words:

/snip/

>Hope this help.

I meant to add that some "snipping" would probably go down well :-)

Adrian

WWW    WWW Adrian Gothard                 
WWW ww WWW White Horse Design
WWWWWWWWWW 			
WWWW  WWWW whd@zetnet.co.uk, http://www.users.zetnet.co.uk/whd
- ---
Designers of video capture/filter/processing systems for aircraft

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

Newsgroups: comp.os.vxworks
Subject: RTIs HeapCheck()
Date: Fri, 18 Dec 1998 12:50:40 +0100
From: Roberto Nunnari <roberto.nunnari@agie.ch>
Organization: AGIE
Message-ID: <367A4190.F9764253@agie.ch>

Hi all,

I tried to run RTI's HeapCheck() on 2 different x86 targets and
its reports are strange to me... maybe some kind soul
can help me understand what's going on...

First target:
default BSP from wind river 'pc486' with 16MB RAM
I run
  HeapCheck  --> OK
  HeapCheck 1
HeapCheck: Checking heap at 0xfff000...
HeapCheck: 30 blocks checked.
HeapCheck: 1 free blocks totalling 20 bytes (28 with headers).
HeapCheck: 29 used blocks totalling 9740 bytes (9972 with headers).
HeapCheck: Checking heap at 0xffc8f0...
HeapCheck: 3653 blocks checked.
HeapCheck: 20 free blocks totalling 13709140 bytes (13709300 with
headers).
HeapCheck: 3633 used blocks totalling 283892 bytes (312956 with
headers).
HeapCheck: Checking heap at 0x200000...
HeapCheck: 1 blocks checked.
HeapCheck: 0 free blocks totalling 0 bytes (0 with headers).
HeapCheck: 1 used blocks totalling -8 bytes (0 with headers).
21 total free blocks found.

Isn't that '-8' bytes strange???

Second  target:
third-party BSP for pentium with 32MB RAM
I run
  HeapCheck --> ERROR
0xfae2ac (t16): Heap Error: 'prev ptr' is corrupt at   1ffff8 (count =
1)
  HeapCheck 1
HeapCheck: Checking heap at 0xfff000...
HeapCheck: 8 blocks checked.
HeapCheck: 1 free blocks totalling 9784 bytes (9792 with headers).
HeapCheck: 7 used blocks totalling 152 bytes (208 with headers).
HeapCheck: Checking heap at 0xffc8f0...
HeapCheck: 104 blocks checked.
HeapCheck: 1 free blocks totalling 13785724 bytes (13785732 with
headers).
HeapCheck: 103 used blocks totalling 340764 bytes (341588 with headers).

HeapCheck: Checking heap at 0x200000...
0xfae2ac (t17): Heap Error: 'prev ptr' is corrupt at   1ffff8 (count =
2)
HeapCheck: 1 blocks checked.
HeapCheck: 1 free blocks totalling -10 bytes (-2 with headers).
HeapCheck: 0 used blocks totalling 0 bytes (0 with headers).

Here again I get a negative value for bytes, but this time for the free
blocks!

Any help/hint will be greatly appreciated...

Best regards.
Robi.



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

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


From owner-vxwexplo-process  Fri Dec 18 10:03:51 1998
From: Charlie Grames <cgrames@mdc.com>
Date: Fri Dec 18 10:03:55 PST 1998
Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply -Reply

Fred, Carl, Minbo, et al.:

Actually, the way d() behaves depends on which version you use.  The version
in src/usr/usrLib.c is included in the target-based shell.  The version
available from WindSh behaves as I indicated in my other e-mail (i.e.,
vxMemProbe() of first and last byte of a 16-byte segment followed by four
32-bit reads).  If you're using WindSh and want the usrLib.c version, put an
"@" in front of the "d" when you perform the command.

Personally, I still think it is safer to view or modify device memory using
constructs like "val = (char)*0xfbff6005" or "*0xfbff6005 = (char)val".

Charlie Grames
The Boeing Company
(314) 233-1956
Charles.R.Grames@boeing.com

>>> the vxWorks Users Group Exploder <vxwexplo@lbl.gov> 12/17/98 08:23pm >>>
Submitted-by owner-vxwexplo-process  Thu Dec 17 18:23:16 1998
Submitted-by: Fred Roeber <froeber@BBN.COM>

On Thu, 17 Dec 1998, Carl C. Chesbrough answered a question about A16
access:

> You can use the m() function, giving it a parameter of 1 to do 8-bit
> access rather than 16-bit accesses.  I thought that the default d()
> access was 16-bits.  You can specify the size with the 3rd parameter
> to the d() function.

I never realized that the "d" command supported the same width argument
that the "m" command did.

If anyone is interested in how these commands work, they are delivered
in source form with VxWorks. Just look in the file src/usr/usrLib.c.
Default command uses 16 bit accesses the way Carl thought (at least in
my VxWorks 5.3 copy of the code).

Fred

   |      Fred J Roeber,  BBN Systems & Technologies      |
   |    4 John Clarke Road   Middletown, RI  02842-5202   |
   |          froeber@bbn.com     401-848-3548            |
   | TraceMaker product manager -> www.tracemaker.bbn.com |



From owner-vxwexplo-process  Fri Dec 18 10:20:02 1998
From: "Jijo Xavier" <jijo.xavier@tekelec.com>
Date: Fri Dec 18 10:20:07 PST 1998
Subject: Re: Multiple ethernet port - routing troubles.

Hi There!
     I'm quite new to VxWorks. I'm developing a Sharedmemory Backplane n/w
device
driver. I'd like to know how to load a device driver at the boot time.

Thanks in advance.
Jijo.




From owner-vxwexplo-process  Fri Dec 18 11:38:55 1998
From: Lori Fraleigh <lori@rti.com>
Date: Fri Dec 18 11:38:59 PST 1998
Subject: Re:  RTIs HeapCheck()


Have you tried running HeapFindPools?  Sometimes the heuristic that
identifies the default memory pools in the system fails and you
need to make this call to properly initialize the data structures
for HeapCheck.

If this doesn't solve your problems or you have other questions
concerning the Heap tools, feel free to contact our support
department at support@rti.com.  We will be happy to work directly
with you.  (I'll be on vacation.)

Regards,
Lori
--
Lori Fraleigh       Real-Time Innovations        http://www.rti.com
lori@rti.com        408-720-8312 ext. 121         Fax: 408-734-5009


Your message:

Newsgroups: comp.os.vxworks
Subject: RTIs HeapCheck()
Date: Fri, 18 Dec 1998 12:50:40 +0100
From: Roberto Nunnari <roberto.nunnari@agie.ch>
Organization: AGIE
Message-ID: <367A4190.F9764253@agie.ch>

Hi all,

I tried to run RTI's HeapCheck() on 2 different x86 targets and
its reports are strange to me... maybe some kind soul
can help me understand what's going on...

First target:
default BSP from wind river 'pc486' with 16MB RAM
I run
  HeapCheck  --> OK
  HeapCheck 1
HeapCheck: Checking heap at 0xfff000...
HeapCheck: 30 blocks checked.
HeapCheck: 1 free blocks totalling 20 bytes (28 with headers).
HeapCheck: 29 used blocks totalling 9740 bytes (9972 with headers).
HeapCheck: Checking heap at 0xffc8f0...
HeapCheck: 3653 blocks checked.
HeapCheck: 20 free blocks totalling 13709140 bytes (13709300 with
headers).
HeapCheck: 3633 used blocks totalling 283892 bytes (312956 with
headers).
HeapCheck: Checking heap at 0x200000...
HeapCheck: 1 blocks checked.
HeapCheck: 0 free blocks totalling 0 bytes (0 with headers).
HeapCheck: 1 used blocks totalling -8 bytes (0 with headers).
21 total free blocks found.

Isn't that '-8' bytes strange???

Second  target:
third-party BSP for pentium with 32MB RAM
I run
  HeapCheck --> ERROR
0xfae2ac (t16): Heap Error: 'prev ptr' is corrupt at   1ffff8 (count =
1)
  HeapCheck 1
HeapCheck: Checking heap at 0xfff000...
HeapCheck: 8 blocks checked.
HeapCheck: 1 free blocks totalling 9784 bytes (9792 with headers).
HeapCheck: 7 used blocks totalling 152 bytes (208 with headers).
HeapCheck: Checking heap at 0xffc8f0...
HeapCheck: 104 blocks checked.
HeapCheck: 1 free blocks totalling 13785724 bytes (13785732 with
headers).
HeapCheck: 103 used blocks totalling 340764 bytes (341588 with headers).

HeapCheck: Checking heap at 0x200000...
0xfae2ac (t17): Heap Error: 'prev ptr' is corrupt at   1ffff8 (count =
2)
HeapCheck: 1 blocks checked.
HeapCheck: 1 free blocks totalling -10 bytes (-2 with headers).
HeapCheck: 0 used blocks totalling 0 bytes (0 with headers).

Here again I get a negative value for bytes, but this time for the free
blocks!

Any help/hint will be greatly appreciated...

Best regards.
Robi.


From owner-vxwexplo-process  Fri Dec 18 12:12:58 1998
From: heller@nm.picker.com (Mark Heller)
Date: Fri Dec 18 12:13:06 PST 1998
Subject: MVME-2300 and MPMC202 second ethernet.





Hello all,


	I've got a Motorola MVME-2303 cpu board and
	I was thinking of adding a second ethernet
	to it with the Motorola MPMC202 pmc module.
	Has anyone out there done this already?
	If so, what problems were encountered?
	What initialization was necessary?


	Thanks in advance.

-------
-Mark
-------
Mark Heller
Picker International Inc.
Nuclear Medicine Division
heller@nm.picker.com

VxWorks Tornado VxWorks Tornado VxWorks Tornado VxWorks Tornado








From owner-vxwexplo-process  Sat Dec 19 15:01:12 1998
From: darryl@cognex.com (Darryl Troxel)
Date: Sat Dec 19 15:01:18 PST 1998
Subject: MVME-177 locks up with copyback caching


VxWorks folks,

Recently one of our typical configurations has been giving us trouble,
and maybe somebody has seen something similar, or even fixed it.

I'm running VxWorks 5.2 for MC68K on an MVME-167 as CPU 0 and an
MVME-177 as CPU 1 in a VME cardcage.  The two CPU's communicate by
making their RAM accessible on the VMEbus at a unique "global" address,
with VMEchip2 GCSR mailbox interrupts and message pointers in low RAM.
On the 177 I'm using MMU tables to provide noncached RAM at the low end
of the memory map for ethernet buffers, inter-CPU I/O and the MMU
tables themselves; the rest of RAM can be set cachable-writethrough or
cachable-copyback.  When the CPU 1 code has data to send to CPU 0, the
data blocks in copyback RAM are pushed out of cache before interrupting
CPU 0 so the data won't be stale.  We've shipped 10 systems or more
with this configuration that have been working fine in the field.

In the last month we've built 3 such systems that run for anywhere from
4 to 13 hours, then the 177 "locks up".  Sometimes it just plain halts
(STAT LED lit), other times it isn't halted; but it won't respond to
the network or even to the serial port.  The board still responds as a
VME slave, so I can look around in memory a bit. I've verified that none
of the task stacks have overflowed, none have suspended for bus errors
or address faults.  Of the 12 hangs I've investigated in detail, the
vector table of the 177 has been trashed 3 times; it was undisturbed
the other 9 times.  I started recording the PC, SP, and SR values at
each clock tick, and found one occurrence where non-interrupt code was
running at interrupt level (SR = 0x2400).  Other hangs show OK values
(rational PC values, SP well within task statcks).

If I run with the cached RAM as cachable-writethrough, however, the CPU
doesn't hang.  It seems like interrupt processing with copyback caching
somehow causes the problem.  On the 68060, there is no separate
interrupt stack (interrupts are processed on the current task's
stack).  But interrupt processing would still reference memory from the
CPU, which should hit in the cache anyway.  I don't want to run the 177
writethrough or noncached, because the performance drop for the 50MHz
CPU forced to cache-push on the 25MHz local bus makes it not much
faster than the MVME-167 in these modes.

One more fact I found today in the 5.2 Reference Manual: the ei device
driver needs the ethernet buffers to be in noncached RAM, but it also
uses 8 bytes in the .data section and 912 bytes in .bss.  In addition,
the driver allocates some fixed and variable-sized chunks with
cacheDmaMalloc() to share with the 82596 controller.  Since I'm doing
the cache management outside of vxWorks (I'm not using VxVMI),
cacheDmaMalloc is just doing a plain malloc, which will not be in
noncached space.  Does anyone know if these additional data blocks
would cause this problem if in cached space, and if so, how can I
"hotwire" the ei driver or cacheDmaMalloc() to use noncached RAM I can
set aside for this purpose?  And is it just luck that the 10 systems
in the field haven't experienced this problem?

Darryl

__________________________________________________________________
Darryl Troxel                            COGNEX Surface Inspection
darryl@cognex.com                                 Systems Division
Tel: 510.749.4038                            2060 Challenger Drive
Fax: 510.865.9927                            Alameda, CA 94501 USA
__________________________________________________________________







From owner-vxwexplo-process  Sun Dec 20 04:01:29 1998
From: daemon@csg.lbl.gov
Date: Sun Dec 20 04:01:32 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Sun Dec 20 04:01:25 PST 1998

        Subject: Re: vxworks binary semaphore
        Subject: Global Descriptor Table
        Subject: RPC: Procedure unavailable....
        Subject: Re: off topic question
        Subject: Looking for firewall product or source code
        Subject: Re: Dec Ethernet Driver?
        Subject: Zip software needed
        Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver
        Subject: Network misbeviour
        Subject: man pages on NT
        Subject: Re: SCSI disk
        Subject: Re: Zip software needed
        Subject: Re: Tornado + Version Control integration
        Subject: Any Experience with Posix Message Queues?
        Subject: arp proxy form VME backplane to ethernet
        Subject: Re: Network misbeviour
        Subject: Re: embedded HTTP
        Subject: DDD For Tornado/vxWorks?
        Subject: Re: PowerPc assembler & system tick accuracy

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

Newsgroups: comp.os.vxworks
Subject: Re: vxworks binary semaphore
Date: Fri, 18 Dec 1998 07:33:58 -0600
From: "Michael W. Johnson" <mjohnson@wgcgps.com>
Organization: NeoSoft, Inc.  
Message-ID: <367A59C6.FEB3DB63@wgcgps.com>
References: <75c6q7$789@overload.lbl.gov>

TEM Koshimizu, Kazu wrote:

> Does anyone know the way to find out the task did the last semTake() for
> specific b-sem ?

semShow(), executed from the shell, prints the task's ID.

Mike Johnson
Western Geophysical
Houston, TX


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

Newsgroups: comp.os.vxworks
Subject: Global Descriptor Table
Date: Fri, 18 Dec 1998 12:47:25 GMT
From: keshavbc@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <75diss$oq2$1@nnrp1.dejanews.com>

hi,
  i want to know what a GDT (w.r.t 80x86 architecture) is and it's uses. also,
i want to know it's relationship with the IVT(Interrupt Vector Table), if any.
  would you mind being elaborative.

p.s: Please also reply at <keshav@mistralsolutions.com>

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: RPC: Procedure unavailable....
Date: Fri, 18 Dec 1998 09:40:22 -0500
From: Jeff Daly <jeffrey.j.daly@lmco.com>
Organization: Sanders A Lockheed Martin Company
Message-ID: <367A6956.B4FFA4A7@lmco.com>
Reply-To: jeffrey.j.daly@lmco.com

This is a multi-part message in MIME format.
- --------------146EA2B3899CEB21B8F78391
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

trying to attach tgtsvr to my target for the first time.... using the
default BSP build (custom MIPS board) with windCfg
from the launcher.   no problem with vxWorks 5.3 bootrom and kernel boot
(still using TYCODRV_5_2).
WDB_COMM_NETWORK defined.  using snoop on solaris2.5, i see one RCP call
go to the target and the target
responds with an accept status = 3 (Procedure unavailable).
am i missing something in the kernel konfig, since the network
connection is ok?

- --------------146EA2B3899CEB21B8F78391
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jeff Daly
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Jeff Daly
n:              Daly;Jeff
org:            Sanders, A Lockheed Martin Co.
email;internet: jeffrey.j.daly@lmco.com
title:          SW Guy
note:           B-sharps
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


- --------------146EA2B3899CEB21B8F78391--


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

Newsgroups: comp.os.vxworks
Subject: Re: off topic question
Date: Fri, 18 Dec 1998 09:59:50 -0600
From: "Michael W. Johnson" <mjohnson@wgcgps.com>
Organization: NeoSoft, Inc.  
Message-ID: <367A7BF5.A286B578@wgcgps.com>
References: <01be2a8e$653ef520$b7c310ac@ndsuk1063>

Robert Stedman wrote:

> I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc
> compiler for both ends.  Packing structures at the target side is achieved
> with  __attribute__ ((packed)), however this doesn't work at the Sun side.
> Any ideas on how to coerce gcc to pack structures on a Sun would be
> gratefully received (#pragma pack (1) doesn't do the trick either)

To the best of my recollection, when the same issue arose here several years
ago, the solution was just to make all structure elements were some multiple
of four bytes in length, because the Sun won't back bytes as expected.

Mike Johnson
Western Geophysical
Houston, TX


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

Newsgroups: comp.os.vxworks
Subject: Looking for firewall product or source code
Date: Fri, 18 Dec 1998 09:38:08 -0800
From: Randy Riggins <Randy_Riggins@Telestream.net>
Message-ID: <54C40CA7FBB3D111B0D200A0C9AB28C101DD4723@earth.telestream.net>
Sender: Randy Riggins <Randy_Riggins@Telestream.net>

I need some basic firewall functionality between the two network ports
of our product.
What's available in VxWorks?

Thanks,
randy


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

Newsgroups: comp.os.vxworks
Subject: Re: Dec Ethernet Driver?
Date: Fri, 18 Dec 1998 13:41:10 -0500
From: "Khoa" <no-knguyen-spam@csi.com>
Message-ID: <eb9vXZrK#GA.327@ntawwabp.compuserve.com>
References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> <75bmv6$79n$1@nnrp1.dejanews.com>

gtsang@glenayre.com wrote in message <75bmv6$79n$1@nnrp1.dejanews.com>...
>We have almost the exact config (MVME604, SENS) and I am having problem
>bringing the driver up for DEC21143 (we did so for DEC21140). We have
already
>found a few bugs in this "END" driver.
>Gilbert Tsang
>Glenarye R&D Inc.


So does anyone know whether VxWorks has an updated patch for the driver or
acknowledged this problem in an SPR?

Khoa



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

Newsgroups: comp.os.vxworks
Subject: Zip software needed
Date: Fri, 18 Dec 1998 11:13:25 -0800
From: Matthew Downs <mdowns@ada.com>
Organization: Another Netscape Collabra Server User
Message-ID: <367AA955.ECDE28E7@ada.com>

I need some compression software for saving files on my VxWorks target.
Has any one ported gzip or some thing similar to VxWorks?

Matt


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

Newsgroups: comp.os.vxworks
Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver
Date: Fri, 18 Dec 1998 11:11:59 -0800
From: Tom Jackson <tjackson@denali.neopath.com>
Organization: NeoPath Inc
Message-ID: <367AA8FF.A2D3173@denali.neopath.com>
References: <36793932.F79C32CA@denali.neopath.com> <3679A45B.C2E8E588@ada.com>
Reply-To: tjackson

Whoops, that should have said Z85C30.  I've now got a good data sheet
on  the relevant control registers so I should be good to go.  I'll
write back if I run into trouble.  Thanks for the reply.  Tom

Matthew Downs wrote:
> 
> Tom jackson wrote:
> 
> > Anybody know how to assert/deassert the RTS/CTS lines using the Z35C30
> > driver in VxWorks?  Thanks
> >
> > Thomas B. Jackson
> > Neopath, Inc.
> > Phone: 425-869-7284
> > Fax:   425-869-5325
> 
> 85C30 or 35C30? I've used the 85C30 in my time, but not a 35C30.

- -- 
Thomas B. Jackson
Phone: 425-869-7284
Fax:   425-869-5325

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

Newsgroups: comp.os.vxworks
Subject: Network misbeviour
Date: Wed, 16 Dec 1998 08:34:41 -0800
From: "Dave Craig" <dcraig@euphonix.com>
Organization: Verio Northern California's Usenet News Service
Message-ID: <758neq$5ql$1@news.ncal.verio.com>

Here are some symptoms that we have in our system that I'm looking for some
insight into. We run on x86 with SENS...

* Two processors on a switched ethernet system communicate with each other
by broadcasting UDP messages.

* If severely loaded, one processor (lets call it A) gets into a state where
it no longer seems to get messages broadcast from B in real time. They
appear to accumulate in a buffer somewhere before finally the whole lot
avalanches through. No messages appear to be lost.

* However, the messages broadcast from processor A are all received by A
immediately (these do not go out on to the network but loopback at the IP
layer)

* Pinging processor A from another processor times out most of the
time...getting a target server to stay connected is difficult - unless there
is already a steady stream of ethernet messages from processor B which seems
to push the target server messages through (?!)

My question is whether anyone else has seen this, and more importantly at
what level in the SENS stack could such a problem be ocurring.

Thanks,

Dave Craig
Palo Alto



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

Newsgroups: comp.os.vxworks
Subject: man pages on NT
Date: Wed, 16 Dec 1998 08:44:17 -0800
From: "Abimael Pea" <apena@west.raytheon.com>
Organization: Raytheon Systems Company
Message-ID: <3677E360.3E88304C@west.raytheon.com>

I need info on how to make man pages on NT.

Any hints or help would be greatly appreciated.

Thanks in advance.

Abimael Pena
Raytheon Systems Company
El Segundo
apena@west.raytheon.com


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

Newsgroups: comp.os.vxworks
Subject: Re: SCSI disk
Date: Fri, 18 Dec 1998 13:55:12 -0600
From: "Dennis C." <dchou4u@hotmail.nospam.com>
Organization: Cisco Systems, Inc.
Message-ID: <75eit2$hm2$1@news-sj-2.cisco.com>
References: <75eenm$9dc$1@trsvr.tr.unisys.com>

WRS has drivers for this chip. Talk to their field people and they can quote
you a $. It is not cheap.



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

Newsgroups: comp.os.vxworks
Subject: Re: Zip software needed
Date: Fri, 18 Dec 1998 13:54:36 -0600
From: "Dennis C." <dchou4u@hotmail.nospam.com>
Organization: Cisco Systems, Inc.
Message-ID: <75eiru$hi4$1@news-sj-2.cisco.com>
References: <367AA955.ECDE28E7@ada.com>

VxWorks BSP has a compression routine that it uses to uncompress a
compressed image. Perhaps you can use that same routine.



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

Newsgroups: comp.os.vxworks
Subject: Re: Tornado + Version Control integration
Date: Sat, 19 Dec 1998 01:35:16 GMT
From: weatp@syntron.com (Peter Weatherall)
Message-ID: <367b0209.287540781@news.phoenix.net>
References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il> <1998121719370883839@zetnet.co.uk> <367A7ADA.8EED1B31@nortelnetworks.com>

I have a SourceSafe 6.0 installation setup. I haven't quite yet got
around to attempting to integrate with Tornado...

Peter


On Fri, 18 Dec 1998 10:55:06 -0500, Tim Sohacki
<sohacki@nortelnetworks.com> wrote:

>> Wind River announced in a recent seminar that Tornado II will have
>> hooks to allow 3rd party tools to interface to the development
>> environment. They mentioned version control systems in particular.
>
>
>The Tornado II Beta Release Notes (page 9) document specifically 
>mentions integration with ClearCase, which is what Wind River uses.
>
>We're currently using Visual Source Safe.
>Anyone had any experience integrating VSS and Tornado? 
>
>Cheers,
>Tim
>
>
>
>-- 
>Tim Sohacki, Nortel Networks
>email: sohacki@nortelnetworks.com


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

Newsgroups: comp.os.vxworks
Subject: Any Experience with Posix Message Queues?
Date: Wed, 16 Dec 1998 20:52:17 GMT
From: Ephraim Ezekiel <eezekiel@bbn.com>
Organization: Quarry Technologies
Message-ID: <36781D29.BDCDAD5@bbn.com>


We are considering using Posix Message queues as our primary
mechanism for IPC between tasks. The only advantage of using
them is the ability to notify a task to wake up via a signal
when a message is posted on a queue, which therefore allows
a task to wait on multiple queues.

Has anyone had experience with VxWorks implementation of
Posix queues? How does it compare to VxWork's message
queues? Are they reliable? We also considered using UDP
sockets but ruled it out due to too much CPU overhead.

Thanks,
- - Ephraim


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

Newsgroups: comp.os.vxworks
Subject: arp proxy form VME backplane to ethernet
Date: Wed, 16 Dec 1998 14:48:08 -0800
From: Randy Kizer <randy@pcsweb.net>
Organization: TRW, Inc.
Message-ID: <36783834.25F4@pcsweb.net>

I have some questions about how arp proxy works on vxworks.

When there is a VME chassis with many cards with VxWorks and one gateway
to the ethernet, how is the ip address mapped to the hosts on the
ethernet?  i.e. does the chassis controller report the arp mapping to
the ethernet hosts or does each card report itself to the ethernet
hosts?

If it is the chassis controller that reports it, how can I get vxworks
to report a non vxworks card to the ethernet hosts?

Thanks,
Randy Kizer
TRW
randy.kizer@trw.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Network misbeviour
Date: Wed, 16 Dec 1998 16:28:10 -0800
From: "Dave Craig" <dcraig@euphonix.com>
Organization: Verio Northern California's Usenet News Service
Message-ID: <759j6t$j4f$1@news.ncal.verio.com>
References: <758neq$5ql$1@news.ncal.verio.com>

The problem turned out to be...

Our END driver does not handle overflows at all well. We don't have source
for it - though I know that it is very similar to the templateEnd example
(it prints out the same debug and was written by WRS). What was happening is
that netTask was being locked out (due to a priority inversion) which
resulted in an overflow of packets on the ethernet chip. This is because at
interrupt time the END driver does very little except for scheduling some
foreground time to process the received packets. If it doesn't get the
foreground time, the chip will likely overflow. By fixing the priority
inversion and setting netTask priority suitably high netTask always manages
to get in before an overflow occurs on the chip and thus skirts around the
driver bug.

The driver bug appears to be that the receive ring buffer gets confused by a
message overflow. After this it reacts to network interrupts but fails to
process the received message because it's trying to read the wrong one from
the ring - maybe the ring buffer in/out pointers have got back to front?.
The messages are all flushed out when the ring buffer has cycled round - but
for some reason the problem doesn't self rectify as one might hope and this
behavious continues.

Dave Craig.




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

Newsgroups: comp.os.vxworks
Subject: Re: embedded HTTP
Date: 17 Dec 1998 03:36:52 GMT
From: kbeckley@aol.com (KBeckley)
Organization: AOL http://www.aol.com
Message-ID: <19981216223652.07675.00000289@ng-ce1.aol.com>
References: <74ognu$nsv@newstoo.ericsson.se>

Wind River has Wind Web Server which can setup an embedded http server that can
also use CGIs, java, and javascripts.  Another package that has just come out
is HTMLWorks which works similar to the Wind Web Server.  Currently the
HTMLWorks has only been ported to the x86 platform.  I am currently developing
with the Wind Web Server on a 68k platform.

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

Newsgroups: comp.os.vxworks
Subject: DDD For Tornado/vxWorks?
Date: Sat, 19 Dec 1998 08:44:45 -0600
From: "Peter A. Koren" <pkoren@hex.net>
Organization: Family
Message-ID: <367BBBDD.66F40902@hex.net>
Reply-To: pkoren@hex.zap-this.net

Hi,

I saw a reference to DDD being available for Tornado/vxWorks
recently, but I can't find the copy I thought I made. Can
anybody steer me to the DDD info.

Thanks,

Peter Koren

- -- 
Remove the 'zap-this' from the email address to reach me.

"One may proceed from absurd premise to ridiculous
conclusion with impeccable
logic." -- Santayana

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

Newsgroups: comp.arch.embedded,comp.sys.powerpc.tech,comp.sys.powerpc,comp.os.vxworks
Subject: Re: PowerPc assembler & system tick accuracy
Date: Sat, 19 Dec 1998 18:01:13 +0100
From: Ola Liljedahl <olli@enea.se>
Organization: Enea Data AB
Message-ID: <367BDBD9.C6272F96@enea.se>
References: <36760043.5D1F4E4E@ecitele.com>

Yosi Yarchi wrote:
> 
> The following is source copied from vxWorks system timer interrupt
> routine, which is based on the decrementer function of the PowerPc (in
> this case: MPC860). I'm looking for some explanation about the syntax in
> this code: (1) what is the %0 (implemented by the compiler as r9
> register). (2) what means the colon character (appears at the begining
> of the last 3 lines). (3) what means of the "r", "3", and "cc" commands
> which have special inverted commas (" ")? as I could see, these lines
> have no effect on the code generated by the compiler. (4) can someone
> explain me the trick of compensation of the interrupt latency which is
> implemented here in the loop(it required because the decrementer is not
> auto reloaded)?
VxWorks is using the gnu compiler. So this example is using gcc inline
assembly. Download any gcc manual and this should be explained under
gcc extensions to the C language.

Answers:
1) %0 is the first parameter (decCountVal in this case). The compiler
will
   supply a proper register when compiling.
2) the syntax of gcc inline assembly is
   __asm__("string with instructions" : output operands : input operands
: side effects );
3) "r" means the parameter should be passed in a normal register
   gcc for 68k has "d" for data register and "a" for address register
   (I think, it was a while ago). PowerPC only has general purpose
   registers, "r". "3" and "cc" after the last colon means these
registers
   are thrashed by the inline assembly. All other registers are
unmodified
   (except for the register used for %0 but that is under control of the
   compiler).
4: Don't know. I am no VxWorks expert. Actually I am a VxWorks enemy.
Please
   consider OSE for your next project!
> 
> Thank you
> Yosi
> 
> __asm__ ("
>     mfdec       3
> sysClkIntLoop:
>     add.        3, %0, 3
>     ble         sysClkIntLoop           /* check if we missed tick(s) */
> 
>     mtdec       3"
>     :                                   /* no output operands  */
>     : "r" (decCountVal)                 /* input operand, %0 =
> decCountVal */
>     : "3", "cc"/* side-effects: r3 clobbered, 'condition code' is
> clobbered */
>     );
- --
	Ola Liljedahl
	olli@enea.se
	Enea OSE Systems
	"OSE - Design on a higher level"

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

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


From owner-vxwexplo-process  Sun Dec 20 23:58:11 1998
From: "Morbitzer, Dirk ZFL-Calden LE2" <dirk.morbitzer@zf-group.de>
Date: Sun Dec 20 23:58:14 PST 1998
Subject: Tornado and Matlab's Real-Time Workshop

Hi VxWorks Users!

I am looking for any experience of Tornado in combination with
automaticly generated code from Matlab's Real-Time Workshop.
We are seeking a straight rapid prototyping solution from Simulink to
controller on target system with as little code hacking as possible. 

Please send any information on that topic.


Best regards,

Dirk Morbitzer



---------------------------------------------
	Dirk Morbitzer
	Development Rotor Components

	ZF Luftfahrttechnik GmbH
	P.O. Box 101667
	34016 Kassel, Germany
	
	eMail:   dirk.morbitzer@zf-group.de
	Phone:   +49 (0)5674 701-414
	Fax:     +49 (0)5674 701-345
---------------------------------------------



From owner-vxwexplo-process  Mon Dec 21 04:00:12 1998
From: daemon@csg.lbl.gov
Date: Mon Dec 21 04:00:15 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Mon Dec 21 04:00:06 PST 1998

        Subject: Need help: BIOS for Intel x86 and TX chipsets
        Subject: Re: Tornado + Version Control integration
        Subject: Re: Dec Ethernet Driver?
        Subject: Re: Tornado + Version Control integration
        Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency
        Subject: Exception: Interrupt Level 11 2ce card - 2nd request
        Subject: re: Multiple ethernet port - routing troubles.
        Subject: Re: off topic question
        Subject: off topic question
        Subject: Re: Target server windowsNT
        Subject: Re: Tools to track memory leaks
        Subject: Message Passing Interface (MPI) in VxWorks?

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

Newsgroups: comp.os.vxworks
Subject: Need help: BIOS for Intel x86 and TX chipsets
Date: Thu, 17 Dec 1998 08:10:13 -0500
From: John Kang <john.kang@alliedsignal.com>
Organization: AlliedSignal Inc.
Message-ID: <367902B5.A0978014@alliedsignal.com>

Hello.

We're developing a Pentium board with Intel TX chipsets.
It looks like there is a lot to do just to get system RAM alive, not to
mention getting PCI and ISA bus alive.

Does anyone know where we can get source code for commercially available
BIOS?

Thanks in advance.



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

Newsgroups: comp.os.vxworks
Subject: Re: Tornado + Version Control integration
Date: Thu, 17 Dec 1998 17:36:26 +0200
From: "Saffi Hartal" <saffi@globaloop.com>
Organization: NetVision Israel	
Message-ID: <75b9fp$787$1@news.netvision.net.il>
References: <36784811.108860281@news.phoenix.net>

Hi Peter Most people use make external IDE different from Tornado (we use
CodeWright), with version control.
It is a good solution that works fine.

do it and enjoy your work.
        Saffi

Peter Weatherall wrote in message <36784811.108860281@news.phoenix.net>...
>Has anyone integrated Tornado with a source code version control
>system ? Some IDEs have this built-in. Any ideas about what is the
>best approach with Tornado...
>
>
>Thanks
>Peter



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

Newsgroups: comp.os.vxworks
Subject: Re: Dec Ethernet Driver?
Date: Thu, 17 Dec 1998 19:44:39 GMT
From: gtsang@glenayre.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <75bmv6$79n$1@nnrp1.dejanews.com>
References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net>

In article <36778DFF.D92F63F2@ibm.net>,
  Dan DeVault <devault@ibm.net> wrote:
> Wind River has a driver that works with the SENS stack.  At least for
> the Motorola MTX604 BSP.  We are trouble shooting some problems with it
> now.
>
> Dan DeVault
> IBM Global Network
> devault@ibm.net

Hi Dan,

We have almost the exact config (MVME604, SENS) and I am having problem
bringing the driver up for DEC21143 (we did so for DEC21140). We have already
found a few bugs in this "END" driver.

Gilbert Tsang
Glenarye R&D Inc.

>
> Frankie Sierra wrote:
>
> > I am looking for a Dec 21140, or 21143 Ethernet driver for use with
> > VxWorks 5.1.3? Anyone done this? Any issues, caviats?
> >
> > Frankie Sierra
> > sierra@teralogic-inc.com
>
>

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: Re: Tornado + Version Control integration
Date: Thu, 17 Dec 1998 19:37:08 GMT
From: David & Bella Aldrich <davidandbella@zetnet.co.uk>
Message-ID: <1998121719370883839@zetnet.co.uk>
References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il>

Wind River announced in a recent seminar that Tornado II will have 
hooks to allow 3rd party tools to interface to the development 
environment. They mentioned version control systems in particular.

David


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

Newsgroups: comp.os.vxworks,comp.realtime,misc.jobs.contract
Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency
Date: 18 Dec 1998 01:14:59 GMT
From: Tate Consulting <hotjobs@tateinc.com>
Organization: Tate Consulting, Inc.
Message-ID: <75caaj$kaj$18@remarQ.com>



Fortune 100 Company needs contractor to work on CHORUS and VxWorks  
Drivers and OS tuning.

Refer to Job Code: JC-A10078-01.

Please reference the JOB CODE listed above in any correspondence
to us.  Send your resume in ASCII or MSWord format to:

Email:	hotjobs@tateinc.com
Fax:	(561) 852-2385
Snail:	Tate Consulting, Inc.
	10647 Avenida Santa Ana
	Boca Raton, FL  33498

Please visit our Hi-Tech Job Database at http://www.tateinc.com

Tate Consulting is a Computer Consulting and Placement Company
in business since 1991.

Andrew Tate, President/Owner
Tate Consulting, Inc.
atate@tateinc.com
(561) 852-TATE (8283)

We are an EOE.










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

Newsgroups: comp.os.vxworks
Subject: Exception: Interrupt Level 11 2ce card - 2nd request
Date: Thu, 17 Dec 1998 20:36:38 -0500
From: "Albert S. Johnston" <johnston@hom.net>
Message-ID: <3679B1A5.E8CDFA27@hom.net>

>Exception: Interrupt Level 11
>program counter:            0x0002d4fc
>next program counter:       0x0002d500
>processor status register:  0x904010c1


It looks like the below problem was defective hardware.  But...

I had noone reply to my inquiry... If one of you guru's understand
this trap/exception would you please explain it to me...

the discription (in the v8 arch manual) of the conditions  that cause
this
trap
seems to me to be a "normal" condition... ie one that should not cause
an
exception.  There may be a typo in my book, or maybe I just am miss-
understanding what it is saying...

Would one of you guys please explain this to me...

1) is the exception being raised because ET=1 AND
(IR=11) > (IPL=0)

and if so,

2) what is wrong with this happening?  ET=1 means traps are enabled.
IPL=0 means int request levels above level 0 are enabled (which means
ALL inturrupts are enabled) and IR=11 means a request at level 11 came
in.... so why is that an "exception"

somebody give me a clue PLEASE.

more details follow...

> HELP....
>
> some sparc guru out there explain this to me.  I am occasonally
getting
> the following msg
>
> Exception: Interrupt Level 11
> program counter:            0x0002d4fc
> next program counter:       0x0002d500
> processor status register:  0x904010c1
> Task: 0xebf2c0 "rsiSvc"
>
> When I look this up the the arch manual, it says:
>
> "interrupt_level_n : an external interrupt request level (bp_IRL)
> of value n was presented to the IU, while
>     ET=1 AND ( (bp_IRL=15) OR (bp_IRL>PIL))."
>
> if traps are enabled (ET=1) what in the world is wrong with
> getting a level 15 (nmi) interrupt, or an interrupt that is larger
> then the current PIL?  PIL is defined in the manual to be
> the IL ABOVE which the processor will accept the interrupt.
>
> Is the line " ET=1 AND ( (bp_IRL=15) OR (bp_IRL>PIL))."
> a very bad typo?  if so, what should it be?  If not, why am I
> totally confused about this????
>
> Okay, the psr (shown above) decodes to ET=0 and PIL=0,
> which means, according to the book, this exception CAN NOT
> be raised in this situation.... what gives?  What is happening????
>
> thanks,
>             -al







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

Newsgroups: comp.os.vxworks
Subject: re: Multiple ethernet port - routing troubles.
Date: Sun, 20 Dec 1998 22:06:21 GMT
From: johnchann@home.deletethis.com (John Chann)
Organization: @Home Network
Message-ID: <xxef2.501$KT5.530@news.rdc1.sfba.home.com>
References: <199812180939.JAA21105@dsl-2.tadpole.co.uk>

Good answer except...

If you are using SENS you should try calling mRouteAdd() and make the subnet 
mask tight like 255.255.255.240 then the system will only see the last four 
bits as part of this subnet.

IP forwarding is controlled by a variable in BSD 4.3 networking and by a bit 
in a control flags variable in SENS. I think the first is ipForwarding and the 
second is ipFlags. Try looking through usrConfig.c.

Last but not least if you are using SENS you should get the SENS 1.1 update 
from the WRS web site (http://www.wrs.com/) which fixes a number of issues in 
SENS 1.0.

JRC


In article <199812180939.JAA21105@dsl-2.tadpole.co.uk>, David Laight 
<dsl@tadpole.co.uk> wrote:
>You need to read up on IP routing.
>
>In practise you need to:
>  1) Put each interface on a system into a DIFFERENT subnet
>  2) Connect each interface to a diferent physical LAN
>  3) Only have one system/router linking any two subnets
>     A problem because I don't believe you can disable IP-Forwarding in
> vxWorks.
>
>If you don't do the above packets will not go out the expected interfaces.
>
>Another possible area of confusion is that the typical Unix 'ping' does an 
>address to name lookup on every returned packet.  Misconinfigured DNS and the 
>broken resolv code can cause this to take a long time.
>
>        David
>----------------------------------------------------------------
>David Laight                          email: dsl@tadpole.co.uk
>Tadpole Technology plc                phone: +44 1223 278 256
>Cambridge, UK                         fax:   +44 1223 278 201
>

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

Newsgroups: comp.os.vxworks
Subject: Re: off topic question
Date: Sun, 20 Dec 1998 22:19:01 GMT
From: johnchann@home.deletethis.com (John Chann)
Organization: @Home Network
Message-ID: <pJef2.502$KT5.505@news.rdc1.sfba.home.com>
References: <01be2a8e$653ef520$b7c310ac@ndsuk1063>

Being of an untrusting nature I have never expected to be able to recover data 
with a structure definition in anything execpt Ada (Oooo loveley 
representation clauses!) so I've always used pointers for this. 

I suppose you have to decide between wasted bandwidth and wasted processing.

JRC

In article <01be2a8e$653ef520$b7c310ac@ndsuk1063>, "Robert Stedman" 
<rstedman@nospamplease.ndsuk.com> wrote:
>I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc
>compiler for both ends.  Packing structures at the target side is achieved
>with  __attribute__ ((packed)), however this doesn't work at the Sun side. 
>Any ideas on how to coerce gcc to pack structures on a Sun would be
>gratefully received (#pragma pack (1) doesn't do the trick either)
>Thanks
>Rob.

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

Newsgroups: comp.os.vxworks
Subject: off topic question
Date: 18 Dec 1998 13:57:50 GMT
From: "Robert Stedman" <rstedman@nospamplease.ndsuk.com>
Organization: NDS Broadcast, Eastleigh, UK
Message-ID: <01be2a8e$653ef520$b7c310ac@ndsuk1063>

I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc
compiler for both ends.  Packing structures at the target side is achieved
with  __attribute__ ((packed)), however this doesn't work at the Sun side. 
Any ideas on how to coerce gcc to pack structures on a Sun would be
gratefully received (#pragma pack (1) doesn't do the trick either)
Thanks
Rob.
- -- 
Rob Stedman
NDS UK
rstedman@nospamplease.ndsuk.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Target server windowsNT
Date: Fri, 18 Dec 1998 17:25:02 GMT
From: mark-oliver.heger@hgw.scn.de
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <75e35a$7oi$1@nnrp1.dejanews.com>
References: <366E95FF.8698382D@scanmar.no>

In article <366E95FF.8698382D@scanmar.no>,
  Ole Asbjorn Fadum <OleAsbjornF@scanmar.no> wrote:
> Hi
>
> I could not manage to get the targetserver get the file image from the
> target correctly. I've done two experiments but could not find out what
> is wrong:
>
> 1. My host is called oaf, then if I try to start the targetserver I've
> got the following errormessage: 'could not open
> D:/Tornado/oaf:Tornado/target/config/pc486/vxworks'
>
> I though this may be that the WindowsNT, didn't like that I've called
> the host (VxWorks boot parameters) for 'oaf' so I cleared the host name.
>
> 2. This time I've got the following error: 'could not open
> D:/Tornado/Tornado/target/config/pc486/vxworks'
>
> The same error messages appear on both the command prompt start of the
> target server and the start from the tools menu. Where did the extra
> Tornado came from??
>
>

You have to configure your target server with the -c option. -c filename
(filename specifies the path to the core file explicity)  The host with the
running target server must have read access to this location (local drive or
mapped network drive).

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: Re: Tools to track memory leaks
Date: Mon, 21 Dec 1998 12:02:00 +0100
From: Roberto Nunnari <roberto.nunnari@agie.ch>
Organization: AGIE
Message-ID: <367E2AA8.BE3F5054@agie.ch>
References: <75erfp$smr$1@nnrp1.dejanews.com>

- - rtiLib from rti. They come boundled with Sthetoscope
- - codeTest

Robi

sanavr@hotmail.com wrote:

> Hi, I am working on optimizing the memory usage on an ATM interface card
> running vxWorks. I would like to know whether there are any  tools available
> in the market to track the memory leaks and to measure the utilization of
> memory on vxworks. Something similar to purify on unix. Any kind of inputs to
> instrument a piece of code running under vxworks to track the memory are very
> much appreciated. Thank you, Venkat
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

Newsgroups: comp.os.vxworks
Subject: Message Passing Interface (MPI) in VxWorks?
Date: Fri, 18 Dec 1998 13:48:35 -0600
From: John Courtney <John.L.Courtney@gd-is.com>
Organization: General Dynamics Information Systems
Message-ID: <367AB193.665D4B86@gd-is.com>

The Message Passing Interface (MPI) standard specifies
mechanisms for passing messages between processes on
different computers. MPI is popular in the supercomputer
and parallel processing community. 
Has anyone ported/implemented MPI to/on VxWorks?
Did you start from scratch?
Did you port an existing MPI suite?
How long did it take?
Is it publically available?

Thanks,
John Courtney       john.l.courtney@gd-is.com
General Dynamics Information Systems

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

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


From owner-vxwexplo-process  Mon Dec 21 07:56:13 1998
From: Roger Cruz <cruz_nojunk@xyplex.com>
Date: Mon Dec 21 07:56:16 PST 1998
Subject: Re: Booting VxWorks from hard-disk

I believe this is due to the fact that vxsys places a loader in Sector
0 similar to the DOS sys cmd.  Because of its small size, it can't
search sub-directories looking for bootrom.sys, therefore, you need to
place it in the root directory.  The other possibility is that you
didn't use vxcopy to copy the bootrom image generated by the compile to
the hard disk correctly.

Let me know  if you need further help.

Roger.

PS: remove "_nojunk" from email address

From: david.hagood@ifrsys.com

I do a vxsys c:\, and it works.
I copy a:bootrom.sys c:\bootrom.sys, and it works
I verify that bootrom.sys is contiguous.
I reboot the machine.
VxLd complains that it cannot find bootrom.sys

The bootrom.sys I copied over loaded fine from the floppy.
vxworks, VxWorks

-- 
Roger Cruz                           cruz_nojunk@xyplex.com
Xyplex Networks                      w: 978-952-4783
295 Foster Street                    f: 978-952-4887
Littleton, MA 01460


From owner-vxwexplo-process  Mon Dec 21 11:13:15 1998
From: Friedrich Scheurer / ZFS <zfssrr@zfssun6.tz.rus.uni-stuttgart.de>
Date: Mon Dec 21 11:13:18 PST 1998
Subject: InterbusS under VxWorks

Hello VxWorkers,

is there anyone having experience with 
InterbusS-Interface under VxWorks and the x86-platform?

We need a InterbusS-card (Master, PCI or ISA) and 
an acompanied driver to connect a CNC and a PLC.

Are there any experiences out there?

Any help appreciated!


Best regards

Friedrich Scheurer

+-------------------------------------------------+
|                                                 |
| Dipl.-Ing. F. Scheurer                          |
|                                                 |
| c/o Zentrum Fertigungstechnik Stuttgart         |
| Arbeitsbereich Steuerungstechnik                |
| Nobelstrasse 15                                 |
| D-70569 Stuttgart                               |
|                                                 |
| Telefon +49 711 13162-41(-0)                    |
| Fax     +49 711 13162-11                        |
| E-Mail  scheurer@zfs.rus.uni-stuttgart.de       |
|         zfssrr@zfssun6.tz.rus.uni-stuttgart.de  |
+-------------------------------------------------+
| http://zfs.rus.uni-stuttgart.de                 |
+-------------------------------------------------+
|                                                 |
| privat:                                         |
| Telefon +49 7161 686362                         |
| Fax     +49 7161 686301                         |
| E-Mail  Friedrich.Scheurer@t-online.de          |
|                                                 |
+-------------------------------------------------+


From owner-vxwexplo-process  Tue Dec 22 04:00:24 1998
From: daemon@csg.lbl.gov
Date: Tue Dec 22 04:00:28 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Tue Dec 22 04:00:07 PST 1998

        Subject: Re: off topic question
        Subject: Exceptions and Signals
        Subject: Re: Dec Ethernet Driver?
        Subject: Tools to track memory leaks
        Subject: MPC860SAR I & D Cache : Relation with memory type?
        Subject: HELP Please - 2604 & Console IO
        Subject: Re: Problem w/ Tornado 1.0.1/mv147 kernel build...
        Subject: Re: vxWorks.st_rom in floppy
        Subject: Re: man pages on NT
        Subject: Re: Primer

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

Newsgroups: comp.os.vxworks
Subject: Re: off topic question
Date: Mon, 21 Dec 1998 08:19:17 -0500
From: Douglas Fraser <dwfraser@lucent.com>
Organization: Lucent Technologies
Message-ID: <367E4AD5.FC3633E5@lucent.com>
References: <01be2a8e$653ef520$b7c310ac@ndsuk1063>

Robert Stedman wrote:
> 
> I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc
> compiler for both ends.  Packing structures at the target side is achieved
> with  __attribute__ ((packed)), however this doesn't work at the Sun side.
> Any ideas on how to coerce gcc to pack structures on a Sun would be
> gratefully received (#pragma pack (1) doesn't do the trick either)
> Thanks
> Rob.

Packed structures are non-portable across heterogeneous platforms.
You are just begging for bugs if you do that. You may even find
failures between different compiler release for the same processor
as this attribute is wholly undefined. Also, even if you pack
structures on the MPC860, depending on the structure layout, you
will still have holes because the MPC860 can only access data
on naturally aligned addresses. See section 14.4.5 of the 
MPC860 User's Manual, Motorola document MPC860UM/AD REV. 1.

- -- 
Douglas Fraser
dwfraser@lucent.com

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

Newsgroups: comp.os.vxworks
Subject: Exceptions and Signals
Date: Mon, 21 Dec 1998 14:52:04 +0100
From: markus_mitterer@sbu1.storkgroup.com (Markus Mitterer)
Organization: STK-Kufstein
Message-ID: <MPG.10e81cac6e23b497989685@news.austria.eu.net>

Hi VxWorkers,
I could not found enough info about Exceptions and Signals in the VxWorks 
documentation. My target is a PPC mv2301 board.
I tried to do a bus error -> I got the signal SIGILL
I did a division by zero -> signal SIGILL. 
I do not know why I am always getting SIGILL instead of SIGFPE (floating 
point) or SIGBUS???

When I once save my enviroment with setjmp(), can i do several longjmp()s 
to this point??? 
I recognized that when I do the longjmp() more times I hang in the 
sigHandler-Routine (signal SIGILL -> "system call")
Is the enviroment saved again when I come back to this position with 
longjmp()???


Thanks in advance

Mark

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

Newsgroups: comp.os.vxworks
Subject: Re: Dec Ethernet Driver?
Date: Mon, 21 Dec 1998 14:12:20 +0100
From: "Pierre Duval" <pierre_duval@mcg.mot.com>
Organization: Motorola Inc.
Message-ID: <75lhn4$405$1@schbbs.mot.com>
References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> <75bmv6$79n$1@nnrp1.dejanews.com> <eb9vXZrK#GA.327@ntawwabp.compuserve.com>

To all,
For Motorola computer group boards there is a patch that can be asked to
your local MCG support.
It is an enhancement of the standard DEC driver.
There is a new DEC21x4x driver for the PowerPlus Architecture family. This
driver includes support for the dec21040, dec21140, and dec21143 chips as
well as fixes a problem with the driver's cache usage. This driver still has
the 100BaseT performance increases in BOTH directions, supports Full Duplex
and includes additional enhancements.
Hope that helps

Khoa wrote in message ...
>gtsang@glenayre.com wrote in message <75bmv6$79n$1@nnrp1.dejanews.com>...
>>We have almost the exact config (MVME604, SENS) and I am having problem
>>bringing the driver up for DEC21143 (we did so for DEC21140). We have
>already
>>found a few bugs in this "END" driver.
>>Gilbert Tsang
>>Glenarye R&D Inc.
>
>
>So does anyone know whether VxWorks has an updated patch for the driver or
>acknowledged this problem in an SPR?
>
>Khoa
>
>



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

Newsgroups: comp.os.vxworks
Subject: Tools to track memory leaks
Date: Sat, 19 Dec 1998 00:20:10 GMT
From: sanavr@hotmail.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <75erfp$smr$1@nnrp1.dejanews.com>

Hi, I am working on optimizing the memory usage on an ATM interface card
running vxWorks. I would like to know whether there are any  tools available
in the market to track the memory leaks and to measure the utilization of
memory on vxworks. Something similar to purify on unix. Any kind of inputs to
instrument a piece of code running under vxworks to track the memory are very
much appreciated. Thank you, Venkat

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: MPC860SAR I & D Cache : Relation with memory type?
Date: Mon, 21 Dec 1998 23:39:16 GMT
From: newsmine@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <75mm74$134$1@nnrp1.dejanews.com>

Hi All,

I am trying to activate the data and instruction caches on my MPC860SAR board.
I was wondering if anybody could share their experience with me on that. A few
questions I have are :

1.The ADS BSP we have has a couple of lines like

#ifdef	EDO_DRAM
   undef USER_I_CACHE_ENABLE
   undef USER_D_CACHE_ENABLE
   undef INCLUDE_CACHE_SUPPORT
#endif	/* EDO_DRAM */

What is the relationship between DRAM type and turning on the caches? Why
should the cache activation be restricted to SDRAM type of DRAM only?

2.A post earlier in this group mentioned that the caches must be disabled
initially and activated only from bootConfig.c or usrConfig.c. Why?

3.What areas of memory need to be excluded from caching on MPC860SAR? Only
the on-chip DPRAM or something else too? How do I specify these areas in
VxWorks?

4.Is it sufficient to define these macros in config.h and rebuild the BSP?
#define USER_I_CACHE_ENABLE
#define USER_D_CACHE_ENABLE
#define INCLUDE_CACHE_SUPPORT

5.Any performance indicators I may use to determine the speed-up gain?

Thanks a lot in anticipation.

Regards,
Mittal


- --
Mittal Monani
Spacebridge Networks Corporation  Hull J8X 3R1

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: HELP Please - 2604 & Console IO
Date: Sat, 19 Dec 1998 10:10:33 -0500
From: Peter <funonh2o@metrolink.net>
Message-ID: <367BC1E9.8CDED908@metrolink.net>

First, I have been browsing this NG for a few months now when I get the
opportunity.  Unfortunately, I am not able to view this (or any other
newsgroup) while at work.  As a result I am not able to view this NG as
often as I would like.  The posts that I have seen here when I do get
the opportunity are informative and have helped.  I am very new to
working with VxWorks (3 months) and am continuously coming across
questions alot of which I get answers (or ideas) from posts here.  I
cannot name all of the sources (names) that have provided information
that has helped, but I would like to express my thanks to all those who
provide information to this NG.

With that being stated, to lead into my question, here is some
background information.

H/W configuration:

Motorola MVME-2604 PPC SBC
DY-4 SVME 739 Serial I/F Card
Macrolink MVCP Serial I/F Card
BrandyWine IRIG-B I/F Card
Carroll Touch Touch Screen Display.

The Carroll Touch Display that we are using is a serial device (RS-232)
that emulates a VT320 terminal with additional capabilities for using
the touch screen.  This display is connected to the console port (COM1)
and is intended to also serve as the console.  The project team is
currently leaning towards having two tasks oriented to the user display,
one to handle the displaying of the data, and the second for the
processing of user inputs.  Our current implementation is turns OFF the
terminal echo using the ioctl funtion with the OPT_TERMINAL and
~OPT_ECHO flags.  Both tasks are spawned at the same priority level and
utilizing Mutual Exclusion semaphores.

The display routine will be providing continuous data updates during the
real-time processing function of the application, while at the same time
providing user feedback for user inputs whether it be by keyboard input
or touch screen activation.

Question/request for suggestion(s):

What would be the "best" way for working with the serial ports for
handling this?

Does anyone have any examples that they can provide?

Please respond to my e-mail address in addition to a NG post.  I do not
get to view the NG very frequently and would really appreciate receiving
the information.

Thank you in advance.  And, best wishes for this holiday season and for
the new year.
- --
Peter
- -----------------------------------------------
E-mail: funonh2o@metrolink.net (home)


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



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

Newsgroups: comp.os.vxworks
Subject: Re: Problem w/ Tornado 1.0.1/mv147 kernel build...
Date: 19 Dec 1998 20:47:43 GMT
From: fnordz@aol.com (Fnordz)
Organization: AOL http://www.aol.com
Message-ID: <19981219154743.14014.00001855@ng26.aol.com>
References: <3674C43C.A10C8220@uma.com>

You should check out the configdb.h file
produced by WindCFG.  configdb.h is
#included at the end of config.h.  After
inspecting configdb.h, you may find that
you have accidentally undefined some RTOS
component needed to boot the image.



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

Newsgroups: comp.os.vxworks
Subject: Re: vxWorks.st_rom in floppy
Date: 19 Dec 1998 20:55:16 GMT
From: fnordz@aol.com (Fnordz)
Organization: AOL http://www.aol.com
Message-ID: <19981219155516.14014.00001859@ng26.aol.com>
References: <3668D8BE.CDD4381B@aucoasia.com>

It was not clear in your posting whether you attempted the
multi-stage boot - bootrom_uncmp loads vxWorks.  Have
you tried this?  In other words, let the ROM BIOS use
bootrom_uncmp as the boot loader.  bootrom_uncmp should
be able to boot a rather large vxWorks image.



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

Newsgroups: comp.os.vxworks
Subject: Re: man pages on NT
Date: 19 Dec 1998 21:10:23 GMT
From: fnordz@aol.com (Fnordz)
Organization: AOL http://www.aol.com
Message-ID: <19981219161023.20337.00001921@ng25.aol.com>
References: <3677E360.3E88304C@west.raytheon.com>

Just taking a wild guess, but you could try
using MKS ToolKit, or try the Cygwin32
Beta 20 (free download from
www.cygnus.com).  Both of these packages
contain utilities which would commonly be
used to create and view UNIX style man
pages, and both packages run on Win32
machines (95 and NT).



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

Newsgroups: comp.os.vxworks
Subject: Re: Primer
Date: 19 Dec 1998 21:22:40 GMT
From: fnordz@aol.com (Fnordz)
Organization: AOL http://www.aol.com
Message-ID: <19981219162240.20337.00001931@ng25.aol.com>
References: <74rfco$jof@bgtnsc02.worldnet.att.net>

The following are some of the more
commonly available resources:

1.  The "VxWorks Programmer's Guide"      which comes with Tornado / VxWorks.

2.  Tornado Classes taught by WRS - your
      mileage may vary, as the class does not
      exclusively cover vxWorks API;
      WRS development tools are also discussed

3.  If you have purchased support, you can
     access an archive of vxWorks demo code
     on the "WindSurf" page 
     (www.wrs.com->support link)

4.  Publicly available archives of vxWorks
     code at:

      ftp://ftp.atd.ucar.edu/pub/vxworks/vx/
      http://www.pso.com/vxhacks.html




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

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


From owner-vxwexplo-process  Tue Dec 22 05:44:45 1998
From: =?iso-8859-1?Q?Ro=DFmy_Reinhard____ICN_CM_E?=
Date: Tue Dec 22 05:44:48 PST 1998
Subject: Tornado with NetROM

Hallo,

I am very unhappy about the support of WindRiver System, so I use this way
to solve my "Tornado with NetROM" problem.

The Tornado target agent can be configured to communicate with the
target server using the NetROM.
But in my case, the target server fails to connect to the target.

My question is whether anyone else has seen this, and more importantly
could such a problem be solving.

Could it be a problem, that the configuration of the memory is:
RAM start at the address 0x0
ROM (Flash 29f040) start at the address 0x200000

Thanks,

Reinhard Romy
ICN CM WE 322
Phone: +49-89-722-32633
FAX:    +49-89-722-32541
mailto:Reinhard.Rossmy@icn.siemens.de




From owner-vxwexplo-process  Tue Dec 22 07:37:20 1998
From: MacroSystem_FE_trahn@t-online.de (Thomas Rahn)
Date: Tue Dec 22 07:37:23 PST 1998
Subject: AW: Booting VxWorks from hard-disk

just one more idea:

in the request, David mentioned he "created the file system from 
VxWorks, so it ought to be a configuration that VxWorks likes."

That is a very optimistic approach....

Check out the boot block of your dos partition (not the MBR).  You must know 
where the partiton starts (offset in sectors). The Windriver partition demo 
software from the ftp-server will tell you.

    // read boot sector of partition
    partAtaLbaRW (ctrl, drive, offset, (UCHAR*)secBuf, O_RDONLY);

After using  dosFsVolFormat(...) to format the partition, the
data in secbuf[] it should be similar to

00  3 bytes  e9xxxx / ebxx90 jmp entry		= eb 3c 90
03  8 bytes  OEM Name				= "VXDOS516"
0b  2 bytes  Bytes per sector 			= 0x0200 = 512 
0d  1 byte   Sektoren pro Cluster 		= 2
0e  2 byte 	 Reserved sectors (boot record) 	= 2 
10  1 byte   Anzahl der FATs 			= 2
11  2 bytes  Anzahl der Root-Verz.eintrge 	= 0x0200 = 512
13  2 bytes  Anzahl der logischen Sektoren	= 0xa035 
15  1 byte   Media-Byte 				= 0xf8 (Festplatte)
16  2 bytes  Sektoren pro FAT			= 0x0051
18  2 bytes	 Sektoren pro Spur 		= 0x003f = 63
1a  2 bytes  Anzahl Kpfe 			= 0x0010
1c  2 bytes  Hidden Sectors (Part. Offset) 	= ?????

Maybe the entry at 0x1C is zero, then we are on the right track.

The function ataDevCreate(ctrl, drive, 0, offset) is designed to use an offset.  
The ATA device is intended to use several partitions. However,  the dosFs from 
Windriver assumes, it resides on a disk from the start on, not on a 
partition.  That's why dosFsVolFormat() *clears* the Hidden Sectors entry.

Try this:

    // this is the offset of the partition to the start of the disk
    (ULONG*)(secBuf[DOS_BOOT_NHIDDEN_SECS])=  offset;    

    // write back boot sector of partition
    partAtaLbaRW (ctrl, drive, offset, (UCHAR*)secBuf, O_WRONLY);


Anyway: partAtaLbaRW uses ataRawio() similar to the function used in the 
WRS demo code (look it up at the ftp server)


Happy Xmas

 

#=================================================#
# MS MacroSystem GmbH                 Thomas Rahn #
# Forschung und            tel: +49(0)6151-272576 #
# Entwicklung              fax: +49(0)6151-272577 #
#                     email: trahn@macrosystem.de #
#=================================================#





From owner-vxwexplo-process  Tue Dec 22 08:19:01 1998
From: Sergi Casas <sergi@bpo.hp.com>
Date: Tue Dec 22 08:19:04 PST 1998
Subject: Re: Tornado with NetROM

Reinhard Romy wrote:

> The Tornado target agent can be configured to communicate with the
> target server using the NetROM.
> But in my case, the target server fails to connect to the target.
>
> My question is whether anyone else has seen this, and more importantly
> could such a problem be solving.

NetROM is a very nice idea with a rather poor implementation. Its firmware has
some bugs (at least when I used it 1 year ago) that can make you crazy (beware
with the dual port base address command, I recommend to put DualPort Mem in
ROM offset 0 to avoid confusions), the supplied drivers need a lot of tweaking
for some concrete architectures because of NetROM dual port memory contention
problems, and the manuals are poor and contain many errors.

I would encourage you to try to solve these "minor" problems, because when it
works it is very useful in deeply embedded systems with no ethernet ports.

Depending on the architecture, the interrupt priorities mapping, and the write
protocol you may have very different problems; could you specify your system?
For example, I played with an i960JX, with some interrupts in priorities beyond
the OS intLockLevel (this is important!), and using read-read protocol.


>
>
> Could it be a problem, that the configuration of the memory is:
> RAM start at the address 0x0
> ROM (Flash 29f040) start at the address 0x200000

No, I cannot see any problem with that.

Cheers.

--

|===========================================================================|
| Sergi Casas                 #####  /  #####  Software Engineer  (R&D)     |
| Hewlett-Packard             ###   /_  _ ###                               |
| Barcelona Division (BCD)    ##   / / / / ##  mailto:sergi@bpo.hp.com      |
| Avda. Graells, 501          ##  / / /_/  ##                               |
| 08190 S. Cugat (Barcelona)  ###    /    ###                               |
| SPAIN                       ##### /   #####                               |
|===========================================================================|
| "The question of whether a computer can think is no more interesting than |
|  the question of whether a submarine can swim."  E. W. Dijkstra           |
|===========================================================================|





From owner-vxwexplo-process  Tue Dec 22 09:17:32 1998
From: Bill Pringlemeir <bpringlemeir@yahoo.com>
Date: Tue Dec 22 09:17:35 PST 1998
Subject: Re: man pages on NT

The following message is a courtesy copy of an article
that has been posted as well.

The Tornado man pages I have xxxx.1 use the groff program to create
pages in a displayable form.  I think that Linux/GNU is going
toward 'Info' pages.  They use 'tex' as source instead of groff.

MKS toolkit doesn't come with any (rof/troff/groff) tool.  I _believe_
the same is true for cygwin?  I have tried to format these on HP-UX, but 
was unable to get pages that displayed well with MKS man program (actually 
more).  I found that looking at the unformatted 'groff' files in emacs was
pretty good.  Emacs automatically syntax highlights them.

Is the 'tex-info' format being used on Solaris, HP-UX, etc.  I would
think that this would be a better format for WindRiver to use in the
long run.  There are many possible output formats from tex-info; HTML,
pdf, post-script, dvi, info, plain ascii, maybe even word (yech).  Maybe 
WR will switch to the tex-info format.

Bill

    fnordz> Just taking a wild guess, but you could try using MKS
    fnordz> ToolKit, or try the Cygwin32 Beta 20 (free download from
    fnordz> www.cygnus.com).  Both of these packages contain utilities
    fnordz> which would commonly be used to create and view UNIX style
    fnordz> man pages, and both packages run on Win32 machines (95 and
    fnordz> NT).

-- 
Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/"



From owner-vxwexplo-process  Tue Dec 22 09:25:17 1998
From: Bill Pringlemeir <bpringlemeir@yahoo.com>
Date: Tue Dec 22 09:25:20 PST 1998
Subject: ARM target and ARM compiler?

The following message is a courtesy copy of an article
that has been posted as well.

Does the compiler from ARM work with VxWorks?  I have heard that
it generates the best code for that platform.  The Green Hills
compiler seems to support more C++ functionality than either 'gcc'
or ARM, and it includes the EC++ libraries.

Does anyone have experiences with using the ARM or Green Hills compiler
on an ARM target?  I got the DIAB compiler to work with the the MPC821
and VxWorks.  DIAB gave better performance than the supplied GCC.

Does anyone know if WR will ever use the EGCS compiler.  EGCS has a better
backend to do instruction scheduling.  This is one of the reasons gcc
performs worse on ARM/PowerPC (RISC).  I did find that gcc was better than
the MRI compiler we have on a 68k processor.

Thanks,
Bill

-- 
Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/"



From owner-vxwexplo-process  Wed Dec 23 04:00:20 1998
From: daemon@csg.lbl.gov
Date: Wed Dec 23 04:00:24 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Wed Dec 23 04:00:08 PST 1998

        Subject: malloc() hanging with VxWorks on i960 platform
        Subject: ARM target and ARM compiler?
        Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
        Subject: Re: PC16550D UART drivers?
        Subject: What happens to command line arguments?
        Subject: Re: What happens to command line arguments?
        Subject: Wind River User Group
        Subject: VME Interrupts to MVME162
        Subject: Re: What happens to command line arguments?
        Subject: 68040 sensitivity to reads of FPSR ???
        Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
        Subject: Internet Resources
        Subject: Re: DDD For Tornado/vxWorks?

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

Newsgroups: comp.os.vxworks
Subject: malloc() hanging with VxWorks on i960 platform
Date: Tue, 22 Dec 1998 12:13:26 GMT
From: "Derek Syme" <dereks@librasyscom.co.uk>
Organization: Libra Syscom Ltd
Message-ID: <01be2da3$9ec6cb20$24b2dec2@server_1>


Hi,

We have an i960 based embedded system (64Mb RAM) running VxWorks.
We have seen occassional hangs in the call to malloc() when asking for a
large area of RAM (typically 20ish Mb). The call does not fail, it simply
hangs
forever.

We are fairly sure that there is sufficient RAM available before malloc()
is
called and it should be available in a single contiguous block.

Does anyone else have any experience of this problem and if so are there
any known fixes or workarounds?

Thanks in advance,
Mark Kobine

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

Newsgroups: comp.os.vxworks
Subject: ARM target and ARM compiler?
Date: 22 Dec 1998 12:19:24 -0500
From: Bill Pringlemeir <bpringlemeir@yahoo.com>
Organization: PSINet
Message-ID: <u4sqonlgj.fsf@teklogix.com>

Does the compiler from ARM work with VxWorks?  I have heard that
it generates the best code for that platform.  The Green Hills
compiler seems to support more C++ functionality than either 'gcc'
or ARM, and it includes the EC++ libraries.

Does anyone have experiences with using the ARM or Green Hills compiler
on an ARM target?  I got the DIAB compiler to work with the the MPC821
and VxWorks.  DIAB gave better performance than the supplied GCC.

Does anyone know if WR will ever use the EGCS compiler.  EGCS has a better
backend to do instruction scheduling.  This is one of the reasons gcc
performs worse on ARM/PowerPC (RISC).  I did find that gcc was better than
the MRI compiler we have on a 68k processor.

Thanks,
Bill

- -- 
Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/"

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

Newsgroups: comp.os.vxworks
Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
Date: Tue, 22 Dec 1998 10:48:25 -0800
From: Scott Johnson <sj_nospam@nospam.aracnet.com>
Organization: National Association for the Advancement of Computer Geeks
Message-ID: <367FE979.7BA0@nospam.aracnet.com>
References: <75mm74$134$1@nnrp1.dejanews.com>
Reply-To: sj_nospam@nospam.aracnet.com

newsmine@my-dejanews.com wrote:
> 
> Hi All,
> 
> I am trying to activate the data and instruction caches on my MPC860SAR board.
> I was wondering if anybody could share their experience with me on that. A few
> questions I have are :
> 
> 1.The ADS BSP we have has a couple of lines like
> 
> #ifdef  EDO_DRAM
>    undef USER_I_CACHE_ENABLE
>    undef USER_D_CACHE_ENABLE
>    undef INCLUDE_CACHE_SUPPORT
> #endif  /* EDO_DRAM */

Don't know about EDO ram in particular (and I can't think of any reason
why caching would NOT work with EDO)...

However, early version of the 860 family (mask revision A and B) have
caches that don't work.  It is possible (PURELY speculation on my part)
that ADS boards with EDO ram also have these earlier processors...

Also, one of the errata related to the caches might be affected by 
EDO ram.  Again, don't know for sure; go to Motorola's website if you
want to look at the errata.  (VERY important thing to do if you are
porting VxWorks to a custom board...)


 
> What is the relationship between DRAM type and turning on the caches? > Why should the cache activation be restricted to SDRAM type of DRAM > > only?

Other than erratas, there should be no reason.  Memory that cannot be
cached ain't very useful, after all...

 
> 2.A post earlier in this group mentioned that the caches must be 
> disabled initially and activated only from bootConfig.c or > usrConfig.c. Why?

That is how the processor turns on, for one thing--with caches disabled.
(Also, the caches are uninitialized, which is why romInit.s makes SURE
they are disabled.)

For another thing, proper cache operation also requires that the MMU
be turned on.  VxWorks does not enable the MMU until after quite a few
other things happen.  (You can run the caches without the MMU, but the 
only way to do so safely is to mark all of storage as "guarded"; which
kills system performance.)

 
> 3.What areas of memory need to be excluded from caching on MPC860SAR? > Only the on-chip DPRAM or something else too? How do I specify these 
> areas in VxWorks?

There is a data structure in sysLib.c called sysPhysMemDesc, which 
is where you define the memory layouts of your board.  (Did you get the
BSP developers kit???  The documentation explains all this stuff-sort
of.)

As far as caching strategy goes...in general, RAM should be
cached--unless it is an area of RAM being shared between more than one 
processor, or otherwise being read to or written from by something else
other than the CPU.  (This does not include other things internal to the
CPU, such as the SCC---external RAM accessed by the SCC may be safely 
cached).  The 860 family does not have support for bus snooping; so 
there is no way for an external bus master to know if memory it touches
is up-to-date, or to mark it dirty.  So turn off cacheing for any such 
memory.

For ROM (direct access), it depends on how you use it.  If you run
directly out of ROM, turn on the cache for ROM.  If all you do is use
ROM as a boot device and then run out of RAM, it doesn't matter--the
cache is disabled at this point anyway. :)  (Major surgery on your BSP
nonwithstanding.)  If you use ROM as a filesystem only... I'd do some
performance testing to verify this, but I suspect that this will run
faster with cacheing off.

If you have FLASH EEPROM, and should want to reprogram it, disable the 
cache before doing so.  (Better yet, keep the storage as uncached.)

Any area of memory which is used to map registers should be uncached and
guarded.

 
> 4.Is it sufficient to define these macros in config.h and rebuild the BSP?
> #define USER_I_CACHE_ENABLE
> #define USER_D_CACHE_ENABLE
> #define INCLUDE_CACHE_SUPPORT

To tun on the cache?  In general, yes.  But you ought to be turning on
the MMU as well, and that requires modifying the sysPhysMemDesc
structure.

And, if you have revision A or B silicon, you ought not be turning on
the cache at all.  (At least not the D cache; the instruction cache also
does have an error, but it is VERY rare.)

 
> 5.Any performance indicators I may use to determine the speed-up gain?

There is a package on the Motorola website which talks about optimizing 
the performance of the caches; it also includes some (primitive)
benchmarking software.  (This software only verifies that the CPU is 
operating as it should be; it doesn't determing whether cacheing or
not is faster for YOUR application.)

Don't have the specific URL handy, but it is in the "application notes"
section of the 860 page.

Hope this helps,

Scott

 
> Thanks a lot in anticipation.
> 
> Regards,
> Mittal
> 
> --
> Mittal Monani
> Spacebridge Networks Corporation  Hull J8X 3R1
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

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

Newsgroups: comp.os.vxworks
Subject: Re: PC16550D UART drivers?
Date: 22 Dec 1998 19:59:52 +0100
From: jusa@bbn.hp.com (Juergen Sang)
Message-ID: <367fec28.0@isoit370.bbn.hp.com>
References: <366410CC.2AF5661@orbitworld.net> <MPG.10df347ae37fee9698969c@news.supernews.com>

George Pontis (geo@z9.com) wrote:


George,

: You will find lots of serial drivers if you search the net for PC source 
: code. Almost all PCs built in the past five years use this UART or one 
: that is software-compatible with it. The drivers are a little tricky, but 
: I have seen several articles with example code. The "C User's Journal" 
: had a feature article with source in C several years ago. I'm sure there 

The folks at Windriver supplied us with a 16550 FIFO driver once we asked
them for it. It is not in the standard distribution, though.



- -- 

Cu, Jrgen

- ------------------------------------------------------------------
Jrgen Sang                           Phone +49-7031-14-8929
Hewlett Packard GmbH                  FAX   +49-7031-43-0349
Optical Communication Measurement
Herrenberger Str. 130
71034 Bblingen                       WWW (HP internal access)
Germany                               http://bidro63.bbn/~jusa
- ------------------------------------------------------------------
Geschaeftsfuehrer: Joerg Menno Harms (Vorsitzender), Hans-Guenter Hohmann,
                   Heribert Schmitz, Fritz Schuller, Rudi Speier
Vorsitzender des Aufsichtsrates: Franz Nawratil
Sitz der Gesellschaft: Boeblingen - Amtsgericht Boeblingen HRB 4081.
- ------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: What happens to command line arguments?
Date: 22 Dec 1998 20:53:15 GMT
From: rmd@swl.msd.ray.com (Regina DuBord {84134})
Organization: Raytheon Company
Message-ID: <75p0rr$j3v$1@swlmail.msd.ray.com>

Hi,

I have a conventional C program with a 'main'
function that takes command line arguments 
(i.e., its prototype is main(argc, char *argv[])).
It runs ok when I don't specify any arguments,
but when I do, the arguments seem to go to never-
never land and I don't know how to access them in
my program.  

For example, the first line of code in 'main' is
a debug statement that prints the value of argc.
Without any command line arguments, I get:

- -> main
argc is 0

If I add an argument, I get:

- -> main "-b"
argc is 28858832

Or if I take away the quotes, I get:

- -> main -b
argc is  -1751164

These values of argc are obviously garbage.  If I 
try to print out the associated argv's, I get a data
access exception.  

Does anybody know what happens to command line argu-
ments in VxWorks???  They certainly don't seem to get 
assigned to argv in a C program, though I haven't found 
*any* documentation about this.  Arrrgh (tearing my hair 
out, etc....)

Regina

- --
- -------------------------------------------------
Regina DuBord, Software Engineer
Advanced Modeling & Simulation Technology
Raytheon Systems Company
50 Apple Hill Dr. (T3MJ21)
Tewksbury, MA  01876
Voice:  (978) 858-4787   Fax:  (978) 858-4336                       
rmd@swl.msd.ray.com

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

Newsgroups: comp.os.vxworks
Subject: Re: What happens to command line arguments?
Date: Tue, 22 Dec 1998 23:01:22 GMT
From: bruce@CUTMEOUTscimisys.com (Bruce Wedding)
Organization: NeoSoft, Inc.  
Message-ID: <36822455.9388285@news.neosoft.com>
References: <75p0rr$j3v$1@swlmail.msd.ray.com>

On 22 Dec 1998 20:53:15 GMT, rmd@swl.msd.ray.com (Regina DuBord
{84134}) wrote:

>Does anybody know what happens to command line argu-
>ments in VxWorks???  They certainly don't seem to get 
>assigned to argv in a C program, though I haven't found 
>*any* documentation about this.  Arrrgh (tearing my hair 
>out, etc....)

This won't work.  If you need command line args, you will have to pass
them in just like VxWorks does in taskSpawn() and other places.   In
DOS or *NIX, the startup code processes the arguments and passes them
in.  You don't have that luxury here.


Bruce Wedding
Software Manager
bruce@scimisys.com
Scientific MicroSystems, Inc.
http://www.scimisys.com
Tomball, Texas

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

Newsgroups: comp.os.vxworks
Subject: Wind River User Group
Date: Tue, 22 Dec 1998 18:30:06 -0500
From: "Michael McGarry" <mcgarry@eclipse.net>
Message-ID: <75pa4j$s9a$1@news.eclipse.net>

Hello fellow VxWorks users,

Does anyone know of any Wind River User Groups in New Jersey?

If so, I would be interested in joining.

- --
Regards,

Michael McGarry, Firmware Engineer II
Cabletron Systems, Inc.
(732) 394-6041



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

Newsgroups: comp.os.vxworks
Subject: VME Interrupts to MVME162
Date: Tue, 22 Dec 1998 16:00:47 -0800
From: David Morris 222-7450 <cadfael@triumf.ca>
Organization: TRIUMF
Message-ID: <368032AF.90F2FEB8@triumf.ca>

Hello
  When all else has failed, ask the experts.

  I'm trying the get interrupts from a VME motor module to show up under
VxWorks 5.2

  The module generates IRQ5, I can see this on a bus monitor module. I
have the intConnect function to attach my ISR to the particular vector,
but all I get is a reboot. Arghh!

  Here's the code to get ints going. My vector is 180, for whatever
reason, but it should be valid. If I enable the interrupt in the
VMEchip, the system crashes. I suspect the vector is not working right,
since all the ISR does is call logMsg right now. I can read the vector
in the vector register on the board, so its OK.

 *pbdItem->pVectorRegister = sVector;

 if (ERROR == intConnect (INUM_TO_IVEC (sVector), (VOIDFUNCPTR)
omsInterrupt, (int) pbdItem))
  return OMS_ERROR_INTERRUPT;

 piVMEChip2 = (unsigned int *) 0xfff4006C;
*piVMEChip2 = 0x10;

 omsIoctl(pbdItem, NULL, ENABLE_INTERRUPTS);

Can anyone give me an idea of what is missing here? The lack of simple
information on Windserve or anywhere else is starting to get rather
frustrating.

- --
David B Morris                          TRIUMF
Systems Designer/Analyst                Canada's National Meson Facility
cadfael@triumf.ca                       4004 Wesbrook Mall
604-222-7450                            Vancouver, B.C. V6T 2A3

"Remember, no matter where you go, there you are." - Buckaroo Banzai




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

Newsgroups: comp.os.vxworks
Subject: Re: What happens to command line arguments?
Date: 23 Dec 1998 02:02:07 GMT
From: litwin@litwin (Todd Litwin)
Organization: Jet Propulsion Laboratory - Pasadena CA
Message-ID: <75piuv$6ai@netline.jpl.nasa.gov>
References: <75p0rr$j3v$1@swlmail.msd.ray.com>

Regina DuBord {84134} <rmd@swl.msd.ray.com> wrote:

>I have a conventional C program with a 'main'
>function that takes command line arguments 
>(i.e., its prototype is main(argc, char *argv[])).

As any number of experienced VxWorksers can tell you, there is nothing special
about a function called main() in VxWorks. It's just another function, and
it will get passed arguments the same way as any other. Thus when you do

>-> main "-b"

the system passes the pointer to the string "-b" as the first argument of main.

>argc is 28858832

This is the address of "-b".

If you want to do something more like the execution of a program from the
C-Shell in Unix, for example, you need to do alot more. Below is one simple
way of doing some of what you want. But be warned that you *cannot* just take
an arbitrary Unix program, compile it for VxWorks, and expect it to work in
general. There are all kinds of things to trip you up (compile-time-initialized
variables, calling exit(), etc.). Good luck.


/******************************************************************************
*                                                                             *
*                                  C M D                                      *
*                                                                             *
*                                    Todd Litwin                              *
*                                    Written: 21 Nov 1989                     *
*                                    Updated: 21 Nov 1989                     *
*                                                                             *
*******************************************************************************


	This function is used under VxWorks to call a program that has
	been written with a main() function that expects command-line
	arguments. */


cmd(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10)
char *arg1, *arg2, *arg3, *arg4, *arg5, *arg6, *arg7, *arg8, *arg9, *arg10;
{
    int argc, i;
    char *argv[11], **p;

    /* Initialize the program argument */
    argc = 1;
    argv[0] = "";

    /* Fill the list with the pointer values */
    argv[1]  = arg1;
    argv[2]  = arg2;
    argv[3]  = arg3;
    argv[4]  = arg4;
    argv[5]  = arg5;
    argv[6]  = arg6;
    argv[7]  = arg7;
    argv[8]  = arg8;
    argv[9]  = arg9;
    argv[10] = arg10;

    /* Determine the number of arguments */
    p = argv + 1;
    for (i=0; i<10; i++,p++,argc++)
	if (*p == 0)
	    break;

    /* Call the main function */
    main(argc, argv);
    return 0;
    }
- -- 
		Todd Litwin
		Jet Propulsion Laboratory
		(818) 354-5028
		Todd.E.Litwin@jpl.nasa.gov

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

Newsgroups: comp.os.linux.m68k,comp.os.vxworks,comp.sys.m68k
Subject: 68040 sensitivity to reads of FPSR ???
Date: Wed, 23 Dec 1998 05:24:17 GMT
From: "Don Bockenfeld" <don@fltvis.com>
Organization: FlashNet Communications, http://www.flash.net
Message-ID: <01be2e34$9dbdeec0$63cbc2d0@oemcomputer>

I am cross-posting this message to comp.os.linux.m68k, comp.os.vxworks, and
comp.sys.m68k; as well as sending it to Motorola technical support.  Once I
get our maintenance contract straightened out I will also send it to Wind
Rivers technical support.

Up until recently we have been using XC68040 chips [prototype 68040s] in
our embedded systems.  Ignoring for a moment the advisability of doing
this, we have discovered an odd variation in behavior between CPU lots.

In the old days (up until about 4 weeks ago) everything worked fine.  Then
we started using a newer lot of XC68040 chips and encountered two
discrepancies:

1.  Our CPU BIT [built-in test] detected that the seven unused bits of the
FPSR could no longer be written to and read back.  The newer CPUs only read
back zeroes for these bits regardless of what we wrote to them.  No big
deal, we revised the CPU test to not check those bits.  I'm not worried
about this discrepancy, but only include it in case it helps in figuring
out the following mystery...

2.  We use version 5.2 of the vxWorks RTOS from Wind River Systems, which
includes their variant of the FPSP.  We implemented a custom BSP for our
system.  It intermittently, but almost always, locked up during its startup
procedure after we installed the newer CPU chips.  This startup code is
part of the vxWorks object library and is currently a black box to us.  We
eventually determined that a single read of the FPSR at the beginning of
our reset exception handler permitted vxWorks to start up normally. 
Furthermore, we found that a software reset of the FPU (via FRESTORE of a
longword zero) after the dummy FPSR read caused the subsequent vxWorks
startup to lock up again; and that a second dummy FPSR read after the FPU
software reset permitted normal startup!  My unsupported hypothesis is that
FPU initialization, whether due to hardware or software reset, does not
complete properly until after the first read of the FPSR.

At this point we felt that the obvious solution to our problem was to get
rid of these XC68040 chips and start using real MC68040s.

We were amazed and dismayed to find that brand new MC68040 chips exhibited
both of these problems with precisely the same symptoms.

I can find nothing in the M68040 Microprocessors User's Manual (M68040UM/AD
Rev. 1) to suggest that reading FPSR does anything to affect the state of
the CPU.  Does anybody out there know what is going on?

Here are the identifications of the 68040 chips involved:

Original XC chips tht seemed to work fine:
	XC68040RC25
	20D43B
	DENF9110

Recent XC chips that exhibited the problems:
	(the print was very tiny so I might be mistaken)
	XC68040RC25B
	09D50D
	DEHM9152

Current MC chips that also exhibit the problems:
	MC68040RC25
	02E42K
	QQBF9814A

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

Newsgroups: comp.os.vxworks
Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
Date: Tue, 22 Dec 1998 23:14:48 -0800
From: Scott Johnson <sj_nospam@nospam.aracnet.com>
Organization: National Association for the Advancement of Computer Geeks
Message-ID: <36809868.1E4F@nospam.aracnet.com>
References: <75mm74$134$1@nnrp1.dejanews.com> <367FE979.7BA0@nospam.aracnet.com> <75ppc8$isj$1@nnrp1.dejanews.com>
Reply-To: sj_nospam@nospam.aracnet.com

john@kivala.com wrote:
> 
> In article <367FE979.7BA0@nospam.aracnet.com>,
>   sj_nospam@nospam.aracnet.com wrote:
> > newsmine@my-dejanews.com wrote:
> ...
> <good stuff deleted>
> ...
> > As far as caching strategy goes...in general, RAM should be
> > cached--unless it is an area of RAM being shared between more than one
> > processor, or otherwise being read to or written from by something else
> > other than the CPU.  (This does not include other things internal to the
> > CPU, such as the SCC---external RAM accessed by the SCC may be safely
> > cached).  The 860 family does not have support for bus snooping; so
> > there is no way for an external bus master to know if memory it touches
> > is up-to-date, or to mark it dirty.  So turn off cacheing for any such
> > memory.
> ...
> <more good stuff deleted>
> 
> I don't think the above is right. I think the CPM devices
> (including SCCs) are external as far as caching is concerned,
> so if your CPM devices use external memory, the memory should
> either be noncacheable or you should take care of caching
> issues manually.

If you are right, and I am wrong...that might explain one annoying 
bug we have been facing on our BSP... 

:)
 
> Perhaps some of you other 860 regulars could concur or
> straighten me out?

Yes, please do.

Scott

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

Newsgroups: comp.os.vxworks
Subject: Internet Resources
Date: Mon, 21 Dec 1998 12:03:32 -0800
From: Nina Pinto <npinto@eg3.com>
Organization: InterNex Information Services 1-800-595-3333
Message-ID: <367EA994.E2BA8A5E@eg3.com>

Pertinent to comp.os.vxworks, EG3 maintains a list of realtime Internet
resources, including FAQ's, papers, hot list pages,
potential software/shareware, all known companies, etc.

Specific pages are located at:

http://www.eg3.com/real/index.htm
http://www.eg3.com/realv/index.htm

These resource pages are published as part of EG3's Free Electronic
Engineers' Toolbox at:

http://www.eg3.com/index.htm

If you know of other resources, pertinent to comp.os.vxworks please
email me at:

ninapint@hotmail.com

Thanks!


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

Newsgroups: comp.os.vxworks
Subject: Re: DDD For Tornado/vxWorks?
Date: Wed, 23 Dec 1998 09:57:52 +0100
From: Chris Hellwig <hellwig@exp.bessy.de>
Message-ID: <3680B090.C2EF2198@exp.bessy.de>
References: <367BBBDD.66F40902@hex.net>

"Peter A. Koren" wrote:
> 
> Hi,
> 
> I saw a reference to DDD being available for Tornado/vxWorks
> recently, but I can't find the copy I thought I made. Can
> anybody steer me to the DDD info.
> 
> Thanks,
> 
> Peter Koren
> 
> --
> Remove the 'zap-this' from the email address to reach me.
> 
> "One may proceed from absurd premise to ridiculous
> conclusion with impeccable
> logic." -- Santayana


Yes,

  I'm using ddd with 

     /opt/ddd/bin/ddd -debugger "vxgdb68k -fullname"
  
  where vxgdb68k the GNU-dbg for vxWorks is. 


  You have to find a task

  tRdbTask   _rdbTask       f9ff20  20 PEND          6fb74  
f9fe00       0     0

  in your task list at the vxWorks-system.

Bye
  Chris

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

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


From owner-vxwexplo-process  Wed Dec 23 06:19:29 1998
From: Fred Roeber <froeber@bbn.com>
Date: Wed Dec 23 06:19:32 PST 1998
Subject: Re: comp.os.vxworks newsdigest

Dave Morris wrote:

>   I'm trying the get interrupts from a VME motor module to show up under
> VxWorks 5.2
> 
>   The module generates IRQ5, I can see this on a bus monitor module. I
> have the intConnect function to attach my ISR to the particular vector,
> but all I get is a reboot. Arghh!

This sort of sympton could be caused by external hardware continuously
generating interrupts. A lot of peripherals need to have some control
register twiddled to clear a pending interrupt condition. This is
normally done in the interrupt handler. If you don't do this, then the
signal will keep causing new interrupts and the system will reboot due
to a work queue overflow. Normally, it will try to print a message to
this affect but if your boards serial interrupt priority is lower than
level 5 then that won't show up either.

Just a thought.    Fred

-- 
   |      Fred J Roeber,  BBN Systems & Technologies      |
   |    4 John Clarke Road   Middletown, RI  02842-5202   |
   |          froeber@bbn.com     401-848-3548            |
   | TraceMaker product manager -> www.tracemaker.bbn.com |


From owner-vxwexplo-process  Wed Dec 23 09:26:52 1998
From: johill@lanl.gov (Jeff Hill)
Date: Wed Dec 23 09:26:55 PST 1998
Subject: RE: comp.os.vxworks newsdigest


vxWorks tornado

> Newsgroups: comp.os.vxworks
> Subject: VME Interrupts to MVME162
> Date: Tue, 22 Dec 1998 16:00:47 -0800
> From: David Morris 222-7450 <cadfael@triumf.ca>
> Organization: TRIUMF
> Message-ID: <368032AF.90F2FEB8@triumf.ca>
> 
> Hello
>   When all else has failed, ask the experts.
> 
>   I'm trying the get interrupts from a VME motor module to show up under
> VxWorks 5.2
> 
>   The module generates IRQ5, I can see this on a bus monitor module. I
> have the intConnect function to attach my ISR to the particular vector,
> but all I get is a reboot. Arghh!
> 
>   Here's the code to get ints going. My vector is 180, for whatever
> reason, but it should be valid. If I enable the interrupt in the
> VMEchip, the system crashes. I suspect the vector is not working right,
> since all the ISR does is call logMsg right now. I can read the vector
> in the vector register on the board, so its OK.
> 
>  *pbdItem->pVectorRegister = sVector;
> 
>  if (ERROR == intConnect (INUM_TO_IVEC (sVector), (VOIDFUNCPTR)
> omsInterrupt, (int) pbdItem))
>   return OMS_ERROR_INTERRUPT;
> 
>  piVMEChip2 = (unsigned int *) 0xfff4006C;
> *piVMEChip2 = 0x10;
> 
>  omsIoctl(pbdItem, NULL, ENABLE_INTERRUPTS);
> 
> Can anyone give me an idea of what is missing here? The lack of simple
> information on Windserve or anywhere else is starting to get rather
> frustrating.

Here are some possible causes of trouble:

1) You are not accessing the register in the OMS indexer that clears the
interrupt in your interrupt service routine.

2) Your IACK daisy chain is incomplete. If there are any empty slots
between your OMS stepper motor module and the CPU make certain that the
IACK daisy chain jumper has been installed for these slots on the backplane.

3) I cant comment on your change to the default VME Chip II configuration as I 
don't which register you are writing to, but it is normally not necessary to 
use anything other than sysIntEnable() to enable VME interrupts in a vxWorks 
system.

There is an OMS stepper motor indexer device driver in the EPICS source 
distribution. Rolf Keitel at Triumf has a copy.

Jeff

______________________________________________________
Jeffrey O. Hill                      Internet     johill@lanl.gov
LANL MS H820                    Voice         505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107



From owner-vxwexplo-process  Wed Dec 23 09:27:05 1998
From: johill@lanl.gov (Jeff Hill)
Date: Wed Dec 23 09:27:08 PST 1998
Subject: RE: comp.os.vxworks newsdigest


> Newsgroups: comp.os.vxworks
> Subject: VME Interrupts to MVME162
> Date: Tue, 22 Dec 1998 16:00:47 -0800
> From: David Morris 222-7450 <cadfael@triumf.ca>
> Organization: TRIUMF
> Message-ID: <368032AF.90F2FEB8@triumf.ca>
> 
> Hello
>   When all else has failed, ask the experts.
> 
>   I'm trying the get interrupts from a VME motor module to show up under
> VxWorks 5.2
> 
>   The module generates IRQ5, I can see this on a bus monitor module. I
> have the intConnect function to attach my ISR to the particular vector,
> but all I get is a reboot. Arghh!
> 
>   Here's the code to get ints going. My vector is 180, for whatever
> reason, but it should be valid. If I enable the interrupt in the
> VMEchip, the system crashes. I suspect the vector is not working right,
> since all the ISR does is call logMsg right now. I can read the vector
> in the vector register on the board, so its OK.
> 
>  *pbdItem->pVectorRegister = sVector;
> 
>  if (ERROR == intConnect (INUM_TO_IVEC (sVector), (VOIDFUNCPTR)
> omsInterrupt, (int) pbdItem))
>   return OMS_ERROR_INTERRUPT;
> 
>  piVMEChip2 = (unsigned int *) 0xfff4006C;
> *piVMEChip2 = 0x10;
> 
>  omsIoctl(pbdItem, NULL, ENABLE_INTERRUPTS);
> 
> Can anyone give me an idea of what is missing here? The lack of simple
> information on Windserve or anywhere else is starting to get rather
> frustrating.

Here are some possible causes of trouble:

1) You are not accessing the register in the OMS indexer that clears the
interrupt in your interrupt service routine.

2) Your IACK daisy chain is incomplete. If there are any empty slots
between your OMS stepper motor module and the CPU make certain that the
IACK daisy chain jumper has been installed for these slots on the backplane.

3) I cant comment on your change to the default VME Chip II configuration as I 
dont have an mv162 manual at the moment, but it is normally not necessary to 
use anything other than sysIntEnable() to enable VME interrupts in a vxWorks 
system.

There is an OMS stepper motor indexer device driver in the EPICS distribution.
Rolf Keitel at Triumf has a copy.

Jeff



From owner-vxwexplo-process  Wed Dec 23 11:49:45 1998
From: Dale Luck <dale@shoretel.com>
Date: Wed Dec 23 11:49:48 PST 1998
Subject: RE: comp.os.vxworks newsdigest (about what?)

Don't know what this message is about? Its because somebody replied to a
newsdigest and forgot to replace the subject line with the subject line from
the embedded message.
Please folks, if you read the digests and reply with helpful information,
please change the subject line so others can quickly see what it pertains
too.

Thanks
Dale

> -----Original Message-----
> From:	vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov]
> Sent:	Wednesday, December 23, 1998 9:27 AM
> To:	vxworks_users@csg.lbl.gov
> Subject:	RE: comp.os.vxworks newsdigest
> 
> Submitted-by owner-vxwexplo-process  Wed Dec 23 09:26:52 1998
> Submitted-by: name changed to protect the guilty  ;-)
> 
> 
> vxWorks tornado
> 
> > Newsgroups: comp.os.vxworks
> > Subject: VME Interrupts to MVME162
> 


From owner-vxwexplo-process  Wed Dec 23 16:48:32 1998
From: Alistair Adams <aadams@octanttech.com>
Date: Wed Dec 23 16:48:35 PST 1998
Subject: Fortran ggnu compiler?

Has anyone tried using the gnu FORTRAN compiler with VxWorks,
particularly with PowerPC?

Alistair Adams
Octant Technologies Inc.



From owner-vxwexplo-process  Thu Dec 24 04:00:12 1998
From: daemon@csg.lbl.gov
Date: Thu Dec 24 04:00:15 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Thu Dec 24 04:00:07 PST 1998

        Subject: powerpc-vxworks-gdb
        Subject: curses for vxworks
        Subject: Re: How does one wait on more than one object in VxWorks ?.
        Subject: Re: VME Interrupts to MVME162
        Subject: Re: off topic question
        Subject: Re: ARM target and ARM compiler?
        Subject: VxWorks, Rimfire 3573, 4GB Disks and NFS

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

Newsgroups: comp.os.vxworks
Subject: powerpc-vxworks-gdb
Date: Wed, 23 Dec 1998 13:11:59 +0100
From: Melih Ercan xe4 52754 <ercanm@access.bel.alcatel.be>
Organization: Alcatel Telecom
Message-ID: <3680DE0F.318C1F65@access.bel.alcatel.be>

Hi all,

I want to debug a powerpc(mpc860) vxworks build on a target(test)
board without using the tornado tools. But instead, I want to use
ddd/gdb
pair. When I check the gdb-4.17 release I saw the targets for:
vx29k, vx68, vx960, vxmips, vxsparc but not for powerpc. I think
the file remote-vxppc.c is required to build powerpc-vxworks-gdb.

Does anybody know where I can find this file or a prebuild gdb for
vxworks/powerpc target on solaris platform.

Thanx in advance.

Melih.



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

Newsgroups: comp.os.vxworks
Subject: curses for vxworks
Date: Thu, 24 Dec 1998 00:40:57 +0900
From: "ȫ" <jhong@hanimail.com>
Organization: ELIMnet Internet News
Message-ID: <36810F09.D02C3119@hanimail.com>

Hi there,

i am trying to find a curses library for vxworks.
I would appreciate any information.
thanks.

JaeHong Lee
jhong@hanimail.com
Institute for Advanced Engineering
South Korea



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

Newsgroups: comp.os.vxworks
Subject: Re: How does one wait on more than one object in VxWorks ?.
Date: 23 Dec 1998 16:53:57 GMT
From: litwin@litwin (Todd Litwin)
Organization: Jet Propulsion Laboratory - Pasadena CA
Message-ID: <75r775$ffk@netline.jpl.nasa.gov>
References: <75oucf$5b2@news.or.intel.com>

rvsaripa <ramakrishna_saripalli@intel.com> wrote:

>I have 2 semaphores and file descriptor I need to wait on at the same time
> in a certain task context that has access to them ).
>
>Can I use select() ?. When I read the documentation on select, it seems to
>take only file descriptors ( semaphores are not file descriptors, are they

Two mechanisms come to mind:

1. If you want to use select(), then try using pipes instead of semaphores.
   Look at the documentation for pipeDevCreate(). This will create a device,
   with a file descriptor usable in select(), that can be written to and read
   from, and can be used similar to a semaphore if desired.

2. Or you could use a single message queue. Look at msgQLib. Your different
   semaphores could be queued items with different (application-defined) ID
   numbers.

- -- 
		Todd Litwin
		Jet Propulsion Laboratory
		(818) 354-5028
		Todd.E.Litwin@jpl.nasa.gov

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

Newsgroups: comp.os.vxworks
Subject: Re: VME Interrupts to MVME162
Date: Wed, 23 Dec 1998 10:31:07 -0800
From: David Morris 222-7450 <cadfael@triumf.ca>
Organization: TRIUMF
Message-ID: <368136EB.E1877FB8@triumf.ca>
References: <368032AF.90F2FEB8@triumf.ca>

David Morris 222-7450 wrote:

> Hello
>   When all else has failed, ask the experts.
>
>   I'm trying the get interrupts from a VME motor module to show up under
> VxWorks 5.2
>
>   The module generates IRQ5, I can see this on a bus monitor module. I
> have the intConnect function to attach my ISR to the particular vector,
> but all I get is a reboot. Arghh!
>
>   Here's the code to get ints going. My vector is 180, for whatever
> reason, but it should be valid. If I enable the interrupt in the
> VMEchip, the system crashes. I suspect the vector is not working right,
> since all the ISR does is call logMsg right now. I can read the vector
> in the vector register on the board, so its OK.
>
>
> Can anyone give me an idea of what is missing here? The lack of simple
> information on Windserve or anywhere else is starting to get rather
> frustrating.
>

What was missing was that the interrupts for VME are level, not edge
triggered. The ISR must clear the interrupt line as part of it's work in
processing the interrupt. The motor module holds the INT line active until
the board status register is read, which clears all bit automatically. It
was re-interrupting over and over until meltdown.

Thanks to Fred Roeber for the solution!


- --
David B Morris                          TRIUMF
Systems Designer/Analyst                Canada's National Meson Facility
cadfael@triumf.ca                       4004 Wesbrook Mall
604-222-7450                            Vancouver, B.C. V6T 2A3

"Remember, no matter where you go, there you are." - Buckaroo Banzai




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

Newsgroups: comp.os.vxworks
Subject: Re: off topic question
Date: Wed, 23 Dec 1998 17:31:06 -0500
From: Douglas Fraser <dwfraser@lucent.com>
Organization: Lucent Technologies
Message-ID: <36816F2A.FC5FFB02@lucent.com>
References: <01be2a8e$653ef520$b7c310ac@ndsuk1063> <367E4AD5.FC3633E5@lucent.com> <01be2e8f$7c013ed0$b7c310ac@ndsuk1063>

Robert Stedman wrote:
> 
 
> you do not need holes or padding in data strucutres, the MPC860 does allow
> accesing of 16 and 32 bit data on missaligned address - although it
> requires multiple accesses as stated in 14.4.5.  The GNU toolkit

Sorry, I stand corrected.

> documentation describes the packed attribute for this purpose - again
> portability across platforms is not a requirement.  It  appears that the
> gcc documentation supplied for the Sun (SPARC/SunOS) makes no mention of
> strucutre packing options - which I pressume can be controlled in a similar
> fashion to the MPC860 compiler (no matter how undesirable their use may be)

- -- 
Douglas Fraser
dwfraser@lucent.com

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

Newsgroups: comp.os.vxworks
Subject: Re: ARM target and ARM compiler?
Date: Wed, 23 Dec 1998 16:11:12 -0800
From: Hwa-Jin Bae <chaos@idiom.com>
Organization: Idiom Communications
Message-ID: <Pine.BSF.3.96.981223160934.16332B-100000@idiom.com>
References: <75onj6$7b4@overload.lbl.gov>

I have been unsuccessful in using ARM SDK compiler with VxWorks.  The ARM
SDK compiler uses different object output format than ELF or COFF.  The
linker couldn't handle VxWorks objects and assembler uses different syntax
than GAS.  If you have been successful in using ARM SDK C toolchain with
VxWorks/ARM let me know.  THanks.

Hwa-Jin Bae         
PSO Systems, Inc. 
http://www.pso.com
mailto:hjb@pso.com  

On 22 Dec 1998, Bill Pringlemeir wrote:

> The following message is a courtesy copy of an article
> that has been posted as well.
> 
> Does the compiler from ARM work with VxWorks?  I have heard that
> it generates the best code for that platform.  The Green Hills
> compiler seems to support more C++ functionality than either 'gcc'
> or ARM, and it includes the EC++ libraries.
> 
> Does anyone have experiences with using the ARM or Green Hills compiler
> on an ARM target?  I got the DIAB compiler to work with the the MPC821
> and VxWorks.  DIAB gave better performance than the supplied GCC.
> 
> Does anyone know if WR will ever use the EGCS compiler.  EGCS has a better
> backend to do instruction scheduling.  This is one of the reasons gcc
> performs worse on ARM/PowerPC (RISC).  I did find that gcc was better than
> the MRI compiler we have on a 68k processor.
> 
> Thanks,
> Bill
> 
> -- 
> Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/"
> 
> 
> 


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

Newsgroups: comp.os.vxworks
Subject: VxWorks, Rimfire 3573, 4GB Disks and NFS
Date: Thu, 24 Dec 1998 06:50:23 GMT
From: muswick@uhrad.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <75so7f$am$1@nnrp1.dejanews.com>

I am some intermittant problems on a VME system run VxWorks 5.1, a Rimfire
3573 Scsi controller, a new Baracuda 4GB disk, ethernet, and NFS to
a Sun Sparc workstation run SunOS 4.1.

Here is a copy of my status on the vx system:

- -> i

  NAME	ENTRY  TID  PRI  STATUS  PC  SP  ERRNO	DELAY ---------- ------------
- -------- --- ---------- -------- -------- ------- ----- tExcTask  _excTask 
3fbbb8	0 PEND	51a64  3fbb20  d0003  0 tLogTask  _logTask  3f92b8  0 PEND 
51a64  3f921c  0  0 tShell  _shell  3c1b28  1 READY  546a8  3c17f0  320001  0
tRlogind  _rlogind  3f12b0  2 PEND  51d6c  3f0f88  0  0 tTelnetd  _telnetd 
3ef40c	2 PEND	51d6c  3ef33c  0  0 tTelnetOutT_telnetOutTa  325bfc  2 READY 
51d6c  325964  0  0 tTelnetInTa_telnetInTas  3246e4  2 READY  51d28  3243ec 
0  0 tRdbTask  _rdbTask  3ec9dc  20 PEND  51d6c  3ec8bc  d0003	0 gantryTask
_post_gc_rea  32afdc  30 PEND  51d6c  32af18  0  0 tNetTask  _netTask  3f46e0
 50 READY  52ad2  3f4678  0  0 rts_server _rts_server  3a3a20  50 PEND	51d6c
 3a3900  d0003	0 rodTask  _post_rr_rea  3292f4  50 PEND  51d6c  32923c  0  0
tFtpdTask  _ftpdTask  3ea524  55 PEND  51d6c  3ea46c  0  0 tMountd  _mountd 
3e7318	55 PEND  51d6c	3e71f8	d0003  0 tNfsd	_nfsd  3e4988  55 PEND	51d6c
 3e484c  d0003	0 tNfsd3  _nfsdRequest	3e1ff8	60 PEND  51a64	3e1f34	0  0
tNfsd2	_nfsdRequest  3df668  60 PEND  51a64  3df5a4  0  0 tNfsd1 
_nfsdRequest  3dccd8  60 PEND  51a64  3dcc14  0  0 tNfsd0  _nfsdRequest 
3da348	60 PEND  51a64	3da284	0  0 stor_data	_stor_data  37fed0  99 PEND 
51d6c  37fe0c  0  0 tPortmapd  _portmapd  3edef4 100 PEND  51d6c  3eddc0  16 
0 mcs_server _mcs_server  3a5708 100 PEND  51d6c  3a55e8  d0003  0
matrixServe_matrixServe  39ea70 100 PEND  51d6c  39e950  d0003	0 rfa_server
_rfa_server  384e80 150 PEND  51d6c  384d60  d0003  0 value = 0 = 0x0

My first question is whether the ERRNO listed are normal for vxWorks?

Second, are there any known problems using a 4.0GB SCSI drive on vxWorks
using the 3573?

Will the Format command work ok with this disk?

Since the SUN OS can only see a 2GB partion, when NFS mount the
4.0GB Drive, it mostly shows 0% used.  Are there any problems using
SunOS 4.1 and NFS to access a 4.0GB drive?

Any thoughts or suggestions would be appreciated.

Gary Muswick
muswick@uhrad.com
(216)844-7793
(216)844-3106 fax.



- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

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


From owner-vxwexplo-process  Fri Dec 25 04:00:11 1998
From: daemon@csg.lbl.gov
Date: Fri Dec 25 04:00:14 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Fri Dec 25 04:00:07 PST 1998

        Subject: Simple I/O
        Subject: TCP/IP sockets
        Subject: How does one wait on more than one object in VxWorks ?.
        Subject: Re: What happens to command line arguments?

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

Newsgroups: comp.os.vxworks
Subject: Simple I/O
Date: Thu, 24 Dec 1998 08:43:33 -0500
From: Steve O'Neill <steven.m.oneill@lmco.com>
Organization: Sanders, A Lockheed Martin Company
Message-ID: <36824505.CAC5E1CD@lmco.com>

A simple question...

We are using Tornado with a MVME2307 PPC board.  We have an application
that outputs a menu and then reads responses to perform the desired
actions.  The application uses gets(ch) to read the responses into a 1
character item.

The problem is that while the application is able to output the menu to
the debug com port input through that port seems to be getting
intercepted by the VxWorks shell.  I know that I have done this sort of
thing before but I can't seem to remember the setup/operations necessary
to get things configured properly.

Yes, I've tried several virtual I/O configurations but that sets up the
Tornado shell as the output path - this isn't what I want.  I actually
want all I/O to be done with this application via the debug port.

Any help would be appreciated...
Steve O'Neill


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

Newsgroups: comp.os.vxworks
Subject: TCP/IP sockets
Date: Tue, 22 Dec 1998 09:38:18 -0400
From: Kirk Bateman <kirk.bateman@jhuapl.edu>
Organization: Johns Hopkins University Applied Physics Lab, Laurel, MD, USA
Message-ID: <367FA0C9.C8C3A46C@jhuapl.edu>

I've encountered a problem using TCP/IP sockets to communicate between a
real-time system running on an MVME-167 board (VxWorks 5.2) and a
graphical user interface (GUI) running on a Sun SPARC workstation
(Solaris 2.5.1).  Both applications use wrap messages, which they
exchange periodically (every eight seconds), to monitor the socket.

The real-time application uses three tasks, of equal priority, to
monitor and maintain the socket.  Specifically, an input handler task
reads data from the socket, an output spooler task writes data to the
socket, and a socket control task takes appropriate steps to open the
socket during software initialization and to reconnect the socket when
loss of communication between the MVME-167 board and the SPARCstation is
detected.  Additionally, the input handler task writes a response to the
socket immediately upon reading a wrap request message from the socket.
This is the only case in which a task other than the output spooler
writes to the socket.

When there is a high amount of traffic between the GUI and the real-time
application, the input handler task has been observed to "hang."
Specifically, executing a ti command at the shell prompt yields:

 279cc _vxTaskEntry   +10 : _ciwsShipInputHandler (0, 0, 0, 0, 0, 0, 0,
0, 0, 0)
f4818a _ciwsShipInputHandler+1ba: _respondToWrapReq (f8fb40, f50dcc,
&_shipSocketDown)
f46976 _respondToWrapReq+12c: _tcpSocketWrite (f50dcc, 8, f8fb18)
f494a0 _tcpSocketWrite+14 : f49c5e (b, f8fb18, 8)
f49cae _tcpSocketReconnect+7ba: _write (b, f8fb18, 8)
 445e4 _write         +10 : _iosWrite ([b, f8fb18, 8, f8fae8, f49cb4])
 45354 _iosWrite      +78 : 3e0dc ([ffdc30, f8fb18, 8, f8fac4, 445ea])
 3e10a _send          +a8 : _sosend (ffdc30, 0, f8fb18, 8, f8fa98)
 76038 _sosend        +1c2: _sbwait (ffdcc0)
 7733c _sbwait        +10 : _semQPut ([ffdce0, f8fa6c, 7603e, ffdcc0,
8])

The input handler task appears to be blocked awaiting a semaphore within
the VxWorks write function as it attempts to write a wrap request
message to the socket.  I don't know how to proceed in tackling this
problem, as I'm not familiar enough with the kernel to troubleshoot it.
However, as I was pressed for time to solve the problem, I did so by
having the input handler task send the wrap request message to a message
queue, rather than writing it to the socket.  The output spooler task
then takes the wrap request message from the queue and writes it to the
socket.  Isolating the reads and writes in two separate tasks seems to
have solved the problem.  However, I don't understand why the original
software design didn't work.  If there is a semaphore within the kernel
controlling access to the socket, it seems that the input handler task
should be able to get or take this semaphore when the output spooler or
socket control tasks do not have it.

Your help is greatly appreciated.

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

Newsgroups: comp.os.vxworks
Subject: How does one wait on more than one object in VxWorks ?.
Date: Tue, 22 Dec 1998 11:45:36 -0800
From: "rvsaripa" <ramakrishna_saripalli@intel.com>
Organization: Intel Corporation
Message-ID: <75oucf$5b2@news.or.intel.com>

Consider the following scenario .

I have 2 semaphores and file descriptor I need to wait on at the same time
 in a certain task context that has access to them ).

Can I use select() ?. When I read the documentation on select, it seems to
take only file descriptors ( semaphores are not file descriptors, are they
? ) .

In short , I am looking for a mechanism such as WaitForMultipleObjects() on
Win32 ( NT / 95 / 98 ) .

Thanks for any help in advance,
rk

please e-mail me at ramakrishna_Saripalli@intel.com

All opinions are mine and mine only .




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

Newsgroups: comp.os.vxworks
Subject: Re: What happens to command line arguments?
Date: 22 Dec 1998 16:55:45 -0500
From: Ken Taylor <tecak@sprynet.com>
Organization: SpryNet
Message-ID: <wvahfunkfj2.fsf@sunspot.avid.com>
References: <75p0rr$j3v$1@swlmail.msd.ray.com>
Sender: ktaylor@sunspot.avid.com

rmd@swl.msd.ray.com (Regina DuBord {84134}) writes:

> Does anybody know what happens to command line argu-
> ments in VxWorks???  They certainly don't seem to get 
> assigned to argv in a C program, though I haven't found 
> *any* documentation about this.  Arrrgh (tearing my hair 
> out, etc....)
> 

There is no standard C command line processing done in vxWorks.
'main' has no special meaning.  It's just another function call.

In your example:

- -> main "-b"
argc is 28858832

The shell pushes the address of the string "-b" onto the stack.  Then
it calls 'main'.  argc gets set to the first int on the stack
(etc). I'll bet if you looked at address 0x1b859d0 (28858832), you'd
see "-b".
- -- 
Ken Taylor                                          
Avid Technology, Inc.

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

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


From owner-vxwexplo-process  Sat Dec 26 04:00:09 1998
From: daemon@csg.lbl.gov
Date: Sat Dec 26 04:00:12 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Sat Dec 26 04:00:05 PST 1998

        Subject: Re: Simple I/O
        Subject: Re: How does one wait on more than one object in VxWorks ?.
        Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
        Subject: Re: How to get the system time on Vxworks.
        Subject: Re: TCP/IP sockets
        Subject: The Interactive Dance Compilation you can play and Mix on  your PC!!   3373

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

Newsgroups: comp.os.vxworks
Subject: Re: Simple I/O
Date: Fri, 25 Dec 1998 06:47:17 -0600
From: johncobyremovespam@orbitworld.net (John R. Cobarruvias)
Organization: Self
Message-ID: <johncobyremovespam-2512980647170001@dialup-1-82.orbitworld.net>
References: <36824505.CAC5E1CD@lmco.com>

In article <36824505.CAC5E1CD@lmco.com>, Steve O'Neill
<steven.m.oneill@lmco.com> wrote:

If the shell is intercepting it, then the shell has higher priority than
your task. While your application is running either suspend the shell or
kill it. then before your application quits, start the shell up again with
shellInit which is in usrConfig.c (I think.)

> A simple question...
> 
> We are using Tornado with a MVME2307 PPC board.  We have an application
> that outputs a menu and then reads responses to perform the desired
> actions.  The application uses gets(ch) to read the responses into a 1
> character item.
> 
> The problem is that while the application is able to output the menu to
> the debug com port input through that port seems to be getting
> intercepted by the VxWorks shell.  I know that I have done this sort of
> thing before but I can't seem to remember the setup/operations necessary
> to get things configured properly.
> 
> Yes, I've tried several virtual I/O configurations but that sets up the
> Tornado shell as the output path - this isn't what I want.  I actually
> want all I/O to be done with this application via the debug port.
> 
> Any help would be appreciated...
> Steve O'Neill

- -- 
See "Closing Costs" by Brad Tyer, The Houston Press for a feature
story on Ryland Homes and my webpage at:
http://www.houstonpress.com/1998/102998/feature2-1.html

ANTI_SPAM IN EFFECT RESPOND TO: JOHNCOBY@ORBITWORLD.NET

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

Newsgroups: comp.os.vxworks
Subject: Re: How does one wait on more than one object in VxWorks ?.
Date: Wed, 23 Dec 1998 03:48:46 GMT
From: Ephraim Ezekiel <eezekiel@bbn.com>
Organization: Quarry Technologies
Message-ID: <368067B1.C10785EF@bbn.com>
References: <75oucf$5b2@news.or.intel.com>

There is really no easy way to wait on multiple objects. That is why the select
is used in Unix and VxWorks. The select doesn't work for semaphores and queues.

One option is to create multiple tasks which each waits on the different types
of events and then have the 2 tasks coordinate their shared data.

One thing that I did is to use the signal to wait on multiple events although I
am not sure how a file descriptor can be mapped to a signal. Signals can either
be processed asynchronously by a signal handler or synchrounously in the task's
main thread.

The select really only works for sockets, pipes and asynchronous events that
use file descriptors.

rvsaripa wrote:

> Consider the following scenario .
>
> I have 2 semaphores and file descriptor I need to wait on at the same time
>  in a certain task context that has access to them ).
>
> Can I use select() ?. When I read the documentation on select, it seems to
> take only file descriptors ( semaphores are not file descriptors, are they
> ? ) .
>
> In short , I am looking for a mechanism such as WaitForMultipleObjects() on
> Win32 ( NT / 95 / 98 ) .
>
> Thanks for any help in advance,
> rk
>
> please e-mail me at ramakrishna_Saripalli@intel.com
>
> All opinions are mine and mine only .


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

Newsgroups: comp.os.vxworks
Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
Date: Wed, 23 Dec 1998 03:51:35 GMT
From: john@kivala.com
Organization: Kivala Systems, Inc.
Message-ID: <75ppc8$isj$1@nnrp1.dejanews.com>
References: <75mm74$134$1@nnrp1.dejanews.com> <367FE979.7BA0@nospam.aracnet.com>

In article <367FE979.7BA0@nospam.aracnet.com>,
  sj_nospam@nospam.aracnet.com wrote:
> newsmine@my-dejanews.com wrote:
...
<good stuff deleted>
...
> As far as caching strategy goes...in general, RAM should be
> cached--unless it is an area of RAM being shared between more than one
> processor, or otherwise being read to or written from by something else
> other than the CPU.  (This does not include other things internal to the
> CPU, such as the SCC---external RAM accessed by the SCC may be safely
> cached).  The 860 family does not have support for bus snooping; so
> there is no way for an external bus master to know if memory it touches
> is up-to-date, or to mark it dirty.  So turn off cacheing for any such
> memory.
...
<more good stuff deleted>

I don't think the above is right. I think the CPM devices
(including SCCs) are external as far as caching is concerned,
so if your CPM devices use external memory, the memory should
either be noncacheable or you should take care of caching
issues manually.

Perhaps some of you other 860 regulars could concur or
straighten me out?

John

- --------------------------------------------------
 John Finley                 Kivala Systems, Inc.
 Project Manager                   (619) 689-0032
 john@kivala.com            http://www.kivala.com
- --------------------------------------------------
 VxTool - Build Tornado Apps with MS Visual Basic
- --------------------------------------------------

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: Re: How to get the system time on Vxworks.
Date: Wed, 23 Dec 1998 23:00:38 GMT
From: Suresh Gopalakrishna <suresha@dal.dset.com>
Organization: DSET Corporation
Message-ID: <36817525.A42A5783@dal.dset.com>
References: <3679C934.DC671165@qualcomm.com> <367A7025.ECAA7AFF@lmco-NOSPAM.com>

Hey Guys,

This is how it works, there is a clock_gettime() func in VxWorks, which gets
current time of the clock.
The code looks like below,

 struct timespec time_val;
clock_gettime(CLOCK_REALTIME, &time_val);
time_in_seconds=time_val.tv_sec;

So finally you get the time in secs. For setting the clock, there is
clock_settime().

The synopsis is as follows :

int clock_gettime(clockid_t   clock_id,  struct  timespec  *  tp)
     here clockid is always CLOCK_REALTIME --> for VxWorks,
Same for settime also.

Hope this helps for you,

Suresh,

Daniel Wong wrote:

> You need to initialize your system time from the board's Real Time
> Clock.  Most SBCs have one.  I don't know of a standard VxWorks function
> that reads the RTC.  Check your board documentation for specifics.
> Check www.dejanews.com and search on this newsgroup for sample code
> recently posted.
>
> Basically:  1.  Read the RTC time
>             2.  Set the system clock (try clock_settime() )
>
> I only know how I do this for the MVME 2604 board.  Should be very
> similar for many of the Moto boards since they use the same or similar
> RTC chip.
>
> This approach will be as accurate as your RTC [not very].  See postings
> in comp.protocols.time.ntp newsgroup _iff_ you need more accurate
> (to << 1 sec) time and have access to an ntp server.
>
> HTH
>
> Dan Wong
>
> Venkat Emani wrote:
> >
> > Greetings Folks,
> >
> > I would appreciate if someone can help me in the following regard.
> >
> > I am trying to  get the system time from  within the program.
> >
> >      My code looks like this:
> >
> >    #include <time.h>
> >   ........
> >
> >   time_t    tm Time  =  time(NULL) ;
> >
> >    struct tm * tmp  =  localtime(&tmTime) ;
> >
> >     .....
> >
> >    I thought tmTime should contain the no. of seconds from Jan 1st.
> > 1970  ( At least on Solaris and NT it's like that )
> >    However, tmTime is  set to the  no. of seconds  elapsed since the
> > card was booted last.  ( Which meant  if I run it
> >    in 5 minutes after booting my MC card, tmTime was being set to   5 *
> > 60 = 300 . As a result the localtime() routine
> >    sets the time to Jan 1st 1970 ,  00:05:00   which was n't what I
> > wanted.
> >
> >    Please let me know  how I can get the system Time .
> >
> > My apologies if this  question was previously answered. Please point me
> > to that.
> >
> >  Thanks,
> >
> > Ven.
>
> --
> Daniel Wong Principal System Engineer
> Lockheed Martin  Ocean Radar and Sensor Systems
> Electronics Park EP7-333  Syracuse, NY 13090
> (315)456-2162 [FAX (315)456-1430]
> ------------------------------------------------------------------------
>           Blessed is the man who always fears the Lord,
> but he who hardens his heart falls into trouble. -- Proverbs 28:14


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

Newsgroups: comp.os.vxworks
Subject: Re: TCP/IP sockets
Date: Wed, 23 Dec 1998 16:08:14 -0800
From: Hwa-Jin Bae <chaos@idiom.com>
Organization: Idiom Communications
Message-ID: <Pine.BSF.3.96.981223160519.16332A-100000@idiom.com>
References: <367FA0C9.C8C3A46C@jhuapl.edu>

This sounds like the sending task is blocking due to tcp socket buffer
exhaustion.  TCP window is derived from socket level buffer (settable via
setsockopt SO_SNDBUF).  The send side has a limit on how many bytes can be
queued on the send buffer queue at the socket level.  If the receiver is
not reading bytes off of its queue (receive side socket level queue), this
causes the TCP window to close up.  Until receiver opens up the window the
sender will block.  You can do a couple of things:

1. increase tcp window size (via setsockopt)
2. make sure receiver is emptying data that are coming in -- quickly
enough to not get into a situation where the sender might wait for the TCP
window to open up again.

Hwa-Jin Bae         
PSO Systems, Inc. 
http://www.pso.com
mailto:hjb@pso.com  

On Tue, 22 Dec 1998, Kirk Bateman wrote:

> I've encountered a problem using TCP/IP sockets to communicate between a
> real-time system running on an MVME-167 board (VxWorks 5.2) and a
> graphical user interface (GUI) running on a Sun SPARC workstation
> (Solaris 2.5.1).  Both applications use wrap messages, which they
> exchange periodically (every eight seconds), to monitor the socket.
> 
> The real-time application uses three tasks, of equal priority, to
> monitor and maintain the socket.  Specifically, an input handler task
> reads data from the socket, an output spooler task writes data to the
> socket, and a socket control task takes appropriate steps to open the
> socket during software initialization and to reconnect the socket when
> loss of communication between the MVME-167 board and the SPARCstation is
> detected.  Additionally, the input handler task writes a response to the
> socket immediately upon reading a wrap request message from the socket.
> This is the only case in which a task other than the output spooler
> writes to the socket.
> 
> When there is a high amount of traffic between the GUI and the real-time
> application, the input handler task has been observed to "hang."
> Specifically, executing a ti command at the shell prompt yields:
> 
>  279cc _vxTaskEntry   +10 : _ciwsShipInputHandler (0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0)
> f4818a _ciwsShipInputHandler+1ba: _respondToWrapReq (f8fb40, f50dcc,
> &_shipSocketDown)
> f46976 _respondToWrapReq+12c: _tcpSocketWrite (f50dcc, 8, f8fb18)
> f494a0 _tcpSocketWrite+14 : f49c5e (b, f8fb18, 8)
> f49cae _tcpSocketReconnect+7ba: _write (b, f8fb18, 8)
>  445e4 _write         +10 : _iosWrite ([b, f8fb18, 8, f8fae8, f49cb4])
>  45354 _iosWrite      +78 : 3e0dc ([ffdc30, f8fb18, 8, f8fac4, 445ea])
>  3e10a _send          +a8 : _sosend (ffdc30, 0, f8fb18, 8, f8fa98)
>  76038 _sosend        +1c2: _sbwait (ffdcc0)
>  7733c _sbwait        +10 : _semQPut ([ffdce0, f8fa6c, 7603e, ffdcc0,
> 8])
> 
> The input handler task appears to be blocked awaiting a semaphore within
> the VxWorks write function as it attempts to write a wrap request
> message to the socket.  I don't know how to proceed in tackling this
> problem, as I'm not familiar enough with the kernel to troubleshoot it.
> However, as I was pressed for time to solve the problem, I did so by
> having the input handler task send the wrap request message to a message
> queue, rather than writing it to the socket.  The output spooler task
> then takes the wrap request message from the queue and writes it to the
> socket.  Isolating the reads and writes in two separate tasks seems to
> have solved the problem.  However, I don't understand why the original
> software design didn't work.  If there is a semaphore within the kernel
> controlling access to the socket, it seems that the input handler task
> should be able to get or take this semaphore when the output spooler or
> socket control tasks do not have it.
> 
> Your help is greatly appreciated.
> 
> 


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

Newsgroups: comp.os.vxworks
Subject: The Interactive Dance Compilation you can play and Mix on  your PC!!   3373
Date: 24 Dec 1998 12:03:03 GMT
From: gericom@usa.net
Organization: Centro Servizi Interbusiness
Message-ID: <75tahn$gjq$1914@fe2.cs.interbusiness.it>

The Interactive Dance Compilation you can play and Mix on  your PC!! 


The best dance hits of '90 and 98 together in Discoparade
the first double compilation that you can play and Mix !

Discoparade is the one and only interactive compilation !

http://www.discoparade.com/




http://www.discoparade.com/




ovnibogxpidfdrkixdvzivwouxikzrgegkxviegphwg


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

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


From owner-vxwexplo-process  Sun Dec 27 04:00:08 1998
From: daemon@csg.lbl.gov
Date: Sun Dec 27 04:00:12 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Sun Dec 27 04:00:06 PST 1998

        Subject: Pussy shot from behind  324

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

Newsgroups: comp.os.vxworks
Subject: Pussy shot from behind  324
Date: 25 Dec 1998 22:02:45 GMT
From: rwcrwd@aol.com
Organization: Migros-Genossenschafts-Bund
Message-ID: <761225$9ap@uranus.m-netz.ch>

The sex gallery ! 
It's all FREE here !
FREE xxx memberships,
passwords,pic,thumbnails,and
much more ! Now featuring live 
hott erotic talk !
Cum by today ! WE'RE WAITING !
http://www.thesexgallery.com/



htsceortutuhwsirutjolikenphbcvyrbniqijhvwqwwhzjbjgieennxgpn


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

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


From owner-vxwexplo-process  Tue Dec 29 04:00:09 1998
From: daemon@csg.lbl.gov
Date: Tue Dec 29 04:00:12 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Tue Dec 29 04:00:06 PST 1998

        Subject: Interrupt Vector Table
        Subject: Re: Interrupt Vector Table
        Subject: Request BSD for Cirrus Logic CL-PS7500FE
        Subject: Re: Loading (ld) over a serial port
        Subject: Re: Loading (ld) over a serial port
        Subject: Re: delete operator

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

Newsgroups: comp.os.vxworks
Subject: Interrupt Vector Table
Date: Mon, 28 Dec 1998 15:50:36 -0500
From: "Michael McGarry" <mcgarry@eclipse.net>
Message-ID: <768r1l$n3d$1@news.eclipse.net>

Hello felow VxWorks users,

I was wondering if anyone knew what the interrupt vector table that vxWorks
sets up on the mpc860 looks like? and where in memory does it place this
table?

I put my interrupt handler in the vector table by calling
intConnect(vector_num, (VOIDFUNCPTR) myHandler, param);

correct?

- --
Regards,

Michael McGarry, Firmware Engineer II
Cabletron Systems, Inc.
(732) 394-6041



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

Newsgroups: comp.os.vxworks
Subject: Re: Interrupt Vector Table
Date: Tue, 29 Dec 1998 00:39:25 GMT
From: john@kivala.com
Organization: Kivala Systems, Inc.
Message-ID: <7698bt$gn7$1@nnrp1.dejanews.com>
References: <768r1l$n3d$1@news.eclipse.net>

There are several tables used to demultiplex interrupts on
the 860. When an interrupt happens, the "external interrupt"
exception happens, and the CPU starts executing at 0x500.
VxWorks attaches a handler to this that goes off and reads
the SIU and CPM (as necessary) to see what interrupted. All
this happens in Tornado/target/src/drv/intrCtl/ppc860Intr.c.
When you do an intConnect(), you are putting an entry into
the table intrVecTable[] in that file. The "vector" you pass
in is an index into this table; there are defines for these
in Tornado/target/h/drv/intrCtl/ppc860Intr.h. The "IV_..."
things are the things to pass to intConnect. For example:

    intConnect(IV_TIMER3, yourHandler, 0)

connects to timer 3 in the CPM.

As with any other CPU, you have to make sure and properly
acknowledge the interrupt in the ISR, or you go off into
never-never land. This seems to be more common with the 860
due to the weight of the user's manual. Email me if you
would like a little sample that sets up a CPM timer and
handles interrupts from it, and I will dig it up.

Good luck,
John

- --------------------------------------------------
 John Finley                 Kivala Systems, Inc.
 Project Manager                   (619) 689-0032
 john@kivala.com            http://www.kivala.com
- --------------------------------------------------
 VxTool - Build Tornado Apps with MS Visual Basic
- --------------------------------------------------

In article <768r1l$n3d$1@news.eclipse.net>,
  "Michael McGarry" <mcgarry@eclipse.net> wrote:
> Hello felow VxWorks users,
>
> I was wondering if anyone knew what the interrupt vector table that vxWorks
> sets up on the mpc860 looks like? and where in memory does it place this
> table?
>
> I put my interrupt handler in the vector table by calling
> intConnect(vector_num, (VOIDFUNCPTR) myHandler, param);
>
> correct?
>
> --
> Regards,
>
> Michael McGarry, Firmware Engineer II
> Cabletron Systems, Inc.
> (732) 394-6041
>
>

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: Request BSD for Cirrus Logic CL-PS7500FE
Date: Tue, 29 Dec 1998 12:32:12 +0800
From: Rayson Wai-sang Wong <wswong@aucoasia.com>
Organization: Cyber Express Communications (using Airnews.net!)
Message-ID: <E044DFEFA84AEEA9.819D75D35DC14C69.D0AFF65D3421977F@library-proxy.airnews.net>

Hi,

    My latest project is considering using Cirrus Logic CL-PS7500SE as
platform.  Does anyone know where can I find a BSP for it?  This is
urgent.

    Thanks.

Wong Wai Sang
wswong@wesoft.com.hk
We Software Ltd.


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

Newsgroups: comp.os.vxworks
Subject: Re: Loading (ld) over a serial port
Date: Tue, 29 Dec 1998 08:52:51 +0200
From: Yosi Yarchi <yosiy@ecitele.com>
Message-ID: <36887C43.6E5CE5AD@ecitele.com>
References: <366EAFFE.CF8E6DF2@orbitworld.net>

"John R. Cobarruvias" wrote:

> According to the ld() command, I can load an object module from standard
> input.
> Has anyone done this? I'm a bit confused.
>
> I have a pc running NT with a target booting from rom with the shell and
> symbol table.
> I do not have a network. My only access is via a serial port. Two are
> available.
>
> So, how do I use the ld command to load an executable, say a.out, from
> the NT workstations into the target and run a.out from the shell?
>
> johncoby@orbitworld.net

Hello John

I'm also working with target without network. It has two serial ports, one
is dedicated for STDIO, and the other is dedicated for connection to the
debugger. When working with shell, you enter your commands (such as "ld")
via a terminal connected to the stdio serial port. But, in the case of "ld"
command, it requires a network (or a local disk) to load file from. Hence,
I think, you cannot use it to load files if you have not configured network
on your target. What you have to do, is to launch target server against
your target (configuring it to work with serial backplane, the one
dedicated to the debugger). After launching the target server, you can
launch host shell, and from it load files (using the command "ld").

I hope it helps you

Yosi


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

Newsgroups: comp.os.vxworks
Subject: Re: Loading (ld) over a serial port
Date: Tue, 29 Dec 1998 08:55:57 +0200
From: Yosi Yarchi <yosiy@ecitele.com>
Message-ID: <36887CFD.E196BFEA@ecitele.com>
References: <366EAFFE.CF8E6DF2@orbitworld.net>

"John R. Cobarruvias" wrote:

> According to the ld() command, I can load an object module from standard
> input.
> Has anyone done this? I'm a bit confused.
>
> I have a pc running NT with a target booting from rom with the shell and
> symbol table.
> I do not have a network. My only access is via a serial port. Two are
> available.
>
> So, how do I use the ld command to load an executable, say a.out, from
> the NT workstations into the target and run a.out from the shell?
>
> johncoby@orbitworld.net

Hello John

I'm also working with target without network. It has two serial ports, one
is dedicated for STDIO, and the other is dedicated for connection to the
debugger. When working with shell, you enter your commands (such as "ld")
via a terminal connected to the stdio serial port. But, in the case of "ld"
command, it requires a network (or a local disk) to load file from. Hence,
I think, you cannot use it to load files if you have not configured network
on your target. What you have to do, is to launch target server against
your target (configuring it to work with serial backplane, the one
dedicated to the debugger). After launching the target server, you can
launch host shell, and from it load files (using the command "ld").

I hope it helps you

Yosi


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

Newsgroups: comp.os.vxworks
Subject: Re: delete operator
Date: Tue, 29 Dec 1998 00:27:20 -0800
From: Scott Johnson <sj_nospam@nospam.aracnet.com>
Organization: National Association for the Advancement of Computer Geeks
Message-ID: <36889268.58BE@nospam.aracnet.com>
References: <769spl$vbo$1@nnrp1.dejanews.com>
Reply-To: sj_nospam@nospam.aracnet.com

keshavbc@my-dejanews.com wrote:
> 
> hi,
>     i'm having problem with the c++ delete operator. while this code perfectly
> works fine with a turbo C++ compiler on win95, it give 'memPartFree' error on
> vxWorks. what could be the problem? i'm also attaching the code.
> 
> <p.s: please also reply to my personal account>
> 
> -----------> start of code ------------->
> #include "vxWorks.h"
> #include "stdio.h"
> #include "string.h"
> 
> class mystring
> {
>         char *str ;
> 
>         public:
>                 mystring(){ str=0 ;}
>                 mystring(char *s)
>                 {
>                         int len=strlen(s) ;
>                         str=new char[len+1] ;
>                         str=s ;
>                 }

Ah!  Here is your problem!!!!!

You are assigning str to point to the region pointed to by s, which
probably was not allocated with new [x].  Calling delete[] on a 
region of memory not allocated with new[] will indeed cause a corrupt
heap.

This code also leaks memmory;  the buffer you are allocating in the
second statement is leaked in the third.

What you want is this:

		mystring (const char *s)
		{
			str = new char [strlen(s) + 1];
			strcpy (str, s);
		}

Notice the use of const, too.  Unless you intend to modify an
argument passed by reference or pointer, you should make the declaration
const.

One more thing, and this depends on your compiler.  If you are 
compiling with exceptions enabled (a bit dicey with vxWorks, as 
the current "officially" supported gcc variant from Wind River is 
2.7.x, the exception handling capability of which is seriously broken),
the above is OK--if new fails, an exception gets thrown.

If your compiler DOES not throw exceptions, then you ought to check
the return value of char::operator new[] to make sure that it isn't
NULL (indicating out of memory).  Of course, without exceptions, there
isn't any clean way to indicate a failed constructor...

>                 ~mystring()
>                 {
>                         if(str!=NULL)
>                                 delete [] str ;

The test for NULL is redundant; delete foo (and delete [] foo)
both check for foo==NULL, and return harmlessly if this is the case.

However, you ought to after delete [] ing str, set it to NULL. 
Otherwise, it might well be deleted again....
 
>                 }
> 
>                 mystring &operator= (mystring s1)

Should be mystring &operator= (const mystring &s1)

The argument to the assignment operator MUST be a reference parameter
(and should, in most cases, be const).  Likewise, the return value
(if not void) MUST also be a reference.

Otherwise, weird things will happen.  (I'm actually surprised you  got
to the delete[] statement; one would expect that the call would recurse
forever, at least until you run out of stack...)

>                 {
>                         delete [] str ; /* i'm getting error here - i also
> tried with "delete str" only. but even that is not working */

delete [] str is correct.
 
>                         str=s1.str ;

>                         return ;

The assignment operator should, in general, end with "return *this;"
Not absolutely required, of course (operator = can return void, but
doing so doesn't allow you to "use" the result of the assignment.
Code such as if a = b = c won't work.  May or may not be a problem.)


>                 }



>                 void putstr(char *s)
>                 {
>                         str=new char[strlen(s)+1] ;
>                         str=s ;
>                 }

This suffers from the same problems as the constructor above;
in addition, it contains an additional memory leak.  If str points
to something valid before this is called, your first statement
will leak that storage away.  Try this instead.

		void putstr (const char *s)
		{
			delete [] str;
			str = new char [strlen(s) + 1];
			strcpy (str, s);
		}

> 
>                 char *getstring()
>                 {       return str ;    }

Careful!!!!  If you are going to return pointers to dynamic storage
like this, make DAMN sure the calling code doesn't hold on to them.
Otherwise, folks may do bad things like this:

void nasty_function (int arg) {

	char *foo;

	foo = NULL;

	if (arg == 0) {
    		mystring mystr = "foo";
		foo = mystr.getstring();
	}

	if (foo)
		printf (foo);

}

Do you see the problem??  If arg is nonzero, this works.  If arg is 
zero, though, by the time the "printf(foo)" statement is executed,
foo is pointing to garbage.  Why?  When the if block exits, str
is destroyed.  mystr.~mystring (the destructor) deallocates it's
internal storage (mystr.str), which points to the same location as foo.

Thus, the block of memory pointed to by foo is no longer valid.  There
may still be data there (causing printf to work), or not.  This sort
of bug (wild pointers) are MURDER to debug.

This example is a bit contrived, of course, but similar things happen
ALL THE TIME.  And when it really happens, the offending deallocation
and the offending use are usually far apart, making finding it even
worse.


In general, returning pointers or references to an object's private
parts is a bad idea.  The exception to this rule is if there is a "many
to one" relationship; and multiple objects refer to a common object.
The array str is most definitely private to mystring in this example.


 
> void teststr()
> {
>         mystring s1, s2 ;
> 
>         s1.putstr("abcdef") ;
>         s2.putstr("ghijkl") ;
> 
>         s1=s2 ;
> 
>         printf("\n %s \n",s1.getstring()) ;
> 
>         printf("\n %s \n",s2.getstring()) ;
> }
> -----------> end of code ---------------->


I would suggest that you get yerself a good C++ book.  The ones I
recommend is "Effective C++; 50 Specific Ways to Improve Your Programs
and Designs" by Scott Meyers, and its sequeel "More Effective C++". 

Most C++ texts teach how to program in C++--the syntax, the structures, 
etc.  These two teach how to program in C++ **CORRECTLY**.  C++ provides
you with LOTS of ways to hurt yourself, muchmoreso than C does.  Your
code sample above (no offense) contains quite a few examples.

Good luck,


Scott

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

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


From owner-vxwexplo-process  Wed Dec 30 04:00:18 1998
From: daemon@csg.lbl.gov
Date: Wed Dec 30 04:00:22 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Wed Dec 30 04:00:15 PST 1998

        Subject: FREE XXX   9798
        Subject: Re: delete operator
        Subject: illegal instruction
        Subject: Calender time on VxSim?
        Subject: ccmips abnormal program termination
        Subject: Re: Loading (ld) over a serial port
        Subject: Vxworks IP -> NIC level binding question(s) ...
        Subject: Re: Booting VxWorks from hard-disk
        Subject: US-AZ-Tempe / Real-Time S/W Contractors (10) / Agency
        Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency
        Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
        Subject: Re: Loading (ld) over a serial port

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

Newsgroups: comp.os.vxworks
Subject: FREE XXX   9798
Date: 27 Dec 1998 02:19:57 GMT
From: jftzii@ggggg.ggg
Organization: SIAST
Message-ID: <7645gd$r69929@www1.siast.sk.ca>

The sex gallery ! 
It's all FREE here !
FREE xxx memberships,
passwords,pic,thumbnails,and
much more ! Now featuring live 
hott erotic talk !
Cum by today ! WE'RE WAITING !
http://www.thesexgallery.com/




oinbwcrplyljiiw


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

Newsgroups: comp.os.vxworks
Subject: Re: delete operator
Date: Tue, 29 Dec 1998 11:13:50 -0500
From: "Lawrence T. Hoff" <hoff@bnl.gov>
Organization: Brookhaven National Lab
Message-ID: <3688FFBE.B302C391@bnl.gov>
References: <769spl$vbo$1@nnrp1.dejanews.com>

keshavbc@my-dejanews.com wrote:
> 
> hi,
>     i'm having problem with the c++ delete operator. while this code perfectly
> works fine with a turbo C++ compiler on win95, it give 'memPartFree' error on
> vxWorks. what could be the problem? i'm also attaching the code.
> 
> <p.s: please also reply to my personal account>
> 
> -----------> start of code ------------->
> #include "vxWorks.h"
> #include "stdio.h"
> #include "string.h"
> 
> class mystring
> {
>         char *str ;
> 
>         public:
>                 mystring(){ str=0 ;}

Why do you use "0" here, and "NULL" later?


>                 mystring(char *s)
>                 {
>                         int len=strlen(s) ;
>                         str=new char[len+1] ;
>                         str=s ;
                          ^^^^^^^

Eeek! I think you wanted to say : "strcpy(str, s);"

>                 }
>                 ~mystring()
>                 {
>                         if(str!=NULL)
>                                 delete [] str ;
> 
>                 }
> 
>                 mystring operator= (mystring s1)
>                 {
>                         delete [] str ; /* i'm getting error here - i also
> tried with "delete str" only. but even that is not working */

"delete str" is *wrong*, you must use "delete [] str" when deleting
memory
allocated with new []


> 
>                         str=s1.str ;
                          ^^^^^^^^^^^^

Eeek again! Plus you forgot a separate allocation (unless you *want* to
share
the allocated memory, in which case you'll need a reference count, and
special
handling in the "putstr()" and "getstring()" methods).

>                         return ;
>                 }
>                 void putstr(char *s)
>                 {
>                         str=new char[strlen(s)+1] ;
>                         str=s ;
                          ^^^^^^^

Triple eeeek!

>                 }
> 
>                 char *getstring()
>                 {       return str ;    }

"const char *" may be "better" than "char *" (unless you *want* users to
be 
able to manipulate your private members directly)

> } ;
> 

	I *assume* this is an educational exercise. There are plenty of 
public-domain string classes, with a variety of features. You may be
better 
off starting with one of those.

HTH -- Larry

- -- 
Building 911-C, Brookhaven National Laboratory
PO Box 5000, Upton, NY, 11973                
http://www.rhichome.bnl.gov/~hoff,  mailto:hoff@bnl.gov
Phone: (516) 344-2194 FAX: (516) 344-5443

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

Newsgroups: comp.os.vxworks
Subject: illegal instruction
Date: Tue, 29 Dec 1998 17:43:42 +0100
From: ping1412@ping.be (Dirk Schelfhout)
Organization: Donkergroen bvba
Message-ID: <ping1412-2912981743420001@dialup010.antwerp.eunet.be>

How do I proceed to find out what causes this error.

I checked that the code that causes this to happen is not altered.
( If i compare the assembly code at the specific address, before and after
running )
The code that causes this is not special, it is a simple switch case block
inside a function.
Today I found out that one of the tasks running uses floating point, so I
changed spawning of all tasks with the floatingpoint option.

I am getting very desperate, all help welcome.

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

Newsgroups: comp.os.vxworks
Subject: Calender time on VxSim?
Date: Tue, 29 Dec 1998 16:59:54 GMT
From: jyl97@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <76b1qa$srk$1@nnrp1.dejanews.com>

Hi,

Does anyone know how to get correct time and date on VxSim? I'm running VxSim
on Sun Solaris 2.6.

Thanks a lot.


- -- JYL

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: ccmips abnormal program termination
Date: Tue, 29 Dec 1998 10:59:01 -0700
From: Rick Busser <rickb@sitera.com>
Organization: Dimensional Communications
Message-ID: <36891865.761FE4B4@sitera.com>

Has anyone else seen this when compiling templates in C++ files?

- --
Rick Busser                            rickb@sitera.com
Software Engineer                      (303) 651-1935 x256
SiTera Corporation                     (303) 651-1199 fax
1820 Lefthand Circle                   Longmont, CO  80501



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

Newsgroups: comp.os.vxworks
Subject: Re: Loading (ld) over a serial port
Date: Tue, 29 Dec 1998 11:00:11 -0800
From: Hwa-Jin Bae <chaos@idiom.com>
Organization: Idiom Communications
Message-ID: <Pine.BSF.3.96.981229105955.15572A-100000@idiom.com>
References: <366EAFFE.CF8E6DF2@orbitworld.net> <36887C43.6E5CE5AD@ecitele.com>

You could use SLIP or PPP over serial port.

Hwa-Jin Bae         
PSO Systems, Inc. 
http://www.pso.com
mailto:hjb@pso.com  


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

Newsgroups: comp.os.vxworks
Subject: Vxworks IP -> NIC level binding question(s) ...
Date: Tue, 29 Dec 1998 12:25:38 -0800
From: "rvsaripa" <ramakrishna_saripalli@intel.com>
Organization: Intel Corporation
Message-ID: <76bfe8$54b@news.or.intel.com>

Hi,
   I am fairly new to vxworks . I am writing a device driver for a custom
device. This device is a Ethernet NIC as far as the host is concerned and so
accepts MAC layer packets for transmission .

My questions are as follows :-
a) If I am using SENS , what do I need to do to bind
IP to my driver . Further , my device issues a MAC address for the host . If
I wanted to use a DHCP client on the host to request an IP address for this
interface , how would I provide the MAC address to the IP stack ?. Is there
a standard / custom ioctl that my driver needs to support that the IP layer
would call to get the MAC address for my interface ?.

Thanks in advance,
rk

All opinions expressed are mine and mine only.



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

Newsgroups: comp.os.vxworks
Subject: Re: Booting VxWorks from hard-disk
Date: Tue, 29 Dec 1998 17:50:13 -0800
From: John Fabiani <johnx@nospam.wrs.com>
Organization: Wind River Systems
Message-ID: <368986D5.83A7AB03@nospam.wrs.com>
References: <7422lv$lg7@news.or.intel.com> <3667470D.AA598FFD@know_spam.wrs.com> <756nra$1r8$1@nnrp1.dejanews.com>
Reply-To: johnx@nospam.wrs.com

david.hagood@ifrsys.com wrote:

> I've tried to boot VxWorks from a hard disk only to fail miserably.

Rest assured this can work.

>
>
> The disk is partitioned with a FAT-16 partition as the first primary
> partition. That partition is bootable (marked active).
>
> I do a vxsys c:\, and it works.



Freshly format the drive.  (With FDISK and FORMAT from MSDOS)

Do "lock c:"  to remove the partition protection (win95)

Do "vxsys c:\"   - This copies the VxLD 1.2 bootstrapping code
to the filesystem bootsector.  Note that the target hard drive
should exist as "c:\" at this stage (ie: you cannot do "vxsys d:" and
then switch the disk to C:, since the 0x80 BIOS representation
is used when vxld looks for bootrom.sys), else this will fail with no
bootrom.sys error.

Do "vxcopy bootrom c:\bootrom.sys" - this copies the file,
stripping the 32byte a.out header.

Do "chkdsk c:\bootrom.sys /f",  since bootrom.sys
must be a contiguous file.

> I copy a:bootrom.sys c:\bootrom.sys, and it works
> I verify that bootrom.sys is contiguous.
> I reboot the machine.
> VxLd complains that it cannot find bootrom.sys
>
> The bootrom.sys I copied over loaded fine from the floppy.
>
> I created the file system from VxWorks, so it ought to be a configuration
> that VxWorks likes.

Hmm, that may be the problem.

Create the HDD filesystem from MSDOS.  This will force the use
of partitions when making the file system (vxworks does not
create partitions) but looking at the asm for vxsys.com, it
does expect a partition if it is on a hard disk.



>
>
> Any ideas?
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own




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

Newsgroups: az.jobs,misc.jobs.contract,comp.os.vxworks,comp.os.lynx,comp.realtime
Subject: US-AZ-Tempe / Real-Time S/W Contractors (10) / Agency
Date: 30 Dec 1998 05:46:45 GMT
From: Tate Consulting <hotjobs@tateinc.com>
Organization: Tate Consulting, Inc.
Message-ID: <76ceo5$fq4$17@remarQ.com>



Our client in Tempe Arizona is a Fortune 100 company building state of 
the art computer systems. 

10 Real-time Systems Development Engineering Contractors needed for a  
January start date.

JOB DESCRIPTION:

System software integration for high availability real-time systems. Working
with Compact PCI and real-time Operating system products to implement  
unique competence in system reliability. Responsible for designing and  
implementing integration test software for highly available products for  
customer specific applications. Knowledge of PowerPC highly  desirable.

Experienced C and C++ Programmers.   Proven ability to debug and  
diagnose hardware and software problems on new hardware.

Reference Job Code JC-A12048-01 on any correspondence.

Please reference the JOB CODE listed above in any correspondence
to us.  Send your resume in ASCII or MSWord format to:

Email:	hotjobs@tateinc.com
Fax:	(561) 852-2385
Snail:	Tate Consulting, Inc.
	10647 Avenida Santa Ana
	Boca Raton, FL  33498

Please visit our Hi-Tech Job Database at http://www.tateinc.com

Tate Consulting is a Computer Consulting and Placement Company
in business since 1991.

Andrew Tate, President/Owner
Tate Consulting, Inc.
atate@tateinc.com
(561) 852-TATE (8283)

We are an EOE.










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

Newsgroups: comp.os.vxworks,comp.realtime,misc.jobs.contract
Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency
Date: 30 Dec 1998 05:46:48 GMT
From: Tate Consulting <hotjobs@tateinc.com>
Organization: Tate Consulting, Inc.
Message-ID: <76ceo8$fq4$18@remarQ.com>



Fortune 100 Company needs contractor to work on CHORUS and VxWorks  
Drivers and OS tuning.

Refer to Job Code: JC-A10078-01.

Please reference the JOB CODE listed above in any correspondence
to us.  Send your resume in ASCII or MSWord format to:

Email:	hotjobs@tateinc.com
Fax:	(561) 852-2385
Snail:	Tate Consulting, Inc.
	10647 Avenida Santa Ana
	Boca Raton, FL  33498

Please visit our Hi-Tech Job Database at http://www.tateinc.com

Tate Consulting is a Computer Consulting and Placement Company
in business since 1991.

Andrew Tate, President/Owner
Tate Consulting, Inc.
atate@tateinc.com
(561) 852-TATE (8283)

We are an EOE.










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

Newsgroups: comp.os.vxworks
Subject: Re: MPC860SAR I & D Cache : Relation with memory type?
Date: Wed, 30 Dec 1998 10:20:11 +0200
From: Yosi Yarchi <yosiy@ecitele.com>
Message-ID: <3689E23A.C5EE2C0E@ecitele.com>
References: <75mm74$134$1@nnrp1.dejanews.com>

newsmine@my-dejanews.com wrote:

> Hi All,
>
> I am trying to activate the data and instruction caches on my MPC860SAR board.
> I was wondering if anybody could share their experience with me on that. A few
> questions I have are :
>
> 1.The ADS BSP we have has a couple of lines like
>
> #ifdef  EDO_DRAM
>    undef USER_I_CACHE_ENABLE
>    undef USER_D_CACHE_ENABLE
>    undef INCLUDE_CACHE_SUPPORT
> #endif  /* EDO_DRAM */
>
> What is the relationship between DRAM type and turning on the caches? Why
> should the cache activation be restricted to SDRAM type of DRAM only?

The cache activation is not restricted to SDRAM or DRAM. There were some bugs
concerning the cache in the first revisions of the MPC860, and wind river, when
created the BSP for the ADS860 board used one of this buggie chips. In my
company, it works fine with both caches enabled with chip revision A3 or later
and with EDO RAM. There is yet problem with data cache when working exactlly in
50 Mhz (solved in chip revision C and later).

>
>
> 3.What areas of memory need to be excluded from caching on MPC860SAR? Only
> the on-chip DPRAM or something else too? How do I specify these areas in
> VxWorks?

Excluded memory areas:
(1) communication buffers
(2) MPC860 internal DPR
(3) board i/o memory mapped areas
(4) FLASH ?

The definition is done in "sysLib.c" file, in structure named "sysPhysMemDesc".
vxWorks automatically exclude it's communication buffers out of the cache
(ethernet, serial). Other communication buffers must be defined as not cacheable
manually, or be dynamically allocated as non cacheable blocks
("cacheDmaMalloc()").

>
>
> 4.Is it sufficient to define these macros in config.h and rebuild the BSP?
> #define USER_I_CACHE_ENABLE
> #define USER_D_CACHE_ENABLE
> #define INCLUDE_CACHE_SUPPORT
>

Yes. You can try to change the mode of the cache (WRITE_TROUGH, COPYBACK), but
I'm not sure it have real meaning in the MPC860. In the MPC860 the instruction
cache works only in COPYBACK mode, and from my experience vxWorks configure data
cache to work in COPYBACK mode. The user can change this default manualy and
force WRITE_THROUGH by commanding the DC_CST cache register.

>
> 5.Any performance indicators I may use to determine the speed-up gain?

The performance for the instruction cache is improved significantlly. For the
data cache, only load/store commands are accelerated by the cache. You can write
small program, using some global variables, and check what going on with or
without cache. In my small program (which not representing typical application at
all !!!) I found that it runs X 8 faster when both caches are enables than when
both caches are disabled. I estimate that data cache contributed 25% of the
acceleration, and instruction cache - 75%.

- --

Yosi Yarchi
yosiy@ecitele.com
eci-telecom




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

Newsgroups: comp.os.vxworks
Subject: Re: Loading (ld) over a serial port
Date: Wed, 30 Dec 1998 09:45:53 +0100
From: Sebastien Mallet <mallet@nortel.ca>
Organization: Nortel
Message-ID: <3689E841.DA51D4CE@nortel.ca>
References: <366EAFFE.CF8E6DF2@orbitworld.net> <36887C43.6E5CE5AD@ecitele.com> <Pine.BSF.3.96.981229105955.15572A-100000@idiom.com>

Hi,
You DON'T NEED a network to ld() from your host, a serial line with
WDB_SERIAL backend does the job.
The parameters are in config.h WDB_COMM_TYPE=WDB_COMM_SERIAL,
WDB_TTY_CHANNEL, WDB_TTY_DEV_NAME, WDB_TTY_BAUD
for communication type, channel, device name and baudrate. 
HTH
Sebastien

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

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


From owner-vxwexplo-process  Thu Dec 31 04:00:09 1998
From: daemon@csg.lbl.gov
Date: Thu Dec 31 04:00:12 PST 1998
Subject: comp.os.vxworks newsdigest

Comp.Os.Vxworks Daily Digest    Thu Dec 31 04:00:05 PST 1998

        Subject: NT4.0 as PPP server question
        Subject: ScsiMgr task?
        Subject: segmented memory
        Subject: I'm looking for development work

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

Newsgroups: comp.os.vxworks
Subject: NT4.0 as PPP server question
Date: Mon, 28 Dec 1998 12:33:21 -0700
From: Rick Busser <rickb@sitera.com>
Organization: Dimensional Communications
Message-ID: <3687DD01.EE10F616@sitera.com>

I am trying to run VxWorks over PPP, using NT4.0 as a host.  I followed
the instructions in the "Vinh's PPP guide" and I'm still having
problems.  I get the following error
Attaching network interface ppp0...
ppp0: ppp 2.1.2 started by
ppp0: Connect: ppp0 <--> /tyCo/1
ppp0: sent [LCP ConfReq id=0x3 <mru 1500> <magic 0x3c> <pcomp> <accomp>]

ppp0: sent [LCP ConfReq id=0x3 <mru 1500> <magic 0x3c> <pcomp> <accomp>]

ppp0: sent [LCP ConfReq id=0x3 <mru 1500> <magic 0x3c> <pcomp> <accomp>]

ppp0: sent [LCP ConfReq id=0x3 <mru 1500> <magic 0x3c> <pcomp> <accomp>]

ppp0: sent [LCP ConfReq id=0x3 <mru 1500> <magic 0x3c> <pcomp> <accomp>]

ppp0: timeout: could not establish link with peer.
Can't load boot file!!
ppp0: sent [LCP TermReq id=0x4]

If I hook up COM2 on my PC to hyperterm, I see binary characters coming
in.  But NT never responds to any of these LCPs.  Any ideas what could
be going wrong?
Thanks.

- --
Rick Busser                            rickb@sitera.com
Software Engineer                      (303) 651-1935 x256
SiTera Corporation                     (303) 651-1199 fax
1820 Lefthand Circle                   Longmont, CO  80501



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

Newsgroups: comp.os.vxworks
Subject: ScsiMgr task?
Date: Thu, 31 Dec 1998 10:52:04 +0900
From: Sang-Min Lee <smlee@puddle.etri.re.kr>
Organization: ETRI
Message-ID: <368AD8C3.965C8F0D@puddle.etri.re.kr>



Hi

I want to know about the internal operations of scsi driver.

If any system has many SCSI contollers and devices,
then ScsiMgr tasks as many as  controllers are spawned with same task
priority.

^^^^^^^^^^^^^^^^^
How do those tasks perform?

In the case of our system(5 contollers and one disk per controller),
the system dies during boot.(tasks conflict?)

have a happy holidays~

    ---------------------------------------------------------------
    + Lee Sang Min
    +    Input/Output System Research Team
    +    Computer System Division, Computer & Software Institute
    +    Electronics and Telecommunications Research Institute
    +    (Home) http://puddle.etri.re.kr/~smlee
    +    (Tel)  82-42-860-4926
    ---------------------------------------------------------------



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

Newsgroups: comp.os.vxworks
Subject: segmented memory
Date: Thu, 31 Dec 1998 05:32:51 GMT
From: keshavbc@my-dejanews.com
Organization: Deja News - The Leader in Internet Discussion
Message-ID: <76f2a4$1q3$1@nnrp1.dejanews.com>

hi,
   does vxWorks use segmented memory or a flat memory addressing ?

<p.s: please also reply at my personal>

- -----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

Newsgroups: comp.os.vxworks
Subject: I'm looking for development work
Date: Wed, 30 Dec 1998 20:55:52 -0700
From: Ryan Pedersen <ryan_pedersen@hotmail.com>
Message-ID: <368AF5C4.ACF248A6@hotmail.com>

I'm looking for some a C/C++ development work.
I have 6 years working with vxWorks.
If interested,  I will send you my resume in word format.

ryan_pedersen@hotmail.com

Ryan
Pedersen



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

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