Optional Products

1
Optional Products
14.1 Overview Shared Memory Objects
(VxMP) Virtual Memory (VxVMI)
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.

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.

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.

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.

6
Optional Products
Overview 14.2 Shared Memory Objects
(VxMP) Virtual Memory (VxVMI)
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( )).

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.

9
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).
• 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.

10
Finding 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.

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.

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.

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
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
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 CPUs.
• Anchor - Structure containing ready value and an
  offset to shared memory. Must be at an address
  known by all CPUs.
• 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.

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
  CPUs to 20 (CPU0 through CPU19). Hardware
  considerations may limit this number further.

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.

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.

19
1. Shared Memory Location/Size(CPU0)

• Example parameter values for CPU0
• SM_OFF_BOARD FALSESM_ANCHOR_ADRS ((char )
  0xfb800000)SM_MEM_ADRS SM_ANCHOR_ADRSSM_MEM_
  SIZE 0x80000 SM_OBJ_MEM_ADRS
  (SM_MEM_ADRSSM_MEM_SIZE)SM_OBJ_MEM_SIZE 0x80000

20
2 Calculating the Anchor Address(for other
CPUs)

• 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 anchors 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.

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

22
Optional Products
Overview Shared Memory Objects
(VxMP) 14.3 Virtual Memory (VxVMI)
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.

24
Virtual Addresses
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.

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.

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.

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( )).

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

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.

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.

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_N
  OT)