Andrew,
Andrew Johnson wrote:
> Kate Feng wrote:
> >
> > Do you mean the dummy read following the last write is needed for
> > only vxWorks-mvme5500 ? Or is it needed for almost all the powrPC
> > boards using VxWorks ? Does it apply to all the VME boards ?
>
> A dummy read following the last write is needed for Interrupt Service
> Routines running on most CPU boards nowadays, and certainly for any
> Universe-2 based board. Even the old 68K boards using the VMEchip2 can
> have Write Posting enabled on their VME master windows, although I don't
> think the write pipeline is anywhere near as long in that case so
> omitting the read might not cause any noticable effects. A common
> symptoms of omitting the read is to cause suprious interrupts which will
> probably have a vector of 0xff. These often appear to be harmless, but
> they do waste CPU time.
I clearly understood what you stated in your first E-mail regrading the
dummy read in ISR. I probably misunderstood Eric's message about the
dummy read. I thought he was talking about the non-ISR related issue
on the VME universe side. Anyway, the reason why I wanted to
clarify is that there is a cavet about the MVME5500 board, which is
due to its Discovery I system controller. It is a different issue from
what was discussed about the dummy read.
* Some PCI devices require Synchronization Barriers or PCI ordering
* for synchronization. For example, the VME-OMS58 motor controller we
* used at NSLS requires either enhanced CPU Synchronization Barrier
* or PCI-ordering (only one mechanism is allowed) for the PCI-write.
* The PCI-ordering simply implements a PCI configuration read for one byte.
The implementation can be found at :
http://www.nsls.bnl.gov/facility/expsys/software/EPICS/
RTEMS-MVME5500 BSP v1.3 : pci/pci_interface.c.
The example is described at synAppRTEMS/motorApp/drvOms58.cc
and RTEMS-MVME5500 BSP v1.3/README.VME.
So far, this mechanism does not seem to be needed in any other
VME devices used in our RTEMS-MVME5500 applications. It is not needed
for the RTEMS-MVME2307 at all even for the VME-OMS58 motor controller.
In spite of the PCI sync overhead for the Oms58 motor controller, I do
not see the runtime performance of RTEMS-mvme5500 being compromised as
compared with that of RTEMS-mvme2307.
Jukka Pietarinen wrote :
> I believe it has to be the same register the write was targeted at. I
> had problems accessing indirect RAM (sequence RAM of EVG) with MVME5500
> running vxWorks. The only solution I found was to read back the address
every time
> before reading the data.
If this is non-ISR related on the MVME5500, you might want to check out
the cavet I pointed out, which "might be" a more proper way to implement
it. Just a suggestion since I do'nt have your board.
Andrew Johnson wrote :
>
>
> > Is this implemented in other vxWorks-PPC site such as APS or any
> > other facility ? I did'nt notice this in synApp which was written by
> > APS, but I am off-site now that I can'nt verify the code.
>
> It is not really sensible to try and resolve this issue in the BSP,
??? I did'nt say the dummy read is implemented in RTEMS BSP.
> it
> really should be the VME slave board driver's ISR that generates the
> dummy read since the BSP is probably not aware of any specific VMEbus
> addresses that it can read from (and it would not be a good idea to
> perform an access that generates a Bus Error as this would completely
> kill interrupt performance).
This is how it is implemented in RTEMS.
Kate
- References:
- Dev lib off-board register access Rees, NP (Nick)
- Re: Dev lib off-board register access Dirk Zimoch
- Re: Dev lib off-board register access Eric Bjorklund
- Re: Dev lib off-board register access Kate Feng
- Re: Dev lib off-board register access Andrew Johnson
- Navigate by Date:
- Prev:
Re: Dev lib off-board register access Andrew Johnson
- Next:
Re: Dev lib off-board register access Andrew Johnson
- 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: Dev lib off-board register access Andrew Johnson
- Next:
Re: Dev lib off-board register access Eric Bjorklund
- 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
|