Download torch15

Chapter - 15
Optional Products
 Wind River Systems, Inc. 1997
Optional Products
15.1
Overview
WindView
WindNet SNMP
Shared Memory Objects (VxMP)
Virtual Memory (VxVMI)
15-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 UNIX
workstation. Allows development,
testing, and prototyping without target
hardware.
RtX-WINDOWS
Scalable X windows / Motif package.
Useful for applications which need to
display data graphically.
WindNet SNMP
Provides remote network management
of target via SNMP.
15-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
Host based debugging tool with GUI.
Allows monitoring of events like context
switches, interrupts, semGive( ),
msgQSend( ). Helps tune and debug system.
15-4
Optional Products
Overview
15.2
WindView
WindNet SNMP
Shared Memory Objects (VxMP)
Virtual Memory (VxVMI)
15-5
Overview



15-6
“Logic Analyzer” for VxWorks
Allows graphical viewing of multitasking application
Helps diagnose:
 race conditions
 deadlocks
 missed deadlines
 system crashes
Host/Target Relationship

15-7
Event uploading can occur:
 During run time, automatically or under program control
 After system crash (for post-mortem debugging)
Event Logging



15-8
Three modes with increasing information (and overhead):
 Log context switches and interrupts only
 Also log state transitions
 Also log instrumented objects
Some objects which can be instrumented include:
 semaphores
 message queues
 signals
 tasks
Supports user defined events
View Graph
15-9
Zoom In on Task Exit
15-10
Task States and Events

Task states are displayed as:

Events are displayed with icons, such as:
15-11
Events

15-12
Event icons use a common paradigm:
Priority Inversion Example
15-13
Priority Inheritance Example
15-14
Optional Products
Overview
WindView
15.3
WindNet SNMP
Shared Memory Objects (VxMP)
Virtual Memory (VxVMI)
15-15
The Network Management Problem
Administrators of internets face two main problems:
 “Why can’t I communicate with Host A?”
 “Why is the network so slow?”
15-16
The SNMP Solution
SNMP, The Simple Network Management Protocol, provides a
standardized way for managing network nodes:
 Supports management of all network devices
 Query nodes to gather statistics on their health
 Reconfigure a node remotely
 Standard for the TCP/IP Protocol Suite
15-17
The SNMP Management Paradigm
15-18
WindNet SNMP Agent





15-19
Bilingual SNMP Agent which supports SNMPv1 and SNMPv2c
MIB-II TCP/IP statistics
Extensible agent which supports creating custom MIB extensions,
scaling the agent MIB to include only relevant groups, and the WRS
demo MIB.
Dynamic addition and removal of MIB variables.
Compatible with standard NMS’s such as SunNet Manager, HP
OpenView, and Netview/6000.
Optional Products
Overview
WindView
WindNet SNMP
15.4
Shared Memory Objects (VxMP)
Virtual Memory (VxVMI)
15-20
VxMP Features




15-21
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( )).
Example Usage


15-22
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.
Registering 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).
The type of shared memory object (e.g.
binary semaphore or message queue).
type

Registers the object in the name database.

Typically called right after object creation.
15-23
Finding Shared Objects
STATUS smNameFind (name, &objId, &type,wait)

15-24
name
Name to find in the database.
objId
type
wait
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.
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.
15-25
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.

15-26
Once created, msgQLib routines (e.g., msgQSend( ), msgQReceive(
)) work as before, except can not send a message from an ISR.
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 * smObjGlobalToLocal (globalAdrs)
15-27
Creating 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).
15-28
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.
15-29
System Requirements


15-30
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.
Caveats



15-31
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.
Initialization



15-32
Define INCLUDE_SM_OBJ in config.h.
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 in config.h and rebuild
VxWorks for that CPU.
1. Shared Memory Location/Size
(CPU0)
Example wind/target/config/target/config.h stub for CPU0:
#define SM_OFF_BOARD FALSE
#if
#undef
#define
#define
#define
#define
#define
#else /*
#define
#define
#define
#define
#endif /*
15-33
SM_OFF_BOARD
SM_ANCHOR_ADRS
SM_ANCHOR_ADRS
SM_MEM_ADRS
SM_MEM_SIZE
SM_OBJ_MEM_ADRS
SM_OBJ_MEM_SIZE
SM_OFF_BOARD */
SM_MEM_ADRS
SM_MEM_SIZE
SM_OBJ_MEM_ADRS
SM_OBJ_MEM_SIZE
SM_OFF_BOARD
((char *) 0xfb800000)
SM_ANCHOR_ADRS
0x80000
/* 512K */
(SM_MEM_ADRS+SM_MEM_SIZE)
0x80000
/* 512K */
NONE /* NONE = malloc */
0x10000
/* 64K */
NONE /* NONE = malloc */
0x10000
/* 64K */
*/
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.
15-34
Other Configuration Parameters
The following configuration parameters are defined in configAll.h,
and may be overridden in config.h:
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).
15-35
Optional Products
Overview
WindView
WindNet SNMP
Shared Memory Objects (VxMP)
15.5
15-36
Virtual Memory (VxVMI)
VxVMI Features



15-37
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.
Virtual Addresses
15-38
Default Virtual Memory Context



15-39
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.
Other Uses of VxVMI



15-40
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.
Including VxVMI


15-41
Define INCLUDE_MMU_FULL in config.h.
Note: The symbol INCLUDE_MMU_BASIC is not part of VxVMI.
It is bundled with VxWorks to provide support for cacheLib.
Write Protection -Text
and Vector Table




15-42
Define INCLUDE_PROTECT_VEC_TABLE to write protect the
interrupt vector table.
Define INCLUDE_PROTECT_TEXT to write protect program text.
Prevents accidental modifications.
Intentional modification can still occur (e.g., via intConnect( )).
Write Protection Overview-User
Data
1. Allocate a page aligned buffer.
2. Fill buffer with data.
3. Modify the state of the page to be read-only.
15-43
Allocating Page Aligned Buffers
void * valloc (nBytes)
nBytes



15-44
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.
Changing Page States
STATUS vmStateSet (context, pVirtual, len,
stateMask, state)
15-45
context
A VM_CONTEXT_ID, or NULL to use
pVirtual
len
stateMask
state
current context.
Virtual address of page to modify.
Number of pages affected (in bytes).
Which states to modify.
State to set.
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);
15-46