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
- Replies:
- Re: mmio in epics base Bjorklund, Eric A
- Navigate by Date:
- Prev:
Re: new archiver problem James F Ross
- Next:
Re: mmio in epics base Bjorklund, Eric A
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: new archiver problem James F Ross
- Next:
Re: mmio in epics base Bjorklund, Eric A
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|