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
- Replies:
- Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- References:
- EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- Re: EPICS R3.14.9 and vxWorks Andrew Johnson
- Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- Navigate by Date:
- Prev:
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- Next:
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- Next:
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|