Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Tue, 10 Apr 2007 17:26:28 -0400

On Tue, 2007-04-10 at 16:00 -0500, Andrew Johnson wrote:
> 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.

In the case of an ioc application, the application source code does not
change between a vxWorks 5.5.x and vxWorks 6.x kernel.

However, in the case of a "share top" which contains drivers such as
vxStats there will be an impact.  So, vxStats is riddle with "ifdefs" or
a new branch is made.  In the case of vxStats we will be working on some
abstraction layer to hide vxWorks API changes.

> 
> > 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.
Okay, this is the way we will go.

> 
> > 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...
> 
Sounds good.

> > 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.
The compiler options are actually CPU specific and BSP specific.
One example is the altivec support, but you already handle this with an
altivec suffix in the target name.  I agree that the options may not be
necessary always.

> 
> 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.
Hmmm, sounds worth looking into.

Thanks,
Ernest

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System