® 14-2 Optional Products 14.1Overview Shared Memory Objects (VxMP) Virtual Memory (VxVMI)

® 14-3 Overview The following products may be purchased separately if desired. BSP Porting KitAssists porting VxWorks to a new board on a supported architecture. VxSimVxWorks simulation on a Solaris, HP-UX, or Windows host. Full simulator includes networking support and allows mulitiple simulators per host. WindNet SNMPProvides remote network management of target via SNMP. OSPFOpen Shortest Path First link-state routing protocol. More powerful than RIPv1/v2.

® 14-4 Overview StethoScopeHost based debugging tool with GUI. Monitor VxWorks program variables in real time, or store data and analyze later. Also contains a task profiler. VxMPHigh speed multiprocessing tools for distributed applications needing to communicate over the VMEbus. VxVMIVirtual memory support. Can restrict a tasks access to certain addresses. WindViewWindView support available for non-simulator targets as an optional product. TrueFFSFlash file system--provides wear-leveling and redundancy on FLASH parts.

® 14-5 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 /HTMLWorkseNavigator is an embeddable browser, based on Netscape Navigator; includes a toolkit for customization and scalability. HTMLWorks allows construction of HTML-based graphical interfaces.

® 14-6 Overview CodeTestCode coverage and memory leak checking tool. WindNavigatorCode 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-7 Optional Products Optional Products Overview 14.2Shared Memory Objects (VxMP) Virtual Memory (VxVMI)

® 14-8 VxMP Features Allows multiprocessing on the VMEbus. Faster than shared memory network. Components: Name databaseAllows boards to share information on objects. Shared semaphoresFor mutual exclusion and synchronization. Shared message queuesFor message passing. Shared memory managerTo dynamically allocate and free shared memory blocks. Familiar interface (e.g., semGive( ), msgQSend( )).

® 14-9 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.

® Registering Shared Objects STATUS smNameAdd (name, objId, type) nameString used to name this object. objIdShared memory object identifier (e.g., SEM_ID or MSG_Q_ID). typeThe 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.

® Finding Shared Objects STATUS smNameFind (name, &objId, &type, wait) nameName to find in the database. objIdObject id returned through this variable. typeObject type returned. waitWait 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.

® 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.

® 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)

® Creating Shared Memory Partitions To creates additional shared memory partitions: PART_ID memPartSmCreate (pPool, poolSize) pPoolAddress of some shared memory. poolSizeSize of this pool. Manipulated with memPartLib routines (just like local partitions).

® Terminology Shared Memory Master Shared Memory Master - CPU 0. Initializes the shared memory objects data structures. Once initialized, all boards are peers. Shared Memory 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 Anchor - Structure containing ready value and an offset to shared memory. Must be at an address known by all CPU’s. Heartbeat Heartbeat - Integer incremented once per second by CPU0, used to indicate that the shared memory objects system is alive. Ready Value Ready Value - Stored in anchor by CPU0 to indicate that the shared memory objects facility is initialized.

® 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.

® 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.

® Initialization /operating system components/kernel components/shared memory objects 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.

® Shared Memory Location/Size (CPU0) Example parameter values for CPU0: SM_ANCHOR_ADRS ((char *) 0xfb800000) SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE) SM_OBJ_MEM_SIZE 0x80000 SM_OFF_BOARD FALSE SM_ANCHOR_ADRS ((char *) 0xfb800000) SM_MEM_ADRS SM_ANCHOR_ADRS SM_MEM_SIZE 0x80000 SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE) SM_OBJ_MEM_SIZE 0x80000

® : 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.

® Other Configuration Parameters Other configuration parameters and their default values: ConstantDescription (default value) SM_OBJ_MAX_TASKMaximum number of tasks using shared memory objects (40) SM_OBJ_MAX_SEMMaximum number of semaphores (30). SM_OBJ_MAX_MSG_QMessage queues (10). SM_OBJ_MAX_MEM_PARTMemory partitions (4) SM_OBJ_MAX_NAMENames in database (100). SM_OBJ_MAX_TRIESTries to obtain lock (100).

® Optional Products Overview Shared Memory Objects (VxMP) 14.3Virtual Memory (VxVMI)

® 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.

® Virtual Addresses

® 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.

® 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.

® Including VxVMI /hardware/memory/MMU/MMU Mode/full MMU support Include /hardware/memory/MMU/MMU Mode/full MMU support component..../basic MMU Note: The component.../basic MMU support is not part of VxVMI. It is bundled with VxWorks to provide support for cacheLib.

® Write Protection - Text and Vector Table /hardware/memory/MMU/write protect vector table Include the component /hardware/memory/MMU/write protect vector table to write protect the interrupt vector table. /hardware/memory/MMU/write protect program text 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( )).

® 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.

® Allocating Page Aligned Buffers void * valloc (nBytes) nBytesNumber 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) contextA VM_CONTEXT_ID, or NULL to use current context. pVirtuaVirtualaddress of page to modify. lenNumber of pages affected (in bytes). stateMaskWhich states to modify. stateState 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);