®14-1

Optional ProductsOptional Products

14.1 Overview

Shared Memory Objects (VxMP)

Virtual Memory (VxVMI)

®14-2

OverviewOverview

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

OverviewOverview

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

OverviewOverview

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

OverviewOverview

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 ProductsOptional Products

Overview

14.2 Shared Memory Objects (VxMP)

Virtual Memory (VxVMI)

®14-7

VxMP FeaturesVxMP 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 UsageExample 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 ObjectsRegistering Shared Objects

STATUS smNameAdd (name, objId, type)name String used to name this object.

objId Shared memory object identifier (e.g., SEM_ID or MSG_Q_ID).

type 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 ObjectsFinding Shared Objects

STATUS smNameFind (name, &objId, &type, wait)

name Name to find in the database.

objId Object id returned through this variable.

type Object type returned.

wait 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 SemaphoresShared 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 QueuesShared 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 ManagerShared 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 PartitionsCreating Shared Memory Partitions

To creates additional shared memory partitions:

PART_ID memPartSmCreate (pPool, poolSize)pPool Address of some shared memory.

poolSize Size of this pool.

Manipulated with memPartLib routines (just like local partitions).

®14-15

TerminologyTerminology

Shared Memory MasterShared Memory Master - CPU 0. Initializes the shared memory objects data structures. Once initialized, all boards are peers.

Shared MemoryShared 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.

AnchorAnchor - Structure containing ready value and an offset to shared memory. Must be at an address known by all CPU’s.

HeartbeatHeartbeat - Integer incremented once per second by CPU0, used to indicate that the shared memory objects system is alive.

Ready ValueReady Value - Stored in anchor by CPU0 to indicate that the shared memory objects facility is initialized.

®14-16

System RequirementsSystem 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

CaveatsCaveats

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

InitializationInitialization

Include the component /operating system components/kernel /operating system components/kernel components/shared memory objectscomponents/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/Size1. Shared Memory Location/Size(CPU0)(CPU0)

Example parameter values for CPU0:

SM_OFF_BOARD FALSESM_ANCHOR_ADRS ((char *) 0xfb800000)SM_ANCHOR_ADRS ((char *) 0xfb800000)SM_MEM_ADRS SM_ANCHOR_ADRSSM_MEM_SIZE 0x80000 SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE)SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE)SM_OBJ_MEM_SIZE 0x80000SM_OBJ_MEM_SIZE 0x80000

®14-20

2: Calculating the Anchor Address2: Calculating the Anchor Address(for other CPU’s)(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 ParametersOther 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 ProductsOptional Products

Overview

Shared Memory Objects (VxMP)

14.3 Virtual Memory (VxVMI)

®14-23

VxVMI FeaturesVxVMI 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 AddressesVirtual Addresses

®14-25

Default Virtual Memory ContextDefault 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 VxVMIOther 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 VxVMIIncluding VxVMI

Include /hardware/memory/MMU/MMU Mode/full MMU support/hardware/memory/MMU/MMU Mode/full MMU support component.

Note: The component .../basic MMU.../basic MMU support is not part of VxVMI. It is bundled with VxWorks to provide support for cacheLib.

®14-28

Write Protection -Write Protection -Text and Vector TableText and Vector Table

Include the component /hardware/memory/MMU/write protect /hardware/memory/MMU/write protect vector tablevector table to write protect the interrupt vector table.

Include /hardware/memory/MMU/write protect program text/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 Overview-Write Protection Overview-User DataUser 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 BuffersAllocating 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 StatesChanging 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 ExampleWrite 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);