From arjon.vlasblom@hta.nl  Mon Dec  2 00:46:16 1996
From: Arjon Vlasblom <arjon.vlasblom@hta.nl>
Date: Mon Dec  2 00:46:18 PST 1996
Subject: Re: LonTalk
At 20:55 29-11-96 PST, you wrote:
>
> Submitted-by selliott@mkc.com.au  Fri Nov 29 20:54:51 1996
> Submitted-by: Steve Elliott <selliott@mkc.com.au>
>
> Does anyone know of VxWorks 5.3 driver implementations for LonTalk?
>
Hello Steve,
As far as I know there is none.
What we did, for one of our customers, is making a port of the DOS driver
version towards a VxWorks 5.2 I/O task.
The target system was Intel Pentium, but we kicked out all the assembly
instructions in the code and wrote it in 'C'.
We needed 2 till 3 months effort to get it done (including testing).
Regards,
Arjon Vlasblom.
--                                ////
                                 (0 0)
 _____________________________o00_( )_00o______________________________
/                                                                      \
|  Arjon Vlasblom                     High Tech Automation BV          |
|  voice: +31 499 474725              Ekkersrijt 4006, 5692 DA Son     |
|  fax  : +31 499 474799              The Netherlands                  |
|  email: arjon.vlasblom@hta.nl       http://www.hta.nl                |
|----------------------------------------------------------------------|
|      T H E   E M B E D D E D   S O F T W A R E   C O M P A N Y       |
|----------------------------------------------------------------------|
| Disclaimer: This message does not necessarily reflect the company's  |
|             opinion just my own humble one.                          |
\______________________________________________________________________/
From arjon.vlasblom@hta.nl  Mon Dec  2 00:48:50 1996
From: Arjon Vlasblom <arjon.vlasblom@hta.nl>
Date: Mon Dec  2 00:48:51 PST 1996
Subject: Re: Code Coverage tools
At 20:55 29-11-96 PST, you wrote:
>
> Submitted-by selliott@mkc.com.au  Fri Nov 29 20:54:51 1996
> Submitted-by: Steve Elliott <selliott@mkc.com.au>
>
> Does anyone know of any code coverage tools which have been implemented for
> VxWorks applications?
>
> Also we are looing for any test case generation tools which may be
available.
>
> Steve Elliott
>
Hello Steve,
Try to find GCT (Gnu Coverage Testing) on the net.
We used it in VxWorks applications for version 5.2 on i960 CPU's and it is
working fine.
Kind regards,
Arjon Vlasblom
--                                ////
                                 (0 0)
 _____________________________o00_( )_00o______________________________
/                                                                      \
|  Arjon Vlasblom                     High Tech Automation BV          |
|  voice: +31 499 474725              Ekkersrijt 4006, 5692 DA Son     |
|  fax  : +31 499 474799              The Netherlands                  |
|  email: arjon.vlasblom@hta.nl       http://www.hta.nl                |
|----------------------------------------------------------------------|
|      T H E   E M B E D D E D   S O F T W A R E   C O M P A N Y       |
|----------------------------------------------------------------------|
| Disclaimer: This message does not necessarily reflect the company's  |
|             opinion just my own humble one.                          |
\______________________________________________________________________/
From burt@xylan.com  Mon Dec  2 10:52:45 1996
From: burt@xylan.com (Burt Cyr)
Date: Mon Dec  2 10:53:03 PST 1996
Subject: Re:  Code Coverage tools
Steve Elliot wrote:
> Does anyone know of any code coverage tools which have been implemented
> for VxWorks applications?
We recently evaluated Applied Microsystem's CodeTest product and decided to
purchase it. It's got a nice GUI based on X and actually provides a lot of
information that would be difficult to capture in the vxworks environment.
It introduces a bit of overhead into your code since it instruments
every decision path (as would be expected) such as branches, function
entry/exit, etc.
They provide four basic modules: performance analysis, code coverage,
memory use (for leak detection) and trace. Their trace buffer has a few
preconfigured sizes which go from small (4K events) to large (400K events)
where an event is defined to be a branch or entry point.
A vxWorks interface is provided which interfaces with the taskHookLib. No
modification is necessary there. Eval units are available from the factory and
they do provide some support to get the eval going.
A contact point in the US would be:
	Jeff Butcher, Acct Mgr		jwb@amc.com
	(714) 852-9446 or
	(800) 290-5187
Burt
==================================================================
    v  _                                 Xylan, Inc.
  ____(_)___    Burt Cyr                 26679 Agoura Rd. Suite 100
  _-_-__-_-_-_    burt@xylan.com         Calabasas, CA 91302
  --_-_--_-_-                            (818) 878-4533
==================================================================
From mea@mclean.sparta.com  Mon Dec  2 12:57:40 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Mon Dec  2 12:57:42 PST 1996
Subject: Re: socket: synchronous, asynchronous, blocking and
At 06:53 AM 11/29/96 PST, you wrote:
>Submitted-by yfan@spar.ca  Fri Nov 29 06:53:12 1996
>Submitted-by: Yibing Fan <yfan@spar.ca>
>
>Hi Everyone,
>
>I am confused by recent discussion of asynchronous socket.
>I've been using TCP and UDP socket in both blocking and non-blocking
>way, and never questioned myself about socket is synchronous or
>asynchronous. I had no doubt that these (synchronous and blocking) are
>two different sets of concept. I can rationalize myself  that the TCP
>socket is synchronous,  because message is guaranteed delivery, so
>some sort of acknowledgement has to be send back to sender. This
>must be done by layers lower than application. I would guess it is done
>by TCP/IP layer.
>For UDP socket I always think it is asynchronous. Am I  wrong?
>Someone please strait me out.
>
Greetings!
  In this particular context, the term "asynchronous" is used to describe
the behavior of sockets that have been marked as such *and* have the
ability to "asynchronously" alter the control flow of your application
when a message arrives for the given port (typically using the signal
mechanism).  This means that your application could be running merrily
along and suddenly jump to a signal handler when a message came in
via IP.  This requires that the O/S support the SIGIO signal handler
facility, which VxWorks does not.  This is a completely different
issue from blocking vs. non-blocking sockets, as many posters, including
myself, have already pointed out.
  To see a more complete discussion of the topic, please check out W.R.
Steven's  Unix Network Programming. It is the "bible" of network programming
techniques.
HTH,
==============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
==============================================================================
From daemon@csg.lbl.gov  Tue Dec  3 04:00:22 1996
From: daemon@csg.lbl.gov
Date: Tue Dec  3 04:00:24 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Dec  3 04:00:19 PST 1996
        Subject: IDE Drivers for 68K Based design
        Subject: Re: non blocking sockets
        Subject: Re: non blocking sockets
        Subject: Re: Asynchronous sockets
        Subject: VxWorks/C++ users?
        Subject: Senior Programmer position
        Subject: MVME162 FLASH file system
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: IDE Drivers for 68K Based design
Date: 24 Nov 1996 13:01:46 GMT
From: "David Bole" <davidbic@iol.ie>
Organization: BIC Systems
Message-ID: <01bbda08$cdb1dd80$dd2f7dc2@david-bole>
Anyone know where I can get a device driver for an IDE drive
running inside a 68K based design.
thanks
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: non blocking sockets
Date: Fri, 29 Nov 96 23:33:44 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57nrps$rfh@idiom.com>
References: <3298F82D.167EB0E7@bbn.com> <57e32v$buh@idiom.com> <329BAA9E.5DA0@pacbell.net> <valentinE1MI0s.4Cs@netcom.com>
In article <valentinE1MI0s.4Cs@netcom.com>, valentin@netcom.com (Valentin Pepelea) wrote:
>In article <329BAA9E.5DA0@pacbell.net> dcaustin@pacbell.net writes:
>>
>>> Again, non-blocking sockets != asynch sockets.
>>> The non-blocking one is supported in VxWorks, asynch one is *not*!
>>
>>ok... I thought non-blocking == asynch i/o so....... What is "asynch
>>sockets"?
>
>Actually, asynchronous I/O usually refers to what happens during the trans-
>mission of data. If the sender has to block after a send operation, until the
>receiver replies to confirm that the data has been received, then the I/O
>operation is called synchronous. If the sender returns immediately from the
>send(), the operating is called asynchronous.
>
>Non-blocking usually refers to what happens to the receiver. If the receiver
>tries to read data and there is no data present, what happens? If he blocks
>until some data is present, the call is blocking. If he returns immediately,
>with or without and error code, the call is non-blocking.
>
>I'm not sure about VxWorks, but Berkley sockets are by default asynchronous.
>A send() call always returns immediately, regardless of whether the data ever
>reaches the destination. Oh what fun. The recv() call may block or not, as
>optionally set on a per-socket basis by the programmer.
>
This is perhaps the most unique definition of non-blocking vs. asynch I've
seen.  I don't care about the lingo, but perhaps I should tell you what
I meant w.r.t VxWorks and BSD non-blocking sockets and asynch I/O on sockets.
non-blocking I/O over sockets is just that -- when you call I/O system
calls you will not block.   It has nothing to do with whether you do
and recv-side I/O call or send-side I/O call.   Even in BSD, send-side
call can block -- yes, send() will block when local-side socket level
buffer runs out, until there is more room to copy in the user data.
In that instance, a non-block'ed socket will return on send(), indicating
the buffer exhaustion condition.  recv() is obvious; if there's no data
to be read or not enough to be read, it returns, instead of waiting.
Async I/O over sockets (or any other descriptor type) requires signalling
via SIGIO when I/O events occur.  This works fine in later BSD (4.4 and
post-tahoe 4.3), but not in VxWorks.   VxWorks signals are not implemented
the same way as Unix ones, and have subtle differences (or I should say
it used to have subtle differences when I thought of doing asynch I/O
for VxWorks, WRS may have fixed it).
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: non blocking sockets
Date: 29 Nov 1996 15:23:53 -0800
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <57nra9$kqs@mr-ed.jpl.nasa.gov>
References: <3298F82D.167EB0E7@bbn.com> <57e32v$buh@idiom.com> <329BAA9E.5DA0@pacbell.net>
In article <329BAA9E.5DA0@pacbell.net>,
Duane C Austin  <dcaustin@pacbell.net> wrote:
>[snip]
>
>>
>> Again, non-blocking sockets != asynch sockets.
>> The non-blocking one is supported in VxWorks, asynch one is *not*!
>>
>> http://peacefulstar.oakland.ca.us
>> mailto:hjb@peacefulstar.oakland.ca.us
>
>ok... I thought non-blocking == asynch i/o so....... What is "asynch
>socket
asynchonous I/O is not polled
- --
matthew.r.wette@jpl.nasa.gov
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: 1 Dec 1996 19:06:09 GMT
From: "Arve Sollie" <asollie@online.no>
Organization: ABB Network Partner
Message-ID: <01bbe083$f8f0f860$6c63d4c1@nenu02h1.nopow.abb.no>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>
Async vs Sync sockets.
A send() calls to a sync socket ( TCP ) will force an IP datagram to be
generated, event if the window is not full. On async() sockets, flushing
will
be done by the net-task when a flush-timer has expired.
Sync sockets giv much less latency when sending small amounts of data (
telnet, poll operations ),
but the cost is a lot of small IP datagrams.
UDP datagrams are atomic TPDUs, and no differentiation make sense.
( Except for handling in user context, and not in nettask context )
James Lewis <ljames@okstate.edu> wrote in article
<01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>...
> I was wondering how to make an ethernet socket asynchronous
(non-blocking).
>  On the host Sparc station this is done with an ioctl call.  I assume
that
> VxWorks handles it
> the same way.  If so, how is it done?  Any hints would be greatly
> appreciated.
>
> Thanks,
> James Lewis
> ljames@okstate.edu
>
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks/C++ users?
Date: Sat, 30 Nov 1996 02:53:40 GMT
From: njt@worlds-edge.u-net.com (N Turner)
Organization: U-NET limited
Message-ID: <57o7eb$i86@nuntius.u-net.net>
Reply-To: njt@worlds-edge.u-net.com
If anyone is using the VxWorks RTOS (C++ libraries) with C++?
What development methods and tools are you using?, e.g OMT, Tornado
etc. Has anyone delivered and os anyone supporting products inthe
field developed using Tornado?
Although I have read a considerable amount about combining objects and
concurrent processes(language extensions, new languages, use of
libraries or classes that support concurrency issues), I have little
idea how to design for real-time using objects based on the use of a
library such as VxWorks.  My experience is based on the use of OCCAM.
Does anyone know of any useful articles(preferably available on the
.net) that  I can refer to, to get started?
The one useful book I do have is:
Title:        Object-Oriented Technology for Real-Time Systems
               - A Practical Approach Using OMT and Fusion(1996)
Authors :  Maher Awad, Juha Kuusela, Jurgen Ziegler
Publisher: Prentice-Hall
ISBN:       0-13-227943-6
Price UK Sterling36-95(It's hardback - 276 pages)
Its written by engineers, is very applied and technically
detailed(particularly about parallel processing) and contains a
couple of farly well documented case studies.  Some C++ code is
included in the book to show you what the implemenation looks like but
the book isn't littered with unneccessary code listings.
BTW Bill McCombie of:
>ENEA OSE SYSTEMS AB		E-mail: bill@enea.se
>Box 232				WWW   : http://www.enea.se/ose
>S-183 23 TABY			Phone : +46-8-638-5000
>Sweden				Fax   : +46-8-638-5050
tells me that the case studies in the book were implemented with the
OSE RTOS from Enea OSE Systems.
Thanks in advance...
---------------------------
Newsgroups: sci.image.processing,alt.image.medical,comp.lang.tcl,comp.os.vxworks
Subject: Senior Programmer position
Date: Mon, 02 Dec 1996 15:45:00 -0700
From: Tony Poyner <apoyner@as.arizona.edu>
Organization: Multiple Mirror Telescope Observatory
Message-ID: <32A35BEC.5B20@as.arizona.edu>
COMPUTER SPECIALIST, TELESCOPE, SENIOR
The Multiple Mirror Telescope Observatory at the University of Arizona
is seeking a Senior Computer Specialist to work on problems of image
analysis, aquisition and processing; instrument and telescope subsystem
control; and computer network maintenance.  Programs are being developed
for the existing 4.5m telescope at the 8500 foot summit of Mt. Hopkins,
40 miles south of Tucson, and for the 6.5m telescope that will replace
it begining in 1997.
The duty station for this position is located on the U of A campus in
Tucson, but 3-4 days per month typically will be spent at the
telescope.
System installation, checkout and maintenance will require some night-
time work.
Development of these application programs requires knowledge of
spherical geometry, celestial coordinate systems, engineering
mathmatics, image processing techniques and the problems of
astronomical observing.  Therefore, a successful applicant will have a
background in Astronomy, Physics or related Science, or an applicable
Engineering field.  Applicants should have experience in C programming,
Unix, realtime programming and image processing.  Knowledge of the
VxWorks operating system, Tcl/TK, IRAF, Datacube image processing
hardware, or system administration of Unix networks would be a strong
plus.
MINIMUM REQUIREMENTS:  Master's or higher degree in a related Science or
Engineering field AND four years experience programming computer systems
for integrated telescope control, data acquisition and image processing;
OR Bachelor's degree in a related Science or Engineering field AND five
years experience programming computer systems for integrated telescope
control, data acquisition and image processing
Hiring salary range: $39173 to $46197 dependent on experience level.
An official University of Arizona application is required (resume
alone is not sufficient).  Closing date: 31 December 1996.
        EMPLOYMENT SERVICES
        888 N Euclid Ave #117
        Tucson, AZ 85721-0158
        (520) 621-3660
        TDD (520) 621-8299
Additionally, resumes may be sent to
        MMTO, University of Arizona
        Tucson, Az 85721
        FAX (520) 670-5740
University of Arizona is an EEO/AA/ADA employer.
- --
Tony Poyner                               apoyner@as.arizona.edu
Multiple Mirror Telescope Observatory     Tel   (520) 621-5185
Univ. of Arizona, Tucson, AZ 85721        Fax   (520) 670-5740
---------------------------
Newsgroups: comp.os.vxworks
Subject: MVME162 FLASH file system
Date: 2 Dec 1996 21:15:23 GMT
From: tmichaud@osf1.gmu.edu (Thomas M Michaud)
Organization: George Mason University, Fairfax, Virginia, USA
Message-ID: <57vgtb$ar8@portal.gmu.edu>
Has anyone successfully ported a FLASH file system to the MVME162?
Tom Michaud
tmichaud@gmu.edu
---------------------------
End of New-News digest
**********************
From p72950@gmcl.co.uk  Tue Dec  3 04:58:51 1996
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Tue Dec  3 04:58:56 PST 1996
Subject: Re:  Code Coverage tools
>Steve Elliot wrote:
>
>> Does anyone know of any code coverage tools which have been implemented
>> for VxWorks applications?
>We recently evaluated Applied Microsystem's CodeTest product and decided to
>purchase it. It's got a nice GUI based on X and actually provides a lot of
>information that would be difficult to capture in the vxworks environment.
>
>It introduces a bit of overhead into your code since it instruments
>every decision path (as would be expected) such as branches, function
>entry/exit, etc.
>
>They provide four basic modules: performance analysis, code coverage,
>memory use (for leak detection) and trace. Their trace buffer has a few
>preconfigured sizes which go from small (4K events) to large (400K events)
>where an event is defined to be a branch or entry point.
<snip>
>Burt
We have also evaluated CodeTEST recently and like Burt have decided to
purchase it. In our case though we are interested in the 'trace' facility
as it is easier to see program flow than with a logic analyser.
There is an Applied Microsystems Web page (http://www.amc.com) where details
of CodeTEST & other products may be found.
Regards
Phil Quiney
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From AS_Bridge@MSMAIL3.HAC.COM  Tue Dec  3 07:34:05 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Dec  3 07:34:23 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: comp.os.vxworks newsdigest
Sent: Tue, Dec 3, 1996 6:11 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Dec 3, 1996 7:32 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From AS_Bridge@MSMAIL3.HAC.COM  Tue Dec  3 08:09:02 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Dec  3 08:09:20 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Re:  Code Coverage tools
Sent: Tue, Dec 3, 1996 7:06 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Dec 3, 1996 8:07 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From cgrames@mdc.com  Tue Dec  3 11:33:33 1996
From: Charlie Grames <cgrames@mdc.com>
Date: Tue Dec  3 11:33:35 PST 1996
Subject:  Backplane Transfer Software
With experimentation, it has become painfully obvious that VxWorks does not offer an efficient
method of transfering data across the backplane.  Is anyone aware of existing software for
VxWorks that provides a more efficient backplane transfer method?  Preferably, I would like
somthing that uses block transfer mode and perhaps even allows use of any existing DMA
controller in the hardware.
Charlie Grames
McDonnell Douglas Training & Support Systems
(314) 233-1956
CGrames@mdc.com
From mea@mclean.sparta.com  Tue Dec  3 12:31:39 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Tue Dec  3 12:31:45 PST 1996
Subject: Re: Backplane Transfer Software
At 11:33 AM 12/3/96 PST, you wrote:
>Submitted-by cgrames@mdc.com  Tue Dec  3 11:33:33 1996
>Submitted-by: Charlie Grames <cgrames@mdc.com>
>
>With experimentation, it has become painfully obvious that VxWorks does
not offer an efficient
>method of transfering data across the backplane.  Is anyone aware of
existing software for
>VxWorks that provides a more efficient backplane transfer method?
Preferably, I would like
>somthing that uses block transfer mode and perhaps even allows use of any
existing DMA
>controller in the hardware.
>
Greetings!
  There are lots of implementations of "more efficient" (I assume you mean
faster) VME transfer mechanisms.  Unfortunately, each of them is typically
tied to a particular hardware implementation.  The problem is that
Heurikon's VME interface is different from Motorola's, is different from
Synergy's, is different from Themis, is different from Force, etc. ad
infinitum, ad naseum.  Even if two different vendors use the same
interface chip, say the VIC64, they may have implemented DMAs, register
locations, etc. differently or not at all.  So, what you really need to do
is to formulate the question better.  You need to outline your hardware
and your transfer requirements.  Then, there maybe someone on the net
who can supply some sample code.
  What I suspect that needs to happen is that WRS needs to specify an
API for things like BLT, MBLT, DMA, etc. and then each BSP developer can
add support in sysLib.c if the card actually supports those functions.
At least then we could have a standard S/W interface and hide the details
in the BSP.
This answer then remids me of a joke:
> A helicopter was flying around above Seattle yesterday when an
> electrical malfunction disabled all of the aircraft's electronic
> navigation and communications equipment.  Due to the clouds and haze,
> the pilot could not determine the helicopter's position and
> course to steer to the airport.
>
> The pilot saw a tall building, flew toward it, circled, drew a
> handwritten sign, and held it in the helicopter's window.  The pilot's
> sign said "WHERE AM I?" in large letters.
>
> People in the tall building quickly responded to the aircraft, drew a
> large sign, and held it in a building window.  Their sign said
> "YOU ARE IN A HELICOPTER."
>
> The pilot smiled, waved, looked at his map, determined the course to
> steer to SEATAC airport, and landed safely.
>
> After they were on the ground, the co-pilot asked the pilot how the
> "YOU ARE IN A HELICOPTER" sign helped determine their position.
>
> The pilot responded "I knew that had to be the MICROSOFT building
> because they gave me a technically correct, but completely
> useless answer."
Regards,
==============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
==============================================================================
From fangcj@ix.netcom.com  Tue Dec  3 15:54:36 1996
From: CJ Fang <fangcj@ix.netcom.com>
Date: Tue Dec  3 15:54:38 PST 1996
Subject: MMU mapping shuts off Cache
I have been having speed problem on Pentium.
Somehow, MMU mapping shuts off Cache on Pentium
system and slows down VxWorks execution speed.
In sysLib.c, I added an entry into sysPhysMemDesc[]
to map my Ethernet adapter addree space to a
virtual address space. Since the adapter is for PCI
bus, the physical address is controlled by PCI bus
hardware and is at high address location
0xfffb0000.
The entry I added into sysPhysMemDesc[] is:
{
(void *)0xfffb0000,
(void *)0xfffb0000,
0x1000,
VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE |
VM_STATE_MASK_CACHEABLE,
VM_STATE_VALID | VM_STATE_WRITABLE |
VM_STATE_CACHEABLE_NOT }
Can anyone out there tell me why this mapping turns
off Cache? Thank You!
My another problem is that:
If I turn on Cache with cacheLibInit() and
cacheEnable(), I'll run into Cache Coherent
problem.
This problem was assigned a TSR #36864 since
11/11/96. And since about 10 days ago, I heard
nothing back from Wind River even though I sent
E-Mails and called Tech Support many times.
Please help! I appreciate!
From espin@idiom.com  Tue Dec  3 19:02:19 1996
From: Geoffrey Espin <espin@idiom.com>
Date: Tue Dec  3 19:02:20 PST 1996
Subject: Re: MMU mapping shuts off Cache
CJ,
> Subject: MMU mapping shuts off Cache
> Submitted-by fangcj@ix.netcom.com  Tue Dec  3 15:54:36 1996
> Submitted-by: CJ Fang <fangcj@ix.netcom.com>
> The entry I added into sysPhysMemDesc[] is:
> {
> (void *)0xfffb0000,
> (void *)0xfffb0000,
> 0x1000,
> VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE |
> VM_STATE_MASK_CACHEABLE,
> VM_STATE_VALID | VM_STATE_WRITABLE |
> VM_STATE_CACHEABLE_NOT }
This is probably what you want, namely the MMU should
not allow this any data on this page (0x1000 == VM_PAGE_SIZE == 4096))
to be held in the cache.
> Can anyone out there tell me why this mapping turns
> off Cache? Thank You!
This does not turn off the cache.
Unfortunately, VxWorks does not have a
routine to determine the state of the cache.
Yes, you can call cacheEnable() and cacheDisable()
but they don't return the previous state.  :-(
In fact, I'm dubious that the functions correctly
return STATUS on the x86.  Try disassembling them from the shell...
Use this to write: cacheIsOn(which) to determine state.
Geoff
--
Geoffrey Espin espin@idiom.com
From daemon@csg.lbl.gov  Wed Dec  4 04:00:32 1996
From: daemon@csg.lbl.gov
Date: Wed Dec  4 04:00:36 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec  4 04:00:30 PST 1996
        Subject: Re: "Auto" Routing
        Subject: clnt_broadcast (rpc) on 5.11/frc2ce
        Subject: RPC clnt_broadcast -- how ?
        Subject: Re: socket: synchronous, asynchronous, blocking and non-blocking
        Subject: Re: RPC clnt_broadcast -- how ?
        Subject: Re: RPC clnt_broadcast -- how ?
        Subject: Windnet Streams and streamtab device drivers
        Subject: Optimization of VxWorks kernel; specifically Sockets layer?
        Subject: Integration of WindCFG with a version control tool
        Subject: Slow target server connection
        Subject: How to setup time() and TOD clock on mv162 board
        Subject: Re: Ada Tasking/Rendezvous vs. VxWorks Tasking
        Subject: Re: socket: synchronous, asynchronous, blocking and non-blocking
        Subject: Re: How to set the cursor on vt100-terminal.
        Subject: GDB Monitor
        Subject: Re: Slow target server connection
        Subject: get system in msecond and usecond unit
        Subject: loading new tasks in realtime
        Subject: Re: Slow target server connection
        Subject: Re: CD-ROM & ZIP drives under VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: "Auto" Routing
Date: 3 Dec 1996 13:44:37 GMT
From: "Arve Sollie" <asollie@online.no>
Organization: ABB Network Partner
Message-ID: <01bbe1e9$536e7cc0$7b63d4c1@nenu02h1.nopow.abb.no>
References: <57henc$4rj@news.res.ray.com> <57i3bo$on3@idiom.com>
H.J. Bae <hjb@peacefulstar.oakland.ca.us> wrote in article
<57i3bo$on3@idiom.com>...
> In article <57henc$4rj@news.res.ray.com>, milesm@tif531.ed.ray.com
(Michael Miles) wrote:
>><<<
> Your co-worker is wrong.  VxWorks will not detect the failure and
re-route
> automatically.  You either have to do this in your application (edit
> routing table), or use a routing protocol daemon (port one on your own).
>
A possible solution to your problem is to write a pseudo-device driver,
which present the entire
cluster of interfaces as a single device to the higher layers. As far as I
know, there is no support
in VxWorks for more than one MAC address per device, so all physical
devices should have the
same MAC address. The MAC address is editable on some classes of NIC's.
This setup will
only work if link redundancy is the goal. If device swithcing is handled by
the link-layer,
no network layer interaction is necessary.
---------------------------
Newsgroups: comp.os.vxworks
Subject: clnt_broadcast (rpc) on 5.11/frc2ce
Date: Mon, 02 Dec 1996 02:40:27 GMT
From: johnston@hom.net (Albert S.  Johnston)
Organization: Homenet Communications, Inc.
Message-ID: <329f70bb.10825364@pop.hom.net>
Hi,
Has anyone gotten the clnt_bradcast routine to work?  Althought it is
in the vxworks header files it does not seem to be part of VxWorks...
I have found some sun code in the unsupported directory, but I
am having trouble getting it to work.
Anybody done this already?
       thanks,
                     -al
---------------------------
Newsgroups: comp.os.vxworks
Subject: RPC clnt_broadcast -- how ?
Date: Mon, 02 Dec 1996 02:40:29 GMT
From: johnston@hom.net (Albert S.  Johnston)
Organization: Homenet Communications, Inc.
Message-ID: <32a0b2e8.27768960@pop.hom.net>
Hi,
I was wondering if anyone has gottin a clnt_broadcast call coded up
and working under vxWorks?
It seems to be in the header files but not in vxWorks exicutable it
self.
I found the sun code in the unsupported directory, but that seems
to be awful complicated for what I need....
Can any one help?
running vxWorks 5.11 on frc2ce connected to a sun (sunos 4.1.2)
network... yp/nis based....
Thanks,
                 -al
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: socket: synchronous, asynchronous, blocking and non-blocking
Date: 2 Dec 1996 14:25:31 GMT
From: kadionik@aramis (Patrice KADIONIK (IXL - CNRS URA 846 - FRANCE))
Organization: CRIBX1 , Universite de Bordeaux I , France
Message-ID: <57uosr$t4i@news.u-bordeaux.fr>
References: <s29eb2c4.092@SPAR.CA>
Yibing Fan (yfan@spar.ca) wrote:
: Hi Everyone,
: I am confused by recent discussion of asynchronous socket.
: I've been using TCP and UDP socket in both blocking and non-blocking
: way, and never questioned myself about socket is synchronous or
: asynchronous. I had no doubt that these (synchronous and blocking) are
: two different sets of concept. I can rationalize myself  that the TCP
: socket is synchronous,  because message is guaranteed delivery, so
: some sort of acknowledgement has to be send back to sender. This
: must be done by layers lower than application. I would guess it is done
: by TCP/IP layer.
: For UDP socket I always think it is asynchronous. Am I  wrong?
: Someone please strait me out.
: Thanks
: =========================
: Yibing Fan
: yfan@spar.ca
: Video et Taceo
: =========================
Hi Yibing;
I just know blocking or non blocking socket calls. The choice between
these two modes may be done by a ioctl() or fcntl() call.
A non blocking mode is interesting when you want to poll several sockets
in the same time with a poll() call and don't want to be blocked on
one socket.
TCP or UDP packets transmission with the socket API is asynchronous because
you don't know when the kernel will execute your job (on a write() call).
It's also true in
reception because you don't know when you will have a connection (on a
listen() call) or receive a packet (on a read() call).
With the select() call, you can do a synchronous multiplexing on sockets (in
fact on file descriptors) in order to help you to work on several
sockets BUT in all cases the basical mechanism stays asynchronous.
You have in fact a FASYNC option that permits the kernel to emit a signal
SIGIO  to a process group when data are ready (in reception for example).
It may be a method to wake up a process blocked on a socket used in the
blocking mode (by default).
Regards;
- --
Pat.
- -----------
                                \^ ^/
                                )@ @(
                  +---------oOO--(_)-------------+
                  |      Patrice Kadionik        |
                  |  kadionik@ixl.u-bordeaux.fr  |
                  +-----------------Oooo--oOO----+
                              oooO (   )
                             (   )  ) /
                              \ (  (_/
                               \_)
=========================================================================
| "Tout doit etre aussi simple que possible, pas seulement plus simple" |
=========================================================================
| Patrice Kadionik                                                      |
|    IXL                           Fax   : +33 5.56.37.15.45            |
| Laboratory of Microelectronics   Voice : +33 5.56.84.65.40            |
| 351, Cours de la liberation      http  : http://www.ixl.u-bordeaux.fr |
| 33405 TALENCE cedex              mail  : kadionik@ixl.u-bordeaux.fr   |
| FRANCE                                                                |
=========================================================================
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: RPC clnt_broadcast -- how ?
Date: Tue, 3 Dec 1996 10:26:32 GMT
From: noblenet@world.std.com (NobleNet Inc.)
Organization: NobleNet, Inc.
Message-ID: <E1u2C9.8As@world.std.com>
References: <32a0b2e8.27768960@pop.hom.net>
In article <32a0b2e8.27768960@pop.hom.net>,
Albert S.  Johnston <johnston@hom.net> wrote:
>I was wondering if anyone has gottin a clnt_broadcast call coded up
>and working under vxWorks?
Please contact NobleNet for ONC/RPC tools and solutions for UNIX,
Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc.
        NobleNet, Inc.
        337 Turnpike Road
        Southboro, MA  01772
        Voice +1 508 460 8222
        Fax +1 508 460 3456
        <sales@noblenet.com>
        <http://www.noblenet.com/>
PRESS RELEASE
For Immediate Release
For Further Information, Please Contact:
David Burns
Vice President of Marketing
NobleNet, Inc.
Voice: (508) 460-8222
FAX: (508) 460-3456
e-mail: david.burns@noblenet.com
"The Client/Server Toolkit for C and C++ Programmers"
New Book From NobleNet Turns Programmers Into Client/Server Experts
New York, October 8, 1996 --  NobleNet, Inc. today announced the availability
of its newly published book that turns C and C++ programmers into
client/server experts.   Co-authored by middleware experts Steven Lemmo and
Rich Grehan, The Client/Server Toolkit for C and C++ Programmers  is a self-
contained instructional tool that teaches programmers how to distribute any
application or Application Programming Interface (API) across a network.
The CD-ROM software included with The Client/Server Toolkit features a unique
Windows-based client/server simulator that lets programmers gain hands-on
experience in client/server partitioning.  Programmers are guided through four
"real-world" client/server projects: distributed ODBC database, scanner
device, image engine, and datafeed.  The authors expertise combined with a
Rapid Application Development (RAD) environment, demystifies the art of
distributing complex applications.
"I learned more about client/server development in the last three days of
reading your book than I learned in the past few years of doing C and C++
programming," said Pascal Specht, Technical Sales Engineer at Precision
Software in Paris, France.
"Our new book will help any C or C++ programmer that wants to learn about
state-of-the-art client/server computing," said Steve Lemmo, co-author and
Chief Technology Officer of NobleNet.  "The techniques taught in the book will
help programmers learn to use the powerful Interface Definition Languages
(IDLs) found in today's most popular distributed computing middleware."
Beginning with a monolithic application, readers learn how to separate
programs into independent parts that communicate with each other.  While other
books on client/server computing include sample code, The Client/Server
Toolkit goes further and delivers a true client/server Software Development
Toolkit (SDK) designed for application partitioning.  Unlike other approaches,
programmers learn to build client/server applications using industry-standard
RPC technology that requires no source code changes.
"The Client/Server Toolkit is ideal for programmers that want to get a quick
immersion into client/server computing with tools that require very little
effort to learn,"  said Vincent Russo, Assistant Professor of Computer Science
at Purdue University.  "I like the fact that the book is totally self-
contained.  It has a wealth of real-world examples that provide the reader
with a thorough understanding of client/server development.  And the simulator
gives programmers hands-on experience with building and running real
client/server applications."
Although The Client/Server Toolkit is written for C and C++ programmers,
examples are given that show "drag and drop" programmers how to create
client/server applications utilizing popular GUI front-ends such as Visual
Basic, PowerBuilder, Delphi, and Developer 2000.  Distributed with the book is
a free version of NobleNet's powerful standards-based RPC product used by
client/server developers world-wide.  Programmers are presented with client
and server Windows connected by a simulated network.  Using NobleNet RPC,
applications developed on the simulator are easily deployed to over 40
platforms including 26 UNIXes, Windows 3.1, 95, and NT, NetWare, Macintosh,
OS/2, and VMS.  More than 20 Windows-based TCP/IP stacks are supported to
ensure operation in existing multi-vendor environments.
Co-author Steven Lemmo founded NobleNet, engineered NobleNet's first software
product, EZ-RPC(R), and led the team that developed the company's NetWare and
Windows-based middleware tools.  With an in-depth understanding of both
communication and application software, he is a sought after consultant on RPC
programming.  Steve has over fifteen years of experience in software
engineering and tools development in companies such as Computervision Corp.,
Sun Microsystems, Inc., and Xerox Imaging Systems, Inc.  He is widely
recognized as an expert on distributed computing and is frequently called upon
to appear at industry forums.
Co-author Rick Grehan has been on the editorial staff of BYTE Magazine for
over 11 years.  He is currently the Technical Director of BYTE Labs and the
author of BYTE's monthly CodeTalk column.  His articles have appeared in BYTE,
Embedded Systems Programming, and Forth Dimensions.  In addition, he was a
contributor to the 1993 edition of The Encyclopedia of Microcomputers,
published by Marcel Dekker, Inc.  Rick is also the designer of BYTE Magazine's
BYTEmark benchmark suite.
The Client/Server Toolkit for C and C++ Programmers is published by NobleNet.
The 350 page book with CD-ROM can be ordered for $49.95 by calling (800)-250-
6427 or (508)-893-0398.
NobleNet offers tools for distributed client/server development for procedural
and object paradigms. Incorporated in 1991, NobleNet is a world leader in
Remote Procedure Call (RPC) technology and has won numerous awards for its RPC
product family.   NobleNet also distributes IONA Technologies' industry-
leading "Orbix" CORBA-compliant Object Request Broker. The company is
headquartered in Southboro, MA, and can be reached at (508) 460-8222 or at
<http://www.noblenet.com/>.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: RPC clnt_broadcast -- how ?
Date: Tue, 03 Dec 96 07:56:34 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <580mda$7qf@idiom.com>
References: <32a0b2e8.27768960@pop.hom.net>
In article <32a0b2e8.27768960@pop.hom.net>, johnston@hom.net (Albert S.  Johnston) wrote:
>Hi,
>
>I was wondering if anyone has gottin a clnt_broadcast call coded up
>and working under vxWorks?
>
>It seems to be in the header files but not in vxWorks exicutable it
>self.
clnt_broadcast() is in the library.  You may not be linking it into
your VxWorks kernel image but it's there.  As for examples, what
could be simpler than what's in the rpc4.0 release directory?
The file unsupported/rpc4.0/etc/rpcinfo.c contains the following function:
static void
brdcst(argc, argv)
        int argc;
        char **argv;
{
        enum clnt_stat rpc_stat;
        u_long prognum, vers;
        if (argc != 2) {
                usage();
                exit(1);
        }
        prognum = getprognum(argv[0]);
        vers = getvers(argv[1]);
        rpc_stat = clnt_broadcast(prognum, vers, NULLPROC, xdr_void,
            (char *)NULL, xdr_void, (char *)NULL, reply_proc);
        if ((rpc_stat != RPC_SUCCESS) && (rpc_stat != RPC_TIMEDOUT)) {
                fprintf(stderr, "rpcinfo: broadcast failed: %s\n",
                    clnt_sperrno(rpc_stat));
                exit(1);
        }
        exit(0);
}
/*ARGSUSED*/
static bool_t
reply_proc(res, who)
        void *res;              /* Nothing comes back */
        struct sockaddr_in *who; /* Who sent us the reply */
{
        register struct hostent *hp;
        hp = gethostbyaddr((char *) &who->sin_addr, sizeof who->sin_addr,
            AF_INET);
        printf("%s %s\n", inet_ntoa(who->sin_addr),
            (hp == NULL) ? "(unknown)" : hp->h_name);
        return(FALSE);
}
As you can see this is as simple as it gets.   Be warned, however,
the clnt_broadcast() function was never tested in VxWorks when I
ported rpc4.0 over to vxWorks (in 1989!).   I could be wrong, but
I don't think WRS did any further work on the RPC stuff since then.
It seems to be still pretty vanilla 4.0 RPC I ported (I'm using
VxWorks 5.3, a.k.a. Tornado).
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Windnet Streams and streamtab device drivers
Date: Tue, 03 Dec 1996 10:57:40 +0200
From: Casey Crellin <casey@ccii.co.za>
Organization: CCII Systems
Message-ID: <32A3EB84.2B69A37A@ccii.co.za>
Reply-To: casey@ccii.co.za
Hi,
I am in the process of writing my first streams device driver.
Is there any source available that deals with the initialization of the
device through the streamtab struct?
Is it just a case of writing the driver code and then attaching it via
the process below or is there more involved to get it "running"?
Any help would be very much appreciated.
Thanks
Casey
- --
Casey Crellin                                          casey@ccii.co.za
CCII Systems (Pty) Ltd
- ------------------------------------------------------------------------
- -------------------------------8<---------------------------------------
#include "stdio.h"
#include "types/vxTypesOld.h"
#include "errno.h"
#include "strmLib.h"
#include "streams/stream.h"
#include "h/targetos.h"
extern int errno;
extern struct streamtab skfpinfo;
STATUS ldfddi()
    {
    /* add the driver */
    STATUS status = strmDriverAdd( "/dev/fddi",
                    &skfpinfo,
                    FALSE,
                    NULL,
                    SVR4_STYLE_OPEN,
                    SQLVL_QUEUEPAIR );
    if (status == ERROR)
	    {
	    fprintf(stderr, "ERROR: %d \n ", errno);
	     printErrno (errno);
    }
- -------------------------------8<---------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Optimization of VxWorks kernel; specifically Sockets layer?
Date: 3 Dec 1996 18:27:02 GMT
From: mcatalan@aol.com
Organization: AOL http://www.aol.com
Message-ID: <19961203182800.NAA11000@ladder01.news.aol.com>
Has anyone ever turned on compiler optimization when building all/parts of
the VxWorks kernel?   Specifically, the socket-level functions are
extremely SLOW in performing their jobs (i.e. the "select" call takes over
120 micro seconds to execute with FD_SETSIZE equal to 30 !!).
The reson is simple, I am trying to tweak code to get it to run as
efficiently as possible.
Any help or pointers would be appreciated !
Thanks,
Mike Catalanotti
catman@codem.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Integration of WindCFG with a version control tool
Date: 3 Dec 1996 13:20:59 -0500
From: clare@moe.pixel.kodak.com (Bill Clare)
Organization: Eastman Kodak Company
Message-ID: <581r2b$1jc@moe.pixel.kodak.com>
I am starting to investigate the use of Tornado on our project.  One of the
things I'd like to do is to either make WindCFG a lot smarter, or remove it
altogether from the list of icons available from the launcher.  Specifically
what I'd like to do is integrate it with our version control tool, and also
have it work on more than just configAll.h and config.h.
I'd like to know if anyone has gone through this effort, and if they found it
a worthwhile exercise, or is it just easier to edit all the files I have to
edit by hand like I've been doing.
Thanks in advance billc
- --
Bill Clare, Eastman Kodak Company	Internet: clare@bisco.kodak.com
mail code 35424 --  901 Elmgrove Road	Phone:    (716) 726-9419
Rochester, New York 14653-5424		May $5M, Hasek <$800K.  I don't get it..
Any opinions expressed herein belong to me and not to my employer.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Slow target server connection
Date: 3 Dec 1996 21:24:46 GMT
From: sparks@winternet.com (Hugh Sparks)
Organization: StarNet Communications, Inc
Message-ID: <5825qu$kcu@blackice.winternet.com>
We have a NT Workstation running Tornado 1.0 FCS. It is connected
to a PowerPC (MVME1604) in a VME box with a dedicated Ethernet.
We added an Ethernet board to the host just for this connection.
The host also has a built-in Ethernet card connected to the corporate
LAN.
The problem is that the Target Server takes a very very long time
to connect to the target system. Usually at least a minute.
Has anyone else seen/resolved this problem?
Thanks,
Hugh Sparks,  hugh.sparks@mts.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: How to setup time() and TOD clock on mv162 board
Date: 2 Dec 1996 19:50:52 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <58082s$3nj@elaine35.Stanford.EDU>
I use the following function to print the date/time from VxWorks shell.
char *currentTimeString( void )
{
  static char timeString[100];
  time_t clock;
  /* get current calendar time */
  clock = time( 0 );
  /* convert time in seconds into a string (ANSI) */
  strcpy( timeString, ctime( &clock ) );
  printf("*** %s ***\n", timeString) ;
}
When I invoke this program from the shell I get the following output:
v6-> ld < test.o
value = 3812076 = 0x3a2aec
v6-> currentTimeString
*** THU JAN 01 00:00:00 1970
 ***
value = 4184608 = 0x3fda20 = test.o_data
# wait a few seconds and enter again
v6-> currentTimeString
*** THU JAN 01 00:00:08 1970
 ***
So the clock seems to sort of be working. Now I have two questions:
1. How can I initialize the clock so that it shows the correct date?
   Does clock_settime() write to the memory map for TOD clock
   or do I have to do it myself?
2. When I repeated the test above (from powerup) I waited a long time to first invoke
   "currentTimeString" after loading test.o, and it still returned this?
*** THU JAN 01 00:00:00 1970
 ***
   Is the time() function in VxWorks actually using the Time of Day (TOD)
   clock on the mv162 board at all? Do I have to configure this somehow.
Still waiting for answers from WRS after a week.
So if anybody has done this before please post some tips. Thanks.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Ada Tasking/Rendezvous vs. VxWorks Tasking
Date: Mon, 25 Nov 1996 08:13:07 -0400
From: jcreem@mailgw.sanders.lockheed.com (Jeff Creem)
Organization: Jeff Creem
Message-ID: <jcreem-2511960813070001@ljd155.sanders.lockheed.com>
References: <01IC3SUOEG52002RFM@emamv1.orl.mmc.com>
In article <01IC3SUOEG52002RFM@emamv1.orl.mmc.com>,
Susan_J_Henry@ccmail.orl.mmc.com wrote:
> Hello,
>
> We are developing a real-time embedded application in Ada (and C as
well).  Our
> target is the PowerPC (MVME 1603) and are using Green Hill's Multi Cross
> Compiler and VxWorks 5.3.  We are in the detailed design phase of the project
> and looking to use the VxWorks tasking model (tasks, message queues, and
> semaphores) versus using the Ada language Task Structure and the
Rendezvous.  We
> have been told (by WRS) that VxWorks tasking is more efficient and less
overhead
> then Ada's.  Has anyone out there performed a trade study or have hard
> throughput numbers to back this up?  Our customer is familiar with Ada
tasking
> and not VxWorks and wants justification why we think VxWorks tasks are
the way
> to go.  I'm posing the question and hoping to receive an answer, otherwise we
> are going to have to do this study.
>
> Thanks in advance,
> Sue Henry
> Lockheed Martin
> susan_j_henry@ccmail.orl.lmco.com
Hmm,
  Well at least with VADS (an I believe this to be true with green hills too)
Ada tasks map one-to-one with vxWorks tasks. On projects where we have used
Ada with vxWorks we do all task creation with Ada tasks. Then, within the
context of the Ada tasks we use a variety of control methods including Ada
rendezvous and vxWorks semaphores, mailboxes etc. (usually after using an
elaboration rendezvous to prevent the task from getting to semaphore or
mailbox code until the objects have been created)
For example, in Ada 83, there is no really good way to ensure atomic
data access to a large data structure without wrapping a monitor task around
it. This then requires a context switch for every access to the object
(some compilers allow for the concept of a passive task that gets around
this but while the code then ends up portable the passive task concept
is not so the code will run everwhere but not as well as under the one
or two compilers that support the idea).
So, in situaions like this we use vxWorks semaphores (actually VADS semaphores
which are layered on top of vxWorks) to protect the data.
(We will probably have to adjust our approach for ADa 95 since there are
 protected records that will accomplish what we want (in general)).
We also make use of vxWorks mailboxes when we think it is appropriate.  So,
to make a long story short, In general I do no think there is a huge issue
here. If buffering makes sense use mailboxes. if you need lock step running
of tasks or nifty complex time-out use rendezvous. if you want atomic
data protection use semaphores.
Unless your customer explicitly forbids calls to any OS routines I would not
treat these features any different than any other semi-non-portable OS
call. (Obviously its nice to wrap all OS routines in either your own package
wrapper or try to use a POSIX equivilent).
Oh, also we have always used semaphores for kicking off tasks that are
essentially controlled by interrupt handlers (not the interrupt entry
format as defined by Ada. This may be for historical reasons since we have
not recently timed the entry tied to a handler method.)
Jeff Creem
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: socket: synchronous, asynchronous, blocking and non-blocking
Date: 3 Dec 1996 12:09:30 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <5821dq$ek@elaine35.Stanford.EDU>
References: <s29eb2c4.092@SPAR.CA>
In article <s29eb2c4.092@SPAR.CA>, Yibing Fan  <yfan@spar.ca> wrote:
>Hi Everyone,
>
>I am confused by recent discussion of asynchronous socket.
>I've been using TCP and UDP socket in both blocking and non-blocking
>way, and never questioned myself about socket is synchronous or
>asynchronous. I had no doubt that these (synchronous and blocking) are
>two different sets of concept. I can rationalize myself  that the TCP
>socket is synchronous,  because message is guaranteed delivery, so
>some sort of acknowledgement has to be send back to sender. This
>must be done by layers lower than application. I would guess it is done
>by TCP/IP layer.
A very brief description of each.
TCP provides a reliable transport layer that guarantees reliable delivery of
data. It does this using ACKs, retransmission, and establishing a connection.
>For UDP socket I always think it is asynchronous. Am I  wrong?
>Someone please strait me out.
UDP is an unreliable datagram service. It is connectionless and does not
use ACKs or retransmissions, so it is unreliable, but has much less overhead.
The upper layer is responsible for providing reliability if it needs it. For example,
I believe RPC uses UDP.
Now the sync vs async issues I'm not sure about. At the application level it
can either synchronously block on a socket (TCP or UDP socket) or asynchronously poll it.
As far as sync vs async issues within TCP and UDP ... I don't know. I guess you could
say TCP is synchronous because it has a connection and timeouts on packets, while UDP
is connectionless and doesn't use timeouts.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: How to set the cursor on vt100-terminal.
Date: Sun, 01 Dec 1996 10:13:13 +0200
From: Rami Gideoni <rami_gideoni@aisys.co.il>
Organization: AISYS
Message-ID: <32A13E19.2388@aisys.co.il>
References: <329D5806.4E38@mee.hwm.com>
Uwe Scheffold wrote:
>
> Hi vxWorkers,
>
> it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do
this. Can anyone help?
>
> Regards: Uwe Scheffold[snip]
Dear sir,
To Clear screen, transmit the following sequence :
0x1B , 0x5B , 0x32 , 0x4A, 0x00
To move cursor home, transmit the following sequence :
0x1B , 0x5B , 0x48 , 0x00 , 0x00
To move cursor right, transmit the following sequence :
0x1B , 0x5B , 0x31 , 0x43 , 0x00
Please inform me with the results.
>
> -------------------------------------------------------------------------
> Uwe Scheffold     _/_/_/_/_/_/_/_/_/  _/_/_/_/   Mail: usd@mee.hwm.com
> Tele Robot Engineering _/    _/   _/ _/           Web: http://www.hwm.com
> Waelischmiller GmbH   _/    _/_/_/  _/_/_/      Voice: (+49) 7532 4320 41
> Klingleweg 8         _/    _/   _/ _/             Fax: (+49) 7532 4320 99
> D-88709 Meersburg   _/    _/    _/_/_/_/_/
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- --
Rami Gideoni
Development Projects Manager
AISYS Ltd.
E-mail : rami_gideoni@aisys.co.il
WWW : http//www.aisys-usa.com
- ---------------------------
Address :
16 Basel street,P.O.B 10041
Petach-Tikva 49001
ISRAEL
Phone : 1-800-397-7922, 972-3-9226860
Fax : 1-800-625-5525,972-3-9226863
- ----------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: GDB Monitor
Date: 3 Dec 1996 21:05:36 GMT
From: saqib@wam.umd.edu (Saqib)
Organization: University of Maryland, College Park, MD
Message-ID: <5824n0$ag0@dailyplanet.wam.umd.edu>
 Hi.
 I was wondering wheather or not anyone has gotten a copy of the VxWorks
 GDB monitor source from Wind River. If so how was this done? Was it
 tough to get from them? I am concerned with the HP - i960 version.
 We are interested in getting this. The reason we need it is that we use
 vxworks 5.0.6 with vxgdb. However, we are trying to implement some
 better debugging tools without going to a newer OS (To avoid testing all
 over again) and to do this, we would like to look at the GDB monitor
 sources so that we can figure out how to talk to it.
 Please reply by email.
 Thanks
 Saqib
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Slow target server connection
Date: Wed, 04 Dec 1996 04:45:53 GMT
From: brucew@phoenix.net (Bruce)
Organization: BranPaul Systems
Message-ID: <582vt6$2ek$1@gryphon.phoenix.net>
References: <5825qu$kcu@blackice.winternet.com>
In comp.os.vxworks
sparks@winternet.com (Hugh Sparks) wrote:
>We have a NT Workstation running Tornado 1.0 FCS. It is connected
>to a PowerPC (MVME1604) in a VME box with a dedicated Ethernet.
>
>We added an Ethernet board to the host just for this connection.
>The host also has a built-in Ethernet card connected to the corporate
>LAN.
>
>The problem is that the Target Server takes a very very long time
>to connect to the target system. Usually at least a minute.
>
>Has anyone else seen/resolved this problem?
We had this problem when we moved to a new location and
attached to their network.  If I'm not mistaken, we resolved
it by changing either the gateway or the subnet mask to
reflect our new system.
Bruce
---------------------------
Newsgroups: comp.os.vxworks
Subject: get system in msecond and usecond unit
Date: Sun, 01 Dec 1996 19:26:13 +0800
From: Cai Zhihong <eezhcai@ee.ust.hk>
Organization: HKUST, EEE Dept.
Message-ID: <32A16B55.41C67EA6@ee.ust.hk>
Hi, everyone:
	I want to get system in msecond and usecond unit on VxWorks, in fact I
am modifing a program which is using gettimeofday() but you know it can
not be used in VxWorks, could you give me some advises?
	Thanks,
- --
Cai, Zhihong
EEE Dept.
Hong Kong Univer. of Science & Technology
Kowloon, Clear Water Bay
Hong Kong
---------------------------
Newsgroups: comp.os.vxworks
Subject: loading new tasks in realtime
Date: 4 Dec 1996 10:39:51 GMT
From: "Robert Humphris" <rhumphris@csl.co.uk>
Organization: Concept Systems Ltd, Edinburgh, UK
Message-ID: <01bbe1cf$6d82f740$973482c2@irvine.csl.co.uk>
Dear All,
Having loaded a .o file into a segment of memory I wish to 'ld' it and
spawn the 'main' task,
while my system is running.  The method that was employed when using OS9
was to copy
the file via a socket from the SUN server to a block of memory. The memory
block was
then treated as a process, which was forked as an additional task.
To change from this method would be a large overhead, and thus something we
wish to
avoid.
Has anyone done this sort of thing before? Or have any of you got any clues
as  to how
I can load the symbols that are in the memory segment so that I can
taskSpawn(...)
the main function?
Cheers,
Rob Humphris. Concept Systems Ltd
rhumphri@csl.co.uk
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Slow target server connection
Date: Wed, 04 Dec 1996 11:48:23 +0100
From: "anders.wallin" <md13032@dredd.swipnet.se>
Organization: ABB Sweden
Message-ID: <32A556F7.1B65@dredd.swipnet.se>
References: <5825qu$kcu@blackice.winternet.com>
Hugh Sparks wrote:
>
> We have a NT Workstation running Tornado 1.0 FCS. It is connected
> to a PowerPC (MVME1604) in a VME box with a dedicated Ethernet.
>
> We added an Ethernet board to the host just for this connection.
> The host also has a built-in Ethernet card connected to the corporate
> LAN.
>
> The problem is that the Target Server takes a very very long time
> to connect to the target system. Usually at least a minute.
>
> Has anyone else seen/resolved this problem?
>
> Thanks,
> Hugh Sparks,  hugh.sparks@mts.com
If you are using the IP-no to get in contact with your target this will
happen. I don4t now why!
Try to use a name instead. Put the name and IP-no in your hosts-file.
Good luck
Anders Wallin
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: CD-ROM & ZIP drives under VxWorks
Date: 4 Dec 1996 06:32:39 GMT
From: klmvines@ix.netcom.com(Ken Vines)
Organization: Netcom
Message-ID: <5835u7$puf@sjx-ixn8.ix.netcom.com>
References: <01BBDE0C.4D88B7C0@sydney52.world.net>
In <01BBDE0C.4D88B7C0@sydney52.world.net> Steve Elliott
<selliott@mkc.com.au> writes:
>
>Does anyone know of implementations of CD-ROM and/or ZIP drive drivers
for VxWorks?
>
>Steve Elliott
>----------------------------------------------------
>Steve Elliott,       | Voice:  +61(2) 9638 4055    |
>MAYER KRIEG & CO     | Fax:    +61(2) 9638 6145    |
>U2, 8-10 Mary Parade | Mobile: +61(418) 236 820    |
>Rydalmere, NSW 2116  | Email:  selliott@mkc.com.au |
>Australia            |
>
I've tried to connect a Jaz drive and a CDROM drive to our PowerPC
based target running vxWorks (Tornado) without success. I asked Wind
River if they knew of anyone who had connected these SCSI devices and
they did not. They gave me a short list of SCSI devices that had been
interfaced to vxWorks systems. Unless the device adheres to certain
SCSI standards a device specific driver is needed, so I was told.
I dug through a lot of Tornado SCSI related documentation and hacked
around for a couple of days before I decided WRS implementation of SCSI
is not yet ready for prime time.
My solution was to go to a third-party (Radix) for SCSI/VME adapters
that provides drivers for vxWorks.
Ken
---------------------------
End of New-News digest
**********************
From leonid@rst.co.il  Wed Dec  4 06:48:05 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Wed Dec  4 06:48:12 PST 1996
Subject: Re: How to setup time() and TOD clock on mv162 board
> 1. How can I initialize the clock so that it shows the correct date?
>   Does clock_settime() write to the memory map for TOD clock
>   or do I have to do it myself?
Look in our Web site "Free Software" section - there is
a file that shows how to connect the VxWorks time to a TOD clock.
In that example the TOD chip is different from the one on mv162,
and I have the mv162 version too someplace, but I gather it will
be easy to change the stuff from the Web site for your needs.
Happy Hanuka Everyone !			http://www.rst.co.il/fun/hanuka.htm
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From cgrames@mdc.com  Wed Dec  4 09:21:46 1996
From: Charlie Grames <cgrames@mdc.com>
Date: Wed Dec  4 09:21:48 PST 1996
Subject:  Backplane Transfer Software
Yesterday, I posted a query for "more efficient" backplane transfer software for VxWorks.  Yes,
"more efficient" does mean "faster," but it also attempts to address problems with VxWorks basic
shared memory algorithms.
Primarily, I am looking for "efficiency" at a higher, board-independent level.  Using VxWorks
standard shared memory software presents a number of problems.  One such problem is that
with shared memory residing on the primary processor (processor 0), the secondary processors
(processors 1, 2, etc.) must do all the work of transfering data across the backplane, whether they
are sending the data or receiving it.  This makes it difficult to provide deterministic behavior for the
secondary processors, which may go off for extended periods of time to pull data across the
backplane, and also makes it possible for the receiver's IP stack to be overrun when the receiver
is a secondary processor (refer to Wind River SPR 7301).  Worse yet, when performing a transfer
between two secondary processors, the sender must first transfer data across the backplane to
the primary processor, and the receiver must then transfer the data from the primary processor to
itself.  Thus all data transfered between two secondary processors is actually transfered across
the backplane twice.
I am also looking for "efficiency" at the board level.  My current targets are the Motorola MVME1604
and MVME2604, which have different VME interface chips.  My hope was that any existing
higher-level software would provide hooks for tying in lower-level capabilities like BLT, MBLT, DMA,
etc.  Ideally, such hooks should be resolved in the BSPs, but that is not a reality for now.
As far as transfer requirements are concerned, I am looking for "as fast as possible."  I don't really
want to quote an MB/s requirement, because I don't want to narrow the field of possibilities just yet.
I can say that transfers need to be faster than those achieved with the VxWorks shared memory
software.  Certainly, I want at least D32 capability (data transfers using VxWorks shared memory
software are D16).
Charlie Grames
McDonnell Douglas Training & Support Systems
(314) 233-1956
CGrames@mdc.com
From claire@wrs.com  Wed Dec  4 10:33:37 1996
From: claire@wrs.com (Claire Chaplais)
Date: Wed Dec  4 10:33:39 PST 1996
Subject: Wind River Users Conference and Exhibition: it's time to register!
Join us at the Wind River Users Conference and Exhibition !
January 13 and 14, 1997
Techmart, Santa Clara, California
See details on the web for Agenda and registration!
http://www.wrs.com/wruscon.html
It is time to get together again for the Wind River Users Conference and
Exhibition.  We have changed the format of the Conference to make it even
more valuable to you. Check out the agenda on the Web
(http://www.wrs.com/wruscon.html) and see for yourself.
You'll also have the opportunity to see demonstrations of outstanding
products integrated with Tornado.
And to optimize your trip to California we scheduled the Users Conference
in conjunction with the Real Time Computer Show and Conference in Santa
Clara. (check their Web page at http://www.rtcgroup.com)
We look forward to seeing you there, to showing you what's new at Wind
River, and to hearing your comments and suggestions. So register now to
receive the discounted rate.
If you have any further questions please do not hesitate to contact Claire
Chaplais at 510-814-2177 or claire@wrs.com
Sincerely,
Claire Chaplais
Wind River Systems
From cruise@cfht.hawaii.edu  Wed Dec  4 13:13:51 1996
From: Bill Cruise <cruise@cfht.hawaii.edu>
Date: Wed Dec  4 13:13:58 PST 1996
Subject: Interrupt questions
I hope this doesn't fall too far below the technical level of the
list, but it just isn't explained in the WRS docs, and I am currently
at an impasse.
I am trying to hook up a simple interrupt device, a Data Translation
frame grabber.  It has a single interrupt, and a vector which must be
strapped on the card.  You can select the interrupt level, from 1-6.
Couldn't be much simpler.  The processor is a Sparc, which may
complicate things a bit.
In the Sparc vxWorks, and in the VME bus specs I have access to a wide
array of interrupt things, most of which I don't understand very well.
First there are the hardware VME interrupt levels, 1 - 7.  These have
been assigned definitions like this:
/* VMEbus interrupt vector definitions */
#define INT_VEC_VME_IRQ1  IV_AUTOVEC_2
...
The AUTOVEC's, in turn, are set up as traps in the Sparc interrupt
vector table.  These are defined like this:
* 17 - 31   Autovectors:  (aka "interrupt_level_xx" in the documentation) */
#define IV_AUTOVEC_2   INUM_TO_IVEC (TT_AUTOVEC_2)
and in turn:
#define TT_AUTOVEC_2  18
That last number, 18, is the actual trap location in the Sparc
interrupt table.  The memory address is 0x1000 + (trap << 4).
Then there are the user defined vectors, which are done as:
/* 128 - 255   User Defined Vectors (128)  */
#define IV_USER(n)   INUM_TO_IVEC (TT_USER(n))
For a given user number, 0 - 127, it adds 128 (which gets the trap
number), and gives you the trap's vector address in the table.  I
would think having user vectors from 128 - 255 would be more logical,
but...
Anyway, here's what I have done.
1.  I left the board at its default interrupt level of 6, and used
    INT_VEC_VME_IRQ_6 in my intConnect.  I left the board's vector
    register set to the factory default of 0xf0.  Basically this was
    an exercise in crash and burn.  When I have a lot of error
    messages turned on I get a first interrupt that looks OK, then
    Exceptions on several more, then the processor hangs and sometimes
    reboots.  I couldn't read the system message as it was scrambled
    with my stuff, which also scrambles interrupt level (logMsg) and
    normal messages.
    If I turn off the outside messages, the system crashes and locks
    (hard reset) before it even prints all the messages in the first
    interrupt.
2.  I then used INUM_TO_IVEC (0xf0) in the intConnect call.  Still
    using level 6, and vector register set to 0xf0. According to my
    explorations this puts an interrupt vector table entry in the
    right place; trap 240, and memory 0x1f00.  After an initial
    error message about an uninitialized interrupt,
    Uninitialized Interrupt!
    Vector number 27 (0-255), Interrupt level 11
    ...
    the system seems to handle interrupts just fine.  It turns out VME
    IRQ6 is on Autovector 11 and trap 27.  This means something is
    coming in on the vector for IRQ6, and there is nothing there to
    catch it.  I didn't see any calls appropriate to initializing
    interrupts.
OK, here is the question part.
1.  What am I supposed to specify as the vector in the intConnect
    call?  Is it the VME IRQ vector's trap, or a user defined one that
    is in the board's vector register?
2.  What am I supposed to do about the VME IRQ level if I specify a
    user defined vector, such as 0xf0?  Right now all I do is a
    sysIntEnable(6) call right after I do the intConnect call.
3.  Am I supposed to use the INT_VEC_VME_IRQ_n vector for any devices
    on a particular VME IRQ, and set them all to have the vector
    required for this IRQ?  This implies that there can only be one
    ISR for each VME level, or 7 total.  This is, in fact, what I did
    for my first, successful, interrupt project.
4.  If I have more than 7 boards, or multiple interrupts on boards,
    then I must use some other means to determine which board is
    interrupting.  However, since all vectors are the same, and since
    the parameter in the intConnect couldn't be used, I think you
    would start having to do hardware polling just to see which board
    is interrupting.  Is this what you do for more than 7 interrupts?
5.  The only system calls I am using are intConnect, sysIntEnable, and
    sysBusIntAck.  Is there something else I should be doing?
6.  Are there any secrets I am missing?  Why does this have to be so
    obtuse (as with many other things WRS)?  Wouldn't some samples be
    useful?
Thanks for any help you can offer or point me to.
--
William L. Cruise                             cruise@cfht.hawaii.edu
Electronics System Supervisor                   FAX:    808 885-7288
Canada-France-Hawaii Telescope                  Voice:  808 885-3122
P.O. Box 1597                     http://www.cfht.hawaii.edu/~cruise
Kamuela, HI   96743
From mikemcquade@connect.com  Wed Dec  4 18:25:29 1996
From: mikemcquade@connect.com
Date: Wed Dec  4 18:25:30 PST 1996
Subject: PowerPC MVME-1604 Panics, lockups.
Ive seen my 604 (133) board generate panic: mfree, panic: mget messages,
has anyone else seen these messages ?
or has anyone experienced the 1604 boards locking up ?
I can compile my application for a 603, and run it for hours on a 603
target, with no problems, but the 604's will lock up after 5 - 20
minutes of operation (sometimes generating panics, sometimes just
locking up). I have good air flow to the CPU, its not getting hot, Ive
tried three different 604 boards, and they all behave the same.
It seems like its tied to interrupt frequency, as the higher the
frequency of VME interrupts, the shorter the 604 boards will run.
I know of at least one other person that has seen the panics on a 604, I
just want to get a feel if this is a "real" problem.
Im using FCS Tornado.
Thanks.
From daemon@csg.lbl.gov  Thu Dec  5 04:00:15 1996
From: daemon@csg.lbl.gov
Date: Thu Dec  5 04:00:17 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec  5 04:00:13 PST 1996
        Subject: Re: How to setup time() and TOD clock on mv162 board
        Subject: Re:loading new tasks in realtime
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: How to setup time() and TOD clock on mv162 board
Date: 4 Dec 1996 09:14:38 GMT
From: "Adam Baker" <adam_baker@roke.co.uk>
Organization: Roke Manor Research
Message-ID: <01bbe1c3$bd4e7ad0$e2c076c1@aabpc>
References: <58082s$3nj@elaine35.Stanford.EDU>
Earl Mitchell <kla@leland.Stanford.EDU> wrote in article
<58082s$3nj@elaine35.Stanford.EDU>...
> 1. How can I initialize the clock so that it shows the correct date?
>    Does clock_settime() write to the memory map for TOD clock
>    or do I have to do it myself?
No,  you have to do it yourself.
>
> 2. When I repeated the test above (from powerup) I waited a long time to
first invoke
>    "currentTimeString" after loading test.o, and it still returned this?
>
> *** THU JAN 01 00:00:00 1970
>  ***
>
>    Is the time() function in VxWorks actually using the Time of Day (TOD)
>    clock on the mv162 board at all? Do I have to configure this somehow.
>
No. You need to do all the work yourself. Get the data sheet for the clock
chip, read the time from it
(remember to stop the registers updating first) and then call clock_settime
with the result. At least
thats what I had to do.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re:loading new tasks in realtime
Date: Wed, 04 Dec 1996 14:05:52 +0100
From: Herbert F|reder <herbert.fuereder@sea.ericsson.se>
Organization: Ericsson Austria AG
Message-ID: <32A57730.777F@sea.ericsson.se>
Robert Humphris wrote:
>
> Dear All,
>
> Having loaded a .o file into a segment of memory I wish to 'ld' it and
> spawn the 'main' task,
> while my system is running.  The method that was employed when using OS9
> was to copy
> the file via a socket from the SUN server to a block of memory. The memory
> block was
> then treated as a process, which was forked as an additional task.
> To change from this method would be a large overhead, and thus something we
> wish to
> avoid.
> Has anyone done this sort of thing before? Or have any of you got any clues
> as  to how
> I can load the symbols that are in the memory segment so that I can
> taskSpawn(...)
> the main function?
>
> Cheers,
>
> Rob Humphris. Concept Systems Ltd
> rhumphri@csl.co.uk
Hallo Robert
I do not know your environment looks like but for testing purposes we
tried something similar.
We use C++ as a programming language, and we declare a GLOBAL Object and
in the constructor of this object we do a  taskspawn(..). After
compiling your sources you have to call a host tool called munch and
this tool implements code that calls constructors of static objects
automatically after downloading.
Now you just have to load this *.o file into your target and the loader
will link it with the rest of the applications (of course you have to
have a loader running on the target which holds the symbol table, which
is available from WRS) and will also call the constructor of your global
object which will spawn your new tasks.
Hope this is some help
herbert
Herbert Fuereder
email: herbert.fuereder@sea.ericsson.se
---------------------------
End of New-News digest
**********************
From geng@desy.de  Thu Dec  5 07:39:03 1996
From: geng@heras1.desy.de (Xiaosong GENG)
Date: Thu Dec  5 07:39:14 PST 1996
Subject: Re: comp.os.vxworks newsdigest
unsubscribe.
From 75104.3460@CompuServe.COM  Thu Dec  5 14:23:53 1996
From: David Parkerson <75104.3460@CompuServe.COM>
Date: Thu Dec  5 14:23:55 PST 1996
Subject: unsubscribe
Please unsubscribe.
From tmorris@me.umn.edu  Thu Dec  5 16:55:36 1996
From: "Ted Morris" <tmorris@me.umn.edu>
Date: Thu Dec  5 16:55:38 PST 1996
Subject: Good Text Book
I asked this group a couple of weeks ago about a good book for
Undergrad (3rd - 4th year) Students to learn basic principles of
real-time OSes and real-time programming. This one looks like the best
so far:
Phillip A. Laplante, "Real-Time Systems Design And Analysis: An
Engineer's handbook", IEEE PRESS, ISBN 0-7803-1152-3
Ted
Ted Morris              "WWW = World-Wide-Wait"
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology, U of Minnesota                   FAX: 612-625-8884
From kbaumann@sky.itr.ch  Thu Dec  5 23:37:16 1996
From: Kurt Baumann <kbaumann@itr.ch>
Date: Thu Dec  5 23:37:19 PST 1996
Subject: unsubscribe
unsubscribe
From pfischer@force.de  Fri Dec  6 02:44:55 1996
From: pfischer@force.de (Paul Fischer)
Date: Fri Dec  6 02:44:57 PST 1996
Subject: Re: Backplane Transfer Software
The VSO (VITA Standards Organization) is standardizing a networking
interface for the VMEbus called BusNet.  This is not an API but a
standard set of data structures and procedures for transferring IP
packets between VMEbus masters.
You can find out more by going to the Technology section of the
FORCE web page at:  http://www.forcecomputers.com/
I am the chair of that committee.  We expect to have a final draft
in January.  The information you will find on the web page is
representative of the initial version of BusNet.  If the web page
does not answer all your questions please contact me (e-mail works
best).
By the way, BusNet is designed to allow you to transfer packets
using BLT and DMA.  The performance figures have been calculated
using ftp, which is not a very good measuring tool.  I hope that in
the spring we'll have a better throughput indicator.
Paul Fischer
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Paul Fischer                       voice:  +49/89/608-14-334
  FORCE COMPUTERS GmbH                 fax:  +49/89/608-14-276
  Prof.-Messerschmitt-Str. 1        e-mail:  pfischer@force.de
  D-85579 Neubiberg/Munich, Germany
                 http://www.forcecomputers.com/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From daemon@csg.lbl.gov  Fri Dec  6 04:00:25 1996
From: daemon@csg.lbl.gov
Date: Fri Dec  6 04:00:28 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec  6 04:00:23 PST 1996
        Subject: Re: Asynchronous sockets
        Subject: IP multicast
        Subject: Re: Two systems, One IP
        Subject: Re: LonTalk
        Subject: Re: get system in msecond and usecond unit
        Subject: Using ULIP to Talk between two VxSim
        Subject: Domain Name services
        Subject: Re: Using ULIP to Talk between two VxSim
        Subject: Re: Memory tests
        Subject: Re: Domain Name services
        Subject: Re: CD-ROM & ZIP drives under VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Mon, 02 Dec 1996 17:08:52 -0800
From: Dave Zaleta <zaleta@reticular.com>
Organization: Reticular Systems, Inc.
Message-ID: <32A37DA4.2781E494@reticular.com>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> <01bbe083$f8f0f860$6c63d4c1@nenu02h1.nopow.abb.no> <57t2nq$gp2@idiom.com>
H.J. Bae wrote:
>
> This thread has generated incredible amount of misinformation, but
> this one has to top them all.  Amazing.  This is so utterly wrong,
> I probably should just ignore it, but I'd hate to see someone believe
> what this guy wrote because he sounds so convinced.
>
> "Trust no one".  "The truth is out there".
>
Rather than stating that the previous explanation was "utterly wrong" it
might be more helpful if you explained the difference between asynch.
and synch. sockets or at least point to a reference that might better
explain the difference.
dave z
---------------------------
Newsgroups: comp.os.vxworks
Subject: IP multicast
Date: Thu, 05 Dec 1996 07:20:07 -0800
From: Gary Steven Fish <gsfish@ccgate.hac.com>
Organization: Hughes Aircraft Co. WSS/NAMS
Message-ID: <32A6E827.632B@ccgate.hac.com>
Reply-To: gsfish@ccgate.hac.com
Does anyone know when Wind Rivers will have IP multicast in their
VxWorks product?  If available, O.S. version and date of beta testing
and official release.
Gary S. Fish
Hughes Aircraft Co.
Fullerton, Ca.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Two systems, One IP
Date: Thu, 05 Dec 96 09:39:30 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Oracle
Message-ID: <58655o$kqf@idiom.com>
References: <5850q8$r9d@nrchh52.rich.nt.com> <5864fc$kqf@idiom.com>
In article <5864fc$kqf@idiom.com>, hjb@pso.com (H.J. Bae) wrote:
>
>This may require a custom device driver.
>[etc.]
I read the original posting again and it seems I misunderstood the
problem.  You are talking about two seperate machines here right?
I missed that.  Sorry.
In the case of two seperate machines, it's OK to turn ARP off (you
can do this dynamically using IFF_NOARP flag on the network interface)
on one of the machines when both are alive.  This makes one of
the machines respond to ARP, and everything is OK.
The trick is finding out if one of the machines is dead and turn
on ARP on the other machine that is still alive (which had the
ARP turned off before).  If you have more than one network
interface on both machines, it's easy (just use ping to check
each other over the second interfaces).  If you don't, you'll
have to come up with a custom protocol -- perhaps at ethernet level,
using an unused ethernet type (bad but it works).
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: LonTalk
Date: Sun, 01 Dec 96 22:58:47 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57t2h0$gp2@idiom.com>
References: <01BBDED6.8A859B00@sydney70.world.net>
In article <01BBDED6.8A859B00@sydney70.world.net>, Steve Elliott <selliott@mkc.com.au> wrote:
>Does anyone know of VxWorks 5.3 driver implementations for LonTalk?
>
Echelon LonWorks stuff can be easily to VxWorks but you will
need to first buy their developer kit.  Engenuity sells VME
boards with neuron chips complete with a working driver, on
top of which you will need to implement the LonTalk protocol
stuff which you get from Echelon.  The protocol implementation
was not very portable last time I've seen (they use bit fields
extensively and assume particular byte ordering in bit field
definitions), but not hard to port once you convert all the
byte ordering (I assume you are using on big-endian machine?).
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: get system in msecond and usecond unit
Date: Sun, 01 Dec 96 22:59:31 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57t2ic$gp2@idiom.com>
References: <32A16B55.41C67EA6@ee.ust.hk>
In article <32A16B55.41C67EA6@ee.ust.hk>, Cai Zhihong <eezhcai@ee.ust.hk> wrote:
>Hi, everyone:
>        I want to get system in msecond and usecond unit on VxWorks, in fact I
>am modifing a program which is using gettimeofday() but you know it can
>not be used in VxWorks, could you give me some advises?
>        Thanks,
take a look at tickLib
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Using ULIP to Talk between two VxSim
Date: Thu, 05 Dec 1996 16:05:39 -0500
From: martin_dubuc@qmail.ca.newbridge.com (Martin Dubuc)
Organization: West End Systems Corp.
Message-ID: <martin_dubuc-0512961605390001@wemac098.westend.ca>
I am trying to use ULIP to talk between two VxSim processes. I saw the
ReadUlip and WriteUlip functions in one include files. However, I do not
know how to initialize the file descriptor that are used in those
functions. Would somebody have example code of how to do that?
Regards,
Martin
---------------------------
Newsgroups: comp.os.vxworks
Subject: Domain Name services
Date: Thu, 05 Dec 1996 17:22:57 -0800
From: "David P. Davis" <ddavis@xtech.com>
Organization: Extended Technologies
Message-ID: <32A77571.BA2@xtech.com>
- --
Does VxWorks include DNS services?  I cant find any mention in the 5.3 reference manual.
Or do I have to go to a third party for this?  I just want to be able to specify the address of
a DNS server and then be able to do name lookups from VxWorks.  Anyone have any experience with
this?
Thanks.
- ---------------------
David Davis
Extended Technologies
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Using ULIP to Talk between two VxSim
Date: Fri, 06 Dec 96 06:52:53 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <588fs5$1j8_006@hjbpc.idiom.com>
References: <martin_dubuc-0512961605390001@wemac098.westend.ca>
In article <martin_dubuc-0512961605390001@wemac098.westend.ca>, martin_dubuc@qmail.ca.newbridge.com (Martin Dubuc) wrote:
>I am trying to use ULIP to talk between two VxSim processes.
Sorry if this is a dumb question.  But why not just use sockets
to talk over TCP/IP over ULIP?
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Memory tests
Date: Fri, 06 Dec 96 06:36:43 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Oracle
Keywords: memory test power boot
Message-ID: <588etr$1j8_004@hjbpc.idiom.com>
References: <587jth$rar@alcor.usc.edu>
In article <587jth$rar@alcor.usc.edu>, helding@alcor.usc.edu (helding) wrote:
>When a PC is powered on it usually goes through a memory check before the DOS
>prompt even shows up.  In my experience with vxWorks this is never done as part
>of the boot-up sequence.
Yes.  However, you can write your own low level routine to do this.
The safest way I've found is by writing assembly code to be put in
as part of romInit.s.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Domain Name services
Date: Fri, 06 Dec 96 06:33:49 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Oracle
Message-ID: <588eod$1j8_002@hjbpc.idiom.com>
References: <32A77571.BA2@xtech.com>
To do this you will need to port the resolver library to vxWorks.
There is no support in VxWorks for DNS.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: CD-ROM & ZIP drives under VxWorks
Date: Fri, 06 Dec 96 09:22:57 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <588olh$no_004@hjbpc.idiom.com>
References: <01BBDE0C.4D88B7C0@sydney52.world.net> <5835u7$puf@sjx-ixn8.ix.netcom.com>
In article <5835u7$puf@sjx-ixn8.ix.netcom.com>, klmvines@ix.netcom.com(Ken Vines) wrote:
>
>I've tried to connect a Jaz drive and a CDROM drive to our PowerPC
>based target running vxWorks (Tornado) without success. I asked Wind
>River if they knew of anyone who had connected these SCSI devices and
>they did not. They gave me a short list of SCSI devices that had been
>interfaced to vxWorks systems. Unless the device adheres to certain
>SCSI standards a device specific driver is needed, so I was told.
>I dug through a lot of Tornado SCSI related documentation and hacked
>around for a couple of days before I decided WRS implementation of SCSI
>is not yet ready for prime time.
>
>My solution was to go to a third-party (Radix) for SCSI/VME adapters
>that provides drivers for vxWorks.
In all fairness, this is not quite true.  VxWorks does have decent
enough SCSI subsystem to work with a SCSI ZIP drive.  The speed
of SCSI code is not that great, but it certainly works with ZIP drive
I have here.  To verify this, I've just created a DOS filesystem
on it using VxWorks SCSI driver.  It works great.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
End of New-News digest
**********************
From leonid@rst.co.il  Fri Dec  6 04:51:20 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Fri Dec  6 04:51:23 PST 1996
Subject: Re: Re: Backplane Transfer Software
> From: pfischer@force.de (Paul Fischer)
> Date: Fri Dec  6 02:44:57 PST 1996
> ...
> I am the chair of that committee.
> ...
I would like to applaud this effort. I think it was long due that a standard
for message-passing and netowkring over VME existed.
I am somewhat worried though, that the chairman is a Force Computers
executive, while Force has initially intoduced the BusNet protocol.
Are there any guarantees that other board vendors VME boards,
including the ones that already exist out there, will be able
to co-exist on the BusNet network ?
Who are the companies who participate in this cometee, and
have any of them try to actually implement the existing BusNet
protocol on teir boards ?
WInd River's solutions,, both BP and the newer SM protocols
have works on a wide variety of board this far, and we would not
want the new standard to fall short on this.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From AS_Bridge@MSMAIL3.HAC.COM  Fri Dec  6 05:07:34 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Dec  6 05:07:36 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Re: Backplane Transfer Software
Sent: Fri, Dec 6, 1996 4:05 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Dec 6, 1996 5:06 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From uucp@relay1.fnet.fr  Fri Dec  6 05:45:02 1996
From: leverone@zeus.egt.fr (Philippe Leverone)
Date: Fri Dec  6 05:45:04 PST 1996
Subject: subscribe
From pfischer@force.de  Fri Dec  6 05:51:59 1996
From: pfischer@force.de (Paul Fischer)
Date: Fri Dec  6 05:52:01 PST 1996
Subject: Re: Backplane Transfer Software
Hello Leonid,
I wish I could call myself a "FORCE Computers executive."  However,
I'm just a Technical Marketing Engineer ... just another "schmoe"!
Currently implementations exist from FORCE and a German middleware
company called SYSGO.  The SYSGO implementation is independent, based
on the specification.  SYSGO has enhanced their version and we are
putting most of those enhancements into the spec.  FORCE's versions
will eventually track the enhancements in order to guarantee
interoperability.  Today they do not interoperate.
Radstone is also working on an implementation.  Several customers
(or consultants to those customers) are working on implementations
on non-FORCE hardware (SYSGO also supports non-FORCE hardware).  I
cannot, at this time, give the names of those customers.
We hope that during 1997 we can demonstrate interoperability between
implementations from a variety of vendors on a variety of hardware.
The specification accounts for a variety of vendors, not just FORCE.
It was very important to include other vendors, an existing hardware.
We do not depend on VME64 features (we don't even recognize it!) nor
do we depend on any special hardware features.  Interrupts and RMW
are not required.
More information is available in the Technology section of our web
page at http://www.forcecomputers.com/ .
Biggest problem is getting the OS vendors to support the standard,
since they all have a proprietary solution.  We believe that once the
standard and several implementations exist we will have a better
chance getting them to signup.  Until then it will be up to the h/w
vendors to "get the ball rolling."
Paul
At 02:38 pm 12/06/96 IST, Leonid Rosenboim wrote:
>> From: pfischer@force.de (Paul Fischer)
>> Date: Fri Dec  6 02:44:57 PST 1996
>> ...
>> I am the chair of that committee.
>> ...
>
>I would like to applaud this effort. I think it was long due that a standard
>for message-passing and netowkring over VME existed.
>
>I am somewhat worried though, that the chairman is a Force Computers
>executive, while Force has initially intoduced the BusNet protocol.
>
>Are there any guarantees that other board vendors VME boards,
>including the ones that already exist out there, will be able
>to co-exist on the BusNet network ?
>
>Who are the companies who participate in this cometee, and
>have any of them try to actually implement the existing BusNet
>protocol on teir boards ?
>
>WInd River's solutions,, both BP and the newer SM protocols
>have works on a wide variety of board this far, and we would not
>want the new standard to fall short on this.
>-----------------------------------------------------------------------
>Leonid Rosenboim                        Phone:  +972-3-559-8144
>R S T  Software Industries Ltd.         Mobile: +972-50-307-142
>P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
>WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
>
From AS_Bridge@MSMAIL3.HAC.COM  Fri Dec  6 06:46:41 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Dec  6 06:46:43 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: comp.os.vxworks newsdigest
Sent: Fri, Dec 6, 1996 5:37 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Dec 6, 1996 6:44 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From AS_Bridge@MSMAIL3.HAC.COM  Fri Dec  6 07:21:43 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Dec  6 07:21:45 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Re: Re: Backplane Transfer Software
Sent: Fri, Dec 6, 1996 6:19 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Dec 6, 1996 7:20 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From AS_Bridge@MSMAIL3.HAC.COM  Fri Dec  6 07:59:04 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Dec  6 07:59:10 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Undeliverable Mail
Sent: Fri, Dec 6, 1996 6:47 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Dec 6, 1996 7:56 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From daemon@csg.lbl.gov  Sat Dec  7 04:00:23 1996
From: daemon@csg.lbl.gov
Date: Sat Dec  7 04:00:27 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec  7 04:00:21 PST 1996
        Subject: Can't I use basic commands?
        Subject: [Q] Why is low 1 MB noncacheable on mv1604?
        Subject: Shared Memory Network Woes
        Subject: Re: Can't I use basic commands?
        Subject: Re: Shared Memory Network Woes
        Subject: Re: Asynchronous sockets
        Subject: Floppy driver for ULTRA Power PC 603e
        Subject: Re: Asynchronous sockets
        Subject: Re: Code Coverage tools
        Subject: Re: Using ULIP to Talk between two VxSim
        Subject: Re: Slow target server connection
        Subject: VxWorks Drivers for ATM Cards ?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Can't I use basic commands?
Date: 6 Dec 1996 02:16:55 GMT
From: isogai@relax.mecsys.ryukoku.ac.jp (Kentaro Isogai)
Organization: Ryukoku Univ.
Message-ID: <587vmn$5rj@rins.st.ryukoku.ac.jp>
Hi, everyone!
I am a beginner on the field of VxWorks.
I've already installed VxWorks 5.2, and it works well, I think.
Host is Soralis 2.5, target is Intel i486.
Everybody knows the command "loginUserShow", but I tried that,
I got an error message:
	-> loginUserShow
	undefined symbol: loginUserShow
	->
And I got a same error when I tried  "proxyPortShow" command.
Those commands are in an Introduction guide, without special explanations.
In the guide, those work well.
	->loginUserShow
	  User Name
	  =========
	  vxtarget
	value = 0 = 0x0
	->loginUserAdd "vxtarget2", "RedyyQzQzQ"
	value = 0 = 0x0
	->loginUserShow
	  User Name
	  =========
	  vxtarget2
	  vxtarget
	value = 0 = 0x0
	->
Why I can't use those commands?
I don't know whether there are some more commands I can't use.
Or, did I need special processes when I installed?
Could you give me some advises?
Kentaro Isogai
MSE Dept.
Ryukoku Univ.
Otsu,Shiga,
Japan
---------------------------
Newsgroups: comp.os.vxworks
Subject: [Q] Why is low 1 MB noncacheable on mv1604?
Date: Fri, 6 Dec 1996 13:09:40 GMT
From: Bob Marino <ram@mr.picker.com>
Organization: Picker International, Inc.
Message-ID: <32A81B14.41C6@mr.picker.com>
Sender: news@picker.com
Does anyone know why the low 1 MB is declared as cache inhibited in
the BSP for the mv1604?  For what is the low 1 MB used?
- --
Roberto "Bob" Marino                          Picker International, Inc.
principal engineer                            5500 Avion Park Dr.
NMR division                                  Highland Hts, OH 44143
---------------------------
Newsgroups: comp.os.vxworks
Subject: Shared Memory Network Woes
Date: Fri, 06 Dec 1996 13:00:16 +0100
From: Maureen Jett <mjett@gwdg.de>
Organization: MPI fuer biophysikalische Chemie
Message-ID: <32A80AD0.345@gwdg.de>
Reply-To: mjett@gwdg.de
Hello,
We are having lots of problems getting our shared memory network
running.  Specifically, the MV 147 on the VME bus has access to the
external memory at address 0x40100000 before booting, but after the
vxWorks kernel is loaded, we get a bus error when we try to look at the
external memory at the same address.  In fact, after booting there is no
access at all to the VME bus.  I apologize if my hardware description
isn't good, as I'm really a software person.  The only configuration
changes I made were in config.h as shown below:
#define SM_OFF_BOARD	TRUE
#define SM_ANCHOR_ADRS	((char *) (0x40100000)
Do I need to make other changes?
TIA,
Maureen
- --
Maureen M. Jett
Max Planck Institute for Biophysical Chemistry
ZEWEG-EDV Group, 051
tel:   49-551-201-1414       FAX: 49-551-201-1011
email: mjett@gwdg.de
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Can't I use basic commands?
Date: Fri, 06 Dec 96 09:19:27 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <588oev$no_002@hjbpc.idiom.com>
References: <587vmn$5rj@rins.st.ryukoku.ac.jp>
In article <587vmn$5rj@rins.st.ryukoku.ac.jp>, isogai@relax.mecsys.ryukoku.ac.jp (Kentaro Isogai) wrote:
>Hi, everyone!
>
>I am a beginner on the field of VxWorks.
>I've already installed VxWorks 5.2, and it works well, I think.
>Host is Soralis 2.5, target is Intel i486.
>
>Everybody knows the command "loginUserShow", but I tried that,
>I got an error message:
>
>        -> loginUserShow
>        undefined symbol: loginUserShow
Maybe this is too obvious... but are you defining INCLUDE_SECURITY?
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Shared Memory Network Woes
Date: Fri, 06 Dec 1996 12:15:37 -0500
From: Fred Roeber <froeber@bbn.com>
Organization: BBN Systems and Technologies
Message-ID: <32A854B9.167EB0E7@bbn.com>
References: <32A80AD0.345@gwdg.de>
Maureen Jett wrote:
> We are having lots of problems getting our shared memory network
> running.  Specifically, the MV 147 on the VME bus has access to the
> external memory at address 0x40100000 before booting, but after the
> vxWorks kernel is loaded, we get a bus error when we try to look at the
> external memory at the same address.  In fact, after booting there is no
> access at all to the VME bus.  I apologize if my hardware description
> isn't good, as I'm really a software person.  The only configuration
> changes I made were in config.h as shown below:
>
> #define SM_OFF_BOARD    TRUE
>
> #define SM_ANCHOR_ADRS  ((char *) (0x40100000)
>
> Do I need to make other changes?
If you can't get at external memory after booting VxWorks it is likely
due to a memory protection problem.  In the config/sysLib.c file
you need to make changes to the sysPhysMemDesc file used to initialize
the MMU so that the external memory is accessible.  If you don't do
this the memory protection problems will show up as bus errors.  Fred
- --
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Tue, 03 Dec 96 04:59:18 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <580c12$naq@idiom.com>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> <01bbe083$f8f0f860$6c63d4c1@nenu02h1.nopow.abb.no> <57t2nq$gp2@idiom.com> <32A37DA4.2781E494@reticular.com>
In article <32A37DA4.2781E494@reticular.com>, Dave Zaleta
<zaleta@reticular.com> wrote:
>Rather than stating that the previous explanation was "utterly wrong" it
>might be more helpful if you explained the difference between asynch.
>and synch. sockets or at least point to a reference that might better
>explain the difference.
>
>dave z
I did explain the differences, twice, already.  Perhaps you missed them?
Anyway, to satify your request, the non-blocking and asynch I/O
as they appear at API level has nothing to do with whether you
are doing send or receive, nor does it have anything to do with
the way TCP or UDP packets are sent.  It has to do with API interface.
The non-blocking socket interface provides an interface to programmers
that are non-blocking -- i.e. when you do I/O operations (send/recv)
the calls do not block.  One of the previous posters apparently
thinks that because send() returns immediately after copying the
data into socket level buffer queue most of the time, the send is
asynch.  This is not true.  The send() can also block, if the socket
is not marked non-blocking, when the socket level buffer runs out.
It will block waiting for more buffer space.  Not only that, the
asynch API interface to socket is independent of the seemingly
asynch behavior of the protocol implementation in the kernel.
Anyway, the asynch I/O on the socket, however, is quite different
in terms of API.  It uses SIGIO to tell the application when
further recv() or send() can be done.  When the protocol in the
kernel receives more data and queues it up to the socket level
buffer, it will send SIGIO to the user.  Similarly, when the
protocol has drained the socket level write buffer sufficiently,
making more room to accept more data from the user, it will send
SIGIO to the user.
None of this secret.  The source code for BSD networking code is
available everywhere on Internet.  The best thing to do is to
read the code yourself.  My recommendation for your reference has
always been available.  Just search for BSD Unix source code
on your web browser.  There is your best reference.
That's enough on this issue.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Floppy driver for ULTRA Power PC 603e
Date: Fri, 06 Dec 1996 13:09:14 -0500
From: David Pyle <dpyle@teklogix.com>
Organization: Teklogix Inc.
Message-ID: <32A8614A.3E5F@teklogix.com>
Does anyone know where I can get a floppy driver for the Power PC ULTRA
603e? It is not part of the BSP.
Dave
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Fri, 06 Dec 96 19:04:47 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <589qof$11s_002@hjbpc.idiom.com>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> <01bbe083$f8f0f860$6c63d4c1@nenu02h1.nopow.abb.no>
I'm told that I was rude in remarking the following article
as "utterly wrong".  I apologize for being rude.  However, I
feel that I need to explain why I said something so rude (it
might be because I'm crazy rude person, which could be true.
but there is a reason for my irrational actions at times.)
I will comment each point.
In article <01bbe083$f8f0f860$6c63d4c1@nenu02h1.nopow.abb.no>, "Arve Sollie"
<asollie@online.no> wrote:
>Async vs Sync sockets.
>A send() calls to a sync socket ( TCP ) will force an IP datagram to be
>generated, event if the window is not full.
This is wrong.  A send() to a TCP socket will NOT force an IP datagram
to be generated.  It may cause a TCP segment to be injected into the
stream, it may not.
> On async() sockets, flushing
>will
>be done by the net-task when a flush-timer has expired.
There is no "flush" timer anywhere in the network code.
Any "flushing" of data that may happen in the network kernel code
has to do with closing the socket, not timer based.
netTask is nothing but a netJob handler which provides context
for executing events.  It has no logic to "flush" any sockets.
>Sync sockets giv much less latency when sending small amounts of data (
>telnet, poll operations ),
>but the cost is a lot of small IP datagrams.
The behavior of any TCP network traffic depends greatly on the
underlying data stream (bandwidth, congestion, link-level latency, etc.)
as well as TCP implementations (how good they are, how well they
cooperate, etc.)
Any decent TCP implementation will *not* generate lots and lots of small
segments even for telnet traffic (i.e. you won't see a segment for
each keyboard input, unless you are typing really slow or you have high
bandwidth, low congestion pipe stream).  Nagel's algorithm (and newer VJ's
algorithm) specifically takes care of that.   If you turn TCP_NODELAY
option on, to defeat the Nagel's algorithm, you may experience more segments
on the stream.
>UDP datagrams are atomic TPDUs, and no differentiation make sense.
>( Except for handling in user context, and not in nettask context )
Both UDP and TCP are handled exactly same way in terms of user/nettask
context issues.
Now, as you can see, every single sentence in the original article is
curiously misleading, if not very wrong.  Since I'm an extremely
anal retentive person when it comes to "accuracy in posting" (TM),
I couldn't help it.
Sorry for all the noise.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Code Coverage tools
Date: Tue, 03 Dec 1996 23:14:31 GMT
From: johnd@reflex-tech.co.uk (John Dalton)
Organization: Reflex Technology
Message-ID: <582cb9$c6h@stilton.rednet.co.uk>
References: <01BBDED6.91C9A6E0@sydney70.world.net>
Reply-To: johnd@reflex-tech.co.uk
Steve Elliott <selliott@mkc.com.au> wrote:
>Does anyone know of any code coverage tools which have been implemented for VxWorks applications?
Verilog's Logiscope : www.verilogusa.com
John
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Using ULIP to Talk between two VxSim
Date: 6 Dec 1996 16:22:36 GMT
From: mda@bnr.ca (Mark Dapoz)
Organization: Bell-Northern Research Ltd.
Message-ID: <589h8c$7gt@bcarh8ab.bnr.ca>
References: <martin_dubuc-0512961605390001@wemac098.westend.ca> <588fs5$1j8_006@hjbpc.idiom.com>
In article <588fs5$1j8_006@hjbpc.idiom.com>, H.J. Bae <hjb@pso.com> wrote:
>In article <martin_dubuc-0512961605390001@wemac098.westend.ca>, martin_dubuc@qmail.ca.newbridge.com (Martin Dubuc) wrote:
>>I am trying to use ULIP to talk between two VxSim processes.
>
>Sorry if this is a dumb question.  But why not just use sockets
>to talk over TCP/IP over ULIP?
Better yet, set up a shared memory network using the SM_NET defines in
your config file.  In vxSim this will use a UNIX shared memory segment
to create a virtual network.  Depending on how much data you are trying to
pass between your vxSim's, you may see an order of magnatude speed
improvement over ulip.
				-mark
- --
Mark Dapoz	Bell-Northern Research, Ottawa, Canada	    Mark.Dapoz@bnr.ca
Fingers and toes, fingers and toes, forty things we share, forty one if you
include the fact that we don't care.  - The Tragically Hip
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Slow target server connection
Date: Wed, 04 Dec 1996 23:44:01 +0000
From: John Gordon <j.gordon@dial.pipex.com>
Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX)
Message-ID: <32A60CC1.1FB6@dial.pipex.com>
References: <5825qu$kcu@blackice.winternet.com> <32a6a0b6.513895021@news.seinf.abb.se>
Henry Gessau wrote:
>
> We connected our targets directly to the LAN. Our MIS department frowned
> heavily at us and said that if they detected any disturbances on the LAN they
> would ban our targets. That was a year ago ...
This must be standard behaviour for these people as ours said something very
similar. We have ended up with the targets on a subnet gatewayed from a Sun!
I haven't told them how to route over the gateway yet though so I can only
talk to them from the gateway machine - so many things to do, so little time...
John...
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks Drivers for ATM Cards ?
Date: Fri, 06 Dec 1996 10:20:38 +0000
From: Robert Smith <Robert.Smith@rd.bbc.co.uk>
Organization: BBC R&D Department
Message-ID: <32A7F376.695678E2@rd.bbc.co.uk>
Does anyone know where I can get hold of VxWorks drivers for 155 Mbps
cards (such as Fore Systems) hosted by Pentium (PCA-200) or SPARC
(SBA-200) hosts ?
I have tried Com.Path but they do not seem to be able to supply what I
want from their standard product line, and the amount that they wish to
charge for porting is way outside my budget !
- --------------------------------------------------
Any opinions expressed here are my own and not
necessarily those of the BBC.
**************************************************
*   Robert Smith
*   BBC Research & Development Department.
*   Kingswood Warren, Tadworth, Surrey. KT20 6NP
*   Phone:      +44 1737 836615
*   Fax:        +44 1737 836665
*   Email:      robert.smith.bbc.co.uk
**************************************************
---------------------------
End of New-News digest
**********************
From leonid@rst.co.il  Sun Dec  8 00:13:18 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sun Dec  8 00:13:21 PST 1996
Subject: Re: Asynchronous sockets
I think enough has been written about the non-blocking vs. asynch
socket APIs. (Thanks H.J. !)
I would like to elaborate on the non-supported asynch side of it.
The wa Asynch is done on UNIX, is to deliver a SIGIO signal
what data is queued on a socket to be received. The process ID
to receive this SIGIO is the owner of file descriptor.
Now in VxWorks, say no task is waiting with a read() or recv() call
on the socket, which task should be signalled with SIGIO ??
I do no tknow for a fact, but I would speculate that this
is the reason for not supporting SIGIO. Maybe they missed
the SIOCSPGRP ioctl, that is supposed to do just that,
assign a "Process ID" to a socket fd.
Also, I would speculate that the POSIX AIO facility that has been
added since 5.2, can probably serve the same purpose. Never tried
myself, but it sounds possible. Obviously there are no AIO alternatives
for sendto() and recvfrom(), but it seems quite applicable to TCP
streams.
Happy Holidays Everyone !
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From espin@idiom.com  Sun Dec  8 09:34:48 1996
From: Geoffrey Espin <espin@idiom.com>
Date: Sun Dec  8 09:34:50 PST 1996
Subject: Re: Asynchronous sockets
Leonid, et al,
> The way Asynch is done on UNIX, is to deliver a SIGIO signal
> what data is queued on a socket to be received. The process ID
> to receive this SIGIO is the owner of file descriptor.
> Now in VxWorks, say no task is waiting with a read() or recv() call
> on the socket, which task should be signalled with SIGIO ??
>
> I do no tknow for a fact, but I would speculate that this
> is the reason for not supporting SIGIO. Maybe they missed
> the SIOCSPGRP ioctl, that is supposed to do just that,
> assign a "Process ID" to a socket fd.
Bob Cohen did the original port of BSD 4.2 networking.
I ported BSD 4.3-tahoe.  Then Hwa-Jin came on the scene
and made great improvements.
The simple reason that SIGIO on sockets was not supported
is that VxWorks had no "signals" back in '89 and then
the first pseudo-signals in VxWorks 4.0.2 were miserable.
The small amount of code commented out by me in 4.3-tahoe/VxWorks could
have easily been restored.  What about BSD 4.4?  And "mac" support?
Geoff
--
Geoffrey Espin espin@idiom.com
From ind@ocegr.fr  Mon Dec  9 00:11:40 1996
From: ind@ocegr.fr (Ibrahim Ndoye)
Date: Mon Dec  9 00:11:43 PST 1996
Subject: Virtual Memory / Hard Disk access in raw mode
Hi everybody,
I am looking for someone who has written or already deal with
virtual memory under vxWorks on ultra board Motorola 604.
Or at leat somebody who has written a piece of software which
allows RAW access on a IBM hard disk.
Thanks
Regards
Ibrahima Ndoye
From kboley@frodo.eng.vmic.com  Mon Dec  9 08:21:37 1996
From: Kirk Boley <Kirk.Boley@vmic.com>
Date: Mon Dec  9 08:21:47 PST 1996
Subject: template problems with GNU c++ 2.7.2.1
Hi all,
	I'm having problems compiling code with template functions even with
GNU c++ 2.7.2.1. I attempt to compile the following example from Stroustrup's
2nd edition:
template <class T> T max (T a, T b)
{
    return(a>b?a:b);
}
void f(int a, int b, char c, char d)
{
    int m1 = max(a, b);
    char m2 = max(c, d);
}
And I get the following error:
testtemp.cpp: In function `void f(int, int, char, char)':
testtemp.cpp:11: type unification failed for function template
                 `template <class T> T max(T, T)'
This is the same error I was getting with 2.6.
Is GNU c++ just not quite up to snuff on templates yet?
Is there a patch which will fix this problem? Or do I have to wait for 2.8?
If that's the case, is there a compiler which supports VxWorks and will
compile template functions?
================================================================================
Kirk Boley
VME Microsystems International Corporation
12090 S. Memorial Pkwy.
Huntsville, AL 35803-3308
(205)650-8254                                   EMAIL: Kirk.Boley@vmic.com
From johill@lanl.gov  Mon Dec  9 09:45:13 1996
From: Jeff Hill <johill@lanl.gov>
Date: Mon Dec  9 09:45:15 PST 1996
Subject: Re: template problems with GNU c++ 2.7.2.1
Kirk Boley wrote:
>         I'm having problems compiling code with template functions even with
> GNU c++ 2.7.2.1. I attempt to compile the following example from Stroustrup's
> 2nd edition:
I dont see any problems here when I compile the attached
coded with g++ 2.7.2.
Jeff
> template <class T> T max (T a, T b)
> {
>     return(a>b?a:b);
> }
>
> void f(int a, int b, char c, char d)
> {
>     int m1 = max(a, b);
>     char m2 = max(c, d);
> }
>
--
______________________________________________________________________
Jeffrey O. Hill                 Internet        johill@lanl.gov
LANL MS H820                    Voice           505 665 1831
Los Alamos, NM 87545 USA        FAX             505 665 5107
From Chris.Pinkard@AGAI.COM  Mon Dec  9 10:20:35 1996
From: Christopher Pinkard <Chris.Pinkard@AGAI.COM>
Date: Mon Dec  9 10:20:37 PST 1996
Subject: problems with __attribute__ ((packed))
I've got a set of network header data structs and unions.
There are three header fields, one is 2 bytes, the next
is 3 bytes, the last is 11 bytes.  Using gcc from Tornado
the compiler wants to pad these headers up to the next
even four-byte boundary.  There are many variants for
these headers, defined as different structs, and then
combined as unions.  I've declared every single field of
every struct and union with "__attribute__ ((packed))".
The good news is the compiler doesn't complain, and it
builds just fine.  The bad news is that sizeof(...)
always returns the padded size, and dumping the structure
shows that it is indeed still padded.
Anybody run into this before?  Any suggestions?
a thousand thanks,
chris pinkard
---------------------------------------------------------------
		May all your goats be free of fleas
		and may your camels never spit.
---------------------------------------------------------------
From cwsicki@sandia.gov  Mon Dec  9 12:01:24 1996
From: cwsicki@sandia.gov (Carl Sicking)
Date: Mon Dec  9 12:01:28 PST 1996
Subject: Returned mail: User unknown
Hello,
I am using the Motorola MV1603 board under VxWorks 5.3 (Tornado).  I had an
application that was running extremely slow.  I was able to trace the
sluggishness to the sqrt call.  By writing my own sqrt function, I was able
to increase the performance by an order of magnitude, even more if I was
willing to settle for less precision.  (from close to 30 microseconds
native to 2.5 for full precision )
This leaves me with several questions:
Why is the native sqrt so slow?  My guess would be that the routine is
written to run on the lowest common denominator of the Power PC family and
does not assume much about floating point hardware.  The Wind River
response to this question was "You are correct, it is slow on the MV1603.
Can we close out this TSR?"
Are there "fast" libraries available for the MV160x BSP's?  Is there a
simple fix for this that I am overlooking?  If I include -lm when linking
under GNU, I do get a faster sqrt function (around 10 microseconds) (still
too slow), but I also get an "undefined symbol _impure_ptr" message when
loading.  Under the DIAB compiler, the -lm option causes "Unsupported
relocation type 109" error message and I end up with the wrong result.
Are there other functions (such as cos, sin, etc.) that one should watch
out for?
/****** Change of topics *****/
Has anyone tried using either port 3 or 4 on the front of the MV1603 boards
as the console?  I want to avoid having a transition module plugged into
the back of each board.  Is there any reason this wouldn't work?  A quick
glance at the MVME1600-011 Base Board block diagram shows that Serial ports
3 and 4 are attached through the EIA232 and COM1 and COM2 are attached
through the PC87303 Super I/O.
Thanks in advance.
     _/_/_/_/   _/      _/   _/        Carl W. Sicking                  _
    _/         _/_/    _/   _/     Email:  cwsicki@sandia.gov         _| ~~.
   _/_/_/_/   _/  _/  _/   _/     (505) 844-2056  FAX  844-4157       \,  _}
        _/   _/    _/_/   _/     Senior Member of the Technical Staff   \( A&M
 _/_/_/_/   _/      _/   _/_/_/_/ Exploratory Image Processing Systems, 2524
   Sandia National Laboratories      Albuquerque, NM 87185-0843
From cwsicki@sandia.gov  Mon Dec  9 14:03:33 1996
From: cwsicki@sandia.gov (Carl Sicking)
Date: Mon Dec  9 14:03:35 PST 1996
Subject: sqrt on mv1603, console
Hello,
I am using the Motorola MV1603 board under VxWorks 5.3 (Tornado).  I had an
application that was running extremely slow.  I traced the sluggishness to
the sqrt call.  By writing my own sqrt function, I was able to increase the
performance by an order of magnitude, even more if I was willing to settle
for less precision.  (from close to 30 microseconds native to 2.5 for full
precision)
This leaves me with several questions:
Why is the native sqrt so slow?  My guess would be that the routine is
written to run on the lowest common denominator of the Power PC family and
does not assume much about floating point hardware.  The Wind River
response to this question was "You are correct, it is slow on the MV1603.
Can we close out this TSR?"
Are there "fast" libraries available for the MV160x BSP's?  If I include
-lm when linking under GNU, I do get a faster sqrt function (around 10
microseconds) (still too slow), but I also get an "undefined symbol
_impure_ptr" message when
loading.  Under the DIAB compiler, the -lm option causes "Unsupported
relocation type 109" error message and I end up with the wrong result.
Is there a simple fix for this that I am overlooking?
Are there other performance killing functions (sin?, cos?, etc.) included
in the shell?
/****** Change of topics *****/
Has anyone used either port 3 or 4 on the front of the MV1603 boards
as the console?  I want to avoid having a transition module plugged into
the back of each board.  Is there any reason this wouldn't work?  A quick
glance at the MVME1600-011 Base Board block diagram shows that Serial ports
3 and 4 are attached through the EIA232 and COM1 and COM2 are attached
through the PC87303 Super I/O.  I have not tried this yet, but the
difference in the block diagram makes me suspect there may be more to
making this work than just changing the console serial port define statment
in the BSP directory.
Thanks in advance.
Carl
From cgrames@mdc.com  Mon Dec  9 15:15:14 1996
From: Charlie Grames <cgrames@mdc.com>
Date: Mon Dec  9 15:15:16 PST 1996
Subject:  Re: Why is low 1 MB noncacheable on mv1604
> Does anyone know why the low 1 MB is declared as cache inhibited in the BSP for the mv1604?
> For what is the low 1 MB used?
The low 1 MB on the 1604 is used for the data structures for the shared memory and Ethernet
drivers.  Take a look at config.h.  In there you will see definitions for SM_MEM_ADRS and
SM_MEM_SIZE, SM_OBJ_MEM_ADRS and SM_OBJ_MEM_SIZE, and DC_POOL_ADRS and
DC_POOL_SIZE.  These definitions determine what portions of the low meg you are using for
shared memory, shared object memory, and Ethernet, respectively.
Note that if you are using the Ethernet interface on your card and handling or generating significant
Ethernet traffic, you will probably want to increase DC_POOL_SIZE.  The number of receive and
transmit descriptors available is a function of the pool size, and the default only allows for eight of
each.
You might also be interested in knowing that Wind River may be changing the memory layout in
their upcoming maintenance release so that memory for these data structures is allocated
dynamically rather than reserving a large chunk for them when it may not be needed.
Charlie Grames
McDonnell Douglas Training & Support Systems
(314) 233-1956
CGrames@mdc.com
From amolkho@madge.com  Tue Dec 10 08:35:47 1996
From: "Adi Molkho LAN-Tel" <amolkho@madge.com>
Date: Tue Dec 10 08:35:53 PST 1996
Subject: Re: problems with __attribute__ ((packed))
Chris
I have faced this kind of problems
you must add before all of the structures and unions declarations :
#pragma align 1
#pragma pack 1
and in the end of the declarations
#pragma pack 0
#pragma align 0
although it is not written in the Users Guide
Adi Molkho
From esadot@madge.com  Tue Dec 10 08:35:50 1996
From: "Emek Sadot LAN-Tel" <esadot@madge.com>
Date: Tue Dec 10 08:35:53 PST 1996
Subject: BSP
Hello,
I am building a BSP with the VxWorks 5.2 version (which include the Hx
supported libraries) using Intel I960HD Microprocessor, and I come up
against this problem where I can't initialize the VxWorks kernel (the
sequence of the BSP is stopped during the kernelInit()).
Assuming the kernelInit() argument are already double checked, does
someone have an idea how to solve this problem.
Thanks in advance.
Emek Sadot
Madge Networks Israel
Tel: 972-3-645-7591
eMail: esadot@madge.com
From kirnumr@dialogic.com  Tue Dec 10 09:44:21 1996
From: "Kirnum, Robert" <kirnumr@dialogic.com>
Date: Tue Dec 10 09:44:28 PST 1996
Subject: Re: problems with __attribute__ ((packed))
Try using '#pragma pack 1' to pack the data structure down to one byte
increments. And
use '#pragma pack 0' to reset the packing back to the prior maximum
setting.
__________________________________________________
D I A L	Bob Kirnum
_|_|_|O	Software Engineer
_|_|_|G	201-993-3000 Ext. 6589
_|_|_|I	201-993-5916 Fax
_|_|_|C	R.Kirnum@dialogic.com
Dialogic Corp.
1515 Rt. 10
Parsippany, NJ 07054
http://www.dialogic.com
__________________________________________________
Do you believe in Macintosh? Please check out
<http://www.evangelist.macaddict.com/>
and join the EvangeList mailing list by sending an email to
<evangelist@macway.com>.
From daemon@csg.lbl.gov  Tue Dec 10 09:53:43 1996
From: daemon@csg.lbl.gov
Date: Tue Dec 10 09:53:45 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Dec 10 04:00:17 PST 1996
        Subject: Re: VxWorks and SDL
        Subject: Call for Papers LCT-RTS '97
        Subject: Re: Two systems, One IP
        Subject: Re: VxWorks Drivers for ATM Cards ?
        Subject: 68332, BDM, and Tornado ?
        Subject: re: Asynchronous sockets
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks and SDL
Date: Wed, 04 Dec 1996 20:19:09 GMT
From: johnd@reflex-tech.co.uk (John Dalton)
Organization: Reflex Technology
Message-ID: <584mdt$115@stilton.rednet.co.uk>
References: <199511080127.JAA25922@webster.qpsx.oz.au>
Reply-To: johnd@reflex-tech.co.uk
RUSSELL@qpsx.oz.au (Jones, Russell) wrote:
>We've recently purchased VxWorks 5.2, which we'll be using in a telephony
>switch that we're developing. We're doing a lot of our signalling
>specification and design using SDL (Specification and Description
>Language), and we've found a CASE tool called SDT which <snip> does produce C output code
>(although it would not do badly in an obfuscation competition). What
>we're lacking is any way of connecting this with VxWorks. Has anyone come
>across SDT (by Telelogic in Sweden), and can they help us port the
>generated code into VxWorks?
The SDL from SDT should (if it conforms to ITU standards) be portable
to ObjectGEODE from Verilog.  There is a supported code generator
library for VX-Works for GEODE, and the C code is easily legible with
this tool as it knows about local variables' scope and doesn't need to
mangle the names.  The Verilog Design Tracer is also integrated with
Tornado for viewing target execution through the state charts and
MSC's.    See www.verilogusa.com.
>Russell Jones
>QPSX Communications Pty. Ltd.,
>Private Bag No.24,
>West Perth 6005,
>Western Australia.
>rjones@qpsx.oz.au
---------------------------
Newsgroups: comp.os.lynx,comp.os.qnx,comp.os.vxworks,comp.os.os9,comp.os.chorus
Subject: Call for Papers LCT-RTS '97
Date: 6 Dec 1996 11:20:48 GMT
From: whalley@sed.cs.fsu.edu (David Whalley)
Organization: Florida State University Computer Science Department
Message-ID: <588vig$pv2@news.fsu.edu>
                         Call for Papers
                     ACM SIGPLAN Workshop on
      Languages, Compilers, and Tools for Real-Time Systems
          http://www.cs.pitt.edu/~gupta/lct-rts97.html
                Las Vegas, Nevada, 15 June, 1997
        (In Conjunction with ACM SIGPLAN PLDI and PPoPP)
ACM  SIGPLAN  LCT-RTS  '97  is  an  interface between two dynamic
fields of computer science and engineering: programming  language
implementation and real-time systems.  Researchers in these areas
are  addressing  many  similar  problems,  but   with   different
backgrounds  and  approaches.   LCT-RTS  is  intended  to  expose
researchers from either area to  relevant  work  and  interesting
problems  in  the  other  area and provide a forum where they can
interact.
Until recently real-time systems  development  was  performed  by
experienced  specialists  using a variety of custom kernels, non-
standard  languages,  and  vendor-specific   device   interfaces.
System  integration  involved  a complicated process of obtaining
timing measurements, hand-tuning code, and  re-measuring.   These
ad-hoc  techniques  do  not scale well for modern systems.  Also,
the majority of real-time developers is  no  longer  composed  of
embedded  control experts.  New software approaches are needed to
support these new systems and provide appropriate tools for real-
time programmers.
Original  submissions  are  invited in all areas relevant to this
theme.  Appropriate topics include (but are  not  restricted  to)
the following aspects of real-time systems.
       * Programming languages for real-time applications
       * Real-time design, specification, analysis
       * Exception & interrupt handling for real-time
       * Timing analysis: static & dynamic
       * Program optimization for real-time performance
       * Real-time profiling, measurement, & debugging
       * Real-time scheduling analysis
       * Real-time memory management & garbage collection
       * Language support for imprecise computation
       * Real-time on RISCs: caches, pipelines, windows
       * Real-time system integration & testing
       * Support for partitioning, mapping, & compression
Papers  should  report  new  research  and should not exceed 5000
words (approximately  10  typeset  on  16-point  spacing,  or  15
typewritten  double-spaced  pages).   Short  papers that describe
existing implementations  or  work-in-progress,  or  outline  new
problems  or  important  issues  are  also welcome.  Short papers
should not exceed 3000 words (6 pages).  All accepted papers will
be  presented  at  the workshop and published in the proceedings,
which will be distributed at the workshop.
                        PROGRAM COMMITTEE
            Rich Gerber (University of Maryland)
            Rajiv Gupta (University of Pittsburgh)
            Jane Liu (University of Illinois)
            Tom Marlowe (Seton Hall, NJIT RTCL)
            Sang Lyul Min (Seoul National University)
            Frank Mueller (Humboldt University)
            Kelvin Nilsen (NewMonics Inc.)
            David Whalley (Florida State University)
            Andrew Wolfe (Princeton University)
                           SUBMISSION
Please  e-mail  a  postscript  copy   of   your   submission   to
whalley@cs.fsu.edu  by  5pm  EST on January 10, 1997.  If you are
unable to send a postscript file via  e-mail,  then  please  send
nine  hard  copies  to  one  of  the  co-chairs.  Authors will be
notified by March 17.  Final, camera-ready versions  are  due  on
May 15.  Proceedings will be distributed at the workshop.
               Co-Chairs, ACM SIGPLAN LCT-RTS '97
          Rajiv Gupta                     David Whalley
  Computer Science Department      Computer Science Department
    University of Pittsburgh        Florida State University
      Pittsburgh, PA 15260         Tallahassee, FL 32306-4019
   e-mail: gupta@cs.pitt.edu       e-mail: whalley@cs.fsu.edu
     phone: (412) 624-8421            phone: (904) 644-3506
      fax: (412) 624-5249              fax: (904) 644-0058
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Two systems, One IP
Date: Thu, 05 Dec 96 09:27:34 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Oracle
Message-ID: <5864fc$kqf@idiom.com>
References: <5850q8$r9d@nrchh52.rich.nt.com>
In article <5850q8$r9d@nrchh52.rich.nt.com>, ashrafis@nt.com (Siamak Razzaghe-Ashrafi) wrote:
>
>Can I have two systems running one IP.   The first will ARP it's IP
>the second will not and just listen on the net.
>
>When the first is "out" the second will pickup the packets. and vise-versa.
>
>Only one system will talk at a time but both will listen.
>
>If I do not consider Ethernet differences (I can make the systems have the same
>Ethernet address)
>
>Will this work.  Where can I get info on how this is done.
>
>I have heard Tandem has machines that have the same IP.  An application
>talking to an IP will be talking to several machines but only one IP.
>I have heard Hatchi has multiple critical Sun workstations that have
>one IP and an application does not know if any of the Suns go down.
>
>Any Ideas on how this is done?
>
This may require a custom device driver.  You need to write a driver
that will handle both ethernet devices.  IP routing will done the same
way as any other normal network interface.  When IP layer sends packets
to your custom driver, the driver should determine which ethernet
device the IP packet should go out on.  This works as long as you
program the ethernet addresses to be the same in both ethernet devices.
This works fine and you don't need to worry about turning off ARP
on one of the devices.  You wouldn't need to -- if an ARP comes in
through either of the devices (usually both devices will get a
copy of ARP at the same time) and forward the ARP packet to the
ARP network code in the kernel, either one of the device will be
used to send ARP replies back.  Even if duplicates go out everything
should work as long as the same ethernet address is used for both
ethernet devices.  You can create a custom driver like this without
really having to write drivers from scratch, if you already have
a working driver.  You will only need to modify the existing driver
to if_attach() only once for both ethernet devices.  Within the
driver, you will need to distinguish two instantiations of "softc"
for each of the ethernet devices.  For output path driver code,
you will forward the output packet to either of the output routines
per "softc" pointed if_output routine.  For input path driver code,
you only need to modify the code that puts the "ifp" pointer into
the first mbuf in the input mbuf chain being constructed.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks Drivers for ATM Cards ?
Date: Sat, 07 Dec 96 22:45:11 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <58cs1n$1t0_002@hjbpc.idiom.com>
References: <32A7F376.695678E2@rd.bbc.co.uk>
In article <32A7F376.695678E2@rd.bbc.co.uk>, Robert Smith <Robert.Smith@rd.bbc.co.uk> wrote:
>Does anyone know where I can get hold of VxWorks drivers for 155 Mbps
>cards (such as Fore Systems) hosted by Pentium (PCA-200) or SPARC
>(SBA-200) hosts ?
>
I've written drivers for FORE cards on Pentinum hosted PCI bus machines.
However, it was not for VxWorks, it was for Network Appliance NFS toaster
product.  NetApp kernel is a small embeddable kernel based on 4.4 BSD.
This was done a couple of years back, but as I recall, I had to buy
FORE SPANS IP reference code for lots of $$$$.  Writing a "netif" device
driver for the PCA cards is not hard.  Getting the driver to do signalling
and other ATM protocol stuff to manage SVC's and interoperate with other
ATM products is a different thing.  After getting the driver working
you will need ATM <-> IP protocol stuff.  2 years ago, most systems were
still using FORE SPANS IP (proprietary scheme, which worked well), but
by now they should be doing standard ATM IP (based on RFC ???).  This
is the stuff that costs a lot of effort, thus money.   On the other hand,
if you just want to run IP over SNAP over ATM PVC's, then it's much easier.
You might also want to check WRS web site.  I seem to recall some third-party
stuff that supports ATM listed there.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: 68332, BDM, and Tornado ?
Date: Mon, 09 Dec 1996 19:29:09 -0800
From: George Pontis <geo@z9.com>
Organization: Pontis Engineering Services
Message-ID: <32ACD905.25BF@z9.com>
Reply-To: geo@z9.com
Just getting started on a new project... I am wondering if anyone is
using Tornado (68K) with a BDM interface, hosted on a PC. This seems to
me to be a likely configuration, but not from visiting the wrs site. An
emulator would be OK for the initial turn-on, but would be a somewhat of
a pain long-term. Not to mention the cost. I am guessing that the
emulator would be required for nice features like being able to break in
one task while others continue to run. Any comments or suggestions ?
---------------------------
Newsgroups: comp.os.vxworks
Subject: re: Asynchronous sockets
Date: Tue, 10 Dec 96 07:23:53 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <58j369$214_002@hjbpc.idiom.com>
References: <199612081734.JAA03874@idiom.com>
In article <199612081734.JAA03874@idiom.com>, Geoffrey Espin <espin@idiom.com> wrote:
>The small amount of code commented out by me in 4.3-tahoe/VxWorks could
>have easily been restored.
The code could have been easily restored.  Whether it should work
the way it's meant to is another issue.
First, Leonid's comment about not knowing which task to send SIGIO is a
reasonable guess, but not a correct one.  The same problem exists
in both UNIX and VxWorks, and the same solution for this can be
provided.
On the other hand, the reason I personally resisted enabling the
SIGIO code is due to my lack of confidence in VxWorks signal mechanism.
I never use VxWorks signal stuff in my work, nor will I ever, because
it doesn't really provide UNIX signal semantics, even though it may
look like it does.
One major problem I have had with VxWorks sigLib is that it doesn't
really support system call restart functionality, as it was meant to
do in UNIX.  There are some subtle, if not infrequent, problems that
can happen because of this.  VxWorks goes out of its way to remedy
this situation (in genuinely ingenious way, I might add) by providing
restart capability to semaphores -- there is some special magic to
roll back and wait on the semaphore again after signal happens.  However,
this is not the same as how UNIX works.  Thus, some really subtle
and hard-to-debug errors can theoretically happen.   Which is why
I resisted the temptation to attempt to enable SIGIO stuff.
I'm not saying VxWorks sigLib is bad.  It's an excellent piece of work
from programming standpoint.  However, it really isn't compatible 100%
with UNIX ones, even though it may appear to be so to casual observers.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
End of New-News digest
**********************
From getker@sentientnet.com  Tue Dec 10 10:57:49 1996
From: getker@sentientnet.com (Jim Getker)
Date: Tue Dec 10 10:57:51 PST 1996
Subject: Re: BSP
Emek Sadot wrote:
>>I am building a BSP with the VxWorks 5.2 version (which include the Hx
>>supported libraries) using Intel I960HD Microprocessor, and I come up
>>against this problem where I can't initialize the VxWorks kernel (the
>>sequence of the BSP is stopped during the kernelInit()).
>>
>>Assuming the kernelInit() argument are already double checked, does
>>someone have an idea how to solve this problem.
I ran into a similar problem with the i960CF processor.  If the data cache
was enabled in usrInit, the usrRoot task would never start.  I moved the
enabling of the data cache to the usrRoot task, and everything worked fine.
Good Luck,
Jim Getker                          email: getker@sentientnet.com
Sentient Networks Inc.              phone: 941-379-3608
2201 Cantu Court, Suite 205         fax:   941-371-5532
Sarasota, FL. 34232
From kirnumr@dialogic.com  Tue Dec 10 11:56:04 1996
From: "Kirnum, Robert" <kirnumr@dialogic.com>
Date: Tue Dec 10 11:56:07 PST 1996
Subject: Re: BSP
Try checking your interrupts and handlers.  A simple way is to create a
dummy handler which does something you can check, perhaps bump a counter.
Use this for all interrupts and see if some invalid or unhandled one is
being triggered.
If you have access to a logic analyzer or emulator you might be able to
set
up a trace and see the course of events from when kernelInit is called.
Bob
__________________________________________________
D I A L	Bob Kirnum
_|_|_|O	Software Engineer
_|_|_|G	201-993-3000 Ext. 6589
_|_|_|I	201-993-5916 Fax
_|_|_|C	R.Kirnum@dialogic.com
Dialogic Corp.
1515 Rt. 10
Parsippany, NJ 07054
http://www.dialogic.com
__________________________________________________
Do you believe in Macintosh? Please check out
<http://www.evangelist.macaddict.com/>
and join the EvangeList mailing list by sending an email to
<evangelist@macway.com>.
From daemon@csg.lbl.gov  Wed Dec 11 04:00:24 1996
From: daemon@csg.lbl.gov
Date: Wed Dec 11 04:02:53 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec 11 04:00:22 PST 1996
        Subject: Memory tests
        Subject: telnet client
        Subject: Re: Shared Memory Network Woes
        Subject: Re: 5.3 compability 5.2 compability mode
        Subject: Re: Date/Time on x86 platform??
        Subject: Re: Floppy Driver Device Configuration
        Subject: Re: VxWorks Help !
        Subject: Re: 68332, BDM, and Tornado ?
        Subject: MVME1603 DMA BLT
        Subject: Re: MMU mapping shuts off Cache
        Subject: Re: Is your 5.2 X86 target SLOW?
        Subject: Re: Is your 5.2 X86 target SLOW?
        Subject: Re: Is your 5.2 X86 target SLOW?
        Subject: Multi-processor synchronization using VMEbus interrupt
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Memory tests
Date: 5 Dec 1996 14:55:45 -0800
From: helding@alcor.usc.edu (helding)
Organization: University of Southern California, Los Angeles, CA
Keywords: memory test power boot
Message-ID: <587jth$rar@alcor.usc.edu>
Sender: helding@alcor.usc.edu
When a PC is powered on it usually goes through a memory check before the DOS
prompt even shows up.  In my experience with vxWorks this is never done as part
of the boot-up sequence.  Does anyone know the philosophy behind this and if one
wanted to perform a memory test as part of a power-on self test how would one go
about doing it safely, i.e. what address space would be safe to write into?
- --
- --------------------------------------------------------------------------
Steve Helding                           email: helding@alcor.usc.com
- --------------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: telnet client
Date: Tue, 10 Dec 1996 10:24:15 -0500
From: Dave New <den@aisinc.com>
Organization: Applied Intelligent Systems
Message-ID: <32AD809F.1AF1@aisinc.com>
Reply-To: den@aisinc.com
Hi everyone:
Does anyone know of source for a telnet client that could run on
a vxWorks box?  I need to be able to telnet from an MVME147 card
to an i960 based box.
Thanks,
Paul Wilt
Paul Wilt
Sr. Software Engineer
Applied Intelligent Systems, Inc.
(313) 332-7044 (voice)
(313) 332-7077 (fax)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Shared Memory Network Woes
Date: Tue, 10 Dec 1996 09:39:08 -0800
From: Stef Sonck <ssonck@sun-valley.Stanford.EDU>
Organization: Stanford University
Message-ID: <32ADA03C.112589A7@sun-valley.Stanford.EDU>
References: <32A80AD0.345@gwdg.de> <32A854B9.167EB0E7@bbn.com> <850226935.27033@dejanews.com>
Maureen,
The reason might be that your kernel is configured for a P1/P2 VME
backplane,
whereas you only have a P1.
A long time ago, some people in our lab made the following change
to sysHwInit() in sysLib.c:
/* Modified to support 16 bit VME bus (no P2 backplane) (See Pg. 3-41 og
mv147 manual) */
#ifdef P2_BACKPLANE
    *LCSR_MASTER_CONF    = MASTER_CONF_MASD32 |
                           MASTER_CONF_MASA32;  /* simple A32 D32 master
*/
#else
    *LCSR_MASTER_CONF    = MASTER_CONF_MASD16 |
                           MASTER_CONF_MASA24;  /* simple A24 D16 master
*/
#endif
Hope this helps...
Stef Sonck
Aerospace Robotics Lab
Stanford University
> This did indeed make the shared memory visible.  Now the problem we're having is
> that the data at the anchor address is wrong.  After the VxWorks kernel is
> loaded, it looks something like:
>
> 40100000: 4321 ffff 0001 ffff 0000 ffff 002c ffff
> 40100010: 0170 ffff 0000 ffff 0000 ffff 0000 ffff
>
> The hardware person thinks the words are swapped, which is okay, but only every
> second word is set correctly.  The memory card has a connection to 16-bit data.
> By the way, we're using VxWorks 5.1.  Any insight into this problem would be
> greatly appreciated.  I will be out for a few weeks for the Christmas/New Year
> holidays, but I will use Deja News to read any posted responses.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: 5.3 compability 5.2 compability mode
Date: Sun, 08 Dec 1996 00:52:09 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AA81B9.2CF2@wrs.com>
References: <327FEDE2.2B2C@primenet.com>
Reply-To: johnx@wrs.com
John R Henderson wrote:
>
> How do you put 5.3 into 5.2 compatibility mode?
>
>         ____________________________
>        | John R. Henderson, HMSC    |
>        | Hughes Missile Systems Co. |
>        | (520) 792-0162             |
>        | Email:jhend@primenet.com   |
>        |____________________________|
#ifdef	INCLUDE_CONFIGURATION_5_2
#define INCLUDE_LOADER		/* object module loading */
#define INCLUDE_NET_SYM_TBL     /* load symbol table from network */
#define INCLUDE_RLOGIN          /* remote login */
#define INCLUDE_SHELL		/* interactive c-expression interpreter */
#define INCLUDE_SHOW_ROUTINES	/* show routines for system facilities*/
#define INCLUDE_SPY		/* spyLib for task monitoring */
#define INCLUDE_STARTUP_SCRIPT	/* execute start-up script */
#define INCLUDE_STAT_SYM_TBL	/* create user-readable error status */
#define INCLUDE_SYM_TBL 	/* symbol table package */
#define INCLUDE_TELNET		/* telnet-style remote login */
#define INCLUDE_UNLOADER	/* object module unloading */
#define INCLUDE_DEBUG           /* native debugging */
#undef	INCLUDE_WDB		/* tornado debug agent */
#endif	/* INCLUDE_CONFIGURATION_5_2 */
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Date/Time on x86 platform??
Date: Sun, 08 Dec 1996 01:33:31 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AA8B6B.7BEB@wrs.com>
References: <32929B68.76D6829D@leland.stanford.edu>
Reply-To: johnx@wrs.com
eric olsen wrote:
>
> Hello,
> Does anyone have the appropriate code to get the date/time
> from the bios. The 'ansi' time function supplied with vxworks
> does not return the actual date, even though there is a clock
> on the pc keeping track of it.
>
> Thanks,
>
> --------------------------------------------------------------
> "How can I lose to such an idiot?"
>                             Aaron Nimzovich(1886-1935)
>
>  eric olsen
>  eolsen@leland.stanford.edu
> --------------------------------------------------------------
value = 0 = 0x0
- -> < date
sysOutByte(0x70,9)
value = 9 = 0x9
sysInByte(0x71)
value = 150 = 0x96
sysOutByte(0x70,8)
value = 8 = 0x8
sysInByte(0x71)
value = 16 = 0x10
sysOutByte(0x70, 7)
value = 7 = 0x7
sysInByte(0x71)
value = 16 = 0x10
sysOutByte(0x70, 6)
value = 6 = 0x6
sysInByte(0x71)
value = 4 = 0x4
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Floppy Driver Device Configuration
Date: Sun, 08 Dec 1996 01:44:56 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AA8E18.7C66@wrs.com>
References: <9610311509.AA26961@woody>
Reply-To: johnx@wrs.com
Jeffrey R. Szczepanski wrote:
>
> We are trying to add floppy support to a Power PC BSP. The version of
> sysLib.c that we have does not include the "fdTypes[]" table to properly
> configure the floppy driver for DOS support. If your BSP includes the
> fdTypes[] lookup table in sysLib.c (such as the NEC765 driver on PC's),
> can you please forward a copy to me.
>
> Thanks,
>
> Jeff
>
> ------------------------------------------------------------------------------
> Jeffrey R. Szczepanski                                  Phone: (716) 264-6613
> Xerox Engineering Systems                               FAX:   (716) 264-6612
> 300 Main Street
> East Rochester, NY 14445                         Email: js@eroch.mc.xerox.com
> ------------------------------------------------------------------------------
#ifdef INCLUDE_FD
FD_TYPE fdTypes[] =
    {
    {2880,18,2,80,2,0x1b,0x54,0x00,0x0c,0x0f,0x02,1,1,"1.44M"},
    {2400,15,2,80,2,0x24,0x50,0x00,0x0d,0x0f,0x02,1,1,"1.2M"},
    };
UINT    sysFdBuf     = FD_DMA_BUF_ADDR;	/* floppy disk DMA buffer
address */
UINT    sysFdBufSize = FD_DMA_BUF_SIZE;	/* floppy disk DMA buffer size
*/
#endif	/* INCLUDE_FD */
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks Help !
Date: Sun, 08 Dec 1996 02:11:04 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AA9438.52EB@wrs.com>
References: <32814C32.6AE2@med.siemens.de>
Reply-To: johnx@wrs.com
Michael Wenzel wrote:
>
> Dear Ladies and Gentleman,
>
> We are using a FORCE SYS68K/CPU-30 Board with a running
> VxWorks Version 5.1.1 . This CPU is conncted a
> VME BUS via a SCSI II Controller to a SEAGATE ST32550N
> Disk (2.1 GByte).
> Now, we would like to use a defracmentation or squezze
> command for the disk, but the VxWorks dose not have one.
>
> How could we implement such kind of an command into our
> system or dose one already exist ?
>
> Many thnaks in advance for yor help and assistance.
>
> Best Regrads,
>
> Michael Wenzel
One way to allow memory mapped devices is to make
    following changes in sysMemTop() in sysLib.c:
#if FALSE
    limit = (((int)memTop) / 0x1000 - 1);
    for (ix=1; ix < GDT_ENTRIES; ix++)
        {
        pGdt++;
        pGdt->limit00 = limit & 0x0ffff;
        pGdt->limit01 = ((limit & 0xf0000) >> 16) | (pGdt->limit01 &
0xf0);
        }
#endif
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: 68332, BDM, and Tornado ?
Date: Tue, 10 Dec 1996 11:19:52 -0800
From: Benjamin Skrainka <bss@wrs.com>
Organization: Wind River Systems, Inc.
Message-ID: <32ADB7D8.41C67EA6@wrs.com>
References: <32ACD905.25BF@z9.com>
George Pontis wrote:
>
> Just getting started on a new project... I am wondering if anyone is
> using Tornado (68K) with a BDM interface, hosted on a PC. This seems to
> me to be a likely configuration, but not from visiting the wrs site.
I have helped several third parties integrate their BDM
emulators with Tornado.  These integrations really help
Tornado deliver on its promises to allow you to use all
the tools with even an deeply embedded target.  (Not that
I am biased. :-))
For more information on support for CPU32 and BDM,
contact:
    EST (Embedded Support Tools)
    617-828-5588
    Their product is the visionNET/visionICE line of emulators.
    They cost a few K or more depending on what features
    you get.  The basic emulator has a lot of nice features
    which will save you enough time to pay for the emulator
    quickly.
    Abatron
    Their product is called bdiWind and can operate as
    an emulator or a communication pathway to Wind River's
    WDB agent.
    Abatron AG
    Stockstrasse CH-6221
    Rickenbach
    Switzerland +41 41 930 28 44 phone
    +41 41 930 38 60 fax
    http://www.access.ch/abatron
    abatron@access.ch
> An
> emulator would be OK for the initial turn-on, but would be a somewhat of
> a pain long-term. Not to mention the cost.
These BDM emulators are definitely low cost, unlike
a full ICE.
>I am guessing that the
> emulator would be required for nice features like being able to break in
> one task while others continue to run.
Typically, with an emulator either everything is running
or nothing is running.  If you want to break only one
task, then you can use the WDB agent, which is provided with
Tornado.
Best Wishes,
- --
Ben
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Benjamin S. Skrainka                   Wind River Systems
Development Engineer                   1010 Atlantic Avenue
bss@wrs.com                            Alameda, CA 94501-1147
                                       voice     510.814.2147
http://www.wrs.com/                    facsimile 510.814.2560
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------
Newsgroups: comp.os.vxworks
Subject: MVME1603 DMA BLT
Date: Tue, 10 Dec 1996 16:18:15 +0000
From: Doug Owens <owens2@llnl.gov>
Organization: Lawrence Livermore National Lab
Message-ID: <32AD8D20.5E4D@llnl.gov>
Reply-To: owens2@llnl.gov
When I use the vmechip2 for 64bit block transfers, a vmebus analyzer
shows that the address is being reposted every 6 transfers (48 bytes)
when doing transfers from local ram to vmebus ram.  When I dma into the
local ram the interval is about every 32 transfers (256 bytes).
The manual says the DMAC will give up the VME when the FIFO is empty -
but it also says the local bus is faster than the VME bus?  Is there
anything I can do to get closer to the standard (32 transfers) on DMA
transfers to VME?  This is on a 200MHz PPC603EV (MV1603).
Thanks,
Doug Owens
owens2@llnl.gov
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: MMU mapping shuts off Cache
Date: Sun, 08 Dec 1996 01:16:19 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AA8763.7FA2@wrs.com>
References: <32A4AEF0.738B@ix.netcom.com>
Reply-To: johnx@wrs.com
CJ Fang wrote:
>
> I have been having speed problem on Pentium.
> Somehow, MMU mapping shuts off Cache on Pentium
> system and slows down VxWorks execution speed.
>
> In sysLib.c, I added an entry into sysPhysMemDesc[]
> to map my Ethernet adapter addree space to a
> virtual address space. Since the adapter is for PCI
> bus, the physical address is controlled by PCI bus
> hardware and is at high address location
> 0xfffb0000.
>
> The entry I added into sysPhysMemDesc[] is:
>
> {
> (void *)0xfffb0000,
> (void *)0xfffb0000,
> 0x1000,
> VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE |
> VM_STATE_MASK_CACHEABLE,
> VM_STATE_VALID | VM_STATE_WRITABLE |
> VM_STATE_CACHEABLE_NOT }
>
> Can anyone out there tell me why this mapping turns
> off Cache? Thank You!
>
> My another problem is that:
> If I turn on Cache with cacheLibInit() and
> cacheEnable(), I'll run into Cache Coherent
> problem.
>
> This problem was assigned a TSR #36864 since
> 11/11/96. And since about 10 days ago, I heard
> nothing back from Wind River even though I sent
> E-Mails and called Tech Support many times.
>
> Please help! I appreciate!
Notice the line below in sysLib.c.
    /* load the global descriptor table. set the MMU table */
    sysLoadGdt (gdtr);
    pMmu = &sysPhysMemDesc[2];          /* upper memory */
    pMmu->len = (UINT)memTop - (UINT)pMmu->physicalAddr;
It changes the size of the upper memory.  An entry for
the upper memory must be the third one.  Your added
entry is modified by those lines, and probably the "len"
became nagative number.  I guess that caused the entire
memory UN-CACHEABLE.  So put the new entry at the end of
the sysPhysMemDesc[] table.
I noticed that you are mapping FEI's memory at 0xfffb0000.
My PCI chipset(Intel 430HX) split the extended memory area
as follows.
     *   - Flash BIOS area from 4GByte to (4GB - 512KB)
     *   - DRAM memory from 1MB to a maximum of 512MB
     *   - PCI memory space from the top of DRAM to (4GB - 512KB)
Check your chipset.
> 2. Why does cacheEnable() speed up Pentium in ether case?
I noticed that CR0 register is different after the second
cacheLibInit().
  1st time:
    CR0=0x80010013
  2nd time:
    CR)=0x11
I believe that is caused by sysCpuProbe() in sysALib.s.
sysCpuProbe() in 1.0-FCS is not user callable.
So cacheLibInit() should be called only once.
Actually, we fixed it for the next release.  You could
replace it if you like, as follows:
- ----- sysALib.s -----
        .align 4,0x90
_sysCpuProbe:
        cmpl    $-1,_sysProcessor
        je      sysCpuProbe99
        movl    _sysProcessor,%eax
        ret
sysCpuProbe99:
        cli
        movl    %cr0,%eax
        andl    $0x7ffafff1,%eax        /* PG=0, AM=0, WP=0, TS=0, EM=0,
MP=0 *
/
        orl     $0x60000000,%eax        /* CD=1, NW=1 */
        movl    %eax,%cr0
        pushfl
        popl    %edx
        movl    %edx,%ecx
        xorl    $0x00040000,%edx        /* AC bit */
        pushl   %edx
        popfl
        pushfl
        popl    %edx
        xorl    %edx,%ecx
        jz      sysCpuProbe0
        pushfl
        popl    %edx
        movl    %edx,%ecx
        xorl    $0x00200000,%edx        /* ID bit */
        pushl   %edx
        popfl
        pushfl
        popl    %edx
        xorl    %edx,%ecx
        jz      sysCpuProbe1
        movl    $ X86CPU_PENTIUM,%eax   /* 2 for Pentium */
        movl    %eax,_sysProcessor
        ret
sysCpuProbe1:
        movl    $ X86CPU_486,%eax       /* 1 for 486 */
        movl    %eax,_sysProcessor
        ret
sysCpuProbe0:
        movl    $ X86CPU_386,%eax       /* 0 for 386 */
        movl    %eax,_sysProcessor
        ret
- ----- sysLib.c -----
 UINT    sysProcessor    = NONE;         /* 0=386, 1=486, 2=Pentium */
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is your 5.2 X86 target SLOW?
Date: Sun, 08 Dec 1996 01:57:13 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AA90F9.4A4@wrs.com>
References: <565dbf$kdm@Starbase.NeoSoft.COM>
Reply-To: johnx@wrs.com
Bob Irwin wrote:
>
> If you are using the X86 bsp with vxWorks 5.2, you may have
> a serious performance problem with system images that are
> loaded into low memory (bootable *.st images).  To see if
> your bsp has this problem, boot a vanilla vxWorks image
> (with timexN support) from the network and enter the
> following two shell commands.  Observe the return values.
>
>    -> timexN bcopyBytes, 0x200000, 0x300000, 1000
>
>    -> timexN bcopyBytes, 0x108000, 0x300000, 1000
>                             ^
>                        LOW_RAM_ADRS
>
> The first command times a copy of bytes from 'high mem' to 'high mem',
> while the second command times a copy of bytes from 'low mem' to
> 'high mem'.  If your low mem copy takes 3-4 times LONGER that
> your high mem copy, You have this problem.  If you load a bootable
> standalone image, it loads at LOW_RAM_ADDRESS.  If you've linked
> your own code into the kernel, it's gonna run SLOW.  Not only
> your code, but sysLib is loaded here (sysInByte, sysOutByte, etc).
>
> As delivered, our bsp's LOW_RAM_ADRS was set at 0x108000
> in Makefile, MakeSkel, Makefile.I80486gnu, and config.h.
> The original sysPhysMemDesc showed 0x100000 as the beginning of
> cached memory.  By using timexN, I found that the first 64K bytes
> of 'low mem' were likely uncached.  This problem existed on
> different target machines with different CPU types.
>
> My 'workaround' was to change LOW_RAM_ADRS in the above 4 bsp
> files to 0x110000.  This lets the 'low mem' copy run at normal
> speed.
>
> A TSR was openened on this several months ago with no resolution.
> It has been reopened with the above test description.
>
> I'm a consultant for Systems Interface Software, Inc. (SIS). We
> have geen providing custom PC104 boxes and software to NASA
> at JSC here in Houston.
>
>    - Bob
> --
> R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 <irwin@neosoft.com>
> I don't want to achieve immortality through my work.  I want to
> achieve immortality through not dying.  - Woody Allen
- -> version
VxWorks (for PC 386) version 5.3.
Kernel: WIND version 2.4
Made on Sun Dec 08 01:50:56 1996.
Boot line:
eex(0,0)god:g:\pcmcia\target\config\pc386\vxWorks e=90.0.0.50:ff000000
h=90.0.0.3 u=vxwork
s pw=vxworks tn=gonesh.
value = 0 = 0x0
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
value = 58 = 0x3a = ':'
- ->
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is your 5.2 X86 target SLOW?
Date: Sun, 08 Dec 1996 03:18:42 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AAA412.2170@wrs.com>
References: <565dbf$kdm@Starbase.NeoSoft.COM>
Reply-To: johnx@wrs.com
Bob Irwin wrote:
>
> If you are using the X86 bsp with vxWorks 5.2, you may have
> a serious performance problem with system images that are
> loaded into low memory (bootable *.st images).  To see if
> your bsp has this problem, boot a vanilla vxWorks image
> (with timexN support) from the network and enter the
> following two shell commands.  Observe the return values.
>
>    -> timexN bcopyBytes, 0x200000, 0x300000, 1000
>
>    -> timexN bcopyBytes, 0x108000, 0x300000, 1000
>                             ^
>                        LOW_RAM_ADRS
>
> The first command times a copy of bytes from 'high mem' to 'high mem',
> while the second command times a copy of bytes from 'low mem' to
> 'high mem'.  If your low mem copy takes 3-4 times LONGER that
> your high mem copy, You have this problem.  If you load a bootable
> standalone image, it loads at LOW_RAM_ADDRESS.  If you've linked
> your own code into the kernel, it's gonna run SLOW.  Not only
> your code, but sysLib is loaded here (sysInByte, sysOutByte, etc).
>
> As delivered, our bsp's LOW_RAM_ADRS was set at 0x108000
> in Makefile, MakeSkel, Makefile.I80486gnu, and config.h.
> The original sysPhysMemDesc showed 0x100000 as the beginning of
> cached memory.  By using timexN, I found that the first 64K bytes
> of 'low mem' were likely uncached.  This problem existed on
> different target machines with different CPU types.
>
> My 'workaround' was to change LOW_RAM_ADRS in the above 4 bsp
> files to 0x110000.  This lets the 'low mem' copy run at normal
> speed.
>
> A TSR was openened on this several months ago with no resolution.
> It has been reopened with the above test description.
>
> I'm a consultant for Systems Interface Software, Inc. (SIS). We
> have geen providing custom PC104 boxes and software to NASA
> at JSC here in Houston.
>
>    - Bob
> --
> R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 <irwin@neosoft.com>
> I don't want to achieve immortality through my work.  I want to
> achieve immortality through not dying.  - Woody Allen
Attaching network interface eex0... done.
Attaching network interface lo0... done.
NFS client support not included.
Adding 2151 symbols for standalone.
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
      ]]]]]]]]]]]  ]]]]     ]]]]]]]]]]       ]]
]]]]         (R)
 ]     ]]]]]]]]]  ]]]]]]     ]]]]]]]]       ]]               ]]]]
 ]]     ]]]]]]]  ]]]]]]]]     ]]]]]] ]     ]]                ]]]]
 ]]]     ]]]]] ]    ]]]  ]     ]]]] ]]]   ]]]]]]]]]  ]]]] ]] ]]]]  ]]
]]]]]
 ]]]]     ]]]  ]]    ]  ]]]     ]] ]]]]] ]]]]]]   ]] ]]]]]]] ]]]] ]]
]]]]
 ]]]]]     ]  ]]]]     ]]]]]      ]]]]]]]] ]]]]   ]] ]]]]    ]]]]]]]
]]]]
 ]]]]]]      ]]]]]     ]]]]]]    ]  ]]]]]  ]]]]   ]] ]]]]    ]]]]]]]]
]]]]
 ]]]]]]]    ]]]]]  ]    ]]]]]]  ]    ]]]   ]]]]   ]] ]]]]    ]]]]
]]]]    ]]]]
 ]]]]]]]]  ]]]]]  ]]]    ]]]]]]]      ]     ]]]]]]]  ]]]]    ]]]]  ]]]]
]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]       Development System
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]       VxWorks version 5.3
 ]]]]]]]]]]]]]]]]]]]]]]]]]]       KERNEL: WIND version 2.4
 ]]]]]]]]]]]]]]]]]]]]]]]]]       Copyright Wind River Systems, Inc.,
1984-1995
                               CPU: PC 386.  Processor #0.
                              Memory Size: 0x400000.  BSP version 1.1/1.
- ->
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
timex: 2675 reps, time per rep = 343 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
timex: 2675 reps, time per rep = 349 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 2675 reps, time per rep = 349 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 2675 reps, time per rep = 349 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- ->-> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 2675 reps, time per rep = 343 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x200000, 0x300000, 1000
timex: 2675 reps, time per rep = 343 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 2675 reps, time per rep = 343 +/- 6 (1%) microsecs
value = 58 = 0x3a = ':'
- ->
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is your 5.2 X86 target SLOW?
Date: Sun, 08 Dec 1996 04:49:21 -0800
From: Nicky and Gypsie <johnx@wrs.com>
Organization: Messy
Message-ID: <32AAB951.4D20@wrs.com>
References: <565dbf$kdm@Starbase.NeoSoft.COM>
Reply-To: johnx@wrs.com
Bob Irwin wrote:
>
> If you are using the X86 bsp with vxWorks 5.2, you may have
> a serious performance problem with system images that are
> loaded into low memory (bootable *.st images).  To see if
> your bsp has this problem, boot a vanilla vxWorks image
> (with timexN support) from the network and enter the
> following two shell commands.  Observe the return values.
>
>    -> timexN bcopyBytes, 0x200000, 0x300000, 1000
>
>    -> timexN bcopyBytes, 0x108000, 0x300000, 1000
>                             ^
>                        LOW_RAM_ADRS
>
> The first command times a copy of bytes from 'high mem' to 'high mem',
> while the second command times a copy of bytes from 'low mem' to
> 'high mem'.  If your low mem copy takes 3-4 times LONGER that
> your high mem copy, You have this problem.  If you load a bootable
> standalone image, it loads at LOW_RAM_ADDRESS.  If you've linked
> your own code into the kernel, it's gonna run SLOW.  Not only
> your code, but sysLib is loaded here (sysInByte, sysOutByte, etc).
>
> As delivered, our bsp's LOW_RAM_ADRS was set at 0x108000
> in Makefile, MakeSkel, Makefile.I80486gnu, and config.h.
> The original sysPhysMemDesc showed 0x100000 as the beginning of
> cached memory.  By using timexN, I found that the first 64K bytes
> of 'low mem' were likely uncached.  This problem existed on
> different target machines with different CPU types.
>
> My 'workaround' was to change LOW_RAM_ADRS in the above 4 bsp
> files to 0x110000.  This lets the 'low mem' copy run at normal
> speed.
>
> A TSR was openened on this several months ago with no resolution.
> It has been reopened with the above test description.
>
> I'm a consultant for Systems Interface Software, Inc. (SIS). We
> have geen providing custom PC104 boxes and software to NASA
> at JSC here in Houston.
>
>    - Bob
> --
> R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 <irwin@neosoft.com>
> I don't want to achieve immortality through my work.  I want to
> achieve immortality through not dying.  - Woody Allen
Hello,
	I also tested on 486.  Below was 386.  (opps)
but even with 80486-DX2,  I did not see this problem:
Adding 2167 symbols for standalone.
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
      ]]]]]]]]]]]  ]]]]     ]]]]]]]]]]       ]]              ]]]]
(R)
 ]     ]]]]]]]]]  ]]]]]]     ]]]]]]]]       ]]               ]]]]
 ]]     ]]]]]]]  ]]]]]]]]     ]]]]]] ]     ]]                ]]]]
 ]]]     ]]]]] ]    ]]]  ]     ]]]] ]]]   ]]]]]]]]]  ]]]] ]] ]]]]  ]]
]]]]]
 ]]]]     ]]]  ]]    ]  ]]]     ]] ]]]]] ]]]]]]   ]] ]]]]]]] ]]]] ]]
]]]]
 ]]]]]     ]  ]]]]     ]]]]]      ]]]]]]]] ]]]]   ]] ]]]]    ]]]]]]]
]]]]
 ]]]]]]      ]]]]]
  ]]]]]]    ]  ]]]]]  ]]]]   ]] ]]]]    ]]]]]]]]    ]]]]
 ]]]]]]]    ]]]]]  ]    ]]]]]]  ]    ]]]   ]]]]   ]] ]]]]    ]]]] ]]]]
]]]]
 ]]]]]]]]  ]]]]]  ]]]    ]]]]]]]      ]     ]]]]]]]  ]]]]    ]]]]  ]]]]
]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]       Development System
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]       VxWorks version 5.3
 ]]]]]]]]]]]]]]]]]]]]]]]]]]       KERNEL: WIND version 2.4
 ]]]]]]]]]]]]]]]]]]]]]]]]]       Copyright Wind River Systems, Inc.,
1984-1995
                               CPU: PC 486.  Processor #0.
                              Memory Size: 0xfff000.  BSP version 1.1/1.
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x300000, 0x400000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x300000, 0x400000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x108000, 0x300000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- -> timexN bcopyBytes, 0x300000, 0x400000, 1000
timex: 5000 reps, time per rep = 125 +/- 3 (2%) microsecs
value = 58 = 0x3a = ':'
- ->
So, perhaps something has changed in the MMU or GDT in your BSP?
---------------------------
Newsgroups: comp.os.vxworks
Subject: Multi-processor synchronization using VMEbus interrupt
Date: 10 Dec 1996 22:15:28 GMT
From: dmorse@Morsesoft.COM (Dennis F. Morse)
Organization: Morse Associates
Message-ID: <58kne0$4ag@nntp1.best.com>
Reply-To: dmorse@Morsesoft.COM
Sender: dmorse@sun-valley.Stanford.EDU (Dennis F. Morse)
Hello,
I'm trying to use a single VMEbus interrupt (level 6) to synchronize two
processors. I've read through the Wind River documentation and it isn't much
help. I can't seem to find any examples.
Below are two simple routines I've written: one to generate an interrupt on
the master processor (slot 0) and a responder on the processor in slot 1
However, I get an ``Uninitialized Interrupt'' error on the receiver. Both
processors are mv167s.
Below are the commands and the spurious uninitialized interrupt error.
    On slot 1 processor (receiver):
	-> ld 1 < receiveInt.o
	value = 1986588 = 0x1e501c = receiveInt.o_bss + 0x8
	-> InterruptInit
	InterruptInit: intConnect() succeeded. Enabling interrupts.
	value = 0 = 0x0
    On slot 0 processor (generator):
	-> ld 1 < generateInt.o
	value = 1698932 = 0x19ec74 = generateInt.o_bss + 0xc
	-> printIvecNum 6
	Interrupt vector address of interrupt level 6 is 0x24.
	value = 56 = 0x38 = '8'
	-> generateInterrupt
	value = 0 = 0x0
The output on processor 1 is the following.
    interrupt:
					 Uninitialized Interrupt!
	Vector number 24 (0-255). Spurious Interrupt
	Program Counter: 0x0005715e
	Status Register: 0x3600
	interrupt:
	Uninitialized Interrupt!
	Vector number 24 (0-255). Spurious Interrupt
	Program Counter: 0x0005715e
	Status Register: 0x3600
I thought all that was needed to initialize an interrupt was calls to
intConnect() and sysIntEnable(). The veclist utility shows my ISR attached.
What I'm missing? Is there a good place to get documentation and examples
on this kind of stuff?
Thanks,
Dennis Morse
- -----
On Slot 0 processor (mv167):  File generateInt.c
================================================
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <sysLib.h>
#include <intLib.h>
#include <iv.h>
#define SYNC_ILEVEL	(6)
static int iVecAddr;
int printIvecNum( int intLevel )
{
    iVecAddr = INUM_TO_IVEC( intLevel );
    printf( "Vector address of interrupt level %d is %p.\n",
	    intLevel, iVecAddr );
}
int generateInterrupt( void )
{
    sysBusIntGen( SYNC_ILEVEL, INUM_TO_IVEC(SYNC_ILEVEL) );
}
On Slot 1 processor (mv167):  File receiveInt.c
===============================================
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <logLib.h>
#include <sysLib.h>
#include <intLib.h>
#include <iv.h>
#define SYNC_ILEVEL	(6)
static int InterruptCount = 0;
/*
 * This is the ISR called upon a frame interrupt.
 */
void trajISR( void )
{
    sysBusIntAck( SYNC_ILEVEL );	/* Acknowledge interrupt. */
    InterruptCount++;
    logMsg( "trajISR: Received interrupt number %d.\n", InterruptCount );
}
int InterruptInit( void )
{
    if ( intConnect( INUM_TO_IVEC(SYNC_ILEVEL), trajISR, 0 ) == OK ) {
	printf( "InterruptInit: intConnect() succeeded. Enabling "
		"interrupts.\n" );
	sysIntEnable( SYNC_ILEVEL );	/* Enable this level of interrupts. */
    } else {
	printf( "InterruptInit: intConnect() FAILED.\n" );
    }
}
- ------------------------------------------------------------------------------
Output of veclist:
==================
    Slot 0 processor.
	-> ld 1 < veclist.o
	value = 2006128 = 0x1e9c70 = veclist.o_bss + 0xbd8
	-> veclist
	vec 0x00 MACRO ISR __DYNAMIC
	vec 0x01 MACRO ISR __DYNAMIC
	vec 0x04 MACRO ISR __x_fpsp_ill_inst
	vec 0x0B MACRO ISR __x_fpsp_fline
	vec 0x30 MACRO ISR __x_fpsp_bsun
	vec 0x31 MACRO ISR __x_fpsp_inex
	vec 0x32 MACRO ISR __x_fpsp_dz
	vec 0x33 MACRO ISR __x_fpsp_unfl
	vec 0x34 MACRO ISR __x_fpsp_operr
	vec 0x35 MACRO ISR __x_fpsp_ovfl
	vec 0x36 MACRO ISR __x_fpsp_snan
	vec 0x37 MACRO ISR __x_fpsp_unsupp
	vec 0x47     C ISR _eiInt(0x7D30C)
	vec 0x48     C ISR _sysAuxClkInt(0x0)
	vec 0x49     C ISR _sysClkInt(0x0)
	vec 0x55     C ISR _sysMailboxInt(0x0)
	vec 0x5E     C ISR _sysAbortInt(0x0)
	vec 0x90     C ISR _tyCoInt(0x7F420)
	vec 0x92     C ISR _tyCoIntTx(0x7F420)
	vec 0x93     C ISR _tyCoIntRx(0x7F420)
	vec 0x94     C ISR _tyCoInt(0x7F50C)
	vec 0x96     C ISR _tyCoIntTx(0x7F50C)
	vec 0x97     C ISR _tyCoIntRx(0x7F50C)
	vec 0x98     C ISR _tyCoInt(0x7F5F8)
	vec 0x9A     C ISR _tyCoIntTx(0x7F5F8)
	vec 0x9B     C ISR _tyCoIntRx(0x7F5F8)
	vec 0x9C     C ISR _tyCoInt(0x7F6E4)
	vec 0x9E     C ISR _tyCoIntTx(0x7F6E4)
	vec 0x9F     C ISR _tyCoIntRx(0x7F6E4)
	value = 0 = 0x0
    Slot 1 processor.
	-> ld 1 < veclist.o
	value = 2040916 = 0x1f2454 = veclist.o_bss + 0x8
	-> veclist
	vec 0x00 MACRO ISR __DYNAMIC
	vec 0x01 MACRO ISR __DYNAMIC
	vec 0x04 MACRO ISR __x_fpsp_ill_inst
	vec 0x06     C ISR _trajISR(0x0)
	vec 0x0B MACRO ISR __x_fpsp_fline
	vec 0x30 MACRO ISR __x_fpsp_bsun
	vec 0x31 MACRO ISR __x_fpsp_inex
	vec 0x32 MACRO ISR __x_fpsp_dz
	vec 0x33 MACRO ISR __x_fpsp_unfl
	vec 0x34 MACRO ISR __x_fpsp_operr
	vec 0x35 MACRO ISR __x_fpsp_ovfl
	vec 0x36 MACRO ISR __x_fpsp_snan
	vec 0x37 MACRO ISR __x_fpsp_unsupp
	vec 0x48     C ISR _sysAuxClkInt(0x0)
	vec 0x49     C ISR _sysClkInt(0x0)
	vec 0x55     C ISR _sysMailboxInt(0x0)
	vec 0x5E     C ISR _sysAbortInt(0x0)
	vec 0x90     C ISR _tyCoInt(0x7F420)
	vec 0x92     C ISR _tyCoIntTx(0x7F420)
	vec 0x93     C ISR _tyCoIntRx(0x7F420)
	vec 0x94     C ISR _tyCoInt(0x7F50C)
	vec 0x96     C ISR _tyCoIntTx(0x7F50C)
	vec 0x97     C ISR _tyCoIntRx(0x7F50C)
	vec 0x98     C ISR _tyCoInt(0x7F5F8)
	vec 0x9A     C ISR _tyCoIntTx(0x7F5F8)
	vec 0x9B     C ISR _tyCoIntRx(0x7F5F8)
	vec 0x9C     C ISR _tyCoInt(0x7F6E4)
	vec 0x9E     C ISR _tyCoIntTx(0x7F6E4)
	vec 0x9F     C ISR _tyCoIntRx(0x7F6E4)
    (ORIGINAL BEFORE MY CODE)
	-> veclist
	vec 0x00 MACRO ISR __DYNAMIC
	vec 0x01 MACRO ISR __DYNAMIC
	vec 0x04 MACRO ISR __x_fpsp_ill_inst
	vec 0x0B MACRO ISR __x_fpsp_fline
	vec 0x30 MACRO ISR __x_fpsp_bsun
	vec 0x31 MACRO ISR __x_fpsp_inex
	vec 0x32 MACRO ISR __x_fpsp_dz
	vec 0x33 MACRO ISR __x_fpsp_unfl
	vec 0x34 MACRO ISR __x_fpsp_operr
	vec 0x35 MACRO ISR __x_fpsp_ovfl
	vec 0x36 MACRO ISR __x_fpsp_snan
	vec 0x37 MACRO ISR __x_fpsp_unsupp
	vec 0x48     C ISR _sysAuxClkInt(0x0)
	vec 0x49     C ISR _sysClkInt(0x0)
	vec 0x55     C ISR _sysMailboxInt(0x0)
	vec 0x5E     C ISR _sysAbortInt(0x0)
	vec 0x90     C ISR _tyCoInt(0x7F420)
	vec 0x92     C ISR _tyCoIntTx(0x7F420)
	vec 0x93     C ISR _tyCoIntRx(0x7F420)
	vec 0x94     C ISR _tyCoInt(0x7F50C)
	vec 0x96     C ISR _tyCoIntTx(0x7F50C)
	vec 0x97     C ISR _tyCoIntRx(0x7F50C)
	vec 0x98     C ISR _tyCoInt(0x7F5F8)
	vec 0x9A     C ISR _tyCoIntTx(0x7F5F8)
	vec 0x9B     C ISR _tyCoIntRx(0x7F5F8)
	vec 0x9C     C ISR _tyCoInt(0x7F6E4)
	vec 0x9E     C ISR _tyCoIntTx(0x7F6E4)
	vec 0x9F     C ISR _tyCoIntRx(0x7F6E4)
	value = 0 = 0x0
- --
---------------------------
End of New-News digest
**********************
From mmilde@scires.com  Wed Dec 11 06:09:30 1996
From: Mike Milde <mmilde@scires.com>
Date: Wed Dec 11 06:09:32 PST 1996
Subject: Experiences with Java/Tornado?
I haven't seen any postings from people using Tornado for
Java, and I'm just curious about anyone's experiences
with it.  Is this product available from Wind River yet?  If
you use it, does Java really work well in an embedded
environment?  And most of all, why did you choose to use
Java instead of C++?
Thanks!
Mike Milde
Scientific Research Corporation
mmilde@scires.com
From mili@medoc.force.se  Wed Dec 11 10:59:18 1996
From: Michael Liden <mili@medoc.force.se>
Date: Wed Dec 11 10:59:20 PST 1996
Subject: Re: VxWorks and SDL
Hi!
>RUSSELL@qpsx.oz.au (Jones, Russell) wrote:
>
>>We've recently purchased VxWorks 5.2, which we'll be using in a telephony
>>switch that we're developing. We're doing a lot of our signalling
>>specification and design using SDL (Specification and Description
>>Language), and we've found a CASE tool called SDT which <snip> does
produce C output code
>>(although it would not do badly in an obfuscation competition). What
>>we're lacking is any way of connecting this with VxWorks. Has anyone come
>>across SDT (by Telelogic in Sweden), and can they help us port the
>>generated code into VxWorks?
I know customers that have used the VxWorks/SDT combination.
Check out the Telelogic web pages (http://www.telelogic.se/), which say:
"VxWorks fully integrated with SDT 3.0. Included in the integration is the
possibility to have a trace in MSC-PR format, this trace can then be visualized
in the MSC editor. Several customers are using the VxWorks integration."
/Michael
From pathway@pathway-inc.com  Wed Dec 11 12:10:08 1996
From: "Pathway, Inc." <pathway@pathway-inc.com>
Date: Wed Dec 11 12:10:11 PST 1996
Subject: Looking for ATM Driver
Dear Anybody:
We have developed a ATM card with Bt8230 and TI TNETE100 for the
distance learning system.
I am looking for Bt8230 Driver for ILMI and UNI 3.1 Signalling stack and
Ethernet driver over Vxwork.
Would you direct me any company or person for these?
Thanks in advance.
Tai Rhee
Pathway Inc.
777 Beta Drive
Cleveland, Ohio 44143
(216)473-0270
pathway@pathway-inc.com
From chris@kla-inc.com  Wed Dec 11 13:24:37 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:24:39 PST 1996
,kSNGLKvndflknvDKFLNBVlkfdnbfdrSf
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 13:25:46 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:25:47 PST 1996
'l;kdrf;lgkmrda;lhgb;lkdfghjz;lkdtfmh;klmtfhf
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 13:39:11 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:39:13 PST 1996
dthjtrjrsytjytjsyt
srtj
y
t
j
ytdsjytsjytsjr6syjyrsjtrt
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 13:50:58 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:51:00 PST 1996
.khdflkjhsdlkfjnfsdlkjfsdjlkjf
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 13:52:08 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:52:10 PST 1996
sdfgldfgadfgfgadfgdf
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 13:53:33 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:53:35 PST 1996
rthsrthrthstrthrs
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 13:55:50 1996
From: Chris Shoulet <chris@kla-inc.com>
Date: Wed Dec 11 13:55:52 PST 1996
test
<x-rich></x-rich><x-rich>
==========================
PIERRE CLEMENCEAU at
Ken Leiner & Associates, inc.
11510  Georgia Ave, Suite # 105
Wheaton, MD  20902
voice:  301-933-8800  ext 127
fax:     301-933-8808
toll free: 800-989-8803
email: pierre@kla-inc.com
==========================
</x-rich>
From chris@kla-inc.com  Wed Dec 11 14:03:06 1996
From: jyclemenceau@CCGATE.HAC.COM (by way of Chris Shoulet <jyclemenceau@CCGATE.HAC.COM>)
Date: Wed Dec 11 14:03:11 PST 1996
     hi,
     je crois que mon addresse is
     jacques@ccgate.hac.com
From pierre@kla-inc.com  Wed Dec 11 14:12:25 1996
From: pierre@kla-inc.com (Pierre Clemenceau)
Date: Wed Dec 11 14:12:27 PST 1996
Subject: Email problems
I am sorry for any emails incorrectly redirected by Chris or myself to
vxwexplo@lbl.gov.
My Beta Eudora has been acting up.
Pierre
From kpmarie@binc.net  Wed Dec 11 15:38:39 1996
From: "Dave Sloan" <kpmarie@binc.net>
Date: Wed Dec 11 15:38:41 PST 1996
Subject: unsubscribe
unsubscribe
From kpmarie@mailbag.com  Wed Dec 11 15:40:02 1996
From: "Dave Sloan" <kpmarie@mailbag.com>
Date: Wed Dec 11 15:40:05 PST 1996
Subject: unsubscribe
unsubscribe
From jiaqp@nuhepz.phys.nwu.edu  Wed Dec 11 15:59:45 1996
From: "QiuPing Jia" <jiaqp@nuhepz.phys.nwu.edu>
Date: Wed Dec 11 15:59:47 PST 1996
hi, there,
  I have recieved 6-7 copies of your test mail, it is working!
--
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@  QIUPING   JIA                                                      @@@@@
@  8836 North Moody Av.                                               @@@@@
@  Morton Grove, IL 60053                                             @@@@@
@  Physics and Astronomy, Northwestern University, Evenston, IL       @@@@@
@  Tel#: (847)9650232(h)    (847)4673083(L)   Fax: (847)4675712(L)    @@@@@
@  E-mail: jiaqp@nuhepz.phys.nwu.edu, jiaqp@nuhep.phys.nwu.edu       @@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
From froeber@bbn.com  Wed Dec 11 19:11:45 1996
From: Fred Roeber <froeber@bbn.com>
Date: Wed Dec 11 19:11:47 PST 1996
Subject: Re: generating VME interrupts for Multi-processor sync
On Wed, 11 Dec 1996, Dennis F. Morse wrote:
>
> I'm trying to use a single VMEbus interrupt (level 6) to synchronize two
> processors. I've read through the Wind River documentation and it isn't much
> help. I can't seem to find any examples.
>
> Below are two simple routines I've written: one to generate an interrupt on
> the master processor (slot 0) and a responder on the processor in slot 1
> However, I get an ``Uninitialized Interrupt'' error on the receiver. Both
> processors are mv167s.
<<cut>>
> I thought all that was needed to initialize an interrupt was calls to
> intConnect() and sysIntEnable(). The veclist utility shows my ISR attached.
> What I'm missing? Is there a good place to get documentation and examples
> on this kind of stuff?
As to your last question first; there isn't much documentation around
relative to using the board/architecture related functions under VxWorks.
The BSPs try to standardize things as much as possible but the details
on using things like interrupts aren't really spelled out to fully.
You can always look at the source code for the BSP to see what it says
for your specific board.  For the MVME167, I would start by looking at
config/mv167/sysLib.c.  The interrupt handling code is in
  src/drv/vme/vmeChip2Vme.c
Your main problem is that you aren't making the proper distinction between
interrupt levels, interrupt numbers, and interrupt vectors.  This isn't your
fault as I have always thought there was a fair amount of ambiguity in what
VxWorks documentation there is.  Interrupt levels are fairly straightforward;
there are only 7 VME interrupt levels.  Your use of level 6 is fine as long
as no other VME board in your bus will also be trying to respond to level
6 interrupts.
Ohe big problem is with the interrupt vector/number you are using.  In
VxWorks, interrupt numbers are simple integers while interrupt vectors
are interrupt table adress offsets (i.e. interrupt number times 4).  The
problem is that most Motorola doc uses the term interrupt vector to describe
what VxWorks calls an interrupt number.  You really need to keep the two
terms straight as some routines in VxWorks take interrupt numbers and
others take interrupt vectors.
As to the details, there are 256 possible interrupt numbers for the MC68040
processor on the MV167 card.  In general, you want to stay away from
reserved interrupt numbers which are classified as 0-63 for this architecture.
I usually further restrict the numbers I use to the range 180-255 (to avoid
trampling interrupts used for things like peripheral chips).  If you use
interrupt number 180 in your code it should work fine.  You had coded:
> int generateInterrupt( void )
> {
>     sysBusIntGen( SYNC_ILEVEL, INUM_TO_IVEC(SYNC_ILEVEL) );
> }
> void trajISR( void )
> {
>     sysBusIntAck( SYNC_ILEVEL );	/* Acknowledge interrupt. */
>     InterruptCount++;
>     logMsg( "trajISR: Received interrupt number %d.\n", InterruptCount );
> }
>
> int InterruptInit( void )
> {
>     if ( intConnect( INUM_TO_IVEC(SYNC_ILEVEL), trajISR, 0 ) == OK ) {
> 	printf( "InterruptInit: intConnect() succeeded. Enabling "
> 		"interrupts.\n" );
> 	sysIntEnable( SYNC_ILEVEL );	/* Enable this level of interrupts. */
>     } else {
> 	printf( "InterruptInit: intConnect() FAILED.\n" );
>     }
> }
It turns out that the intConnect function requires an interrupt vector;
thus the use of INUM_TO_IVEC is correct.  The sysBusIntGen function is
poorly documented.  Even though the code describes the input parm as:
      int vector          /* interrupt vector for interrupt */
The function really takes what should be called an interrupt number;
you use the value 180 directly without INUM_TO_IVEC.  The only real way
to tell this is to note that the code for the function checks that the
vector is in the range 2 - 255.  So, use INUM_TO_IVEC(180) as the parm
to intConnect but 180 as the 2nd parm to sysBusIntGen and everything should
work.
As a side note, the processor on the board receiving the interrupt didn't
respond to the vector 24 you were using so the result was a spurious interrupt.
Also, you will notice if you look at the code that sysBusIntAck is a NULL
routine for the MV167 so can be left out.
Hope this helps.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
From malcolm.cifuentes@nautronix.com.au  Wed Dec 11 19:26:27 1996
From: malcolm.cifuentes@nautronix.com.au (Malcolm Cifuentes)
Date: Wed Dec 11 19:26:29 PST 1996
Subject: windsh crashes when I ...
Hi all,
    OS: Solaris 2.51
    Tornado: FCS 1.0 Power PC 1604
    Has any one seen the following behaviour :-
    When I execute the windsh command and connect to a target, as soon
    as I execute :-
        -> cplusXtorSet 1
              or
        -> cplusStratShow
    Any following command crashes the shell (core dump).
    I have installed WFC hoping that would solve the problem but it didn't!
    I don't know what else to try, this did not happen under the beta
    release.
    Has any one else had this problem?
                    or
    Can provide help to target in on the problem.
Any help is appreciated!
--
Malcolm Cifuentes
(
 Nautronix LTD
 malcolm.cifuentes@nautronix.com.au
 PH  : +61-09-430-5900
 FAX : +61-09-430-5901
)
From rtp.co.uk!frs@rtp.co.uk  Thu Dec 12 02:24:56 1996
From: Francis Sreeves <frs@rtp.co.uk>
Date: Thu Dec 12 02:24:58 PST 1996
Subject: RE: windsh crashes when I ...
>Submitted-by malcolm.cifuentes@nautronix.com.au  Wed Dec 11 19:26:27 1996
>Submitted-by: malcolm.cifuentes@nautronix.com.au (Malcolm Cifuentes)
>
>Hi all,
>    OS: Solaris 2.51
>    Tornado: FCS 1.0 Power PC 1604
>
>    Has any one seen the following behaviour :-
>
>    When I execute the windsh command and connect to a target, as soon
>    as I execute :-
>        -> cplusXtorSet 1
>              or
>        -> cplusStratShow
>
>    Any following command crashes the shell (core dump).
>
>    I have installed WFC hoping that would solve the problem but it
didn't!
>
>    I don't know what else to try, this did not happen under the beta
>    release.
>
>    Has any one else had this problem?
>                    or
>    Can provide help to target in on the problem.
>
>Any help is appreciated!
>--
>Malcolm Cifuentes
This is a problem with the Solaris-hosted Tornado 1.0 FCS version only. The
previous beta version didn't have this problem. As a workaround use the
windsh.ex file from the beta version. The problem has been logged by WRS as
SPR#7503.
Francis
----------------------------------------------------------------
Francis Sreeves
Real-Time Products Ltd.                 e-mail:    frs@rtp.co.uk
Unit 8, Holt Court,                     tel:    +44 121 333 6955
Aston Science Park, Jennens Road,       fax:    +44 121 333 5433
Birmingham B7 4EJ. England.             web:       www.rtp.co.uk
----------------------------------------------------------------
From daemon@csg.lbl.gov  Thu Dec 12 04:00:17 1996
From: daemon@csg.lbl.gov
Date: Thu Dec 12 04:00:25 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec 12 04:00:15 PST 1996
        Subject: Re: system resource reclamation
        Subject: 5.11 vs 5.2 performance/differences
        Subject: SDLC and VxWorks and VME
        Subject: GNU libg++ under MIPS Tornado
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: system resource reclamation
Date: Fri, 06 Dec 1996 20:58:59 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: A customer of Pacific Bell Internet Services
Message-ID: <32A8F993.25C4@pacbell.net>
References: <32A8BC8E.4D6F@xtech.com>
Reply-To: dcaustin@pacbell.net
David P. Davis wrote:
>
> --
>
> Is there any support in VxWorks for per-task system resource allocation and recovery?
This feature (nice as it would be) is missing....
---------------------------
Newsgroups: comp.os.vxworks
Subject: 5.11 vs 5.2 performance/differences
Date: 11 Dec 1996 22:02:34 GMT
From: mcatalan@aol.com (MCatalan)
Organization: AOL http://www.aol.com
Message-ID: <19961211220200.RAA07086@ladder01.news.aol.com>
First I want to thank those who reponded to my question from a couple of
weeks ago on 'Optimization of vxWorks kernal; Specifically Sockets layer'.
 Basically, without overhauling our system completely, we are out of luck
in that area.
There was another thread here on 'Is your 5.2 X86 target SLOW?'.  The
question I post could be related to that.
Does anyone know why 5.2 is alot slower in many of it's system calls (for
instance, the 'signal()' call is TWICE as slow in 5.2 than 5.11)?  Is it
related to same problem the X86 board support package is having?  We are
using a Force 5 SPARC board and suspect a similar thing happening.
Thanks for any/all input,
Mike Catalanotti
Codem Systems, Inc.
catman@codem.com
http://www.codem.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: SDLC and VxWorks and VME
Date: 11 Dec 1996 14:32:37 -0500
From: lclarke@oasys.dt.navy.mil (Lee Clarke)
Organization: Carderock Division, NSWC, Bethesda, MD
Message-ID: <58n28lINN4d4@oasys.dt.navy.mil>
Reply-To: lclarke@oasys.dt.navy.mil (Lee Clarke)
I have an RS-485 interface with SDLC-protocol data on one end.
I have a VME-bus  system at another end.
The SDLC data bandwidth is 375K baud, 16 frames per second.
Can anyone help point to some hardware/software solution to
reading the SDLC data with a vme-bus cpu (MVME167 / MVME162-533A)
running VxWorks? I am looking for the I/O interface and card and
a VxWorks driver that I can use with the I/O card to read SDLC data.
I will write my own application to read the SDLC data, but I am looking
for an off-the-shelf XvWorks driver and (SDLC) I/O card. Industry Packs
and VME bus are probably my first choices.
Thanks.
Lee Clarke
lclarke@oasys.dt.navy.mil
---------------------------
Newsgroups: comp.os.vxworks
Subject: GNU libg++ under MIPS Tornado
Date: Wed, 11 Dec 1996 17:55:15 -0800
From: Larry Gadallah <gadallahl@aval.com>
Organization: Aval Communications
Message-ID: <32AF6603.7D0@aval.com>
References: <199612091621.KAA25507@frodo.eng.vmic.com>
Reply-To: gadallahl@aval.com
Has anyone had any luck using libg++ and container class prototypes with
Tornado?  I haven't even been able to determine if libg++ is included as
part of the Tornado product or whether I need to install it myself.
Has anyone had any experience with these components?
Thanks in advance,
Larry Gadallah
Aval Communications
gadallahl@aval.com
---------------------------
End of New-News digest
**********************
From YFILLION@spar.ca  Thu Dec 12 05:29:02 1996
From: Yvan Fillion <YFILLION@spar.ca>
Date: Thu Dec 12 05:29:04 PST 1996
Subject:  unsubscribe
From 75353.1150@CompuServe.COM  Thu Dec 12 05:58:30 1996
From: "William G.St.Clair" <75353.1150@CompuServe.COM>
Date: Thu Dec 12 05:58:31 PST 1996
Subject: VxWorks Virus Detection
Hello, world:
I need to determine the state of the art of virsus detection/scanning technology
on the VxWorks platform.
Should I start rubbing two sticks together?
Bill St.Clair
Venus Telecom,
75353.1150@compuserve.com
410 923-3349
From "VCF::SKO"@DELPHI.DASD.HONEYWELL.COM  Thu Dec 12 07:53:17 1996
From: "VCF::SKO"@ASTRO.DASD.HONEYWELL.COM
Date: Thu Dec 12 07:53:19 PST 1996
xwexplo@lbl.gov
X-Vmsmail-To: VCF::SMTP%"vxwexplo@lbl.gov"
Message-Id: <961212085227.2a201e7b@ASTRO.DASD.HONEYWELL.COM>
Subject: RE: unsubscribe rate and e-mail problems
The unsubscribing rate seems to be much higher after e-mail problems that
produce garbage mails.
Shang
From bf@kayser-threde.de  Fri Dec 13 02:44:48 1996
From: Florian Bittner <bf@kayser-threde.de>
Date: Fri Dec 13 02:44:50 PST 1996
Subject: PCI/VME mapping on MVME1604
Hello,
we are migrating from mvme167=B4s to mvme1604=B4s. What I don=B4t=
 understand, is
the memory mapping of these PPC boards. We have hardware at 0x60000000 to
0x603ffff,
at c0000000 to cfffffff and some other places. The target.txt and config.h
files mention that the VME window is 256 MB. Does this mean anything has to
reside in
a predefined area, so all hardware must be changed ?
Greetings from Munich,
Merry Xmas
Florian Bittner                 Software Engineer            __  __  =20
Kayser-Threde GmbH              Tel +49 89 78720 383        |  |/  / =20
Perchtingerstr.3                Fax +49 89 78720 398        | =3D=3D=3D=3D< =
 =20
81379 Munich                    Germany                     |__|\__\ =20
From 100067.355@CompuServe.COM  Fri Dec 13 03:24:20 1996
From: Philippe Weber <100067.355@CompuServe.COM>
Date: Fri Dec 13 03:24:22 PST 1996
Subject: SBus graphics
Hi friends,
I'm looking for an SBus graphics card with VxWorks driver/library. Is there
anything available out there ?
*************************************
* Philippe WEBER                    *
* THEMIS COMPUTER                   *
* 1, rue des Essarts                *
* 38610 GIERES, FRANCE              *
* Voice : +33 (0)476 59 60 46       *
* Fax   : +33 (0)476 63 00 30       *
* E-mail: phil@themis.com           *
*************************************
From daemon@csg.lbl.gov  Fri Dec 13 04:00:20 1996
From: daemon@csg.lbl.gov
Date: Fri Dec 13 04:00:22 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 13 04:00:18 PST 1996
        Subject: packing structures
        Subject: Two systems, One IP
        Subject: Core dump in VxWorks
        Subject: FORCE 10 50mhz
        Subject: mv1604 comments
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: packing structures
Date: Wed, 11 Dec 1996 21:35:55 GMT
From: Bob Marino <ram@mr.picker.com>
Organization: Picker International, Inc.
Message-ID: <32AF293B.167E@mr.picker.com>
Sender: news@picker.com
Is there some attribute that I can use when declaring a structure
which would allow all of its fields to be packed together, i.e, no
slack space in between fields?  I am aware of the -fpack-struct
option that I can specify to the GNU C compiler, but I was wondering
if I could do it on a structure by structure basis.
- --
Roberto "Bob" Marino                          Picker International, Inc.
principal engineer                            5500 Avion Park Dr.
NMR division                                  Highland Hts, OH 44143
---------------------------
Newsgroups: comp.os.vxworks
Subject: Two systems, One IP
Date: 4 Dec 1996 23:17:28 GMT
From: ashrafis@nt.com (Siamak Razzaghe-Ashrafi)
Organization: Northern Telecom Inc., Mission Park
Message-ID: <5850q8$r9d@nrchh52.rich.nt.com>
Can I have two systems running one IP.   The first will ARP it's IP
the second will not and just listen on the net.
When the first is "out" the second will pickup the packets. and vise-versa.
Only one system will talk at a time but both will listen.
If I do not consider Ethernet differences (I can make the systems have the same
Ethernet address)
Will this work.  Where can I get info on how this is done.
I have heard Tandem has machines that have the same IP.  An application
talking to an IP will be talking to several machines but only one IP.
I have heard Hatchi has multiple critical Sun workstations that have
one IP and an application does not know if any of the Suns go down.
Any Ideas on how this is done?
Thanks for any help
ashrafis@nt.com
- --
Build any hardware, Program any software           \   Email : ashrafis@nt.com
Speek any language, Understand any Thought          \   Phone : 565 - 7070
Climb any mountain, Surf any Ocean, Ride any road    \   Address : not for public display
Love, Praise and Fear the Lord thy God in all things  \
---------------------------
Newsgroups: comp.os.vxworks
Subject: Core dump in VxWorks
Date: Thu, 12 Dec 1996 14:40:22 -0500
From: Roger Cruz <cruz@xyplex.com>
Organization: Whittaker Xyplex
Message-ID: <32B05FA6.31DFF4F5@xyplex.com>
I'm searching for a way to have VxWorks create a core dump of the
application running on the target system which can then be used with the
tornado development tools to do debugging.  This approach is similar to
what unix provides: 1) the OS creates a core file, and 2) the debugging
tool (ie, dbx) knows how to read this file and print out useful
information.  Any ideas?  Has anybody done any time of dumping or
written tools to analyzed a memory dump?
   Thanks!
- --
Roger Cruz         cruz@xyplex.com, rcruz@xyplex.com, rrc@xyplex.com
Whittaker Xyplex                                    w: 508-952-4783
295 Foster Street                                    f: 508-952-5772
Littleton, MA 01460
---------------------------
Newsgroups: comp.os.vxworks
Subject: FORCE 10 50mhz
Date: Thu, 12 Dec 1996 20:03:49 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: A customer of Pacific Bell Internet Services
Message-ID: <32B0D5A5.2A08@pacbell.net>
Reply-To: dcaustin@pacbell.net
Any FORCE 10 50mhz cards for sale?
Duane Austin
email:	dcaustin@pacbell.net
---------------------------
Newsgroups: comp.os.vxworks
Subject: mv1604 comments
Date: Thu, 12 Dec 1996 20:09:45 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: A customer of Pacific Bell Internet Services
Message-ID: <32B0D709.25C6@pacbell.net>
Reply-To: dcaustin@pacbell.net
I'm considering migrating to mv1604.  Please tell me, have you had any
problems with this card or the BSP?
Duane Austin
email:	dcaustin@pacbell.net
---------------------------
End of New-News digest
**********************
From cgrames@mdc.com  Fri Dec 13 07:06:37 1996
From: Charlie Grames <cgrames@mdc.com>
Date: Fri Dec 13 07:06:39 PST 1996
Subject:  Re: PCI/VME mapping on MVME1604
By default, VxWorks maps all of VME A32 space into a single window.  As delivered, this window is
only 16 MB.  However, it can be increased to 256 MB by changing the constants
MASTER_MEM_BUS_A32 and MASTER_MEM_A32_SIZE in config.h.  If you want more than one
VME window and/or more than 256 MB of A32 space, you need to modify the LBSAR register
definitions in sysLib.c.  Refer to the MVME1604 Single Board Computer Programmer's Reference
Guide from Motorola.
For whatever reason, VxWorks uses two of the LBSAR registers to map A24 and A16 space.  The
VMEchip2 already does this, so these mappings are redundant.  I have not tried to do anything in
A24 or A16 space without these mappings, however.
If you are planing to map large regions of the VMEbus, you may also want to consider using the
BAT registers to do so.  Using the page table to map 256 MB consumes an additional 2 MB of
local memory for page table entries.
Good luck!
Charlie Grames
McDonnell Douglas Training & Support Systems
(314) 233-1956
CGrames@mdc.com
From Chris.Pinkard@AGAI.COM  Fri Dec 13 08:26:46 1996
From: Christopher Pinkard <Chris.Pinkard@AGAI.COM>
Date: Fri Dec 13 08:26:49 PST 1996
Subject: RE: packing structures
I'm unable to do it using Tornado/gnu NT host and Moto mvme
target.  I've tried every combination of pragma's and
__attribute__ type compiler directives to no avail.
all the best,
chris p.
---------------------------------------------------------------
		May all your goats be free of fleas
		and may your camels never spit.
---------------------------------------------------------------
Summary #20335
AUTHOR: jerald
-------------------------------------------------------
DATE: Jan  4 1995  1:52PM
Product: 5.1.1
Host:    Sun4
Board:   mv167
Board:
                           Summary of TSR # 20335
  |
TITLE: Padding of structs in gnu C.
KEYWORDS: gnu c padding structs
SYSTEM: Gnu 2.2.3.1
SYMPTOM(S): For example:
    typedef struct {
       char element[5];
    }STRUCTURE;
    sizeof(STRUCTURE) returns 6.
RESOLUTION:  This is not a bug - This is normal behaviour of the gnu C
compiler.  There are no switches or compiler options to "pack"
structures.
(Note:  The intel i960 compiler supports a pragma pack - This pragma
does
not exist on 68k 2.2.3.1 of the gnu compiler)
This is due to the fact that the ANSI specifications of C declare that
these
structures are implementation dependant.
The following is email from David Wilner - V.P. of Engineering and a
WindRiver founder:
A customer writes:
> I'd like to raise an issue about how most people represent hardware in
> device drivers under VxWorks.  It seems that the prevailing method is:
>
> #define BOARD_ADDRESS 0x12345678
>
> #define BOARD_REG_1   (char *) (BOARD_ADDRESS + 0x00)
...
> >From Unix drivers, a more common way is to declare a struct which is
> overlayed on the physical address space:
>
> struct        board {
>       char    reg_1;
>
> This second method seems cleaner to me.  Why does the first method prevail?
It's been a subject of discussion for years here at WRS.  I agree that
defining hardware structures as C structures is appealing from a coding
point of view, and yes, many Unix drivers are written that way.  And I'd
like to go further and use bit fields and enum types for values within
registers.  However, there are some good reasons for using the macro
technique instead.
First, as someone else pointed out, the exact representation of C
structures
in hardware is completely unspecified by the C language.  The compiler
is allowed to pad and align structure members in various ways.  This is
to allow the compiler to organize for certain hardware limitations or
optimizations (i.e. longs may have to be 4 byte aligned, or at least
be faster to access).  I'm not even sure the compiler is required to
keep the members in the same order as they're declared.
If you make assumptions about the layout of C data structures in memory,
you may get away with it with some or most compilers on some or most
architectures, but you're not writing truly portable C code.
One of the biggest failings of C as a system implementation language,
in my opinion, is the lack of any construct that would allow the
programmer more precise control over the actual storage layout of
structures.  *Some* compilers have flags that affect the storage
layout of structures, and some compilers have non-standard
keywords (i.e. "packed") that suppress padding/alignment.  But since
VxWorks has to work with several compilers, those really aren't options
for us.  Even the ANSI C standard didn't address this issue, to my
dismay.
The next problem is that in the many years of porting VxWorks to many
hardware platforms, we've encountered all kinds of screwy addressing
arrangements.  One particularly common problem is that some hardware
vendors find it convenient to not hook up the least-significant address
bit, A0, of the CPU bus to the least-significant bit of the peripheral
chip.  Instead, A1, or even A2, is connected to the lsb of the
peripheral.
This means that a chip's 1 byte registers may appear at 2 or 4 byte
intervals (i.e. every even or odd address).  We've tried to write
generic
headers and drivers that can be reused in many hardware environments, so
in some of our headers we've added an INTERVAL parameter to the macros.
For
example, the header for the MFP (MultiFunction Peripheral chip),
m68901.h,
looks like:
    /* m68901.h - Motorola MC68901 MFP (Multi-Function Peripheral) */
    #define MFP_ADRS(base,reg)   ((char *)
(base+(reg*MFP_REG_ADDR_INTERVAL)))
    /* register definitions */
    #define MFP_GPIP(base)      MFP_ADRS(base,0x00)     /* Data I/O port
*/
    #define MFP_AER(base)       MFP_ADRS(base,0x01)     /* active edge
reg*/
    #define MFP_DDR(base)       MFP_ADRS(base,0x02)     /* data
direction reg */
    ... more registers ...
Thus by defining MFP_REG_ADDR_INTERVAL to be 1, 2, or 4, you can compile
a driver to access the MFP registers at 1, 2, or 4 byte intervals, to
accommodate different hardware environments.  This is pretty ugly to
try to accommodate in the C structure method.
But wait, there's more!  When we began porting to other CPU
architectures
we ran into a few cases where there were byte order issues, where the
peripheral chip's registers don't even end up in the same order!
This applies to board-level peripherals as well as chip-level.  It would
be a pretty hairy macro to untangle that one.
Furthermore, you're absolutely right that the hardware addresses should
not be compiled into the code.  We would love to get to the point where
we could have one single object module for any given peripheral chip
or board, and be able to configure it externally at run-time by calling
an initialization routine with appropriate parameters.  These parameters
would have to specify not only the base address but perhaps the
"interval"
and byte order mentioned above.
Towards this end, we've used a somewhat different technique in the SCSI
drivers we've provided over the last year.  In the SCSI drivers, we keep
a data structure for each SCSI device that contains not just the base
address of the SCSI chip, but the addresses of EACH register on the SCSI
chip.  Accesses to read/write the registers all go indirect through
these
pointers.  Thus an initialization routine can easily establish any
necessary
mapping of the chips registers.  The cost, of course, is that every
access
requires an extra memory fetch for the indirection (deemed not too bad
in the case of a low frequency device like SCSI).  So for example, the
header for the Fujitsu MB87030 SCSI controller chip (SPC) contains:
    /* mb87030.h - Fujitsu MB87030 SPC (SCSI Protocol Controller) header
*/
    typedef struct                      /* MB_87030_SCSI_CTRL - Fujitsu
mb87030
                                           SCSI controller info */
        {
        ... (other device specific values)...
        UINT8 *pBdidReg;                /* ptr bus device ID reg.*/
        UINT8 *pSctlReg;                /* ptr control reg. */
        UINT8 *pScmdReg;                /* ptr command reg. */
        UINT8 *pTmodReg;                /* ptr transfer mode reg. */
        ... (20 more registers) ...
        } MB_87030_SCSI_CTRL;
Then to use the chip you call mb87030CtrlCreate() and provide the base
address and register interval.  This routine sets up all the register
addresses in MB_87030_SCSI_CTRL structure.  (Note: for clarity I deleted
all the extraneous stuff from the routine.):
    MB_87030_SCSI_CTRL *mb87030CtrlCreate (spcBaseAdrs, regOffset, ...
        UINT8 *spcBaseAdrs;       /* base address of the SPC */
        int regOffset;            /* address offset between consecutive
regs. */
        ...
        {
        MB_87030_SCSI_CTRL *pSpc;  /* ptr to SPC info */
        pSpc = (MB_87030_SCSI_CTRL *) malloc (sizeof
(MB_87030_SCSI_CTRL));
        pSpc->pBdidReg = spcBaseAdrs;
        pSpc->pSctlReg = spcBaseAdrs + (0x1 * regOffset);
        pSpc->pScmdReg = spcBaseAdrs + (0x2 * regOffset);
        pSpc->pTmodReg = spcBaseAdrs + (0x3 * regOffset);
        ... (20 more registers) ...
        return (pSpc);
        }
Then all access to the registers go indirect through these pointers:
    *pSpc->pSctlReg |= SPC_SCTL_INT_ENBL;
------------------
David Wilner
Wind River Systems
From bawilson@llnl.gov  Fri Dec 13 11:06:50 1996
From: Bruce Wilson <bawilson@llnl.gov>
Date: Fri Dec 13 11:06:52 PST 1996
Subject: Re: PCI/VME mapping on MVME1604
Hi,
	We also had a VME device residing at 0x60000000, and found that the
mv1603 processor's vmeChip2 has an address mapping register AM4, which
supports translation of the map.  That way we didn't have to change our VME
board address, and yet still we could access it from within the processor's
MASTER VME window (0xd8000000 - 0xd8ffffff by default). It's probably much
the same for the 1604.  As shipped, VxWorks 5.3 FCS does not enable that
register, so we added the following code to sysLib.c:
*VMECHIP2_LBSAR4	= ( 0x08ff0000  |  0x0800 );
*VMECHIP2_LBSAR		|= (LBSAR4_AM_EXT_USR_DATA  |  LBASR4_D32 );
*VMECHIP2_LBTVCR	|= LBTVCR_EN4;
*VMECHIP2_LBSATR1	= (0x60000000  |  0xff00);	/* set 8 upper bits */
Note that there are two 16-bit pieces in LBSAR4 and LBSATR1, which is why
they're written with the OR operation rather than simply 0x08ff8000, which
is equivalent.  It's a reminder that there are two pieces.
The mapping set up here gives the following:
processor addresses  (0xd8000000 - 0xd8ffffff) map onto the
VME bus  addresses  (0x60000000 - 0x60ffffff).
We also changed the AM3 mapping from the default start of 0x0 to
0x09000000, with the following line:
	*VMECHIP2_LBSAR3  =  (0x7fff0000  |  0x0900);
The default size for the MASTER_MEM_A32_SIZE, in VxWorks 5.3, is 16 MB,  so
we increased that to 32 MB ( 16 MB mapped up to 0x60000000  and  16 MB
straight-through mapping).
The document that made helped us the most in making these changes was
  "MVME1603/MVME1604 Single Board Computer Programmer's Reference Guide",
by the Motorola Computer Group.  The publication number is listed as
V1600-1A/PG.
--Bruce Wilson
University of California LLNL
Livermore, Calif.
>Submitted-by bf@kayser-threde.de  Fri Dec 13 02:44:48 1996
>Submitted-by: Florian Bittner <bf@kayser-threde.de>
>
>Hello,
>we are migrating from mvme167=B4s to mvme1604=B4s. What I don=B4t=
> understand, is
>the memory mapping of these PPC boards. We have hardware at 0x60000000 to
>0x603ffff,
>at c0000000 to cfffffff and some other places. The target.txt and config.h
>files mention that the VME window is 256 MB. Does this mean anything has to
>reside in
>a predefined area, so all hardware must be changed ?
>
>Greetings from Munich,
>Merry Xmas
>
>
>Florian Bittner                 Software Engineer            __  __  =20
>Kayser-Threde GmbH              Tel +49 89 78720 383        |  |/  / =20
>Perchtingerstr.3                Fax +49 89 78720 398        | =3D=3D=3D=3D< =
> =20
>81379 Munich                    Germany                     |__|\__\ =20
From bawilson@llnl.gov  Fri Dec 13 12:07:56 1996
From: Bruce Wilson <bawilson@llnl.gov>
Date: Fri Dec 13 12:07:58 PST 1996
Subject: Re: PCI/VME mapping on MVME1604
Hi,
	In my explanation about using the OR function to help remember that
there are two pieces in the register, I noticed a typo.  It should say that
0x08fff0800 is equivalent to (0x08ff0000  | 0x0800).
--Bruce Wilson          (bawilson@llnl.gov)
University of California LLNL
Livermore, Calif.
From daemon@csg.lbl.gov  Sat Dec 14 04:00:19 1996
From: daemon@csg.lbl.gov
Date: Sat Dec 14 04:00:21 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec 14 04:00:16 PST 1996
        Subject: Force 5CE MMU help?
        Subject: Trapping rpc errors
        Subject: VxWorks/MS-Windows compatible database ???
        Subject: Re: problems with __attribute__ ((packed))
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Force 5CE MMU help?
Date: 11 Dec 1996 17:51:17 -0800
From: cro@chandra.caltech.edu (John Cromer)
Organization: Caltech Astronomy Department
Message-ID: <58noel$h2v@chandra.caltech.edu>
Hello, fellow vxWorks folk,
Does anyone here have any experience with the Force 5CE and it's VxWorks
BSP?
I have a very simple system, this CPU board in slot 0 and a Chrislin
CI-VME40 64Mb memory board.  I can't seem to read the VME memory
from VxWorks.  I have a fairly superficial understanding of the way
this is supposed to work, and that is, keeping the BSP default defines
in config.h and ss5.h, I should be able to do A32 accesses through
addresses starting at 0x60000000, which should correspond to VME
address 0x10000000.  When I try this, I either get a failure of
a vxWorks function (vxMemProbe) or a "data access exception."
As an aside, A16 accesses work ok.  I can read the Chrislin board's
CSR at 0x6fff0000.
Anyone else seen anything like this or have any SPARC/VxWorks
wisdom they would like to impart?
John
cro@astro.caltech.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: Trapping rpc errors
Date: 13 Dec 1996 10:45:43 GMT
From: "Robert Humphris" <rhumphris@csl.co.uk>
Organization: Concept Systems Ltd, Edinburgh, UK
Message-ID: <01bbe8e2$b310dba0$973482c2@irvine.csl.co.uk>
We are using rpc's between our vxWorks system, and a Unix
box.
When the program on the Unix box, that acts as a data server
is shut down there is of course an exception generated in by
the rpc library.
What I would like to do is add a hook, so that in the case of
a fatal exception, I can shut down as many tasks as I wish etc.
and thus have a cleaner more fault tollerant system.
Anyone have any clues as to how I may manage this without
having a deamon running and taking up my valuable processor
time?
Thanks
Rob Humphris
Concept System Ltd.
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks/MS-Windows compatible database ???
Date: 13 Dec 1996 11:31:00 GMT
From: "Tapani Leppanen" <leppanen_tapani@pine.sahako.fi>
Organization: Heinolan Sahakoneet Oy
Message-ID: <01bbe8e9$12ad6c80$20ce9dc2@tle.hla>
Hi,
Is there database product for vxworks that would be combatible with Win95 /
Borland Delphi
DataBaseEngine. What I need is to be able to read/write data to/from
database with
MVME162 based vxworks machine. Database would be in my PC, and then I could
manage the database from Delphi application.
Vxworks application would need to handle the byte-order stuff etc.
Any suggestions ??
Best regards,
Tapani
- --
Tapani Leppdnen				|	Heinola Sawmill Machinery Inc
phone +358 3 8484275 				|  	PL 24
fax +358 3 8484303				|	18100 HEINOLA
EMail: leppanen_tapani@troponor.heinola.fi	|	FINLAND
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: problems with __attribute__ ((packed))
Date: 13 Dec 1996 14:51:10 GMT
From: tsg@stout.netlink.com ()
Organization: Netlink, Inc.
Message-ID: <58rqgu$sfc@news.netlink.com>
References: <8411AD3201660C00@mail.madge.com>
On Tue, 10 Dec 96 7:38:10 +0200, Adi Molkho LAN-Tel <amolkho@madge.com> wrote:
>Chris
>I have faced this kind of problems
>you must add before all of the structures and unions declarations :
>
>#pragma align 1
>
>#pragma pack 1
>
>and in the end of the declarations
>
>#pragma pack 0
>#pragma align 0
>
>although it is not written in the Users Guide
>
>Adi Molkho
>
I didn't see the original post, but unfortunately this is unsupported in the
new Tornado toolchain (i960 cc960 gcc version 2.6-95q2, for what it's worth).
I think WRS decided to go with the Cygnus maintained GNU compiler and Cygnus
doesn't feel that using #pragma's is an acceptable solution (someone correct
me if I'm wrong or they've since changed their mind).
Todd Goodman
---------------------------
End of New-News digest
**********************
From MikeMcQuade@connect.com  Sat Dec 14 11:05:13 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Sat Dec 14 11:05:15 PST 1996
Subject: Fast Ethernet PMC performance test results.
Someone was asking about network performance a while back, I recently ran
some tests on a 100 Base-Tx PMC card and a Motorola MVME-1604 (133Mhz) board,
here are my results.
Your mileage may vary.
I used the VxWorks TCP blaster and blastee programs, these programs open up
a TCP socket and shove data through as fast as they can, after a one minute
period, they total muber of bytes transfered is reported, along with the
bytes / second calculation. I ran each test three times, the result below
are the average of three runs.
The PMC card is a RNS 2350, using a Ross Microsystems driver,
in fact the card and driver were purchased from Ross Microsystems,
Im very pleased with the support that they have provided, they
can be reached at:
                        rmi@qed.net
The Host is a HP-UX C-110, here we are using a Phobos Corp EISA
card, the HP-UX machine is running HP-UX 9.07, Phobos can be reached
at:
                        sales@phoboscorp.com
                        (im guessing here, we bought the card from a rep)
                        szick@mdlcorp.com - rep.
----- Test Results -----
Target:
VxWorks MVME-1604 (133Mhz)
Ross Microsystem Vx2300 driver, RNS 2350 PMC card.
Target running vxBlaster port: 7000 size: 8192 length: 16000
Host:
HP C-110, running 9.07 HP-UX
Phobos Corp 100Base-tx EISA card
Host running blastee port: 7000 size: 8192 length: 16000
at  10Mbit, half duplex, performance = 1.07 Mbytes / Second
at 100Mbit, half duplex, performance = 7.12 Mbytes / Second
Tests were conducted on an isolated network,
ie: I had a crossover cat 5 cable from the Host to the Target.
MikeMcQuade@connect.com
From Chris.Pinkard@AGAI.COM  Mon Dec 16 11:18:46 1996
From: Christopher Pinkard <Chris.Pinkard@AGAI.COM>
Date: Mon Dec 16 11:18:51 PST 1996
Subject: debugging multiple tasks
Fellow Travelers,
It's been 6 years since I worked with VxWorks at the MR
group of GE Medical Systems.  Debugging used to be easier,
but I don't remember what tools we were using.  The last
three years I've been working in PSOS on Moto MVME boards
and using Microtec Research compilers and their XRay
debugger.
Now, I'm back in VxWorks with Moto MVME boards using the
"highly acclaimed" (by whom I don't know) Tornado develop-
ment environment.  This is so far this biggest single hit
to my productivity I have ever encountered.  My colleagues
and I have a list of a dozen grievances about using Tornado
ranging from very irritating to user vicious, for example
the editor, which only emulates Notepad (with colors).
The overriding problem that is not even on the list because
it is so fundamental is the ability to easily debug several
concurrent tasks.  This was so easy using XRay, I had
forgotten it was an issue.  Tornado does not appear to be
a giant leap forward in this most basic need for a real-
time multitasking development tool.
The first line of support at WRS (as far as I have been
able to penetrate) has not given any satisfactory answers.
I want to do something simple, like put a breakpoint in a
background task, after it wakes up from pending on a message
queue.  Then I want to step through the task that sends the
message, and have the background task break when it receives
the message.
WRS suggests that I detach from the first task and attach
to the second task to set the breakpoint.  Then detach from
the second one and attach back to the first one.  However
detaching seems to wipe out all breakpoints, and it will
put the task on the ready list, so it takes off.  Their
next suggestion was to put some debugging semaphor in the
first task, and have it pend just before it sent the message.
Then detach from it and attach to the background task.
Put a breakpoint where the message will be caught, then
send the semaphore from the shell command line.  Not what
I would call a "productivity enhancing" solution for the
general case.
Our program manager was persuaded to go with Tornado, and
we have NT development systems with VxWorks Motorolo VME
targets.  This may limit the tools available.  If anyone
can help with the names of some better debugging tools for
this setup, we would greatly appreciate it.  If anyone knows
how it can be done using Tornado, even better.
many thanks,
Chris Pinkard
---------------------------------------------------------------
		May all your goats be free of fleas
		and may your camels never spit.
---------------------------------------------------------------
From bemills@sandia.gov  Mon Dec 16 13:30:19 1996
From: bemills@sandia.gov (Barbara Mills)
Date: Mon Dec 16 13:30:21 PST 1996
Subject: Re: debugging multiple tasks
This may not be a "good" solution either, but you might try creating a
vxWorks 5.2-style kernel so that you could set breakpoints in both
the (now target-resident) shell and the crosswind debugger.   This
"feature" is not available with the Tornado shell.
I don't remember whether or not I tried to bring up a separate instance
of crosswind for each task.  I do know that I was able to control the
execution of both tasks and debug the one I was interested in.  I was
unsuccessful at even controlling both tasks using the full 5.3 environment.
Barbara Mills
From dalsup@tinygee.dasd.honeywell.com  Mon Dec 16 15:00:51 1996
From: Dave Alsup <dalsup@tinygee.dasd.honeywell.com>
Date: Mon Dec 16 15:00:54 PST 1996
Subject: ACW on the I960
I am working on a custom I960MC board using vxWorks 5.2.
Can anyone give me a hint on how to define the arithmetic control word
in the process control block (PCB) of a task at task creation?  I would
like to mask floating point underflow faults in certain tasks but I have
only managed to figure out how to do it in the currently executing task
(i.e. call an assembly routine just prior to the math in question).  Is
there a default PCB somewhere that I could monkey with?
Thanks for any help
Dave Alsup
dalsup@dasd.honeywell.com
From alon@radcom.co.il  Tue Dec 17 05:56:46 1996
From: "Alon Ecker" <alon@radcom.co.il>
Date: Tue Dec 17 05:56:49 PST 1996
Subject: Opinion about Win95 Tornado
Hi,
I would like to hear from users of Tornado under Win95.
1. I like to know if the Tornado is stable and satisfactory.
2. If there are problems that you have faced. I would also like to
know.
3. Further I would like to get an opinion from users of the Tornado for
the i960 series who work with C++ under the Win95  environment.
Alon Ecker.
Software Engineer.
Radcom Ltd.
12, Hanechoshet st.
Tel-Aviv 69710
Israel
Tel:    +972-3-6455183        Fax:    +972-3-6474681
E-Mail: alon@radcom.co.il
Home Page: www.radcom-inc.com
From alon@radcom.co.il  Tue Dec 17 06:03:37 1996
From: "Alon Ecker" <alon@radcom.co.il>
Date: Tue Dec 17 06:03:40 PST 1996
Subject: Opinion about Win95 Tornado
------- Forwarded Message Follows -------
Hi,
I would like to hear from users of Tornado under Win95.
1. I like to know if the Tornado is stable and satisfactory.
2. If there are problems that you have faced. I would also like to
know.
3. Further I would like to get an opinion from users of the Tornado for
the i960 series who work with C++ under the Win95  environment.
Alon Ecker.
Software Engineer.
Radcom Ltd.
12, Hanechoshet st.
Tel-Aviv 69710
Israel
Tel:    +972-3-6455183        Fax:    +972-3-6474681
E-Mail: alon@radcom.co.il
Home Page: www.radcom-inc.com
From wbrown@csg.lbl.gov  Tue Dec 17 07:19:20 1996
From: wbrown@csg.lbl.gov (Bill Brown)
Date: Tue Dec 17 07:19:22 PST 1996
Subject: This is a test
of the vxWorks exploder.  Please excuse the noise.
-bill
Duty "Keeper of the List"
From Ilia.Maller@ecitele.com  Tue Dec 17 07:55:35 1996
From: Ilia Maller <Ilia.Maller@ecitele.com>
Date: Tue Dec 17 07:55:38 PST 1996
Subject: RE: debugging multiple tasks
Chris,
You should run two instances of CrossWind.
In the first one you should attach to the 'receiver' task and set
breakpoint where the task receives message. In the second instance you
attach to the 'sender' task and step through it, watching how it sends the
message. The first task will break when it receives the message.
There is only one problem (in this case) on you NT version of Tornado
tools. From unknown reason Tornado doesn't allow to create the second
instance of CrossWind. So you have to run the second instance of Tornado.
On Unix this works fine, and I can't understand why they restrict it on
Windows.
Good luck,
Ilia Maller
Software Technologies Group
E.C.I. Telecom
Tel: +972-3-9266843
Fax: +972-3-9266870
ilia@ecitele.com
From syed@sunriver.com  Tue Dec 17 08:29:08 1996
From: ""Syed Naseem"" <syed@sunriver.com>
Date: Tue Dec 17 08:29:10 PST 1996
Subject: unsubscribe
From dleviner@HiWAAY.net  Tue Dec 17 09:03:29 1996
From: David Leviner <dleviner@HiWAAY.net>
Date: Tue Dec 17 09:03:31 PST 1996
Subject: FLASH file system support?
Hi all,
I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH (Intel
28F016 chipset) and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM
for the embedded application and 3 MBytes of FLASH is to be used as a "FLASH disk" for
storing his applications. I am running the text section of VxWorks (instructions,
constants,etc.) in the first 1MByte of FLASH and the data section of VxWorks (i.e., C
variables) in DRAM.
Does anyone know of a VxWorks FLASH file system driver that can be used for this type of
BSP? And does anyone know of a device driver with read/write/erase, etc. support for the
Intel 28F016 FLASH device.
Thanks for the advice.
--
David Leviner
Systems Engineer
Chandler/May, Inc. (CMI)
125 West Park Loop
Huntsville, AL  35806
(205)722-0175
(205)722-0144 (fax)
dleviner@HiWAAY.net
**********
From daemon@csg.lbl.gov  Wed Dec 18 04:00:43 1996
From: daemon@csg.lbl.gov
Date: Wed Dec 18 04:00:45 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec 18 04:00:41 PST 1996
        Subject: !    MASS POST  Was Here                                                                                                 (rynnot)
        Subject: Bulk Mail Software
        Subject: SCSI disks
        Subject: Re: Background write to disk
        Subject: Re: [Q] Why is low 1 MB noncacheable on mv160
        Subject: Re: SCSI disk problems?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: !    MASS POST  Was Here                                                                                                 (rynnot)
Date: Sat, 14 Dec 96 12:16:36 GMT
From: Ones-And-Zeros@Prodigy.net
Organization: Ones And Zeros, Corp.
Message-ID: <58u5r6$7a1m@usenet1w.prodigy.net>
MASS POST, by Ones And Zeros, will let you post to as many newsgroups as you
want!
To find out more about this exciting new program, visit a business newsgroup.
(This ad was sent to thousands of newsgroups!)
(arivqf)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Bulk Mail Software
Date: 18 Dec 1996 03:18:49 GMT
From: jorge@mailloop.com
Organization: Mailloop Software
Message-ID: <597nqp$k75@crawler.dlc.fi>
Mailloop is bulk mailing software that will revolutionize how
people advertise on the internet...
See what all the fuss is about:
http://www.mailloop.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: SCSI disks
Date: Fri, 13 Dec 1996 11:51:56 -0500
From: Harish Nandyala <nandyala@crd.ge.com>
Organization: Wipro GE Medical Systems
Message-ID: <32B189AC.1E5F@crd.ge.com>
Reply-To: nandyala@crd.ge.com
Hi,
	I have a HP Vectra as my target with a SCSI disk. I am
unable to configure it because the sysScsiInit routine is missing
in the sysLib.
How do I do the system Initialization for the SCSI card ...
Any pointers help.. anything at all will be greatly appreciated
regards
Harish
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Background write to disk
Date: Wed, 18 Dec 1996 02:05:06 GMT
From: brucew@phoenix.net (Bruce)
Organization: BranPaul Systems
Message-ID: <597jq1$agv$4@uhura.phoenix.net>
References: <59633p$104@news.ed.ray.com>
In comp.os.vxworks
milesm@ed.ray.com (Michael Miles) wrote:
> The problem is that this interferes  with the real time
>operation of our system (of course).
We ran into the same problem.  The only way we fixed it was
with a 5 meg SRAM disk.  If you hear of a solution, I'd like
to hear it also.
Bruce
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: [Q] Why is low 1 MB noncacheable on mv160
Date: 18 Dec 1996 02:24:07 GMT
From: bnorristx@aol.com (BNorrisTx)
Organization: AOL http://www.aol.com
Message-ID: <19961218022300.VAA17994@ladder01.news.aol.com>
References: <32A81B14.41C6@mr.picker.com>
I am not familiar with the mv160; however, the low 1 meg is normally
marked as non cacheable if you are useing one of the Motorola MC68040
series of processors.
If you are supporting an ethernet on board, the buffers must be
noncachable or you may get cache coherency problems on the data being
serviced. Normally the O.S. will recognize that you do not have the
noncacheable memory and malloc it in such a way that the RAM is marked
noncachable at that time, but as usuall it is always safe to set aside
some noncacheable memory for these purposes from the onset of the board
design. The base address of the noncacheable region is then provided to
the ethernet driver when it is called (as an arg). So, if your board
supports ethernet, the buffers most likely require noncacheable RAM.
B.T. Norris
Software Analyst
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: SCSI disk problems?
Date: Tue, 17 Dec 1996 16:05:04 GMT
From: bryan@sgl.ists.ca (Bryan Feir)
Organization: Institute for Space and Terrestrial Science
Message-ID: <bryan.850838704@s2.sgl.ists.ca>
References: <58ovv7$6kh@news.res.ray.com>
Sender: news@newshub.ists.ca
milesm@tif531.ed.ray.com (Michael Miles) writes:
>Has anyone had unreliable performance from the use of a SEAGATE
>"Barracuda" or other SCSI drives in their system with vxWorks?  We have
>an mvme167 based system with about a dozen boards which locks up
>randomly.  It seems to be linked to the SCSI driver.  The vendor believes
>it is a problem with the SEAGATE drive.  Has anyone experienced anything
>like this?
   Given the delay in our newsfeed, someone's likely already answered
this, but anyway...
   We've been using the Seagate Barracuda in a VxWorks-based file server
system here where we needed at least 2 megabytes/second throughput from
the drive, and there's a fairly constant update scan running over it.
The CPU card is also an MVME167, and we're using VxWorks 5.1 still.  We've
had no problems with it, even under that heavy load.
   A few things you should look at: first, make sure you're using the most
up to date SCSI driver; there were some problems with an early version
of that under VxWorks 5.1.  There was also the VME test-and-set bug.  The
big problem with the Barracuda drives is cooling: they tend to overheat
and fail unless kept well cooled.  You may also want to check the revision
of the code in the Barracuda itself, as that's been updated a few times.
   Hmm.  Lot of vague comments here, but we haven't had any problems like
this in a couple of years.
- ---------------------------+---------------------------------------------------
Bryan Feir           VA3GBF|"Every man has somewhere in the back of his head
bryan@sgl.ists.ca          | the wreck of a thing which he calls his
jenora@istar.ca            | education."              -- Stephen Leacock
- ---------------------------+---------------------------------------------------
---------------------------
End of New-News digest
**********************
From leonid@rst.co.il  Wed Dec 18 05:39:47 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Wed Dec 18 05:39:50 PST 1996
Subject: RE: debugging multiple tasks
> Ilia Maller <Ilia.Maller@ecitele.com> write:
> ...
> From unknown reason Tornado doesn't allow to create the second
> instance of CrossWind. So you have to run the second instance of Tornado.
> ...
This is correct, and I would like to explain the reason.
The Win95/NT version is an IDE, and the debugging function buttons
as well as the "Debug" menu items of the GUI are actually front end for the GDB
debugger back-end. If you have two instamces of GDB in the same IDE,
the IDE would be confised, as to which GDB exactly should receive the
commands when YOU clock on the e.g. "Step" botton.
You could argue that when the second GDB starts then a second panel of
debugging buttons should pop-up aotumatically, wht the "Name"
of the GDB instance it controls. But this still leaves room
for many other unclear issues, menu etc. Besides, I think that
the Win32 API which was used extensively to provide this IDE
functionality has asome limitation in this respect
(I could be wrong, cause I am not a Win32 expert :-)) ).
The UNIX version does not use an IDE, there each GDB has its own GUI
and all tools are independent of one-another. However, IDE seems as
the de-facto fasion in the PC world.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From tmorris@me.umn.edu  Wed Dec 18 12:57:24 1996
From: Ted Morris <tmorris@me.umn.edu>
Date: Wed Dec 18 12:57:27 PST 1996
Subject: RE: debugging multiple tasks
the vxWorks Users Group Exploder writes:
 > Submitted-by leonid@rst.co.il  Wed Dec 18 05:39:47 1996
 > Submitted-by: leonid@rst.co.il (Leonid Rosenboim)
 >
 > > Ilia Maller <Ilia.Maller@ecitele.com> write:
 > > ...
 > > From unknown reason Tornado doesn't allow to create the second
 > > instance of CrossWind. So you have to run the second instance of Tornado.
 > > ...
 >
 > This is correct, and I would like to explain the reason.
 > The Win95/NT version is an IDE, and the debugging function buttons
 > as well as the "Debug" menu items of the GUI are actually front end for the GDB
 > debugger back-end. If you have two instamces of GDB in the same IDE,
 > the IDE would be confised, as to which GDB exactly should receive the
 > commands when YOU clock on the e.g. "Step" botton.
 >
 > You could argue that when the second GDB starts then a second panel of
 > debugging buttons should pop-up aotumatically, wht the "Name"
 > of the GDB instance it controls. But this still leaves room
 > for many other unclear issues, menu etc. Besides, I think that
 > the Win32 API which was used extensively to provide this IDE
 > functionality has asome limitation in this respect
 > (I could be wrong, cause I am not a Win32 expert :-)) ).
 >
 > The UNIX version does not use an IDE, there each GDB has its own GUI
 > and all tools are independent of one-another. However, IDE seems as
 > the de-facto fasion in the PC world.
 >
Although I'm not a big windoz programmer, I did read the chapter
regarding Interprocess communications with Win95.  There are methods
to set up shared memory segments, semaphores, etc.  Perhaps this might
be a prudent approach with their app. rather than using IDE msg
passing.  Not 100% sure this applies to NT but the example programs in
the book supposedly can run on either NT or Win95.
Ted
From geoff@sdsi.co.uk  Thu Dec 19 00:40:41 1996
From: Geoff Revill <geoff@sdsi.co.uk>
Date: Thu Dec 19 00:40:44 PST 1996
Subject: RE: debugging multiple tasks
On Wednesday, December 18, 1996 01:39, the vxWorks Users Group
Exploder[SMTP:vxwexplo@lbl.gov] wrote:
> Submitted-by leonid@rst.co.il  Wed Dec 18 05:39:47 1996
> Submitted-by: leonid@rst.co.il (Leonid Rosenboim)
>
> > Ilia Maller <Ilia.Maller@ecitele.com> write:
> > ...
> > From unknown reason Tornado doesn't allow to create the second
> > instance of CrossWind. So you have to run the second instance of
Tornado.
> > ...
>
> This is correct, and I would like to explain the reason.
> The Win95/NT version is an IDE, and the debugging function buttons
> as well as the "Debug" menu items of the GUI are actually front end for
the GDB
> debugger back-end. If you have two instamces of GDB in the same IDE,
> the IDE would be confised, as to which GDB exactly should receive the
> commands when YOU clock on the e.g. "Step" botton.
>
> You could argue that when the second GDB starts then a second panel of
> debugging buttons should pop-up aotumatically, wht the "Name"
> of the GDB instance it controls. But this still leaves room
> for many other unclear issues, menu etc. Besides, I think that
> the Win32 API which was used extensively to provide this IDE
> functionality has asome limitation in this respect
> (I could be wrong, cause I am not a Win32 expert :-)) ).
>
> The UNIX version does not use an IDE, there each GDB has its own GUI
> and all tools are independent of one-another. However, IDE seems as
> the de-facto fasion in the PC world.
>
Software Development Systems (SDS) have made a Tornado compliant version of
their debugger,  currently only for the PowerPC customers.  It connects to
the Tornado server in exactly the same way Crosswind does.  However it's
multiple task debug is implemented differently.  Within the debugger you
have a task list on which you can click and view each tasks current
context. All the normal windows (register, stack, locals etc) are updated
with the stored context. This debugger is available on Windows 95, NT,
 SunOS, Solaris and HP-UX.
Of course, SingleStep supports all the  dynamic load and incremental link
facilities provided by Tornado. The ability to pull tasks out of the
scheduler and debug them while the rest of the system is active is also
part of Singlestep.  If you halt multiple tasks then you can swap between
their contexts and debug them.
SingleStep supports the GNU C compiler,  and the Diab C and C++ compiler
(which is validated for use with Tornado) via ELF/DWARF object format.  The
lack of C++ GNU support is due to the fact that GNU have only implemented a
translator for their debug information for C,  GNU does not provide a
translator for it's C++ debug information to ELF/DWARF,  at least not at
the moment.
Geoff
--
Geoff Revill
Software Development Systems, Ltd.
geoff@sdsi.co.uk
http://www.sdsi.com
+44 (0) 1442 876065
From daemon@csg.lbl.gov  Thu Dec 19 04:00:31 1996
From: daemon@csg.lbl.gov
Date: Thu Dec 19 04:00:35 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec 19 04:00:28 PST 1996
        Subject: Cross platform shared memory
        Subject: Re: VxVMI, prevention of code overwriting
        Subject: Memory Protection using VxVMI on a FORCE 32 card (MC68030)
        Subject: Re: debugging multiple tasks
        Subject: Re: Opinion about Win95 Tornado
        Subject: Re: debugging multiple tasks
        Subject: Re: debugging multiple tasks
        Subject: vxWorks SNMP (epilogue? vs. cmu)
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Cross platform shared memory
Date: 17 Dec 1996 17:07:30 GMT
From: freier@eng.utah.edu (Rod Freier)
Organization: University of Utah Computer Science Department
Message-ID: <596k0i$bpg@magus.cs.utah.edu>
Sender: freier@cadesm40.eng.utah.edu (Rodney Freier)
We are planning to use two different computers
in our VME rack:  Motorola MVME162-512a  and   MVME1603e.
We need to use shared memory.  Are we crazy?  Is this
possible under VxWorks 5.2?
Just hoping for a sanity check....
Rod Freier
freier@eng.utah.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxVMI, prevention of code overwriting
Date: Wed, 18 Dec 1996 20:44:52 +0100
From: Torsten Rupp <rupp@fzi.de>
Organization: University of Karlsruhe, Germany
Message-ID: <32B849B4.41C67EA6@fzi.de>
References: <32B7B275.3D75@indigo.co.il> <59921q$291@news.sei.cmu.edu>
Theodore Marz wrote:
> amount of dynamic linking you are doing, you can (very nearly) get Unix type
> memory space protection.
I'am currently making some experience with VxVMI and tried to make the
system more stable and resistend againts crashes of single tasks.
Unfortunatelly I have still no success to create a task with it's own
memory context which is completly isolated from all other contexts. For
example: if a task crash how is it possible to remove the private memory
pool? There exists only a function "memPartCreate", but not a function
"memPartDelete". With some debugging and testing I have found a way to
destroy a memory partition, but I'am not sure if this is "legal".
>   To do this 1) your application has to be structured such that there isn't
> any dynamic linking, other than to the OS.
What is the problem with dynamic linking and VxVMI?
> You can even create map "holes" around the stack and TCB.  What you cannot do
> is actually write protect the stack and TCB.
>
> Oh, if you do the above, you have to set up a task switch hook.
I tried this, but it doesn't work. Currently I don't know if there
exists some problems with write protected stack pages. In the manuals is
only an example how to create a private memory pool and to write-protect
specific data, but there is no example how to write-protect stack pages
of a foreign task.
If you have some idea or some code-examples it would be nice if you can
send me some email. Thank you.
 Torsten
- --
Information Science Research Center at the University of Karlsruhe
Technical Expert Systems and Robotics   phone:   +49-721-9654-302
Haid-und-Neu-Str. 10-14                 fax  :   +49-721-9654-309
D 76131 Karlsruhe (Germany)             e-mail:  rupp@fzi.de
---------------------------
Newsgroups: comp.os.vxworks
Subject: Memory Protection using VxVMI on a FORCE 32 card (MC68030)
Date: Wed, 18 Dec 1996 17:08:07 GMT
From: i.kerr@dra.hmg.gb (Ian Kerr)
Organization: DRA
Message-ID: <59972v$b3f$1@trog.dra.hmg.gb>
Reply-To: I.KERR@DRA.HMG.GB
To VxWorkers everywhere,
We have purchased the VxVMI add-on for VxWorks 5.1 to write memory
protected tasks on a MC68030 on a FORCE CPU32 card. Does anyone have
knowledge of what can and cannot be protected by VxWorks using this
add-on. Ideally different tasks will run quite separate applications
and no matter how badly they lose control how much can be done to
protect the other tasks from being interfered with. Can we protect
private data, Task Common Blocks (TcBs) etc.
Should we start a task/context to use in loading other tasks/contexts
and set them running or have we got "the completely wrong end of the
stick"?
Perhaps some wise person can give some advise or recount any
experiences that may be of direct relevance.
Ian Kerr
i.kerr@dra.hmg.gb
- ----------------------------------------------------------
                    Tel:44-1252-393000
AVS Dept            Fax:44-1252-395021
Probert (A5) Building
DRA Farnborough
Ively Road, Farnborough
HANTS GU14 0LX
United Kingdom
- ----------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: debugging multiple tasks
Date: 18 Dec 1996 16:34:22 GMT
From: mda@bnr.ca (Mark Dapoz)
Organization: Bell-Northern Research Ltd.
Message-ID: <5996ee$1f4@bcarh8ab.bnr.ca>
References: <199612162130.OAA03440@sass443.sandia.gov>
In article <199612162130.OAA03440@sass443.sandia.gov>,
Barbara Mills <bemills@sandia.gov> wrote:
>This may not be a "good" solution either, but you might try creating a
>vxWorks 5.2-style kernel so that you could set breakpoints in both
>the (now target-resident) shell and the crosswind debugger.   This
>"feature" is not available with the Tornado shell.
Unfortunatly the wdb agent and the shell use completely different
implementations of breakpoints and they are not interchangeable.
Breakpoints set in one environment will not appear in the other. In
fact, if you include wdb breakpoints in your target, it will most
likely disable the target resident shell breakpoints.  I've got a
patch that will allow both to co-exist, although they will only work
independent of each other. Unfortunatly you need source access in
order to apply the patch.
				-mark
- --
Mark Dapoz	Bell-Northern Research, Ottawa, Canada	    Mark.Dapoz@bnr.ca
Fingers and toes, fingers and toes, forty things we share, forty one if you
include the fact that we don't care.  - The Tragically Hip
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Opinion about Win95 Tornado
Date: Wed, 18 Dec 1996 21:05:50 +0100
From: Torsten Rupp <rupp@fzi.de>
Organization: University of Karlsruhe, Germany
Message-ID: <32B84E9E.167EB0E7@fzi.de>
References: <9612171346.AA18021@radcom.co.il> <5988a8$228_004@hjbpc.idiom.com>
H.J. Bae wrote:
> Tornado GUI on Win95 (and WinNT) has many bugs that makes it
> almost unusable, as far as I (and many of my coworkers) are concerned.
I have made the same experience. Currently I'am not able to run the
debugger of Tornado with a MV162-target on a WinNT-4.0-PC. I'am able to
start the target server and then the debugger, but there is always an
error message like "UNSUPPORTED_AGENT_REQUEST" and the target server
will be restarted. Furthermore the target server will then only run for
a _few_ minutes and will then crash with some other error (some request
fail and errorlevel 2 will be return). With a lot of time and many tests
it is _possible_ to start the debugger (for a few minutes only, of
course) and to go a few steps further, but I have never made a success
to debug a small program (<100 lines) - the debugger or Tornado itself
crashes at some time and a post-mortem image will be created by WinNT.
Therefore I think the PC-Tornado is currently simply unusable.
At a demo session of WindRiver I have seen a PC running Tornado, but I
don't know what they do to avoid unexpected crashes of the program which
I can see several times each day.
> Perhaps SUN-hosted Tornado works better, but I don't know.
For a short time I could the SUN development environment, too and I
think it is more stable. The GUI-Debugger looks not as big as the
Windows GUI-Debugger, but it does not crash as often as the Windows one.
Nevertheless the debugger is still not very comfortable. For example you
have to type in some commands via keyboard, too (what is the meaning of
GUI? :-((( ).
> One of things I have been wondering about is: do people at WRS use
> windows version of Tornado heavily?  What do their developers use?
I'am wondering about that, too and I don't understand it.
  Torsten
- --
Information Science Research Center at the University of Karlsruhe
Technical Expert Systems and Robotics   phone:   +49-721-9654-302
Haid-und-Neu-Str. 10-14                 fax  :   +49-721-9654-309
D 76131 Karlsruhe (Germany)             e-mail:  rupp@fzi.de
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: debugging multiple tasks
Date: Thu, 19 Dec 96 07:32:48 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <59ar0a$73r@idiom.com>
References: <199612162130.OAA03440@sass443.sandia.gov> <5996ee$1f4@bcarh8ab.bnr.ca> <599or9$39q@idiom.com> <59aa79$pta@bcarh8ab.bnr.ca>
In article <59aa79$pta@bcarh8ab.bnr.ca>, mda@bnr.ca (Mark Dapoz) wrote:
>It is for vxSim, the wdb agent steals the interrupt vector from the
>shell breakpoint library and shell breakpoints are never given a
>chance to be trapped.
Well, you certainly know better about this than I do since I don't
have access to the source code.  However, scanning the
header files confirms that rdb and shell debugger share the same
trap vectors.  It doesn't make any sense.  Why not at least make
it configurable?
Also, looking at the fragments of source code you posted, it seems
that whoever gets initialized last will end up owning the trap vector.
Which may explain why I am able to use shell debugger while my wdb
stuff is also running in the system.  I'm not sure.
Thanks for the info.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: debugging multiple tasks
Date: Thu, 19 Dec 96 07:34:01 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <59ar2i$73r@idiom.com>
References: <199612162130.OAA03440@sass443.sandia.gov> <5996ee$1f4@bcarh8ab.bnr.ca> <599or9$39q@idiom.com> <59aa79$pta@bcarh8ab.bnr.ca> <59ar0a$73r@idiom.com>
In article <59ar0a$73r@idiom.com>, hjb@pso.com (H.J. Bae) wrote:
>header files confirms that rdb and shell debugger share the same
                            ^^^^
                            of course I meant wdb here.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: vxWorks SNMP (epilogue? vs. cmu)
Date: Thu, 19 Dec 96 07:38:34 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <59arb4$73r@idiom.com>
I'm interested in getting some feedback on WRS' SNMP offering.
If you have used the "Epilogue(?)" SNMP WRS sells, how
does it compare to the free CMU SNMP stuff?  I have a
product that uses CMU SNMP stuff currently, and one of
the things that I don't like about CMU implementation is
the lack of pre-compiled MIB support.  It would be simple
to modify CMU stuff to have this support but time == money.
Before I go out and spend more money , I'd like
to get some feedback.
Thanks!
http://www.pso.com
mailto:hjb@pso.com
---------------------------
End of New-News digest
**********************
From leonid@rst.co.il  Thu Dec 19 04:00:55 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Thu Dec 19 04:00:58 PST 1996
Subject: Announcement - FlashLib 2.0
It has been almost one year that FlashLib has been shipping, 19 design
wins, and some customers already in production with FlashLib for file
storage on embedded Flash arrays, We beleive this to be a success.
Now we are announcing the upcoming availability of FlashLib 2.0, with
some important improvements over the previous version, including
support for long file names and fault tolerance.  FlashLib 2.0 is
currently in Beta stage.
FlashLib is a Flash File System based on Microsoft's FFS specification
(not related to the popular DOS File System, aka FAT), which supports a
wide variety of hardware configuration, including virtually any custom
design.
Please see our Web site for details on the new features.
Our Web page also carries some free software for VxWorks.  A new
addition to the free modules is our implementation of IEEE 802.2
LLC/SNAP for Token Ring networks.  We also added an article about
installing Tier-2 and Tier-2 Tornado architectures on a common
directory tree.
Emjoy, and  ... Happy New Year !
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From sikora@orca.ds.boeing.com  Thu Dec 19 09:17:32 1996
From: Gregory Sikora <sikora@orca.ds.boeing.com>
Date: Thu Dec 19 09:17:34 PST 1996
Subject: unsubscribe
sikora@orca.ds.boeing.com
From daemon@csg.lbl.gov  Fri Dec 20 04:01:11 1996
From: daemon@csg.lbl.gov
Date: Fri Dec 20 04:01:13 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 20 04:01:09 PST 1996
        Subject: Re: setsockopt problem on i960 target
        Subject: Re: VxWorks Virus Detection
        Subject: Re: Core dump in VxWorks
        Subject: Positions Available at MBARI
        Subject: Re: Shared Memory Network Woes
        Subject: system resource reclamation
        Subject: Re: vmechip2 (again)
        Subject: DMAs interrupted by bus errors
        Subject: Tornado ELF downloader bug?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: setsockopt problem on i960 target
Date: Wed, 18 Dec 96 07:37:44 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star Ozonosphere
Message-ID: <598708$228_002@hjbpc.idiom.com>
References: <32B77009.6641@ix.netcom.com>
In article <32B77009.6641@ix.netcom.com>, j.oonk@ix.netcom.com wrote:
>We seem to be unable to turn off the Nagle algorithm in our socket
>communication from target to host using TCP_NODELAY set on.
>We were able to kludge around this problem but it is discouraging
>that we could not change this behaviour. Our PC/NT host on the
>other hand responded as expected to this setsockopt().
>
>Has anyone had a similar experience and either found a satisfactory
>workaround/fix or submitted this as a bug for the i960 target?
setsockopt TCP_NODELAY works as expected on VxWorks.  This isn't
really a target specific feature, so I'd expect it to work on all
supported BSP's.  I'm curious about why you say it doesn't work.
Could you elaborate?
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks Virus Detection
Date: 16 Dec 1996 20:49:08 GMT
From: Softweyr LLC <softweyr@xmission.xmission.com>
Organization: XMission Internet (801 539 0900)
Message-ID: <594ck4$d0e@news.xmission.com>
References: <961212135656_75353.1150_EHI74-2@CompuServe.COM>
William G.St.Clair <75353.1150@CompuServe.COM> wrote:
: I need to determine the state of the art of virsus detection/scanning
: technology on the VxWorks platform.
:
: Should I start rubbing two sticks together?
Scanning for VxWorks viruses?  Or scanning incoming datastreams for
common PC/Mac viruses?
The idea of viruses on VxWorks kind of boggles...
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Core dump in VxWorks
Date: 16 Dec 1996 20:50:46 GMT
From: Softweyr LLC <softweyr@xmission.xmission.com>
Organization: XMission Internet (801 539 0900)
Message-ID: <594cn6$d0e@news.xmission.com>
References: <32B05FA6.31DFF4F5@xyplex.com>
Roger Cruz <cruz@xyplex.com> wrote:
: I'm searching for a way to have VxWorks create a core dump of the
: application running on the target system which can then be used with the
: tornado development tools to do debugging.  This approach is similar to
: what unix provides: 1) the OS creates a core file, and 2) the debugging
: tool (ie, dbx) knows how to read this file and print out useful
: information.  Any ideas?  Has anybody done any time of dumping or
: written tools to analyzed a memory dump?
WindView has a post-mortem mode; you can (probably) find more information
in the WV manuals.  I've used it once before, on a custom 68HC000 board,
but didn't configure it myself, so I'm not sure what it takes.
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks,comp.realtime
Subject: Positions Available at MBARI
Date: 18 Dec 1996 08:57:35 -0800
From: bobh@rovctl.mbari.org (Bob Herlien)
Organization: Monterey Bay Aquarium Research Institute (MBARI)
Message-ID: <5997pv$rbp@rovctl.mbari.org>
                        Software Engineer
                  (Real-time & Embedded Systems)
This position will design, implement, and support software for control
of electro-mechanical devices, instrumentation and data acquisition
systems for scientific applications in the field of oceanography.
Requires a Bachelors degree (advanced degree preferred) in Engineering,
Computer Science, or related technical area, and minimum five years
experience in a real-time or embedded systems programming field.  In
addition, 2+ years experience using the VxWorks real-time operating
system is required.  Must have ability to design and implement software
for complex multi-processor systems and to perform hardware/software
system integration of both commerical and in-house developed VMEbus
based products.  Must have experience developing embedded or real time
applications using C or C++ under UNIX or PC hosted cross-development
environments.  Excellent problem-solving and communication skills are
required.  Must be able to use tools, such as emulators, debuggers, and
logic analyzers.  Must be able to work effectively as a team player.
Detailed knowledge of data communication and networking hardware and
protocols is also required.  Familiarity with the Tornado development
environment is desirable.  Understanding of the use of structured
software development practices is preferred.  Must be willing and able
to go to sea for specified periods.
                        Software Engineer
                   (Scientific Instrumentation)
This position will design, implement and support software for control of
scientific instrumentation in the field of oceanography, including
development of system software, application software and diagnostic
software for scientific instrumentation, robotic systems, and general
data acquisition, data management, analysis and display applications.
Requires a Bachelors degree in Computer Science, Engineering, or related
technical discipline and at least three years experience developing
instrument control software in a scientific, medical, or test equipment
development field.  Experience developing software using C or C++ for
embedded or real time applications using UNIX or PC based development
environments is required.  Solid problem solving skills and the ability
to integrate and test complete data acquisition systems that function
reliably in a hostile ocean environment is essential.  Excellent
communication skills and ability to work as a team player is a must.
Must be able and willing to go to sea for specified periods.
Familiarity with data communication hardware and protocols, and data
telemetry techniques is desirable.
Please send resume and cover letter by January 6, 1997 to MBARI, Human
Resources, Dept. SW, PO Box 628, Moss Landing, CA  95039.
Please don't reply via email.  I'm posting this for our HR department,
but I'm not in HR.  Your resume will get into the system more quickly
via snail mail.
For more information on MBARI, and other open positions, check out
our web page at http://www.mbari.org
                                EOE
                        MBARI Welcomes Diversity
- --
- --------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
bobh@mbari.org
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Shared Memory Network Woes
Date: Tue, 10 Dec 1996 08:31:06 -0600
From: mjett@gwdg.de
Organization: Deja News Usenet Posting Service
Message-ID: <850226935.27033@dejanews.com>
References: <32A80AD0.345@gwdg.de> <32A854B9.167EB0E7@bbn.com>
In article <32A854B9.167EB0E7@bbn.com>,
  Fred Roeber <froeber@bbn.com> wrote:
>
> Maureen Jett wrote:
>
> > We are having lots of problems getting our shared memory network
> > running.  Specifically, the MV 147 on the VME bus has access to the
> > external memory at address 0x40100000 before booting, but after the
> > vxWorks kernel is loaded, we get a bus error when we try to look at the
> > external memory at the same address.  In fact, after booting there is no
> > access at all to the VME bus.  I apologize if my hardware description
> > isn't good, as I'm really a software person.  The only configuration
> > changes I made were in config.h as shown below:
> >
> > #define SM_OFF_BOARD    TRUE
> >
> > #define SM_ANCHOR_ADRS  ((char *) (0x40100000)
> >
> > Do I need to make other changes?
>
> If you can't get at external memory after booting VxWorks it is likely
> due to a memory protection problem.  In the config/sysLib.c file
> you need to make changes to the sysPhysMemDesc file used to initialize
> the MMU so that the external memory is accessible.  If you don't do
> this the memory protection problems will show up as bus errors.  Fred
>
Fred,
Thanks for your reply.  I also wanted to thank the following people for
e-mailing me replies:
Don Fox <dfox@tdl.tdl.com>
Mike Deliman <miked@wrs.com>
Etok@communityonline.net
malcolm.cifuentes@nautronix.com.au (Malcolm Cifuentes)
The consensus was that I also needed to add the following entry to
the sysPhysMemDesc table in sysLib.c.
    {
    (void *) 0x40100000,
    (void *) 0x40100000,
    0x00080000,          /* 512 Kb, amount of address space to make visable */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },
This did indeed make the shared memory visible.  Now the problem we're having is
that the data at the anchor address is wrong.  After the VxWorks kernel is
loaded, it looks something like:
40100000: 4321 ffff 0001 ffff 0000 ffff 002c ffff
40100010: 0170 ffff 0000 ffff 0000 ffff 0000 ffff
The hardware person thinks the words are swapped, which is okay, but only every
second word is set correctly.  The memory card has a connection to 16-bit data.
By the way, we're using VxWorks 5.1.  Any insight into this problem would be
greatly appreciated.  I will be out for a few weeks for the Christmas/New Year
holidays, but I will use Deja News to read any posted responses.
TIA and happy holidays,
Maureen
- ---
Maureen M. Jett
Max Planck Institute for Biophysical Chemistry
ZEWEG-EDV Group, 051
tel:   49-551-201-1414       FAX: 49-551-201-1011
email: mjett@gwdg.de
- -------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
---------------------------
Newsgroups: comp.os.vxworks
Subject: system resource reclamation
Date: Fri, 06 Dec 1996 16:38:38 -0800
From: "David P. Davis" <ddavis@xtech.com>
Organization: Extended Technologies
Message-ID: <32A8BC8E.4D6F@xtech.com>
- --
Is there any support in VxWorks for per-task system resource allocation and recovery?  Under Unix,
after a task exits, all resources allocated to that task are returned to the system.  Does VxWorks
have any facilities to return files, memory, semaphores, etc. resources back to the system when a
task is deleted/destroyed/exiting?  I know there is a task deletion hook, but does that mean I have
to do all my own resource tracking on a per application basis?
Thanks.
- ---------------------
David Davis
Extended Technologies
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: vmechip2 (again)
Date: Thu, 19 Dec 1996 18:23:53 -0800
From: Elliot Lipeles <lipeles@cithe502.cithep.caltech.edu>
Organization: Caltech
Message-ID: <32B9F8B9.3630@cithe502.cithep.caltech.edu>
References: <32AE934F.6A5D@llnl.gov>
Doug Owens wrote:
>
> Does anyone have any example code that uses the interrupts from the
> vmechip2 DMA controller or interval timers on an MV160X board.  I would
> like to avoid reinventing the wheel here.
>
> Thanks,
> Doug Owens
> owens2@llnl.gov
I have DMA driver for the mvme1604 that is on the web at
http://cithe502.cithep.caltech.edu/cleo/daq/vxcode.html
the code is preliminary but it may still be useful. Actually we
plan on using 2600's for our final system.
Elliot Lipeles
lipeles@cithe502.cithep.caltech.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: DMAs interrupted by bus errors
Date: Thu, 19 Dec 1996 18:47:03 -0800
From: Elliot Lipeles <lipeles@cithe502.cithep.caltech.edu>
Organization: Caltech
Message-ID: <32B9FE27.4E5@cithe502.cithep.caltech.edu>
On a mvme1604 board I have found the following problem
which I think is in the hardware, but would like a second
opinion. If a DMA (D32 or D64) from the VME to the DRAM
is interrupted by a VME bus error the last few bytes of
data doesn't make it into the memory.
My theory on this is that the vmechip2 DMA engine fails
to empty its fifo after receiving a bus error and that
there is no software way arround this. Has anyone seen this?
It is important because we are implementing a D64 CBLT (chained
block transfer) where the master that is doing the DMA reads out
the entire crate from one CBLT address. The first slave board
knows it is first and transfers its data (which is undetermined
in length) then is notifies the next board (via IACK lines) to
transfer. And so on until we get to the board that is last which
transfers its data and then interupts the DMA with a BERR. So a
DMA being interupted by a bus error will be routine.
The documentation on the Universe (VME to PCI bridge) which will
be on that mvme 2600 board specifically states that it empties the
fifo before passing on the VME Bus Error interupt.
Thanks
Elliot Lipeles
lipeles@cithe502.cithep.caltech.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: Tornado ELF downloader bug?
Date: Fri, 20 Dec 1996 10:27:51 +0000
From: Hepworth & Hatcher <ny15@dial.pipex.com>
Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX)
Message-ID: <32BA6A27.1CFF@dial.pipex.com>
We have been having a problem with the Tornado 1.0 FCS elf downloader. It appears that for
some programs it is calculating absolute addresses incorrectly and overlapping the objects
text and data segments with disasterous consequences. For now we have fixed the problem
by padding out segments using the loader, ldppc.
To fix this problem took me two days, so I am not very happy at fixing WR bugs.
Has anyone else come across this problem and do WRS have a patch?
I have noticed that WRS have an SPR#6144 which describes a similar problem.
Thanks,
Paul Hatcher
hephat@dial.pipex.com
Host : Windows95, Tornado 1.0 FCS for PowerPC.
Target : MVME1302 with MVME1300 Beta BSP + Radstone PMC network card.
---------------------------
End of New-News digest
**********************
From rbf@ssd.ray.com  Fri Dec 20 04:40:08 1996
From: "Fleury Jr." <rbf@ssd.ray.com>
Date: Fri Dec 20 04:40:10 PST 1996
Subject: unsubscribe
From tkb@mclean.sparta.com  Fri Dec 20 07:38:49 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Fri Dec 20 07:38:51 PST 1996
Subject: Re: debugging multiple tasks
At 11:18 AM 12/16/96 PST, you wrote:
>WRS suggests that I detach from the first task and attach
>to the second task to set the breakpoint.  Then detach from
>the second one and attach back to the first one.  However
>detaching seems to wipe out all breakpoints, and it will
>put the task on the ready list, so it takes off.  Their
>next suggestion was to put some debugging semaphor in the
>first task, and have it pend just before it sent the message.
>Then detach from it and attach to the background task.
>Put a breakpoint where the message will be caught, then
>send the semaphore from the shell command line.  Not what
>I would call a "productivity enhancing" solution for the
>general case.
I generally run multiple instances of the debugger to look
at a sequence of events like those described above.  I don't
use the launcher very much but I know you can start crosswind
from the command line.  I've also used Xray ( a fine product)
but the GNU debugger will easily do what you want, perhaps you
were talking to a rookie in tech support...
adios
From daemon@csg.lbl.gov  Sat Dec 21 04:00:35 1996
From: daemon@csg.lbl.gov
Date: Sat Dec 21 04:00:40 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec 21 04:00:30 PST 1996
        Subject: Re: Opinion about Win95 Tornado
        Subject: Re: VxVMI stuff
        Subject: TCB link list
        Subject: Re: FLASH file system support?
        Subject: VxVMI stuff
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Opinion about Win95 Tornado
Date: 20 Dec 96 03:45:55 GMT
From: johncoby@ghgcorp.com (John R. Cobarruvias)
Organization: Self
Message-ID: <johncoby-2012960949040001@max7-79.ghg.net>
References: <9612171346.AA18021@radcom.co.il> <5988a8$228_004@hjbpc.idiom.com>
WOW! I was just about to put in an order for Tornado with 5 seats on a
Win95 platform. I appreciate the insight. I think we will stay with the
Unix platform.
In article <5988a8$228_004@hjbpc.idiom.com>, hjb@pso.com (H.J. Bae) wrote:
> Tornado GUI on Win95 (and WinNT) has many bugs that makes it
> almost unusable, as far as I (and many of my coworkers) are concerned.
> This is not a "flame", just a fact.  Or maybe it is a flame, but
> I've paid good money to use Tornado, and I've recommended it to
> a lot of my customers, and damn it, I am very unhappy as a customer.
>
> We simply do not use Tornado GUI, debugger, etc.  Instead, we
> ended up just running the cross-compilers from the DOS shell (or
> from inside GNU emacs).  For debugging, the command line version
> of GDB is much more stable than the Tornado GUI version.  Some of
> the people I know use the command line version a lot, but I've
> found that even the command line version occasionally barfs out.
> I never personally found any need for a buggy source level debugger
> that doesn't let you set breakpoints applicable to multiple tasks,
> so instead I just use the assembly level debugger built into the
> target resident shell, which works always.  We ended up wasting
> a lot of development time fighting bugs in Tornado and its debugger.
> Perhaps SUN-hosted Tornado works better, but I don't know.
>
> I was very excited when I first saw the Tornado demo.  I think
> that if all the bugs are worked out, Tornado is a very useful
> package.  Unfortunately, as it is now (at least on win32), it
> needs a lot of work.   Having spent about a year using the win32
> Tornado, I am just about fed up with its problems.
>
> Doing a GDB that will work rock-solid remotely is not that hard.
> But I am yet to see one that come out of WRS that's stable enough to use.
> This is really hard to understand, since cross/remote debugging is
> one of the main features of the VxWorks system.  Someone posted
> an article earlier about XRAY vs. Tornado GDB.  Having used both
> packages, I agree with him completely.  Some of the things that
> work solidly in XRAY just aren't even available in Tornado.  XRAY
> is a superbly stable debugger.  It's a pity that you have to
> use pSOS or VRTX to use XRAY, because I don't like either pSOS or VRTX.
> GDB itself is also a superb debugger, and it is also very stable.
> It just happens that the versions coming out of WRS are not.
>
> One of things I have been wondering about is: do people at WRS use
> windows version of Tornado heavily?  What do their developers use?
> In the old days, everyone used SUN workstations there.  Do you
> guys now use windows Tornado a lot internally?  If so, do you not
> see that it is full of bugs?  How can you get your work done?
> If WRS does not use windows Tornado heavily internally, how do you
> expect the customers to use it?
>
> Hopefully all of these problems will be fixed in the future.
>
> http://www.pso.com
> mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxVMI stuff
Date: 20 Dec 1996 18:00:21 GMT
From: mda@bnr.ca (Mark Dapoz)
Organization: Bell-Northern Research Ltd.
Message-ID: <59ek7l$4jh@bcarh8ab.bnr.ca>
References: <599o2c$idr@news.sei.cmu.edu> <32BA9E90.2781E494@fzi.de>
In article <32BA9E90.2781E494@fzi.de>, Torsten Rupp  <rupp@fzi.de> wrote:
>Theodore Marz wrote:
>
>I have tried this, too, but without good success. It is possible to
>place such a hole at the top and bottom of the stack, but if the stack
>is overflowing then you will get on a MC680x0 a double bus error,
>because all tasks are running in supervisor mode (Motorola suggested to
>do this _only_ in kernel or operation system routines) and therefore the
>supervisor stack is already in use and can not be used for processing
>the MMU exceptions (data which have to be saved on the suppervisor stack
>will cause a second access fault by the MMU).
You should be able to avoid this situation by using a separate interrupt
stack.  Many of the architectures are implemented in such a way that
interrupts are taken on the currently executing task stack instead of
allocating a private interrupt stack.  If I remember correctly, the 020
used a separate interrupt stack whereas for some reason all the other
68K architectures used the task stack.  Why, I'm not really sure, it should
be possible to use an interrupt stack on all 68K architectures.
>						I think this is one more
>example that is not possible to make vxWorks more reliable and stable.
Well, that might be a bit of an overstatement.  Although vxWorks isn't
the best example of reliable code, it is rather well written and for the
most part it works reliably.  There are of course numerous features which
are lacking if you want a robust environment for ill-behaved applications.
Those extensions could be added to vxWorks if you wanted to take the time
to do them.  I would really like to see a nice clean multiple address space
implementation so that tasks can run isolated from each other.
				-mark
- --
Mark Dapoz	Bell-Northern Research, Ottawa, Canada	    Mark.Dapoz@bnr.ca
Fingers and toes, fingers and toes, forty things we share, forty one if you
include the fact that we don't care.  - The Tragically Hip
---------------------------
Newsgroups: comp.os.vxworks
Subject: TCB link list
Date: Thu, 19 Dec 1996 14:12:44 GMT
From: Uri Porat <poratu@indigo.co.il>
Organization: Indigo Israel
Message-ID: <32B94D5C.17E0@indigo.co.il>
Reply-To: poratu@indigo.co.il
Sender: news@indigo.co.il (News Administrator)
Hello
Is there any convinient way to trace the TCB link list?
BTY: I do know that the head to the list is activeQ.
        Thanks
        \Uri
- --
.--------------------------------------------------------------------.
| Uri Porat, Software Engineer (RnD)  Tel: (972-8)  9-38-91849/1818  |
| Indigo LTD, POB 150,                FAX: (972-8)  9-38-91-341/338  |
| Kiryat Weizmann,                    E-mail: poratu@Indigo.co.il    |
| Rehovot 76101, Israel               "My views are my own"          |
'--------------------------------------------------------------------'
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: FLASH file system support?
Date: Fri, 20 Dec 1996 09:23:39 -0700
From: Michael Mirabile <mmirabile@dayna.com>
Organization: Dayna Communications, Inc.
Message-ID: <32BABD8B.3117@dayna.com>
References: <32B6D2EA.2F88@HiWAAY.net>
The following company has a Flash File System for VxWorks:
	Leonid Rosenboim                        Phone:  +972-3-559-8144
	R S T  Software Industries Ltd.         Mobile: +972-50-307-142
	P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
	WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
Good Luck.
Michael Mirabile
Dayna Communications, Inc.
- ----------------------------------------------------------------------
David Leviner wrote:
>
> Hi all,
>
> I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH (Intel
> 28F016 chipset) and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM
> for the embedded application and 3 MBytes of FLASH is to be used as a "FLASH disk" for
> storing his applications. I am running the text section of VxWorks (instructions,
> constants,etc.) in the first 1MByte of FLASH and the data section of VxWorks (i.e., C
> variables) in DRAM.
>
> Does anyone know of a VxWorks FLASH file system driver that can be used for this type of
> BSP? And does anyone know of a device driver with read/write/erase, etc. support for the
> Intel 28F016 FLASH device.
>
> Thanks for the advice.
> --
> David Leviner
> Systems Engineer
> Chandler/May, Inc. (CMI)
> 125 West Park Loop
> Huntsville, AL  35806
> (205)722-0175
> (205)722-0144 (fax)
> dleviner@HiWAAY.net
>
> **********
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxVMI stuff
Date: 18 Dec 1996 21:35:08 GMT
From: tfm@sei.cmu.edu (Theodore Marz)
Organization: The Software Engineering Institute
Message-ID: <599o2c$idr@news.sei.cmu.edu>
The code that follows is not in a production state (and may not ever be made
so by me, don't know yet).  There are no provisions for deleting a private
virtual memory context ID.  Returning the allocated memory to the system pool
appears to work by "free"ing it.
I didn't get too hung up on this as VxWorks does not seem to be well behaved
WRT dynamically allocated memory, or task unloading.  Perhaps it really is, I
just have found no reason to trust it.
Dynamic linking in this kind of an environment is a problem because of how the
object code relocates during the loadTaskProtected operation.  I am actually
loading in the object such that it will execute ONLY in it's virtual address
space view (all relative addresses are relocated based on the load address,
which is the virtual load address).  You could extend this such that shared
code is loaded in a known good virtual address space (or in the Global Virtual
space), and then mapping this space appropriatly in all private virtual memory
contexts.
Because each load operation happens in it's own virtual address space, and all
of these virtual address spaces happen to have the same virtual base address,
there is no way for these objects to intercommunicate via dynamic linking
correctly.  In this setup, anything that is dynamically linked would have to
be loaded in the Global Virtual context.
Task switch hooks do indeed work.... This code uses them to correctly
establish the new private virtual context associated with a task at contect
switch time.
You cannot write protect stack / tcb pages (VxWorks loader actually
establishes the stack in proximity to the TCB, don't remember which order they
are in, but they are contiguous).  This is because when the task is spawned,
VxWorks (shell) goes and does things to the TCB and stack to initialize them.
If they were write protected in the global virtual address space, then they
could not be accessed properly by the shell.
What I have done is establish a map "hole" around the stack / tcb.  This is
wasteful of physical memory, but should do 2 things.  It should prevent other
tasks from "walking" into the stack/tcb of another task.  It should also have
some kind of protection for stack over/under flows (I don't remember which, I
think overflows).
Again, this is just one way (and fairly crude) to use the tools provided.
Your mileage may vary.
Ted Marz
====================================================================
start-up script for loading a memory protected application:
The first 4 lines establish some symbols in the global virtual space that the
later loaded applications link to.  The ld <taskprotect.o establishes the
facilities for linking into the VxVMI environment.
_pio_max_time = 0
_base_max_time = 0
_comp_max_time = 0
_dec_max_time = 0
ld <timing.o
ld < taskprotect.o
loadAndGo("EB_Dec_C",  "_decision", "decision",   52)
loadAndGo("EB_Simple",  "_baseline", "baseline",   53)
loadAndGo("EB_Complex_Ada", "_ada_main",  "ada_complex",  54)
loadAndGo("EB_Phys_IO",  "_lan_io", "lan_io",   51)
=====================================================================
/****************************************************************************\
*                                                                            *
*   context.c - Private virtual memory context support routines              *
*                                                                            *
*  Public Routines:                                                          *
*     loadTaskProtected - load a task into a virtual context.                *
*     spawnTaskProtected - spawn a task loaded into virtual memory,          *
*                          with a protected "hole" around the stack          *
*     loadAndGo - convience routine to load/spawn a task.                    *
*                                                                            *
******************************************************************************
*                                                                            *
*  loadTaskProtected - create a private virtual memory context to establish  *
*  a task in.                                                                *
*                                                                            *
* <context-id> = loadTaskProtected( <filename>,                              *
*                                   <tvaddr>,<dvaddr>,<bvaddr> );            *
* Where:                                                                     *
*  <context-id> is the ID of the created virtual context, or NULL if error   *
*  <filename>   is a char * to the filename of an a.out file to load into    *
*               a protected virtual context.                                 *
*  <tvaddr> is the address of a void *, returning the virtual address of     *
*           the task's text segment                                          *
*  <dvaddr> is the address of a void *, returning the virtual address of     *
*           the task's data segment                                          *
*  <bvaddr> is the address of a void *, returning the virtual address of     *
*           the task's bss segment                                           *
*                                                                            *
*  The virtual addresses will be allocated at the first virtual address      *
*  following the global virtual space.  Text before Data before BSS          *
*                                                                            *
*  physical memory will be allocated with valloc, from the system memory     *
*  pool.  This memory will be made RO in the global virtual context.         *
*                                                                            *
******************************************************************************
*                                                                            *
*  spawnTaskProtected - spawn a task into a protected context with a         *
*     protected stack.                                                       *
*                                                                            *
*  <task-id> = spawnTaskProtected( <name>, <context>, <priority>,            *
*                                  <stack_size>, <entry_point>,              *
*                                  <arg1>, ..., <arg9>                       *
*  Where:                                                                    *
*   <task-id>    is a positive integer task id, or ERROR if the spawn fails. *
*   <name>       is a char * to the task name for the spawned task.          *
*                if NULL, a task name of the form  t<n> will be used.        *
*   <context>    is the virtual memory context to establish for this task.   *
*   <priority>   is the integer VxWorks priority for this task.              *
*   <stack-size> is the size of the stack, in bytes.                         *
*   <entry>      is the address of the entry point of the task               *
*   <arg1> thru                                                              *
*   <arg9>       are the 9 arguments to start the VxWorks task with          *
*                                                                            *
*  The spawn'ed task's 10th argument will be the id of it's virtual context  *
*                                                                            *
*  The stack will be allocated starting at the first virtual page following  *
*  the highest allocated virtual address in the supplied segment.            *
*                                                                            *
*  The task control block will be allocated "below" the stack.  This is the  *
*  same way that VxWorks taskSpawn() does it.                                *
*                                                                            *
******************************************************************************
*                                                                            *
*  loadAndGo - load and spawn a task, with a default stack size, priority    *
*              and argument set.                                             *
*                                                                            *
*  <task-id> = loadAndGo( <name>, <entry>, <taskName> );                     *
*                                                                            *
*  Where:                                                                    *
*   <task-id>    is a positive integer task id, or ERROR if the spawn fails. *
*   <filename>   is a pointer to a character string containing the name      *
*                of the object file to load / run.                           *
*   <entryName>  is a pointer to a character string containing the name      *
*                of the task's entry point.  Under GreenHills tools, this    *
*                is the routine name of the entry point, preceeded (and      *
*                possibly followed, depending on the language) by one        *
*                or more underscores (_).  objdump68k or nm can be used      *
*                to examine the object file's symbol table.                  *
*    <taskName>  is a pointer to a character string containing the desired   *
*                name for the task.                                          *
*                                                                            *
*  loadAndGo uses a VxWorks priority of 200 (decimal) and a stack size of    *
*  8K bytes (less the size of the TCB, and some overhead that VxWorks        *
*  appears to put at the "top" (lowest address) limit of the stack.          *
*                                                                            *
\****************************************************************************/
/******************************  VxWorks Include Files **********************/
#include "vxWorks.h"
#include "vmLib.h"
#include "memLib.h"
#include <stdio.h>
#include <fcntl.h>
#include <ioLib.h>
#include <loadLib.h>
#include "a_out.h"
#include <string.h>
#include <taskLib.h>
#include <symLib.h>
#include <sysSymTbl.h>
#include <taskHookLib.h>
/*****************************  Other defines  ******************************/
#define VM_STATE_MASK_ALL (VM_STATE_MASK_VALID | \
                           VM_STATE_MASK_WRITABLE | \
                           VM_STATE_MASK_CACHEABLE )
#define RO_CACHE (VM_STATE_VALID | VM_STATE_WRITABLE_NOT | VM_STATE_CACHEABLE)
#define RW_CACHE (VM_STATE_VALID | VM_STATE_WRITABLE     | VM_STATE_CACHEABLE)
/***************************** Private typedef's ****************************/
/* private data for task VM handling */
typedef struct {
  int global;
} privateInitType;
/*****************************  Private Global Variables ********************/
static privateInitType privateData = { 0 };
/*****************************  Private Utility Routines  *******************/
/******************************************************************\
 *                                                                *
 *  switchHandler - virtual memory aware context switch task hook *
 *                                                                *
 *  This routine assumes that if a task (incoming or outgoing)    *
 *  has an associated private virtual memory context, the VM      *
 *  context ID will be saves (as an int) in the  spare1  element  *
 *  of the tasks control block (TCB).                             *
 *                                                                *
 *  While the task in activly running, the private virtual memory *
 *  context is established as the current context.  In this case, *
 *  the  spare1  element of the TCB contains the VM Context ID    *
 *  that was current when control switched to this task           *
 *  (usually, the system VM context ID).                          *
 *  The context in effect when the task was entered is first      *
 *  re-established.  The TCB of the incoming task is then checked *
 *  and if a private context is present, the current              *
 *  (re-established) context is saved in the incoming TCB and the *
 *  incoming task's VM context is made current.                   *
 *                                                                *
\******************************************************************/
static void switchHandler( WIND_TCB *pOldTcb, WIND_TCB *pNewTcb )
{
  VM_CONTEXT_ID pContext = NULL;  /* temp for saving vm contexts */
  /* check to see if the previous task had a private context */
  if (pOldTcb->spare1) {
     pContext = (VM_CONTEXT_ID) pOldTcb->spare1;
     pOldTcb->spare1 = (int) vmCurrentGet();
     vmCurrentSet( pContext );
  }
  /* check to see if the incoming task has a private context */
  if (pNewTcb->spare1) {
    pContext = (VM_CONTEXT_ID) pNewTcb->spare1;
    pNewTcb->spare1 = (int) vmCurrentGet();
    vmCurrentSet( pContext );
  }
}
/******************************************************************\
 *                                                                *
 *  deleteHandler - virtual memory aware delete task hook         *
 *                                                                *
 *  This routine cleans up any "holes" in the global virtual      *
 *  context that may have been put in place around a task's       *
 *  stack.  These "holes" are single pages of invalid memory.     *
 *  They are placed around a task's stack to help ensure that     *
 *  this task will not overflow it's stack and corrupt other      *
 *  memory resources.  It will also protect from a task running   *
 *  away in physical memory (global virtual space) from           *
 *  corrupting this task's stack.                                 *
 *                                                                *
 *  This scheme will not protect a task from having another task  *
 *  jump directly into it's stack segment.                        *
 *                                                                *
 *  This is a possible problem, as pointers to the physical top   *
 *  and bottom of the stack, as well as the current stack         *
 *  location are located in the Task Control Block (TCB) of       *
 *  each task.  These TCBs are locatable and hence the stack      *
 *  may be subject to attack.                                     *
 *                                                                *
 *  For that matter, the VM Context ID of a task is also stored   *
 *  in the  spare1  location of the TCB.  A malagnant task        *
 *  could use this information to gain access virtually to the    *
 *  physical memory allocated to your task's text, data, or bss   *
 *  segments and again attack the task.                           *
 *                                                                *
\******************************************************************/
static void deleteHandler( WIND_TCB *pTcb )
{
  int    pageSize;             /* size of a VM page */
  char  *physAddr;             /* associated physical address */
  STATUS status;               /* function return status value */
  VM_CONTEXT_ID context;       /* task's local context */
  VM_CONTEXT_ID global;        /* system global context */
  UINT   physState;            /* system context page state */
  /*  check the TCB to see if this task has a private context associated */
  if (pTcb->spare1) {
    /* Ok, there is a VM context associated with this task */
    /* check to see if this is the system global virtual context */
    if (pTcb->spare1 != privateData.global) {
      context = (VM_CONTEXT_ID) pTcb->spare1;
      global  = (VM_CONTEXT_ID) privateData.global;
      /* in creating the task, we may have mapped a "hole" around the stack */
      /* check this and map this memory back in, then free it               */
      pageSize = vmPageSizeGet();
      physAddr = pTcb->pStackBase;
      /* if the physical address of the stack base is not on a page bound */
      /* then we have carved out the tcb below the stack.                 */
      /* bias the address up to the start of the next page                */
      physState = (int) physAddr % pageSize;
      if (physState) {
        physAddr += (pageSize - physState);
      }
      status = vmStateGet( global, physAddr, &physState );
      if (status == ERROR) return;
      if ( (physState & VM_STATE_MASK_VALID) == VM_STATE_VALID_NOT) {
         status= vmStateSet( global, physAddr, pageSize,
                             VM_STATE_MASK_VALID, VM_STATE_VALID);
      }
      physAddr = pTcb->pStackEnd - pageSize;
      status = vmStateGet( global, physAddr, &physState );
      if (status == ERROR) return;
      if ( (physState & VM_STATE_MASK_VALID) == VM_STATE_VALID_NOT) {
         status= vmStateSet( global, physAddr, pageSize,
                             VM_STATE_MASK_VALID, VM_STATE_VALID);
      }
      free (physAddr);
    }
  }
}
/******************************************************************\
 *                                                                *
 *  privateInit  -  initialize the private virtual context        *
 *                  environment.                                  *
 *                                                                *
 *  privateInit is called by spawnTaskProtected() to initialize   *
 *  context switch and task delete support for our use of private *
 *  virtual memory contexts for task protection.                  *
 *                                                                *
\******************************************************************/
static void privateInit()
{
  FUNCPTR swch = (FUNCPTR) switchHandler;
  FUNCPTR dele = (FUNCPTR) deleteHandler;
  if (!privateData.global) {
    privateData.global = (int) vmCurrentGet();
    taskSwitchHookAdd( swch );
    taskDeleteHookAdd( dele );
  }
}
/******************************************************************\
 *                                                                *
 *  cleanupTaskContext - loadTaskProtected convienience function  *
 *                                                                *
 *  This routine free's allocated memory sections in the event    *
 *  of an error occurring during task load memory allocation.     *
 *                                                                *
\******************************************************************/
static void cleanupTaskContext (
  VM_CONTEXT_ID context, void *text_paddr, void *data_paddr, void *bss_paddr)
{
    /* free allocated physical memory */
    if (text_paddr != NULL)
      memPartFree( memSysPartId, text_paddr );
    if (data_paddr != NULL)
      memPartFree( memSysPartId, data_paddr );
    if (bss_paddr != NULL)
      memPartFree( memSysPartId, bss_paddr );
    /* delete the virtual context */
    vmContextDelete( context );
}
/*****************************  public routines *******************************/
/****************************************************************************\
*                                                                            *
*  loadTaskProtected - create a private virtual memory context to establish  *
*  a task in.                                                                *
*                                                                            *
* <context-id> = loadTaskProtected( <filename>,                              *
*                                   <tvaddr>,<dvaddr>,<bvaddr> );            *
* Where:                                                                     *
*  <context-id> is the ID of the created virtual context, or NULL if error   *
*  <filename>   is a char * to the filename of an a.out file to load into    *
*               a protected virtual context.                                 *
*  <tvaddr> is the address of a void *, returning the virtual address of     *
*           the task's text segment                                          *
*  <dvaddr> is the address of a void *, returning the virtual address of     *
*           the task's data segment                                          *
*  <bvaddr> is the address of a void *, returning the virtual address of     *
*           the task's bss segment                                           *
*                                                                            *
*  The virtual addresses will be allocated at the first virtual address      *
*  following the global virtual space.  Text before Data before BSS          *
*                                                                            *
*  physical memory will be allocated with valloc, from the system memory     *
*  pool.  This memory will be made RO in the global virtual context.         *
*                                                                            *
\****************************************************************************/
VM_CONTEXT_ID loadTaskProtected( char *filename,
                                 void **text, void **data, void **bss )
{
  VM_CONTEXT_ID context;     /* returned context ID */
  VM_CONTEXT_ID global;      /* ID of global virtual context */
  INT8 *text_paddr = NULL;  /* text segment physical address */
  INT8 *data_paddr = NULL;  /* data segment physical address */
  INT8 *bss_paddr = NULL;   /* bss  segment physical address */
  INT8 *text_vaddr;         /* text segment virtual address */
  INT8 *data_vaddr;         /* data segment virtual address */
  INT8 *bss_vaddr;          /* bss  segment virtual address */
  int    pageBlockSize;      /* size of the VM page block */
  int    pageSize;           /* size of an MMU page */
  UINT8 *globalPageBlkArray; /* pointer to global page block info */
  INT8 *baseVirtAddr;       /* base virtual address */
  int    i;                  /* loop counter */
  int    fd;                 /* file descriptor to read a.out file */
  struct exec a_out_header;  /* a.out header buffer */
  int size;                  /* returned size of fread */
  int text_size;
  int data_size;
  int bss_size;
  MODULE_ID module;
  /* open this file, make sure it exists */
  fd = open( filename, O_RDONLY, 0);
  if (fd == ERROR) {
    printf("file %s does not exist, exiting\n", filename);
    return(NULL);
  }
  /* read in the a.out header */
  size = read( fd, (char *)&a_out_header, sizeof(a_out_header) );
  /* rewind the file */
  ioctl( fd, FIOSEEK, 0);
  /* determine the text, data, and bss sizes */
  text_size = a_out_header.a_text;
  data_size = a_out_header.a_data;
  bss_size  = a_out_header.a_bss;
  /* create the new virtual memory context */
  context = vmContextCreate();
  if (context == NULL) return (context);
  /* round up the sizes to a full page */
  pageSize = vmPageSizeGet();
  text_size += pageSize - (text_size % pageSize);
  data_size += pageSize - (data_size % pageSize);
  if (bss_size) bss_size  += pageSize - (bss_size  % pageSize);
  /* allocate physical memory for each segment */
  /* if an error occurrs, free previously allocated memory */
  /* and delete the created context. */
  text_paddr = valloc( text_size );
  if (text_paddr == NULL) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
    return (NULL);
  }
  data_paddr = valloc( data_size );
  if (data_paddr == NULL) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr);
    return (NULL);
  }
  if (bss_size > 0) {
    bss_paddr  = valloc( bss_size );
    if (bss_paddr == NULL) {
      cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
      return (NULL);
    }
  }
  /* locate the first free virtual address following gobal virtual */
  pageBlockSize = vmPageBlockSizeGet();
  globalPageBlkArray = vmGlobalInfoGet();
  for (i=0; globalPageBlkArray[i] != 0; i++);
  baseVirtAddr = (void *) (i * pageBlockSize);
  /* assign the virtual address's of the segments, relative to the base */
  text_vaddr = baseVirtAddr;
  data_vaddr = text_vaddr + text_size;
  bss_vaddr  = data_vaddr + data_size;
  /* map these sections into the virtual context */
  /* text is read-only, data and bss are read/write */
  if (vmMap( context, text_vaddr, text_paddr, text_size ) == ERROR) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
    return (NULL);
  }
  if (vmMap( context, data_vaddr, data_paddr, data_size ) == ERROR) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
    return (NULL);
  }
  if (bss_paddr) {
    if (vmMap( context, bss_vaddr, bss_paddr, bss_size ) == ERROR) {
      cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
      return (NULL);
    }
  }
  if (
      vmStateSet( context, text_vaddr, text_size, VM_STATE_MASK_ALL, RW_CACHE )
      == ERROR ) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
    return (NULL);
  }
  if (
      vmStateSet( context, data_vaddr, data_size, VM_STATE_MASK_ALL, RW_CACHE )
      == ERROR ) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
    return (NULL);
  }
  if (bss_paddr) {
    if (
        vmStateSet( context, bss_vaddr, bss_size, VM_STATE_MASK_ALL, RW_CACHE )
        == ERROR ) {
      cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr );
      return (NULL);
    }
  }
  /* load the file here */
  global = vmCurrentGet();
  vmCurrentSet( context );
  module = loadModuleAt(fd, LOAD_GLOBAL_SYMBOLS,
                        &text_vaddr, &data_vaddr, &bss_vaddr);
  vmCurrentSet( global );
  /* make text segment RO in the task context */
  vmStateSet( context, text_vaddr, text_size, VM_STATE_MASK_ALL, RO_CACHE);
  /* now, invalidate the same sections in global virtual space */
  if (
      vmStateSet( global, text_paddr, text_size, VM_STATE_MASK_ALL,
                                                 RO_CACHE)
      == ERROR) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr);
    return (NULL);
  }
  if (
      vmStateSet( global, data_paddr, data_size, VM_STATE_MASK_ALL,
                                                 RO_CACHE)
      == ERROR) {
    cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr);
    vmStateSet( global, text_paddr, text_size, VM_STATE_MASK_ALL,
                                               RW_CACHE);
    return (NULL);
  }
  if (bss_paddr) {
    if (
        vmStateSet( global, bss_paddr, bss_size, VM_STATE_MASK_ALL,
                                                  RO_CACHE)
        == ERROR) {
      cleanupTaskContext( context, text_paddr, data_paddr, bss_paddr);
      vmStateSet( global, text_paddr, text_size, VM_STATE_MASK_ALL,
                                                 RW_CACHE);
      vmStateSet( global, data_paddr, data_size, VM_STATE_MASK_ALL,
                                                 RW_CACHE);
      return (NULL);
    }
  }
  /* set return values and return */
  *text = text_vaddr;
  *data = data_vaddr;
  *bss  = bss_vaddr;
  return ( context );
}
/****************************************************************************\
*                                                                            *
*  spawnTaskProtected - spawn a task into a protected context with a         *
*     protected stack.                                                       *
*                                                                            *
*  <task-id> = spawnTaskProtected( <name>, <context>, <priority>,            *
*                                  <stack_size>, <entry_point>,              *
*                                  <arg1>, ..., <arg9>                       *
*  Where:                                                                    *
*   <task-id>    is a positive integer task id, or ERROR if the spawn fails. *
*   <name>       is a char * to the task name for the spawned task.          *
*                if NULL, a task name of the form  t<n> will be used.        *
*   <context>    is the virtual memory context to establish for this task.   *
*   <priority>   is the integer VxWorks priority for this task.              *
*   <stack-size> is the size of the stack, in bytes.                         *
*   <entry>      is the address of the entry point of the task               *
*   <arg1> thru                                                              *
*   <arg9>       are the 9 arguments to start the VxWorks task with          *
*                                                                            *
*  The spawn'ed task's 10th argument will be the id of it's virtual context  *
*                                                                            *
*  The stack will be allocated starting at the first virtual page following  *
*  the highest allocated virtual address in the supplied segment.            *
*                                                                            *
\****************************************************************************/
int spawnTaskProtected( char *name,  VM_CONTEXT_ID context,
                        int prio, int stackSize, FUNCPTR entry,
                        int arg1, int arg2, int arg3, int arg4, int arg5,
                        int arg6, int arg7, int arg8, int arg9 )
{
  VM_CONTEXT_ID global;       /* global virtual context id */
  int    pageSize;            /* the size of a virtual page */
  int    nPages;              /* number of pages needed for the stack */
  INT8 *physStack;            /* physical address of stack */
  INT8 *stackBase;            /* "base" of stack */
  WIND_TCB *tcb;              /* task control block */
  STATUS status;              /* function status value */
  int    retval = 0;          /* return function value */
  /* make sure private contexts are enabled, if not, enable them */
  if (!privateData.global) privateInit();
  /* save the current (global) context */
  global = vmCurrentGet();
  /* get the size of a virtual memory page */
  pageSize = vmPageSizeGet();
  nPages   = (stackSize + pageSize - 1) / pageSize;
  stackSize = nPages * pageSize;
  /* allocated physical memory for the stack              */
  physStack = (INT8 *) valloc( stackSize+(2*pageSize) );
  if (physStack == NULL) return (retval);
  /* map out the pages before and after the allocated stack */
  vmStateSet( global, physStack, pageSize,
              VM_STATE_MASK_VALID, VM_STATE_VALID_NOT );
  vmStateSet( global, (physStack + stackSize + pageSize), pageSize,
              VM_STATE_MASK_VALID, VM_STATE_VALID_NOT);
  /* ok, stack is allocated and initialized */
  /* perform the taskInit and taskActivate to start the task    */
  /* "Carve" the TCB out of the bottom of the stack */
  stackBase = (physStack + stackSize + pageSize - sizeof(WIND_TCB));
  stackSize -= sizeof(WIND_TCB);
  tcb = (WIND_TCB *) stackBase;
/*  tcb = (WIND_TCB *) memalign( sizeof(int), sizeof(WIND_TCB) ); */
  bzero( (char *) tcb, sizeof(WIND_TCB) );
/* printf("tcb for task %s is at %x spare1 @ %x\n", name, tcb, &tcb->spare1);*/
  status = taskInit(
	       tcb, name, prio, VX_FP_TASK,
               stackBase, stackSize,
               entry,
               arg1, arg2, arg3, arg4, arg5,
	       arg6, arg7, arg8, arg9, (int) context );
  /* if taskInit fails, release the allocated memory and return */
  if (status == ERROR) {
    vmStateSet( global, physStack, pageSize,
                VM_STATE_MASK_VALID, VM_STATE_VALID );
    vmStateSet( global, (physStack + stackSize + pageSize), pageSize,
                VM_STATE_MASK_VALID, VM_STATE_VALID);
/*    memPartFree( memSysPartId, (char *) tcb ); */
    memPartFree( memSysPartId, physStack );
    return (retval);
  }
  retval = (int) tcb;
  /* establish the VM context in the TCB */
  tcb->spare1 = (int) context;
  /* activate the task */
  status = taskActivate( (int) tcb );
  /* if taskActivate failes for some reason, delete the task */
  if (status == ERROR) {
    vmStateSet( global, physStack, pageSize,
                VM_STATE_MASK_VALID, VM_STATE_VALID );
    vmStateSet( global, (physStack + stackSize + pageSize), pageSize,
                VM_STATE_MASK_VALID, VM_STATE_VALID);
    memPartFree( memSysPartId, (char *)tcb );
    memPartFree( memSysPartId, physStack );
    return(0);
  }
  else {
    return( retval );
  }
}
int loadAndGo( char *filename, char *entryName, char *taskName, int prio )
{
   VM_CONTEXT_ID loadStatus;    /* status of loadTaskProtected == vm context */
   int           spawnStatus;   /* status of spawnTaskProtected == task id */
   STATUS        status;        /* status of entrypoint symbol lookup  */
   UINT8 *text;                 /* virt addr of loaded text segment    */
   UINT8 *data;                 /* virt addr of loaded data segment    */
   UINT8 *bss;                  /* virt addr of loaded bss  segment    */
   int    default_stack = 0x2000; /* task stack size                   */
   FUNCPTR entry;               /* pointer to spawned task entry point */
   SYM_TYPE type;               /* symbol type of entry point symbol   */
   char   *centry;              /* pointer to spawned task entry point */
   /* try and load the specified file into memory */
   loadStatus = loadTaskProtected ( filename, &text, &data, &bss );
   if (loadStatus == NULL) return(0);
/* printf("context for %s is %x\n", filename, loadStatus); */
   /* look up the entry point in the symbol table */
   status = symFindByName( sysSymTbl, entryName, &centry, &type );
   if (status == ERROR) {
      printf("entry point symbol %s not found, exiting\n", entryName);
      return(0);
   }
   entry = (FUNCPTR) centry;
   /* spawn the task into it's virtual context */
   spawnStatus = spawnTaskProtected( taskName, loadStatus, prio,
				     default_stack, entry,
				     0, 0, 0, 0, 0,
				     0, 0, 0, 0 );
   return( spawnStatus );
}
---------------------------
End of New-News digest
**********************
From tkb@mclean.sparta.com  Sat Dec 21 13:18:23 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Sat Dec 21 13:18:25 PST 1996
Subject: Re: VxVMI stuff
>>						I think this is one more
>>example that is not possible to make vxWorks more reliable and stable.
VxWorks is extrememly reliable and ultra-stable, your application
may not be.  In a real-time embedded system where reliability and
determinism is the first concern, concentrate on software quality
assurance practices first.  Adding a level of fault tolerance by
implementing task based virtual memory schemes should be way down
on the list of methods to ensure stability.
WRS made the correct choice of not including VxVMI or task-based
virtual memory spaces by default.  Using VM can have a huge impact
on determinism.  It is pretty quick to change memory contexts but
the performance of code execution just after the context switch is
very non-deterministic.  I have authored a few SPARC BSP ports.  On
a SuperSPARC, any instruction may take as little as 1/3 of a clock
cycle to execute if in the cache or as many 40 clock cycles is not in
the cache.  You always have this problem to a certain extent but if
you are changing memory contexts very often, you'll encounter
invalidated caches & MMU page definitions not in the TLB much more
often.
The dirty truth is that caches, MMUs, TLBs etc have a measurable impact
on determinism.  Implementing task-based VM protection makes that
non-deterministic behaviour a much larger factor, usually large enough
that you can't ignore it.  If you can live with it, you should look at
some of the 'real-time' Unix OSes or Solaris.  VxWorks was intended for
a different sort of mission.
adios
From eknuds@extremenetworks.com  Sat Dec 21 22:29:19 1996
From: Eric Knudstrup <eknuds@extremenetworks.com>
Date: Sat Dec 21 22:29:21 PST 1996
Subject: Building GCC cross compiler for vxworks...
I am trying to build GCC 2.7.2 on Linux (I think I got binutils right.)
The problem is that configure tells me that the "i386-wrs-vxworks
configuration is not supported"
Is there a way around this, or should I just tell it to build for a
generic 386 a.out system?
TIA,
Eric
From daemon@csg.lbl.gov  Sun Dec 22 04:00:48 1996
From: daemon@csg.lbl.gov
Date: Sun Dec 22 04:00:50 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Dec 22 04:00:46 PST 1996
        Subject: subscribe
        Subject: Need help with non-standard loading (flash memory)
        Subject: Re: Background write to disk
        Subject: setsockopt problem on i960 target
        Subject: Re: debugging multiple tasks
        Subject: VxWorks Newbie - VME reads and Writes
        Subject: Help for MVME162lx Memory extension
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: subscribe
Date: Fri, 20 Dec 1996 12:51:45 GMT
From: Uri Porat <poratu@indigo.co.il>
Organization: Indigo Israel
Message-ID: <32BA8BE1.36FD@indigo.co.il>
Reply-To: poratu@indigo.co.il
Sender: news@indigo.co.il (News Administrator)
subscribe
- --
.--------------------------------------------------------------------.
| Uri Porat, Software Engineer (RnD)  Tel: (972-8)  38-95629/1818    |
| Indigo LTD, POB 150,                FAX: (972-8)  38-91-341/338    |
| Kiryat Weizmann,                    E-mail: poratu@Indigo.co.il    |
| Rehovot 76101, Israel               "My views are my own"          |
'--------------------------------------------------------------------'
---------------------------
Newsgroups: comp.os.vxworks
Subject: Need help with non-standard loading (flash memory)
Date: Mon, 16 Dec 1996 21:40:49 -0500
From: Martin Cooley <martinc@hotmail.com>
Organization: just me!
Message-ID: <32B60831.4C53@hotmail.com>
Does anyone have any experience loading an image from flash memory
rather than the traditional network/floppy/hard disk?
Any suggestions or pointers will be greatly appreciated.
Thanks,
- --
Martin Cooley
martinc@hotmail.com
I'nstitutionale de Neuron'c Impasse'
Departmente de Hemispheric Partitione
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Background write to disk
Date: Wed, 18 Dec 96 21:46:27 GMT
From: hjb@pso.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <599ol2$39q@idiom.com>
References: <59633p$104@news.ed.ray.com>
In article <59633p$104@news.ed.ray.com>, milesm@ed.ray.com (Michael Miles) wrote:
>In a system under development, we  are trying to write record data from
>a disk on our VxWorks target via nfs on a remote console.  We are doing
>this by having the console go out and look at the disk of the vsWorks
>target and record to its' own disk.  The problem is that this interferes
>with the real time operation of our system (of course).  I was wondering
>if anyone had any suggestions as to how to make this interference minimal
>or non-existant.  The disk write can be very low priority, and so I
>started by making my tasks higher priority than nfs, which helped a
>little.  I was thinking about changing the priority of the SCSI task from
>5 to say 100, as well.  Any input would be appreciated.
We had a similar problem while working on I/O to the emulated Disk on
FlashROM device.  The flash disk I/O is so slow that we ended up doing
all I/O on a temporary RAM disk which gets sync'ed to the flash in
the context of a very low priority task, or upon demand during
maintenance mode.
http://www.pso.com
mailto:hjb@pso.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: setsockopt problem on i960 target
Date: Tue, 17 Dec 1996 20:16:09 -0800
From: "John M. Oonk" <j.oonk@ix.netcom.com>
Organization: Netcom
Message-ID: <32B77009.6641@ix.netcom.com>
Reply-To: j.oonk@ix.netcom.com
We seem to be unable to turn off the Nagle algorithm in our socket
communication from target to host using TCP_NODELAY set on.
We were able to kludge around this problem but it is discouraging
that we could not change this behaviour. Our PC/NT host on the
other hand responded as expected to this setsockopt().
Has anyone had a similar experience and either found a satisfactory
workaround/fix or submitted this as a bug for the i960 target?
Thanks,
john_oonk@credence.com
Credence Systems Corp.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: debugging multiple tasks
Date: Thu, 19 Dec 1996 20:31:24 GMT
From: gerlach@netcom.com (Matthew H. Gerlach)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Message-ID: <gerlachE2oH0C.GGp@netcom.com>
References: <9612181254.AA13495@rst.co.il> <599p8t$39q@idiom.com>
Sender: gerlach@netcom19.netcom.com
>
>Besides, you shouldn't have to instantiate multiple GDB's anyway.  There
>is no need to create multiple GDB's to debug multiple tasks.  GDB source
>code is readily available and if you read the code there are amazing
>amount of code there.   GDB can attach and detach to different tasks
>anytime.  and there are zillions of GDB remote debugging protocols.
>GDB itself works pretty independently over many of these protocols
>and the protocol and stubs on both remote and host can be modified to
>do all kinds of things.
>
>
>http://www.pso.com
>mailto:hjb@pso.com
Actually, I never really like VxWork's task level debugging, for
the very reason that I normally have to debug multiple tasks or
interrupt handlers.  Therefore, I always use a "board" level debugger
like VxMon, Mon960, or the "standard" GDB remote debugging, as mentioned
above.
Matthew H. Gerlach
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks Newbie - VME reads and Writes
Date: 12 Dec 1996 14:16:34 GMT
From: popeyeman@aol.com (PopeyeMan)
Organization: AOL http://www.aol.com
Message-ID: <19961212141600.JAA02159@ladder01.news.aol.com>
I am new to the VxWorks world. We have a project to develop hardware
devices that hang off a VME bus. We have done that before but with a
different computer. Now we have to use the MVME 167 and VxWorks. My
problem is getting started. My company is too cheap to send me to class so
I have to learn this on my own.
What I am looking for is some starter code to read/write to/from the VME
bus to/from our hardware.
Any help would be great. Thanks. Ether respond here or e-mail to
popeyeman@aol.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Help for MVME162lx Memory extension
Date: Wed, 18 Dec 1996 16:59:35 +0100
From: Taurigna Monique <taurigna@lal.in2p3.fr>
Organization: In2p3
Message-ID: <32B814E7.167E@lal.in2p3.fr>
Hello,
I have a problem to extend the memory of my  MVME162 .
I have now a memory of 16 Mb intead of 4Mb .
I change in config.h the LOCAL_MEM_SIZE to 0x01000000 and generate the
new vxWorks and vxWorks.sym
But the new boot hang up afert loading "attaching networks interface"
Help me if you know this problem.
Thank you.
- ------------------------------------
: Monique Taurigna                  :
: LAL Facultes des sciences         :
: 91405 ORSAY  - France             :
: Email : taurigna@lal.in2p3.fr     :
- ------------------------------------
---------------------------
End of New-News digest
**********************
From froeber@bbn.com  Sun Dec 22 09:50:54 1996
From: Fred Roeber <froeber@bbn.com>
Date: Sun Dec 22 09:50:56 PST 1996
Subject: Re: VxVMI stuff
On Sat, 21 Dec 1996, Thomas K. Buchanan wrote:
> VxWorks is extrememly reliable and ultra-stable, your application
> may not be.  In a real-time embedded system where reliability and
> determinism is the first concern, concentrate on software quality
> assurance practices first.  Adding a level of fault tolerance by
> implementing task based virtual memory schemes should be way down
> on the list of methods to ensure stability.
Using a system with task based memory protection can be of great
benefit in finding quite a few types of program problems.  Quite a few
years ago at Raytheon I worked on a large "real-time" project that was
68000 based.  The run time system we helped write had task level memory
protection.  Most of the embedded systems I have worked on, however,
haven't had this feature.  When a group of us later designed and
developed a set of extensions for VxWorks to use as a common platform
across multiple projects, we felt it would be very important to support
task based protection based on the benefits we had seen on the project
that had it.  However, even though we implemented things like tightly
coupled multipprocessing and event logging (ala WindView) in advance of
Wind River's support for such things, we didn't implement task based
protection.  My claim has always been that the VxWorks architecture
isn't conducive to supporting this feature.  In particular, the fact
that VxWorks runs everything in supervisor mode and dynamically links
applications together make real complete support for such protection
practically impossible.
> WRS made the correct choice of not including VxVMI or task-based
> virtual memory spaces by default.  Using VM can have a huge impact
> on determinism.  It is pretty quick to change memory contexts but
> the performance of code execution just after the context switch is
> very non-deterministic.  I have authored a few SPARC BSP ports.  On
> a SuperSPARC, any instruction may take as little as 1/3 of a clock
> cycle to execute if in the cache or as many 40 clock cycles is not in
> the cache.  You always have this problem to a certain extent but if
> you are changing memory contexts very often, you'll encounter
> invalidated caches & MMU page definitions not in the TLB much more
> often.
One of the big reasons we didn't try harder to implement even any sort
of limited task level protection into our VxWorks extensions was that
the non determinism and time/memory overhead required to support
dynamic protection is significant.  Without getting into details, I
have spent a lot of time looking at detailed timing of systems with
memory protection including UNIX systems as well as embedded systems.
I fully concur with Thomas that there are real performance implications
of using protection.  I further agree that VxWorks is targeted at a
different market; one where you need absolute performance and fully
deterministic and reliable operation.  Under VxWorks, if you write a
reliable application it will run very reliably.  VxWorks won't help you
easily catch certain types of problems in buggy applications.  If you
use an OS with memory protection, it might help you find your problems
in buggy applications easier.  However, it won't always run your
application reliably if that application has tight timing constraints.
This is true even if the application is bug free.  That's an important
thing to consider.
> The dirty truth is that caches, MMUs, TLBs etc have a measurable impact
> on determinism.  Implementing task-based VM protection makes that
> non-deterministic behaviour a much larger factor, usually large enough
> that you can't ignore it.  If you can live with it, you should look at
> some of the 'real-time' Unix OSes or Solaris.  VxWorks was intended for
> a different sort of mission.
I couldn't agree with these statements more completely.  Very little has
been published on the quantitative performance aspects of MMUs that I have
ever found.  One of the only good articles I have ever seen was in the
May 1993 issue of Embedded Systems on "The Perils if PC Cache" which showed
how having the MMU and cache enabled could cause a 300% spread in timing
for an interrupt handler.  This isn't inconsistent with what I have measured
in various systems.  There just so happens to be an article on using memory
protected OSes in this month's issue of Embedded Systems.  It is by Dan
Hildebrand from QNX.  Their OS is one of the class of 'real-time' Unix
OSes that could be appropriate for systems that don't have tight real time
constraints.  I would be interested in hearing from anyone who has references
to any more hard data on MMU performance effects.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
From tkb@mclean.sparta.com  Sun Dec 22 19:17:26 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Sun Dec 22 19:17:28 PST 1996
Subject: Re: VxVMI stuff
>Submitted-by: Fred Roeber <froeber@bbn.com>
>Using a system with task based memory protection can be of great
>benefit in finding quite a few types of program problems.  Quite a few
>years ago at Raytheon I worked on a large "real-time" project that was
>68000 based.  The run time system we helped write had task level memory
>protection.  Most of the embedded systems I have worked on, however,
I agree 100%... in fact I strongly suggest testing smaller pieces of large
embedded projects in a Unix environment before running it in Wind River's
single name space.  It does help catch a number of classic 'C' programming
problems.  Keep in mind that all types of memory errors will not get caught,
only those that trigger access exceptions by the MMU.
>protection.  My claim has always been that the VxWorks architecture
>isn't conducive to supporting this feature.  In particular, the fact
>that VxWorks runs everything in supervisor mode and dynamically links
>applications together make real complete support for such protection
>practically impossible.
It makes it very difficult, an application must be planned from the start
with this in mind.  The use of user/supervisor mode helps to protect the
interface with the kernel but isn't a major factor in systems where security
isn't of concern.
We've been doing a lot of Solaris OBP and driver work lately.  Bottom line:
the most popular Unix OS also makes VM task protection very tough to use.
Writing code to coexist with a multi-threaded kernel and interact with task
contexts is like pulling teeth.  If WRS implemented VM, writing drivers and
libraries would become much more difficult.
>I couldn't agree with these statements more completely.  Very little has
>been published on the quantitative performance aspects of MMUs that I have
>ever found.  One of the only good articles I have ever seen was in the
That would be a great series of articles, sure to stir up a lot of
commentary.
Embedded Systems professionals are using some of the latest greatest
super-scalar architectures, taking advantage of their incredible statistical
performance.  We need to keep in mind that the great technologies used to
achieve these statistically awesome throughput numbers were tuned for
desktop applications.  These CPUs come in very handy but don't forget the
laws of physics.  Faster memory, peripherals w/ FIFOs, greater data path
widths, some caching algorithms, etc. give us characterizable linear
improvements to the throughput of an embedded system.  Many other
improvements need to be analyzed from a different perspective than our
desktop/scientific app generating brethren.  SPARC International, the
PowerPC Consortium, MIPS, DEC, and Intel did not have us in mind when...
adios
From p72950@gmcl.co.uk  Mon Dec 23 01:51:02 1996
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Mon Dec 23 01:51:04 PST 1996
Subject: Re: Help for MVME162lx Memory extension
Hi there
Try rebuilding the bootroms with the new memory map by typing
'make bootrom.hex'. You will then need to blow the resulting SRecord file
(bootrom.hex) into a suitable EPROM.
Doing this will ensure that the extra memory is initialised & may fix
the problem. Its worth a try anyway ;)
Regards,
Phil Quiney
>Hello,
>
>I have a problem to extend the memory of my  MVME162 .
>I have now a memory of 16 Mb intead of 4Mb .
>I change in config.h the LOCAL_MEM_SIZE to 0x01000000 and generate the
>new vxWorks and vxWorks.sym
>But the new boot hang up afert loading "attaching networks interface"
>
>Help me if you know this problem.
>
>Thank you.
>
>- ------------------------------------
>: Monique Taurigna                  :
>: LAL Facultes des sciences         :
>: 91405 ORSAY  - France             :
>: Email : taurigna@lal.in2p3.fr     :
>- ------------------------------------
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From leonid@rst.co.il  Mon Dec 23 02:56:25 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Mon Dec 23 02:56:28 PST 1996
Subject: Re: Opinion about Win95 Tornado
This with respect to the recent discussion regarding Tornado on Windows
and it's stability. This is an important issue, but there is something
missing in this discussion this far, there is too much emotion and too
little hard facts.
Our experience shows that there is significant difference in stability
of Tornado on different versions of Windows OS, and it also depends on
different configuration issues.
Our experience shows us that Windows NT 3.5 and 3.51 is probably the
best PC platform for Tornado, which was developed originally with this
particular system.  Windows NT 4.0 Beta on the other hand was
practically unusable with Tornado (it was never claimed to be supported
by WRS).
Also, serial target connection at high speeds, e.g. 38400 has problems
on different PCs, while on others it works well.
What I would suggest, is that for everybody who have expressed on
opinion about Tornado on Windows, please let us know on which version
of Windows you used, and which target communications link.  Also, let
us know if you have installed any significant changes on to Windows,
e.g. third party WINSOCK DLL, etc.
This way this forum can come very handy for new and potential users,
and help them with the choise of their host platform.
[ standard sisclaimer should be appropriate here ... ]
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From cdunn@nswc.navy.mil  Mon Dec 23 14:17:09 1996
From: cdunn@nswc.navy.mil
Date: Mon Dec 23 14:17:11 PST 1996
Subject: Problem with cacheDisable()
Has anyone had problems disabling the data cache using vxWorks 5.2
or Tornado on a Power PC 603 (MV1603 board)?  We've noted occasional
problems with cacheDisable(1) hanging up the machine. This occurs
both from the shell and within a program, but is very intermittent.
The machine hangs up with no other indications, and the problem has
occured with Tornado as well as 5.2 for Power PC.
We wrote a simple test to loop a million times while calling
cacheDisable(1) to disable the data cache and cacheEnable(1) to
re-enable it. The machine eventually hangs, although it frequently
takes several hundred thousand passes through the loop (the test prints
out the loop count).
Has anyone had similar experiences or have any thoughts on this?
Thanks,
Curtis
From daemon@csg.lbl.gov  Tue Dec 24 04:00:20 1996
From: daemon@csg.lbl.gov
Date: Tue Dec 24 04:00:24 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Dec 24 04:00:18 PST 1996
        Subject: Re: FLASH file system support?
        Subject: Re: VxVMI stuff
        Subject: SALE: MVME167 33Mhz 16MB VME card
        Subject: BUY FORCE10 50mhz
        Subject: ftp boot problem - addendum
        Subject: VxWorks flock ?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: FLASH file system support?
Date: Thu, 19 Dec 1996 17:50:39 -0800
From: John Finley <john@finley.com>
Organization: Netcom
Message-ID: <32B9F0EF.B33@finley.com>
References: <32B6D2EA.2F88@HiWAAY.net>
Reply-To: john@finley.com
David Leviner wrote:
> I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH (Intel
> 28F016 chipset) and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM
> for the embedded application and 3 MBytes of FLASH is to be used as a "FLASH disk" for
> storing his applications. I am running the text section of VxWorks (instructions,
> constants,etc.) in the first 1MByte of FLASH and the data section of VxWorks (i.e., C
> variables) in DRAM.
You are probably aware that you'll have to be tricky about updating
the same flash chip that your OS is in.  I assume you have two '016s
side-by-side to make 2M x 16, so any update to something in the 3 MB
FS space will mean updating the same chips VxWorks is in.  You either
have to disable all interrupts, so, for example, a clock tick doesn't
vector to some code in flash while the flash chip is off erasing some
sectors, or relocate ISRs and flash-update code to DRAM.  Even though
you execute from a separate area of flash, I think the whole chip is
inaccessible while an erase or write is in progress.  This is how AMD
29Fxxx chips work; I only assume Intel is similar.
> Does anyone know of a VxWorks FLASH file system driver that can be used for this type of
> BSP? And does anyone know of a device driver with read/write/erase, etc. support for the
> Intel 28F016 FLASH device.
I've only heard of file systems from M-Systems or RST, but not
necessarily for your board.  The driver code is really simple (again,
assuming Intel's comparable to AMD).
Hopefully helpful, or at least not misleading,
John
- --------------------------------------------------
John Finley                 Engineering Consultant
john@finley.com                  Real Time Systems
(619) 689-0032                Networking Protocols
- --------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxVMI stuff
Date: Fri, 20 Dec 1996 15:11:28 +0100
From: Torsten Rupp <rupp@fzi.de>
Organization: University of Karlsruhe, Germany
Message-ID: <32BA9E90.2781E494@fzi.de>
References: <599o2c$idr@news.sei.cmu.edu>
Theodore Marz wrote:
> What I have done is establish a map "hole" around the stack / tcb.
I have tried this, too, but without good success. It is possible to
place such a hole at the top and bottom of the stack, but if the stack
is overflowing then you will get on a MC680x0 a double bus error,
because all tasks are running in supervisor mode (Motorola suggested to
do this _only_ in kernel or operation system routines) and therefore the
supervisor stack is already in use and can not be used for processing
the MMU exceptions (data which have to be saved on the suppervisor stack
will cause a second access fault by the MMU). I think this is one more
example that is not possible to make vxWorks more reliable and stable.
It is only a fast system, but imho that's not enough. If one task is
crashing then the whole system will be going down most the times.
But, nevertheless, thank you for posting your code example for protected
tasks in vxWorks. Maybe there will be a solution for the MMU-problem in
the near future. I hope it.
 Torsten Rupp
- --
Information Science Research Center at the University of Karlsruhe
Technical Expert Systems and Robotics   phone:   +49-721-9654-302
Haid-und-Neu-Str. 10-14                 fax  :   +49-721-9654-309
D 76131 Karlsruhe (Germany)             e-mail:  rupp@fzi.de
---------------------------
Newsgroups: comp.os.vxworks
Subject: SALE: MVME167 33Mhz 16MB VME card
Date: Wed, 18 Dec 1996 10:25:58 -0800
From: Innovative Research Technologies <Sales@innovative-research.com>
Organization: Netcom
Message-ID: <32B83735.2CAA@innovative-research.com>
Reply-To: Sales@innovative-research.com
I have available a qty of (1) Motorola - MVME167 68040 33Mhz 16MB VME
card.
E-mail if interested or for more information.
E-Mail: Marty@innovative-research.com
Thanks.
---------------------------
Newsgroups: comp.os.vxworks
Subject: BUY FORCE10 50mhz
Date: Thu, 19 Dec 1996 19:07:57 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: A customer of Pacific Bell Internet Services
Message-ID: <32BA030D.12CD@pacbell.net>
Reply-To: dcaustin@pacbell.net
Any FORCE10 50mhz 6U cards with 64MB for sale?
Duane
---------------------------
Newsgroups: comp.os.vxworks
Subject: ftp boot problem - addendum
Date: Thu, 19 Dec 1996 18:16:48
From: herb@pktr.desy.de
Organization: DESY PKTR
Message-ID: <herb.58.0012483E@pktr.desy.de>
Forgot to mention - the booting problem refers to vxW 5.1 running
on an MVME162 .
                                               S. Herb
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks flock ?
Date: Tue, 24 Dec 1996 12:48:21 +0100
From: Vincent HUE <vincent.hue@met.fr>
Organization: MET
Message-ID: <32BFC305.41C67EA6@met.fr>
Hello
As anyone made a 'flock' function (or 'fcntl(F_SETLK)')
for VxWorks ?
Thanks in advance,
/vincent
- --------------------------------------------------
Vincent HUE              SDH/ATM Software Engineer
MET Commutation, 19 av Carnot 91348 MASSY / France
Tel.: +33-1 64 47 51 30  - Fax : +33-1 64 47 57 45
Email : vincent.hue@met.fr  -  Memoid : met.metvhe
---------------------------
End of New-News digest
**********************
From page@rocko.mit.edu  Tue Dec 24 06:35:48 1996
From: "Russell J. Page, Sr." <page@rocko.mit.edu>
Date: Tue Dec 24 06:35:49 PST 1996
Subject: Foundation FieldBus
This is a multi-part message in MIME format.
--------------C3F2E74415
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Does anyone have any experience with Foundation FieldBus and EPICS ?
Specifically, are there any drivers under R3.13.0.Beta4 ?
							Thanks
							Russ
--------------C3F2E74415
Content-Type: text/plain; charset=us-ascii; name="my_signature.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="my_signature.txt"
-----------------------------------------------------------------
|Russell J.Page, Sr.		    Phone (617) 253-9585	|
|Mass. Institute of Technology	    FAX   (617) 253-9799	|
|Bates Linear Accelerator Center				|
|PO Box 846			    email :page@rocko.mit.edu	|
|Middleton, MA  01949		    http://mitbates.mit.edu/	|                     |
-----------------------------------------------------------------
--------------C3F2E74415--
From punamia@falcon.kla.com  Tue Dec 24 11:51:48 1996
From: punamia@falcon.kla.com (Manoj Punamia)
Date: Tue Dec 24 11:51:50 PST 1996
Subject: send signal to a task
Which vxWorks5.3 function call would be compatible with function
 "sigRaise(tid, signo, NULL)" in vxWorks5.0.2.
The VxWorks5.3 reference manual  describes the following two
1.  kill(tid, signo) - send a signal to a task (POSIX).
2.  sigqueue(tid,signo,value) - send a queued signal to a task.
To send signal with no signal-parameter, could I use either one ?
Thanks
Manoj Punamia
From daemon@csg.lbl.gov  Wed Dec 25 04:00:18 1996
From: daemon@csg.lbl.gov
Date: Wed Dec 25 04:00:22 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Dec 25 04:00:15 PST 1996
        Subject: Help ! problem with DC21140A ethernet driver
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Help ! problem with DC21140A ethernet driver
Date: Tue, 24 Dec 1996 05:30:40 +0000
From: Hung Tran <hung@dynatem.com>
Organization: Dynatem
Message-ID: <32BF6A80.62FF@dynatem.com>
Hi all,
I am trying to port the "if_dc.c" ethernet driver into our BSP (a Pentium
based CPU).
1. The device is the DEC 21140A Fast Ethernet LAN Controller device.
2. We are using the mii (as supposed to srl) interface running at 10Mb/s.
3. The network seems to work fine under Win NT, so I suppose the hardware
(our customize Pentium CPU) is OK.
4. Under vxWorks, however, my ethernet driver always hang up upon power up. It
only works after a couple of hard reset (via the front panel reset button).
Further look into the driver reveals that it would hang up right when the
first transmit packet is attempted. The device would never release the transmit
descriptor OWN bit (TDESC0, bit 31), and CSR5<22:20> = 010 indicating waiting
for end of tranmission while CSR5<10> = 1 signaling an early transmit interrupt.
The receive process would works fine the whole time (it is interrupt driven).
Once the first packet got transmit (after a couple of hard reset), everything
works perfectly.
I suspect that the problem is with my software initialization routine. However,
I have tried numerous configuration to no avail, and the strange thing is that
it would eventually work after a couple of reset. I would appreciate if anyone
can provide us any idea or recommendation on where to check in either software
or hardware. By the way, the hardware interface between the DEC 21140A and the
physical media is an ICS1890.
Thank you in advance,
Hung Tran
---------------------------
End of New-News digest
**********************
From daemon@csg.lbl.gov  Thu Dec 26 04:00:20 1996
From: daemon@csg.lbl.gov
Date: Thu Dec 26 04:03:14 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Dec 26 04:00:18 PST 1996
        Subject: tty driver
        Subject: Re: PPC SCSI (MV160X)
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: tty driver
Date: Sat, 21 Dec 1996 19:33:03 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: A customer of Pacific Bell Internet Services
Message-ID: <32BCABEF.221A@pacbell.net>
Reply-To: dcaustin@pacbell.net
Can anyone help me please?
I have a low priority process that does a lot of output via the tty
driver.  The output in this low priority process, via the tty driver, is
effecting a high priority and time critical prcoess (as much as 3
milliseconds).
I don't think the tty driver is taking advantage of DMA on the serial
port.  Can I modify the tty driver (via ioctl() maybe?) so that the i/o
will not effect my time critical process?
Target = FORCE 10 (superSparc)
VxWorks version 5.2
Thanks for any help
Duane Austin
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: PPC SCSI (MV160X)
Date: Fri, 20 Dec 1996 16:24:34 -0500
From: hogle@crd.ge.com (Rich Hogle)
Organization: GE Corp R&D Center, Schenectady NY
Message-ID: <hogle-2012961624340001@tam.crd.ge.com>
References: <32B510DA.63B4@llnl.gov>
Doug,
I'm using a 4GB Quantum drive with a MVME-1604 and an MVME760
transition module and am not having any problems.  I'm not using VxWorks, but
have a different flavor RTOS.
Rich Hogle
GE-CRD
hogle@crd.ge.com
In article <32B510DA.63B4@llnl.gov>, owens2@llnl.gov wrote:
> Hello,
> Does anybody out there have SCSI working on a Motrorla MV160X board?  We
> haven't succeeded with either the on-board (ncr825) or a 3rd party
> (Macrolink MVS216) driver and hardware.  We are using the -001 baseboard
> with the MV760 Transition Module.
>
> Thanks,
> Doug Owens
> owens2@llnl.gov
---------------------------
End of New-News digest
**********************
From tunch@dominet.in.com.tr  Thu Dec 26 05:20:10 1996
From: tunch@dominet.in.com.tr (Tunc Hoscan)
Date: Thu Dec 26 05:20:13 PST 1996
Subject: help list
help list
From tkb@mclean.sparta.com  Thu Dec 26 09:40:07 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Thu Dec 26 09:40:09 PST 1996
Subject: Re: tty driver
>I have a low priority process that does a lot of output via the tty
>driver.  The output in this low priority process, via the tty driver, is
>effecting a high priority and time critical prcoess (as much as 3
>milliseconds).
It's hard to imagine how your low priority task can delay your high
priority task for 3ms.  The tty driver send data out one char at a time,
the worse effect you should see are periodic delays due to the ISR.  If you
really have a 3ms delay, you have designed in some priority inversion
somewhere.  Do you have critical regions of code protected by
semTake/semGive, taskSuspend/taskResume or taskLock/taskUnlock pairs
somewhere?  They can have an accumulative effect.
>I don't think the tty driver is taking advantage of DMA on the serial
>port.  Can I modify the tty driver (via ioctl() maybe?) so that the i/o
>will not effect my time critical process?
The default tty drivers do not use DMA nor is there an enabling ioctl call.
 If you can live with delays due to the ISR used by the tty driver, the I/O
is not your problem.  You must have other scheduling problems.
adios
From froeber@bbn.com  Thu Dec 26 12:14:14 1996
From: Fred Roeber <froeber@bbn.com>
Date: Thu Dec 26 12:14:17 PST 1996
Subject: Re: tty driver
the vxWorks Users Group Exploder wrote:
>
> Submitted-by daemon@csg.lbl.gov  Thu Dec 26 04:00:20 1996
> Submitted-by: daemon@csg.lbl.gov
 Duane C Austin writes:
> I have a low priority process that does a lot of output via the tty
> driver.  The output in this low priority process, via the tty driver, is
> effecting a high priority and time critical prcoess (as much as 3
> milliseconds).
You don't say what type of processor you are using but the serial driver
usually only impacts tasks during the time that the serial interface
chip interrupt is being processed.  This interrupt can take tens of
microseconds per character output but certainly won't take milliseconds.
You also don't classify what you consider high and low priority.  The
network task at priority 50 may occasionaly be woken up to respond to
broadcast messages on the network like routing table messages that you
aren't expecting.  This could cause somewhat longer delays (but still
not 3 msec).  The only real way to get the details on a problem
like this is to use the Wind River WindView product.  It will quickly
show you exactly what is taking up the 3 msec you are losing.  Good
luck.   Fred
--
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
From cruise@cfht.hawaii.edu  Thu Dec 26 19:44:24 1996
From: Bill Cruise <cruise@cfht.hawaii.edu>
Date: Thu Dec 26 19:44:26 PST 1996
Subject: rstatd
Does anyone use an rstat daemon to assist in monitoring their vxWorks
systems across the net?  If not, do you have other ways of remotely
looking at cpu loading?
I am interested in any available solutions.  Just to throw in a
filter, we run Sparc vxWorks cpu's.
Thanks for your help,
--
William L. Cruise                             cruise@cfht.hawaii.edu
Electronics System Supervisor                   FAX:    808 885-7288
Canada-France-Hawaii Telescope                  Voice:  808 885-3122
P.O. Box 1597                     http://www.cfht.hawaii.edu/~cruise
Kamuela, HI   96743
From daemon@csg.lbl.gov  Fri Dec 27 04:00:14 1996
From: daemon@csg.lbl.gov
Date: Fri Dec 27 04:00:18 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Dec 27 04:00:11 PST 1996
        Subject: PR: NobleNet RPC 3.0
        Subject: flock for VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: PR: NobleNet RPC 3.0
Date: Fri, 27 Dec 1996 07:50:59 GMT
From: Alex Valentine <alexv@noblenet.com>
Organization: NobleNet, Inc.
Keywords: NobleNet, Client/Server, Remote Procedure Call, RPC, ONC, XDR, TCP/IP, Middleware, Tool, OneDriver ODBC SDK, Secure, API, EZ-RPC, Communications, Developer, Software, Windows, Unix, Macintosh, VxWorks, VMS, Internet, Intranet
Message-ID: <E32B4z.88D@world.std.com>
Followup-To: poster
Reply-To: noblenet@world.std.com
Sender: noblenet@world.std.com (NobleNet Inc.)
PRESS RELEASE
For Immediate Release
For Further Information, Please Contact:
Alex Valentine
Director of Product Management
NobleNet, Inc.
Voice: (508) 460-8222
FAX: (508) 460-3456
e-mail: alexv@noblenet.com
NobleNet RPC 3.0(TM) is World's Most Advanced RPC Environment
 New Remote Procedure Call Middleware Gains Enterprise Services
Southboro, MA, December 17, 1996 -- NobleNet introduces RPC 3.0, the
third generation of the most advanced and customer-proven Remote
Procedure Call middleware.  NobleNet RPC 3.0 contains important new
features such as integrated security, naming, load balancing,
asynchronous operation, multi-threading, and server management.
Employing state-of-the-art technology, the product slashes development
time for distributed applications by automatically generating client/
server network code for all program data structures and Application
Programming Interfaces (APIs).  NobleNet RPC 3.0 is firewall-aware and
provides developers with everything necessary to distribute today's
complex enterprise-wide client/server applications across the Internet,
corporate intranets, and the World Wide Web.
"Business Travel Solutions (BTS) is a three-tiered client/server
system... NobleNet RPC 3.0 is used for all communication between the
clients and the application servers... With NobleNet RPC 3.0 it's real
easy to include security and load balancing on the servers," said Mark
Wedge, one of the principal programmers on BTS, SABRE Decision
Technologies'SM new high performance on-line corporate travel booking
and management project.  SABRE, now an independent company, was formerly
owned by AMR Corporation, the parent of American Airlines.
"SABRE Decision Technologies is a consulting company that is definitely
interested in exploiting the advantages we have," said Richard
Pendergast, Senior Programmer-Consultant.  "We have a lot of experience
in building large systems for large volumes of users - we understand
that business... We are looking for the best tools to bring that about.
We are very happy with NobleNet."
Based on the industry-standard ONC/RPC, NobleNet RPC 3.0 supports
additional complex data types that allow programmers to avoid tedious
hand coding.  Extended RPC types such as batch, broadcast, forking,
nowait, callback, asynchronous, and send-reply, support the design of
sophisticated business applications.  In addition, advanced server
models such as process-per-server, multi-threaded server, and
multi-client server allow for optimization of high volume business
applications.
NobleNet RPC 3.0 can distribute any application or API automatically.
Its powerful IDL compiler generates RPC DLLs for Windows 3.1, 95, and
NT that are callable from 4GLs such as Visual Basic, PowerBuilder,
Delphi, and Developer/2000, and RPC NLMs for NetWare.  NobleNet RPC 3.0
applications can find their way through "well-known" ports on corporate
firewalls allowing for deployment of client/ server applications across
the Internet and corporate intranets.
"When we developed our latest version of Optix, we needed an
industry-standard technology for communicating between client and
server, a technology that would work across all the platforms we
support and help us provide our customers with a robust set of APIs,"
said Keith Ellis, Vice President of Marketing and Sales for Blueridge
Technologies, The Internet Document Management Company.  "NobleNet
products meet these criteria with room to spare."
NobleNet RPC 3.0 is priced at $5,000 per developer seat plus a one-time
distribution charge for application deployment and is available on
virtually all platforms including the most popular UNIXes, Windows 3.1,
95, and NT, Macintosh, OpenVMS, and VxWorks.  NobleNet RPC 3.0 with
threading, naming, load balancing, and server management, combined with
NobleNet Secure(TM) and/or NobleNet ODBC(TM) form a comprehensive
standards-based Network Computing Environment (NCE)(TM).  Significant use
of multiplexed RPC streams and dispatch capabilities optimizes
application efficiency and performance when the products are used
together.
NobleNet offers client/server middleware for procedural and object
paradigms.  Incorporated in 1991, NobleNet is the world leader in
Remote Procedure Call (RPC) technology and has won numerous awards for
its product family.  The company headquarters in Southboro,
Massachusetts can be reached by telephone at (508) 460-8222 or at
<http://www.noblenet.com/>.
Optix and The Internet Document Management Company are trademarks of
Blueridge Technologies, Flint Hill, VA <http://www.blueridge.com/>
SABRE Decision Technologies is a service marks of SABRE Group Holding,
Inc., Southlake, TX <http://www.sabre.com/>
---------------------------
Newsgroups: comp.os.vxworks
Subject: flock for VxWorks
Date: Fri, 27 Dec 1996 09:31:15 +0100
From: Vincent HUE <vincent.hue@met.fr>
Organization: MET
Message-ID: <32C38953.41C67EA6@met.fr>
Hello,
Has anyone made a 'flock()' or 'fcntl(F_SETLK)' ?
Thanks in advance.
vincent
- --------------------------------------------------
Vincent HUE              SDH/ATM Software Engineer
MET Commutation, 19 av Carnot 91348 MASSY / France
Tel.: +33-1 64 47 51 30  - Fax : +33-1 64 47 57 45
Email : vincent.hue@met.fr  -  Memoid : met.metvhe
---------------------------
End of New-News digest
**********************
From 100067.355@compuserve.com  Fri Dec 27 05:22:03 1996
From: Philippe Weber <100067.355@compuserve.com>
Date: Fri Dec 27 05:22:05 PST 1996
Subject: RE: rstatd
> From: Bill Cruise <cruise@cfht.hawaii.edu>
> Date: Thu Dec 26 19:44:26 PST 1996
> Subject: rstatd
>
> Does anyone use an rstat daemon to assist in monitoring their vxWorks
> systems across the net?  If not, do you have other ways of remotely
> looking at cpu loading?
>
> I am interested in any available solutions.  Just to throw in a
> filter, we run Sparc vxWorks cpu's.
>
> Thanks for your help,
>
> --
>
>
> William L. Cruise                             cruise@cfht.hawaii.edu
> Electronics System Supervisor                   FAX:    808 885-7288
> Canada-France-Hawaii Telescope                  Voice:  808 885-3122
> P.O. Box 1597                     http://www.cfht.hawaii.edu/~cruise
> Kamuela, HI   96743
>
>
Bill,
I have an adaptation of  'loadMeter', a piece of code I once found on the
net, on which I have ported an RPC library just to make it rstatd-like. It
allows using tools like 'perfmeter' to monitor your VxWorks target from a
Sun host. As far as I remember, you can monitor CPU load and network
activity. Guess what, it works on Themis SPARC CPUs.
Drop me a line if you're interested, I'll send you a copy.
--
*************************************
* Philippe WEBER                    *
* THEMIS COMPUTER                   *
* 1, rue des Essarts                *
* 38610 GIERES, FRANCE              *
* Voice : +33 (0)476 59 60 46       *
* Fax   : +33 (0)476 63 00 30       *
* E-mail: phil@themis.com           *
*************************************
From daemon@csg.lbl.gov  Sat Dec 28 04:00:15 1996
From: daemon@csg.lbl.gov
Date: Sat Dec 28 04:00:18 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Dec 28 04:00:11 PST 1996
        Subject: Re: VxVMI stuff
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxVMI stuff
Date: Mon, 23 Dec 1996 17:52:51 +0100
From: Torsten Rupp <rupp@fzi.de>
Organization: University of Karlsruhe, Germany
Message-ID: <32BEB8E3.446B9B3D@fzi.de>
References: <3.0.32.19961221161938.006a461c@mailhost.mclean.sparta.com>
Thomas K. Buchanan wrote:
> >>                                              I think this is one more
> >>example that is not possible to make vxWorks more reliable and stable.
>
> VxWorks is extrememly reliable and ultra-stable, your application
> may not be.
Maybe I have not made a good expression of what I mean. I'am sorry for
this. Of course vxWorks is very reliable and stable if none of the tasks
make an error. Therefore it is legal and correct to say "if your
application tasks are error-free then the system is reliable and
stable". But in the real world it is very difficult to write error-free
programs. Maybe you will now say that this is a problem of the bad
capability of the person who writtes the code, but who is able to write
error-free programs (except small tivial programs)? I'am not and to
handle a system which is a) written by more then one person (with
difference experience in programming) and b) of the size of serveral
100000 lines of code is not trivial. Therefore I'am looking for some
help and one thing is a protected environment for different tasks. It
would be enough for my application with vxWorks if an illegal memory
access is detected, logged and the task is suspended and then a suitable
function will be called to shut down the system (I have to control a
robot with vxWorks and therefore it is not very good if the robot
crashes with a wall because the motor controlling task was been killed
by some other buggy task or something else).
 Torsten
- --
Information Science Research Center at the University of Karlsruhe
Technical Expert Systems and Robotics   phone:   +49-721-9654-302
Haid-und-Neu-Str. 10-14                 fax  :   +49-721-9654-309
D 76131 Karlsruhe (Germany)             e-mail:  rupp@fzi.de
---------------------------
End of New-News digest
**********************
From tkb@mclean.sparta.com  Sat Dec 28 10:12:23 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Sat Dec 28 10:12:25 PST 1996
Subject: Re: VxVMI stuff
>> VxWorks is extrememly reliable and ultra-stable, your application
>> may not be.
...
>stable". But in the real world it is very difficult to write error-free
>programs. Maybe you will now say that this is a problem of the bad
>capability of the person who writtes the code, but who is able to write
>error-free programs (except small tivial programs)? I'am not and to
>handle a system which is a) written by more then one person (with
>difference experience in programming) and b) of the size of serveral
>100000 lines of code is not trivial. Therefore I'am looking for some
It's not trivial, it is extremely difficult.  The first preventative
measure should be a comprehensive software quality assurance program.  The
clue to writing stable and reliable large systems is hidden above.  We can
write "perfect" small programs.  Any software solution can be broken down
into small testable elements.  Integration is always painful but testing
the individual pieces as they are coded will eliminate the kinds of bugs VM
task protection will detect for you.
>help and one thing is a protected environment for different tasks. It
>would be enough for my application with vxWorks if an illegal memory
>access is detected, logged and the task is suspended and then a suitable
>function will be called to shut down the system (I have to control a
>robot with vxWorks and therefore it is not very good if the robot
>crashes with a wall because the motor controlling task was been killed
>by some other buggy task or something else).
The hardest errors to find in a real-time multitasking system are usually
related to mutual exclusion, priority inversion, scheduling conflicts,
intertask communications errors etc.  Unfortunately, protected task
environments don't help with these types of errors.
Although I argue against it, it is possible to implement task-based
protection.  You can use VxVMI and taskHookLib to implement some level of
task protection.  Unless you have a source license, the interface with the
kernel is tough.  You'll have to compromise, every task context you create
will have to include read/write access to kernel data areas.  In addition,
you must design your application so that shared code and data areas are
easily handled.  If you want to be really thorough, you should modify the
I/O subsystem.  I prepared an estimate for accomplishing this work for a
customer, it could take over 4 man-years of effort by senior software
engineers to implement task based VM on a single architecture.
You'll end up with a much larger, more sophisticated kernel.  The volume of
code needed to manipulate the VM contexts may exceed that of your application.
Consider the types of errors that the task protection will not prevent.
Many very common capable CPUs ( like the CPU32 family ) do not have VM,
does that mean we give up on writing reliable large apps on such platforms?
 The moral of the story:  if you can afford the affects on determinism and
you're in love with VM task protection, switch to Unix or a "real-time
Unix" kernel.  MMUs, caches and the capabilities that come with them are
handy, but not tailored for use in hard real-time applications.  The types
of software bugs habitually present in desktop and scientific apps that run
under Unix/WinNT are not acceptable in embedded software.  These demands on
our work product are what make us a somewhat elite group ( and hopefully
better paid ).
adios
From leonid@rst.co.il  Sat Dec 28 23:54:45 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sat Dec 28 23:54:48 PST 1996
Subject: Re: System reliability (was: VxVMI stuff)
On Mon, 23 Dec 1996 Torsten Rupp <rupp@fzi.de> writes:
> Therefore it is legal and correct to say "if your
> application tasks are error-free then the system is reliable and
> stable".
This is not as simple as it sounds, to make a system like that,
which does not introduces any errors of its own into the system
is a great job. However, this system (unlike UNIX) does not
have a requirement to keep the system, running if one particular
application crashes. This has to do with the whole oncept of embedded
software, where the entier application software, and hardware, a lot
of which is application specific, is considered "a single application",
and VxWorks is only a part thereof. Such applications are designed,
developed and tested as whole systems. A customer in the field is
not supposed to add a new module to such a system, thereby changing the
operating conditions, and break the system.
> But in the real world it is very difficult to write error-free
> programs.  ... a) written by more then one person (with
> difference experience in programming) and b) of the size of serveral
> 100000 lines of code is not trivial.
Software has never been easy or trivial, it's a hard trade.
Nevertheless, there exist a lot of knowledge accumulated
over more then 20 years of experience, which is called SOftware Engineering.
Although not (yet) considered a Science by its own right,
it is a collection of many studies, methods and practices to
assist in producing quality software within reasonable budget.
Management theories and practices which deal with quality, (like TQM)
are also applicable to the process of software development.
You can get away with an amateur programmer writing
a couple of small programs in Visual Basic or Access,
(in fact most PC progremmers I know are in fact amateurs, despite
their academic degrees in different fields, except software).
It is far from being enough to know the "C" lagnuage in
order to produce quality software in the real-time or embedded areas.
Having said that, it is true that as software complexity grows,
the chanses of program erros increases. 20 years ago Fault Tolerant
systems where designed in order to survive hardware failures.
Nower days, the hardware is sometimes much more reliable then sodftware.
During one project we done for a customer, we termed the solution
as "Fault Reselience". The purpose was to use different methods
to detect software errors, log them for later analisys, and then
the idea is to RESTART the system. Most people would think that if
a *minor* software error occured, they would like to somehow
recover from it without restarting the system. Turned out that it
is never possible to say how *serious* is the error which
in turn caused the *minor* error, and thus the only safe method
to recover is to RESTART the system.
This was a complex project, and required us to interfere in the way
VxWorks does certain things. I hope that some day I will find some
time to write an article about this project, but I am sure that such
solutions are implemented in many products.
> Therefore I'am looking for some
> help and one thing is a protected environment for different tasks. It
> would be enough for my application with vxWorks if an illegal memory
> access is detected, logged and the task is suspended and then a suitable
> function will be called to shut down the system ...
We have also tried to do this with VxVMI, and protect the stack
with "pae holes" on both ends, and we too have hit the Double Fault
problem, which halts the processor.
An alternative approach is to insert more run-time checking
in to the application code. Writing "assert()" statements all over your
code is a very recommended practice. Don't think twice about it,
if there is something you can check for sanity, done trust your
other functions or modules, dont trust yourself, put that test in.
Later you can remove these "assert" statements simply by defninigng NDEBUG.
Another issue, is the run-time checks which can be produced by
the compliler. There is an experimantal version of GCC which
has some run-time checks, but we have never experimented this yet.
This should be a very effective approach too.
> (I have to control a
> robot with vxWorks and therefore it is not very good if the robot
> crashes with a wall because the motor controlling task was been killed
> by some other buggy task or something else)
One company I know use Hardware safety mechanisms for things like this,
they do not trust software for really dangerous stuff. In the Robot
example they would put cut-off switches which would turn off the power
if the robot reaches a certain angle or position.
I hope this helps.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From tkb@mclean.sparta.com  Mon Dec 30 14:59:31 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Mon Dec 30 14:59:34 PST 1996
Subject: Re: System reliability (was: VxVMI stuff)
>> (I have to control a
>> robot with vxWorks and therefore it is not very good if the robot
>> crashes with a wall because the motor controlling task was been killed
>> by some other buggy task or something else)
>
>One company I know use Hardware safety mechanisms for things like this,
>they do not trust software for really dangerous stuff. In the Robot
>example they would put cut-off switches which would turn off the power
>if the robot reaches a certain angle or position.
This a a very important point.  Never ever leave software as the last line
of defense where safety, mechanical damage or the loss of expensive
materials is concerned.  Software should be the primary means of detecting
and preventing such problems. It should not be left as the only means to
prevent them.  In a system like that described above, let software monitor
the motor controller outputs and try to take corrective action.  Back up
the software with optical and mechanical limit switches.  The optical
sensor positions should be related to the motion of the motor.  The
mechanical switch positions should be related to the device that is being
protected.  The optical indicators can backup the normal functions of the
limits monitored by the motor controller.  This will give the software a
second means of detecting critical faults.  The mechanical limit switches
should shut down power to the robot ( on all axis of motion!! ) w/o the
need for software intervention.
I've seen some fault tolerant systems where the failure of critical systems
triggers a watchdog that will reset the software.  This is pretty standard
practice in military systems and space-based systems.
adios
From 75353.1150@CompuServe.COM  Mon Dec 30 19:11:21 1996
From: "William G.St.Clair" <75353.1150@CompuServe.COM>
Date: Mon Dec 30 19:11:23 PST 1996
Subject: unsubscribe
Unsubscribe
From tunch@dominet.in.com.tr  Tue Dec 31 01:25:46 1996
From: tunch@dominet.in.com.tr (Tunc Hoscan)
Date: Tue Dec 31 01:25:49 PST 1996
Subject: workQAdd0 - work queue overflow problem
Hi all,
Recently we ran into a problem with a Themis SPARC 5/64 board
and vxWorks 5.1.1.
We are developing an air defense system with Ada. Sometimes
when we are loading our Ada application and sometimes after
we load it and started running our system gives a panic message
and reboots itself. It says something like:
Work Queue Panic - workQAdd0
Work Queue Overflow
 .. and reboots
We have a number of VME cards in the system, one being a GET
Engineering NTDS card, and the others are some serial I/O cards.
We are using AP Labs aio (Async. I/O) libraries to write our
device drivers for the I/O cards.
Any insights on this problem??
Thanks,
--
Tunc N. Hoscan
Aydin Yazilim ve Elektronik Sanayi A.S.
Tel   : +90 (312) 287-7575
Fax   : +90 (312) 287-7584
e-mail: tunch@dominet.in.com.tr
From egbert@ra.timeplex.com  Tue Dec 31 09:20:16 1996
From: egbert@ra.timeplex.com (Stephen L. Egbert)
Date: Tue Dec 31 09:20:19 PST 1996
Subject: Re: workQAdd0 - work queue overflow problem
Tunc Hoscan wrote:
>
> Recently we ran into a problem with a Themis SPARC 5/64 board
> and vxWorks 5.1.1.
>
> We are developing an air defense system with Ada. Sometimes
> when we are loading our Ada application and sometimes after
> we load it and started running our system gives a panic message
> and reboots itself. It says something like:
>
> Work Queue Panic - workQAdd0
> Work Queue Overflow
>  .. and reboots
>
> We have a number of VME cards in the system, one being a GET
> Engineering NTDS card, and the others are some serial I/O cards.
>
> We are using AP Labs aio (Async. I/O) libraries to write our
> device drivers for the I/O cards.
First place I would look at is the AP Labs aio libraries.  The Async driver
(or your hook routines if called) is apparently performing at interrupt
context mode way too many VxWorks function calls that requires
deferred kernel processing.
Some examples of deferred kernel works would be qJobPut, semTake, wdStart, msgQSend, msgQBroadcast, wdCancel, taskSuspend, taskPrioritySet, et. al.
Normally interrupt routines performs simple task without calling any deferred kernel functions.
Steve
From eshober@borg.utsci.com  Tue Dec 31 16:33:28 1996
From: "Edward D. Shober" <eshober@utsci.com>
Date: Tue Dec 31 16:33:30 PST 1996
Subject: tyLib questions
I'm forwarding this question from my co-worker Mike Stimpson:
Due to getting no reply from Wind River's tech support for a week and a half,
I am posting some questions here in the hopes that somebody knows the answer.
These questions concern the FIOCANCEL command for the ioctl() function in
tyLib.  As far as I could find, the manual does not answer the following
questions:
- If a task is pending on a read on the serial port, a second task is pending
  on a write on the same port, and a third task issues an FIOCANCEL on the
  port, does it cancel both the read and the write?  Or does it just cancel
  one of them?
- What value is returned from a read or write canceled by an FIOCANCEL?  Does
  it return the number of bytes read/written before the FIOCANCEL was issued?
  Or does it return ERROR?  Or something else?
- If I request a read of 20 bytes from a serial port, and the port has only
  received 10 bytes, does it return the 10 bytes, or does it block waiting
  for the remaining 10?  How about if I'm writing to the port and the transmit
  buffer is full?
Thanks for any light you can shed on all this...