2178 lines
82 KiB
Plaintext
2178 lines
82 KiB
Plaintext
Newsgroups: comp.os.vxworks,comp.answers,news.answers
|
|
Path: bloom-beacon.mit.edu!grapevine.lcs.mit.edu!olivea!sgigate.sgi.com!sgiblab!swrinde!cs.utexas.edu!howland.reston.ans.net!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!hjb
|
|
From: hjb@netcom.com (squeedy)
|
|
Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]
|
|
Message-ID: <hjbCoI2AA.KqK@netcom.com>
|
|
Followup-To: comp.os.vxworks
|
|
Summary: This posting contains a list of Frequently Asked
|
|
Questions (and their answers) about VxWorks REALTIME
|
|
Operating System. It should be read by anyone who wishes to
|
|
post to the comp.os.vxworks newsgroup.
|
|
Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded
|
|
Sender: hjb@netcom.com
|
|
Reply-To: hjb@netcom.com
|
|
Organization: PEACEFUL STAR, Oakland, CA
|
|
Date: Tue, 19 Apr 1994 09:27:46 GMT
|
|
Approved: news-answers-request@MIT.Edu
|
|
Lines: 2158
|
|
Xref: bloom-beacon.mit.edu comp.os.vxworks:2634 comp.answers:4980 news.answers:18274
|
|
|
|
Archive-name: vxworks-faq
|
|
Maintained-by: hjb@netcom.com
|
|
Last-modified: April 17, 1994
|
|
Version: 1.5
|
|
|
|
This is the list of frequently asked questions (and their answers) for
|
|
the newsgroup comp.os.vxworks.
|
|
|
|
Where possible, pointers to existing information are included here, rather
|
|
than rehashing that information again.
|
|
|
|
If you haven't already done so, now is as good a time as any to read the
|
|
guide to Net etiquette which is posted to news.annouce.newusers regularly.
|
|
You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know
|
|
about smileys, followups and when to reply by email to postings.
|
|
|
|
The FAQ is currently posted to comp.os.vxworks, news.answers and
|
|
comp.answers on the 15th of every month.
|
|
|
|
This FAQ was compiled by hjb@netcom.com using comments by readers of
|
|
comp.os.vxworks as well as his own limited knowledge of VxWorks. Credits
|
|
appear at the end. Comments and indications of doubt are enclosed in []s in
|
|
the text. Each section begins with dashes ("-") on a line of their own,
|
|
then the section number. This should make searching for a specific section
|
|
easy.
|
|
|
|
This FAQ is also available via anonymous ftp in:
|
|
rtfm.mit.edu:/pub/usenet/news.answers/vxworks-faq.Z
|
|
ftp.uu.net:/usenet/news.answers/vxworks-faq.Z
|
|
cs.toronto.edu:/pub/usenet/comp.answers/vxworks-faq.Z
|
|
netcom.com:/pub/hjb/vxfaq.gz
|
|
|
|
-------------------------------------------------------------------------
|
|
|
|
TABLE OF CONTENTS
|
|
|
|
1. What is VxWorks?
|
|
2. Brief History of VxWorks
|
|
3. What are some of the major features of VxWorks?
|
|
4. What are the Latest versions of VxWorks?
|
|
5. Where is the archive site for user-contributed code?
|
|
6. What application notes are available from Wind River?
|
|
7. How can I join the VxWorks user's group?
|
|
8. Is comp.os.vxworks also available via a mailing list?
|
|
9. Can I use gcc or g++ with VxWorks?
|
|
10. Other C/C++ Compiler tools for VxWorks?
|
|
11. Which cross-debuggers can I use with VxWorks?
|
|
12. What are differences between traditional UNIX and VxWorks?
|
|
13. What are the performance/benchmark numbers for WIND kernel?
|
|
14. What are the performance/benchmark numbers for VxWorks TCP/IP?
|
|
15. What is the VxSim VxWorks Simulator?
|
|
16. Can I use one boot EPROM for multiple boards on the same net?
|
|
17. What's the deal with 68881 FPU code in interrupt handlers?
|
|
18. Why does ls() not work on netDrv devices?
|
|
19. Why can't I do ".." at top level directories or NFS mount points?
|
|
20. Why do I have trouble using relative symbolic links with NFS?
|
|
21. X for VxWorks
|
|
22. IEEE-488 (GPIB) driver for VxWorks
|
|
23. How does one disable NFS client caching?
|
|
24. Why doing a lot of slipInit()/slipDelete() cause routing
|
|
table corruption?
|
|
25. How does one get better network I/O performance?
|
|
26. How does one troubleshoot a backplane driver malfunction?
|
|
27. How do I add select support to my driver?
|
|
28. bind() gets EADDRINUSE, how do I fix it?
|
|
29. Common errors in interrupt handlers with floating point
|
|
co-proc hardware
|
|
30. Finding entry point of a given module using its name
|
|
31. The problem with irint() in earlier (5.0.2 ?) releases
|
|
32. What are +T, +I thingies in the "i" output?
|
|
33. Gotchas w.r.t watchdogs
|
|
34. Is it possible to delete a memory partition in VxWorks?
|
|
35. rename() does not work in netDrv and nfsDrv filesystems, why?
|
|
36. Free NFS Server for VxWorks
|
|
37. Free SNMP for VxWorks
|
|
38. What third party products are available for VxWorks?
|
|
39. What kind of products have been developed using VxWorks?
|
|
40. A complete list of CPU hardware supported by VxWorks
|
|
41. A complete list of peripheral devices supported by VxWorks
|
|
42. What's with these unbundled "accessories"?
|
|
43. How come my 5.0.2 BSP isn't available in 5.1, damn it?
|
|
44. How much is VxWorks?
|
|
45. What is MicroWorks?
|
|
46. Other Unbundled Products for VxWorks?
|
|
47. How can I find out more about VxWorks?
|
|
48. What other net.resources are available on real-time systems?
|
|
49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?
|
|
50. Free lex and yacc for use with VxWorks
|
|
51. timer_gettime() bug
|
|
52. bogus INCLUDE_TCP_DEBUG
|
|
53. free ppp for VxWorks
|
|
54. how to disable cache on mc68040 or mc68030 using TT regs?
|
|
55. work-arounds for ms-dos filesystem bug when lseek() past eof
|
|
56. TCL for VxWorks
|
|
57. adding default route
|
|
58. adjusting network driver MTU size
|
|
59. tcpdump like utility for vxworks
|
|
60. VxWorks performance on i960 -- unofficial benchmark
|
|
61. VxWorks SCSI Performance -- unofficial benchmark
|
|
[new] 62. VME bus arbitration gotchas
|
|
[new] 63. 5.1.X new MMU supporting code gotchas, as explained in the Manual
|
|
[new] 64. "Cannot Boot. Error 0x1a9" while downloading/booting
|
|
[new] 65. problem with qsort in some versions of VxWorks
|
|
[new] 66. fmod fiasco
|
|
[new] 67. MVME167 copyback cache and various problems
|
|
[new] 68. unloading objects
|
|
9999. Contributions to comp.os.vxworks FAQs.
|
|
|
|
-------------------------------------------------------------------------
|
|
|
|
1. What is VxWorks?
|
|
|
|
VxWorks, from Wind River Systems, is a networked real-time operating
|
|
system designed to be used in a distributed environment. It runs on a
|
|
wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel
|
|
i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems.
|
|
It requires a host workstation for program development; supported host
|
|
platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS.
|
|
|
|
It does not run development systems software such as compiler, linker
|
|
and editor on the target machine. The development environment is based
|
|
on cross-development or remote-development method. You will need a
|
|
UNIX machine of some sort (e.g. SUN's) to run the compilers and
|
|
debuggers. The compiled application code can be downloaded to the
|
|
target and runs as part of the VxWorks image. During the development
|
|
phase or thereafter, individual object code (.o files) can be
|
|
downloaded dynamically to running target system. Finished applications
|
|
can be ROM'ed or whatever.
|
|
|
|
----------------------------
|
|
|
|
2. Brief History of VxWorks
|
|
|
|
Based on what I have heard from David Wilner and others, WRS was
|
|
started by Jerry Fiddler and David Wilner in Jerry's garage as a
|
|
contract/consultant shop for realtime, embedded systems and other fun
|
|
things. Francis Coppola was one of the earlier customers.
|
|
|
|
They wrote a bunch of neat programs for their work and found that they
|
|
liked them a great deal themselves, and added more excellent features
|
|
to the system, eventually adding some things unheard of in
|
|
embedded/realtime market in those days such TCP/IP networking. And
|
|
continued to pioneer in this area by adding NFS, etc.
|
|
|
|
VxWorks was the name given the collection of software which ran on
|
|
top of various realtime kernels including VRTX and pSOS as well an
|
|
earlier slower version of WIND kernel. [ editorial:
|
|
VxWorks no longer runs on other kernels; it now runs exclusively on
|
|
its own WIND kernel since the 5.0 release, for which the WIND was
|
|
rewritten by John Fogelin. ]
|
|
|
|
They got more people interested in the system and became successful.
|
|
And moved from a little building in Emeryville to a larger one. And
|
|
eventually to the present site in Alameda. And hired a lot of people.
|
|
|
|
WRS sold many many more copies of this system and continues to grow
|
|
like a real successful company.
|
|
|
|
-----------------------------
|
|
|
|
3. What are some of the major features of VxWorks?
|
|
|
|
In Version 5.1:
|
|
|
|
- wind kernel unlimited tasks
|
|
- 256 priorities
|
|
- binary, counting mutex semaphores
|
|
- message q's
|
|
- POSIX pipes
|
|
- sockets
|
|
- shared memory
|
|
- profiling utilities
|
|
- ethernet support (i596, LANCE, NIC, SONIC)
|
|
- SLIP (no PPP yet)
|
|
- backplane driver for network
|
|
- rlogin (server & client)
|
|
- telnet (server only)
|
|
- rpc (no rpcgen)
|
|
- nfs (client)
|
|
- ftp (server & client)
|
|
- tftp (client & server)
|
|
- rsh
|
|
- bootp
|
|
- proxyarp
|
|
- C-interpreter shell (incomplete but useful)
|
|
- symbolic debugging
|
|
- disassembly
|
|
- performmance monitoring tools
|
|
- exception handling
|
|
- signal handling (not quite UNIX compatible)
|
|
- dynamic object image loader
|
|
- system symbol table
|
|
- system info utilities
|
|
- libraries of 600+ utility routines
|
|
- remote source level debugger(VxGDB)
|
|
- SCSI support
|
|
- DOS & RT11 & Raw filesystems.
|
|
- "full ANSI"
|
|
- "POSIX I/O"
|
|
|
|
It is a good idea to get a copy of VxWorks manuals before purchasing
|
|
the system. WRS can provide you with such documentation. As far as I
|
|
know there is no "VxBook" in the bookstores.
|
|
|
|
----------------------------
|
|
|
|
4. What are the Latest versions of VxWorks?
|
|
|
|
As as of June 1993,
|
|
|
|
5.0.3.: TRON will be discontinued.
|
|
5.0.3 : i386
|
|
5.0.5 : r3000
|
|
5.1 : 680x0, 683xx, i960, SPARC
|
|
i386 and r3000 will be upgraded to 5.1.
|
|
|
|
------------------------------
|
|
|
|
5. Where is the archive site for user-contributed code?
|
|
|
|
The VxWorks archive system is available for FTP as thor.atd.ucar.edu.
|
|
It is also accessible via email server at vxworks_archive@ncar.ucar.edu.
|
|
Questions should be directed to its maintainer, Richard Neitzel
|
|
<thor@thor.ucar.edu>.
|
|
|
|
To get more detailed infomation send email to:
|
|
|
|
vxworks_archive@ncar.ucar.edu
|
|
|
|
The message body must read:
|
|
|
|
send index
|
|
send index from vx
|
|
send index from unix
|
|
|
|
A summary of the archives is periodically posted to comp.os.vxworks.
|
|
|
|
Some of the usual titles available:
|
|
|
|
ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench
|
|
cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress
|
|
flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2
|
|
lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe
|
|
poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod
|
|
tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar
|
|
vxtool, vxview, xc
|
|
|
|
------------------------------
|
|
|
|
6. What application notes are available from Wind River?
|
|
|
|
List of Wind Technical Notes
|
|
|
|
Motorola MV147 Slave Base Control 9-1
|
|
System hang during lkup( ) output 10-1
|
|
Reserving Memory 11-1
|
|
Serial IO Vanishing 13-1
|
|
NFS: problems with writing files 14-1
|
|
Which interrupts does VxWorks use? 15-1
|
|
Debugging ftp problems 18-1
|
|
Interrupt handlers, floating point 19-1
|
|
Booting From a Memory Board 22-1
|
|
Changing Network Interfaces 23-1
|
|
Writing Non-buffered Sockets 24-1
|
|
RPC and VxWorks 25-1
|
|
Using SCSI devices with VxWorks 5.x 26-1
|
|
The Select Facility in VxWorks 28-1
|
|
Using on-board Serial Ports 29-1
|
|
Problems with ls() 30-1
|
|
SCSI 31-1
|
|
Trouble Shooting Booting Problems 32-1
|
|
|
|
-----------------------------
|
|
|
|
7. How can I join the VxWorks user's group?
|
|
|
|
For User Group info contact WRS or Eric Rabinowitz of Panoramic Systems at:
|
|
|
|
elr@netcom.com or ericr@wrs.com
|
|
phone: 408-289-7757
|
|
|
|
------------------------------
|
|
|
|
8. Is comp.os.vxworks also available via a mailing list?
|
|
|
|
Lawrence Berkeley Labs maintains an automated mailing list which is
|
|
bi-directionally gatewayed to comp.os.vxworks
|
|
|
|
It is called the 'VxWorks Exploder'.
|
|
|
|
Mail to vxwexplo@lbl.gov is automatically mailed to a number
|
|
of sites, including Wind River.
|
|
|
|
Send subscription request to vxwexplo-request@lbl.gov.
|
|
|
|
------------------------------
|
|
|
|
9. Can I use gcc or g++ with VxWorks?
|
|
|
|
WRS's gcc GNU Toolkit distribution can be reshipped in its entirety.
|
|
WRS charges are for media and support, so obviously copies thereof
|
|
don't matter to them.
|
|
|
|
Lots of customers use g++ as provided by the "net" --
|
|
see the VxWorks Archive information below.
|
|
|
|
You can get a generic freely distributable GCC/G++ and compile your
|
|
code for VxWorks. Or you can just get a copy from someone who has a
|
|
working GCC cross-development setup from WRS.
|
|
|
|
WRS worked with Cygnus to polish up their release of GCC but a generic
|
|
GCC distribution works just fine as well.
|
|
|
|
For MC68K targets:
|
|
You can also use native SunOS 4.X cc running on Sun-3's.
|
|
You can also use various other free m68k C compilers
|
|
such as lcc, sozobon, etc. provided that you're willing
|
|
to hack on them.
|
|
|
|
Richard Neitzel (thor@thor.atd.ucar.edu) writes,
|
|
|
|
Thanks to some feedback I've corrected the archive instructions on how to
|
|
build gcc, libgcc and libg++ for VxWorks. To make my life simpler the
|
|
patches referenced are no longer included in the vx_cplusplus file. Instead
|
|
there are now seperate patch files for the effected parts:
|
|
|
|
libg++-2.5-src.patch: Patches libg++/src.
|
|
libgcc2-2.5.0.patch: Patch libgccc2.c for gcc-2.5.0.
|
|
libgcc2-2.5.2.patch: Patch libgcc2.c for gcc-2.5.2.
|
|
libio-2.5.patch: Patch the stream library.
|
|
|
|
See VxWorks Archive information in this FAQ for details on how to
|
|
get these files.
|
|
|
|
---------------------------------------
|
|
|
|
10. Other C/C++ Compiler tools for VxWorks?
|
|
|
|
WRS re-sells (re-engineered?) CenterLine cfront product and WindC++
|
|
Gateway for CenterLine ObjectCenter. They come with browsers, etc.
|
|
Not free.
|
|
|
|
Wind C++ Gateway for ObjectCenter sold by WRS:
|
|
|
|
$995 / user 1-4 copies
|
|
$875 / user 5-9 copies
|
|
|
|
Note that this is the cost over and above ObjectCenter.
|
|
|
|
------------------------------
|
|
|
|
11. Which cross-debuggers can I use with VxWorks?
|
|
|
|
GDB & other more expensive tools from WRS, MicroTec Research, etc.
|
|
|
|
WRS sells a lightly modified version of xxgdb which has a lousy GUI
|
|
interface. In 5.1 xvxgdb may have been slightly improved -- but the
|
|
ObjectCenter C++ with VxWorks solution provides better GUI interface.
|
|
|
|
With a little bit of hacking, regular GDB works just fine. Personally,
|
|
I find GUI to a debugger gets in the way of real work. I use GNU Emacs
|
|
GDB interface which works well and can be easily customized.
|
|
|
|
There might be some old VxWorks customers that also use VxWorks-aware
|
|
dbxtool on Sun machines. This used to be maintained and sold by SUN
|
|
Consulting.
|
|
|
|
If you're only interested in debugging your "application" on VxWorks,
|
|
the vxgdb approach (using RPC) works just fine.
|
|
|
|
If you are rather more interested in the guts of the system as well as
|
|
your application you might want to spend some time building
|
|
cross-debugging tools from generic GDB distribution into VxWorks.
|
|
|
|
------------------------------------
|
|
|
|
12. What are differences between traditional UNIX and VxWorks?
|
|
|
|
They're both hacks. UNIX has a larger installed base. :-)
|
|
|
|
Seriously though, similarities end there, IMHO. VxWorks does have a
|
|
lot of UNIX "compatible" routines in the user libraries. So porting a
|
|
UNIX application is not that hard. But there are enough differences to
|
|
make such a port take longer than normally expected.
|
|
|
|
VxWorks runs in one mode. No protected vs. user mode switching is
|
|
done. Running in supervisor mode on most processors, and not using
|
|
traps for system calls, VxWorks can achieve minimal overhead on a given
|
|
piece of hardware than UNIX. Programming on VxWorks can be more tricky
|
|
than UNIX for the same reason.
|
|
|
|
UNIX provides resource reclamation; by default, VxWorks does not. [
|
|
editorial: using deleteHooks or whatever, you could implement this on
|
|
your own.] Instead programmers write what they need as needed. As a
|
|
result, the context switch time in VxWorks is on the order of a few
|
|
micro-seconds (since there is a lot smaller context to save and
|
|
restore). VxWorks does not have full "process"; it only has tasks, or
|
|
"threads", or light weight processes as some people like to call them.
|
|
|
|
Like any other multi-threaded environments (or MP environments), care
|
|
should be taken when writing multi-tasking code. Each routine should
|
|
be written carefully to be re-entrant (if it is going to be called from
|
|
multiple contexts), semaphores are used a lot for this. And static
|
|
variables are frowned upon. Sometimes, when porting a UNIX
|
|
application, you may need to add "task variables" for this reason (as
|
|
done for rpcLib in VxWorks).
|
|
|
|
VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented
|
|
as semaphores). Traditional UNIX: high interrupt latency (e.g. spl's
|
|
are implemented as interrupt lock and unlock calls).
|
|
|
|
VxWorks: priority interrupt-driven preemption, optional round-robin
|
|
time-slicing. Traditional UNIX: prioritized round-robin preemptive
|
|
time-slicing. Since VxWorks is just a glorified "program" it can be
|
|
changed and customized pretty easily. Task scheduling can be
|
|
customized as desired, for example.
|
|
|
|
VxWorks networking code, however, is very UNIX compatible [editorial:
|
|
it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe
|
|
release ]. It is relatively easy to port socket based code to
|
|
VxWorks. [ editorial: except the not-so-compatible hostLib routines,
|
|
etc.]
|
|
|
|
VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX
|
|
as often misunderstood by some people. The confusion perhaps is due to
|
|
the fact that UNIX hosts are used most widely to develop applications
|
|
for VxWorks (and VxWorks itself).
|
|
|
|
There are a lot more differences! In short, UNIX is a nice system to
|
|
run emacs on. VxWorks is much better at playing pin-ball game
|
|
machines.
|
|
|
|
Having said all this, I should also note that there are Realtime capable
|
|
UNIX systems out there. Most of these systems do not come close to
|
|
the capabilities and performance of VxWorks in realtime processing.
|
|
An exception to this might be QNX, which is a very well designed
|
|
Realtime POSIX operating system.
|
|
|
|
----------------------------
|
|
|
|
13. What are the performance/benchmark numbers for WIND kernel?
|
|
|
|
A WRS VxWorks 5.1 Benchmark Report hot off the press:
|
|
|
|
Benchmark numbers based on: mv167-25Mhz, 5.1
|
|
|
|
Cache Cache
|
|
Key Measurements Enabled Disabled
|
|
|
|
Raw Context Switch Time 4 us 14 us
|
|
Cyclic Test Time 172 us 638 us
|
|
Suspend/Switch/Resume/Switch 23 us 86 us
|
|
|
|
Kernel Timings
|
|
|
|
Task Related
|
|
taskSpawn 124 us 370 us
|
|
taskInit 58 us 181 us
|
|
taskActivate 12 us 33 us
|
|
taskDelete 101 us 303 us
|
|
Task Create / Delete 249 us 684 us
|
|
taskLock
|
|
CASE 1: no lock 3 us 4 us
|
|
CASE 2: lock exists 2 us 5 us
|
|
taskUnlock
|
|
CASE 1: no lock 2 us 12 us
|
|
CASE 2: lock exists 5 us 6 us
|
|
taskSuspend
|
|
CASE 1: ready task 11 us 30 us
|
|
CASE 2: pended task 9 us 19 us
|
|
CASE 3: suspended task 8 us 19 us
|
|
CASE 4: delayed task 9 us 19 us
|
|
taskResume
|
|
CASE 1: ready task 6 us 19 us
|
|
CASE 2: pended task 10 us 19 us
|
|
CASE 3: suspended task 13 us 30 us
|
|
CASE 4: delayed task 9 us 18 us
|
|
|
|
Semaphore Related
|
|
semBCreate 66 us 152 us
|
|
semCCreate 46 us 150 us
|
|
semMCreate 45 us 139 us
|
|
semDelete
|
|
Binary 49 us 157 us
|
|
Counting 49 us 163 us
|
|
Mutual Exclusion 48 us 157 us
|
|
semGive
|
|
CASE 1: tasks in queue
|
|
Binary 18 us 44 us
|
|
Counting 20 us 46 us
|
|
Mutual Exclusion 25 us 59 us
|
|
CASE 2: no tasks in queue
|
|
Binary 4 us 8 us
|
|
Counting 5 us 11 us
|
|
Mutual Exclusion 6 us 15 us
|
|
|
|
semTake
|
|
CASE 1: semaphore available
|
|
Binary 4 us 9 us
|
|
Counting 5 us 11 us
|
|
Mutual Exclusion 5 us 13 us
|
|
CASE 2: semaphore unavailable
|
|
Binary 10 us 25 us
|
|
Counting 11 us 27 us
|
|
Mutual Exclusion 4 us 12 us
|
|
Semaphore Give / Take
|
|
Binary 7 us 15 us
|
|
Counting 9 us 21 us
|
|
Mutual Exclusion 10 us 26 us
|
|
semFlush
|
|
Binary 11 us 20 us
|
|
Counting 11 us 20 us
|
|
Mutual Exclusion 10 us 16 us
|
|
|
|
Miscellaneous Operating System Timings
|
|
|
|
Message Queue Related
|
|
msgQCreate 93 us 280 us
|
|
msgQDelete 71 us 229 us
|
|
msgQSend
|
|
CASE 1: task pending 39 us 102 us
|
|
CASE 2: no tasks pending 23 us 64 us
|
|
CASE 3: queue full 14 us 45 us
|
|
msgQReceive
|
|
CASE 1: message available 20 us 62 us
|
|
CASE 2: message unavailable 15 us 41 us
|
|
|
|
Memory Related
|
|
malloc 28 us 81 us
|
|
free 32 us 104 us
|
|
|
|
Watchdog Related
|
|
wdCreate 42 us 106 us
|
|
wdDelete
|
|
CASE 1: timer started 48 us 160 us
|
|
CASE 2: timer not started 44 us 150 us
|
|
wdStart
|
|
CASE 1: timer in queue 20 us 70 us
|
|
CASE 2: no timer in queue 18 us 55 us
|
|
wdCancel 11 us 34 us
|
|
|
|
Floating-Point
|
|
robot application 18 sec 51 sec
|
|
|
|
[ editorial:
|
|
If you care enough to count pico-seconds in comparing realtime
|
|
kernels, you might want to actually get each of the evaluation copies
|
|
from various vendors and test them yourself. But remember benchmarks
|
|
are misleading and almost always biased and inaccurate. Given similar
|
|
benchmark numbers, give or take a few microseconds, etc., your dollars
|
|
are better spent in getting something you'll enjoy using. ]
|
|
|
|
-----------------------------
|
|
|
|
14. What are the performance/benchmark numbers for VxWorks TCP/IP?
|
|
|
|
According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet)
|
|
|
|
w/ cache w/o cache enabled
|
|
TCP/IP Throughput (KB/sec) 859 KB/sec 682 KB/sec
|
|
|
|
No numbers available on latency.
|
|
|
|
Using a reasonably fast processor 25Mhz MC68040 and a reasonably well
|
|
made ethernet chip like SONIC or LANCE put together on a reasonable board
|
|
design will achieve TCP throughput close to full bandwidth of ethernet.
|
|
|
|
[ editorial:
|
|
This, of course, is rather slow in comparison with other fast
|
|
implementations, since a 16Mhz MC68020 with onboard LANCE
|
|
or a PeeCee with an ethernet board can easily do the same.
|
|
I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC
|
|
that does: 1170KB/sec. ]
|
|
|
|
---------------------------------
|
|
|
|
15. What is the VxSim VxWorks Simulator?
|
|
|
|
Propaganda from WRS:
|
|
|
|
It really is VxWorks running under UNIX! So sure it
|
|
is not realtime, although all tasks and resources interact
|
|
in the same way -- great for prototyping "high-level" code.
|
|
Using the simulator saves wear and tear on h/w. It (only)
|
|
allows sytem level debugging with native GDB.
|
|
|
|
Portably written object code compiled for VxSim (for SunOS SPARC)
|
|
will usually load without recompilation on a SPARC target. And,
|
|
BTW under 5.1 switching from one architecture to anthoer really is
|
|
pretty painless.
|
|
|
|
------------------------------
|
|
|
|
16. Can I use one boot EPROM for multiple boards on the same net?
|
|
|
|
WRS provides EPROMs with a default bogus bootline, virtually all
|
|
boards come with non-valiatile RAM which is set as soon as the user
|
|
fills in his parameters (which include CPU #). Therefore 1 EPROM may
|
|
be duplicated and used in all boards at a site. If the board does not
|
|
contain nvram then ROMs have to be specially blown, unless a custom
|
|
scheme for reading some switches or something is coded to index into a
|
|
bootline table. In 5.1 BOOTP is supported -- no more repeated EPROM
|
|
burning is necessary.
|
|
|
|
------------------------------
|
|
|
|
17. What's the deal with 68881 FPU code in interrupt handlers?
|
|
|
|
In general, FP context is optimally saved only when the scheduler
|
|
notices that the new task coming in also uses the fpu (VX_FP_TASK).
|
|
ISRs don't. If no tasks are using the FPU then ISRs may go ahead,
|
|
unless different levels of ISRs could interrupt each other and again
|
|
cause a protocol violation.
|
|
|
|
And Stan Schneider says,
|
|
|
|
You have to set the "VX_FP_TASK" option flag when you spawn your task. You
|
|
also need to make sure you don't use the FPU in any interrupt service
|
|
routines. Even if your code uses no floating point, some (brain-dead)
|
|
compilers save some FPU registers at the start of all routines if there's any
|
|
floating point in the file. That's not usually a problem if you're using the
|
|
gcc compiler (at least with the "-O" flag on). A sure way to check is via the
|
|
dissassembler.
|
|
|
|
And Leonid Rosenboim says,
|
|
|
|
This problem is quite common, and really simple to fix, all you have to
|
|
do is make sure that all tasks that do a float operation ever, will
|
|
be spawned with the VX_FP task option set. This is the best and only
|
|
solution. Also, if you run floating operations in ISRs care must be taken,
|
|
to call fppSave() and fppRestore(). Also if you are using 5.1 on a 68040,
|
|
there is a bug in the compiler that you must work around:
|
|
|
|
If you write an ISR that uses float instructions, it is not
|
|
enougth just to call fppSave()/fppRestore(), since the compiler
|
|
for 68040 inserts FP instructions BEFORE your first line
|
|
of C code, hence you need to write a dummy ISR that:
|
|
|
|
dummyIsr()
|
|
{
|
|
fppSave( .. );
|
|
yourRealISR();
|
|
fppRestore( ... );
|
|
}
|
|
|
|
And Kent Long says,
|
|
|
|
This was indeed a real problem in the context switch code in 5.0.x which
|
|
was corrected in 5.1.
|
|
|
|
In both OS versions, there is an optimization that causes the FP context
|
|
to be swapped only when the incoming task has been spawned with the
|
|
floating point (VX_FP) flag set. In 5.0.x, the copying-in of the FP context
|
|
was done via an fppSave() call. This created problems if a new FP
|
|
task was created after a previous FP task had been pre-empted by a non-FP
|
|
task in the middle of an instruction. The new task ended up with a
|
|
mid-instruction context (which causes the protocol violation), and the
|
|
old swapped-out FP task ultimately ended up with its context set to IDLE
|
|
(which is equally incorrect).
|
|
|
|
In 5.1, the FP context initialization was changed so that when a task
|
|
is created, a pre-defined IDLE frame is copied into that tasks's context.
|
|
Since there is no assumption about current FP state (as with fppSave),
|
|
task creation is now decoupled from the regular switch logic.
|
|
|
|
|
|
------------------------------
|
|
|
|
18. Why does ls() not work on netDrv devices?
|
|
|
|
Because the way directory information retrieval IOCTL calls are not acompatible
|
|
between different types of "filesystems" in VxWorks. Another reason why
|
|
some think VxWorks filesytem does not exist; they're just a collection of
|
|
ioDevice drivers, and there is not a real consistent "design" to it.
|
|
|
|
The lsOld() should work on "filesystems" that does not support ls().
|
|
|
|
Chuck Mead proposes the following special routine in case lsOld() does not
|
|
work for you:
|
|
|
|
|
|
#include "vxWorks.h"
|
|
#include "bootLib.h"
|
|
|
|
#define RSHD 514
|
|
|
|
STATUS lsHost(path)
|
|
char *path ;
|
|
{
|
|
char *lsString;
|
|
int dataSock ;
|
|
int n ;
|
|
char nextChar ;
|
|
|
|
extern BOOT_PARAMS sysBootParams ;
|
|
extern char *sysBootHost ;
|
|
|
|
if (path == (char *) NULL)
|
|
{
|
|
lsString = (char *) malloc(4) ;
|
|
strcpy(lsString, "ls") ;
|
|
}
|
|
else
|
|
{
|
|
lsString = (char *) malloc(strlen(path) + 5) ;
|
|
sprintf(lsString, "%s%s", "ls ", path) ;
|
|
}
|
|
|
|
dataSock = rcmd (sysBootHost, RSHD, sysBootParams.usr,
|
|
sysBootParams.usr, lsString, (int *) NULL) ;
|
|
|
|
if (dataSock == ERROR)
|
|
{
|
|
printf("Error opening socket") ;
|
|
return (ERROR) ;
|
|
}
|
|
|
|
n = fioRead(dataSock, &nextChar, 1) ;
|
|
while (n == 1)
|
|
{
|
|
printf("%c",nextChar) ;
|
|
n = fioRead(dataSock, &nextChar, 1) ;
|
|
}
|
|
|
|
close(dataSock) ;
|
|
}
|
|
|
|
------------------------------
|
|
|
|
19. Why can't I do ".." at top level directories or NFS mount points?
|
|
|
|
Because, again, VxWorks does not really have a "filesystem" as most people
|
|
understand it. The top level directories are just implemented as device
|
|
driver "node", which is used to identify the ioDev associated with the
|
|
specific VxWorks "filesystem". Since there is no underlying filesystem
|
|
layer, the story ends there. When you're at the top of the directory
|
|
hierarchy within a given ioDev/filesytem, you simply cannot do "..".
|
|
|
|
------------------------------
|
|
|
|
20. Why do I have trouble using relative symbolic links with NFS?
|
|
|
|
See [Q: Why can't I do ".." at top level directories or NFS mount points?]
|
|
above. This is just another problem caused by the fact that a real filesystem
|
|
does not exist for VxWorks. NFS client implementation actually does implement
|
|
the symbolic links correctly, using lookup and readlink. The problem is
|
|
due to the fact that, for some relative links that use ".." or whatever, that
|
|
crosses over filesystems, VxWorks cannot have underlying subsystem that will
|
|
handle file pathname to device mapping.
|
|
|
|
Using absolute symbolic links work just fine (i.e. full path name from top).
|
|
|
|
------------------------------
|
|
|
|
21. X for VxWorks
|
|
|
|
WRS has a product called windX which supports Motif. There is also
|
|
libX11 contribution in the VxWorks Archive. This package is perhaps
|
|
fairly old and out of date. Essentially, to port X stuff to VxWorks
|
|
you'll need to do make sure code is re-entrant everywhere. There is a
|
|
"multi-thread" safe version of Xlib available somewhere on the net, one
|
|
might try porting that. There are also vendors that have built X servers
|
|
using VxWorks. Jupiter Systems, in Alameda, makes high-end X server
|
|
machines based on VxWorks. Other X terminal vendors (HP?) also use VxWorks.
|
|
|
|
-----------------------------
|
|
|
|
22. IEEE-488 (GPIB) driver for VxWorks
|
|
|
|
- National Instruments has lots of GPIB stuff
|
|
- THEMIS computers has TSVME-409 whic hincludes a GPIB interface.
|
|
- APLABS probably has some GPIB stuff too.
|
|
|
|
-----------------------------
|
|
|
|
23. How does one disable NFS client caching?
|
|
|
|
VxWorks caches read and write requests in NFS client code.
|
|
To completely disable read and write cache, set nfsCacheSize to 0.
|
|
To just flush the write cache as needed, use nfsCacheFlush() or
|
|
FIOSYNC ioctl().
|
|
|
|
------------------------------
|
|
|
|
24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption?
|
|
|
|
This is due to a bug in slipDelete() and/or if_dettach(). slipDelete()
|
|
calls if_dettach() to clean up after itself (SLIP network interface driver).
|
|
Not only is if_dettach() misspelled, it also doesn't do a complete job.
|
|
One deficiency is that it does not delete routes that are pointing to the
|
|
interface being deleted. This is remedied via another function that deletes
|
|
all routes for a give netif device driver. [ ifRouteDelete() ??? ]
|
|
slipDelete() does call this routine to delete routes. Another problem is
|
|
that if_dettach() does not delete a pointer to the netif device driver
|
|
structure in the global in_ifaddr linked list. The in_ifaddr list is
|
|
used by the network kernel code to find IP addresses of available network
|
|
interfaces, among other things. This lack of proper cleanup turns out to
|
|
be a rather hard-to-find memory corruption problem in network code, and
|
|
usually manifests itself as routing table corruptions.
|
|
|
|
To fix this add the following routine, and call it right after calling
|
|
slipDelete:
|
|
|
|
void in_ifaddr_remove(ifp)
|
|
struct ifnet *ifp; /* ifp = ifunit("sl0") before slipDelete() called */
|
|
{
|
|
struct in_ifaddr *ia, *prev_ia;
|
|
|
|
if (!ifp)
|
|
return;
|
|
|
|
prev_ia = 0;
|
|
|
|
for (ia = in_ifaddr; ia; ia = ia->ia_next) {
|
|
if (ia->ia_ifp == ifp) {
|
|
if (prev_ia)
|
|
prev_ia->ia_next = ia->ia_next;
|
|
else
|
|
in_ifaddr = ia->ia_next;
|
|
return;
|
|
}
|
|
prev_ia = ia;
|
|
}
|
|
}
|
|
|
|
This, along with the route cleanup, should be incorporated into if_detach().
|
|
|
|
------------------------------
|
|
|
|
25. How does one get better network I/O performance?
|
|
|
|
Most of the overhead is due to socket to network core interface overhead.
|
|
The copy that happens between the socket layer and network core code
|
|
can be avoided by using the routines in uipc_socket.c (as in BSD tahoe
|
|
release code available on various archive sites) and using mbufs directly.
|
|
|
|
You can also try using raw etherLib routines. However, etherLib also
|
|
does copying between user application and network driver.
|
|
|
|
If you must use the socket interface (sockLib), make sure you tune the
|
|
socket level buffers sizes to optimal values using setsockopt() calls
|
|
SO_SNDBUF and SO_RCVBUF. You might also just try changing the globals
|
|
that control the following default parameters to larger numbers (all
|
|
the way upto 48K):
|
|
|
|
tcp_sendspace (default 4K)
|
|
tcp_recvspace (default 4K)
|
|
udp_sendspace (default 2K)
|
|
udp_recvspace (default 4K)
|
|
|
|
To get around extra latency in some cases, you might turn on TCP_NODELAY
|
|
option on TCP sockets.
|
|
|
|
------------------------------
|
|
|
|
26. How does one troubleshoot a backplane driver malfunction?
|
|
|
|
There are a few rules of thumb:
|
|
|
|
1) Try the simplest case first -- use polling instead of
|
|
bus or mailbox interrupts and software test-and-set
|
|
instead of hardware test-and-set. See if this
|
|
works first. And then try hardware test-and-set
|
|
and then the desired mailbox or bus interrupt.
|
|
|
|
2) Use bpShow() to see what's up. Also look for magic code
|
|
0x1234 in share mem area being used for messages,
|
|
and verify heartbeat is being incremented.
|
|
At the "anchor" you should see the magic code (4 bytes)
|
|
followed by a long word which should be incrementing (the
|
|
heartbeat) every second.
|
|
|
|
3) Verify all memory mapping and make sure there's no
|
|
address conflicts on the bus, and the anchor area is
|
|
properly set up. If the anchor and ring buffer area
|
|
is on a CPU, make sure the sysLib.c:sysHwInit()
|
|
does the right thing to allow access to on-board memory
|
|
by other CPU's in the chassis. Be careful, as some
|
|
VxWorks BSP's turn off on-board memory access by other CPU's
|
|
if the CPU is not processor 0. This should be changed
|
|
if your anchor CPU is not processor 0 (first CPU in
|
|
VME chassis/backplane) -- this is a boot time configuration
|
|
parameter [ based on the assumption that bpInit() will be done
|
|
by the processor 0 ].
|
|
|
|
4) Make sure bus controller is functioning properly.
|
|
Some combinations of boards might not work well
|
|
especially if your system controller board
|
|
arbitrates the bus in one way and other boards
|
|
expect to be arbitrated in a different way.
|
|
Sometimes you might need to use a separate
|
|
system controller. Of course, also make sure
|
|
you only have one bus master. And that your VME
|
|
bus strappings (BREQ, IACK daisychains) are right.
|
|
|
|
5) Call Wind River's VxWorks tech-support...
|
|
|
|
------------------------------
|
|
|
|
27. How do I add select support to my driver?
|
|
|
|
#include "selectLib.h"
|
|
...
|
|
|
|
xxx_init(...)
|
|
{
|
|
...
|
|
selWakeupListInit(&xxxdev->selwakeupList);
|
|
...
|
|
}
|
|
|
|
xxx_ioctl(...)
|
|
{
|
|
...
|
|
switch(request_type) {
|
|
...
|
|
case FIOSELECT:
|
|
selNodeAdd(&xxxdev->selwakeupList,
|
|
(SEL_WAKEUP_NODE *)request_arg);
|
|
if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD)
|
|
&& readable_condition_is_met)
|
|
selWakeup((SEL_WAKEUP_NODE*)request_arg);
|
|
if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE)
|
|
&& writable_condition_is_met)
|
|
selWakeup((SEL_WAKEUP_NODE*)request_arg);
|
|
break;
|
|
...
|
|
case FIOUNSELECT:
|
|
selNodeDelete(&xxxdev->selWakeupList,
|
|
(SEL_WAKEUP_NODE*)request_arg);
|
|
break;
|
|
...
|
|
}
|
|
}
|
|
|
|
And, add calls to selWakeup() as appropriate in your interrupt handlers
|
|
and read/write routines as selective conditions are toggled or satisfied.
|
|
|
|
------------------------------
|
|
|
|
28. bind() gets EADDRINUSE, how do I fix it?
|
|
|
|
Fix: do setsockopt() SO_REUSEADDR
|
|
|
|
------------------------------
|
|
|
|
29. Common errors in interrupt handlers with floating point co-proc hardware
|
|
|
|
Don't forget to use:
|
|
fppSave()
|
|
fppRestore()
|
|
|
|
Interrupt handler encapsulation code doesn't always save fpp registers for you.
|
|
|
|
------------------------------
|
|
|
|
30. Finding entry point of a given module using its name
|
|
|
|
Example from a poster in vxworks newsgroup (who?):
|
|
|
|
|
|
FUNCPTR start; /* found entry point goes here */
|
|
UINT8 symType;
|
|
int tid;
|
|
|
|
if(symFindByName(sysSymTbl,"_nlos_start",(char**)&start,&symType)==OK){
|
|
/* taskSpawn(name,priority,options,stacksize,entryAddress,arg1,..) */
|
|
|
|
tid = taskSpawn("nlos",TASK_PRI_NLOS,SPAWN_OPTS,STACK_SIZE_NLOS,start,
|
|
arg1,arg2,.....);
|
|
}
|
|
|
|
------------------------------
|
|
|
|
31. The problem with irint() in earlier (5.0.2 ?) releases
|
|
|
|
The problem:
|
|
|
|
/* Include Files */
|
|
#include "vxWorks.h"
|
|
#include "math.h"
|
|
|
|
long irint_count = 0;
|
|
|
|
sinTest()
|
|
{
|
|
int sinTable;
|
|
|
|
while(1)
|
|
{
|
|
sinTable = irint(sin(4./1024.*(2.*3.14))*10.);
|
|
irint_count++;
|
|
}
|
|
}
|
|
|
|
|
|
% cc68k -I/vxworks/vw/h -c sinTest.c
|
|
|
|
-> ld < sinTest.o
|
|
|
|
/* 0x08 Option = VX_FP_TASK within taskLib.h */
|
|
-> taskSpawn ("sinTest", 100, 0x08, 4000, sinTest)
|
|
/* OR without the Floating Point Option */
|
|
-> sp sinTest
|
|
|
|
-> irint_count
|
|
|
|
Bus Error
|
|
Program Counter: 0xb0ac0124
|
|
Status Register: 0x3004
|
|
Access Address : 0xb0ac0120
|
|
Special Status : 0x01e6
|
|
Task: 0xfcb82c "sinTest"
|
|
|
|
The answer:
|
|
|
|
Submitted-by wrs!yuba!kent@uunet.uu.net Fri Sep 27 18:55:25 1991
|
|
Submitted-by: wrs!yuba!kent@uunet.uu.net (Kent Long)
|
|
|
|
> In the function irint, there is a bug that sets the floating point
|
|
> Exception enable byte register to random values. Here is the
|
|
> disasembled code:
|
|
>
|
|
> _irint:
|
|
> 00e034 4e56 0000 LINK .W A6,#0
|
|
> 00e038 f227 6b80 FMOVE .X F7,-(A7)
|
|
> 00e03c f22e 5780 0008 FMOVE .D ($8,A6),F7
|
|
> 00e042 f22e 6380 0008 FMOVE .L F7,($8,A6)
|
|
> 00e048 202e 0008 MOVE .L ($8,A6),D0
|
|
>
|
|
> 00e04c f201 9000 FMOVE .L D1,#<FPCR>
|
|
|
|
<insert audible groan here>
|
|
|
|
> 00e050 504f ADDQ .W #8,A7
|
|
> 00e052 4e5e UNLK A6
|
|
> 00e054 4e75 RTS
|
|
>
|
|
> Line 0e04c is the line that sets the FPCR to some random value,
|
|
> as D1 is unknown going into the function. I rewrote the routine,
|
|
> without line 0e4c, and everything works fine.
|
|
> If anyone out there knows why this line was put in, I would
|
|
> appreciate knowing. Hope this may keep someone else from spending
|
|
> a couple of days tracking down this problem.
|
|
|
|
I have confirmed that this is a bug in all 5.x versions of VxWorks for
|
|
the 68k. (In fact, it's in 4.0.2 as well.) As Mark correctly observed,
|
|
the problem is that the FPCR register is erroneously being set.
|
|
|
|
This was a simple cut-and-paste error in the VxWorks source module.
|
|
The line which sets the FPCR should instead be restoring the value
|
|
of FP7, which was saved on the stack earlier (as you can see in the
|
|
code above). So, it would appear that another side effect of this
|
|
bug is to clobber FP7.
|
|
|
|
The fix is pretty simple. The following patch scripts should get things
|
|
back to what they should be. (You can just include the appropriate lines
|
|
in your startup script, or enter them from the VxWorks shell.)
|
|
|
|
For VxWorks 5.0.1 and 5.0.2:
|
|
|
|
pMathPatch = mathHardIrint + 0x18;
|
|
*pMathPatch = (short) 0xf21f;
|
|
pMathPatch = mathHardIrint + 0x1a;
|
|
*pMathPatch = (short) 0x4b80;
|
|
|
|
This bug does NOT affect VxWorks 5.1. The disassembled code for Vx5.1,
|
|
(HK68K/V3D) is:
|
|
_mathHardIrint:
|
|
2042e58 4e56 0000 LINK .W A6,#0
|
|
2042e5c f227 6800 FMOVE .X F0,-(A7)
|
|
2042e60 f22e 5400 0008 FMOVE .D (0x8,A6),F0
|
|
2042e66 f22e 6000 0008 FMOVE .L F0,(0x8,A6)
|
|
2042e6c 202e 0008 MOVE .L (0x8,A6),D0
|
|
2042e70 f21f 4800 FMOVE .X (A7)+,F0
|
|
2042e74 4e5e UNLK A6
|
|
2042e76 4e75 RTS
|
|
|
|
Kent Long further clarifies,
|
|
|
|
This was indeed a real problem in the context switch code in 5.0.x which
|
|
was corrected in 5.1.
|
|
|
|
In both OS versions, there is an optimization that causes the FP context
|
|
to be swapped only when the incoming task has been spawned with the
|
|
floating point (VX_FP) flag set. In 5.0.x, the copying-in of the FP context
|
|
was done via an fppSave() call. This created problems if a new FP
|
|
task was created after a previous FP task had been pre-empted by a non-FP
|
|
task in the middle of an instruction. The new task ended up with a
|
|
mid-instruction context (which causes the protocol violation), and the
|
|
old swapped-out FP task ultimately ended up with its context set to IDLE
|
|
(which is equally incorrect).
|
|
|
|
In 5.1, the FP context initialization was changed so that when a task
|
|
is created, a pre-defined IDLE frame is copied into that tasks's context.
|
|
Since there is no assumption about current FP state (as with fppSave),
|
|
task creation is now decoupled from the regular switch logic.
|
|
|
|
------------------------------
|
|
|
|
32. What are +T, +I thingies in the "i" output?
|
|
|
|
The following is an excellent description of all these symbols by many people
|
|
on the net, including "Fred J. Roeber" and others:
|
|
|
|
Description Status symbol
|
|
===================================== ===============
|
|
<blah> and task's priority inherited <blah> + I
|
|
Delayed and suspended DELAY+S
|
|
Pended and suspended PEND+S
|
|
Pended and Delayed PEND+T
|
|
Pended, delayed and suspended PEND+S+T
|
|
|
|
The DELAY state indicates that the task has done some sort of delayed
|
|
call while PEND means the task has done something that caused it to
|
|
block like trying to semTake a semaphore someone else was holding.
|
|
PEND+T means that the task is both delaying and pending; it has done a
|
|
semTake with a timeout. +I means that the task has (temporarily)
|
|
inherited a higher priority through the use of a mutex semaphore.
|
|
|
|
The priority inheritance protocol also accounts for the ownership of
|
|
more than one mutual exclusion semaphore at a given time. A task in
|
|
such a situation will execute at the priority of the highest priority
|
|
task blocked on any of the owned resources. The task will return to
|
|
its normal, or standard, priority only after relinquishing all of the
|
|
mutual exclusion semaphores with the inversion safety option enabled.
|
|
|
|
If you use nested mutex semaphores with priority inheritance turned on then
|
|
when a task inherits a high priority due to some inner semaphore it owns,
|
|
it doesn't lose that priority until it relinquishes all the semaphores it
|
|
holds. This doesn't quite follow the rules for priority inheritance (to
|
|
the extent that there really are any rules) in that normally, a task's
|
|
inherited priority should decrease as it releases each nested semaphore to
|
|
whatever the priority ceiling is for the semaphores it still holds. Getting
|
|
this incremental priority reduction to work right in practice, though,
|
|
is extremely difficult (some of the SUN papers on the Solaris real time
|
|
scheduling indicate that this was one of the hardest things for SUN to
|
|
get right in their OS upgrades). Given that VxWorks is a real time embedded
|
|
OS, I, for one, don't care if WRS uses the current implementation even
|
|
though it isn't "pure" because the result is a more reliable implementation
|
|
that runs more deterministically. Anyway, my guess is that you will find
|
|
that you have some nested semaphore code where you are doing something
|
|
after releasing one of the nested semaphores that shouldn't be done at a
|
|
high priority.
|
|
|
|
------------------------------
|
|
|
|
33. Gotchas w.r.t watchdogs
|
|
|
|
watchdog handlers run at interrupt level. You should not use
|
|
routines that can block in interrupt level code. Frequent mistakes:
|
|
using printf() in watchdog routines -- use logMsg() instead.
|
|
|
|
------------------------------
|
|
|
|
34. Is it possible to delete a memory partition in VxWorks?
|
|
|
|
No. memPartDestroy() is not really implemented. Perhaps it will
|
|
be in the future. Currently it just returns ERROR.
|
|
|
|
------------------------------
|
|
|
|
35. rename() does not work in netDrv and nfsDrv filesystems, why?
|
|
|
|
Because rename() is not implemented for netDrv (although it could be),
|
|
and nfsDrv does not implement rename() completely either.
|
|
|
|
Talk to WRS to get these fixed.
|
|
|
|
------------------------------
|
|
|
|
36. Free NFS Server for VxWorks
|
|
|
|
A free, incomplete, sample implementation (i.e. hack) of NFS Server
|
|
for VxWorks is available in:
|
|
|
|
netcom.com:/pub/hjb/vxnfsd.tar.gz
|
|
|
|
There is a README file there that describes further details. The current
|
|
snapshot of this implementation is a result of a couple of days of
|
|
hacking, doesn't do everything right, and intended for educational and
|
|
further hacking purpose.
|
|
|
|
There is someone else who's porting the MS-DOS PC-based nfs server (SOSS?)
|
|
to VxWorks. Not clear on its availability yet (let me know!)
|
|
|
|
------------------------------
|
|
|
|
37. Free SNMP for VxWorks
|
|
|
|
hoff@bnlux1.bnl.gov (Lawrence T. Hoff) reports,
|
|
|
|
We ported the CMU SNMPv2 code to vxWorks 5.1. This latest round of posts has
|
|
prompted me to put it in anonymous ftp (ctrldev1.rhic.bnl.gov --
|
|
130.199.96.82).
|
|
|
|
SNMP Research sells VxWorks compatible port of their SNMP implementation
|
|
with support. Their's cost $$$$$, though.
|
|
|
|
------------------------------
|
|
|
|
38. What third party products are available for VxWorks?
|
|
|
|
I tried to include the third party products, list of consultants,
|
|
services, goodies, etc. available for VxWorks from various sources but...
|
|
there are too many to list here. Instead,
|
|
|
|
the file:
|
|
|
|
netcom.com:/pub/hjb/vxworkers.gz
|
|
|
|
is updated in realtime to contain a list of individuals and companies
|
|
that offer help, services (paid or unpaid), and goods for VxWorks.
|
|
|
|
To get a copy (if you don't have ftp access) or to be listed in this file,
|
|
please contact or send info in ASCII to:
|
|
|
|
hjb@netcom.com.
|
|
|
|
------------------------------
|
|
|
|
39. What kind of products have been developed using VxWorks?
|
|
|
|
- Flight simulators
|
|
- Radio and optical telescopes
|
|
- Automative ABS & realtime suspension
|
|
- Naviation systems
|
|
- Deep sea instrumentation
|
|
- PBXs
|
|
- Traffic lights
|
|
- Modems
|
|
- Sonar systems
|
|
- Comm/weather satellite test equipment.
|
|
- X terminals
|
|
- PostScript laser printers
|
|
|
|
---------------------------------
|
|
|
|
40. A complete list of CPU hardware supported by VxWorks
|
|
|
|
Complete list of WRS supported BSP's are available in:
|
|
|
|
netcom.com:/pub/hjb/vxbsp.gz
|
|
|
|
VxWorks runs on a lot of different hardware. Majority of hardware
|
|
supported is based on VME bus. Porting VxWorks to a new VME board
|
|
based on MC68K takes only a few days, give or take a week, depending
|
|
on your karmic condition at the time. A lot of the ports are
|
|
initially done by the customers and later "approved" by WRS, for
|
|
which they charge, in order to keep them on "supported" list.
|
|
|
|
Porting to a new "architecture" (new processor) takes longer.
|
|
This varies more widely -- from a few months to a few years.
|
|
|
|
---------------------------------
|
|
|
|
41. A complete list of peripheral devices supported by VxWorks
|
|
|
|
Complete list of WRS supported BSP's are available in:
|
|
|
|
netcom.com:/pub/hjb/vxbsp.gz
|
|
|
|
VxWorks supports a wide variety of devices. A lot of device drivers
|
|
are written both by customers and WRS staff. There are device drivers
|
|
for almost popular available ethernet chips (except perhaps SEEQ and
|
|
Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async
|
|
COMM chip, etc.), little I/O thingies in micro-controllers (MC68302
|
|
serial I/O, etc.), SCSI, etc.
|
|
|
|
Customers of VxWorks, hackers and other hardware vendors (especially
|
|
VME) usually have a VxWorks driver for their board. There are drivers
|
|
for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers,
|
|
frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch
|
|
toy games.
|
|
|
|
A list of available device driver for VxWorks can be found in:
|
|
|
|
netcom.com:/pub/hjb/vxdrivers.gz
|
|
|
|
----------------------------------
|
|
|
|
42. What's with these unbundled "accessories"?
|
|
|
|
Propaganda from WRS:
|
|
|
|
The new product/feature doesn't need to wait for the
|
|
next OS release. Only the users who want/need it pay for it
|
|
lengthens price list which keeps individual items lower
|
|
but still enhances WRS revenue growth.
|
|
|
|
Please Note:
|
|
WRS still always adds features to the core product, and
|
|
has never taken items out of core product to make them
|
|
unbundled. Unlike UNIX vendors and others.
|
|
|
|
-----------------------------------------
|
|
|
|
43. How come my 5.0.2 BSP isn't available in 5.1, damn it?
|
|
|
|
Propaganda from WRS:
|
|
|
|
WRS tries to give customers 1 year warning when any product
|
|
may be discontinued. Unfortunately, all the bugs in
|
|
the notification system are still to be worked out.
|
|
Complain vehemently to your sales rep. if he didn't
|
|
keep you informed. WRS BSP obsoletion policy is primarily
|
|
based on BSP volume and h/w avalability.
|
|
|
|
The 5.1 Guide and Release Notes provide a step by step recipe to
|
|
upgrade from 5.0.2 -- minimal changes, start by ANISifying. The BSP
|
|
Port Kit 1.1 provides extensive info for the masochist.
|
|
|
|
----------------------------------------
|
|
|
|
44. How much is VxWorks?
|
|
|
|
In general: Not free, in fact, quite the opposite.
|
|
|
|
- Development License $23.5K (per project?)
|
|
- Source $120K.
|
|
- Target Licenses from $1000 for single quantity to $10 for 100,000+.
|
|
|
|
------------------------------
|
|
|
|
45. What is MicroWorks?
|
|
|
|
VxWorks is also available as a kernel-only product (MicroWorks 1.0) for
|
|
the following processors:
|
|
|
|
i960, 680x0, 683xx
|
|
|
|
MicroWorks is -- half the product at a half the price.
|
|
|
|
It has no network, native debug, shell, or profiling. Comes with
|
|
VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0
|
|
also included -- this is the debug agent which allows true system
|
|
level debugging in ISR or wherever. In future, VxWorks may also be
|
|
able to work with VxMon.
|
|
|
|
Development License $12,500.
|
|
|
|
------------------------------------
|
|
|
|
46. Other Unbundled Products for VxWorks?
|
|
|
|
Other unbundled "accessory" products are: VxMP ($4K) which is an
|
|
extended shared memory capabilities for the kernel allowing semaphores
|
|
and other objects to be manipulated over the backplane transparently
|
|
(really!).
|
|
|
|
VxVMI ($3K) is a library of virtual memory interface routines allowing
|
|
text & kernel data protection. complementary products: BSP Port Kit
|
|
1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++
|
|
Gateway for ObjectCenter ($?K's), and Realtime Innovations StethoScope (3K).
|
|
|
|
-----------------------------
|
|
|
|
47. How can I find out more about VxWorks?
|
|
|
|
Read: comp.os.vxworks
|
|
Email: inquiries@wrs.com
|
|
Call: 1-800-KIK-WIND
|
|
|
|
------------------------------
|
|
|
|
48. What other net.resources are available on real-time systems?
|
|
|
|
There is at least one other newsgroup devoted exclusively to a particular
|
|
vendor's real-time operating system:
|
|
|
|
comp.os.os9 Discussions about the OS/9 operating system.
|
|
|
|
Here are some other related newsgroups:
|
|
|
|
comp.arch Computer architecture.
|
|
comp.arch.bus.vmebus Hardware and software for VMEbus Systems.
|
|
comp.os.misc General OS-oriented discussion not carried elsewhere.
|
|
comp.realtime Issues related to real-time computing.
|
|
comp.os.os9 Issues related to OS9 and OS9000 realtime OS.
|
|
|
|
There are too many other newsgroups devoted to computer operating systems
|
|
to list here. The interested reader is advised to check the "newsgroups"
|
|
file on a local news service machine.
|
|
|
|
The automatic server for users of pSOS RTOS is now in place.
|
|
|
|
PSOSUSER - A list intended for the discussion of topics relating to
|
|
pSOSystem and other products of Integrated Systems Inc.,
|
|
Software Components Group.
|
|
|
|
Send articles to psosuser@isi.com and administrative requests to
|
|
listserver@isi.com.
|
|
|
|
If you aren't already subscribed and would like to, please send a mail
|
|
message to listserv@isi.com containing the following in the body of
|
|
the message
|
|
|
|
SUBSCRIBE PSOSUSER <substitute your full name here>
|
|
|
|
------------------------------
|
|
|
|
49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?
|
|
|
|
Use ioctl() instead.
|
|
|
|
...
|
|
{
|
|
...
|
|
int on = 1; /* turn it on */
|
|
...
|
|
ioctl(fd, FIONBIO, &on);
|
|
...
|
|
}
|
|
|
|
------------------------------
|
|
|
|
50. Free lex and yacc for use with VxWorks
|
|
|
|
John Winas (winas@phebos.aps.anl.gov) writes,
|
|
|
|
I just (moments ago) uploaded the two packages to thor.ncar.ucar.edu where
|
|
the vxWorks archive is. When ever the maintainer moves it into the release
|
|
area they will be available to everyone. I named the file lexyacc.tar.Z
|
|
and it contains all of the sources and make files for you to build them.
|
|
It all seems to work perfectly on my sun sparc running 4.1.3. The
|
|
only thing you have to configure is the full path name to where you wish
|
|
to keep flex so that it can find its skeleton file when you use it to
|
|
lexify your .l files. Byacc has no skeleton files and simply needs to
|
|
be in your path.
|
|
|
|
This file is now available in:
|
|
|
|
epics.aps.anl.gov:/pub/lexyacc.tar.Z
|
|
|
|
I am interested in any bugs found in because we are using them here. Feel
|
|
free to email me at winans@phebos.aps.anl.gov.
|
|
|
|
------------------------------
|
|
|
|
51. timer_gettime() bug
|
|
|
|
[ From: kent@wrs.com (Kent Long) ]
|
|
|
|
In article <9311230139.AA21147@focal.com> bobk@focal.com (Bob Klawuhn) writes:
|
|
>I am currently trying to user the timerLib to obtain
|
|
>the amount of time that a timer has left before it
|
|
>expires. I am trying to use the timer_gettime function.
|
|
>The value that it seems to return is always the time
|
|
>that the start timer was given, not what is left on the
|
|
>timer.
|
|
|
|
|
|
This is indeed a bug in the 5.1 and 5.1.1 VxWorks versions.
|
|
It is now being tracked as WRS SPR #2673.
|
|
|
|
As a workaround, the following could be done following the
|
|
timer_gettime() call, to convert the erroneous results into
|
|
the desired remainder value:
|
|
|
|
|
|
#include "private/timerLibP.h"
|
|
struct timespec timeNow;
|
|
|
|
(void) clock_gettime (CLOCK_REALTIME, &timeNow);
|
|
TV_SUB (timerid->exp.it_value, timeNow);
|
|
|
|
...which leaves the remainder in it_value.
|
|
|
|
------------------------------
|
|
|
|
52. bogus INCLUDE_TCP_DEBUG
|
|
|
|
[ From: hipp@wrs.com (Emily Hipp) ]
|
|
|
|
>Bus Error
|
|
>Program Counter: 0x0001c738
|
|
>Status Register: 0x3000
|
|
>Access Address : 0xbfbfbfd3
|
|
>Special Status : 0x0505
|
|
>Task: 0x3dcc54 "tExcTask"
|
|
>TCP tracing not enabled (use INCLUDE_TCP_DEBUG).
|
|
|
|
This is misleading information. INCLUDE_TCP_DEBUG is not supported
|
|
as a configAll.h include option.
|
|
|
|
[ editorial:
|
|
INCLUDE_TCP_DEBUG never got integrated into VxWorks config files.
|
|
To get around this bug, until WRS fixes it, either unset SO_DEBUG
|
|
socket option using getsockopt()/setsockopt(), or call tcpTraceInit() (sp?)
|
|
which will drag in tcp_debug.o and set the tcp_trace() routine to
|
|
be called when debug option is set on TCP sockets.
|
|
]
|
|
|
|
------------------------------
|
|
|
|
53. free ppp for VxWorks
|
|
|
|
Is available via anonymous ftp
|
|
|
|
netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz
|
|
|
|
------------------------------
|
|
|
|
54. how to disable cache on mc68040 or mc68030 using TT regs?
|
|
|
|
[ From: Steve Morris <morriss@smtplink.indigo.co.il> ]
|
|
|
|
/**************************/
|
|
/* for 68030 (e.g. mv147) */
|
|
/**************************/
|
|
|
|
/* 2 large areas, R/W, cache disabled */
|
|
#define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */
|
|
#define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */
|
|
|
|
test_tt ()
|
|
{
|
|
register int *pVal;
|
|
int ttVal;
|
|
|
|
pVal = &ttVal;
|
|
|
|
ttVal = TT0_VALUE;
|
|
asm ("pmove %0,tt0" : : "g" (*pVal));
|
|
ttVal = TT1_VALUE;
|
|
asm ("pmove %0,tt1" : : "g" (*pVal));
|
|
}
|
|
|
|
/**************************/
|
|
/* for 68040 (e.g. mv167) */
|
|
/**************************/
|
|
|
|
/* 2 large areas, R/W, cache disabled */
|
|
#define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */
|
|
#define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */
|
|
|
|
test_dtt ()
|
|
{
|
|
asm ("movec %0,dtt0" : : "r" (DTT0_VALUE));
|
|
asm ("movec %0,dtt1" : : "r" (DTT1_VALUE));
|
|
}
|
|
|
|
------------------------------
|
|
|
|
55. work-arounds for MS-DOS filesystem bug when lseek() past eof
|
|
|
|
[From: georg@sgl.ists.ca (Georg Feil)]
|
|
|
|
[editorial: This is a workaround for the bug in VxWorks ms-dos
|
|
implementation which produces incorrect error return on write() after
|
|
lseek() beyond eof. N.B.: VxWorks versions upto 5.1.1 have buggy IO
|
|
system layer that does not support "correct" write() to normal files.
|
|
When writing to a file via write() expect to check the return value
|
|
even if it is not ERROR. Unlike most other systems (e.g. UNIX) VxWorks
|
|
write() upto version 5.1.1 will return number of bytes actually written
|
|
even when write() was not completely successful on devices that are
|
|
not marked non-blocking and/or are subject to flow control. ]
|
|
|
|
There's been enough heated debate on this so I'm sending out my brute force
|
|
workaround. Thanks to Kent Long who managed to let slip enough information
|
|
on the bug to identify the prerequisite: lseek() past the end of file.
|
|
|
|
My workaround simply extends a file by writing 0's on the end whenever there
|
|
is a seek past the end. (This may result in a file being extended when it
|
|
shouldn't have been, i.e. no write follows the seek, but what the hell.)
|
|
Use file_seek() below instead of lseek() to seek. Note that file_seek() is
|
|
not meant to be plug-replaceable with lseek(), that feature is not
|
|
required in our system. 'zero8k' is a character array of 8192 zero bytes.
|
|
|
|
|
|
int file_seek(int fd, int offset)
|
|
/*
|
|
* Sets the byte offset for the next write or read from a file.
|
|
* Simple interface to lseek() function. This returns ERR_NONE iff the actual
|
|
* actual seek offset returned by lseek() exactly matches the desired offset.
|
|
* 'fd' is the file descriptor to seek on.
|
|
* 'offset' is the absolute file position to seek to in bytes, where 0 is
|
|
* the beginning of file.
|
|
* Return value is error code (not a VxWorks error code, another type).
|
|
*/
|
|
{
|
|
STATUS st;
|
|
struct stat filestat; /* file status info obtained from fstat() */
|
|
int aoff; /* actual seek offset returned by lseek() */
|
|
long int fillsz; /* (***) for SPR #2739 kludge */
|
|
long int fillamt; /* (***) for SPR #2739 kludge */
|
|
|
|
if (FileDebug && Verbose>=2) {
|
|
wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n",
|
|
offset,fd);
|
|
}
|
|
|
|
/* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with
|
|
transfer count too low but errno not set after seeking past current
|
|
end of file). Note that this may extend the file prematurely, i.e.
|
|
even if no write() calls follow the seek. */
|
|
/* get current file size */
|
|
st=fstat(fd, &filestat);
|
|
if (st==VX_ERROR) {
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n",
|
|
fd, vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
|
|
/* manually extend file using zero writes if seek offset past end of file
|
|
(note: tried ioctl() with FIOTRUNC, but this only works to shorten
|
|
files! */
|
|
if (offset>filestat.st_size) {
|
|
/* seek to the end of the file first */
|
|
errno=0;
|
|
aoff=lseek(fd, filestat.st_size, SEEK_SET);
|
|
if (aoff != filestat.st_size) {
|
|
/* returned value should always match 'filestat.st_size' */
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n",
|
|
fd, aoff, filestat.st_size, vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
|
|
/* fill file with zeroes to bring length up to 'offset' */
|
|
fillsz=offset-filestat.st_size;
|
|
while (fillsz>0) {
|
|
if (fillsz>8192)
|
|
fillamt=8192;
|
|
else
|
|
fillamt=fillsz;
|
|
|
|
errno=0;
|
|
aoff=write(fd, zero8k, fillamt);
|
|
if (aoff == VX_ERROR) {
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n",
|
|
fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
|
|
if (aoff != fillamt) {
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n",
|
|
fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
|
|
fillsz -= fillamt;
|
|
}
|
|
|
|
/* flush the output to disk immediately */
|
|
st=ioctl(fd, FIOFLUSH, 0);
|
|
if (st!=VX_OK) {
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n",
|
|
fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
}
|
|
|
|
/* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */
|
|
|
|
|
|
errno=0;
|
|
aoff=lseek(fd, offset, SEEK_SET);
|
|
if (aoff == VX_ERROR) {
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n",
|
|
offset, fd, vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
|
|
/* returned value should always match 'offset' */
|
|
if (aoff != offset) {
|
|
if (Verbose>0) {
|
|
wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n",
|
|
fd, aoff, offset, vw_errmsg(0));
|
|
}
|
|
return(ERR_VXIO);
|
|
}
|
|
|
|
return(ERR_NONE);
|
|
}
|
|
|
|
------------------------------
|
|
|
|
56. TCL for VxWorks
|
|
|
|
[ From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) ]
|
|
|
|
Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is
|
|
on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz
|
|
|
|
If you've ever been frustrated that the VxWorks shell is not re-entrant,
|
|
and has no control flow (e.g. if then else, switch, case ),
|
|
then you will find TCL very useful since it is a very complete language,
|
|
that allows you to add your own application specific commands to
|
|
the interpreter.
|
|
|
|
I find it invaluable for system testing, since I register TCL commands for
|
|
all major functionality of my real-time application. This allows me
|
|
to test most pieces of my data acquisition system from a command line,
|
|
and build nice flexible scripts to test and operate my system. As a
|
|
matter of fact, I can even invoke specific methods of C++ classes via
|
|
TCL.
|
|
|
|
Also, you can control your real-time system from a Unix workstation by
|
|
sending TCL commands from either a TCL or Tk/TCL application (via
|
|
tclTCP). I find that sending TCL commands (which are just strings) is
|
|
much easier and more flexible than writing a Remote Procedure Call
|
|
(RPC) for each piece of functionality that I need to remotely invoke.
|
|
|
|
------------------------------
|
|
|
|
57. adding default route
|
|
|
|
A default route is a route table entry with destination field set to 0.
|
|
To do the equivalent of "route add default gateway metric" in VxWorks,
|
|
do:
|
|
routeAdd("0",addr_of_gateway);
|
|
|
|
------------------------------
|
|
|
|
58. adjusting network driver MTU size
|
|
|
|
VxWorks network driver are compatible (mostly) with tahoe BSD drivers.
|
|
To change MTU you should modify "if_mtu" field of "struct ifnet" you
|
|
pass to ether_attach() or if_attach().
|
|
|
|
------------------------------
|
|
|
|
59. tcpdump like utility for vxworks
|
|
|
|
Take a look at a hacked up packet trace program in:
|
|
|
|
netcom.com:/pub/hjb/vxsniff.c.gz
|
|
|
|
[editorial: if you have something better, let me know]
|
|
|
|
------------------------------
|
|
|
|
60. VxWorks performance on i960 -- unofficial benchmark
|
|
|
|
[ From: djanssen@mswe.dnet.ms.philips.nl (Ton Janssen, 62203 (TSSW)) ]
|
|
|
|
We did some measurements on a Heurikon HK80/V960E.
|
|
Equiped with I960CA on 33MHz. Here they are:
|
|
|
|
Test-item Conditions Time in us
|
|
==========================================================================
|
|
- semGive/semTake pair (binary semaphore) 11,2
|
|
- taskSpawn (+/- 8 processes active) 790,0
|
|
- taskIdVerify 0,72
|
|
- taskSuspend/taskResume pair (+/- 8 processes active) 32,6
|
|
- lstAdd/lstDelete pair (10 nodes in list) 3,9
|
|
- msgQNumMsgs 1,2
|
|
- msgQReceive (NOWAIT, no message available) 16,8
|
|
- rngBufPut/rnBufGet pair (0x20 bytes) 24,5
|
|
- msgQSend/msgQReceive pair (NOWAIT, no arguments) 65,7
|
|
- bcopy (Quad aligned data) 0,515/Quad
|
|
- mutliply two floats (depends on the value!) 1,6
|
|
- multiply two doubles ( '' '' ) 2,6
|
|
- Raw context switch (8 processes active) 34,0
|
|
|
|
------------------------------
|
|
|
|
61. VxWorks SCSI Performance -- unofficial benchmark
|
|
|
|
[ From: mea@mclean.sparta.com (Mike Anderson) ]
|
|
|
|
System : Heurikon HK68G/V4D
|
|
(33 MHz 68040, 16 MB RAM, NCR53C710 SCSI
|
|
w/ Hk SCSI DMA routines in Asynchronous SCSI mode)
|
|
|
|
VxWorks : 5.1.1 (Yes, using Heurikon VxWorks 5.1 BSP)
|
|
|
|
Disk : Seagate ST11200N (1 GB SCSI)
|
|
|
|
File System: VxWorks RAW partition mounted as "/sd1/"
|
|
|
|
Clock Rate : 60 Hz
|
|
|
|
Approach:
|
|
|
|
My application has the data coming in in 16Kbyte chunks. So, I devised
|
|
a piece of test code that would allow me to specify how many 16K chunks
|
|
I sent to the disk in each write and how many total bytes to write.
|
|
The actual number of bytes written is generally a little larger
|
|
(typically one more block size) due to the quick and dirty way I wrote
|
|
the code, but the calculations are based on the actual number of bytes
|
|
written to the disk. The technique I used was to write a block to the
|
|
disk starting at the end of the last write and then seek back to
|
|
relative zero and write the current pointer (just as I would in real
|
|
life to know how many bytes had been streamed total). Also, you
|
|
may notice the disk seek time coming into effect in the 200MByte files.
|
|
|
|
Here are the results:
|
|
|
|
Buffer Size Total Requested Bytes/sec total secs
|
|
16K 1024000 (1 MB) 1,032,192 1.000 secs
|
|
10240000 (10 MBs) 1,036,087 9.883 secs
|
|
102400000 (100 MBs) 1,049,538 97.566 secs
|
|
204800000 (200 MBs) 1,043,123 196.333 secs
|
|
|
|
32K 1024000 1,613,193 0.650 secs
|
|
10240000 1,627,997 6.300 secs
|
|
102400000 1,627,980 62.900 secs
|
|
204800000 1,610,485 127.166 secs
|
|
|
|
48K 1024000 1,935,360 0.533 secs
|
|
10240000 1,994,712 5.150 secs
|
|
102400000 1,992,209 51.416 secs
|
|
204800000 1,970,335 103.950 secs
|
|
|
|
64K 1024000 2,169,467 0.483 secs
|
|
10240000 2,244,905 4.583 secs
|
|
102400000 2,246,332 45.600 secs
|
|
204800000 2,216,450 92.400 secs
|
|
|
|
96K 1024000 2,495,409 0.433 secs
|
|
10240000 2,580,480 4.000 secs
|
|
102400000 2,571,534 39.833 secs
|
|
204800000 2,533,374 80.866 secs
|
|
|
|
128K 1024000 2,621,440 0.400 secs
|
|
10240000 2,761,250 3.750 secs
|
|
102400000 2,771,147 36.983 secs
|
|
204800000 2,726,693 75.133 secs
|
|
|
|
256K 1024000 2,859,752 0.366 secs
|
|
10240000 3,130,077 3.350 secs
|
|
102400000 3,139,304 32.650 secs
|
|
204800000 3,083,428 66.483 secs
|
|
|
|
512K 1024000 3,145,728 0.333 secs
|
|
10240000 3,346,519 3.133 secs
|
|
102400000 3,361,846 30.566 secs
|
|
204800000 3,298,416 62.150 secs
|
|
|
|
1024K 1024000 3,311,292 0.316 secs
|
|
10240000 3,475,942 3.016 secs
|
|
102400000 3,487,345 29.466 secs
|
|
204800000 3,416,806 60.150 secs
|
|
|
|
------------------------------
|
|
|
|
62. VME bus arbitration gotchas
|
|
|
|
[ From: mea@mclean.sparta.com (Mike Anderson) ]
|
|
|
|
> Sender: Rob Steele, e-mail: steele@telerobotics.jpl.nasa.gov
|
|
>
|
|
>
|
|
> I have the following VME hardware configuration:
|
|
>
|
|
> VME MOTES chassis:
|
|
> 1 Motorola system controller card,
|
|
> 6 Huerikon 68020 CPU boards (HKV2A),
|
|
> 1 Micro Memory shared memory cards,
|
|
> 1 Bit-3 memory interface card,
|
|
> 2 XYCOM parallel boards, and
|
|
> 1 Excelan ethernet cards.
|
|
>
|
|
> VadsWorks 2.0.1 (equivalent to vxWorks 5.0).
|
|
>
|
|
> I am unable to consistently boot the chassis. I will get bus errors and file
|
|
> not present errors during the boot process on different boards. On rare
|
|
> occasions it will boot. To get it to boot I halt the boot process on the last
|
|
> 4 boards in the chassis and let the first two boot. After that I boot the
|
|
> last 4 one at a time.
|
|
>
|
|
|
|
This sounds like the bus arbitration bug biting. If the Heurikon
|
|
boards are all at the same bus grant level (they typically come from
|
|
the factory set for BG3) then you will experience "random" failures
|
|
that manifest themselves as bus errors when a board is requesting
|
|
access to the bus and the bus is so busy that the bus watchdog timer
|
|
(1.6ms on the HKV2F I think) expires. This is proper behaviour. The
|
|
watchdog timer is designed to alert the task that it was unsuccessful
|
|
in accessing a VME address in the alotted time and to signal that
|
|
failure with a bus error.
|
|
|
|
Now, there are several ways to fix this problem. One which I heard
|
|
about was to modify the boot ROMs to insert a variable length delay so
|
|
the first CPU booted immediately, the second booted 30 secs later the
|
|
third 60 secs later, etc. This approach was clearly a software hack
|
|
trying to get around a hardware problem that was obviously not
|
|
understood. This approach *may* get the boards to boot, but with heavy
|
|
bus traffic during execution, they will continue to exhibit bus
|
|
errors. You see, because the VMEbus is a daisy chain, the first CPU in
|
|
the chain has an inherently higher priority than all others that follow
|
|
it. The 2nd board gets the next highest priority, etc. This means
|
|
that a graph of bus access at a given BG level looks something like
|
|
this:
|
|
|
|
% 60 |
|
|
|
|
|
A 50 | *
|
|
|
|
|
C 40 |
|
|
|
|
|
C 30 |
|
|
| *
|
|
E 20 |
|
|
| *
|
|
S 10 |
|
|
| *
|
|
S 0 |------------------*---*--
|
|
1 2 3 4 5 6
|
|
# CPUs @ BG level
|
|
|
|
I.e., it is roughly an exponential decay such that, given that the
|
|
level of bus activity is moderately high, the first 1-3 CPUs will hog
|
|
85-95% of the bus cycles and CPUs 4 and beyond will exhibit bus
|
|
errors. If the bus activity level is very high such as during a boot
|
|
up via the backplane, you may not be able to get past CPU 2 before bus
|
|
errors manifest themselves.
|
|
|
|
Now, as I said, there are other ways to circumvent this problem.
|
|
Boards equipped with the VIC68 VMEbus interface, for instance, can have
|
|
their bus timeouts changed to the point of an infinite wait (i.e., the
|
|
bus watchdog is disabled). This is still just a kludge that masks the
|
|
real problem of a poorly thought-out arbitration scheme. With this
|
|
approach, *real* bus errors resulting from errant pointers and/or
|
|
failed boards are never reported and the system just seems to hang.
|
|
|
|
The REAL solution to this problem is to adjust the arbitration levels
|
|
of the CPUs. In the VMEbus, there are 4 levels of arbitration (0-3)
|
|
where level 3 is the highest priority. By default, virtually all
|
|
manufacturers ship their boards configured for BG3. Therein lies the
|
|
problem. What the real-time designer needs to do is to realize this
|
|
and make adjustments. Within the 4 BG levels, there are two modes of
|
|
operation: 1) priority and 2) round robin. Priority mode means that
|
|
requests at level 3 will be honored before requests at level 2. Level
|
|
2 before level 1 and so on. This means that with priority mode
|
|
arbitration, put your highest priority boards at level 3 and distribute
|
|
the other boards at the other levels according to their relative
|
|
priorities.
|
|
|
|
On the other hand, round robin arbitration mode means that all 4 BG
|
|
levels are treated equally and each level gets a fair slice of the pie
|
|
so to speak. Use this mode when you have lots of boards, but no one
|
|
has an inherently higher priority than any other. With this approach,
|
|
we've been able to get as many as 16 CPUs running in the same backplane
|
|
(4 at each level) without experiencing bus error problems due to
|
|
arbitration. Remember, just because the boards are at different BG
|
|
levels doesn't circumvent the implied priorities of the CPUs at the
|
|
*same* level based on the bus daisy chain.
|
|
|
|
Typically, these modes are configurable on the system controller either
|
|
through a jumper, PAL or software bit twiddling. However, there are
|
|
boards that are hardwired for arbitration level 3 and they can't be
|
|
changed. The Force SPARC 1E board is one of them. This means that
|
|
you'll have to use these boards sparingly in VxWorks chassis (i.e.,
|
|
probably no more than 3-4 booting up from the backplane but probably
|
|
more if you boot each of them up from local Ethernet). I understand
|
|
that the SPARC 2CE board uses the same VMEbus interface as the 1E which
|
|
simply means that the bus errors will happen twice as fast. Hopefully,
|
|
the 3E board will get a real bus interface on it if it ever comes out.
|
|
|
|
------------------------------
|
|
|
|
63. 5.1.X new MMU supporting code gotchas, as explained in the Manual
|
|
|
|
Carl Lacy points out:
|
|
|
|
1) Programmer's Guide, Chapter 8.3, page 319
|
|
How to setup the the MMU for VMEbus address spaces
|
|
|
|
2) 5.1 Known Problems, Apr '93, page 5
|
|
"Several BSPs turn on basic MMU support ... even if
|
|
this option is not specified in configAll.h"
|
|
|
|
------------------------------
|
|
|
|
64. "Cannot Boot. Error 0x1a9" while downloading/booting
|
|
|
|
This is usually due to the built-in 'feature' inside UNIX inetd program.
|
|
The inetd tries to protect itself against clients that tries to connect
|
|
too often too quick as a security measure, and disallows more than a
|
|
certain number of connections per given period. When this happens, you
|
|
will usually see some error messages about "looping..." in syslog (if
|
|
your syslog is configured correctly) on your UNIX server (where inetd
|
|
is running). You can either try "kill -HUP inetd_process_id" to get
|
|
out of this looping mode by sending HUP signal to inetd, or try and
|
|
install the patched version of inetd that has larger default limit for
|
|
looping detection (some OS vendors will supply this to you), or just
|
|
get a copy of BSD UNIX distribution of inetd source code and compile it
|
|
with larger default values for looping and use it instead.
|
|
|
|
------------------------------
|
|
|
|
65. problem with qsort in some versions of VxWorks
|
|
|
|
Some version of VxWorks are shipped with incorrect qsort(), to remedy
|
|
this problem, get a copy of qsort() from BSD UNIX distribution and
|
|
compile it.
|
|
|
|
------------------------------
|
|
|
|
66. fmod fiasco
|
|
|
|
From: jbrandt@sadira.gb.nrao.edu (JOE BRANDT)
|
|
|
|
remainder = fmod(value, divisor) - floating point modulus routine.
|
|
|
|
The fmod math subroutine for MC68040 (mv167) based systems has been a
|
|
topic of discussion on the exploder for many months now. The first
|
|
discussions centered around the routine's accuracy (or even
|
|
correctness). Recently I found that the execution time for the fmod
|
|
subroutine is highly dependent upon the ratio of the values passed as
|
|
arguments. At a ratio of about 50,000 I was seeing execution times of
|
|
30ms! The VxWorks exploder FAQ now includes a proposed replacement
|
|
routine for 68040 systems, however, I have examined this routine and
|
|
found it to be grossly in error in cases where the divisor is less than
|
|
1.0.
|
|
|
|
Fortunately, I have found public domain source, authored by Sun Micro,
|
|
for an alternative algorithm. This algorithm claims an exact result.
|
|
It can be found at:
|
|
ftp: plan9.att.com in /netlib/fdlibm/e_fmod.c.Z
|
|
(I believe ftp.uu.net has copies also).
|
|
This appears to be a ieee 754 compliant routine. (I'm not sure what that
|
|
means, but it sounds good).
|
|
|
|
Execution times for this routine are in the range of 7.6 to 100 usec's.
|
|
|
|
|
|
From: vince@rti.com (Vince Chen)
|
|
|
|
> Submitted-by jbrandt@sadira.gb.nrao.edu Thu Mar 24 12:41:16 1994
|
|
> Submitted-by: jbrandt@sadira.gb.nrao.edu (JOE BRANDT)
|
|
>
|
|
> While I currently am not questioning the accuracy of the fmod() function,
|
|
> the performance of it on the mv167 card (68040) is certainly an issue.
|
|
>
|
|
> Here's some benchmarks from my 5.1/mv167 system:
|
|
>
|
|
> -> timexN(fmod, 49999.9, 1.0)
|
|
> timex: 25 reps, time per rep = 30661 +/- 666 (2%) microsecs
|
|
>
|
|
> -> timexN(fmod, 2.0, 1.0)
|
|
> timex: 50000 reps, time per rep = 9 +/- 0 (0%) microsecs
|
|
>
|
|
> -> timexN(fmod, 499.9, 1.0)
|
|
> timex: 2525 reps, time per rep = 305 +/- 6 (1%) microsecs
|
|
>
|
|
> Note the dependency on value. Unfortunately I am doing an fmod on the
|
|
> modified julian date (which is currently in the 50,000 range). which
|
|
> took an amazing 30ms/call !
|
|
>
|
|
> Wow, can some elaborate on the algorithm being used here. seems like it's
|
|
> a straight while loop!
|
|
|
|
I believe it is a while loop. A while loop is faster in some situations,
|
|
but obviously no in yours!
|
|
|
|
Until WindRiver resolves the problem w/ the Motorola Floating Point
|
|
Exception library, you may want to roll your own on this one.
|
|
The code below on our 167/25MHz VxWorks 5.1 consistently results in 30 usecs.
|
|
|
|
double myfmod1( double arg1, double arg2 )
|
|
{
|
|
return (arg1 - ((int) (arg1 / arg2)) * arg2);
|
|
}
|
|
|
|
------------------------------
|
|
|
|
67. MVME167 copyback cache and various problems
|
|
|
|
From: georg@sgl.ists.ca (Georg Feil)
|
|
|
|
Well, I think we now know everything there is to know about the memPartFree()
|
|
problem we were having. The original subject here was "memPartFree error with
|
|
copyback caching enabled (167)". Other past subjects that possibly related to
|
|
the same problem include "Large disk writes w/cache cause MVME167 to freeze".
|
|
Apparently the root cause is a snooping problem related to TAS on the
|
|
VME bus, and is Motorola's fault.
|
|
|
|
The solution to the problem is the "MV167 VME TAS patch" from Wind River.
|
|
It consists of a number of configuration changes (config.h, usrConfig.c etc.)
|
|
and is reproduced below. Strangely, it has not been assigned an SPR number
|
|
because, according to Wind River, the new version of the 167 BSP has fixed
|
|
the problem so no SPR is necessary(?). This situation may have changed since
|
|
the memos I received were written. Our related TSR number was 16443, which may
|
|
help others to track things down.
|
|
|
|
I had already come up with my own patch that worked in a completely different
|
|
(and very specific) way, and the WRS patch seemed not to apply to our problem.
|
|
However I tested the patch anyway and sure enough it fixes our problem.
|
|
As a bonus, SCSI performance seems to have improved slightly.
|
|
|
|
------------------------------
|
|
|
|
68. unloading objects
|
|
|
|
From: stan@rti.com (Stan Schneider)
|
|
|
|
Under VxWorks 5.1.x, you can use 'unld "file.o"' (or use the module id,
|
|
see "moduleShow"). Under 5.0.x, you can't unload the object & reclaim the
|
|
space, but you could remove the symbols from the symbol table with symRemove.
|
|
That would prevent unnecessary maiming.
|
|
|
|
------------------------------
|
|
|
|
9999: Contributions to comp.os.vxworks FAQs.
|
|
|
|
The following net.folks, among others, have contributed to this posting:
|
|
[ If you have contributed, but are not listed here please me know. ]
|
|
|
|
Name email address
|
|
------------ ----------------------------
|
|
Mike Anderson mea@mclean.sparta.com
|
|
Mark Linimon linimon@nominil.lonestar.org
|
|
Geoff Espin geoff@wrs.com
|
|
Rev. Bob Crispen crispen@foxy.boeing.com
|
|
Stan Schneider stan@rti.com
|
|
Fred J Roeber fjr@ssd.ray.com
|
|
Marc Friedman maf@verdix.com
|
|
Joe Van Andel vanandel@ncar.ucar.edu
|
|
Emily Hipp hipp@wrs.com
|
|
Bob Marino ram@mr.picker.com
|
|
Richard Kowalsky cmdorat@tc.fluke.com
|
|
Kent Long kent@wrs.com
|
|
James Moore james@wrs.com
|
|
Chuck Meade chuckm@verdix.com
|
|
Patrick T. Pinkowski ppinkow@jupiter.ksc.nasa.gov
|
|
D'Anne Thompson dat@noao.edu
|
|
Leonid Rosenboim leonid@rst.hellnet.org
|
|
David Lim lim@robotics.jpl.nasa.gov
|
|
Richard Neitzel thor@thor.atd.ucar.edu
|
|
John Winas winas@phebos.aps.anl.gov
|
|
Lawrence T. Hoff hoff@bnlux1.bnl.gov
|
|
Georg Feil georg@sgl.ists.ca
|
|
Steve Morris morriss@smtplink.indigo.co.il
|
|
Don Brooks dab@netcom.com
|
|
Ton Janssen djanssen@mswe.dnet.ms.philips.nl
|
|
Brian Brunner brunner%mother@icarus.ssd.loral.com
|
|
Carl Lacy lacy@draper.com
|
|
Joe Brandt jbrandt@sadira.gb.nrao.edu
|
|
Vince Chen vince@rti.com
|
|
|
|
I welcome flames, insults, accusations, reactions, additions, and
|
|
corrections to this posting via email:
|
|
|
|
Hwa-Jin Bae
|
|
PEACEFUL STAR
|
|
hjb@netcom.com
|
|
|
|
------------------------------
|
|
|
|
===============================================================================
|
|
--
|
|
hwajin
|
|
PEACEFUL STAR
|