Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 10 Apr 2007 11:20:11 -0500

Hi Ernest,

Ernest L. Williams Jr. wrote:

I suppose there will be some sites that move into vxWorks 6.x but still
have vxWorks 5.5 targets as well.  What recommendation do you have to
handle this?  We could have to separate versions of EPICS BASE.
Does no good to change the VXWORKS version number in the config files as
it will simply overwrite libraries for vxWorks 6 or 5 depending on which
one you built first.

There are two ways to handle this situation: Use a completely separate

installation of EPICS Base (the best way to do this is just to bump up

your local version number for Base; in our case we'd go from 3-14-9-asd1

to 3-14-9-asd2 for example), or create your own target architecture

which derives from one of the standard ones. 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.

If you really want to create your own target architecture instead, the

difference with R3.14.9 is that the infrastructure for vxWorks 6 is now

built in, so you only need to create two files in configure/os to do

this; I call this target aliasing:

::::::::::::::
CONFIG.Common.vxWorks6-ppc604_long
::::::::::::::
# Definitions for vxWorks6-ppc604 targets with >32MB of RAM
# Site-specific overrides go in CONFIG_SITE.Common.vxWorks6-ppc604_long
#-------------------------------------------------------

# Inherit the settings from vxWorks-ppc604_long
include $(CONFIG)/os/CONFIG.Common.vxWorks-ppc604_long

::::::::::::::
CONFIG_SITE.Common.vxWorks6-ppc604_long
::::::::::::::
# Site Specific definitions for the vxWorks6-ppc604_long target
#-------------------------------------------------------

# Inherit the settings from vxWorks-ppc604_long
-include $(CONFIG)/os/CONFIG_SITE.Common.vxWorks-ppc604_long

VXWORKS_VERSION = 6.3
WIND_BASE = /usr/local/vw/vxWorks6.3-$(ARCH_CLASS)

Problems with vxWorks build with new config file structure:
(1) Can't build for vxWorks 5.5.X and vxWorks 6.X
This is not good. Since our production environment includes both.
So, vxWorks-ppc604 gets overwritten by second build of EPICS BASE
against a different version of vxWorks.  I am sure that other sites
that move to vxWorks 6 will experience this.

This is not a problem if you just synchronize a vxWorks version upgrade

with a Base version upgrade, which could be just a local version number

increase.

I think we should have the config files contain vxWorks major version
and BSP name like before.  Looks like you allow RTEMS to do this?

The generated RTEMS IOC binary includes all the OS/BSP code, therefor

the target has to define the BSP to be used. On vxWorks the OS/BSP code

is currently separate, and there's nothing in the IOC code which needs

to be specific to anything more than the CPU. We stopped including the

BSP name in the EPICS target name when we found we were compiling the

same code 4 times with the *exact* same compiler options for the mv162,

mv167, mv172 and mv177 targets.

For example, we are starting to use the altivec support on the

MVME5110 but the MVME5100 does not have altivec support.

We could have vxWorks-ppc604_altivec, I guess.

That target already exists in R3.14.9, but unfortunately it is broken; I

think the fix is for epicsThreadCreate() to set the VX_ALTIVEC_TASK flag

on altivec builds for the IOC to run properly. I've not tried to do this

yet, but it shouldn't be hard to do.

Another example is using
the BSP/target name to discover whether we have a UNIVERSE or Tsi148
interface for a DMA driver that we may write.  Having, the scheme that
we used last time just turns into a bit more compile time and disk
space, right?

You can use the above target aliasing technique if you really want to

encode BSP information into your target architecture name.

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.

- 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