EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: VME Bus Error handling on MVME3100 and 6100 boards
From: Kate Feng <[email protected]>
To: Till Straumann <[email protected]>
Cc: Andrew Johnson <[email protected]>, EPICS tech-talk <[email protected]>
Date: Thu, 24 Aug 2006 09:36:28 -0400
Till Straumann wrote:

Andrew Johnson wrote:

Till Straumann wrote:

I was on vacation last week but I'd like to wrap this thread up with the
comment that regarding bus errors, the MVME5500 and the MVME6100
are not any different. AFAIK, none of those have the MCP interrupt
to the CPU hooked up, so even if the Tsi148 would generate a PCI target-
abort it would still not raise a machine-check interrupt.


I don't have the programmer's manual for the Discovery-II (MV64360) chip so I don't know whether the Host Bridge has the necessary capability or connections.

I don't have it either. Kate could clarify for the GT64260. Looking at the linux
drivers, I doubt it. They install regular ISRs to detect PCI errors (such as target abort).

Discovery deos not have the necessary capability or connections to the MCP. I was told that
on the boards which use a Discovery system controller, the MCP signal is connected to a
pull-up and therefore not used as it is on other boards. That's the design on the
MVME5500 and MVME6100 boards. I do not see it as a big problem for the
MVME5500 board because ......


Till Straumann wrote :

(currently, a PCI error such as target abort is routed to the one
and only EE interrupt of the powerpc).


The MCP, if available, is routed to the EE interrupt as well.


You probably know more about the hardware than I do, and if there's no connection from the Bridge to the MCP input I accept what you say; this only increases my dislike of the MVME 3100 and 6100 boards though.

You should dislike the marvell system controllers (I really dislike that whole thing
from the interrupt, i2c to the ethernet controller)
and that company's policy of not granting access to documentation (w/o signing
an NDA).

It's becoming a fact of life for the RTEMS programmers like me. We just had one signed last month.




Till Straumann wrote:

OTOH, a VME bus error on read can be reported simply by using
the respective interrupt (as demonstrated earlier).


I will be implementing that in my version of the mv6100 BSP (but as demonstrated earlier though, this is of little use if the Bus Error occurs inside an ISR. I know about one device that will perform 97 bus accesses inside its ISR if it gets all-1s from its read cycles.

This driver should probably be rewritten. That many VME accesses from an ISR
introduce serious latencies (even w/o bus timeouts).


Andrew Johnson wrote :
> Ah, but in normal operation it probably only performs 4 or 5 bus accesses at most; the problem comes if it thinks (from erroneous all-1s >return values when reading its status registers) that it needs to do I/O on every one of its input and output channels. This could very easily >happen if someone hot-swapped out a VME64 IPAC carrier board the device was mounted on (which shouldn't happen since this driver is >not hot-swap safe, but it might still occur by mistake).


For the MVME6100, I am more concerned with the
"making use of the dud all-1's read data in the process"
that Andrew mentioned earlier. I do'nt seem to get the answer from the
http://www.aps.anl.gov/epics/tech-talk/2006/msg00892.php, which was posted by Till.
Is it in the "vmeTsi148ClearVMEBusErrors(&erraddr);" ? How is it programmed?



We have one application that could be optimied by the PCI bandwidth
that MVME61000 offers ( 800 MHZ).


Also, I am still not sure about the  "MBLT" transfer of
the VME backplane, whih was posted at
http://www.aps.anl.gov/epics/tech-talk/2006/msg00888.php.
I assumed it was limited by the capability of the DMA controller
instead of the bus speed because I assume a simple test could be done
easily by using two MVME6100s on a VME320 crate.  Perhaps
Till can verify this ??

Andrew Johnson wrote:
> Anyone interested in MicroTCA to replace the now aging VMEbus?

Why do you think VMEbus is aging ?  I was researching the VXS bus for
a short while and comapred it with  the MVME6100 solution for our
application.  VMEbus does not seem to be aging for me.

Regards,
Kate





Replies:
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
References:
VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Kate Feng
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann

Navigate by Date:
Prev: ezca and ENUM D. Peter Siddons
Next: Re: ezca and ENUM Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·