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