Optional Products
14.1 Overview
Shared Memory Objects (VxMP)
Virtual Memory (VxVMI)
®
14-2
Overview

The following products may be purchased separately if
desired.
BSP Porting Kit
Assists porting VxWorks to a new board on a
supported architecture.
VxSim
VxWorks simulation on a Solaris, HP-UX, or
Windows host. Full simulator includes
networking support and allows mulitiple
simulators per host.
WindNet SNMP
Provides remote network management of target
via SNMP.
OSPF
Open Shortest Path First link-state routing
protocol. More powerful than RIPv1/v2.
®
14-3
Overview
StethoScope
Host based debugging tool with GUI. Monitor
VxWorks program variables in real time, or store
data and analyze later. Also contains a task
profiler.
VxMP
High speed multiprocessing tools for distributed
applications needing to communicate over the
VMEbus.
VxVMI
Virtual memory support. Can restrict a tasks
access to certain addresses.
WindView
WindView support available for non-simulator
targets as an optional product.
TrueFFS
Flash file system--provides wear-leveling and
redundancy on FLASH parts.
®
14-4
Overview
Tornado For Java
Java Virtual Machine for VxWorks.
Interoperable VxWorks tasks and Java
threads.
Zinc for VxWorks
Small (about 0.5 MB) configurable C++
GUI Toolkit and libraries. Allows
customized look and feel for graphical
applications.
eNavigator /HTMLWorks
eNavigator is an embeddable browser,
based on Netscape Navigator; includes a
toolkit for customization and scalability.
HTMLWorks allows construction of
HTML-based graphical interfaces.
®
14-5
Overview
CodeTest
Code coverage and memory leak checking tool.
WindNavigator
Code browsing tool with support for C and C++.
Able to construct call tree.
Look!
C++ visualization and debugging tool. Allows
graphical exploration of a C++ program as it
executes.
®
14-6
Optional Products
Overview
14.2 Shared Memory Objects (VxMP)
Virtual Memory (VxVMI)
®
14-7
VxMP Features

Allows multiprocessing on the VMEbus.

Faster than shared memory network.

Components:
Name database
Allows boards to share information on
objects.
Shared semaphores
For mutual exclusion and
synchronization.
Shared message queues For message passing.
Shared memory manager To dynamically allocate and free shared
memory blocks.

Familiar interface (e.g., semGive( ), msgQSend( )).
®
14-8
Example Usage

The tFooServer task on CPU1 wants to read requests
from a shared message queue:
1. It first creates the message queue.
2. It then registers the MSG_Q_ID in the name database under the
name “ServerSMQueue”
3. Finally, it reads and services requests in a loop.

The tFooClient task on CPU0 wants to send a request to
tFooServer:
1. It first queries the name database to find the MSG_Q_ID under the
name “ServerSMQueue”
2. This MSG_Q_ID is then used to send requests to the server.
®
14-9
Registering Shared Objects
STATUS smNameAdd (name, objId, type)
name
objId
type
String used to name this object.
Shared memory object identifier (e.g., SEM_ID or
MSG_Q_ID).
The type of shared memory object (e.g. binary
semaphore or message queue).

Registers the object in the name database.

Typically called right after object creation.
®
14-10
Finding Shared Objects
STATUS smNameFind (name, &objId, &type,
wait)
name
objId
type
wait

Name to find in the database.
Object id returned through this variable.
Object type returned.
Wait until the object is created. Can be NO_WAIT or
WAIT_FOREVER. Does not specify timeout in ticks.
Obtains the objId of an object created on another board.
®
14-11
Shared Semaphores
SEM_ID semBSmCreate (options, initialState)
SEM_ID semCSmCreate (options, initialCount)

Creation routines similar to local semaphore creation
routines, except options must be SEM_Q_FIFO.

Mutex semaphores are not provided.

Once created, semLib routines (e.g., semGive( ),
semTake( )) work as before, except
– Can not give a semaphore from an ISR.
– May not delete semaphores.
®
14-12
Shared Message Queues
MSG_Q_ID msgQSmCreate (maxMsgs,
maxMsgLen, options)

Creation routine similar to local message queue creation
routine, except options must be MSG_Q_FIFO.

Once created, msgQLib routines (e.g., msgQSend( ),
msgQReceive( )) work as before, except can not send a
message from an ISR.
®
14-13
Shared Memory Manager

Can dynamically allocate/free blocks of shared memory:
void * smMemMalloc (nBytes)
smMemFree (void * ptr)

These routines use local addresses. When exchanging
address information through the name database, may
need to call:
void * smObjLocalToGlobal (localAdrs)
void * smObjGlobalToLobal (globalAdrs)
®
14-14
Creating Shared Memory Partitions

To creates additional shared memory partitions:
PART_ID memPartSmCreate (pPool, poolSize)
pPool
poolSize

Address of some shared memory.
Size of this pool.
Manipulated with memPartLib routines (just like local
partitions).
®
14-15
Terminology
Shared Memory Master - CPU 0. Initializes the shared
memory objects data structures. Once initialized, all boards
are peers.
Shared Memory - Memory used for shared memory objects.
Can be dual ported RAM on CPU0, or RAM on a memory
card, but it must be accessible to all CPU’s.
Anchor - Structure containing ready value and an offset to
shared memory. Must be at an address known by all CPU’s.
Heartbeat - Integer incremented once per second by CPU0,
used to indicate that the shared memory objects system is
alive.
Ready Value - Stored in anchor by CPU0 to indicate that the
shared memory objects facility is initialized.
®
14-16
System Requirements

All boards must support an atomic read-modify-write
cycle (e.g., test and set) in hardware.

Software implementation limits the number of CPU’s to 20
(CPU0 through CPU19). Hardware considerations may
limit this number further.
®
14-17
Caveats

Non-deterministic; exclusive access to shared memory
object over the VMEbus is subject to unpredictable
delays.

Slower than corresponding local objects; only use for
distributed applications.

Increases interrupt latency; interrupts are locked out
while shared memory object is updated.
®
14-18
Initialization

Include the component /operating system components/kernel
components/shared memory objects.

If booting over the shared memory network, no extra
initialization necessary.

If not booting over the shared memory network:
1. On CPU0, configure the location and size of the shared memory
region. Boot CPU0.
2. Before another CPU can access shared memory objects, you
must:
• Calculate anchor address as seen by that board (as discussed in the
shared memory network chapter).
• Specify SM_ANCHOR_ADRS parameter and rebuild VxWorks for that
CPU.
®
14-19
1. Shared Memory Location/Size
(CPU0)

Example parameter values for CPU0:
SM_OFF_BOARD
SM_ANCHOR_ADRS
SM_MEM_ADRS
SM_MEM_SIZE
SM_OBJ_MEM_ADRS
SM_OBJ_MEM_SIZE
FALSE
((char *) 0xfb800000)
SM_ANCHOR_ADRS
0x80000
(SM_MEM_ADRS+SM_MEM_SIZE)
0x80000
®
14-20
2: Calculating the Anchor Address
(for other CPU’s)
1. If the anchor is in dual ported memory on CPU0, call
sysLocalToBusAdrs( ) on CPU0 to calculate the VMEbus
address of the anchor.
2. Call sysBusToLocalAdrs( ) on each other CPU board to
calculate the local address which maps to the anchor’s
VMEbus address. May need to examine source code for
this routine if this CPU has not booted.
More information, and an example anchor address
calculation, are available in the Shared Memory Network
appendix.
®
14-21
Other Configuration Parameters

Other configuration parameters and their default values:
Constant
Description (default value)
SM_OBJ_MAX_TASK
Maximum number of tasks using
shared memory objects (40)
SM_OBJ_MAX_SEM
Maximum number of
semaphores (30).
SM_OBJ_MAX_MSG_Q
Message queues (10).
SM_OBJ_MAX_MEM_PART
Memory partitions (4)
SM_OBJ_MAX_NAME
Names in database (100).
SM_OBJ_MAX_TRIES
Tries to obtain lock (100).
®
14-22
Optional Products
Overview
Shared Memory Objects (VxMP)
14.3 Virtual Memory (VxVMI)
®
14-23
VxVMI Features

Allows write protecting:
– The interrupt vector table.
– Program text.
– Crucial user data.

Makes application safer.

Makes debugging easier since writing to a protected area
will incur a bus error.
®
14-24
Virtual Addresses
®
14-25
Default Virtual Memory Context

A mapping of virtual to physical addresses is called a
virtual memory context.

A global mapping is defined at system start-up.
– Local memory, on board devices, and some VME addresses are
mapped.
– Same as physical mapping, except some VME addresses are not
mapped.
– Controlled by sysPhysMemDesc structure in sysLib.c.

By default, all tasks use the global mapping.
®
14-26
Other Uses of VxVMI

Can dynamically create new virtual memory contexts.

User is responsible for managing the contexts:
– Initializing virtual to physical address maps in newly created
contexts.
– Swapping between contexts.

Low level support routines provided.

Allows application to restrict a set of addresses to:
– Only to one task.
– Only to a select group of tasks.
– Only through a library.
®
14-27
Including VxVMI

Include /hardware/memory/MMU/MMU Mode/full MMU support
component.

Note: The component .../basic MMU support is not part of
VxVMI. It is bundled with VxWorks to provide support for
cacheLib.
®
14-28
Write Protection Text and Vector Table

Include the component /hardware/memory/MMU/write protect
vector table to write protect the interrupt vector table.

Include /hardware/memory/MMU/write protect program text to
write protect program text.

Prevents accidental modifications.

Intentional modification can still occur (e.g., via
intConnect( )).
®
14-29
Write Protection OverviewUser Data
1. Allocate a page aligned buffer.
2. Fill buffer with data.
3. Modify the state of the page to be read-only.
®
14-30
Allocating Page Aligned Buffers
void * valloc (nBytes)
nBytes
Number of bytes to allocate.

Returns a pointer to allocated buffer, or NULL on error.

Allocated buffer will begin on a page boundary.

nBytes should be a multiple of VM_PAGE_SIZE. If not,
then other data might get write protected when we try to
write protect our buffer.
®
14-31
Changing Page States
STATUS vmStateSet (context, pVirtual, len,
stateMask, state)
context
A VM_CONTEXT_ID, or NULL to use current
context.
pVirtuaVirtual address of page to modify.
len
Number of pages affected (in bytes).
stateMask
Which states to modify.
state
State to set.
®
14-32
Write Protection Example
char *buf;
/* Allocate physical memory on a page boundary */
buf = (char *)valloc (VM_PAGE_SIZE);
/* fill buf with important data */
...
/* write protect virtual memory buf */
vmStateSet (NULL, buf, VM_PAGE_SIZE,
VM_STATE_MASK_WRITABLE,
VM_STATE_WRITABLE_NOT);
®
14-33