Experimental Physics and
Industrial Control System

"Bjorklund, Eric A" <[email protected]> · Fri, 10 May 2013 23:39:51 +0000

Hi Michael & Andrew.

Couldn't resist throwing my 2 cents worth in here...

I'm currently on a voyage of discovery regarding vxWorks BSPs for x86 architectures, and the picture gets even worse.  The sysInByte/Word/Long routines all appear to be for I/O space access, with nothing (as far as I can discover) for memory-mapped I/O.  As you may have noticed, WR doesn't even provide header definitions for any of the sys(In/Out)... routines  so obviously they don't feel the need for any consistency here.

So now for the 2 cents:

1st Cent:  Maybe we should just create our own standard for vxWorks MMIO routines.  WR does provide architecture-specific barrier macro's (at least in V6), so maybe we should just roll our own with C volatile pointers and the WR barrier macros.

2nd Cent:  I would definitely like to see this added to 3.14.

Thanks,
-Bj

PS (or 3rd cent) If you need a beta tester I have a need right now.

On May 10, 2013, at 4:20 PM, Andrew Johnson wrote:

> Hi Michael,
> 
> On 2013-05-10 you wrote:
>> On 05/10/2013 03:55 PM, Till Straumann wrote:
>>> ...
>>> Let's face it: Reordering of loads even to guarded and cache-inhibited
>>> memory is not prohibited and thus could happen. ...
>> 
>> I would agree with Till in this case.  Existing hardware probably isn't
>> taking advantage of all the reordering allowed by the PPC ISA.  So even
>> if this isn't a problem with current hardware, future hardware could.
>> So I think it is prudent to do the "right thing".
> 
> I agree.  I'd like to add the following article into the conversation, which I 
> found informative even though the later parts mostly talk about AIX:
>  http://www.ibm.com/developerworks/systems/articles/powerpc.html
> 
> I suspect that the (older) PowerPC CPUs that we mostly use at the APS don't 
> actually do reordering (on guarded memory at least) which is why we haven't 
> seen the need for this here yet.  The FreeScale e500 family CPUs such as on 
> the MVME3100 may be a different matter however.
> 
>> In the interest of making this easier to do I'm proposing that the MMIO
>> wrappers from devLib2 be included in EPICS Base 3.15.
>> 
>> https://code.launchpad.net/~epics-core/epics-base/devlib2mmio/+merge/163365
>> 
>> I would ask that those interested (Till and Eric especially) please look
>> this over and see if it is sufficient.  Right now it has
>> speciallizations only for vxWorks and RTEMS (PPC and x86 only). Other
>> targets fall back to C volatile pointers, which are better than nothing.
> 
> We will also need this to work on vxWorks-68040 where the compiler will pull 
> in your vxWorks/epicsMMIO.h header but the BSPs don't have any of the 
> sys{In,Out}{Byte,16,32,Word,Long} routines (that CPU doesn't do any reordering 
> either).
> 
> On the VxWorks PowerPC targets there is the problem that Wind River's mv2100 
> BSP provides these routines:
>    UCHAR  sysInByte (ULONG);
>    void   sysOutByte (ULONG, UCHAR);
>    USHORT sysInWord (ULONG);
>    void   sysOutWord (ULONG, USHORT);
>    ULONG  sysInLong (ULONG);
>    void   sysOutLong (ULONG, ULONG);
> The mv2700 and mv5100 BSPs provides these:
>    UCHAR  sysInByte (ULONG);
>    void   sysOutByte (ULONG, UCHAR);
>    UINT16 sysIn16 (UINT16 *);
>    void   sysOut16 (UINT16 *, UINT16);
>    UINT32 sysIn32 (UINT32 *);
>    void   sysOut32 (UINT32 *, UINT32);
> while the mv6100 BSP provides these:
>    UCHAR  sysInByte (ULONG);
>    void   sysOutByte (ULONG, UCHAR);
>    UINT16 sysIn16 (UINT32);
>    void   sysOut16 (UINT32, UINT16);
>    UINT32 sysIn32 (UINT32);
>    void   sysOut32 (UINT32, UINT32);
> The mv3100 has these:
>    UCHAR  sysInByte (UCHAR *)
>    VOID   sysOutByte (UCHAR *, UCHAR);
>    USHORT sysInWord (ULONG address);
>    VOID   sysOutWord (ULONG address, UINT16 data);
>    ULONG  sysInLong (ULONG address);
>    VOID   sysOutLong (ULONG address, ULONG data);
> and the mv7100 BSP these:
>    UCHAR  sysInByte (ULONG);
>    VOID   sysOutByte (ULONG, UCHAR);
>    USHORT sysInWord (ULONG address);
>    VOID   sysOutWord (ULONG address, UINT16 data);
>    ULONG  sysInLong (ULONG address);
>    VOID   sysOutLong (ULONG address, ULONG data);
> 
> Note the subtle differences in argument types (which don't really matter) and 
> routine names (which do).  We may have to get users to install aliases for 
> these routines in their BSPs, since the same generic vxWorks-ppc32 binary can 
> be loaded on almost all those boards but would only succeed on half of them.
> 
> Should we consider merging this into 3.14 instead of 3.15?  I'm open to 
> discussion of that.
> 
> - Andrew
> -- 
> It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it. -- Upton Sinclair

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System