Remote IPC over VME Bus

In current implementation of IPC over VME bus the following constraints must be satisfied:

• The kernel must be configured for remote IPC feature over the VME bus (see "IPC Feature Configuration").

• Each ChorusOS system image for every VME bus board must have the same logical and uniform view of all the devices present on the VME bus, through their respective device trees. As the device tree of each VME board will be different, a different ChorusOS archive should be built and booted on each target board. Typically, on genesis2 targets, the file src/bsp/powerpc/genesis2/ src/boot/deviceTree.c must be modified and recompiled for each different CPU board involved in the IPC protocol.

• IPC memory allocated to each CPU board must be in contiguous blocks of 64 Kilobytes on the VME bus.

• The ChorusOS system image must be booted first on the VME bus system controller, and then on other (non-system controller) boards, in any order.

The following example describes what the device sub-tree representing the VME bus on each board should be. It assumes that your target consists of three VME boards in cage slots 0,1, and 2, your VME bus system controller is located in slot 0, 64Kb of memory is used on each board for IPC, and VME memory dedicated to IPC is allocated as follows:

Table A-1 VME memory dedicated to IPC

	bridge I/O registers	IPC memory
board 0:	0x20000000-0x2000ffff	0x20030000-0x2003ffff
board 1:	0x20010000-0x2001ffff	0x20040000-0x2004ffff
board 2:	0x20020000-0x2002ffff	0x20050000-0x2005ffff

The device sub-tree representing the VME bus on each board is illustrated in Figure A-1.

Figure A-1 Device sub-tree representing the VME bus

The main differences between ChorusOS system images for each board are:

• the properties associated with each VME bus controller device node

• the presence of the BUSCOM_PROP_REMOTE property in each child node. This property selects which local or remote instance of the bus communication (BUSCOM) VME device driver will be started on each node.

Building and booting ChorusOS system images on a VME target system is similar to the one described in the previous example. Embedding only the genesis2 targets in a system image is achieved as follows:

• Edit the file src/bsp/powerpc/genesis2/src/boot/deviceTree.c.

  Change VME_MAX_BOARD to 3:

  #define VME_MAX_BOARD 3

• For each board:

  • Change LOCAL_CPU to 0 for board 0, 2 for board 2, or 3 for board 3, for example:

    #define LOCAL_CPU     0

  • Compile the BSP, and build a ChorusOS system image using make chorus.

  • Rename the ChorusOS system image to a file suffixed by the board number, for example chorus.RAM.0.

• Boot the system controller target first, using the system image suffixed with .0.

• Boot your other targets in any order, using the appropriate archive.