Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 10 Apr 2007 16:00:09 -0500

Hi Ernest,

The first way is how we

expect sites to manage this situation, which synchronizes IOC upgrades

from vxWorks 5.5.x to 6.x at the same time as you upgrade them from one

version of Base to the next. That's what we've done here in the past,

and it encapsulates the change nicely.

This does not work.

Actually it can, but it takes a bit of effort...

For ioc application top you choose one version of EPICS in the

$IOCTOP/configure/RELEASE file.

A given ioc application top can have many IOCs. Each IOC could have a

different version of vxWorks.  Especially, during any type of migration
period where one can't upgrade all IOCs at the same time.

That is one of the circumstances that causes us to start a new branch of

our IOC application top. The two branches can co-exist for extended

periods if necessary, but in general we try to make this as short a time

as possible because it means you have to commit every change to CVS

twice, once on each branch (NB doing a cvs update with two -j options

can make this task easier). Application developers get tired of making

the changes in both branches during that period, and this gives them an

extra incentive to upgrade their older IOCs to the new version as soon

as they can.

The option below is close to what I need.  Except that I need the
vxWorks 5.5.x and vxWorks 6.x targets to be built at the same time.
So, I am back to creating another set of CONFIG files in
$EPICS_BASE/configure/os

The target alias files I posted do exactly that - after adding those two

files to configure/os you just add the vxWorks 6.x target architecture

vxWorks6-ppc604_long to the CROSS_COMPILER_TARGET_ARCHS setting in your

configure/CONFIG_SITE file as well as the vxWorks-ppc604_long target

which handles the vxWorks 5.5.x systems.

Given our history with WindRiver, they will most likely make changes in
the future based on OS version number.

We now have the infrastructure in CONFIG.Common.vxWorksCommon to handle

that...

We have newer BSPs from the same family (i.e. PowerPC) that don't have
the same compiler options.  Sometimes the compiler options are BSP
specific.

Do they fall under the same CPU type? Are you sure the different

options are really necessary? There is often a difference between the

options necessary to compile a vxWorks BSP and those necessary to

compile application code; the BSP is more dependent on the particular

CPU instructions, whereas applications code can be pretty generic.

We run our MC68060 CPUs (mv172, mv177) on code compiled for the MC68040

because the user-level code that the C and C++ compiler generates is not

CPU-specific (there may be a very slight performance hit on the faster

68060 CPUs, but it's not noticable). Note that there is a standard

PowerPC ABI which we could probably use for all PowerPC targets, thus

omitting even the 603/604 distinction that we currently make.

Kay-Uwe Kasemir wrote:

Here at APS I never need to do that though; intead I include all my
Board-specific code in the vxWorks boot image and provide a  generic API
that the device support routines call; for example I have three
different implementations of my VME DMA API, which now works on the

VMEchip2, Universe-2 and Tempe chips; Marty's Generic Transient

Recorder

support code doesn't care which kind of board it's running on, it  just
calls my API.

Does this mean that every vxWorks contains this DMA support,
even if the IOC doesn't need DMA?

Yes. It's not as if we're short of RAM, and these are usually only a

couple of Kbytes which is nothing compared to the size of the bootfile.

How many driver modules of this type do you add to your vxWorks kernel?

The VME DMA API and VME A24 Memory allocation are the easy ones to

separate out; there are others such as the VME Bus Error handler that I

consider more a part of the BSP. WRS already provide things like

sysBusToLocalAdrs() and the AUX Clock, and I think of these as just a

further extension to those kinds of facilities.

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System